On 05/31, Eric W. Biederman wrote:
>
> Oleg Nesterov writes:
>
> > OK. But this means that even 1/3 is not 100% right, exactly because
> > leader can be unhashed right before first_tid() takes rcu lock. Easy
> > to fix, we should simply factor out the "nr != 0" check.
> >
> > And this also means
Oleg Nesterov writes:
> Eric, sorry for delay.
>
> On 05/29, Eric W. Biederman wrote:
>>
>> Oleg Nesterov writes:
>>
>> > Why the empty "." + ".." dir is bad if the task(s) has gone away after
>> > opendir?
>>
>> Because the definition of a deleted directory that you are in is that
>> getdents
Eric, sorry for delay.
On 05/29, Eric W. Biederman wrote:
>
> Oleg Nesterov writes:
>
> > Why the empty "." + ".." dir is bad if the task(s) has gone away after
> > opendir?
>
> Because the definition of a deleted directory that you are in is that
> getdents will return -ENOENT.
>
> You can
Eric, sorry for delay.
On 05/29, Eric W. Biederman wrote:
Oleg Nesterov o...@redhat.com writes:
Why the empty . + .. dir is bad if the task(s) has gone away after
opendir?
Because the definition of a deleted directory that you are in is that
getdents will return -ENOENT.
You can
Oleg Nesterov o...@redhat.com writes:
Eric, sorry for delay.
On 05/29, Eric W. Biederman wrote:
Oleg Nesterov o...@redhat.com writes:
Why the empty . + .. dir is bad if the task(s) has gone away after
opendir?
Because the definition of a deleted directory that you are in is that
On 05/31, Eric W. Biederman wrote:
Oleg Nesterov o...@redhat.com writes:
OK. But this means that even 1/3 is not 100% right, exactly because
leader can be unhashed right before first_tid() takes rcu lock. Easy
to fix, we should simply factor out the nr != 0 check.
And this also means
Oleg Nesterov writes:
> On 05/28, Eric W. Biederman wrote:
>>
>> Oleg Nesterov writes:
>>
>> > proc_task_readdir() does not really need "leader", first_tid()
>> > has to revalidate it anyway. Just pass proc_pid(inode) to
>> > first_tid() instead, it can do pid_task(PIDTYPE_PID) itself
>> > and
On 05/28, Eric W. Biederman wrote:
>
> Oleg Nesterov writes:
>
> > proc_task_readdir() does not really need "leader", first_tid()
> > has to revalidate it anyway. Just pass proc_pid(inode) to
> > first_tid() instead, it can do pid_task(PIDTYPE_PID) itself
> > and read ->group_leader only if
On 05/28, Eric W. Biederman wrote:
Oleg Nesterov o...@redhat.com writes:
proc_task_readdir() does not really need leader, first_tid()
has to revalidate it anyway. Just pass proc_pid(inode) to
first_tid() instead, it can do pid_task(PIDTYPE_PID) itself
and read -group_leader only if
Oleg Nesterov o...@redhat.com writes:
On 05/28, Eric W. Biederman wrote:
Oleg Nesterov o...@redhat.com writes:
proc_task_readdir() does not really need leader, first_tid()
has to revalidate it anyway. Just pass proc_pid(inode) to
first_tid() instead, it can do pid_task(PIDTYPE_PID)
Oleg Nesterov writes:
> proc_task_readdir() does not really need "leader", first_tid()
> has to revalidate it anyway. Just pass proc_pid(inode) to
> first_tid() instead, it can do pid_task(PIDTYPE_PID) itself
> and read ->group_leader only if necessary.
>
> Note: I am not sure
Oleg Nesterov o...@redhat.com writes:
proc_task_readdir() does not really need leader, first_tid()
has to revalidate it anyway. Just pass proc_pid(inode) to
first_tid() instead, it can do pid_task(PIDTYPE_PID) itself
and read -group_leader only if necessary.
Note: I am not sure
proc_task_readdir() does not really need "leader", first_tid()
has to revalidate it anyway. Just pass proc_pid(inode) to
first_tid() instead, it can do pid_task(PIDTYPE_PID) itself
and read ->group_leader only if necessary.
Note: I am not sure proc_task_readdir() really needs the initial
-ENOENT
proc_task_readdir() does not really need leader, first_tid()
has to revalidate it anyway. Just pass proc_pid(inode) to
first_tid() instead, it can do pid_task(PIDTYPE_PID) itself
and read -group_leader only if necessary.
Note: I am not sure proc_task_readdir() really needs the initial
-ENOENT
14 matches
Mail list logo
