linux-kernel - Re: [PATCH] Improving read/write/close system call reliability when used with pthreads

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]

Message-Id: <9BA3E04B-3068-4629-B11C-1A018A9ABF3C@nocrew.org>
Date:	Sun, 12 Aug 2007 20:30:46 +0200
From:	Fredrik Noring <noring@...rew.org>
To:	Paul Jackson <pj@....com>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] Improving read/write/close system call reliability when used with pthreads

Paul,

Paul Jackson wrote:
> You suspected correctly - Apple Mail line wrapped it at 72 columns
> (added newlines in any line going past column 72.)  This makes it
> impossible to apply the patch without alot of hand editing.

Of course, sorry about that. New try!

Regarding the FIXME: Marking bad fd:s in close currently walks all  
tasks, but it ought to be possible to do this much more efficiently.  
For example only tasks that actually use the file table in question.  
Alternatively, only tasks that are waiters in the pipe_inode_info- 
 >wait queue (they are the ones that are woken up to handle the close  
anyway; the wake up btw can perhaps also be more fine-grained).

I have a feeling that the latter is the most efficient, but perhaps a  
bit more tricky regarding races. Plus, this puts the burden of  
marking bad fd:s onto all the implementations of the f_op->closing_fd  
file operation.

The rest of the bookkeeping to handle required_fds should be  
efficient, I believe.

Regarding generality: For maximum benefit of being able to close all  
kinds even non-pipe fd:s reliably, a lot of places need to be  
updated. This is not a requirement though, as current behaviour is  
maintained otherwise. (It might however be worthwhile to have  
sys_read/sys_write etc. refuse -ERESTARTSYS when its fd apparently is  
bad.)

Cheers,
Fredrik

Download attachment "required-fds.patch" of type "application/octet-stream" (9128 bytes)