linux-kernel - Re: [PATCH v3 1/2] clocksource: Update to the newer memory functions.

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]

Message-ID: <alpine.DEB.2.11.1409302229400.4455@nanos>
Date:	Tue, 30 Sep 2014 23:20:45 +0200 (CEST)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	Xiubo Li <Li.Xiubo@...escale.com>
cc:	daniel.lezcano@...aro.org, linux-kernel@...r.kernel.org,
	john.stultz@...aro.org
Subject: Re: [PATCH v3 1/2] clocksource: Update to the newer memory
 functions.

On Tue, 30 Sep 2014, Xiubo Li wrote:

> Use ioread{16,32} instead of read{w,l}_relaxed.
> 
> For read{w,l}_relaxed accessor, if one arch has its own defination,
> then used it. Or will use the generic one, which will be read as LE
> endian as default.
>  
> For some ARCHes, such PowerPC, if using the clocksource mmio, the
> read{w,l}_relaxed will couldn't be used directly. There must be its
> own BE accessor in its individual clocksource driver.
>
> The ioread{16,32} will be read as LE endian as default if the arch
> hasn't any defination of it too, like read{w,l}_relaxed do.
> 
> To prepare supporting the BE APIs and to be more unified with them,
> using ioread{16,32}[be] is a good chioce here.

This is complete nonsense. I asked you to split this change out and
provide a very reasonable changelog for it in the hope that you would
start to think about what the difference between read*, read*_relaxed
and ioread* are.

I bet you did not even try to think about it for a split second.

You just mechanically split out the changes and dumped your completely
incompetent opinion how these interfaces work and why they are there
in the first place into a uncomprehensible changelog.

Try again, once you understood the semantics of the interfaces and a
proper explanation why inflicting a massive performance hit on most
existing users seems to be a brilliant idea.

Once you've done that use that acquired knowledge to look at your
proposed BE functions and figure out why they are wrong as well.

Thanks,

	tglx
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/