linux-kernel - Re: [PATCH] xfs: Correctly invert xfs

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: <CAHrQN1w2DxYD_ZscBhsuGq2b6CKn41AnVCaH6_hSQ2tN8DkA1Q@mail.gmail.com>
Date:   Mon, 5 Mar 2018 11:19:46 +0100
From:   Vratislav Bendel <vbendel@...hat.com>
To:     "Darrick J. Wong" <darrick.wong@...cle.com>
Cc:     linux-xfs@...r.kernel.org, Brian Foster <bfoster@...hat.com>,
        linux-kernel@...r.kernel.org, djwong@...nel.org
Subject: Re: [PATCH] xfs: Correctly invert xfs_buftarg LRU isolation logic

(In response to Luis' comment:)
> Can you add a respective Fixes: tag?

It was apparently present since LRU was added to xfs buffer cache via:
commit 430cbeb86fdcbbdabea7d4aa65307de8de425350
[xfs: add a lru to the XFS buffer cache]

But I wouldn't say this patch "fixes" that commit.
What do you think? Should a fixes tag be added in this case?

> Also what effects are observed by
> the user when this happens on the kernel log?

I haven't spotted any differences visible to user, nor in the kernel log.

(In response to Brian's comment:)
>> However, as per documentation, atomic_add_unless() returns _zero_
>> if the atomic value was originally equal to the specified *unsless* value.
>>
> Nit:                                                         unless

Thanks very much for feedback. Since it's my very first upstream
commit-proposal,
I expected that some polish would be needed.

> It might be worth pointing out in the commit log that currently isolated
> buffers end up right back on the LRU once they are released, because
> ->b_lru_ref remains elevated. Therefore, this patch essentially fixes
> that circuitous route by leaving them on the LRU as originally intended.
> Otherwise this looks Ok to me:

So the final commit message could be:
~~~
Currently the xfs_buftarg_isolate() is causing an xfs_buffer
with zero b_lru_ref, to take another trip around LRU, while
isolating buffers with non-zero b_lru_ref.

Additionally those isolated buffers end up right back on the LRU
once they are released, because ->b_lru_ref remains elevated.

Fix that circuitous route by leaving them on the LRU
as originally intended.

>> Signed-off-by: Vratislav Bendel <vbendel@...hat.com>
> Reviewed-by: Brian Foster <bfoster@...hat.com>
> ---