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, 9 Feb 2021 12:52:49 -0800
From:   Ira Weiny <>
To:     Andrew Morton <>
Subject: Re: [PATCH 0/4] btrfs: Convert kmaps to core page calls

On Tue, Feb 09, 2021 at 11:09:31AM -0800, Andrew Morton wrote:
> On Tue, 9 Feb 2021 16:11:23 +0100 David Sterba <> wrote:
> > On Fri, Feb 05, 2021 at 03:23:00PM -0800, wrote:
> > > From: Ira Weiny <>
> > > 
> > > There are many places where kmap/<operation>/kunmap patterns occur.  We lift
> > > these various patterns to core common functions and use them in the btrfs file
> > > system.  At the same time we convert those core functions to use
> > > kmap_local_page() which is more efficient in those calls.
> > > 
> > > I think this is best accepted through Andrew's tree as it has the mem*_page
> > > functions in it.  But I'd like to get an ack from David or one of the other
> > > btrfs maintainers before the btrfs patches go through.
> > 
> > I'd rather take the non-mm patches through my tree so it gets tested
> > the same way as other btrfs changes, straightforward cleanups or not.
> > 
> > This brings the question how to do that as the first patch should go
> > through the MM tree. One option is to posptpone the actual cleanups
> > after the 1st patch is merged but this could take a long delay.
> > 
> > I'd suggest to take the 1st patch within MM tree in the upcoming merge
> > window and then I can prepare a separate pull with just the cleanups.
> > Removing an inter-tree patch dependency was a sufficient reason for
> > Linus in the past for such pull requests.
> It would be best to merge [1/4] via the btrfs tree.  Please add my
> Acked-by: Andrew Morton <>
> Although I think it would be better if [1/4] merely did the code
> movement.  Adding those BUG_ON()s is a semantic/functional change and
> really shouldn't be bound up with the other things this patch series
> does.

I proposed this too and was told 'no'...

If we put in into a separate patch, someone will suggest backing out the
patch which tells us that there's a problem.

> This logically separate change raises questions such as
> - What is the impact on overall code size?  Not huge, presumably, but
>   every little bit hurts.
> - Additional runtime costs of those extra comparisons?
> - These impacts could be lessened by using VM_BUG_ON() rather than
>   BUG_ON() - should we do this?

<sigh>  I lost that argument last time around.

BUG() is our only option here.  Both limiting how much we copy or
copying the requested amount result in data corruption or leaking
information to a process that isn't supposed to see it.

CC'ing Matthew because I _really_ don't want to argue this any longer.

> - Linus reeeeeeeally doesn't like new BUG_ON()s.  Maybe you can sneak
>   it past him ;)

I'm worried too...  :-(

> See what I mean?

Yes I do however ...  see above...  :-/


> I do think it would be best to take those assertions
> out of the patch and to propose them separately, at a later time.

Powered by blists - more mailing lists