linux-kernel - Re: [GIT PULL] configfs updates for 5.9

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 for Android: free password hash cracker in your pocket

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

Date:   Wed, 5 Aug 2020 12:29:04 -0700
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Christoph Hellwig <hch@...radead.org>
Cc:     "Kai M??kisara" <Kai.Makisara@...umbus.fi>,
        "James E.J. Bottomley" <jejb@...ux.ibm.com>,
        Joel Becker <jlbec@...lplan.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Lenny Szubowicz <lszubowi@...hat.com>
Subject: Re: [GIT PULL] configfs updates for 5.9

On Wed, Aug 5, 2020 at 1:28 AM Christoph Hellwig <hch@...radead.org> wrote:
>
> Yes, but this is a fundamental problem with the commit on close
> model that the configfs binary attributes implement, and we have to
> work around that somehow.  The current behavior is to entirely ignore
> errors, which of course has major issues.

Ignoring errors is better than randomly not doing the commit at all,
which is what that patch does.

> I guess the alternative might be to just commit on every ->flush

That's how ->flush() is designed to be used, yes. It's also why it's
named that way.

It can obviously cause problems too, if you have multiple opens (ie
dup/fork) and one file descriptor is closed while another is in the
middle of a series of writes

But honestly, if you do binary writes to sysfs, you should do them as
one single write, and the flush function should take that mutex and
then skip the flush if write_in_progress is true.

Because in *that* case, it has serialized with other writers and we
know that those other writers will flush when closing, and there's no
race.

You can still screw up by doing multiple independent writes and do s
close() in between the writes, but at some point it becomes a "yeah,
that's broken and nobody actually does that" issue.

                Linus