Date: Wed, 16 Oct 2002 17:54:09 -0700 (PDT) From: Kelly Yancey <kelly@nttmcl.com> To: net@freebsd.org Subject: Patch for review: only report protocol data via EVFILT_READ filter Message-ID: <20021016172902.E11940-200000@alicia.nttmcl.com>
next in thread | raw e-mail | index | archive | help
This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.
Send mail to mime@docserver.cac.washington.edu for more info.
--0-756964737-1034816049=:11940
Content-Type: TEXT/PLAIN; charset=US-ASCII
Currently, the value returned in a kevent's data member by the
EVFILT_READ filter is "number of bytes in the socket buffer" which
includes control and out-of-band data. However, this isn't particularly
useful as any read(), readv(), or readmsg() for the amount of data
reported may block if there is any non-protocol data in the buffer. And
being that there is no way for userland applications to determine if, and
if so how much, non-protocol data is in the buffer, the reported value
cannot be trusted for anything useful.
PR 30634 touches on this issue; UDP sockets are particularly visible
examples since they always include 16 bytes of address information in
addition to the datagram received. However, from reading the code it
would appear that OOB data can cause a similar problem for TCP sockets.
It seems that the overriding issue is that the read* API takes the
number of bytes of protocol data to read whereas kevent() reports the
total number of bytes available (protocol or administrative). The
attached patch, which I would appreciate your comments on, modifies
kevent() to report just the number of bytes of protocol data.
As an aside, it appears that the FIONREAD ioctl (sys_socket.c:soo_ioctl)
and stat(2) on a socket (sys_socket.c:soo_stat) also return the total
number of bytes (protocol data other otherwise) in the socket buffer.
For similar reasons as described above, I suspect that these should be
also modified to return just the number of bytes of actual data. Unless
someone knows of an explicit example otherwise, I don't think changing the
value reported via these interfaces would break any existing applications
as they are probably expecting the new behaviour anyway.
Thanks,
Kelly
(P.S. I've already sent a version of this patch, made against -stable,
to Jonathan, but I haven't heard anything from him in almost a week)
--
Kelly Yancey -- kbyanc@{posi.net,FreeBSD.org}
--0-756964737-1034816049=:11940
Content-Type: TEXT/PLAIN; charset=US-ASCII; name="fix-pr30634.diff"
Content-Transfer-Encoding: BASE64
Content-ID: <20021016175409.M11940@alicia.nttmcl.com>
Content-Description:
Content-Disposition: attachment; filename="fix-pr30634.diff"
SW5kZXg6IHN5cy9zb2NrZXR2YXIuaA0KPT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PQ0KUkNTIGZpbGU6IC9ob21lL25jdnMvc3JjL3N5cy9zeXMvc29ja2V0dmFy
Lmgsdg0KcmV0cmlldmluZyByZXZpc2lvbiAxLjk0DQpkaWZmIC11IC1wIC1y
MS45NCBzb2NrZXR2YXIuaA0KLS0tIHN5cy9zb2NrZXR2YXIuaAkxNyBBdWcg
MjAwMiAwMjozNjoxNiAtMDAwMAkxLjk0DQorKysgc3lzL3NvY2tldHZhci5o
CTE2IE9jdCAyMDAyIDIxOjM0OjEzIC0wMDAwDQpAQCAtMTA1LDYgKzEwNSw3
IEBAIHN0cnVjdCBzb2NrZXQgew0KIAkJdV9pbnQJc2JfaGl3YXQ7CS8qIG1h
eCBhY3R1YWwgY2hhciBjb3VudCAqLw0KIAkJdV9pbnQJc2JfbWJjbnQ7CS8q
IGNoYXJzIG9mIG1idWZzIHVzZWQgKi8NCiAJCXVfaW50CXNiX21ibWF4Owkv
KiBtYXggY2hhcnMgb2YgbWJ1ZnMgdG8gdXNlICovDQorCQl1X2ludAlzYl9j
dGw7CQkvKiBub24tZGF0YSBjaGFycyBpbiBidWZmZXIgKi8NCiAJCWludAlz
Yl9sb3dhdDsJLyogbG93IHdhdGVyIG1hcmsgKi8NCiAJCWludAlzYl90aW1l
bzsJLyogdGltZW91dCBmb3IgcmVhZC93cml0ZSAqLw0KIAkJc2hvcnQJc2Jf
ZmxhZ3M7CS8qIGZsYWdzLCBzZWUgYmVsb3cgKi8NCkBAIC0yMjcsNiArMjI4
LDggQEAgc3RydWN0IHhzb2NrZXQgew0KIC8qIGFkanVzdCBjb3VudGVycyBp
biBzYiByZWZsZWN0aW5nIGFsbG9jYXRpb24gb2YgbSAqLw0KICNkZWZpbmUJ
c2JhbGxvYyhzYiwgbSkgeyBcDQogCShzYiktPnNiX2NjICs9IChtKS0+bV9s
ZW47IFwNCisJaWYgKChtKS0+bV90eXBlICE9IE1UX0RBVEEpIFwNCisJCShz
YiktPnNiX2N0bCArPSAobSktPm1fbGVuOyBcDQogCShzYiktPnNiX21iY250
ICs9IE1TSVpFOyBcDQogCWlmICgobSktPm1fZmxhZ3MgJiBNX0VYVCkgXA0K
IAkJKHNiKS0+c2JfbWJjbnQgKz0gKG0pLT5tX2V4dC5leHRfc2l6ZTsgXA0K
QEAgLTIzNSw2ICsyMzgsOCBAQCBzdHJ1Y3QgeHNvY2tldCB7DQogLyogYWRq
dXN0IGNvdW50ZXJzIGluIHNiIHJlZmxlY3RpbmcgZnJlZWluZyBvZiBtICov
DQogI2RlZmluZQlzYmZyZWUoc2IsIG0pIHsgXA0KIAkoc2IpLT5zYl9jYyAt
PSAobSktPm1fbGVuOyBcDQorCWlmICgobSktPm1fdHlwZSAhPSBNVF9EQVRB
KSBcDQorCQkoc2IpLT5zYl9jdGwgLT0gKG0pLT5tX2xlbjsgXA0KIAkoc2Ip
LT5zYl9tYmNudCAtPSBNU0laRTsgXA0KIAlpZiAoKG0pLT5tX2ZsYWdzICYg
TV9FWFQpIFwNCiAJCShzYiktPnNiX21iY250IC09IChtKS0+bV9leHQuZXh0
X3NpemU7IFwNCkluZGV4OiBrZXJuL3VpcGNfc29ja2V0LmMNCj09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT0NClJDUyBmaWxlOiAvaG9tZS9uY3ZzL3NyYy9zeXMv
a2Vybi91aXBjX3NvY2tldC5jLHYNCnJldHJpZXZpbmcgcmV2aXNpb24gMS4x
MzINCmRpZmYgLXUgLXAgLXIxLjEzMiB1aXBjX3NvY2tldC5jDQotLS0ga2Vy
bi91aXBjX3NvY2tldC5jCTUgT2N0IDIwMDIgMjE6MjM6NDYgLTAwMDAJMS4x
MzINCisrKyBrZXJuL3VpcGNfc29ja2V0LmMJMTYgT2N0IDIwMDIgMjE6MzI6
MDEgLTAwMDANCkBAIC0xNzg1LDYgKzE3ODUsNyBAQCBmaWx0X3NvcmVhZChz
dHJ1Y3Qga25vdGUgKmtuLCBsb25nIGhpbnQpDQogCXN0cnVjdCBzb2NrZXQg
KnNvID0gKHN0cnVjdCBzb2NrZXQgKilrbi0+a25fZnAtPmZfZGF0YTsNCiAN
CiAJa24tPmtuX2RhdGEgPSBzby0+c29fcmN2LnNiX2NjOw0KKwlrbi0+a25f
ZGF0YSAtPSBzby0+c29fcmN2LnNiX2N0bDsNCiAJaWYgKHNvLT5zb19zdGF0
ZSAmIFNTX0NBTlRSQ1ZNT1JFKSB7DQogCQlrbi0+a25fZmxhZ3MgfD0gRVZf
RU9GOw0KIAkJa24tPmtuX2ZmbGFncyA9IHNvLT5zb19lcnJvcjsNCg==
--0-756964737-1034816049=:11940--
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20021016172902.E11940-200000>