All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rolf Eike Beer <eike-kernel@sf-tec.de>
To: Jeroen Roovers <jer@xs4all.nl>, Meelis Roos <mroos@linux.ee>,
	James Bottomley <James.Bottomley@hansenpartnership.com>,
	John David Anglin <dave.anglin@bell.net>,
	Helge Deller <deller@gmx.de>
Cc: linux-parisc@vger.kernel.org
Subject: Re: [RFC PATCH] parisc: Add wrapper syscalls to fix O_NONBLOCK flag usage
Date: Fri, 23 Oct 2020 10:58:37 +0200	[thread overview]
Message-ID: <2572767.mvXUDI8C0e@eto.sf-tec.de> (raw)
In-Reply-To: <15a0414d-9c6d-76ed-becc-f62635763da0@gmx.de>

[-- Attachment #1: Type: text/plain, Size: 1801 bytes --]

Am Freitag, 23. Oktober 2020, 10:31:14 CEST schrieb Helge Deller:
> On 10/23/20 10:18 AM, Helge Deller wrote:
> > On 10/23/20 9:25 AM, Rolf Eike Beer wrote:
> >>> +#define O_NONBLOCK_OLD		000200004
> >>> +#define O_NONBLOCK_MASK_OUT	(O_NONBLOCK_OLD & ~O_NONBLOCK)
> >>> +static int FIX_O_NONBLOCK(int flags)
> >>> +{
> >>> +	if (flags & O_NONBLOCK_MASK_OUT) {
> >>> +		struct task_struct *tsk = current;
> >>> +		pr_warn("%s(%d) uses old O_NONBLOCK value. "
> >>> +			"Please recompile the application.\n",
> >>> +			tsk->comm, tsk->pid);
> >>> +	}
> >>> +	return flags & ~O_NONBLOCK_MASK_OUT;
> >>> +}
> >> 
> >> This will also trigger if I just pass 0x4 in flags, no? The check should
> >> be
> >> 
> >> 	if ((flags & O_NONBLOCK_OLD) == O_NONBLOCK_OLD)
> > 
> > RIGHT!
> > That's a very good point.
> > I was thinking about what would happen if over time a new (unrelated)
> > define gets created which then gets 0x4 as value. My code would then have
> > wrongly modified it.
> 
> After some more thinking....
> 
> It's not that easy.
> Let's assume there will be another new flag at some time with value 0x4.
> Now, the caller sets this flag (0x4) and new O_NONBLOCK (000200000),
> so you end up with 000200004 again, which then triggers your check:
>  	if ((flags & O_NONBLOCK_OLD) == O_NONBLOCK_OLD)
> 
> So, my check to test only the mask for 0x4 was basically better,
> because it would prevent the usage of 0x4 as any new value.
> In any way, it seems we need to avoid using 0x4 for a long time...

Then maybe just add that as an explicit comment in the header so noone picks 
it by accident, and add a comment pointing to these wrappers so they are more 
likely to be kept in sync.

And for extra fun we can just scrap all this for 64 bit userspace as we don't 
need the compat there ;)

Eike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

  reply	other threads:[~2020-10-23  8:58 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-29 12:20 [RFC PATCH] parisc: Define O_NONBLOCK to become 000200000 Helge Deller
2020-10-20 17:21 ` Jeroen Roovers
2020-10-21  6:07   ` Helge Deller
2020-10-22 15:38     ` Jeroen Roovers
2020-10-22 16:14       ` Helge Deller
2020-10-22 16:40         ` [RFC PATCH] parisc: Add wrapper syscalls to fix O_NONBLOCK flag usage Helge Deller
2020-10-22 19:11           ` Meelis Roos
2020-10-22 20:29             ` Helge Deller
2020-10-23  7:02               ` Jeroen Roovers
2020-10-23  8:35                 ` Helge Deller
2020-10-23  8:53                   ` Jeroen Roovers
2020-10-23 18:15                     ` Helge Deller
2020-10-22 20:00           ` Jeroen Roovers
2020-10-23  7:25           ` Rolf Eike Beer
2020-10-23  8:18             ` Helge Deller
2020-10-23  8:31               ` Helge Deller
2020-10-23  8:58                 ` Rolf Eike Beer [this message]
2020-10-23 18:18           ` [RFC PATCH v3] " Helge Deller
2020-10-24  8:22             ` Jeroen Roovers
2020-10-24  8:24               ` Jeroen Roovers
2020-10-24  8:34                 ` Helge Deller
2020-10-24 14:11                   ` John David Anglin
2020-10-24  9:59             ` Jeroen Roovers
2020-10-25 11:48               ` Helge Deller

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=2572767.mvXUDI8C0e@eto.sf-tec.de \
    --to=eike-kernel@sf-tec.de \
    --cc=James.Bottomley@hansenpartnership.com \
    --cc=dave.anglin@bell.net \
    --cc=deller@gmx.de \
    --cc=jer@xs4all.nl \
    --cc=linux-parisc@vger.kernel.org \
    --cc=mroos@linux.ee \
    /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.