lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140922181250.GN1193@ld-irv-0074>
Date:	Mon, 22 Sep 2014 11:12:50 -0700
From:	Brian Norris <computersforpeace@...il.com>
To:	Fabian Frederick <fabf@...net.be>
Cc:	linux-kernel@...r.kernel.org, linux-mtd@...ts.infradead.org,
	David Woodhouse <dwmw2@...radead.org>,
	linux-sparse@...r.kernel.org
Subject: Re: [PATCH 1/1] jffs2: fix sparse warning: unexpected unlock

+ linux-sparse

On Thu, Sep 18, 2014 at 08:46:16PM +0200, Fabian Frederick wrote:
> fs/jffs2/summary.c:846:5: warning: context imbalance in 'jffs2_sum_write_sumnode' - unexpected unlock
> 
> Signed-off-by: Fabian Frederick <fabf@...net.be>
> ---
>  fs/jffs2/summary.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/fs/jffs2/summary.c b/fs/jffs2/summary.c
> index c522d09..a0bac7b 100644
> --- a/fs/jffs2/summary.c
> +++ b/fs/jffs2/summary.c
> @@ -844,6 +844,8 @@ static int jffs2_sum_write_data(struct jffs2_sb_info *c, struct jffs2_eraseblock
>  /* Write out summary information - called from jffs2_do_reserve_space */
>  
>  int jffs2_sum_write_sumnode(struct jffs2_sb_info *c)
> +	__releases(&c->erase_completion_lock)
> +	__acquires(&c->erase_completion_lock)

I'm not too familiar with sparse notations, but Documentation/sparse.txt
suggests the above is wrong, and the following is more accurate:

	__must_hold(&c->erase_completion_lock)

But it looks like there are several other examples which do this.
Anyway, here's the relevant doc text, in case someone wants to clarify
it for me, or else tell me the documentation is wrong:

    __must_hold - The specified lock is held on function entry and exit.

    __acquires - The specified lock is held on function exit, but not entry.

    __releases - The specified lock is held on function entry, but not exit.

So __acquires and __releases look mutually exclusive, but it's not clear
if __must_hold will actually cover what we want. (I haven't tested it.)

>  {
>  	int datasize, infosize, padsize;
>  	struct jffs2_eraseblock *jeb;

Brian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ