From: Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
To: Jonathan Corbet <corbet-T1hC0tSOHrs@public.gmane.org>,
Alexander Shishkin
<alexander.shishkin-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
Cc: Peter Zijlstra
<a.p.zijlstra-/NLkJaSkS4VmR6Xm/wNWPw@public.gmane.org>,
Ingo Molnar <mingo-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
vince-yfjdyHUqu3OsTnJN9+BGXg@public.gmane.org,
eranian-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org,
Arnaldo Carvalho de Melo
<acme-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>,
linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [PATCH RFC v3 1/6] exterr: Introduce extended syscall error reporting
Date: Tue, 15 Sep 2015 19:02:19 +0200 [thread overview]
Message-ID: <1442336539.1914.34.camel@sipsolutions.net> (raw)
In-Reply-To: <20150915103556.36b06f09-T1hC0tSOHrs@public.gmane.org>
> I think that anything other than the errno "grab it now or lose it"
> behavior will prove confusing. I don't think there is any other way to
> know that a given error report corresponds to a specific system call.
> Library calls can mess it up. Kernel changes adding extended reporting to
> new system calls can mess it up. Applications cannot possibly be expected
> to know which system calls might change the error-reporting status, they
> *have* to assume all of them will.
>
Yeah I was about to say something similar - an application that expects
a certain syscall to have extended errors will get confused if running
on an older kernel where that syscall in fact does *not* have extended
errors (and thus also doesn't clear extended errors) and therefore the
extended error from a previous syscall could still be lingering on (for
example because the application didn't care to fetch it for that previo
us syscall.)
johannes
WARNING: multiple messages have this Message-ID (diff)
From: Johannes Berg <johannes@sipsolutions.net>
To: Jonathan Corbet <corbet@lwn.net>,
Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>,
Ingo Molnar <mingo@redhat.com>,
linux-kernel@vger.kernel.org, vince@deater.net,
eranian@google.com, Arnaldo Carvalho de Melo <acme@infradead.org>,
linux-api@vger.kernel.org
Subject: Re: [PATCH RFC v3 1/6] exterr: Introduce extended syscall error reporting
Date: Tue, 15 Sep 2015 19:02:19 +0200 [thread overview]
Message-ID: <1442336539.1914.34.camel@sipsolutions.net> (raw)
In-Reply-To: <20150915103556.36b06f09@lwn.net>
> I think that anything other than the errno "grab it now or lose it"
> behavior will prove confusing. I don't think there is any other way to
> know that a given error report corresponds to a specific system call.
> Library calls can mess it up. Kernel changes adding extended reporting to
> new system calls can mess it up. Applications cannot possibly be expected
> to know which system calls might change the error-reporting status, they
> *have* to assume all of them will.
>
Yeah I was about to say something similar - an application that expects
a certain syscall to have extended errors will get confused if running
on an older kernel where that syscall in fact does *not* have extended
errors (and thus also doesn't clear extended errors) and therefore the
extended error from a previous syscall could still be lingering on (for
example because the application didn't care to fetch it for that previo
us syscall.)
johannes
next prev parent reply other threads:[~2015-09-15 17:02 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-11 15:59 [PATCH RFC v3 0/6] Introduce extended syscall error reporting Alexander Shishkin
2015-09-11 16:00 ` [PATCH RFC v3 1/6] exterr: " Alexander Shishkin
2015-09-14 20:19 ` Jonathan Corbet
2015-09-15 14:15 ` Alexander Shishkin
2015-09-15 14:31 ` Johannes Berg
2015-09-15 15:24 ` Alexander Shishkin
[not found] ` <877fnrn1sj.fsf-qxRn5AmX6ZD9BXuAQUXR0fooFf0ArEBIu+b9c/7xato@public.gmane.org>
2015-09-15 16:35 ` Jonathan Corbet
2015-09-15 16:35 ` Jonathan Corbet
[not found] ` <20150915103556.36b06f09-T1hC0tSOHrs@public.gmane.org>
2015-09-15 17:02 ` Johannes Berg [this message]
2015-09-15 17:02 ` Johannes Berg
2015-09-14 21:59 ` Jonathan Corbet
2016-01-11 10:34 ` Alexander Shishkin
2015-09-11 16:00 ` [PATCH RFC v3 2/6] perf: Use " Alexander Shishkin
2015-09-11 16:00 ` [PATCH RFC v3 3/6] perf/x86: Annotate a BTS error with extended " Alexander Shishkin
2015-09-11 16:00 ` [PATCH RFC v3 4/6] perf tools: Add a simple JSON parser Alexander Shishkin
2015-09-11 16:00 ` [PATCH RFC v3 5/6] perf tools: Add userspace counterpart for extended error reporting Alexander Shishkin
2015-09-11 16:00 ` [PATCH RFC v3 6/6] perf tools: Use extended syscall " Alexander Shishkin
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=1442336539.1914.34.camel@sipsolutions.net \
--to=johannes-cdvu00un1vgdhxzaddlk8q@public.gmane.org \
--cc=a.p.zijlstra-/NLkJaSkS4VmR6Xm/wNWPw@public.gmane.org \
--cc=acme-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org \
--cc=alexander.shishkin-VuQAYsv1563Yd54FQh9/CA@public.gmane.org \
--cc=corbet-T1hC0tSOHrs@public.gmane.org \
--cc=eranian-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org \
--cc=linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=mingo-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
--cc=vince-yfjdyHUqu3OsTnJN9+BGXg@public.gmane.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 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.