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
| ||
|
Message-Id: <20130312211138.a2824b7e.akpm@linux-foundation.org> Date: Tue, 12 Mar 2013 21:11:38 -0700 From: Andrew Morton <akpm@...ux-foundation.org> To: Shuge <shugelinux@...il.com> Cc: "Darrick J. Wong" <darrick.wong@...cle.com>, linux-kernel@...r.kernel.org, linux-mm@...ck.org, linux-ext4@...r.kernel.org, Kevin <kevin@...winnertech.com>, Jan Kara <jack@...e.cz>, "Theodore Ts'o" <tytso@....edu>, Jens Axboe <axboe@...nel.dk>, Catalin Marinas <catalin.marinas@....com>, Will Deacon <will.deacon@....com>, linux-arm-kernel@...ts.infradead.org Subject: Re: [PATCH] bounce:fix bug, avoid to flush dcache on slab page from jbd2. On Wed, 13 Mar 2013 11:35:15 +0800 Shuge <shugelinux@...il.com> wrote: > Hi all > >>> The bounce accept slab pages from jbd2, and flush dcache on them. > >>> When enabling VM_DEBUG, it will tigger VM_BUG_ON in page_mapping(). > >>> So, check PageSlab to avoid it in __blk_queue_bounce(). > >>> > >>> Bug URL: http://lkml.org/lkml/2013/3/7/56 > >>> > >>> ... > >>> > >> ...... > >> > > That sure is strange. I didn't see any obvious reasons why we'd end up with a > > > ...... > > Well, this problem not only appear in arm64, but also arm32. And my > kernel version is 3.3.0, arch is arm32. > Following the newest kernel, the problem shoulde be exist. > I agree with Darrick's modification. Hum, if > CONFIG_NEED_BOUNCE_POOL is not set, it also flush dcahce on > the pages of b_frozen_data, some of them are allocated by kmem_cache_alloc. > As we know, jbd2_alloc allocate a buffer from jbd2_xk slab pool, > when the size is smaller than PAGE_SIZE. > The b_frozen_data is not mapped to usrspace, not aliasing cache. It cat > be lazy flush or other. Is it right? Please reread my email. The page at b_frozen_data was allocated with GFP_NOFS. Hence it should not need bounce treatment (if arm is anything like x86). And yet it *did* receive bounce treatment. Why? -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists