linux-raid.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Michal Soltys <soltys@ziu.info>
To: NeilBrown <neilb@suse.de>
Cc: "Orlowski, Lukasz" <lukasz.orlowski@intel.com>,
	"linux-raid@vger.kernel.org" <linux-raid@vger.kernel.org>
Subject: Re: mdadm r/w operations without TEMP_FAILURE_RETRY()
Date: Tue, 25 Oct 2011 19:29:52 +0200	[thread overview]
Message-ID: <4EA6F210.7040701@ziu.info> (raw)
In-Reply-To: <20111018203016.4536708f@notabene.brown>

On 11-10-18 11:30, NeilBrown wrote:
> On Tue, 18 Oct 2011 10:16:41 +0100 "Orlowski, Lukasz"
> <lukasz.orlowski@intel.com>  wrote:
>
>> Hi,
>>
>> I was going through mdadm code and got to realize that r/w
>> operations are invoked without TEMP_FAILURE_RETRY() macro, which
>> protects from unexpected operation termination, case SIGINT is
>> thrown. According to my knowledge its POSIX best-practice to call
>> the r/w operations within that macro, lest some sporadic unexpected
>> behaviors occur.
>>
>> Any particular reason for not using it?
>
> I've never heard of TEMP_FAILURE_RETRY.
>
> And having looked in to it I would certainly try to avoid using it.
>

As this grabbed my attention ..

that macro is just a shortcut to something along the:

do {
	ret = read/write/etc.( ... );
} while (ret < 0 && errno == EINTR);

which has always been the proper way to handle such situations 
(recollecting Stevens books, glibc reference manual, or any other solid 
source). Why avoid using it ? Costs nothing, and guarantees we won't run 
into some corner case.

> If the SA_RESTART flag is set with sigaction() then it should be
> totally unnecessary.
>

signals(7) has pretty large list of when it can or cannot happen, and
when it will always happen regardless of SA_RESTART. And it would be 
quite different list when other unix vendors are considered (which 
doesn't of course apply to mdadm case, it being only linux specific). 
There're also not ignorable stop signals (and under some cases they will 
end with EINTR as well).

And it's not only SIGINT (as the original mail could suggest), any not 
ignored signal can cause it.

  reply	other threads:[~2011-10-25 17:29 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <2AC2FDB9F3686F48962B2B65E2040CCC3D155FA0@irsmsx503.ger.corp.intel.com>
2011-10-18  9:30 ` mdadm r/w operations without TEMP_FAILURE_RETRY() NeilBrown
2011-10-25 17:29   ` Michal Soltys [this message]
2011-10-25 21:28     ` NeilBrown

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=4EA6F210.7040701@ziu.info \
    --to=soltys@ziu.info \
    --cc=linux-raid@vger.kernel.org \
    --cc=lukasz.orlowski@intel.com \
    --cc=neilb@suse.de \
    /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).