On Sun, Feb 19, 2017 at 09:14:41AM +, Al Viro wrote:
> On Fri, Feb 17, 2017 at 05:09:29PM +0100, Miklos Szeredi wrote:
> > A file is opened for read-only, opened read-write (resulting in a copy up)
> > and modified. The data read back from the the read-only fd will be stale
> > in this case (t
On Sun, Feb 19, 2017 at 10:14 AM, Al Viro wrote:
> This is one hell of a DoS vector - it's really easy to eat tons of struct
> file that way. Preparatory parts of that series make sense on their own,
> but your "let's allocate a struct file, call ->open() and schedule that
> struct file for clos
On Fri, Feb 17, 2017 at 05:09:29PM +0100, Miklos Szeredi wrote:
> A file is opened for read-only, opened read-write (resulting in a copy up)
> and modified. The data read back from the the read-only fd will be stale
> in this case (the read-only file descriptor still refers to the lower,
> unmodif
A file is opened for read-only, opened read-write (resulting in a copy up)
and modified. The data read back from the the read-only fd will be stale
in this case (the read-only file descriptor still refers to the lower,
unmodified file).
This patchset fixes issues related to this corner case. Thi
4 matches
Mail list logo
