linux-kernel - Re: [PATCH] vsprintf: fix build warning

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: <20180709231528.GF4447@eros>
Date:   Tue, 10 Jul 2018 09:15:28 +1000
From:   "Tobin C. Harding" <me@...in.cc>
To:     Steven Rostedt <rostedt@...dmis.org>
Cc:     Sergey Senozhatsky <sergey.senozhatsky@...il.com>,
        Arnd Bergmann <arnd@...db.de>, Petr Mladek <pmladek@...e.com>,
        Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
        Theodore Ts'o <tytso@....edu>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] vsprintf: fix build warning

On Fri, Jul 06, 2018 at 11:49:51AM -0400, Steven Rostedt wrote:
> On Fri, 6 Jul 2018 23:42:13 +0900
> Sergey Senozhatsky <sergey.senozhatsky@...il.com> wrote:
> 
> > On (07/06/18 15:47), Arnd Bergmann wrote:
> > [..]
> > > Fixes: bfe80ed3d7c7 ("vsprintf: add command line option debug_boot_weak_hash")  
> > 
> > Seems like this one is still in linux-next.
> > Can we squash this patch and bfe80ed3d7c7?
> > 
> 
> I prefer not to do squashes unless absolutely necessary. Yes, it is in
> next, but even branches pulled into next should try to resist rebasing
> (I never rebase my next branch unless there is a real bug that will
> break bisecting).

So this seems to be my fault.  I was under the impression that next
branches were rebased.  This warning was introduced in v7 of my patch
set applied by Ted to his random tree.  The build warning issue was
found by the kbuild test bot and based on my _incorrect_ understanding
of how linux-next worked I implemented the fix and _incremented_ the
version number of the original patch set thinking Ted would rebase
random-next and apply the latest version.

I now see that I should have done a new patch set on top of
random-next.  Thanks for fixing this Arnd, it helped me notice that the
other code changes in the final version of that patch set didn't make it
in :)

thanks,
Tobin.