From: Andi K. <ak...@su...> - 2002-01-25 15:06:47
|
Hallo, I've fixed the 2.4 networking EFAULT regressions shown by the recv/recvmsg/recvfrom tests. The only remaining FAIL there is IMHO a bug in LTP. -1 is clearly an invalid recv buffer, which should be EFAULT, not ENOTSOCK. Here is a patch. -Andi --- testcases/kernel/syscalls/recvmsg/recvmsg01.c-o Thu Sep 13 18:31:17 2001 +++ testcases/kernel/syscalls/recvmsg/recvmsg01.c Tue Jan 22 21:16:06 2002 @@ -108,7 +108,7 @@ 0, ENOTSOCK, setup1, cleanup1, "invalid socket length" }, { PF_INET, SOCK_STREAM, 0, iov, 1, (void *)-1, sizeof(buf), &msgdat, 0, (struct sockaddr *)&from, sizeof(from), - 0, ENOTSOCK, setup1, cleanup1, "invalid recv buffer" }, + -1, EFAULT, setup1, cleanup1, "invalid recv buffer" }, { PF_INET, SOCK_STREAM, 0, 0, 1, (void *)buf, sizeof(buf), &msgdat, 0, (struct sockaddr *)&from, sizeof(from), -1, EFAULT, setup1, cleanup1, "invalid iovec buffer" }, |
From: Paul L. <pl...@au...> - 2002-01-25 15:18:26
|
On Fri, 25 Jan 2002, Andi Kleen wrote: > > Hallo, > > I've fixed the 2.4 networking EFAULT regressions shown by the > recv/recvmsg/recvfrom tests. > > The only remaining FAIL there is IMHO a bug in LTP. -1 is clearly an > invalid recv buffer, which should be EFAULT, not ENOTSOCK. > Here is a patch. Ahh, looks like maybe a cut and paste went on here. Odd though that these tests pass sometimes without this patch. IIRC, these tests don't fail all the the time, but when they do fail, the reason is that the system call returned 0 instead of -1. Certainly passing a -1 to these should return an error, not 0. -Paul Larson |
From: Andi K. <ak...@su...> - 2002-01-25 15:31:22
|
On Fri, Jan 25, 2002 at 08:57:42AM -0600, Paul Larson wrote: > On Fri, 25 Jan 2002, Andi Kleen wrote: > > > > > Hallo, > > > > I've fixed the 2.4 networking EFAULT regressions shown by the > > recv/recvmsg/recvfrom tests. > > > > The only remaining FAIL there is IMHO a bug in LTP. -1 is clearly an > > invalid recv buffer, which should be EFAULT, not ENOTSOCK. > > Here is a patch. > Ahh, looks like maybe a cut and paste went on here. Odd though that these > tests pass sometimes without this patch. IIRC, these tests don't fail all > the the time, but when they do fail, the reason is that the system call > returned 0 instead of -1. Certainly passing a -1 to these should return > an error, not 0. They pass sometimes because the EFAULT return of normal 2.4 (without my changes) is timing dependent. There is a fast path that sometimes forgets them and a slower path that handles them reliably. When you take too long to call recvmsg the slow path is always triggered by a timer. Now the fast path should report EFAULT reliably too. BTW the code also had some other interesting bugs like returning EFAULT as a pending socket error (this means it was possible when you have two processes/threads accessing the same socket using poll() they could see each other's EFAULT. Hopefully fixed now) -Andi |
From: Paul L. <pl...@au...> - 2002-01-25 15:35:48
|
On Fri, 25 Jan 2002, Andi Kleen wrote: > On Fri, Jan 25, 2002 at 08:57:42AM -0600, Paul Larson wrote: > > On Fri, 25 Jan 2002, Andi Kleen wrote: > > > > > > > > Hallo, > > > > > > I've fixed the 2.4 networking EFAULT regressions shown by the > > > recv/recvmsg/recvfrom tests. > > > > > > The only remaining FAIL there is IMHO a bug in LTP. -1 is clearly an > > > invalid recv buffer, which should be EFAULT, not ENOTSOCK. > > > Here is a patch. > > Ahh, looks like maybe a cut and paste went on here. Odd though that these > > tests pass sometimes without this patch. IIRC, these tests don't fail all > > the the time, but when they do fail, the reason is that the system call > > returned 0 instead of -1. Certainly passing a -1 to these should return > > an error, not 0. > > They pass sometimes because the EFAULT return of normal 2.4 (without my > changes) is timing dependent. There is a fast path that sometimes forgets > them and a slower path that handles them reliably. When you take too long > to call recvmsg the slow path is always triggered by a timer. Now the fast > path should report EFAULT reliably too. > > BTW the code also had some other interesting bugs like returning EFAULT > as a pending socket error (this means it was possible when you have two > processes/threads accessing the same socket using poll() they could see > each other's EFAULT. Hopefully fixed now) I havn't really had time to give this the attention it deserves yet, but I did try your patch. Recv, and recvfrom tests still fail with it, and recvmsg fails where it did not before. I'll try to take a look at this some more later today. Thanks, Paul Larson |
From: Andi K. <ak...@su...> - 2002-01-25 15:37:18
|
On Fri, Jan 25, 2002 at 09:15:08AM -0600, Paul Larson wrote: > I havn't really had time to give this the attention it deserves yet, but I > did try your patch. Recv, and recvfrom tests still fail with it, and > recvmsg fails where it did not before. I'll try to take a look at this > some more later today. They fail because you also need a patched kernel. It'll take some time before the fixes appear in 2.4, but hopefully soon in 2.5. -Andi |
From: Paul L. <pl...@au...> - 2002-01-25 15:41:51
|
On Fri, 25 Jan 2002, Andi Kleen wrote: > On Fri, Jan 25, 2002 at 09:15:08AM -0600, Paul Larson wrote: > > I havn't really had time to give this the attention it deserves yet, but I > > did try your patch. Recv, and recvfrom tests still fail with it, and > > recvmsg fails where it did not before. I'll try to take a look at this > > some more later today. > > They fail because you also need a patched kernel. It'll take some time > before the fixes appear in 2.4, but hopefully soon in 2.5. Ahh, now that makes more sense. Do you know where I can get this patch? Thanks, Paul Larson |