[PATCH] vsprintf: fix build warning

[PATCH] vsprintf: fix build warning

[Arnd Bergmann]

The have_filled_random_ptr_key variable was recently removed,
but then reappeared with another patch, presumably after an
incorrect rebase:

lib/vsprintf.c:1668:13: error: 'have_filled_random_ptr_key' defined but not used [-Werror=unused-variable]

This removes it again.

Fixes: 85f4f12d5139 ("vsprintf: Replace memory barrier with static_key for random_ptr_key update")
Fixes: bfe80ed3d7c7 ("vsprintf: add command line option debug_boot_weak_hash")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 lib/vsprintf.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/lib/vsprintf.c b/lib/vsprintf.c
index cdc2c355dff5..5fe18ac4d37c 100644
--- a/lib/vsprintf.c
+++ b/lib/vsprintf.c
@@ -1665,7 +1665,6 @@ static int __init debug_boot_weak_hash_enable(char *str)
 }
 early_param("debug_boot_weak_hash", debug_boot_weak_hash_enable);
 
-static bool have_filled_random_ptr_key __read_mostly;
 static siphash_key_t ptr_key __read_mostly;
 
 static void enable_ptr_key_workfn(struct work_struct *work)
-- 
2.9.0

Re: [PATCH] vsprintf: fix build warning

[Sergey Senozhatsky]

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?

	-ss

Re: [PATCH] vsprintf: fix build warning

[Steven Rostedt]

On Fri, 6 Jul 2018 23:42:13 +0900
Sergey Senozhatsky <sergey.senozhatsky@gmail.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).

As this is just a warning fix, and not something that should break any
bisect, I say keep it separate. Rebases tend to cause issues.

-- Steve

Re: [PATCH] vsprintf: fix build warning

[Petr Mladek]

On Fri 2018-07-06 11:49:51, Steven Rostedt wrote:
> On Fri, 6 Jul 2018 23:42:13 +0900
> Sergey Senozhatsky <sergey.senozhatsky@gmail.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).
> 
> As this is just a warning fix, and not something that should break any
> bisect, I say keep it separate. Rebases tend to cause issues.

Ted, just to be sure, are you going to take it via the random tree,
please?

Best Regards,
Petr

Re: [PATCH] vsprintf: fix build warning

[Tobin C. Harding]

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@gmail.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.

Re: [PATCH] vsprintf: fix build warning

[Tobin C. Harding]

CC'ing kernel newbies for anyone else trying to learn how linux-next
works.

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@gmail.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).

Steve if you do not rebase your next branch and the branch ends up
containing fixes to patches like the above doesn't this mean that when
you do a pull request to Linus the branch you are asking to be pulled
will be too 'dirty' i.e. I thought that the pull request should be like
a patch set and only contain the 'final product' not every change that
was made during development?

I was under the impression that each maintainer constantly rebased their
next branches and that was why one has to checkout the tagged linux-next
each day instead of just pulling.  From information on the net somewhere
I have been checking out linux-next using this shell function

checkout-next () {
	local branch='linux-next' 

	git checkout master
	git remote update linux-next
	git branch -D $branch
	git checkout -b $branch $(git tag -l "next-*" | tail -1)
}

Also, when my leaks tree got included in linux-next I was told that it
was ok to rebase and have since been rebasing mercilessly.


thanks in advance for your time,
Tobin.

Re: [PATCH] vsprintf: fix build warning

[Sergey Senozhatsky]

On (07/10/18 09:42), Tobin C. Harding wrote:
> > 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).
> 
> Steve if you do not rebase your next branch and the branch ends up
> containing fixes to patches like the above doesn't this mean that when
> you do a pull request to Linus the branch you are asking to be pulled
> will be too 'dirty' i.e. I thought that the pull request should be like
> a patch set and only contain the 'final product' not every change that
> was made during development?

+1

	-ss

Re: [PATCH] vsprintf: fix build warning

[Steven Rostedt]

On Tue, 10 Jul 2018 09:42:03 +1000
"Tobin C. Harding" <me@tobin.cc> wrote:

> Steve if you do not rebase your next branch and the branch ends up
> containing fixes to patches like the above doesn't this mean that when
> you do a pull request to Linus the branch you are asking to be pulled
> will be too 'dirty' i.e. I thought that the pull request should be like
> a patch set and only contain the 'final product' not every change that
> was made during development?

Nope, once I push to next, my branch is ready to be worked against.
Sha1 and all. Rebasing will break that. I also have a full test suite
that all my code runs through and it must pass before sending to Linus
or linux-next.

> 
> I was under the impression that each maintainer constantly rebased their
> next branches and that was why one has to checkout the tagged linux-next

Some maintainers (Ingo being one) is very against any unnecessary
rebasing. This is because it can hide the history and development of
code. Linus doesn't like to see rebasing of public trees. Once you
rebase, you lose all the prior testing done on the previous code. It
also makes it difficult for anyone that is basing code off of it.

> each day instead of just pulling.  From information on the net somewhere
> I have been checking out linux-next using this shell function
> 
> checkout-next () {
> 	local branch='linux-next' 
> 
> 	git checkout master
> 	git remote update linux-next
> 	git branch -D $branch
> 	git checkout -b $branch $(git tag -l "next-*" | tail -1)
> }

I believe linux-next itself creates its master branch each time it
pulls in everyone's branches. It throws away the old one, and pulls in
all the new ones. This makes sense because otherwise the history will be
loaded with pulls from various branches. And yes, some branches will
rebase. If just one branch rebases, then it would need to do this.

> 
> Also, when my leaks tree got included in linux-next I was told that it
> was ok to rebase and have since been rebasing mercilessly.

It's really a choice for the maintainer. I consider a branch that goes
into next as "tested". I wont rebase unless there is a nasty bug that I
don't want to go upstream. Or a compiler failure. Warnings don't bother
me. I've sometimes rebased to add Acked-by/Reviewed-by tags. But that's
because the code is identical to what was there before (I do git diffs
to confirm that).

Linus has yelled at people that have rebased just before sending a
pull request to him.

-- Steve

Re: [PATCH] vsprintf: fix build warning

[valdis.kletnieks]

[-- Attachment #1: Type: text/plain, Size: 435 bytes --]

On Tue, 10 Jul 2018 09:42:03 +1000, "Tobin C. Harding" said:

> I was under the impression that each maintainer constantly rebased their
> next branches and that was why one has to checkout the tagged linux-next
> each day instead of just pulling.

Close, but no cigar.  The maintainers don't rebase their -next branches, but
due to the way linux-next merges 200+ trees on top of current Linus tree,
*that* ends up rebasing every day.

[-- Attachment #2: Type: application/pgp-signature, Size: 486 bytes --]