linux-kernel - Re: [PATCH v2] devres: use MACRO instead of function for devm

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20171221150859.GA13518@kroah.com>
Date:   Thu, 21 Dec 2017 16:08:59 +0100
From:   Greg KH <gregkh@...uxfoundation.org>
To:     Yisheng Xie <xieyisheng1@...wei.com>
Cc:     thomas.lendacky@....com, lorenzo.pieralisi@....com, bp@...e.de,
        tglx@...utronix.de, kstewart@...uxfoundation.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] devres: use MACRO instead of function for devm_ioremap

On Thu, Dec 21, 2017 at 07:50:16PM +0800, Yisheng Xie wrote:
> Hi Greg,
> 
> On 2017/12/19 18:52, Yisheng Xie wrote:
> > Hi Greg,
> > 
> > On 2017/12/19 16:46, Greg KH wrote:
> >> On Sat, Nov 25, 2017 at 05:23:33PM +0800, Yisheng Xie wrote:
> >>> Default ioremap is ioremap_nocache, so devm_ioremap has the same function
> >>> with devm_ioremap_nocache, which may just be killed. However, there are
> >>> many places which use devm_ioremap_nocache, while many use devm_ioremap.
> >>>
> >>> This patch is to use MACRO for devm_ioremap, which will reduce the size of
> >>> devres.o from 206824 Bytes to 203768 Bytes.
> >>
> >> Ok, the idea is good, but why not just get rid of the callers of
> >> devm_ioremap_nocache() instead and have them call devm_ioremap() if they
> >> really are the same thing?  No need to keep a macro around for the
> >> duplicate thing, just delete the one and things are much better.
> > 
> > Yeah, I thought someone may still want to use devm_ioremap_nocache().
> > 
> > I will take your suggestion in next version and kill devm_ioremap_nocache().
> 
> I am trying to kill devm_ioremap_nocache() as your suggestion, however, if
> put it as a single patch it will be a patch really big (the patch file may
> have more than 1k lines), for many places will use devm_ioremap_nocache().
> But it also makes me fell uncomfortable to separate it to so many litter
> patchs for a litter optimize. :)
> 
> So I put the v3 patch in the attachment, please let me know if I should
> separate it to litter patchs :)

Yes, of course you need to break it up into smaller pieces.

One per subsystem, make a large patch series, send it out, get a few
merged, refresh, send again, and keep going until all of the users are
out of the tree and then drop the old api call.  That's how we do this
all the time, should take about 1 kernel release if you are quick and
lucky :)

hope this helps,

greg k-h