| Message ID | 1511414131.12425.14.camel@gmail.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Thu, Nov 23, 2017 at 10:45:31AM +0530, kaiwan.billimoria@gmail.com wrote: > The current leaking_addresses.pl script only supports showing "leaked" > 64-bit kernel virtual addresses. This patch modifies the "help" screen in the > following manner: > - the '--raw', '--suppress-dmesg', '--squash-by-path' and '--squash-by-filename' > option switches are only meaningful when the '--input-raw=' option switch is > used. So, indent the 'Help' screen lines to reflect the fact. > - an additional example demonstrating usage of the new '--page-offset' > parameter. > > > Feedback welcome.. > > > Signed-off-by: Kaiwan N Billimoria <kaiwan.billimoria@gmail.com> > --- > diff --git a/scripts/leaking_addresses.pl b/scripts/leaking_addresses.pl > index 7ca218221486..3832abb743d7 100755 > --- a/scripts/leaking_addresses.pl > +++ b/scripts/leaking_addresses.pl > @@ -105,10 +105,10 @@ Options: > > -o, --output-raw=<file> Save results for future processing. > -i, --input-raw=<file> Read results from file instead of scanning. > - --raw Show raw results (default). > - --suppress-dmesg Do not show dmesg results. > - --squash-by-path Show one result per unique path. > - --squash-by-filename Show one result per unique filename. > + --raw Show raw results (default). > + --suppress-dmesg Do not show dmesg results. > + --squash-by-path Show one result per unique path. > + --squash-by-filename Show one result per unique filename. > --page-offset=<hex> PAGE_OFFSET value (for 32-bit kernels). > -d, --debug Display debugging output. > -h, --help, --version Display this help and exit. > @@ -124,6 +124,10 @@ Examples: > # View summary report. > $0 --input-raw scan.out --squash-by-filename > > + # (On a 32-bit system with a 2GB:2GB VMSPLIT), pass PAGE_OFFSET value > + # as a parameter > + $0 --page-offset=0x80000000 This should be in the first patch since that is the patch that added it. > + > Scans the running (32 or 64 bit) kernel for potential leaking addresses. > > EOM Neither of these patches applies to my tree. Are you editing the diff's by hand? I noticed the patches don't end with the version signature, like this: ---- 2.7.4 thanks, Tobin.
On Fri, Nov 24, 2017 at 11:29 AM, Tobin C. Harding <me@tobin.cc> wrote: > Neither of these patches applies to my tree. Are you editing the diff's > by hand? I noticed the patches don't end with the version signature, like this: > > ---- > 2.7.4 I cloned your tree from here: https://github.com/tcharding/linux/tree/leaks is that right? One thing i can think of: i have to copy across the script to a cloud-based 32-bit system, work on it there, copy it back to your tree on my laptop manually, then i do the 'git diff -r' and basically copy-paste that. Is this causing issues? thanks, Kaiwan. > thanks, > Tobin.
On Fri, Nov 24, 2017 at 12:51:34PM +0530, Kaiwan N Billimoria wrote: > On Fri, Nov 24, 2017 at 11:29 AM, Tobin C. Harding <me@tobin.cc> wrote: > > > Neither of these patches applies to my tree. Are you editing the diff's > > by hand? I noticed the patches don't end with the version signature, like this: > > > > ---- > > 2.7.4 > > I cloned your tree from here: https://github.com/tcharding/linux/tree/leaks > is that right? If that gets you the tree and the branch then great. I've never done it that way but hey if it works it works. > One thing i can think of: i have to copy across the script to a > cloud-based 32-bit system, work on it there, copy it back to your tree > on my laptop manually, That sounds fine. I'd personally work on it locally, `scp` to the remote host and then run it there. > then i do the 'git diff -r' and basically > copy-paste that. Is this causing issues? There's your problem. I'm no git expert but the format produced by that command is not able to be applied by `git apply` or `git am`. No doubt there is a command to apply it but in ten minutes playing around I couldn't find it. Patches can easily be generated using git format-patch -X where X is the number of commits to include in the patch. You can then apply them to using `git am` or `git apply`. You can in this way verify that your patches apply to the tree/branch of whichever maintainer you are sending the patch to. If you try to patch staging with patches that don't apply you get an automated response saying so, I haven't got that sophisticated yet. Hope this helps, Tobin.
diff --git a/scripts/leaking_addresses.pl b/scripts/leaking_addresses.pl index 7ca218221486..3832abb743d7 100755 --- a/scripts/leaking_addresses.pl +++ b/scripts/leaking_addresses.pl @@ -105,10 +105,10 @@ Options: -o, --output-raw=<file> Save results for future processing. -i, --input-raw=<file> Read results from file instead of scanning. - --raw Show raw results (default). - --suppress-dmesg Do not show dmesg results. - --squash-by-path Show one result per unique path. - --squash-by-filename Show one result per unique filename. + --raw Show raw results (default). + --suppress-dmesg Do not show dmesg results. + --squash-by-path Show one result per unique path. + --squash-by-filename Show one result per unique filename. --page-offset=<hex> PAGE_OFFSET value (for 32-bit kernels). -d, --debug Display debugging output. -h, --help, --version Display this help and exit. @@ -124,6 +124,10 @@ Examples: # View summary report. $0 --input-raw scan.out --squash-by-filename + # (On a 32-bit system with a 2GB:2GB VMSPLIT), pass PAGE_OFFSET value + # as a parameter + $0 --page-offset=0x80000000 + Scans the running (32 or 64 bit) kernel for potential leaking addresses. EOM
The current leaking_addresses.pl script only supports showing "leaked" 64-bit kernel virtual addresses. This patch modifies the "help" screen in the following manner: - the '--raw', '--suppress-dmesg', '--squash-by-path' and '--squash-by-filename' option switches are only meaningful when the '--input-raw=' option switch is used. So, indent the 'Help' screen lines to reflect the fact. - an additional example demonstrating usage of the new '--page-offset' parameter. Feedback welcome.. Signed-off-by: Kaiwan N Billimoria <kaiwan.billimoria@gmail.com> ---