On Sat, Jan 12, 2013 at 9:31 AM, Oleg Nesterov wrote:
> On 01/09, Michel Lespinasse wrote:
>> >> - 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:
>> >
>>
On Sat, Jan 12, 2013 at 9:31 AM, Oleg Nesterov o...@redhat.com wrote:
On 01/09, Michel Lespinasse wrote:
- 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
On 01/11, Michel Lespinasse wrote:
>
> So I looked again at getpriority() since that's what I had used for my
> DOS test code, and it looks like everything there is already protected
> by RCU or smaller granularity locks and refcounts. Patch attached to
> remove this tasklist_lock usage.
And
On 01/09, Michel Lespinasse wrote:
>
> On Wed, Jan 9, 2013 at 9:49 AM, Oleg Nesterov 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
On 01/09, Michel Lespinasse wrote:
On Wed, Jan 9, 2013 at 9:49 AM, Oleg Nesterov o...@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
On 01/11, Michel Lespinasse wrote:
So I looked again at getpriority() since that's what I had used for my
DOS test code, and it looks like everything there is already protected
by RCU or smaller granularity locks and refcounts. Patch attached to
remove this tasklist_lock usage.
And probably
On Fri, Jan 11, 2013 at 03:34:41PM +0100, Thomas Gleixner wrote:
> On Tue, 8 Jan 2013, Michel Lespinasse wrote:
> > - Does anyone know of any current work towards removing the
> > tasklist_lock use of rwlock_t ? Thomas Gleixner mentioned 3 years ago
> > that he'd give it a shot
On Tue, 8 Jan 2013, Michel Lespinasse wrote:
> - Does anyone know of any current work towards removing the
> tasklist_lock use of rwlock_t ? Thomas Gleixner mentioned 3 years ago
> that he'd give it a shot (https://lwn.net/Articles/364601/), did he
> encounter some unforeseen difficulty that we
On Tue, 8 Jan 2013, Michel Lespinasse wrote:
- Does anyone know of any current work towards removing the
tasklist_lock use of rwlock_t ? Thomas Gleixner mentioned 3 years ago
that he'd give it a shot (https://lwn.net/Articles/364601/), did he
encounter some unforeseen difficulty that we should
On Fri, Jan 11, 2013 at 03:34:41PM +0100, Thomas Gleixner wrote:
On Tue, 8 Jan 2013, Michel Lespinasse wrote:
- Does anyone know of any current work towards removing the
tasklist_lock use of rwlock_t ? Thomas Gleixner mentioned 3 years ago
that he'd give it a shot
On Wed, Jan 9, 2013 at 9:49 AM, Oleg Nesterov 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
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
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
On Wed, Jan 9, 2013 at 9:49 AM, Oleg Nesterov o...@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
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 (my abuse code makes
use of the getpriority syscall, but there are plenty of other ways
anyway).
My understanding is that the
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 (my abuse code makes
use of the getpriority syscall, but there are plenty of other ways
anyway).
My understanding is that the
16 matches
Mail list logo
