From: Al Viro <viro@ZenIV.linux.org.uk>
To: Zhang Le <r0bertz@gentoo.org>
Cc: linux-kernel@vger.kernel.org, torvalds@osdl.org, alan@redhat.com
Subject: Re: [PATCH] filp->f_pos not correctly updated in proc_task_readdir
Date: Mon, 16 Mar 2009 08:34:57 +0000 [thread overview]
Message-ID: <20090316083457.GV28946@ZenIV.linux.org.uk> (raw)
In-Reply-To: <1237185871-3343-1-git-send-email-r0bertz@gentoo.org>
On Mon, Mar 16, 2009 at 02:44:31PM +0800, Zhang Le wrote:
> filp->f_pos only get updated at the end of the function. Thus d_off of those
> dirents who are in the middle will be 0, and this will cause a problem in
> glibc's readdir implementation, specifically endless loop. Because when overflow
> occurs, f_pos will be set to next dirent to read, however it will be 0, unless
> the next one is the last one. So it will start over again and again.
Eh... Here's what's really going on:
proc_..._fill_cache() API is rather kludgy and far too convoluted. In
particular, it calls filldir() and passes file->f_pos to it, expecting
the caller to update file->f_pos between the calls. proc_task_readdir()
uses that sucker, but doesn't update ->f_pos until the very end. As
the result, d_off of direntries produced by it gets screwed.
Broken-by: commit 61a28784028e6d55755e4d0f39bee8d9bf2ee8d9
Author: Eric W. Biederman <ebiederm@xmission.com>
Date: Mon Oct 2 02:18:49 2006 -0700
[PATCH] proc: Remove the hard coded inode numbers
Patch is fine, but I'd rather rip the layers of ..._fill_cache() abstractions
out and see what falls out. Anyway, for -rc your variant is definitely the
way to go.
next prev parent reply other threads:[~2009-03-16 8:35 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-03-16 6:44 [PATCH] filp->f_pos not correctly updated in proc_task_readdir Zhang Le
2009-03-16 8:34 ` Al Viro [this message]
2009-03-16 16:27 ` Zhang Le
2009-03-17 10:37 ` Alexey Dobriyan
2009-03-17 12:53 ` Zhang Le
2009-03-17 13:48 ` Alexey Dobriyan
2009-03-17 18:11 ` Al Viro
2009-03-17 18:12 ` Eric W. Biederman
2009-03-18 7:27 ` Zhang Le
2009-03-18 10:36 ` Eric W. Biederman
2009-03-18 13:39 ` [PATCH] proc: Fix proc_tid_readdir so it handles the weird cases Eric W. Biederman
2009-03-18 13:57 ` Louis Rilling
2009-03-19 3:40 ` Eric W. Biederman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20090316083457.GV28946@ZenIV.linux.org.uk \
--to=viro@zeniv.linux.org.uk \
--cc=alan@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=r0bertz@gentoo.org \
--cc=torvalds@osdl.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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.