lkml.org 
[lkml]   [2009]   [Mar]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH] filp->f_pos not correctly updated in proc_task_readdir
From
Date
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?

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 ..
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.

Eric


\
 
 \ /
  Last update: 2009-03-17 19:15    [W:0.098 / U:2.264 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site