public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
* __lock_task_sighand() and RCU
@ 2011-03-28  7:56 Matt Fleming
  2011-03-28 13:36 ` Oleg Nesterov
  0 siblings, 1 reply; 3+ messages in thread
From: Matt Fleming @ 2011-03-28  7:56 UTC (permalink / raw)
  To: Oleg Nesterov; +Cc: linux-kernel

Hi Oleg,

I've been reading __lock_task_sighand() and I can't quite wrap my head
around what the rcu_read_lock()/rcu_read_unlock() is protecting in
there.

Initially I assumed that it was protecting the 'tsk' argument, but
realised that can't be right because all rcu_read_lock() guarantees is
that if tsk is valid when we enter the read section, it will remain
valid throughout the rcu read side section. It doesn't guarantee that
when we enter the read side section 'tsk' _will_ be valid; the callers
are required to lookup and verify the value of 'tsk' before they call
__lock_task_sighand() (possibly by calling __lock_task_sighand() from
within an rcu_read_lock() section).

Then I wondered if it was protecting the sighand from being freed from
under us while we're trying to lock it. But sighands aren't freed via
rcu, it's just a simple refcnt and kmem_cache_free() deal in
__cleanup_sighand() with all synchronization done via the siglock.

So what does that rcu_read_lock() protect?

I'm most likely missing some obvious detail but if you could help me
out I'd appreciate it!

-- 
Matt Fleming, Intel Open Source Technology Center

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: __lock_task_sighand() and RCU
  2011-03-28  7:56 __lock_task_sighand() and RCU Matt Fleming
@ 2011-03-28 13:36 ` Oleg Nesterov
  2011-03-28 15:04   ` Matt Fleming
  0 siblings, 1 reply; 3+ messages in thread
From: Oleg Nesterov @ 2011-03-28 13:36 UTC (permalink / raw)
  To: Matt Fleming; +Cc: linux-kernel

Hi Matt,

On 03/28, Matt Fleming wrote:
>
> I've been reading __lock_task_sighand() and I can't quite wrap my head
> around what the rcu_read_lock()/rcu_read_unlock() is protecting in
> there.

It protects ->sighand.

> Initially I assumed that it was protecting the 'tsk' argument,

No. the caller must have a reference.

> Then I wondered if it was protecting the sighand from being freed from
> under us while we're trying to lock it.

Yes,

> But sighands aren't freed via
> rcu,

it is ;)

> it's just a simple refcnt and kmem_cache_free()

Yes, but please note that sighand_cachep was created with
SLAB_DESTROY_BY_RCU.

Oleg.


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: __lock_task_sighand() and RCU
  2011-03-28 13:36 ` Oleg Nesterov
@ 2011-03-28 15:04   ` Matt Fleming
  0 siblings, 0 replies; 3+ messages in thread
From: Matt Fleming @ 2011-03-28 15:04 UTC (permalink / raw)
  To: Oleg Nesterov; +Cc: linux-kernel

On Mon, 28 Mar 2011 15:36:02 +0200
Oleg Nesterov <oleg@redhat.com> wrote:
 
> > But sighands aren't freed via
> > rcu,
> 
> it is ;)
> 
> > it's just a simple refcnt and kmem_cache_free()
> 
> Yes, but please note that sighand_cachep was created with
> SLAB_DESTROY_BY_RCU.

D'oh. I knew it would be something obvious like that.

Thanks Oleg!

-- 
Matt Fleming, Intel Open Source Technology Center

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2011-03-28 15:05 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-03-28  7:56 __lock_task_sighand() and RCU Matt Fleming
2011-03-28 13:36 ` Oleg Nesterov
2011-03-28 15:04   ` Matt Fleming

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox