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
| ||
|
Date: Mon, 25 Dec 2017 09:09:10 +0800 From: Yisheng Xie <xieyisheng1@...wei.com> To: christophe leroy <christophe.leroy@....fr>, Guenter Roeck <linux@...ck-us.net>, Greg KH <gregkh@...uxfoundation.org> CC: <linux-kernel@...r.kernel.org>, <ysxie@...mail.com>, <ulf.hansson@...aro.org>, <linux-mmc@...r.kernel.org>, <boris.brezillon@...e-electrons.com>, <richard@....at>, <marek.vasut@...il.com>, <cyrille.pitchen@...ev4u.fr>, <linux-mtd@...ts.infradead.org>, <alsa-devel@...a-project.org>, <wim@...ana.be>, <linux-watchdog@...r.kernel.org>, <b.zolnierkie@...sung.com>, <linux-fbdev@...r.kernel.org>, <linus.walleij@...aro.org>, <linux-gpio@...r.kernel.org>, <ralf@...ux-mips.org>, <linux-mips@...ux-mips.org>, <lgirdwood@...il.com>, <broonie@...nel.org>, <tglx@...utronix.de>, <jason@...edaemon.net>, <marc.zyngier@....com>, <arnd@...db.de>, <andriy.shevchenko@...ux.intel.com>, <industrypack-devel@...ts.sourceforge.net>, <wg@...ndegger.com>, <mkl@...gutronix.de>, <linux-can@...r.kernel.org>, <mchehab@...nel.org>, <linux-media@...r.kernel.org>, <a.zummo@...ertech.it>, <alexandre.belloni@...e-electrons.com>, <linux-rtc@...r.kernel.org>, <daniel.vetter@...el.com>, <jani.nikula@...ux.intel.com>, <seanpaul@...omium.org>, <airlied@...ux.ie>, <dri-devel@...ts.freedesktop.org>, <kvalo@...eaurora.org>, <linux-wireless@...r.kernel.org>, <linux-spi@...r.kernel.org>, <tj@...nel.org>, <linux-ide@...r.kernel.org>, <bhelgaas@...gle.com>, <linux-pci@...r.kernel.org>, <devel@...verdev.osuosl.org>, <dvhart@...radead.org>, <andy@...radead.org>, <platform-driver-x86@...r.kernel.org>, <jakub.kicinski@...ronome.com>, <davem@...emloft.net>, <nios2-dev@...ts.rocketboards.org>, <netdev@...r.kernel.org>, <vinod.koul@...el.com>, <dan.j.williams@...el.com>, <dmaengine@...r.kernel.org>, <jslaby@...e.com> Subject: Re: [PATCH v3 00/27] kill devm_ioremap_nocache hi Christophe and Greg, On 2017/12/24 16:55, christophe leroy wrote: > > > Le 23/12/2017 à 16:57, Guenter Roeck a écrit : >> On 12/23/2017 05:48 AM, Greg KH wrote: >>> On Sat, Dec 23, 2017 at 06:55:25PM +0800, Yisheng Xie wrote: >>>> Hi all, >>>> >>>> When I tried to use devm_ioremap function and review related code, I found >>>> devm_ioremap and devm_ioremap_nocache is almost the same with each other, >>>> except one use ioremap while the other use ioremap_nocache. >>> >>> For all arches? Really? Look at MIPS, and x86, they have different >>> functions. >>> >> >> Both mips and x86 end up mapping the same function, but other arches don't. >> mn10300 is one where ioremap and ioremap_nocache are definitely different. > > alpha: identical > arc: identical > arm: identical > arm64: identical > cris: different <== > frv: identical > hexagone: identical > ia64: different <== > m32r: identical > m68k: identical > metag: identical > microblaze: identical > mips: identical > mn10300: different <== > nios: identical > openrisc: different <== > parisc: identical > riscv: identical > s390: identical > sh: identical > sparc: identical > tile: identical > um: rely on asm/generic > unicore32: identical > x86: identical > asm/generic (no mmu): identical Wow, that's correct, sorry for I have just checked the main archs, I means x86,arm, arm64, mips. However, I stall have no idea about why these 4 archs want different ioremap function with others. Drivers seems cannot aware this? If driver call ioremap want he really want for there 4 archs, cache or nocache? > > So 4 among all arches seems to have ioremap() and ioremap_nocache() being different. > > Could we have a define set by the 4 arches on which ioremap() and ioremap_nocache() are different, something like HAVE_DIFFERENT_IOREMAP_NOCACHE ? Then, what the HAVE_DIFFERENT_IOREMAP_NOCACHE is uesed for ? Thanks Yisheng > > Christophe > >> >> Guenter >> >>>> While ioremap's >>>> default function is ioremap_nocache, so devm_ioremap_nocache also have the >>>> same function with devm_ioremap, which can just be killed to reduce the size >>>> of devres.o(from 20304 bytes to 18992 bytes in my compile environment). >>>> >>>> I have posted two versions, which use macro instead of function for >>>> devm_ioremap_nocache[1] or devm_ioremap[2]. And Greg suggest me to kill >>>> devm_ioremap_nocache for no need to keep a macro around for the duplicate >>>> thing. So here comes v3 and please help to review. >>> >>> I don't think this can be done, what am I missing? These functions are >>> not identical, sorry for missing that before. Never mind, I should checked all the arches, sorry about that. >>> >>> thanks, >>> >>> greg k-h >>> >> >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-watchdog" in >> the body of a message to majordomo@...r.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html > > --- > L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast. > https://www.avast.com/antivirus > > > . >
Powered by blists - more mailing lists