commit f0c3b5093addc8bfe9fe3a5b01acb7ec7969eafa
"[readdir] convert procfs" introduced a bug on the listing of the proc
file-system.
The return value of proc_readdir() isn't tested anymore in the
proc_root_readdir function.
This lead to an "interesting" behaviour when we are using the getdents()
system call with a buffer too small:
Instead of failing, it returns the first entries of /proc (enough to
fill the given buffer), plus the PID directories.
This is not triggered on glibc (as getdents is called with a 32KB
buffer), but on uclibc, the buffer size is only 1KB, thus some proc
entries are missing.
(described more in details here: https://lkml.org/lkml/2013/8/12/288 )
Signed-off-by: Richard Genoud <[email protected]>
---
[added Linus Torvalds and Andrew Morton in CC since Al Viro seems to be
on holidays and it's starting to getting late in the -rc cycles]
fs/proc/root.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/fs/proc/root.c b/fs/proc/root.c
index 229e366..e0a790d 100644
--- a/fs/proc/root.c
+++ b/fs/proc/root.c
@@ -205,7 +205,9 @@ static struct dentry *proc_root_lookup(struct inode * dir, struct dentry * dentr
static int proc_root_readdir(struct file *file, struct dir_context *ctx)
{
if (ctx->pos < FIRST_PROCESS_ENTRY) {
- proc_readdir(file, ctx);
+ int error = proc_readdir(file, ctx);
+ if (unlikely(error <= 0))
+ return error;
ctx->pos = FIRST_PROCESS_ENTRY;
}
--
1.7.10.4
On Mon, Aug 19, 2013 at 12:30 PM, Richard Genoud
<[email protected]> wrote:
>
> commit f0c3b5093addc8bfe9fe3a5b01acb7ec7969eafa
> "[readdir] convert procfs" introduced a bug on the listing of the proc
> file-system.
> The return value of proc_readdir() isn't tested anymore in the
> proc_root_readdir function.
>
> This lead to an "interesting" behaviour when we are using the getdents()
> system call with a buffer too small:
> Instead of failing, it returns the first entries of /proc (enough to
> fill the given buffer), plus the PID directories.
>
> This is not triggered on glibc (as getdents is called with a 32KB
> buffer), but on uclibc, the buffer size is only 1KB, thus some proc
> entries are missing.
> (described more in details here: https://lkml.org/lkml/2013/8/12/288 )
>
> Signed-off-by: Richard Genoud <[email protected]>
> ---
> [added Linus Torvalds and Andrew Morton in CC since Al Viro seems to be
> on holidays and it's starting to getting late in the -rc cycles]
>
> fs/proc/root.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/fs/proc/root.c b/fs/proc/root.c
> index 229e366..e0a790d 100644
> --- a/fs/proc/root.c
> +++ b/fs/proc/root.c
> @@ -205,7 +205,9 @@ static struct dentry *proc_root_lookup(struct inode * dir, struct dentry * dentr
> static int proc_root_readdir(struct file *file, struct dir_context *ctx)
> {
> if (ctx->pos < FIRST_PROCESS_ENTRY) {
> - proc_readdir(file, ctx);
> + int error = proc_readdir(file, ctx);
> + if (unlikely(error <= 0))
> + return error;
> ctx->pos = FIRST_PROCESS_ENTRY;
> }
By my reading that commit (f0c3b5093add) also made proc_readdir always
return 0, so with this patch the effect I see is that no pid entries
are listed under /proc, breaking ps for instance. I don't see how
even the previous version of proc_readdir could return a negative
value; looks like 1 and 0 were the only possible return values.
Marc
On Mon, Aug 19, 2013 at 1:33 PM, Marc Dionne <[email protected]> wrote:
>
> By my reading that commit (f0c3b5093add) also made proc_readdir always
> return 0, so with this patch the effect I see is that no pid entries
> are listed under /proc, breaking ps for instance. I don't see how
> even the previous version of proc_readdir could return a negative
> value; looks like 1 and 0 were the only possible return values.
Yes, see the other thread. The "return 1" case had gotten lost. I
think current git should get everything right, but please do test. I
did some testing of my own with a random little getdents test-program
(just checking that it got the same results with different (small)
buffer sizes), but it was by no means exhaustive.
Linus
On Mon, Aug 19, 2013 at 7:49 PM, Linus Torvalds
<[email protected]> wrote:
> On Mon, Aug 19, 2013 at 1:33 PM, Marc Dionne <[email protected]> wrote:
>>
>> By my reading that commit (f0c3b5093add) also made proc_readdir always
>> return 0, so with this patch the effect I see is that no pid entries
>> are listed under /proc, breaking ps for instance. I don't see how
>> even the previous version of proc_readdir could return a negative
>> value; looks like 1 and 0 were the only possible return values.
>
> Yes, see the other thread. The "return 1" case had gotten lost. I
> think current git should get everything right, but please do test. I
> did some testing of my own with a random little getdents test-program
> (just checking that it got the same results with different (small)
> buffer sizes), but it was by no means exhaustive.
>
> Linus
It does fix the symptoms I was seeing, thanks. "ps" now has output
and the pid entries are now visible again under /proc.
Marc
2013/8/20 Marc Dionne <[email protected]>:
> On Mon, Aug 19, 2013 at 7:49 PM, Linus Torvalds
> <[email protected]> wrote:
>> On Mon, Aug 19, 2013 at 1:33 PM, Marc Dionne <[email protected]> wrote:
>>>
>>> By my reading that commit (f0c3b5093add) also made proc_readdir always
>>> return 0, so with this patch the effect I see is that no pid entries
>>> are listed under /proc, breaking ps for instance. I don't see how
>>> even the previous version of proc_readdir could return a negative
>>> value; looks like 1 and 0 were the only possible return values.
>>
>> Yes, see the other thread. The "return 1" case had gotten lost. I
>> think current git should get everything right, but please do test. I
>> did some testing of my own with a random little getdents test-program
>> (just checking that it got the same results with different (small)
>> buffer sizes), but it was by no means exhaustive.
>>
>> Linus
>
> It does fix the symptoms I was seeing, thanks. "ps" now has output
> and the pid entries are now visible again under /proc.
>
> Marc
arg !
I was so focused on getting the non-PID proc entries right that I
didn't even see all the missing PIDs when I tested it !
/me need holidays.
On Mon, Aug 19, 2013 at 6:30 PM, Richard Genoud
<[email protected]> wrote:
> This is not triggered on glibc (as getdents is called with a 32KB
> buffer), but on uclibc, the buffer size is only 1KB, thus some proc
> entries are missing.
JFYI, on glibc 2.3.6.ds1-13 it's also 1 KiB.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds