All of lore.kernel.org
 help / color / mirror / Atom feed
From: Petr Mladek <pmladek@suse.com>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>,
	David Laight <David.Laight@aculab.com>,
	Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>,
	Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
	christophe leroy <christophe.leroy@c-s.fr>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Rasmus Villemoes <linux@rasmusvillemoes.dk>,
	"Tobin C . Harding" <me@tobin.cc>, Michal Hocko <mhocko@suse.cz>,
	Sergey Senozhatsky <sergey.senozhatsky@gmail.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Michael Ellerman <mpe@ellerman.id.au>,
	"linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>,
	Russell Currey <ruscur@russell.cc>,
	Stephen Rothwell <sfr@ozlabs.org>,
	Heiko Carstens <heiko.carstens@de.ibm.com>,
	"linux-arch@vger.kernel.org" <linux-arch@vger.kernel.org>,
	"linux-s390@vger.kernel.org" <linux-s390@vger.kernel.org>,
	Martin Schwidefsky <schwidefsky@de.ibm.com>
Subject: Re: [PATCH] vsprintf: Do not break early boot with probing addresses
Date: Wed, 15 May 2019 09:35:42 +0200	[thread overview]
Message-ID: <20190515073542.y6ru2nfagtcrpdl7@pathway.suse.cz> (raw)
In-Reply-To: <20190514143751.48e81e05@oasis.local.home>

On Tue 2019-05-14 14:37:51, Steven Rostedt wrote:
> 
> [ Purple is a nice shade on the bike shed. ;-) ]
> 
> On Tue, 14 May 2019 11:02:17 +0200
> Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> 
> > On Tue, May 14, 2019 at 10:29 AM David Laight <David.Laight@aculab.com> wrote:
> > > > And I like Steven's "(fault)" idea.
> > > > How about this:
> > > >
> > > >       if ptr < PAGE_SIZE              -> "(null)"
> > > >       if IS_ERR_VALUE(ptr)            -> "(fault)"
> > > >
> > > >       -ss  
> > >
> > > Or:
> > >         if (ptr < PAGE_SIZE)
> > >                 return ptr ? "(null+)" : "(null)";
> 
> Hmm, that is useful.
> 
> > >         if IS_ERR_VALUE(ptr)
> > >                 return "(errno)"  
> 
> I still prefer "(fault)" as is pretty much all I would expect from a
> pointer dereference, even if it is just bad parsing of, say, a parsing
> an MAC address. "fault" is generic enough. "errno" will be confusing,
> because that's normally a variable not a output.
> 
> > 
> > Do we care about the value? "(-E%u)"?
> 
> That too could be confusing. What would (-E22) be considered by a user
> doing an sprintf() on some string. I know that would confuse me, or I
> would think that it was what the %pX displayed, and wonder why it
> displayed it that way. Whereas "(fault)" is quite obvious for any %p
> use case.

This discussion clearly shows that it is hard to make anyone happy.

I considered switching to "(fault)" because there seems to be more
people in favor of this.

But there is used also "(einval)" when an unsupported pointer
modifier is passed. The idea is to show error codes that people
are familiar with.

It might have been better to use the uppercase "(EFAULT)" and
"(EINVAL)" to make it more obvious. But I wanted to follow
the existing style with the lowercase "(null)".

As of now, I think that we should keep it as is unless there is
some wider agreement on a change.

Best Regards,
Petr

WARNING: multiple messages have this Message-ID (diff)
From: Petr Mladek <pmladek@suse.com>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>,
	David Laight <David.Laight@aculab.com>,
	Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>,
	Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
	christophe leroy <christophe.leroy@c-s.fr>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Rasmus Villemoes <linux@rasmusvillemoes.dk>,
	"Tobin C . Harding" <me@tobin.cc>, Michal Hocko <mhocko@suse.cz>,
	Sergey Senozhatsky <sergey.senozhatsky@gmail.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Michael Ellerman <mpe@ellerman.id.au>,
	"linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>,
	Russell Currey <ruscur@russell.cc>,
	Stephen Rothwell <sfr@ozlabs.org>,
	Heiko Carstens <heiko.carstens@de.ibm.com>,
	"linux-arch@vger.kernel.org" <linux-arch@vger.ke>
Subject: Re: [PATCH] vsprintf: Do not break early boot with probing addresses
Date: Wed, 15 May 2019 09:35:42 +0200	[thread overview]
Message-ID: <20190515073542.y6ru2nfagtcrpdl7@pathway.suse.cz> (raw)
In-Reply-To: <20190514143751.48e81e05@oasis.local.home>

On Tue 2019-05-14 14:37:51, Steven Rostedt wrote:
> 
> [ Purple is a nice shade on the bike shed. ;-) ]
> 
> On Tue, 14 May 2019 11:02:17 +0200
> Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> 
> > On Tue, May 14, 2019 at 10:29 AM David Laight <David.Laight@aculab.com> wrote:
> > > > And I like Steven's "(fault)" idea.
> > > > How about this:
> > > >
> > > >       if ptr < PAGE_SIZE              -> "(null)"
> > > >       if IS_ERR_VALUE(ptr)            -> "(fault)"
> > > >
> > > >       -ss  
> > >
> > > Or:
> > >         if (ptr < PAGE_SIZE)
> > >                 return ptr ? "(null+)" : "(null)";
> 
> Hmm, that is useful.
> 
> > >         if IS_ERR_VALUE(ptr)
> > >                 return "(errno)"  
> 
> I still prefer "(fault)" as is pretty much all I would expect from a
> pointer dereference, even if it is just bad parsing of, say, a parsing
> an MAC address. "fault" is generic enough. "errno" will be confusing,
> because that's normally a variable not a output.
> 
> > 
> > Do we care about the value? "(-E%u)"?
> 
> That too could be confusing. What would (-E22) be considered by a user
> doing an sprintf() on some string. I know that would confuse me, or I
> would think that it was what the %pX displayed, and wonder why it
> displayed it that way. Whereas "(fault)" is quite obvious for any %p
> use case.

This discussion clearly shows that it is hard to make anyone happy.

I considered switching to "(fault)" because there seems to be more
people in favor of this.

But there is used also "(einval)" when an unsupported pointer
modifier is passed. The idea is to show error codes that people
are familiar with.

It might have been better to use the uppercase "(EFAULT)" and
"(EINVAL)" to make it more obvious. But I wanted to follow
the existing style with the lowercase "(null)".

As of now, I think that we should keep it as is unless there is
some wider agreement on a change.

Best Regards,
Petr

WARNING: multiple messages have this Message-ID (diff)
From: Petr Mladek <pmladek@suse.com>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: "linux-arch@vger.kernel.org" <linux-arch@vger.kernel.org>,
	Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>,
	Heiko Carstens <heiko.carstens@de.ibm.com>,
	"linux-s390@vger.kernel.org" <linux-s390@vger.kernel.org>,
	"linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>,
	Rasmus Villemoes <linux@rasmusvillemoes.dk>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Michal Hocko <mhocko@suse.cz>,
	Sergey Senozhatsky <sergey.senozhatsky@gmail.com>,
	David Laight <David.Laight@aculab.com>,
	Geert Uytterhoeven <geert@linux-m68k.org>,
	Stephen Rothwell <sfr@ozlabs.org>,
	Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Martin Schwidefsky <schwidefsky@de.ibm.com>,
	"Tobin C . Harding" <me@tobin.cc>
Subject: Re: [PATCH] vsprintf: Do not break early boot with probing addresses
Date: Wed, 15 May 2019 09:35:42 +0200	[thread overview]
Message-ID: <20190515073542.y6ru2nfagtcrpdl7@pathway.suse.cz> (raw)
In-Reply-To: <20190514143751.48e81e05@oasis.local.home>

On Tue 2019-05-14 14:37:51, Steven Rostedt wrote:
> 
> [ Purple is a nice shade on the bike shed. ;-) ]
> 
> On Tue, 14 May 2019 11:02:17 +0200
> Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> 
> > On Tue, May 14, 2019 at 10:29 AM David Laight <David.Laight@aculab.com> wrote:
> > > > And I like Steven's "(fault)" idea.
> > > > How about this:
> > > >
> > > >       if ptr < PAGE_SIZE              -> "(null)"
> > > >       if IS_ERR_VALUE(ptr)            -> "(fault)"
> > > >
> > > >       -ss  
> > >
> > > Or:
> > >         if (ptr < PAGE_SIZE)
> > >                 return ptr ? "(null+)" : "(null)";
> 
> Hmm, that is useful.
> 
> > >         if IS_ERR_VALUE(ptr)
> > >                 return "(errno)"  
> 
> I still prefer "(fault)" as is pretty much all I would expect from a
> pointer dereference, even if it is just bad parsing of, say, a parsing
> an MAC address. "fault" is generic enough. "errno" will be confusing,
> because that's normally a variable not a output.
> 
> > 
> > Do we care about the value? "(-E%u)"?
> 
> That too could be confusing. What would (-E22) be considered by a user
> doing an sprintf() on some string. I know that would confuse me, or I
> would think that it was what the %pX displayed, and wonder why it
> displayed it that way. Whereas "(fault)" is quite obvious for any %p
> use case.

This discussion clearly shows that it is hard to make anyone happy.

I considered switching to "(fault)" because there seems to be more
people in favor of this.

But there is used also "(einval)" when an unsupported pointer
modifier is passed. The idea is to show error codes that people
are familiar with.

It might have been better to use the uppercase "(EFAULT)" and
"(EINVAL)" to make it more obvious. But I wanted to follow
the existing style with the lowercase "(null)".

As of now, I think that we should keep it as is unless there is
some wider agreement on a change.

Best Regards,
Petr

  parent reply	other threads:[~2019-05-15  7:35 UTC|newest]

Thread overview: 95+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-09 12:19 [PATCH] vsprintf: Do not break early boot with probing addresses Petr Mladek
2019-05-09 12:19 ` Petr Mladek
2019-05-09 13:05 ` Andy Shevchenko
2019-05-09 13:05   ` Andy Shevchenko
2019-05-09 13:13 ` Steven Rostedt
2019-05-09 13:13   ` Steven Rostedt
2019-05-09 14:06   ` Petr Mladek
2019-05-09 14:06     ` Petr Mladek
2019-05-09 13:38 ` Michal Suchánek
2019-05-09 13:38   ` Michal Suchánek
2019-05-09 13:46   ` David Laight
2019-05-09 13:46     ` David Laight
2019-05-10 10:21     ` Michael Ellerman
2019-05-10 10:21       ` Michael Ellerman
2019-05-10 10:21       ` Michael Ellerman
2019-05-10  4:32 ` Sergey Senozhatsky
2019-05-10  4:32   ` Sergey Senozhatsky
2019-05-10  4:47   ` Linus Torvalds
2019-05-10  5:07     ` Sergey Senozhatsky
2019-05-10  5:07       ` Sergey Senozhatsky
2019-05-10  6:41       ` Michael Ellerman
2019-05-10  6:41         ` Michael Ellerman
2019-05-10  6:41         ` Michael Ellerman
2019-05-10  6:41         ` Michael Ellerman
2019-05-10  8:06       ` Petr Mladek
2019-05-10  8:06         ` Petr Mladek
2019-05-10  8:16         ` Sergey Senozhatsky
2019-05-10  8:16           ` Sergey Senozhatsky
2019-05-10  8:42           ` Petr Mladek
2019-05-10  8:42             ` Petr Mladek
2019-05-10  8:51             ` Sergey Senozhatsky
2019-05-10  8:51               ` Sergey Senozhatsky
2019-05-10 14:49             ` Petr Mladek
2019-05-10 14:49               ` Petr Mladek
2019-05-10 16:24             ` Steven Rostedt
2019-05-10 16:24               ` Steven Rostedt
2019-05-10 16:32               ` Martin Schwidefsky
2019-05-10 16:32                 ` Martin Schwidefsky
2019-05-10 16:40                 ` Steven Rostedt
2019-05-10 16:40                   ` Steven Rostedt
2019-05-10 16:45                   ` Martin Schwidefsky
2019-05-10 16:45                     ` Martin Schwidefsky
2019-05-13 12:24                   ` Petr Mladek
2019-05-13 12:24                     ` Petr Mladek
2019-05-10 16:41               ` Andy Shevchenko
2019-05-10 16:41                 ` Andy Shevchenko
2019-05-10 17:35               ` christophe leroy
2019-05-10 17:35                 ` christophe leroy
2019-05-13  8:52                 ` David Laight
2019-05-13  8:52                   ` David Laight
2019-05-13  9:13                   ` Andy Shevchenko
2019-05-13  9:13                     ` Andy Shevchenko
2019-05-13  9:13                     ` Andy Shevchenko
2019-05-13 12:42                     ` Petr Mladek
2019-05-13 12:42                       ` Petr Mladek
2019-05-13 12:42                       ` Petr Mladek
2019-05-13 14:15                       ` Steven Rostedt
2019-05-13 14:15                         ` Steven Rostedt
2019-05-13 14:15                         ` Steven Rostedt
2019-05-14  2:07                       ` Sergey Senozhatsky
2019-05-14  2:07                         ` Sergey Senozhatsky
2019-05-14  2:07                         ` Sergey Senozhatsky
2019-05-14  2:25                         ` Sergey Senozhatsky
2019-05-14  2:25                           ` Sergey Senozhatsky
2019-05-14  2:25                           ` Sergey Senozhatsky
2019-05-14  8:28                         ` David Laight
2019-05-14  8:28                           ` David Laight
2019-05-14  8:28                           ` David Laight
2019-05-14  9:02                           ` Geert Uytterhoeven
2019-05-14  9:02                             ` Geert Uytterhoeven
2019-05-14  9:02                             ` Geert Uytterhoeven
2019-05-14 18:37                             ` Steven Rostedt
2019-05-14 18:37                               ` Steven Rostedt
2019-05-14 18:37                               ` Steven Rostedt
2019-05-14 19:13                               ` Geert Uytterhoeven
2019-05-14 19:13                                 ` Geert Uytterhoeven
2019-05-14 19:13                                 ` Geert Uytterhoeven
2019-05-14 19:35                                 ` Steven Rostedt
2019-05-14 19:35                                   ` Steven Rostedt
2019-05-14 19:35                                   ` Steven Rostedt
2019-05-15  7:23                                   ` Geert Uytterhoeven
2019-05-15  7:23                                     ` Geert Uytterhoeven
2019-05-15  7:23                                     ` Geert Uytterhoeven
2019-05-15  7:53                                     ` Petr Mladek
2019-05-15  7:53                                       ` Petr Mladek
2019-05-15  7:53                                       ` Petr Mladek
2019-05-15  6:21                                 ` Sergey Senozhatsky
2019-05-15  6:21                                   ` Sergey Senozhatsky
2019-05-15  6:21                                   ` Sergey Senozhatsky
2019-05-15  7:35                               ` Petr Mladek [this message]
2019-05-15  7:35                                 ` Petr Mladek
2019-05-15  7:35                                 ` Petr Mladek
2019-05-15  9:00                                 ` David Laight
2019-05-15  9:00                                   ` David Laight
2019-05-15  9:00                                   ` David Laight

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=20190515073542.y6ru2nfagtcrpdl7@pathway.suse.cz \
    --to=pmladek@suse.com \
    --cc=David.Laight@aculab.com \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=christophe.leroy@c-s.fr \
    --cc=geert@linux-m68k.org \
    --cc=heiko.carstens@de.ibm.com \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=linux@rasmusvillemoes.dk \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=me@tobin.cc \
    --cc=mhocko@suse.cz \
    --cc=mpe@ellerman.id.au \
    --cc=rostedt@goodmis.org \
    --cc=ruscur@russell.cc \
    --cc=schwidefsky@de.ibm.com \
    --cc=sergey.senozhatsky.work@gmail.com \
    --cc=sergey.senozhatsky@gmail.com \
    --cc=sfr@ozlabs.org \
    --cc=torvalds@linux-foundation.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.