From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keith Owens Date: Sun, 03 Aug 2008 02:08:08 +0000 Subject: Re: [patch] IA64: suppress return value of down_trylock() in salinfo_work_to_do() Message-Id: <12597.1217729288@ocs10w> List-Id: In-Reply-To: Your message of "Sat, 02 Aug 2008 19:32:00 CST." <20080803013159.GB26461@parisc-linux.org> References: <20080803000654.GA30659@verge.net.au> In-Reply-To: <20080803000654.GA30659@verge.net.au> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Matthew Wilcox Cc: Simon Horman , linux-ia64@vger.kernel.org, linux-kernel@vger.kernel.org, Tony Luck Matthew Wilcox (on Sat, 2 Aug 2008 19:32:00 -0600) wrote: >On Sun, Aug 03, 2008 at 10:06:58AM +1000, Simon Horman wrote: >> salinfo_work_to_do() intentionally ignores the return value of >> down_trylock() and calls up() regardless of if the lock >> was taken or not. >> >> This patch suppresses the warning generated by ignoring >> this return value - down_trylock() is annotated with __must_check. > >I can't say that I think this is a good idea. Has anyone looked at what >it would take to actually track this? For example, could we ever have >the situation where: > >task A acquires sem > >task B tries to acquire the sem, fails >task B releases the sem that it didn't acquire > >task A releases the sem, falls down, goes boom? Cannot happen. See the comment above the function: This routine must be called with data_saved_lock held, to make the down/up operation atomic