linux-kernel - RE: [PATCH rcu 3/6] rcu/rcuscale: Move rcu_scale_*() after kfree_scale

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <IA1PR11MB6171B1AD7716B95B0B2C683889759@IA1PR11MB6171.namprd11.prod.outlook.com>
Date:   Fri, 12 May 2023 03:20:20 +0000
From:   "Zhuo, Qiuxu" <qiuxu.zhuo@...el.com>
To:     "paulmck@...nel.org" <paulmck@...nel.org>
CC:     Joel Fernandes <joel@...lfernandes.org>,
        "rcu@...r.kernel.org" <rcu@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "kernel-team@...a.com" <kernel-team@...a.com>,
        "rostedt@...dmis.org" <rostedt@...dmis.org>
Subject: RE: [PATCH rcu 3/6] rcu/rcuscale: Move rcu_scale_*() after
 kfree_scale_cleanup()

> From: Paul E. McKenney <paulmck@...nel.org>
> ...
> > > I wish diff was better at showing what really changed. The meld tool
> > > can help but its gui...
> > >
> > > Should I run meld later (I'm out at a conference so no access to
> > > meld-capable
> > > machines) or are we sufficiently confident that the lines were moved
> > > as-is ? :)
> > >
> >
> > Thank you, Joel for this concern. Good to know the meld diff GUI tool.
> > I just run the command below and confirmed that the lines were moved
> > as-is: rcu_scale_{cleanup,shutdown}() follows kfree_scale_cleanup().
> > You may double check it ;-).
> >
> >       meld --diff ./rcuscale.c.before ./rcuscale.c.after
> 
> Nice, thank you both!
> 
> Another option is to check out the commit corresponding to this patch, then
> do "git blame -M kernel/rcu/rcuscale.c".  Given a move-only commit, there
> should be no line tagged with this commit's SHA-1.

Just had a good experiment with the "git blame -M" option: 
- Used this option to prove a move-only commit quickly (no line tagged with that commit) (the fastest method to me). 
- Then just only needed to quickly check the positions of the moved code chunk by myself (easy).  

Thank you, Paul for sharing this. It's very useful to me. 

> They say that another option is to use "git diff --color-moved", which colors
> the changes.  That it does, but I am hard-pressed to work out exactly what
> distinguishes a moved hunk from an added or removed hunk.
> Fall colors vs. winter colors?  Exterior vs. interior?  Any particular decade in
> the endless rush of changes to fashion?  Perhaps someone with normal color
> vision (to say nothing of better fashion sense) could try it.
> 
> On the other hand: "default: Is a synonym for zebra. This may change to a
> more sensible mode in the future."  So maybe it is not just me.  ;-)
> 
> You can also apparently choose colors using "color.diff.newMoved" and
> "color.diff.oldMoved" when using "--color-moved=plain".
> 
> But "git diff --color-moved=dimmed-zebra" might be more to the point for
> someone like me.  I would need to experiment with it more in order to
> confirm my hypotheses about what it is doing.  To say nothing of building

Yup, this looks a bit painful for me too (need experiments to confirm hypotheses ...). 

> trust in it.  Plus I have to open a color terminal to use it effectively.
> So maybe "git blame -M" continues to be the tool for me?
> 
> 							Thanx, Paul