On Thu, 2018-03-29 at 17:13 +0200, Petr Mladek wrote:
> The original simple patch grew into something bigger. I have it
> almost ready. It looks the following way at the moment:
[]
> vsprintf: Factor out %p[iI] handler as ip_addr_string()
> vsprintf: Factor out %pV handler as va_format()
> vs
On Fri 2018-03-02 16:17:34, Andy Shevchenko wrote:
> On Fri, 2018-03-02 at 13:53 +0100, Petr Mladek wrote:
> > %p has many modifiers where the pointer is dereferenced. An invalid
> > pointer might cause kernel to crash silently.
> >
> > Note that printk() formats the string under logbuf_lock. Any
On Fri, Mar 9, 2018 at 7:01 AM, Petr Mladek wrote:
> Also it makes the handling unified. We print:
>
>+ (null) when pure NULL pointer is dereferenced
>+ (efault) when an invalid address is dereferenced
>+ pointer address otherwise
This is still fundamentally completely wrong.
It neve
On Thu 2018-03-08 09:26:11, Linus Torvalds wrote:
> On Thu, Mar 8, 2018 at 8:45 AM, Linus Torvalds
> wrote:
> >
> > Umm. Look again. It _does_ affect plain %p.
> >
> > You're correct that it doesn't affect %px and %pK, since those never
> > printed out (null) in the first place.
> >
> > It not onl
On Thu, Mar 8, 2018 at 8:45 AM, Linus Torvalds
wrote:
>
> Umm. Look again. It _does_ affect plain %p.
>
> You're correct that it doesn't affect %px and %pK, since those never
> printed out (null) in the first place.
>
> It not only affects %p, but it also affects %pS and friends (sSfFB),
Looking
On Thu, Mar 8, 2018 at 6:18 AM, Petr Mladek wrote:
> On Wed 2018-03-07 10:34:17, Linus Torvalds wrote:
>>
>> Guess what happens now to any crash report if it uses %p and there is
>> anything wrong with the VM?
>
> This patch does _not_ affect plain %p, %px, and %pK!
Umm. Look again. It _does_ aff
On Wed 2018-03-07 10:34:17, Linus Torvalds wrote:
> On Wed, Mar 7, 2018 at 7:52 AM, Petr Mladek wrote:
> > If we are changing things, let's do it properly. The range
> > (-PAGE_SIZE,+PAGE_SIZE) is just a small subset of invalid pointers.
> > Let's try to catch more of them by reading one byte usin
On Wed, Mar 7, 2018 at 7:52 AM, Petr Mladek wrote:
> If we are changing things, let's do it properly. The range
> (-PAGE_SIZE,+PAGE_SIZE) is just a small subset of invalid pointers.
> Let's try to catch more of them by reading one byte using
> probe_kernel_read(). It would return -FAULT if we are
On Wed, 2018-03-07 at 16:52 +0100, Petr Mladek wrote:
> On Tue 2018-03-06 11:56:25, Andy Shevchenko wrote:
> Anyway, I have discussed this with my colleagues. Different people had
> different opinions. But I liked the following.
I discussed as well, and...
> We already prevent crash when derefen
On Tue 2018-03-06 11:56:25, Andy Shevchenko wrote:
> On Tue, 2018-03-06 at 10:25 +0100, Petr Mladek wrote:
> > On Mon 2018-03-05 16:16:37, Rasmus Villemoes wrote:
> > > On 2 March 2018 at 13:53, Petr Mladek wrote:
>
> > > > - if (!ptr && *fmt != 'K' && *fmt != 'x') {
> > > > + if ((un
On Tue, 2018-03-06 at 10:25 +0100, Petr Mladek wrote:
> On Mon 2018-03-05 16:16:37, Rasmus Villemoes wrote:
> > On 2 March 2018 at 13:53, Petr Mladek wrote:
> > > - if (!ptr && *fmt != 'K' && *fmt != 'x') {
> > > + if ((unsigned long)ptr < PAGE_SIZE && *fmt != 'K' && *fmt
> > > != 'x'
On Mon 2018-03-05 16:16:37, Rasmus Villemoes wrote:
> On 2 March 2018 at 13:53, Petr Mladek wrote:
> > %p has many modifiers where the pointer is dereferenced. An invalid
> > pointer might cause kernel to crash silently.
> >
> > Note that printk() formats the string under logbuf_lock. Any recursiv
On Mon, 2018-03-05 at 16:16 +0100, Rasmus Villemoes wrote:
> On 2 March 2018 at 13:53, Petr Mladek wrote:
> > - if (!ptr && *fmt != 'K' && *fmt != 'x') {
> > + if ((unsigned long)ptr < PAGE_SIZE && *fmt != 'K' && *fmt !=
> > 'x') {
>
> ISTM that accidentally passing an ERR_PTR would
On 2 March 2018 at 13:53, Petr Mladek wrote:
> %p has many modifiers where the pointer is dereferenced. An invalid
> pointer might cause kernel to crash silently.
>
> Note that printk() formats the string under logbuf_lock. Any recursive
> printks are redirected to the printk_safe implementation a
On Fri 2018-03-02 16:17:34, Andy Shevchenko wrote:
> On Fri, 2018-03-02 at 13:53 +0100, Petr Mladek wrote:
> > %p has many modifiers where the pointer is dereferenced. An invalid
> > pointer might cause kernel to crash silently.
> >
> > Note that printk() formats the string under logbuf_lock. Any
On Fri, 2018-03-02 at 13:53 +0100, Petr Mladek wrote:
> %p has many modifiers where the pointer is dereferenced. An invalid
> pointer might cause kernel to crash silently.
>
> Note that printk() formats the string under logbuf_lock. Any recursive
> printks are redirected to the printk_safe impleme
%p has many modifiers where the pointer is dereferenced. An invalid
pointer might cause kernel to crash silently.
Note that printk() formats the string under logbuf_lock. Any recursive
printks are redirected to the printk_safe implementation and the messages
are stored into per-CPU buffers. These
17 matches
Mail list logo