On Sat, 2012-11-10 at 21:23 +0100, Krzysztof Mazur wrote: > With this tasklet_schedule() we implement a "spin_lock" here, but in > this case both conditions (vcc not ready and socket locked) can be > true for a long time and we can spin here for a long time.
Reading this more carefully this morning... I hadn't realised it was these conditions, and not the sock_owned_by_user(), which had triggered. Yes, perhaps we should just return zero in that case and find another wakeup trigger... if indeed a wakeup is ever required in the VF_RELEASED and VF_CLOSE case. And if we've fixed things so that !VF_READY can never happen (have we?).... perhaps this one doesn't matter at all? It was the sock_owned_by_user() case I was most interested in, and I was expecting that lock would generally be held briefly enough that the tasklet would be fine. Was that not so? -- dwmw2
smime.p7s
Description: S/MIME cryptographic signature
