* Opening of blocking FIFOs not reliable?
@ 2005-08-13 3:18 Teemu Koponen
2005-08-14 0:49 ` Alan Cox
0 siblings, 1 reply; 4+ messages in thread
From: Teemu Koponen @ 2005-08-13 3:18 UTC (permalink / raw)
To: linux-kernel
Hi,
Opening a FIFO for WR_ONLY should release a previously blocked RD_ONLY
open. I suspect this is not guaranteed on a heavily loaded Linux box.
Consider fs/fifo.c (of 2.6.13-rc6-git4) and its wait_for_partner() and
wake_up_partner() functions. I think wait_for_partner()'s while loop
never exits, *iff* the writer, after opening the FIFO, closes it before
the reader gets scheduled. Shouldn't the writer's open() block until
the reader's open() is done?
Teemu
--
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Opening of blocking FIFOs not reliable?
2005-08-13 3:18 Teemu Koponen
@ 2005-08-14 0:49 ` Alan Cox
0 siblings, 0 replies; 4+ messages in thread
From: Alan Cox @ 2005-08-14 0:49 UTC (permalink / raw)
To: Teemu Koponen; +Cc: linux-kernel
On Gwe, 2005-08-12 at 20:18 -0700, Teemu Koponen wrote:
> the reader gets scheduled. Shouldn't the writer's open() block until
> the reader's open() is done?
Not neccessarily - but you are correct that it should lead to the
readers open completing and then EOFs being returned. Do you have a test
case for the problem?
Alan
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Opening of blocking FIFOs not reliable?
@ 2005-08-14 10:15 Manfred Spraul
2005-08-14 10:40 ` Teemu Koponen
0 siblings, 1 reply; 4+ messages in thread
From: Manfred Spraul @ 2005-08-14 10:15 UTC (permalink / raw)
To: Teemu Koponen; +Cc: linux-kernel
Teemu wrote:
>Opening a FIFO for WR_ONLY should release a previously blocked RD_ONLY
>open. I suspect this is not guaranteed on a heavily loaded Linux box.
>
>
Do you have a test case?
IIRC we had that bug, and it was fixed by adding PIPE_WCOUNTER:
PIPE_WRITERS counts the number of writers. This one is decreased during
close(). PIPE_WCOUNTER counts how often a writer was seen. It's never
decreased. Readers that wait for a writer wait until PIPE_WCOUNTER
changes, they do not look at PIPE_WRITERS.
--
Manfred
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Opening of blocking FIFOs not reliable?
2005-08-14 10:15 Opening of blocking FIFOs not reliable? Manfred Spraul
@ 2005-08-14 10:40 ` Teemu Koponen
0 siblings, 0 replies; 4+ messages in thread
From: Teemu Koponen @ 2005-08-14 10:40 UTC (permalink / raw)
To: Manfred Spraul; +Cc: linux-kernel
On Aug 14, 2005, at 3:15, Manfred Spraul wrote:
>> Opening a FIFO for WR_ONLY should release a previously blocked
>> RD_ONLY open. I suspect this is not guaranteed on a heavily loaded
>> Linux box.
>>
> Do you have a test case?
> IIRC we had that bug, and it was fixed by adding PIPE_WCOUNTER:
> PIPE_WRITERS counts the number of writers. This one is decreased
> during close(). PIPE_WCOUNTER counts how often a writer was seen. It's
> never decreased. Readers that wait for a writer wait until
> PIPE_WCOUNTER changes, they do not look at PIPE_WRITERS.
Ah, I missed the semantics of WCOUNTER. True, writer's open should
always release the reader' s open (as Alan pointed out).
I do have a test application, which experienced dead-locked readers'
opens before I artificially delayed writers' closes. The application
runs on PlanetLab, which uses VServer, though. I'll try to construct
next a minimal test case based on the application and reproduce the
behavior on a vanilla box...
Teemu
--
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2005-08-14 10:40 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2005-08-14 10:15 Opening of blocking FIFOs not reliable? Manfred Spraul
2005-08-14 10:40 ` Teemu Koponen
-- strict thread matches above, loose matches on Subject: below --
2005-08-13 3:18 Teemu Koponen
2005-08-14 0:49 ` Alan Cox
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.