On Tue 2018-04-03 16:40:58, Andy Shevchenko wrote:
> On Tue, 2018-04-03 at 15:13 +0200, Petr Mladek wrote:
> > On Tue 2018-04-03 14:54:18, Andy Shevchenko wrote:
> > > On Tue, 2018-04-03 at 13:46 +0200, Petr Mladek wrote:
> > > > On Mon 2018-04-02 17:15:23, Andy Shevchenko wrote:
> > > We have a
On Tue 2018-04-03 16:40:58, Andy Shevchenko wrote:
> On Tue, 2018-04-03 at 15:13 +0200, Petr Mladek wrote:
> > On Tue 2018-04-03 14:54:18, Andy Shevchenko wrote:
> > > On Tue, 2018-04-03 at 13:46 +0200, Petr Mladek wrote:
> > > > On Mon 2018-04-02 17:15:23, Andy Shevchenko wrote:
> > > We have a
On (04/03/18 13:52), Petr Mladek wrote:
> On Tue 2018-04-03 10:12:37, Sergey Senozhatsky wrote:
> > On (04/02/18 17:15), Andy Shevchenko wrote:
> > > >
> > > > Hmm, I have never seen the error code in this form.
> > >
> > > We have limited space to print it and error numbers currently can be up
On (04/03/18 13:52), Petr Mladek wrote:
> On Tue 2018-04-03 10:12:37, Sergey Senozhatsky wrote:
> > On (04/02/18 17:15), Andy Shevchenko wrote:
> > > >
> > > > Hmm, I have never seen the error code in this form.
> > >
> > > We have limited space to print it and error numbers currently can be up
On Tue, 2018-04-03 at 15:13 +0200, Petr Mladek wrote:
> On Tue 2018-04-03 14:54:18, Andy Shevchenko wrote:
> > On Tue, 2018-04-03 at 13:46 +0200, Petr Mladek wrote:
> > > On Mon 2018-04-02 17:15:23, Andy Shevchenko wrote:
> > > > On Thu, 2018-03-29 at 16:53 +0200, Petr Mladek wrote:
> > > > > On
On Tue, 2018-04-03 at 15:13 +0200, Petr Mladek wrote:
> On Tue 2018-04-03 14:54:18, Andy Shevchenko wrote:
> > On Tue, 2018-04-03 at 13:46 +0200, Petr Mladek wrote:
> > > On Mon 2018-04-02 17:15:23, Andy Shevchenko wrote:
> > > > On Thu, 2018-03-29 at 16:53 +0200, Petr Mladek wrote:
> > > > > On
On Tue 2018-04-03 14:54:18, Andy Shevchenko wrote:
> On Tue, 2018-04-03 at 13:46 +0200, Petr Mladek wrote:
> > On Mon 2018-04-02 17:15:23, Andy Shevchenko wrote:
> > > On Thu, 2018-03-29 at 16:53 +0200, Petr Mladek wrote:
> > > > On Fri 2018-03-16 20:19:35, Andy Shevchenko wrote:
> > > > > On Thu,
On Tue 2018-04-03 14:54:18, Andy Shevchenko wrote:
> On Tue, 2018-04-03 at 13:46 +0200, Petr Mladek wrote:
> > On Mon 2018-04-02 17:15:23, Andy Shevchenko wrote:
> > > On Thu, 2018-03-29 at 16:53 +0200, Petr Mladek wrote:
> > > > On Fri 2018-03-16 20:19:35, Andy Shevchenko wrote:
> > > > > On Thu,
On Tue, 2018-04-03 at 13:52 +0200, Petr Mladek wrote:
> On Tue 2018-04-03 10:12:37, Sergey Senozhatsky wrote:
> > On (04/02/18 17:15), Andy Shevchenko wrote:
> > > >
> > > > Hmm, I have never seen the error code in this form.
> > >
> > > We have limited space to print it and error numbers
On Tue, 2018-04-03 at 13:52 +0200, Petr Mladek wrote:
> On Tue 2018-04-03 10:12:37, Sergey Senozhatsky wrote:
> > On (04/02/18 17:15), Andy Shevchenko wrote:
> > > >
> > > > Hmm, I have never seen the error code in this form.
> > >
> > > We have limited space to print it and error numbers
On Tue, 2018-04-03 at 13:46 +0200, Petr Mladek wrote:
> On Mon 2018-04-02 17:15:23, Andy Shevchenko wrote:
> > On Thu, 2018-03-29 at 16:53 +0200, Petr Mladek wrote:
> > > On Fri 2018-03-16 20:19:35, Andy Shevchenko wrote:
> > > > On Thu, 2018-03-15 at 16:26 +0100, Petr Mladek wrote:
> > > > > On
On Tue, 2018-04-03 at 13:46 +0200, Petr Mladek wrote:
> On Mon 2018-04-02 17:15:23, Andy Shevchenko wrote:
> > On Thu, 2018-03-29 at 16:53 +0200, Petr Mladek wrote:
> > > On Fri 2018-03-16 20:19:35, Andy Shevchenko wrote:
> > > > On Thu, 2018-03-15 at 16:26 +0100, Petr Mladek wrote:
> > > > > On
On Tue 2018-04-03 10:12:37, Sergey Senozhatsky wrote:
> On (04/02/18 17:15), Andy Shevchenko wrote:
> > >
> > > Hmm, I have never seen the error code in this form.
> >
> > We have limited space to print it and error numbers currently can be up
> > to 0xfff (4095). So, I have no better idea how
On Tue 2018-04-03 10:12:37, Sergey Senozhatsky wrote:
> On (04/02/18 17:15), Andy Shevchenko wrote:
> > >
> > > Hmm, I have never seen the error code in this form.
> >
> > We have limited space to print it and error numbers currently can be up
> > to 0xfff (4095). So, I have no better idea how
On Mon 2018-04-02 17:15:23, Andy Shevchenko wrote:
> On Thu, 2018-03-29 at 16:53 +0200, Petr Mladek wrote:
> > On Fri 2018-03-16 20:19:35, Andy Shevchenko wrote:
> > > On Thu, 2018-03-15 at 16:26 +0100, Petr Mladek wrote:
> > > > On Thu 2018-03-15 15:09:03, Andy Shevchenko wrote:
>
> > > > > I
On Mon 2018-04-02 17:15:23, Andy Shevchenko wrote:
> On Thu, 2018-03-29 at 16:53 +0200, Petr Mladek wrote:
> > On Fri 2018-03-16 20:19:35, Andy Shevchenko wrote:
> > > On Thu, 2018-03-15 at 16:26 +0100, Petr Mladek wrote:
> > > > On Thu 2018-03-15 15:09:03, Andy Shevchenko wrote:
>
> > > > > I
On (04/02/18 17:15), Andy Shevchenko wrote:
> >
> > Hmm, I have never seen the error code in this form.
>
> We have limited space to print it and error numbers currently can be up
> to 0xfff (4095). So, I have no better idea how to squeeze them while
> thinking that "(efault)" is much harder to
On (04/02/18 17:15), Andy Shevchenko wrote:
> >
> > Hmm, I have never seen the error code in this form.
>
> We have limited space to print it and error numbers currently can be up
> to 0xfff (4095). So, I have no better idea how to squeeze them while
> thinking that "(efault)" is much harder to
On Thu, 2018-03-29 at 16:53 +0200, Petr Mladek wrote:
> On Fri 2018-03-16 20:19:35, Andy Shevchenko wrote:
> > On Thu, 2018-03-15 at 16:26 +0100, Petr Mladek wrote:
> > > On Thu 2018-03-15 15:09:03, Andy Shevchenko wrote:
> > > > I still think that printing a hex value of the error code is
> > >
On Thu, 2018-03-29 at 16:53 +0200, Petr Mladek wrote:
> On Fri 2018-03-16 20:19:35, Andy Shevchenko wrote:
> > On Thu, 2018-03-15 at 16:26 +0100, Petr Mladek wrote:
> > > On Thu 2018-03-15 15:09:03, Andy Shevchenko wrote:
> > > > I still think that printing a hex value of the error code is
> > >
On Fri 2018-03-16 20:19:35, Andy Shevchenko wrote:
> On Thu, 2018-03-15 at 16:26 +0100, Petr Mladek wrote:
> > On Thu 2018-03-15 15:09:03, Andy Shevchenko wrote:
> > > On Wed, 2018-03-14 at 15:09 +0100, Petr Mladek wrote:
> > > > We already prevent crash when dereferencing some obviously broken
>
On Fri 2018-03-16 20:19:35, Andy Shevchenko wrote:
> On Thu, 2018-03-15 at 16:26 +0100, Petr Mladek wrote:
> > On Thu 2018-03-15 15:09:03, Andy Shevchenko wrote:
> > > On Wed, 2018-03-14 at 15:09 +0100, Petr Mladek wrote:
> > > > We already prevent crash when dereferencing some obviously broken
>
On (03/16/18 09:55), Petr Mladek wrote:
[..]
> I am not sure if it is worth it. I think that we would catch 99% of
> problems by checking the first byte.
>
> This patch was motivated by a code clean up rather than bug reports.
OK. Then I think we really need this "the patch is just good enough"
On (03/16/18 09:55), Petr Mladek wrote:
[..]
> I am not sure if it is worth it. I think that we would catch 99% of
> problems by checking the first byte.
>
> This patch was motivated by a code clean up rather than bug reports.
OK. Then I think we really need this "the patch is just good enough"
On Thu, 2018-03-15 at 16:26 +0100, Petr Mladek wrote:
> On Thu 2018-03-15 15:09:03, Andy Shevchenko wrote:
> > On Wed, 2018-03-14 at 15:09 +0100, Petr Mladek wrote:
> > > We already prevent crash when dereferencing some obviously broken
> > > pointers. But the handling is not consistent. Sometimes
On Thu, 2018-03-15 at 16:26 +0100, Petr Mladek wrote:
> On Thu 2018-03-15 15:09:03, Andy Shevchenko wrote:
> > On Wed, 2018-03-14 at 15:09 +0100, Petr Mladek wrote:
> > > We already prevent crash when dereferencing some obviously broken
> > > pointers. But the handling is not consistent. Sometimes
On Fri, 16 Mar 2018 09:55:56 +0100
Petr Mladek wrote:
> I am not sure if it is worth it. I think that we would catch 99% of
> problems by checking the first byte.
Then it should be commented as such. Something like:
/*
* This is not a fool-proof test. 99.9% of the time
On Fri, 16 Mar 2018 09:55:56 +0100
Petr Mladek wrote:
> I am not sure if it is worth it. I think that we would catch 99% of
> problems by checking the first byte.
Then it should be commented as such. Something like:
/*
* This is not a fool-proof test. 99.9% of the time that this will
*
On Fri 2018-03-16 14:53:46, Sergey Senozhatsky wrote:
> On (03/15/18 18:35), Linus Torvalds wrote:
> > On Thu, Mar 15, 2018 at 6:18 PM, Sergey Senozhatsky
> > wrote:
> > >
> > > Hm, may be sizeof(ptr) still won't suffice. It would be great if we
> > > could
On Fri 2018-03-16 14:53:46, Sergey Senozhatsky wrote:
> On (03/15/18 18:35), Linus Torvalds wrote:
> > On Thu, Mar 15, 2018 at 6:18 PM, Sergey Senozhatsky
> > wrote:
> > >
> > > Hm, may be sizeof(ptr) still won't suffice. It would be great if we
> > > could always look at spec.field_width, which
On (03/15/18 18:35), Linus Torvalds wrote:
> On Thu, Mar 15, 2018 at 6:18 PM, Sergey Senozhatsky
> wrote:
> >
> > Hm, may be sizeof(ptr) still won't suffice. It would be great if we
> > could always look at spec.field_width, which can be up to 2 * sizeof(void
>
On (03/15/18 18:35), Linus Torvalds wrote:
> On Thu, Mar 15, 2018 at 6:18 PM, Sergey Senozhatsky
> wrote:
> >
> > Hm, may be sizeof(ptr) still won't suffice. It would be great if we
> > could always look at spec.field_width, which can be up to 2 * sizeof(void
> > *),
> > and then just
On Thu, Mar 15, 2018 at 6:18 PM, Sergey Senozhatsky
wrote:
>
> Hm, may be sizeof(ptr) still won't suffice. It would be great if we
> could always look at spec.field_width, which can be up to 2 * sizeof(void *),
> and then just
On Thu, Mar 15, 2018 at 6:18 PM, Sergey Senozhatsky
wrote:
>
> Hm, may be sizeof(ptr) still won't suffice. It would be great if we
> could always look at spec.field_width, which can be up to 2 * sizeof(void *),
> and then just probe_kernel_read(spec.field_width). E.g., %b/%bl prints out a
>
On (03/15/18 13:01), Steven Rostedt wrote:
> > > > +static const char *check_pointer_access(const void *ptr)
> > > > +{
> > > > + unsigned char byte;
> > > > +
> > > > + if (!ptr)
> > > > + return "(null)";
> > > > +
> > > > + if (probe_kernel_read(, ptr, 1))
> >
On (03/15/18 13:01), Steven Rostedt wrote:
> > > > +static const char *check_pointer_access(const void *ptr)
> > > > +{
> > > > + unsigned char byte;
> > > > +
> > > > + if (!ptr)
> > > > + return "(null)";
> > > > +
> > > > + if (probe_kernel_read(, ptr, 1))
> >
Hi Petr,
I love your patch! Perhaps something to improve:
[auto build test WARNING on linus/master]
[also build test WARNING on v4.16-rc5 next-20180314]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
Hi Petr,
I love your patch! Perhaps something to improve:
[auto build test WARNING on linus/master]
[also build test WARNING on v4.16-rc5 next-20180314]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
On Thu, 15 Mar 2018 16:07:54 +0100
Petr Mladek wrote:
> Good point. The following should do the job:
>
> static const char *check_pointer_access(const void *ptr)
> {
> char c;
>
> if (!ptr)
> return "(null)";
>
> if ((unsigned long)ptr <
On Thu, 15 Mar 2018 16:07:54 +0100
Petr Mladek wrote:
> Good point. The following should do the job:
>
> static const char *check_pointer_access(const void *ptr)
> {
> char c;
>
> if (!ptr)
> return "(null)";
>
> if ((unsigned long)ptr < TASK_SIZE ||
On Wed, 14 Mar 2018 23:12:36 +0100
Rasmus Villemoes wrote:
> Question: probe_kernel_read seems to allow (mapped) userspace addresses.
> Is that really what we want? Sure, some %p* just format the pointed-to
> bytes directly (as an IP address or raw hex dump or whatnot),
On Wed, 14 Mar 2018 23:12:36 +0100
Rasmus Villemoes wrote:
> Question: probe_kernel_read seems to allow (mapped) userspace addresses.
> Is that really what we want? Sure, some %p* just format the pointed-to
> bytes directly (as an IP address or raw hex dump or whatnot), but some
> (e.g. %pD, and
On Thu, 15 Mar 2018 17:03:09 +0900
Sergey Senozhatsky wrote:
> On (03/15/18 16:58), Sergey Senozhatsky wrote:
> > On (03/14/18 15:09), Petr Mladek wrote:
> > [..]
> > > +static const char *check_pointer_access(const void *ptr)
> > > +{
> > > + unsigned char
On Thu, 15 Mar 2018 17:03:09 +0900
Sergey Senozhatsky wrote:
> On (03/15/18 16:58), Sergey Senozhatsky wrote:
> > On (03/14/18 15:09), Petr Mladek wrote:
> > [..]
> > > +static const char *check_pointer_access(const void *ptr)
> > > +{
> > > + unsigned char byte;
> > > +
> > > + if (!ptr)
> >
On Thu 2018-03-15 15:09:03, Andy Shevchenko wrote:
> On Wed, 2018-03-14 at 15:09 +0100, Petr Mladek wrote:
> > We already prevent crash when dereferencing some obviously broken
> > pointers. But the handling is not consistent. Sometimes we print
> > "(null)"
> > only for pure NULL pointer,
On Thu 2018-03-15 15:09:03, Andy Shevchenko wrote:
> On Wed, 2018-03-14 at 15:09 +0100, Petr Mladek wrote:
> > We already prevent crash when dereferencing some obviously broken
> > pointers. But the handling is not consistent. Sometimes we print
> > "(null)"
> > only for pure NULL pointer,
On Wed 2018-03-14 23:12:36, Rasmus Villemoes wrote:
> On 2018-03-14 15:09, Petr Mladek wrote:
>
> > diff --git a/lib/test_printf.c b/lib/test_printf.c
> > index 71ebfa43ad05..61c05a352d79 100644
> > --- a/lib/test_printf.c
> > +++ b/lib/test_printf.c
> > @@ -207,14 +207,15 @@ test_string(void)
>
On Wed 2018-03-14 23:12:36, Rasmus Villemoes wrote:
> On 2018-03-14 15:09, Petr Mladek wrote:
>
> > diff --git a/lib/test_printf.c b/lib/test_printf.c
> > index 71ebfa43ad05..61c05a352d79 100644
> > --- a/lib/test_printf.c
> > +++ b/lib/test_printf.c
> > @@ -207,14 +207,15 @@ test_string(void)
>
Hi Petr,
I love your patch! Yet something to improve:
[auto build test ERROR on linus/master]
[also build test ERROR on v4.16-rc5 next-20180314]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
Hi Petr,
I love your patch! Yet something to improve:
[auto build test ERROR on linus/master]
[also build test ERROR on v4.16-rc5 next-20180314]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
On Wed, 2018-03-14 at 15:09 +0100, Petr Mladek wrote:
> We already prevent crash when dereferencing some obviously broken
> pointers. But the handling is not consistent. Sometimes we print
> "(null)"
> only for pure NULL pointer, sometimes for pointers in the first
> page and
> sometimes also
On Wed, 2018-03-14 at 15:09 +0100, Petr Mladek wrote:
> We already prevent crash when dereferencing some obviously broken
> pointers. But the handling is not consistent. Sometimes we print
> "(null)"
> only for pure NULL pointer, sometimes for pointers in the first
> page and
> sometimes also
On Thu, 2018-03-15 at 16:58 +0900, Sergey Senozhatsky wrote:
> On (03/14/18 15:09), Petr Mladek wrote:
>
> > char *pointer(const char *fmt, char *buf, char *end, void *ptr,
> > struct printf_spec spec)
> > {
> > + static const char data_access_fmt[] =
> > "RrhbMmIiEUVNadCDgGO";
>
On Thu, 2018-03-15 at 16:58 +0900, Sergey Senozhatsky wrote:
> On (03/14/18 15:09), Petr Mladek wrote:
>
> > char *pointer(const char *fmt, char *buf, char *end, void *ptr,
> > struct printf_spec spec)
> > {
> > + static const char data_access_fmt[] =
> > "RrhbMmIiEUVNadCDgGO";
>
On (03/15/18 16:58), Sergey Senozhatsky wrote:
> On (03/14/18 15:09), Petr Mladek wrote:
> [..]
> > +static const char *check_pointer_access(const void *ptr)
> > +{
> > + unsigned char byte;
> > +
> > + if (!ptr)
> > + return "(null)";
> > +
> > + if (probe_kernel_read(, ptr, 1))
>
On (03/15/18 16:58), Sergey Senozhatsky wrote:
> On (03/14/18 15:09), Petr Mladek wrote:
> [..]
> > +static const char *check_pointer_access(const void *ptr)
> > +{
> > + unsigned char byte;
> > +
> > + if (!ptr)
> > + return "(null)";
> > +
> > + if (probe_kernel_read(, ptr, 1))
>
On (03/14/18 15:09), Petr Mladek wrote:
[..]
> +static const char *check_pointer_access(const void *ptr)
> +{
> + unsigned char byte;
> +
> + if (!ptr)
> + return "(null)";
> +
> + if (probe_kernel_read(, ptr, 1))
^
Why one byte?
On (03/14/18 15:09), Petr Mladek wrote:
[..]
> +static const char *check_pointer_access(const void *ptr)
> +{
> + unsigned char byte;
> +
> + if (!ptr)
> + return "(null)";
> +
> + if (probe_kernel_read(, ptr, 1))
^
Why one byte?
On (03/14/18 15:09), Petr Mladek wrote:
> Changes against v2:
>
> + fix handling with strchr(string, '\0'); happens with
> %p at the very end of the string
> + even more clear commit message
> + update Documentation/core-api/printk-formats.rst
> + add check into
On (03/14/18 15:09), Petr Mladek wrote:
> Changes against v2:
>
> + fix handling with strchr(string, '\0'); happens with
> %p at the very end of the string
> + even more clear commit message
> + update Documentation/core-api/printk-formats.rst
> + add check into
On 2018-03-14 15:09, Petr Mladek wrote:
> diff --git a/lib/test_printf.c b/lib/test_printf.c
> index 71ebfa43ad05..61c05a352d79 100644
> --- a/lib/test_printf.c
> +++ b/lib/test_printf.c
> @@ -207,14 +207,15 @@ test_string(void)
> @@ -256,18 +259,18 @@ plain_hash(void)
> * after an address is
On 2018-03-14 15:09, Petr Mladek wrote:
> diff --git a/lib/test_printf.c b/lib/test_printf.c
> index 71ebfa43ad05..61c05a352d79 100644
> --- a/lib/test_printf.c
> +++ b/lib/test_printf.c
> @@ -207,14 +207,15 @@ test_string(void)
> @@ -256,18 +259,18 @@ plain_hash(void)
> * after an address is
We already prevent crash when dereferencing some obviously broken
pointers. But the handling is not consistent. Sometimes we print "(null)"
only for pure NULL pointer, sometimes for pointers in the first
page and sometimes also for pointers in the last page (error codes).
Note that printk() call
We already prevent crash when dereferencing some obviously broken
pointers. But the handling is not consistent. Sometimes we print "(null)"
only for pure NULL pointer, sometimes for pointers in the first
page and sometimes also for pointers in the last page (error codes).
Note that printk() call
64 matches
Mail list logo