linux-kernel - Re: [LKP] [mm] cc87317726f: WARNING: CPU: 0 PID: 1 at drivers/iommu/io-pgtable-arm.c:413 __arm_lpae

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: <20150317192413.GA7772@phnom.home.cmpxchg.org>
Date:	Tue, 17 Mar 2015 15:24:13 -0400
From:	Johannes Weiner <hannes@...xchg.org>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Huang Ying <ying.huang@...el.com>, Michal Hocko <mhocko@...e.cz>,
	Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>,
	David Rientjes <rientjes@...gle.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Dave Chinner <david@...morbit.com>,
	LKML <linux-kernel@...r.kernel.org>, LKP ML <lkp@...org>,
	linux-mm <linux-mm@...ck.org>
Subject: Re: [LKP] [mm] cc87317726f: WARNING: CPU: 0 PID: 1 at
 drivers/iommu/io-pgtable-arm.c:413 __arm_lpae_unmap+0x341/0x380()

On Tue, Mar 17, 2015 at 10:15:29AM -0700, Linus Torvalds wrote:
> Explicitly adding the emails of other people involved with that commit
> and the original oom thread to make sure people are aware, since this
> didn't get any response.
> 
> Commit cc87317726f8 fixed some behavior, but also seems to have turned
> an oom situation into a complete hang. So presumably we shouldn't loop
> *forever*. Hmm?

It seems we are between a rock and a hard place here, as we reverted
specifically to that endless looping on request of filesystem people.
They said[1] they rely on these allocations never returning NULL, or
they might fail inside a transactions and corrupt on-disk data.

Huang, against which kernels did you first run this test on this exact
setup?  Is there a chance you could try to run a kernel without/before
9879de7373fc?  I want to make sure I'm not missing something, but all
versions preceding this commit should also have the same hang.  There
should only be a tiny window between 9879de7373fc and cc87317726f8 --
v3.19 -- where these allocations are allowed to fail.

[1] https://www.marc.info/?l=linux-mm&m=142450545009301&w=3
--
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/