From: Ira Snyder <kernel@irasnyder.com>
To: Alexey Dobriyan <adobriyan@gmail.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH] sparse fix: add many lock annotations
Date: Wed, 22 Nov 2006 11:34:08 -0800 [thread overview]
Message-ID: <20061122113408.98310698.kernel@irasnyder.com> (raw)
In-Reply-To: <20061122183306.GA4970@martell.zuzino.mipt.ru>
On Wed, 22 Nov 2006 21:33:07 +0300
Alexey Dobriyan <adobriyan@gmail.com> wrote:
> On Wed, Nov 22, 2006 at 12:11:46AM -0800, Ira Snyder wrote:
> > This patch adds many lock annotations to the kernel source to quiet
> > warnings from sparse. In almost every case, it quiets the warning caused
> > by locks that are intentionally grabbed in one function and released in
> > another.
> >
> > In the other cases, __acquire() and __release() are used to make sparse
> > believe that a lock was grabbed (even though it was not), in order to
> > make all exit points have equal lock counts. These follow the style in
> > kernel/sched.c.
>
> > --- a/arch/i386/kernel/smp.c
> > +++ b/arch/i386/kernel/smp.c
> > @@ -507,11 +507,13 @@ struct call_data_struct {
> > };
> >
> > void lock_ipi_call_lock(void)
> > +__acquires(call_lock)
> > {
> > spin_lock_irq(&call_lock);
> > }
> >
> > void unlock_ipi_call_lock(void)
> > +__releases(call_lock)
> > {
> > spin_unlock_irq(&call_lock);
> > }
>
> Wrong place. Prototypes should be marked instead. How else would you
> know about:
>
> lock_ipi_call_lock();
> if (foo)
> return -E;
> lock_ipi_call_lock();
>
> on another compilation unit?
>
Are you saying I should use something like this instead?:
diff --git a/include/asm-i386/smp.h b/include/asm-i386/smp.h
index bd59c15..9489602 100644
--- a/include/asm-i386/smp.h
+++ b/include/asm-i386/smp.h
@@ -38,8 +38,8 @@ extern cpumask_t cpu_core_map[];
extern void (*mtrr_hook) (void);
extern void zap_low_mappings (void);
-extern void lock_ipi_call_lock(void);
-extern void unlock_ipi_call_lock(void);
+extern void lock_ipi_call_lock(void) __acquires(call_lock);
+extern void unlock_ipi_call_lock(void) __releases(call_lock);
#define MAX_APICID 256
extern u8 x86_cpu_to_apicid[];
If so, it doesn't remove the warning from sparse, it still shows:
CHECK
arch/i386/kernel/smp.c arch/i386/kernel/smp.c:509:6: warning: context
imbalance in 'lock_ipi_call_lock' - wrong count at exit
arch/i386/kernel/smp.c:514:6: warning: context imbalance in
'unlock_ipi_call_lock' - unexpected unlock
Those go away with the original patch.
I was following some examples currently in the source, such as in
arch/i386/kernel/efi.c on function efi_call_phys_prelog(). Or
expand_fdtable() in fs/file.c is another good example.
> > --- a/drivers/acpi/osl.c
> > +++ b/drivers/acpi/osl.c
> > @@ -1004,6 +1004,7 @@ EXPORT_SYMBOL(max_cstate);
> > */
> >
> > acpi_cpu_flags acpi_os_acquire_lock(acpi_spinlock lockp)
> > +__acquires(lockp)
> > {
> > acpi_cpu_flags flags;
> > spin_lock_irqsave(lockp, flags);
> > @@ -1015,6 +1016,7 @@ acpi_cpu_flags acpi_os_acquire_lock(acpi
> > */
> >
> > void acpi_os_release_lock(acpi_spinlock lockp, acpi_cpu_flags flags)
> > +__releases(lockp)
> > {
> > spin_unlock_irqrestore(lockp, flags);
> > }
>
> Again, wrong. IMO, sparse should deduce itself that lock is grabbed in such
> trivial cases.
>
I'm not sure that it can. See: http://lwn.net/Articles/109066/ where
Linus talks about addings __acquires(lockname) and __releases(lockname)
to functions whose purpose is to grab and hold a lock at exit.
Anyway, this is my first patch on the LKML, so I'd like to try and get
it right.
Thanks,
Ira
next prev parent reply other threads:[~2006-11-22 19:34 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-11-22 8:11 [PATCH] sparse fix: add many lock annotations Ira Snyder
2006-11-22 18:33 ` Alexey Dobriyan
2006-11-22 19:34 ` Ira Snyder [this message]
2006-11-23 8:18 ` Ira Snyder
2006-11-24 18:47 ` Alexey Dobriyan
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=20061122113408.98310698.kernel@irasnyder.com \
--to=kernel@irasnyder.com \
--cc=adobriyan@gmail.com \
--cc=linux-kernel@vger.kernel.org \
/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.