Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S262387AbUJ0KmP (ORCPT ); Wed, 27 Oct 2004 06:42:15 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S262393AbUJ0KiZ (ORCPT ); Wed, 27 Oct 2004 06:38:25 -0400 Received: from omx2-ext.sgi.com ([192.48.171.19]:49383 "EHLO omx2.sgi.com") by vger.kernel.org with ESMTP id S262375AbUJ0Kek (ORCPT ); Wed, 27 Oct 2004 06:34:40 -0400 Subject: NFS and recalc_sigpending() semantics? From: Greg Banks To: Linux Kernel Mailing List Content-Type: text/plain Organization: Silicon Graphics Inc, Australian Software Group. Message-Id: <1098873273.1985.180.camel@hole.melbourne.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6-1mdk Date: Wed, 27 Oct 2004 20:34:33 +1000 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 947 Lines: 29 G'day, Can someone please explain to me why recalc_sigpending() fails to clear the TIF_SIGPENDING flag if the pending signal is a coredumping signal like SIGQUIT? Is this deliberate? I ask because there's code in the NFS client like this: ---> got here because signal_pending() is set <---- spin_lock_irqsave(¤t->sighand->siglock, flags); oldset = current->blocked; sigfillset(¤t->blocked); recalc_sigpending(); spin_unlock_irqrestore(¤t->sighand->siglock, flags); ---> assumes signal_pending() is cleared <---- Have these semantics changed, or has NFS always been broken? Greg. -- Greg Banks, R&D Software Engineer, SGI Australian Software Group. I don't speak for SGI. - 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/