linux-kernel - Re: Buggy rwsem locking code in fs/smb/client/file.c

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: <CAHk-=wg4J3XjdakYiK6yC-QuBuCDn1g4XGNkuaAzByUM4KCCog@mail.gmail.com>
Date:   Mon, 3 Jul 2023 10:00:11 -0700
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Steven Rostedt <rostedt@...dmis.org>
Cc:     LKML <linux-kernel@...r.kernel.org>,
        Dave Wysochanski <dwysocha@...hat.com>,
        Ronnie Sahlberg <lsahlber@...hat.com>,
        Pavel Shilovsky <pshilov@...rosoft.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ajay Kaher <akaher@...are.com>
Subject: Re: Buggy rwsem locking code in fs/smb/client/file.c

On Mon, 3 Jul 2023 at 08:43, Steven Rostedt <rostedt@...dmis.org> wrote:
>
> And hides the bug by wrapping the down_write() with:
>
> +void
> +cifs_down_write(struct rw_semaphore *sem)
> +{
> +       while (!down_write_trylock(sem))
> +               msleep(10);
> +}

That is indeed disgusting.

It may *work* - because as the commit message says, it means that
writers are now never queued up and thus never block recursive
readers.

And in the process it now becomes absolutely horribly unfair to
writers, who will easily get starved by readers.

This is absolutely not acceptable in any sane situation. Are writers
*so* rare and special that starving them is ok?

Because starvation can be just as deadly as a deadlock. You're just
hiding the problem from lockdep and yourself.

This is very much a "head in the sand" solution.

            Linus