linux-kernel - Re: [Resend] 3.2-rc6+: Reported regressions from 3.0 and 3.1

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]

Date:	Tue, 20 Dec 2011 20:44:33 -0800
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Dave Kleikamp <dave.kleikamp@...cle.com>
Cc:	"Rafael J. Wysocki" <rjw@...k.pl>,
	Dave Kleikamp <shaggy@...nel.org>,
	jfs-discussion@...ts.sourceforge.net,
	Kernel Testers List <kernel-testers@...r.kernel.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Maciej Rutecki <maciej.rutecki@...il.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Florian Mickler <florian@...kler.org>, davem@...emloft.net,
	Hugh Dickins <hughd@...gle.com>,
	Al Viro <viro@...iv.linux.org.uk>, linux-mm@...ck.org
Subject: Re: [Resend] 3.2-rc6+: Reported regressions from 3.0 and 3.1

On Tue, Dec 20, 2011 at 8:23 PM, Dave Kleikamp <dave.kleikamp@...cle.com> wrote:
>
> I don't think this is a regression.  It's been seen before, but the
> patch never got submitted, or was lost somewhere. I believe this
> will fix it.

Hmm. This patch looks obviously correct. But it looks *so* obviously
correct that it just makes me suspicious - this is not new or seldom
used code, it's been this way for ages and used all the time. That
line literally goes back to 2007, commit eb2be189317d0. And it looks
like even before that we had a GFP_KERNEL for the add_to_page_cache()
case and that goes back to before the git history. So this is
*ancient*.

Maybe almost nobody uses __read_cache_page() with a non-GFP_KERNEL gfp
and as a result we've not noticed.

Or maybe there is some crazy reason why it calls "add_to_page_cache()"
with GFP_KERNEL.

Adding the usual suspects for mm/filemap.c to the cc line (Andrew is
already cc'd, but Al and Hugh should comment).

Ack's, people? Is it really as obvious as it looks, and we've just had
this bug forever?

            Linus

--- snip snip ---
> vfs: __read_cache_page should use gfp argument rather than GFP_KERNEL
>
> lockdep reports a deadlock in jfs because a special inode's rw semaphore
> is taken recursively. The mapping's gfp mask is GFP_NOFS, but is not used
> when __read_cache_page() calls add_to_page_cache_lru().
>
> Signed-off-by: Dave Kleikamp <dave.kleikamp@...cle.com>
>
> diff --git a/mm/filemap.c b/mm/filemap.c
> index c106d3b..c9ea3df 100644
> --- a/mm/filemap.c
> +++ b/mm/filemap.c
> @@ -1828,7 +1828,7 @@ repeat:
>                page = __page_cache_alloc(gfp | __GFP_COLD);
>                if (!page)
>                        return ERR_PTR(-ENOMEM);
> -               err = add_to_page_cache_lru(page, mapping, index, GFP_KERNEL);
> +               err = add_to_page_cache_lru(page, mapping, index, gfp);
>                if (unlikely(err)) {
>                        page_cache_release(page);
>                        if (err == -EEXIST)
--
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/