[PATCH] vsprintf: Do not break early boot with probing addresses
Petr Mladek
pmladek at suse.com
Wed May 15 17:35:42 AEST 2019
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 at linux-m68k.org> wrote:
>
> > On Tue, May 14, 2019 at 10:29 AM David Laight <David.Laight at 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
More information about the Linuxppc-dev
mailing list