Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <YjjihIZuvZpUjaSs@google.com> <CAHk-=wgsmvoJFKFWxQ2orEVUOWH1agk9iUNZ=-DFh5OXZL=Ldw@mail.gmail.com>
 <51cded74-3135-eed8-06d3-0b2165e3b379@redhat.com>
In-Reply-To: <51cded74-3135-eed8-06d3-0b2165e3b379@redhat.com>
From:   Linus Torvalds <torvalds@linux-foundation.org>
Date:   Tue, 22 Mar 2022 10:50:35 -0700
Message-ID: <CAHk-=wi=Xsekgj7zfw_vpOM673CG24vznmz-yx9G05rWSAAYXg@mail.gmail.com>
Subject: Re: [GIT PULL] f2fs for 5.18
To:     Waiman Long <longman@redhat.com>, Tim Murray <timmurray@google.com>
Cc:     Jaegeuk Kim <jaegeuk@kernel.org>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        Linux F2FS Dev Mailing List 
        <linux-f2fs-devel@lists.sourceforge.net>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Tue, Mar 22, 2022 at 10:37 AM Waiman Long <longman@redhat.com> wrote:
>
> AFAICS, the read-unfair rwsem code is created to resolve a potential
> lock starvation problem that they found on linux-5.10.y stable tree. I
> believe I have fixed that in the v5.11 kernel, see commit 2f06f702925
> ("locking/rwsem: Prevent potential lock starvation").

Ahh.

Adding Tim Murray to the cc, since he was the source of that odd
reader-unfair thing.

I really *really* dislike people thinking they can do locking
primitives, because history has taught us that they are wrong.

Even when people get the semantics and memory ordering right (which is
not always the case, but at least the f2fs code uses real lock
primitives - just oddly - and should thus be ok), it invariably tends
to be a sign of something else being very wrong.

And I can easily believe that in this case it's due to a rmsem issue
that was already fixed long long ago as per Waiman.

Can people please test with the actual modern rwsem code and with the
odd reader-unfair locks disabled?

            Linus