lkml.org 
[lkml]   [2013]   [Jan]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: rwlock_t unfairness and tasklist_lock
From
On Wed, Jan 9, 2013 at 9:49 AM, Oleg Nesterov <oleg@redhat.com> wrote:
> On 01/08, Michel Lespinasse wrote:
>> Like others before me, I have discovered how easy it is to DOS a
>> system by abusing the rwlock_t unfairness and causing the
>> tasklist_lock read side to be continuously held
>
> Yes. Plus it has perfomance problems.
>
> It should die. We still need the global lock to protect, say,
> init_task.tasks list, but otherwise we need the per-process locking.

To be clear: I'm not trying to defend tasklist_lock here. However,
given how long this has been a known issue, I think we should consider
attacking the problem from the lock fairness perspective first and
stop waiting for an eventual tasklist_lock death.

>> - Would there be any fundamental objection to implementing a fair
>> rwlock_t and dealing with the reentrancy issues in tasklist_lock ? My
>> proposal there would be along the lines of:
>
> I don't really understand your proposal in details, but until we kill
> tasklist_lock, perhaps it makes sense to implement something simple, say,
> write-biased rwlock and add "int task_struct->tasklist_read_lock_counter"
> to avoid the read-write-read deadlock.

Right. But one complexity that has to be dealt with, is how to handle
reentrant uses of the tasklist_lock read side, when such uses come
from a different context (say, the lock was first taken in process
context and the reentrant use is in irq or softirq context).

If in process context we take the tasklist_lock read side, and *then*
increment the tasklist_read_lock_counter, there is still the
possibility of an irq coming up in before the counter is incremented.
So to deal with that, I think we have to explicitly detect the
tasklist_lock uses that are in irq/softirq context and deal with these
differently from those in process context - we would have to either
ignore the tasklist_lock write bias when in irq/softirq context, or we
could deal with it by taking a separate lock then (as in my proposal).

--
Michel "Walken" Lespinasse
A program is never fully debugged until the last user dies.


\
 
 \ /
  Last update: 2013-01-10 01:21    [W:0.088 / U:0.480 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site