Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753432AbaBOP6p (ORCPT ); Sat, 15 Feb 2014 10:58:45 -0500 Received: from zeniv.linux.org.uk ([195.92.253.2]:53055 "EHLO ZenIV.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753385AbaBOP6o (ORCPT ); Sat, 15 Feb 2014 10:58:44 -0500 Date: Sat, 15 Feb 2014 15:58:38 +0000 From: Al Viro To: Oleg Nesterov Cc: Linus Torvalds , Dave Chinner , Dave Jones , Eric Sandeen , Linux Kernel , xfs@oss.sgi.com Subject: Re: 3.14-rc2 XFS backtrace because irqs_disabled. Message-ID: <20140215155838.GA18016@ZenIV.linux.org.uk> References: <20140212113928.GO18016@ZenIV.linux.org.uk> <20140212211421.GP18016@ZenIV.linux.org.uk> <20140213174020.GA14455@redhat.com> <20140215052531.GX18016@ZenIV.linux.org.uk> <20140215142700.GA15540@redhat.com> <20140215152251.GY18016@ZenIV.linux.org.uk> <20140215153631.GZ18016@ZenIV.linux.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140215153631.GZ18016@ZenIV.linux.org.uk> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, Feb 15, 2014 at 03:36:31PM +0000, Al Viro wrote: > On Sat, Feb 15, 2014 at 03:22:51PM +0000, Al Viro wrote: > > On Sat, Feb 15, 2014 at 03:27:00PM +0100, Oleg Nesterov wrote: > > > > > 1. info->q can be already freed if SIGQUEUE_PREALLOC. > > > > > > Once get_signal_to_deliver() or any other caller drops ->siglock > > > another thread can do sys_timer_delete()->sigqueue_free(). > > > > How the devil would it find the sucker? It's off the list already. > > Ouch... I think I see what you mean. Let me see if I got it right: > timer->sigq is *not* freed by collect_signal(); it's done by > release_posix_timer() instead, under siglock. Frankly, this > /* > * If it is queued it will be freed when dequeued, > * like the "regular" sigqueue. > */ > if (!list_empty(&q->list)) > q = NULL; > in sigqueue_free() smells like it's asking for races. Sigh... So basically we want a different condition for "can we just go ahead and free that sucker", right? Instead of "it's on the list, shan't free it" it ought to be something like "it's on the list or it is referenced by ksiginfo". Locking will be interesting, though... ;-/ BTW, I really wonder how does that stuff interact with PTRACE_SETSIGINFO. What happens if tracer does PTRACE_GETSIGINFO, changes ->si_signo to something blocked, shoves it back with PTRACE_SETSIGINFO and does PTRACE_CONT with that new signal number? Would we get two sigqueue instances with the same ->si_tid, one of them matching the timer->sigq and another - not? -- 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/