On 02/06/2015 12:18 PM, Raghavendra K T wrote:
On 02/06/2015 04:27 AM, Linus Torvalds wrote:
On Thu, Feb 5, 2015 at 2:37 PM, Davidlohr Bueso
wrote:
It is possible that the paravirt spinlocks could be saved by:
- moving the clearing of TICKET_SLOWPATH_FLAG into the fastpath
locking code.
On 02/06/2015 04:07 AM, Davidlohr Bueso wrote:
On Thu, 2015-02-05 at 13:34 -0800, Linus Torvalds wrote:
On Thu, Feb 5, 2015 at 1:02 PM, Sasha Levin wrote:
Interestingly enough, according to that article this behaviour seems to be
"by design":
Oh, it's definitely by design, it's just that
On 02/06/2015 04:07 AM, Davidlohr Bueso wrote:
On Thu, 2015-02-05 at 13:34 -0800, Linus Torvalds wrote:
On Thu, Feb 5, 2015 at 1:02 PM, Sasha Levin sasha.le...@oracle.com wrote:
Interestingly enough, according to that article this behaviour seems to be
by design:
Oh, it's definitely by
On 02/06/2015 12:18 PM, Raghavendra K T wrote:
On 02/06/2015 04:27 AM, Linus Torvalds wrote:
On Thu, Feb 5, 2015 at 2:37 PM, Davidlohr Bueso d...@stgolabs.net
wrote:
It is possible that the paravirt spinlocks could be saved by:
- moving the clearing of TICKET_SLOWPATH_FLAG into the
On 02/06/2015 04:27 AM, Linus Torvalds wrote:
On Thu, Feb 5, 2015 at 2:37 PM, Davidlohr Bueso wrote:
It is possible that the paravirt spinlocks could be saved by:
- moving the clearing of TICKET_SLOWPATH_FLAG into the fastpath locking code.
Ouch, to avoid deadlocks they explicitly need
On Thu, Feb 5, 2015 at 2:37 PM, Davidlohr Bueso wrote:
>>
>> It is possible that the paravirt spinlocks could be saved by:
>>
>> - moving the clearing of TICKET_SLOWPATH_FLAG into the fastpath locking
>> code.
>
> Ouch, to avoid deadlocks they explicitly need the unlock to occur before
> the
On Thu, 2015-02-05 at 13:34 -0800, Linus Torvalds wrote:
> On Thu, Feb 5, 2015 at 1:02 PM, Sasha Levin wrote:
> >
> > Interestingly enough, according to that article this behaviour seems to be
> > "by design":
>
> Oh, it's definitely by design, it's just that the design looked at
> spinlocks
On Thu, Feb 5, 2015 at 1:02 PM, Sasha Levin wrote:
>
> Interestingly enough, according to that article this behaviour seems to be
> "by design":
Oh, it's definitely by design, it's just that the design looked at
spinlocks without the admittedly very subtle issue of lifetime vs
unlocking.
On 02/05/2015 03:59 PM, Davidlohr Bueso wrote:
> On Wed, 2015-02-04 at 16:16 -0800, Linus Torvalds wrote:
>> And looking at the arch version, I think the paravirtualized code is crap.
>>
>> It does:
>>
>> prev = *lock;
>> add_smp(>tickets.head, TICKET_LOCK_INC);
>>
On Wed, 2015-02-04 at 16:16 -0800, Linus Torvalds wrote:
> And looking at the arch version, I think the paravirtualized code is crap.
>
> It does:
>
> prev = *lock;
> add_smp(>tickets.head, TICKET_LOCK_INC);
>
> /* add_smp() is a full mb() */
>
>
On 02/05/2015 04:30 AM, Peter Zijlstra wrote:
> On Wed, Feb 04, 2015 at 04:16:54PM -0800, Linus Torvalds wrote:
>> > Why did I think we had this bug but already fixed it ? Maybe it's one
>> > of those things that Waiman fixed in his long delayed qspinlock
>> > series? Waiman?
> ISTR that that
On Wed, Feb 04, 2015 at 04:16:54PM -0800, Linus Torvalds wrote:
>
> Why did I think we had this bug but already fixed it ? Maybe it's one
> of those things that Waiman fixed in his long delayed qspinlock
> series? Waiman?
ISTR that that would do the exact same thing, but I need to go look a
the
On 02/06/2015 04:27 AM, Linus Torvalds wrote:
On Thu, Feb 5, 2015 at 2:37 PM, Davidlohr Bueso d...@stgolabs.net wrote:
It is possible that the paravirt spinlocks could be saved by:
- moving the clearing of TICKET_SLOWPATH_FLAG into the fastpath locking code.
Ouch, to avoid deadlocks they
On Wed, 2015-02-04 at 16:16 -0800, Linus Torvalds wrote:
And looking at the arch version, I think the paravirtualized code is crap.
It does:
prev = *lock;
add_smp(lock-tickets.head, TICKET_LOCK_INC);
/* add_smp() is a full mb() */
On 02/05/2015 03:59 PM, Davidlohr Bueso wrote:
On Wed, 2015-02-04 at 16:16 -0800, Linus Torvalds wrote:
And looking at the arch version, I think the paravirtualized code is crap.
It does:
prev = *lock;
add_smp(lock-tickets.head, TICKET_LOCK_INC);
On Thu, Feb 5, 2015 at 1:02 PM, Sasha Levin sasha.le...@oracle.com wrote:
Interestingly enough, according to that article this behaviour seems to be
by design:
Oh, it's definitely by design, it's just that the design looked at
spinlocks without the admittedly very subtle issue of lifetime vs
On Thu, 2015-02-05 at 13:34 -0800, Linus Torvalds wrote:
On Thu, Feb 5, 2015 at 1:02 PM, Sasha Levin sasha.le...@oracle.com wrote:
Interestingly enough, according to that article this behaviour seems to be
by design:
Oh, it's definitely by design, it's just that the design looked at
On Thu, Feb 5, 2015 at 2:37 PM, Davidlohr Bueso d...@stgolabs.net wrote:
It is possible that the paravirt spinlocks could be saved by:
- moving the clearing of TICKET_SLOWPATH_FLAG into the fastpath locking
code.
Ouch, to avoid deadlocks they explicitly need the unlock to occur before
On Wed, Feb 04, 2015 at 04:16:54PM -0800, Linus Torvalds wrote:
Why did I think we had this bug but already fixed it ? Maybe it's one
of those things that Waiman fixed in his long delayed qspinlock
series? Waiman?
ISTR that that would do the exact same thing, but I need to go look a
the
On 02/05/2015 04:30 AM, Peter Zijlstra wrote:
On Wed, Feb 04, 2015 at 04:16:54PM -0800, Linus Torvalds wrote:
Why did I think we had this bug but already fixed it ? Maybe it's one
of those things that Waiman fixed in his long delayed qspinlock
series? Waiman?
ISTR that that would do the
* Linus Torvalds wrote:
> [...]
>
> As usual, the paravirt code is a horribly buggy heap of crud.
> Film at 11.
>
> Why did I think we had this bug but already fixed it ? Maybe
> it's one of those things that Waiman fixed in his long delayed
> qspinlock series? Waiman? Or maybe I just
On Wed, Feb 4, 2015 at 3:24 PM, Sasha Levin wrote:
>
> I now have a theory for why it happens:
>
> Thread AThread B
> --
>
> [Enter function]
> DECLARE_COMPLETION_ONSTACK(x)
> wait_for_completion(x)
>
On Wed, 04 Feb 2015 18:24:06 -0500 Sasha Levin wrote:
> Hi all,
>
> I was fuzzing with trinity on a -next kernel with the KASan patchset, and
> got what initially appeared to be a rather odd trace:
>
> ...
>
>
> I now have a theory for why it happens:
>
> Thread A
Hi all,
I was fuzzing with trinity on a -next kernel with the KASan patchset, and
got what initially appeared to be a rather odd trace:
[ 856.817966] BUG: AddressSanitizer: out of bounds on stack in
do_raw_spin_unlock+0x417/0x4f0 at addr 8803875c7c42
[ 856.817966] Read of size 2 by task
On Wed, Feb 4, 2015 at 3:24 PM, Sasha Levin sasha.le...@oracle.com wrote:
I now have a theory for why it happens:
Thread AThread B
--
[Enter function]
DECLARE_COMPLETION_ONSTACK(x)
* Linus Torvalds torva...@linux-foundation.org wrote:
[...]
As usual, the paravirt code is a horribly buggy heap of crud.
Film at 11.
Why did I think we had this bug but already fixed it ? Maybe
it's one of those things that Waiman fixed in his long delayed
qspinlock series? Waiman?
Hi all,
I was fuzzing with trinity on a -next kernel with the KASan patchset, and
got what initially appeared to be a rather odd trace:
[ 856.817966] BUG: AddressSanitizer: out of bounds on stack in
do_raw_spin_unlock+0x417/0x4f0 at addr 8803875c7c42
[ 856.817966] Read of size 2 by task
On Wed, 04 Feb 2015 18:24:06 -0500 Sasha Levin sasha.le...@oracle.com wrote:
Hi all,
I was fuzzing with trinity on a -next kernel with the KASan patchset, and
got what initially appeared to be a rather odd trace:
...
I now have a theory for why it happens:
Thread A
28 matches
Mail list logo
