Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1199071
| From | Oleg Nesterov <oleg@redhat.com> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: HARD LOCKUP: Strange hard lock up on spin_lock(&sighand->siglock); |
| Date | 2015-08-03 19:10 +0200 |
| Message-ID | <pTrpr-W6-83@gated-at.bofh.it> (permalink) |
| References | <pQQaC-2jQ-9@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
Sorry for delay, vacation. I'll try to re-read your email later, just one note for now... On 07/27, Nikolay Borisov wrote: > > Based on that I think could be happening is that the sighand itself is > being freed while we are in the grace period inside __lock_task_sighand > but the slab page itself is not freed as per the semantics of > SLAB_DESTROY_BY_RCU. I looked up the source of this function in the > latest kernels and saw that Oleg had put a comment clarifying the > semantics but I'm still not convinced that it is safe. What if > we are trying to lock the spinlock before this particular slab is > initialised with sighand_ctor? But this is not possible? ->sighand can never point to the uninitialized struct sighand_struct. Just in case... please note that if ->sighand was freed and then re-allocated while __lock_task_sighand() spins under rcu_read_lock(), sighand_ctor() won't be called again (due to SLAB_DESTROY_BY_RCU). Perhaps this was the source of your confusion? Oleg. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Back to linux.kernel | Previous | Next | Find similar | Unroll thread
Re: HARD LOCKUP: Strange hard lock up on spin_lock(&sighand->siglock); Oleg Nesterov <oleg@redhat.com> - 2015-08-03 19:10 +0200
csiph-web