lkml.org 
[lkml]   [2018]   [Mar]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] debugfs: Check return value of debugfs_real_fops() for NULL
El Wed, Mar 28, 2018 at 08:19:36PM +0200 Greg Kroah-Hartman ha dit:

> On Wed, Mar 28, 2018 at 11:14:56AM -0700, Matthias Kaehlcke wrote:
> > El Wed, Mar 28, 2018 at 08:05:56PM +0200 Greg Kroah-Hartman ha dit:
> >
> > >
> > > A: Because it messes up the order in which people normally read text.
> > > Q: Why is top-posting such a bad thing?
> > > A: Top-posting.
> > > Q: What is the most annoying thing in e-mail?
> > >
> > > A: No.
> > > Q: Should I include quotations after my reply?
> > >
> > > http://daringfireball.net/2007/07/on_top
> > >
> > > On Wed, Mar 28, 2018 at 07:47:53AM -0700, Manoj Gupta wrote:
> > > > Please note that there is nothing wrong in the generated code, just
> > > > that it confuses objtool.
> > >
> > > Then fix the tool, the C code is correct :)
> > >
> > > > Clang has simply omitted the statement where NULL is returned since
> > > > the pointer was always dereferenced post inlining.
> > >
> > > Then tell clang not to do that, like we tell gcc not to do that as that
> > > is a foolish thing for a compiler to do when building the kernel.
> >
> > Thanks all for your input, we'll try to get
> > -fno-delete-null-pointer-checks or a similar flag to be added to
> > clang.
>
> Wait, clang does not have that?

Nope, clang doesn't currently have such a flag.

> That's crazy, how has this not been hit yet when building the
> kernel?

IIRC this patch was needed to work around the lack of the flag:

commit beaec533fc2701a28a4d667f67c9f59c6e4e0d13
Author: Alexander Potapenko <glider@google.com>
Date: Wed Jul 19 20:27:30 2017 +0200

llist: clang: introduce member_address_is_nonnull()

Currently llist_for_each_entry() and llist_for_each_entry_safe() iterate
until &pos->member != NULL. But when building the kernel with Clang,
the compiler assumes &pos->member cannot be NULL if the member's offset
is greater than 0 (which would be equivalent to the object being
non-contiguous in memory). Therefore the loop condition is always true,
and the loops become infinite.

To work around this, introduce the member_address_is_nonnull() macro,
which casts object pointer to uintptr_t, thus letting the member pointer
to be NULL.

Signed-off-by: Alexander Potapenko <glider@google.com>
Tested-by: Sodagudi Prasad <psodagud@codeaurora.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>


Other than that I am not aware of any known issues.

\
 
 \ /
  Last update: 2018-03-28 20:51    [W:0.043 / U:0.612 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site