On 2/10/21 5:11 AM, Marco Elver wrote:
I wanted to test this for deciding if we can show sensitive info in
KFENCE reports, which works just fine now that debug_never_hash_pointers
is non-static. FWIW,
Acked-by: Marco Elver
Thank you.
But unfortunately this series broke some other
On 2021/02/11 1:54, Andy Shevchenko wrote:
> On Thu, Feb 11, 2021 at 01:39:41AM +0900, Tetsuo Handa wrote:
>> On 2021/02/11 1:18, Steven Rostedt wrote:
>>> The point of this exercise is to be able to debug the *same* kernel that
>>> someone is having issues with. And this is to facilitate that
On Thu, 11 Feb 2021 02:07:21 +0900
Tetsuo Handa wrote:
> I'm not refusing to use kernel command line options. I'm expecting that we can
> also hardcode using kernel config options. Since boot-time switching via
> kernel
> command line options makes the kernel behave differently, less boot-time
On 2/10/21 10:46 AM, Steven Rostedt wrote:
Now the question is, why do you need the unhashed pointer?
Currently, the instruction pointer is what is fine right? You get the
a function and its offset. If there's something that is needed, perhaps we
should look at how to fix that, instead of
On 2021/02/11 1:46, Steven Rostedt wrote:
> On Thu, 11 Feb 2021 01:39:41 +0900
> Tetsuo Handa wrote:
>
>> On 2021/02/11 1:18, Steven Rostedt wrote:
>>> The point of this exercise is to be able to debug the *same* kernel that
>>> someone is having issues with. And this is to facilitate that
On Thu, Feb 11, 2021 at 01:39:41AM +0900, Tetsuo Handa wrote:
> On 2021/02/11 1:18, Steven Rostedt wrote:
> > The point of this exercise is to be able to debug the *same* kernel that
> > someone is having issues with. And this is to facilitate that debugging.
>
> That's too difficult to use. If a
On 2/10/21 5:47 AM, Andy Shevchenko wrote:
It's a bit hard in some mailers (like Gmail) to see the different
versions of your patches.
Can you use in the future
- either `git format-patch -v ...`, where is a version
- or `git format-patch --subject-prefix="PATCH vX / RESEND / etc" ...`
?
On Thu, 11 Feb 2021 01:39:41 +0900
Tetsuo Handa wrote:
> On 2021/02/11 1:18, Steven Rostedt wrote:
> > The point of this exercise is to be able to debug the *same* kernel that
> > someone is having issues with. And this is to facilitate that debugging.
>
> That's too difficult to use. If a
On 2021/02/11 1:18, Steven Rostedt wrote:
> The point of this exercise is to be able to debug the *same* kernel that
> someone is having issues with. And this is to facilitate that debugging.
That's too difficult to use. If a problem is not reproducible, we will have
no choice but always specify
On Thu, 11 Feb 2021 00:46:15 +0900
Tetsuo Handa wrote:
> Oh, I was wishing
>
> diff --git a/lib/vsprintf.c b/lib/vsprintf.c
> index 3b53c73580c5..34c7e145ac3c 100644
> --- a/lib/vsprintf.c
> +++ b/lib/vsprintf.c
> @@ -802,7 +802,7 @@ static char *ptr_to_id(char *buf, char *end, const void
>
On 2021/02/10 14:18, Timur Tabi wrote:
> [accidentally sent from the wrong email address, so resending]
>
> [The list of email addresses on CC: is getting quite lengthy,
> so I hope I've included everyone.]
>
> Although hashing addresses printed via printk does make the
> kernel more secure, it
On Wed, Feb 10, 2021 at 10:33 AM Timur Tabi wrote:
>
> [accidentally sent from the wrong email address, so resending]
>
> [The list of email addresses on CC: is getting quite lengthy,
> so I hope I've included everyone.]
>
> Although hashing addresses printed via printk does make the
> kernel
On Tue, Feb 09, 2021 at 11:18PM -0600, Timur Tabi wrote:
> [accidentally sent from the wrong email address, so resending]
>
> [The list of email addresses on CC: is getting quite lengthy,
> so I hope I've included everyone.]
>
> Although hashing addresses printed via printk does make the
>
[accidentally sent from the wrong email address, so resending]
[The list of email addresses on CC: is getting quite lengthy,
so I hope I've included everyone.]
Although hashing addresses printed via printk does make the
kernel more secure, it interferes with debugging, especially
with some
14 matches
Mail list logo