linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Al Viro <viro@ZenIV.linux.org.uk>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Kyle Huey <me@kylehuey.com>,
	open list <linux-kernel@vger.kernel.org>,
	"Robert O'Callahan" <robert@ocallahan.org>
Subject: Re: [git pull] vfs.git regression fix Re: Regression related to ipc shmctl compat
Date: Tue, 26 Sep 2017 04:01:39 +0100	[thread overview]
Message-ID: <20170926030138.GA32076@ZenIV.linux.org.uk> (raw)
In-Reply-To: <CA+55aFxYFsD1DBt3uTGnmGvdZHi0Sz8Qcyswv_1nc34rU0bkUg@mail.gmail.com>

On Mon, Sep 25, 2017 at 07:07:01PM -0700, Linus Torvalds wrote:
> On Mon, Sep 25, 2017 at 7:03 PM, Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
> >
> > I agree. It might be better to just remove the address space logic,
> > because afaik it never worked for them.
> 
> .. and sadly, we should probably disable the locking ones by default
> too, because while they *work*, sparse only handles static cases, and
> we have way too many dynamically conditional cases that are outside
> the scope of what sparse does.
> 
> It would probably be good to disable things that are fundamentally
> hard to fix, and aim for a clean sparse build, and maybe people would
> start using it at least for user pointer checking where it really does
> work.
> 
> Of course, even there it depends on pointers _statically_ being user
> pointers, but happily we do largely follow that rule. We've had a few
> nasty cases where we have a pointer that is conditionally user or
> kernel pointer, but they are thankfully pretty rare.

BTW, while we are at it - I'd been rebasing POLL... annotations through
the last three cycles and it doesn't take much work (usually 20-30
minutes).  Mind if I throw vfs.git#misc.poll into -next and send it
your way next cycle?

Right now it's pretty much in zero-noise state - a few of the remaining
warnings are spurious, but most of what remains consists of real bugs.
One class is ->poll() instance returning -E... in some case; callers
expect a bitmap instead.  Another, and that's much nastier, is EPOLL...
mess.  We have EPOLL... definitions identical for all architectures.
Unfortunately, we rely upon them being equal to corresponding POLL...
(when both are defined) and some of those are different on different
architectures (sparc is the strangest one in that respect).  Both are
exposed to userland, so we can't just go and change them at will.
Not sure what can be done with that, syscall ABI being what it is...

  reply	other threads:[~2017-09-26  3:01 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-09-25 22:18 Regression related to ipc shmctl compat Kyle Huey
2017-09-26  1:00 ` [git pull] vfs.git regression fix " Al Viro
2017-09-26  1:37   ` Linus Torvalds
2017-09-26  1:46     ` Al Viro
2017-09-26  2:00       ` Al Viro
2017-09-26  2:03         ` Linus Torvalds
2017-09-26  2:07           ` Linus Torvalds
2017-09-26  3:01             ` Al Viro [this message]
2017-09-26 19:45             ` Luc Van Oostenryck
2017-09-26  2:02       ` Linus Torvalds
2017-10-11 17:03         ` Al Viro
2017-10-11 17:06           ` Al Viro
2017-10-11 17:31           ` Linus Torvalds
2017-09-26  6:42     ` Christoph Hellwig
2017-09-28  6:13       ` Script to do smart sparse diffs (was Re: [git pull] vfs.git regression fix Re: Regression related to ipc shmctl compat) Michael Ellerman
2017-10-15  6:58   ` [git pull] vfs.git regression fix Re: Regression related to ipc shmctl compat Pavel Machek
2017-10-16 11:41     ` Linus Torvalds

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=20170926030138.GA32076@ZenIV.linux.org.uk \
    --to=viro@zeniv.linux.org.uk \
    --cc=linux-kernel@vger.kernel.org \
    --cc=me@kylehuey.com \
    --cc=robert@ocallahan.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).