On 03/10, Linus Torvalds wrote:
>
> So I'm not a huge fan of SLAB_DESTROY_BY_RCU in general, but for
> really core data structures like this, I think it's worth it.
I agree, but we have other users which can't be fixed if we just add
SLAB_DESTROY_BY_RCU to task_struct_cachep. So we need something
On Tue, Mar 10, 2015 at 10:28 AM, Oleg Nesterov wrote:
>
> But this won't fix other problems we might have. For example, suppose
> that we will need get_task_struct(owner) in this code, this won't work.
I agree that SLAB_DESTROY_BY_RCU in general is fairly fragile, and
leads to subtle issues. If
On 03/10, Linus Torvalds wrote:
>
> On Sat, Mar 7, 2015 at 9:13 AM, Oleg Nesterov wrote:
> >> + /*
> >> + * Ensure we emit the owner->on_cpu, dereference _after_
> >> + * checking sem->owner still matches owner, if that fails,
> >> + * owner
On Tue, Mar 10, 2015 at 09:04:23AM -0700, Linus Torvalds wrote:
>
> I think we should just make 'task_struct_cachep' have SLAB_DESTROY_BY_RCU.
Yes, that'll work. Also for the other cases Oleg found previously I
think.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
On Sat, Mar 7, 2015 at 9:13 AM, Oleg Nesterov wrote:
>> + /*
>> + * Ensure we emit the owner->on_cpu, dereference _after_
>> + * checking sem->owner still matches owner, if that fails,
>> + * owner might point to free()d memory, if it still
On Sat, Mar 07, 2015 at 06:13:47PM +0100, Oleg Nesterov wrote:
> I think the patch is fine, but this reminds me...
>
> On 03/07, tip-bot for Jason Low wrote:
> >
> > bool rwsem_spin_on_owner(struct rw_semaphore *sem, struct task_struct
> > *owner)
> > {
> > long count;
> >
> >
On Sat, Mar 07, 2015 at 06:13:47PM +0100, Oleg Nesterov wrote:
I think the patch is fine, but this reminds me...
On 03/07, tip-bot for Jason Low wrote:
bool rwsem_spin_on_owner(struct rw_semaphore *sem, struct task_struct
*owner)
{
long count;
rcu_read_lock();
-
On 03/10, Linus Torvalds wrote:
On Sat, Mar 7, 2015 at 9:13 AM, Oleg Nesterov o...@redhat.com wrote:
+ /*
+ * Ensure we emit the owner-on_cpu, dereference _after_
+ * checking sem-owner still matches owner, if that fails,
+ * owner might
On Tue, Mar 10, 2015 at 10:28 AM, Oleg Nesterov o...@redhat.com wrote:
But this won't fix other problems we might have. For example, suppose
that we will need get_task_struct(owner) in this code, this won't work.
I agree that SLAB_DESTROY_BY_RCU in general is fairly fragile, and
leads to
On Sat, Mar 7, 2015 at 9:13 AM, Oleg Nesterov o...@redhat.com wrote:
+ /*
+ * Ensure we emit the owner-on_cpu, dereference _after_
+ * checking sem-owner still matches owner, if that fails,
+ * owner might point to free()d memory, if it still
On Tue, Mar 10, 2015 at 09:04:23AM -0700, Linus Torvalds wrote:
I think we should just make 'task_struct_cachep' have SLAB_DESTROY_BY_RCU.
Yes, that'll work. Also for the other cases Oleg found previously I
think.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the
On 03/10, Linus Torvalds wrote:
So I'm not a huge fan of SLAB_DESTROY_BY_RCU in general, but for
really core data structures like this, I think it's worth it.
I agree, but we have other users which can't be fixed if we just add
SLAB_DESTROY_BY_RCU to task_struct_cachep. So we need something
I think the patch is fine, but this reminds me...
On 03/07, tip-bot for Jason Low wrote:
>
> bool rwsem_spin_on_owner(struct rw_semaphore *sem, struct task_struct *owner)
> {
> long count;
>
> rcu_read_lock();
> - while (owner_running(sem, owner)) {
> - /* abort
Commit-ID: 9198f6edfd9ced74fd90b238d5a354aeac89bdfa
Gitweb: http://git.kernel.org/tip/9198f6edfd9ced74fd90b238d5a354aeac89bdfa
Author: Jason Low
AuthorDate: Fri, 6 Mar 2015 23:45:31 -0800
Committer: Ingo Molnar
CommitDate: Sat, 7 Mar 2015 09:50:49 +0100
locking/rwsem: Fix lock
Commit-ID: 9198f6edfd9ced74fd90b238d5a354aeac89bdfa
Gitweb: http://git.kernel.org/tip/9198f6edfd9ced74fd90b238d5a354aeac89bdfa
Author: Jason Low jason.l...@hp.com
AuthorDate: Fri, 6 Mar 2015 23:45:31 -0800
Committer: Ingo Molnar mi...@kernel.org
CommitDate: Sat, 7 Mar 2015 09:50:49 +0100
I think the patch is fine, but this reminds me...
On 03/07, tip-bot for Jason Low wrote:
bool rwsem_spin_on_owner(struct rw_semaphore *sem, struct task_struct *owner)
{
long count;
rcu_read_lock();
- while (owner_running(sem, owner)) {
- /* abort spinning
16 matches
Mail list logo
