linux-kernel - Re: [RFC] should read(2) update the position if it returns an error?

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: <CA+55aFyEuDsLtKXDCd1w_dUfOg-4_7b2WBO3P+5VMFXB4XS=YQ@mail.gmail.com>
Date:	Fri, 14 Jun 2013 08:38:19 -0700
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Al Viro <viro@...iv.linux.org.uk>
Cc:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	linux-fsdevel <linux-fsdevel@...r.kernel.org>
Subject: Re: [RFC] should read(2) update the position if it returns an error?

On Fri, Jun 14, 2013 at 1:05 AM, Al Viro <viro@...iv.linux.org.uk> wrote:
>
>         Comments?  I'd obviously prefer to solve it that way (i.e. leave
> ->f_pos untouched if vfs_read() returns an error), but I might be missing
> some case where we want position updated even though read() returns an
> error.  I can't come up with one, but then I hadn't RTFS through every
> ->read() instance in drivers in search of weird cases like that - we've
> too many instances ;-/

Not updating f_pos on errors sounds like the right thing to do to me,
and if it also ends up fixing some nasty issues with hpfs and
potentially other cases, I'd say "go for it".

Not for 3.10, though. It's not like this is a new - or acute - problem.

             Linus
--
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/