linux-kernel - Re: [PATCH 4.19 066/133] regmap: debugfs: Dont sleep while atomic for fast

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: <CAD=FV=V53j6h-RAA9xpoj2BBUVOJa=3hH85rnm=0Mh7WnQHMog@mail.gmail.com>
Date:   Thu, 6 Aug 2020 13:10:21 -0700
From:   Doug Anderson <dianders@...omium.org>
To:     Pavel Machek <pavel@...x.de>
Cc:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        LKML <linux-kernel@...r.kernel.org>,
        "# 4.0+" <stable@...r.kernel.org>, Mark Brown <broonie@...nel.org>,
        Sasha Levin <sashal@...nel.org>
Subject: Re: [PATCH 4.19 066/133] regmap: debugfs: Dont sleep while atomic for
 fast_io regmaps

Hi,

On Wed, Jul 22, 2020 at 5:09 AM Pavel Machek <pavel@...x.de> wrote:
>
> Hi!
>
> > From: Douglas Anderson <dianders@...omium.org>
> >
> > [ Upstream commit 299632e54b2e692d2830af84be51172480dc1e26 ]
> >
>
> > +     err = kstrtobool_from_user(user_buf, count, &new_val);
> > +     /* Ignore malforned data like debugfs_write_file_bool() */
>
> > +     err = kstrtobool_from_user(user_buf, count, &new_val);
> > +     /* Ignore malforned data like debugfs_write_file_bool() */
>
> I guess that should be "malformed" in both cases.

Sure.

https://lore.kernel.org/r/20200806130222.1.I832b2b45244c80ba2550a5bbcef80b574e47c57e@changeid

> Plus it would not be bad to share code between those two functions, as
> they are pretty much identical...

I took a quick attempt at it and it seemed slightly worse to me when
they shared code, at least if we wanted to keep the behavior
identical.  For me it was the extra ": syncing cache" part of the
message in one of the two functions that pushed it over the edge.
Specifically if we wanted to keep that we'd have to do one of these:

a) Keep the printing out of the common code, but then the common code
is really small.

b) Add a special parameter to the common code named something like
"do_sync_if_val_becomes_false"

c) Pass some extra string named something like
"append_to_log_message_in_no_case", then do the actual sync outside of
the common code.

That being said, if you want to try to make these two functions use a
common helper and everyone thinks it's better that way then I won't
stand in your way.

-Doug