lkml.org 
[lkml]   [2009]   [Mar]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] filp->f_pos not correctly updated in proc_task_readdir
On 11:12 Tue 17 Mar     , Eric W. Biederman wrote:
> Zhang Le <r0bertz@gentoo.org> writes:
>
> > 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.
> >
> > There is a sample program in man 2 gendents. This is the output of the program
> > running on a multithread program's task dir before this patch is applied:
> >
> > $ ./a.out /proc/3807/task
> > --------------- nread=128 ---------------
> > i-node# file type d_reclen d_off d_name
> > 506442 directory 16 1 .
> > 506441 directory 16 0 ..
> > 506443 directory 16 0 3807
> > 506444 directory 16 0 3809
> > 506445 directory 16 0 3812
> > 506446 directory 16 0 3861
> > 506447 directory 16 0 3862
> > 506448 directory 16 8 3863
> >
> > This is the output after this patch is applied
> >
> > $ ./a.out /proc/3807/task
> > --------------- nread=128 ---------------
> > i-node# file type d_reclen d_off d_name
> > 506442 directory 16 1 .
> > 506441 directory 16 2 ..
> > 506443 directory 16 3 3807
> > 506444 directory 16 4 3809
> > 506445 directory 16 5 3812
> > 506446 directory 16 6 3861
> > 506447 directory 16 7 3862
> > 506448 directory 16 8 3863
>
> I'm trying to understand what the problem that glibc
> runs into. Is this the glibc seekdir madness?
>
> Under which conditions have you seen this problem?

Please see my explanation at the bottom.

>
> The reason I ask is if this is triggered by seekdir and people really
> care then the current proc_task_readdir for the /proc/<pid>/task/
> directories is not quite sufficient. As threads come and go the d_off
> associated with a specific thread will change.
>
> Which means we probably should be returning:
>
> $ ./a.out /proc/3807/task
> --------------- nread=128 ---------------
> i-node# file type d_reclen d_off d_name
> 506442 directory 16 1 .
> 506441 directory 16 2 ..

Without my patch here, d_off will be 0. And so will be the following d_off
except the last one.

> 506443 directory 16 3809 3807
> 506444 directory 16 3811 3809
> 506445 directory 16 3814 3812
> 506446 directory 16 3863 3861
> 506447 directory 16 3864 3862
> 506448 directory 16 3865 3863
>
> Which is slightly better unfortunately it doesn't give us the
> guarantee that the d_off will be continually increasing.

Unfortunately, unlike directories on normal filesystem, there will never be any
other files in /proc/xxxx/task. So, to my understanding, d_off should be
increasing continuously, no?

OK, here is what is going on in glibc. I left it out intentionally so as not to
make the discuss unnecessarily complicated. So here it is:

First of all, we can see that the d_off does not get correctly updated.

Then, let's take a look at glibc's __GETDENTS function. In this function, there
are 3 implementations:
http://sources.redhat.com/git/gitweb.cgi?p=glibc.git;a=blob;f=sysdeps/unix/sysv/linux/getdents.c;h=b33d1789adff11a04cbb1f6f5616bc8eed59418f;hb=cvs/master
Two of them will detect overflow, and lseek if necessary.

This means, although d_off in /proc/xxxx/task does not get updated correctly
everywhere, the problem of endless loop only occurs on certain platforms.
One of them is MIPS N32 ABI system.

Of course, there are other ways to work around this. However, to me, fixing this
would be the easiest and the most straight forward one. :)

Zhang, Le
http://zhangle.is-a-geek.org


\
 
 \ /
  Last update: 2009-03-18 08:31    [W:0.080 / U:0.044 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site