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  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]
Date:   Thu, 21 Dec 2017 16:08:59 +0100
From:   Greg KH <>
To:     Yisheng Xie <>
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

Powered by blists - more mailing lists