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-next>] [day] [month] [year] [list]
Date:	Sat, 14 Oct 2006 14:43:28 -0700 (PDT)
From:	Joan Raventos <jraventos@...oo.com>
To:	linux-kernel@...r.kernel.org
Subject: poll problem with PF_PACKET when using PACKET_RX_RING

Hello,

In order to use PF_PACKET/SOCK_RAW with PACKET_RX_RING
one would possibly do (as described in
Documentation/networking/packet_mmap.txt):
1. setup PF_PACKET socket via socket call.
2. use setsockopt to change the PF_PACKET socket into
PACKET_RX_RING mode and alloc the ring.
3. mmap the ring.
4. use poll with the socket descriptor and then
directly access the pkts from the mmaped ring.

However I've observed that if the socket is opened on
a link with substantial traffic, chances are that some
pkts might hit the socket between (1) and (2). At that
point those pkts will make the socket descriptor be
active (packet_poll is built as an OR from
datagram_poll -essentially whether sk_receive_queue is
empty- and the ring status). However after (2) pkts
are no longer processed by packet_rcv but via
tpacket_rcv, and thus no longer queued in the
sk_receive_queue but into the ring. Moreover since the
user-space app is likely to access them directly (4),
no one is going to empty the socket queue and the
descriptor will remain always active, converting the
poll loop into a busy wait (100% cpu occupied by the
user-space process, etc.).

Is this a bug in PF_PACKET? Should the socket queue be
emptied by packet_set_ring (called via setsockopt when
PACKET_RX_RING is used) so the above cannot happen?
Should the user-space app drain the socket queue with
recvfrom prior to (4) -quite unlikely in practice-?

Thx in advance for your comments!

Salu2,
J.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ