From: Michael Ellerman <mpe@ellerman.id.au>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Ingo Molnar <mingo@kernel.org>, Vlastimil Babka <vbabka@suse.cz>,
linux-kernel@vger.kernel.org, stable@vger.kernel.org,
Dave Hansen <dave.hansen@linux.intel.com>,
Linus Torvalds <torvalds@linux-foundation.org>,
Peter Zijlstra <peterz@infradead.org>,
Thomas Gleixner <tglx@linutronix.de>,
akpm@linux-foundation.org, dave.hansen@intel.com,
linux-mm@kvack.org, linuxram@us.ibm.com, shakeelb@google.com,
shuah@kernel.org, Sasha Levin <alexander.levin@microsoft.com>
Subject: Re: [PATCH 4.16 234/279] x86/pkeys/selftests: Adjust the self-test to fresh distros that export the pkeys ABI
Date: Mon, 09 Jul 2018 13:28:09 +1000 [thread overview]
Message-ID: <87a7r19jg6.fsf@concordia.ellerman.id.au> (raw)
In-Reply-To: <20180708132519.GA29528@kroah.com>
Greg Kroah-Hartman <gregkh@linuxfoundation.org> writes:
> On Sun, Jul 08, 2018 at 08:33:37PM +1000, Michael Ellerman wrote:
...
>>
>> My comment was less about this actual patch and more about the new
>> reality of patches being backported to stable based on Sasha's tooling,
>> which seems to be much more liberal than anything we've done previously.
>>
>> I don't generally have any objection to that process, though it possibly
>> could have been more widely announced. But, it would be good if
>> stable-kernel-rules.txt was updated to mention it.
>>
>> I've had several people ask me "hey my patch got backported to stable
>> but I didn't ask for it - is that OK, what's going on?" etc.
>
> Why didn't those people just ask us? To not do so is very strange, it's
> not like we are hard to find :)
It's not very strange, it's completely normal behaviour. People are
afraid of asking dumb questions in public, so they ask someone
privately.
And the general sentiment has been "I didn't think that patch met the
stable rules, but I'm happy for it to be backported".
>> I guess I should just send a patch to update it, but I don't really know
>> what it should say.
>
> I don't think it really needs any changes, as the selftests is just a
> corner case that is easily explained if anyone cares enough to actually
> ask :)
Yeah again I'm not really concerned about selftests, I should have
replied to a different patch to start this discussion. My bad.
cheers
next prev parent reply other threads:[~2018-07-09 3:28 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20180618080608.851973560@linuxfoundation.org>
2018-06-18 8:13 ` Greg Kroah-Hartman
2018-07-03 11:36 ` Vlastimil Babka
2018-07-03 11:42 ` Greg Kroah-Hartman
2018-07-05 6:03 ` Michael Ellerman
2018-07-05 7:19 ` Ingo Molnar
2018-07-08 10:33 ` Michael Ellerman
2018-07-08 13:25 ` Greg Kroah-Hartman
2018-07-09 3:28 ` Michael Ellerman [this message]
2018-06-18 8:13 ` [PATCH 4.16 235/279] x86/mpx/selftests: Adjust the self-test to fresh distros that export the MPX ABI Greg Kroah-Hartman
2018-06-18 8:13 ` [PATCH 4.16 237/279] x86/pkeys/selftests: Give better unexpected fault error messages Greg Kroah-Hartman
2018-06-18 8:13 ` [PATCH 4.16 238/279] x86/pkeys/selftests: Stop using assert() Greg Kroah-Hartman
2018-06-18 8:13 ` [PATCH 4.16 239/279] x86/pkeys/selftests: Remove dead debugging code, fix dprint_in_signal Greg Kroah-Hartman
2018-06-18 8:13 ` [PATCH 4.16 240/279] x86/pkeys/selftests: Avoid printf-in-signal deadlocks Greg Kroah-Hartman
2018-06-18 8:13 ` [PATCH 4.16 241/279] x86/pkeys/selftests: Allow faults on unknown keys Greg Kroah-Hartman
2018-06-18 8:13 ` [PATCH 4.16 242/279] x86/pkeys/selftests: Factor out "instruction page" Greg Kroah-Hartman
2018-06-18 8:13 ` [PATCH 4.16 243/279] x86/pkeys/selftests: Add PROT_EXEC test Greg Kroah-Hartman
2018-06-18 8:13 ` [PATCH 4.16 244/279] x86/pkeys/selftests: Fix pkey exhaustion test off-by-one Greg Kroah-Hartman
2018-06-18 8:13 ` [PATCH 4.16 245/279] x86/pkeys/selftests: Fix pointer math Greg Kroah-Hartman
2018-06-18 8:13 ` [PATCH 4.16 246/279] x86/pkeys/selftests: Save off prot for allocations Greg Kroah-Hartman
2018-06-18 8:13 ` [PATCH 4.16 247/279] x86/pkeys/selftests: Add a test for pkey 0 Greg Kroah-Hartman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87a7r19jg6.fsf@concordia.ellerman.id.au \
--to=mpe@ellerman.id.au \
--cc=akpm@linux-foundation.org \
--cc=alexander.levin@microsoft.com \
--cc=dave.hansen@intel.com \
--cc=dave.hansen@linux.intel.com \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linuxram@us.ibm.com \
--cc=mingo@kernel.org \
--cc=peterz@infradead.org \
--cc=shakeelb@google.com \
--cc=shuah@kernel.org \
--cc=stable@vger.kernel.org \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.org \
--cc=vbabka@suse.cz \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox