netdev - Re: TPACKET_V3 timeout bug?

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 for Android: free password hash cracker in your pocket

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

Message-ID: <CAAsGZS5ir2Ha1swhdGCg7ibgYRORZykZcu089=oJ51NT4GKDuA@mail.gmail.com>
Date:   Tue, 2 May 2017 08:04:12 -0700
From:   chetan loke <loke.chetan@...il.com>
To:     Guy Harris <guy@...m.mit.edu>
Cc:     Andrew Lunn <andrew@...n.ch>,
        Sowmini Varadhan <sowmini.varadhan@...cle.com>,
        netdev <netdev@...r.kernel.org>,
        tcpdump-workers@...ts.tcpdump.org
Subject: Re: TPACKET_V3 timeout bug?

On Sat, Apr 15, 2017 at 7:41 PM, Guy Harris <guy@...m.mit.edu> wrote:
> On Apr 15, 2017, at 7:10 PM, Andrew Lunn <andrew@...n.ch> wrote:
>
>> Do you think this is a kernel problem, libpcap problem, or an
>> application problem?
>

Its clearly a kernel regression.

If you look at if_packet.h, I have explicitly called out all the cases
for the return/status codes. When I first merged the functionality in
3.11(or 3.12 I think) I had the logic in place to retire the block
with or without packets in it. I think there was one case where we
wouldn't wake up userspace. Someone checked in a fix for that. Now I
am not sure the regression happened as part of that bug fix or
sometime later. If you diff 3.12 against the latest you will find the
regression. Look for prb_retire_rx_blk_timer_expired().

> An application problem.  See my response on netdev; the timeout (which is provided by the kernel's capture mechanism, in most cases) is to make sure packets don't stay stuck in the kernel's packet buffer for an indefinite period of time, it's *not* to make sure a thread capturing packets doesn't stay blocked for an indefinite period of time.  Whether the timer goes off even if no

I cannot speak on behalf of user-space wrappers developed around
tpacket_v3 but the intention(from the kernel POV) of the block_timer
*is* to unblock the capture/user process/thread so that it does NOT
stay blocked for an indefinite period of time. The header explicitly
specifies that contract.

I'm tied up for the next 3 weeks. However I can work on it after
that(unless someone else has cycles for it now).

Chetan