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: <IA1PR11MB6171866D6AEE79DD3413157E897A9@IA1PR11MB6171.namprd11.prod.outlook.com>
Date:   Sat, 13 May 2023 09:52:46 +0000
From:   "Zhuo, Qiuxu" <qiuxu.zhuo@...el.com>
To:     "paulmck@...nel.org" <paulmck@...nel.org>,
        Joel Fernandes <joel@...lfernandes.org>
CC:     "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.
> >
> > Looks good to me as well and thank you both for sharing the tips.
> 
> Here is one way to script this, where "SHA" identifies the commit to be
> checked and PATHS the affected pathnames:
> 
> 	git checkout SHA^
> 	git show SHA | git apply -
> 	git blame -M PATHS | grep '^0* '

Cool ~. Thank you, Paul.  
I took them and made them into a script below for future use ;-)

#!/bin/bash

SHA=$1

if [ -z "$SHA" ]; then
    echo "Usage: $0 <commit-id>"
    exit 1
fi

if ! git cat-file -t "$SHA" &> /dev/null; then
        echo "$SHA does not exist in the repository"
        exit 1
fi

git checkout ${SHA}^ &> /dev/null
git show ${SHA} | git apply - &> /dev/null

PATHS=`git status| grep "modified:" | cut -d: -f2 | xargs`

for P in ${PATHS}; do
        R=`git blame -M $P | grep '^0* '`
        if test -n "$R"; then
                echo "$SHA is NOT a move-only commit"
                exit 1
        fi
done

echo "$SHA is a move-only commit"

> If there is no output, there were no non-move changes.
> 
> Or just do the "git blame -M PATHS | grep '^0* '" before doing the checking.
> 
> And yes, you can derive PATHS using "git status" if you want.  ;-)
> 							Thanx, Paul