* sys_sendfile oops in 2.6.13?
@ 2005-10-11 8:56 Grzegorz Nosek
2005-10-11 14:53 ` Jiri Slaby
` (2 more replies)
0 siblings, 3 replies; 6+ messages in thread
From: Grzegorz Nosek @ 2005-10-11 8:56 UTC (permalink / raw)
To: linux-kernel
Hi all
I found an (IMHO) silly bug in do_sendfile in 2.6.13.x kernels (at
least in 2.6.13.3 and .4, didn't backtrack to find where it
originated). Without the patch all I apparently get from sys_sendfile
is an oops due to a call in sys_sendfile with ppos being NULL. With the
patch it works OK. Noticed in vsftpd.
The patch may apply with some fuzz as my kernel is somehwat patched but
the gist of the patch is the same anyway
Regards,
Grzegorz Nosek
--- linux-2.6/fs/read_write.c~ 2005-10-06 21:35:03.000000000 +0200
+++ linux-2.6/fs/read_write.c 2005-10-05 19:14:04.000000000 +0200
@@ -719,7 +719,7 @@
current->syscr++;
current->syscw++;
- if (*ppos > max)
+ if (ppos && *ppos > max)
retval = -EOVERFLOW;
fput_out:
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: sys_sendfile oops in 2.6.13? 2005-10-11 8:56 sys_sendfile oops in 2.6.13? Grzegorz Nosek @ 2005-10-11 14:53 ` Jiri Slaby 2005-10-12 4:00 ` Andy Isaacson 2005-10-12 17:38 ` Chris Wright 2 siblings, 0 replies; 6+ messages in thread From: Jiri Slaby @ 2005-10-11 14:53 UTC (permalink / raw) To: Grzegorz Nosek; +Cc: linux-kernel Grzegorz Nosek napsal(a): >Hi all > >I found an (IMHO) silly bug in do_sendfile in 2.6.13.x kernels (at >least in 2.6.13.3 and .4, didn't backtrack to find where it >originated). Without the patch all I apparently get from sys_sendfile >is an oops due to a call in sys_sendfile with ppos being NULL. With the >patch it works OK. Noticed in vsftpd. > >The patch may apply with some fuzz as my kernel is somehwat patched but >the gist of the patch is the same anyway > >Regards, > Grzegorz Nosek > >--- linux-2.6/fs/read_write.c~ 2005-10-06 21:35:03.000000000 +0200 >+++ linux-2.6/fs/read_write.c 2005-10-05 19:14:04.000000000 +0200 >@@ -719,7 +719,7 @@ > current->syscr++; > current->syscw++; > >- if (*ppos > max) >+ if (ppos && *ppos > max) > > I don't know the code surrounding this, but shouldn't be this (!ppos || *ppos > max)? > retval = -EOVERFLOW; > > fput_out: > > -- js ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: sys_sendfile oops in 2.6.13? 2005-10-11 8:56 sys_sendfile oops in 2.6.13? Grzegorz Nosek 2005-10-11 14:53 ` Jiri Slaby @ 2005-10-12 4:00 ` Andy Isaacson 2005-10-12 9:11 ` Grzegorz Nosek 2005-10-12 17:38 ` Chris Wright 2 siblings, 1 reply; 6+ messages in thread From: Andy Isaacson @ 2005-10-12 4:00 UTC (permalink / raw) To: Grzegorz Nosek; +Cc: linux-kernel On Tue, Oct 11, 2005 at 10:56:43AM +0200, Grzegorz Nosek wrote: > I found an (IMHO) silly bug in do_sendfile in 2.6.13.x kernels (at > least in 2.6.13.3 and .4, didn't backtrack to find where it > originated). Without the patch all I apparently get from sys_sendfile > is an oops due to a call in sys_sendfile with ppos being NULL. With the > patch it works OK. Noticed in vsftpd. > > @@ -719,7 +719,7 @@ > current->syscr++; > current->syscw++; > > - if (*ppos > max) > + if (ppos && *ppos > max) That change can't fix a bug in 2.6.13, because ppos is forced to be non-null further up the file: 622 static ssize_t do_sendfile(int out_fd, int in_fd, loff_t *ppos, ... 647 if (!ppos) 648 ppos = &in_file->f_pos; ... 684 pos = *ppos; ... 701 current->syscr++; 702 current->syscw++; 703 704 if (*ppos > max) 705 retval = -EOVERFLOW; (line numbers from 2.6.13.) So there must be something else at work. Perhaps your patches? On Tue, Oct 11, 2005 at 04:53:47PM +0200, Jiri Slaby wrote: > I don't know the code surrounding this, but shouldn't be this > (!ppos || *ppos > max)? That would be wrong, too; if it were valid to call in with ppos==0, you wouldn't want to return EOVERFLOW; and if ppos==0 were not valid and you wanted to return an error, EOVERFLOW would be the wrong error to return. -andy ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: sys_sendfile oops in 2.6.13? 2005-10-12 4:00 ` Andy Isaacson @ 2005-10-12 9:11 ` Grzegorz Nosek 0 siblings, 0 replies; 6+ messages in thread From: Grzegorz Nosek @ 2005-10-12 9:11 UTC (permalink / raw) To: Andy Isaacson; +Cc: linux-kernel 2005/10/12, Andy Isaacson <adi@hexapodia.org>: > On Tue, Oct 11, 2005 at 10:56:43AM +0200, Grzegorz Nosek wrote: > > I found an (IMHO) silly bug in do_sendfile in 2.6.13.x kernels (at > > least in 2.6.13.3 and .4, didn't backtrack to find where it > > originated). Without the patch all I apparently get from sys_sendfile > > is an oops due to a call in sys_sendfile with ppos being NULL. With the > > patch it works OK. Noticed in vsftpd. > > > > @@ -719,7 +719,7 @@ > > current->syscr++; > > current->syscw++; > > > > - if (*ppos > max) > > + if (ppos && *ppos > max) > > That change can't fix a bug in 2.6.13, because ppos is forced to be > non-null further up the file: > > 622 static ssize_t do_sendfile(int out_fd, int in_fd, loff_t *ppos, > ... > 647 if (!ppos) > 648 ppos = &in_file->f_pos; > ... > 684 pos = *ppos; > ... > 701 current->syscr++; > 702 current->syscw++; > 703 > 704 if (*ppos > max) > 705 retval = -EOVERFLOW; > > (line numbers from 2.6.13.) > > So there must be something else at work. Perhaps your patches? > > On Tue, Oct 11, 2005 at 04:53:47PM +0200, Jiri Slaby wrote: > > I don't know the code surrounding this, but shouldn't be this > > (!ppos || *ppos > max)? > > That would be wrong, too; if it were valid to call in with ppos==0, you > wouldn't want to return EOVERFLOW; and if ppos==0 were not valid and you > wanted to return an error, EOVERFLOW would be the wrong error to return. > > -andy > OK so I must have a broken kernel tree then. The lines you mention in my version belong to vfs_sendfile function which indeed ensures ppos is a valid pointer but do_sendfile is called from sys_sendfile(64). I'll find the patch that did the change (some must have, obviously) and report it there (probably linux-vserver is to blame) This section of the file in vanilla 2.6.13.4 looks nothing like in my file and the 2.6.13.3 and 2.6.13.4 patches have no changes there so at least that's cleared up. Regards, Greg ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: sys_sendfile oops in 2.6.13? 2005-10-11 8:56 sys_sendfile oops in 2.6.13? Grzegorz Nosek 2005-10-11 14:53 ` Jiri Slaby 2005-10-12 4:00 ` Andy Isaacson @ 2005-10-12 17:38 ` Chris Wright 2005-10-12 20:06 ` Grzegorz Nosek 2 siblings, 1 reply; 6+ messages in thread From: Chris Wright @ 2005-10-12 17:38 UTC (permalink / raw) To: Grzegorz Nosek; +Cc: linux-kernel * Grzegorz Nosek (grzegorz.nosek@gmail.com) wrote: > --- linux-2.6/fs/read_write.c~ 2005-10-06 21:35:03.000000000 +0200 > +++ linux-2.6/fs/read_write.c 2005-10-05 19:14:04.000000000 +0200 > @@ -719,7 +719,7 @@ > current->syscr++; > current->syscw++; > > - if (*ppos > max) > + if (ppos && *ppos > max) > retval = -EOVERFLOW; This doesn't make sense. ppos must not be NULL. Code looks like this: if (!ppos) ppos = &in_file->f_pos; ... pos = *ppos; ... if (*ppos > max) So it can't be NULL, and if somehow it were, the oops would've already happened. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: sys_sendfile oops in 2.6.13? 2005-10-12 17:38 ` Chris Wright @ 2005-10-12 20:06 ` Grzegorz Nosek 0 siblings, 0 replies; 6+ messages in thread From: Grzegorz Nosek @ 2005-10-12 20:06 UTC (permalink / raw) To: Chris Wright; +Cc: linux-kernel 2005/10/12, Chris Wright <chrisw@osdl.org>: > * Grzegorz Nosek (grzegorz.nosek@gmail.com) wrote: > > --- linux-2.6/fs/read_write.c~ 2005-10-06 21:35:03.000000000 +0200 > > +++ linux-2.6/fs/read_write.c 2005-10-05 19:14:04.000000000 +0200 > > @@ -719,7 +719,7 @@ > > current->syscr++; > > current->syscw++; > > > > - if (*ppos > max) > > + if (ppos && *ppos > max) > > retval = -EOVERFLOW; > > This doesn't make sense. ppos must not be NULL. > > Code looks like this: > > if (!ppos) > ppos = &in_file->f_pos; > ... > pos = *ppos; > ... > if (*ppos > max) > > So it can't be NULL, and if somehow it were, the oops would've already > happened. > Yeah, I know. It turned out to be a 3rd-party patch (vserver probably). My read_write.c looks very different and somehow I overlooked that while checking with vanilla 2.6.13.3. Sorry for the confusion. Regards, Greg ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2005-10-12 22:13 UTC | newest] Thread overview: 6+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2005-10-11 8:56 sys_sendfile oops in 2.6.13? Grzegorz Nosek 2005-10-11 14:53 ` Jiri Slaby 2005-10-12 4:00 ` Andy Isaacson 2005-10-12 9:11 ` Grzegorz Nosek 2005-10-12 17:38 ` Chris Wright 2005-10-12 20:06 ` Grzegorz Nosek
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.