netdev - Rules for retransmitting sk

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <CAGXJAmwciox8tkVjjK-0T+x=KbetSN38T3dksJ0-BCDu6Ju_KQ@mail.gmail.com>
Date:   Mon, 5 Nov 2018 10:34:05 -0800
From:   John Ousterhout <ouster@...stanford.edu>
To:     netdev@...r.kernel.org
Subject: Rules for retransmitting sk_buffs?

I am creating a kernel module that implements the Homa transport
protocol (see paper in SIGCOMM 2018) and as a Linux kernel newbie I'm
struggling a bit to figure out how all of Linux's network plumbing
works.

I'm currently having problems retransmitting an sk_buff after packet
loss and hoping that perhaps someone here can help me understand the
rules and/or constraints around retransmission. Pointers to any
existing documentation would also be great.

I'm currently using the naive approach: Homa saves a reference to the
sk_buff after it is first transmitted, and if retransmission is
necessary it calls ip_queue_xmit again with the same sk_buff (it also
reuses the same flowi and dst as in the first call). The behavior I'm
seeing is very strange: the second call to ip_queue_xmit  is modifying
the flowi so that its daddr is 127.0.0.1. This then results in an
ICMP_DEST_UNREACH error.

Am I doing something fundamentally wrong here? E.g., do I need to
clone the sk_buff before retransmitting it? If so, are there any
restrictions on *when* I clone it (I'd prefer not to do this unless
retransmission is necessary, just to save work).

Thanks in advance for any advice/pointers.

-John-