linux-kernel - Re: [PATCH] mm/vmscan: remove prefetch_prev_lru

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] [day] [month] [year] [list]

Date:   Thu, 16 Jan 2020 15:37:35 -0800
From:   Andrew Morton <akpm@...ux-foundation.org>
To:     Qian Cai <cai@....pw>
Cc:     Alex Shi <alex.shi@...ux.alibaba.com>, linux-mm@...ck.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] mm/vmscan: remove prefetch_prev_lru_page

On Thu, 16 Jan 2020 07:26:23 -0500 Qian Cai <cai@....pw> wrote:

> 
> 
> > On Jan 14, 2020, at 9:33 PM, Alex Shi <alex.shi@...ux.alibaba.com> wrote:
> > 
> > 
> > 
> >> 在 2020/1/14 下午9:46, Qian Cai 写道:
> >> 
> >> 
> >>>> On Jan 14, 2020, at 7:55 AM, Alex Shi <alex.shi@...ux.alibaba.com> wrote:
> >>> 
> >>> This macro are never used in git history. So better to remove.
> >> 
> >> When removing unused thingy, it is important to figure out which commit introduced it in the first place and Cc the relevant people in that commit.
> >> 
> > 
> > Thanks fore reminder, Qian!
> > 
> > This macro was introduced in 1da177e4c3f4 Linux-2.6.12-rc2, no author or commiter could be found.
> 
> Looks a bit deeper for this, and I am not sure if it is necessary to remove it especially this does not cause any complication warning noise, because the macro looks like a part of API design to have a pair of both read and write version, even though only the write version is used at the moment.
> 
> In theory,  there could be users for the read version in the future, and then it needs to be added back.

Sure.  A problem with leaving it in place is that this leads people to
assume it is tested, which it presumably is not.

I don't think there's any particular downside either way, really.  But
it's presently cruft so I'm inclined to remove it.  If someone has a
need then they can add it back (presumbly reimplement it, actually) and
test it then.