linux-kernel - Re: Ctrl+C doesn't interrupt process waiting for I/O

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 30 Jun 2008 13:35:35 -0400
From:	"J. Bruce Fields" <bfields@...ldses.org>
To:	Jeremy Fitzhardinge <jeremy@...p.org>
Cc:	Avi Kivity <avi@...ranet.com>,
	Török Edwin <edwintorok@...il.com>,
	Linux Kernel <linux-kernel@...r.kernel.org>
Subject: Re: Ctrl+C doesn't interrupt process waiting for I/O

On Sat, Jun 28, 2008 at 10:13:54PM -0700, Jeremy Fitzhardinge wrote:
> Avi Kivity wrote:
>>>
>>> Yes, it's intended behaviour.  Filesystem IO syscalls are considered  
>>> "fast" and are interruptible.  Usermode code can reasonably expect  
>>> that file IO will never return EINTR.
>>
>> That's filesystem dependent; if you mount an nfs filesystem with the  
>> 'intr' mount option, it will be interruptible (which makes sense, as  
>> it is impossible to guarantee the server's responsiveness).
>
> 'intr' is a pretty bad idea, and I would never recommend it ('soft' is  
> better).

Yipes.

> It's an excellent way to destroy data when a stray signal  
> causes a syscall to fail with EINTR in an unexpected way (write being  
> the obvious one, but link, unlink, truncate or even close can fail in  
> odd ways can cause havok).

And with "soft" all that can happen with the need for the stray
signal....

I suppose the relative likelihoods of hitting the problem under "soft"
and "intr" may vary depending on the details of your setup.  But in
general I'd've thought it'd be easier to control stray signals than,
say, stray network problems.

--b.

> I don't know of any other filesystem with a similarly bad option.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/