From: Keith Owens <kaos@ocs.com.au>
To: Matthew Wilcox <matthew@wil.cx>
Cc: Simon Horman <horms@verge.net.au>,
linux-ia64@vger.kernel.org, linux-kernel@vger.kernel.org,
Tony Luck <tony.luck@intel.com>
Subject: Re: [patch] IA64: suppress return value of down_trylock() in salinfo_work_to_do()
Date: Sun, 03 Aug 2008 02:08:08 +0000 [thread overview]
Message-ID: <12597.1217729288@ocs10w> (raw)
In-Reply-To: Your message of "Sat, 02 Aug 2008 19:32:00 CST." <20080803013159.GB26461@parisc-linux.org>
In-Reply-To: <20080803000654.GA30659@verge.net.au>
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
WARNING: multiple messages have this Message-ID (diff)
From: Keith Owens <kaos@ocs.com.au>
To: Matthew Wilcox <matthew@wil.cx>
Cc: Simon Horman <horms@verge.net.au>,
linux-ia64@vger.kernel.org, linux-kernel@vger.kernel.org,
Tony Luck <tony.luck@intel.com>
Subject: Re: [patch] IA64: suppress return value of down_trylock() in salinfo_work_to_do()
Date: Sun, 03 Aug 2008 12:08:08 +1000 [thread overview]
Message-ID: <12597.1217729288@ocs10w> (raw)
In-Reply-To: Your message of "Sat, 02 Aug 2008 19:32:00 CST." <20080803013159.GB26461@parisc-linux.org>
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
next prev parent reply other threads:[~2008-08-03 2:08 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-08-03 0:06 [patch] IA64: suppress return value of down_trylock() in Simon Horman
2008-08-03 0:06 ` [patch] IA64: suppress return value of down_trylock() in salinfo_work_to_do() Simon Horman
2008-08-03 1:32 ` Matthew Wilcox
2008-08-03 1:32 ` Matthew Wilcox
2008-08-03 1:44 ` Matthew Wilcox
2008-08-03 1:44 ` Matthew Wilcox
2008-08-03 2:08 ` Keith Owens [this message]
2008-08-03 2:08 ` Keith Owens
2008-08-03 2:43 ` Matthew Wilcox
2008-08-03 2:43 ` Matthew Wilcox
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=12597.1217729288@ocs10w \
--to=kaos@ocs.com.au \
--cc=horms@verge.net.au \
--cc=linux-ia64@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=matthew@wil.cx \
--cc=tony.luck@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.