Linus,
A few clean ups and bug fixes
- Replace open coded "ARRAY_SIZE()" with macro
- Updates to uprobes
- Bug fix for perf event filter on error path
Please pull the latest ktest-v4.17-2 tree, which can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-ktest.git
ktest-v4.17-2
Tag SHA1: f4a56400c3b9f949cf5740153aab48a8240f88db
Head SHA1: 0b3dec05dbbce023f4f25aba975b5d253c313ebb
Howard McLauchlan (1):
tracing/uprobe: Add support for overlayfs
Jérémy Lefaure (1):
tracing: Use ARRAY_SIZE() macro instead of open coding it
Ravi Bangoria (2):
trace_uprobe: Use %lx to display offset
trace_uprobe: Simplify probes_seq_show()
Steven Rostedt (VMware) (1):
tracing: Enforce passing in filter=NULL to create_filter()
----
kernel/trace/trace_events_filter.c | 26 +++++++++++---------------
kernel/trace/trace_uprobe.c | 23 ++++-------------------
2 files changed, 15 insertions(+), 34 deletions(-)
On Wed, Apr 11, 2018 at 6:53 PM, Steven Rostedt <[email protected]> wrote:
>
> Please pull the latest ktest-v4.17-2 tree, which can be found at:
That doesn't exist, and makes no sense. Did you mean tracing, not ktest?
And even if you did, why did your scripts not notice that the branch
you point to doesn't actually exist?
Linus
On Thu, Apr 12, 2018 at 10:53 AM, Linus Torvalds
<[email protected]> wrote:
>
> That doesn't exist, and makes no sense. Did you mean tracing, not ktest?
Oh, it's more f'ed up than that. That "ktest-v4.17-2" tag does exist -
in the tracing tree.
So the tag is mis-named, but in the right tree, and then your pull
request points at the wrong tree.
Do you want to fix that all up, or should I just pull from that messed-up thing?
Linus
On 04/12/18 14:28, Steven Rostedt wrote:
> That is 4096. I pushed it to the key servers about a half hour ago,
> hopefully, it has made its way around, as I'm going to start using it.
I semi-heartily recommend using an ECDSA key instead (ED25519), because
it will be much faster and we know they work fine for Linus since jejb
uses them to sign his tags. My understanding is that 4096-bit RSA keys
are pretty slow on Nitrokey Start devices.
If you want to stick to RSA instead of the new-fangled ECC (if you can
call a standard from 1980s new-fangled, that is), there is really no
benefit to having a signing subkey stronger than 2048 bits, especially
for the purposes of signing git objects -- which are only as strong as SHA1.
Regards,
--
Konstantin Ryabitsev
Director, IT Infrastructure Security
The Linux Foundation
On Thu, 12 Apr 2018 10:58:21 -0700
Linus Torvalds <[email protected]> wrote:
> On Thu, Apr 12, 2018 at 10:53 AM, Linus Torvalds
> <[email protected]> wrote:
> >
> > That doesn't exist, and makes no sense. Did you mean tracing, not ktest?
>
> Oh, it's more f'ed up than that. That "ktest-v4.17-2" tag does exist -
> in the tracing tree.
>
> So the tag is mis-named, but in the right tree, and then your pull
> request points at the wrong tree.
>
> Do you want to fix that all up, or should I just pull from that messed-up thing?
>
Grumble, no don't pull it. Let me fix it.
That's what I get when I up-arrow commands. I'll retag it and make sure
it's fine, and send you another pull request.
Oh, and I just received my nitrokey and I'm playing with it. One thing
I found is that it doesn't like keys sized 3072 (gives me a bad key
error), which is my current subkey. So I created a new subkey:
Primary key fingerprint: 5ED9 A48F C54C 0A22 D1D0 804C EBC2 6CDB 5A56 DE73
Subkey fingerprint: B5D7 BDD5 67E0 67A3 EE0C 9FBE 3F0B D661 FC59 E3D3
That is 4096. I pushed it to the key servers about a half hour ago,
hopefully, it has made its way around, as I'm going to start using it.
-- Steve
On 04/12/18 15:46, Steven Rostedt wrote:
> On Thu, 12 Apr 2018 14:28:45 -0400
> Steven Rostedt <[email protected]> wrote:
>
>> Primary key fingerprint: 5ED9 A48F C54C 0A22 D1D0 804C EBC2 6CDB 5A56 DE73
>> Subkey fingerprint: B5D7 BDD5 67E0 67A3 EE0C 9FBE 3F0B D661 FC59 E3D3
>
> Don't use this key.
>
> Konstantin wanted me to make a ECC key, which I did. Here's the new key:
>
> Subkey fingerprint: 514B 0EDE 3C38 7F94 4FB3 7993 29E5 7410 9AEB FAAA
Nice!
You don't actually have to tell people the fingerprint, as the subkey
will inherit the trust/validity of your master key. For the recipients,
it's sufficient to just refresh your key:
gpg2 --refresh-key [email protected]
To validate ECC tags, you will need to tell git to always use gpg2,
since gpg1 doesn't know what ECC is:
git config --global gpg.program gpg2
git config --global gpgv.program gpgv2
Regards,
--
Konstantin Ryabitsev
Director, IT Infrastructure Security
The Linux Foundation
On Thu, 12 Apr 2018 14:28:45 -0400
Steven Rostedt <[email protected]> wrote:
> Primary key fingerprint: 5ED9 A48F C54C 0A22 D1D0 804C EBC2 6CDB 5A56 DE73
> Subkey fingerprint: B5D7 BDD5 67E0 67A3 EE0C 9FBE 3F0B D661 FC59 E3D3
Don't use this key.
Konstantin wanted me to make a ECC key, which I did. Here's the new key:
Subkey fingerprint: 514B 0EDE 3C38 7F94 4FB3 7993 29E5 7410 9AEB FAAA
-- Steve