Perhaps this is old news...but...
I can easily create a race when reading /proc//stat
(fs/proc/{base.c,array.c}) where a rapidly reading application, such as
"top", starts reading stats for a thread which goes away during the
read. This is easily reproduced with a program that rapidly forks and
Alexander Viro wrote:
>
> On Tue, 1 May 2001, Todd Inglett wrote:
>
> > Perhaps this is old news...but...
> >
> > I can easily create a race when reading /proc//stat
> > (fs/proc/{base.c,array.c}) where a rapidly reading application, such as
> > "t
Ok, I've got this isolated. Here's the sequence of events:
1. Some process T (probably "top") opens /proc/N/stat.
2. While holding tasklist_lock the proc code does a get_task_struct()
to add a ref count to the page.
3. Process N exits.
4. The parent of process N exits.
5. Process T reads fr
Andreas Ferber wrote:
>
> On Fri, May 04, 2001 at 10:46:43PM +1000, Keith Owens wrote:
>
> > For a read only case, the only important
> > thing is not to die, one occurrence of bad data is tolerable.
>
> Strong NACK. The pages where the bad data comes from may in some cases
> already be reclaim
4 matches
Mail list logo