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 09:25:07 +0200 [thread overview]
Message-ID: <5650648.lOV4Wx5bFT@eto.sf-tec.de> (raw)
In-Reply-To: <20201022164007.GA10653@ls3530.fritz.box>
[-- Attachment #1: Type: text/plain, Size: 827 bytes --]
> +#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)
because that would correctly reject a bare 0x4, at least I hope that this
would already happen with the strict checking you mentioned.
Would a pr_warn_once make sense? Otherwise your log may get flooded by them if
e.g. sudo is the problem and my nagios comes every minute to check something.
Eike
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 195 bytes --]
next prev parent reply other threads:[~2020-10-23 7:25 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 [this message]
2020-10-23 8:18 ` Helge Deller
2020-10-23 8:31 ` Helge Deller
2020-10-23 8:58 ` Rolf Eike Beer
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=5650648.lOV4Wx5bFT@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.