From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757523AbdJKPkU (ORCPT ); Wed, 11 Oct 2017 11:40:20 -0400 Received: from bombadil.infradead.org ([65.50.211.133]:54440 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757254AbdJKPkR (ORCPT ); Wed, 11 Oct 2017 11:40:17 -0400 Date: Wed, 11 Oct 2017 08:40:13 -0700 From: Matthew Wilcox To: Linus Torvalds Cc: Andrew Morton , Johannes Thumshirn , linux-fsdevel , "linux-nvdimm@lists.01.org" , OGAWA Hirofumi , Ross Zwisler , Toshi Kani , Linux Kernel Mailing List Subject: Re: [PATCH] Fix mpage_writepage() for pages with buffers Message-ID: <20171011154013.GA11800@bombadil.infradead.org> References: <20171006211541.GA7409@bombadil.infradead.org> <20171010124421.c545e6308fed5a585acd43cd@linux-foundation.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.8.3 (2017-05-23) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Oct 10, 2017 at 01:31:44PM -0700, Linus Torvalds wrote: > On Tue, Oct 10, 2017 at 12:44 PM, Andrew Morton > wrote: > > > > This is all pretty mature code (isn't it?). Any idea why this bug > > popped up now? I have no idea why it's suddenly popped up. It looks like it should be a bohrbug, but it's actually a heisenbug, and I don't understand that either. > Also, while the patch looks sane, the > > clean_buffers(page, PAGE_SIZE); > > line really threw me. That's an insane value to pick, it looks like > "bytes in page", but it isn't. It's just a random value that is bigger > than "PAGE_SIZE >> SECTOR_SHIFT". > > I'd prefer to see just ~0u if the intention is just "bigger than > anything possible". Actually, I did choose it to be "number of bytes in the page", based on the reasoning that I didn't want to calculate what the actual block size was, and the block size surely couldn't be any smaller than one byte. I forgot about the SECTOR_SIZE limit on filesystem block size, so your spelling of "big enough" does look better. Now that I think about it some more, I suppose we might end up with a situation where we're eventually passing a hugepage to this routine, and futureproofing it with ~0U probably makes more sense.