linux-kernel - Re: [RFC PATCH v6 3/3] arm: fix a migrating irq bug when hotplug cpu

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

Date:	Thu, 22 Oct 2015 12:13:07 +0100
From:	Russell King - ARM Linux <linux@....linux.org.uk>
To:	Yang Yingliang <yangyingliang@...wei.com>
Cc:	Geert Uytterhoeven <geert@...ux-m68k.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Mark Rutland <mark.rutland@....com>,
	Linux-sh list <linux-sh@...r.kernel.org>,
	Marc Zyngier <marc.zyngier@....com>,
	Will Deacon <will.deacon@....com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Hanjun Guo <hanjun.guo@...aro.org>,
	Jiang Liu <jiang.liu@...ux.intel.com>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>
Subject: Re: [RFC PATCH v6 3/3] arm: fix a migrating irq bug when hotplug cpu

On Thu, Oct 22, 2015 at 06:56:29PM +0800, Yang Yingliang wrote:
> I described it in v2 cover letter and kept the change history in v6
> cover letter. There is no comment on the change when patch the was
> reviewing in v2, so I thought it's ok and I kept the change in the
> next versions.

Cover letters don't always get read, neither do changelogs.

However, there's a principle here: never mix moving code around with
changes to that code.  Always move code with as few changes as possible
in one patch, and then make changes in a subsequent patch.

The "few changes as possible" means that if you need to make changes
for it to end up building in its new location, such as removing a
'static' or adding an 'EXPORT_SYMBOL' then those are fine, but the
main body of the code should remain identical, even down to style.

Any changes (such as, in this case, replacing pr_debug with pr_warn)
should be done as a distinctly separate patch so that such changes
are immediately obvious to reviewers.

> Need I send a patch to the Thomas branch to revert the change ?

I think wait for Thomas and Catalin to reply.  Your patch series is
currently merged into two different trees (Thomas' and Catalin's
trees) and what action is needed depends on how they want to handle
it.

The solutions are:
* A patch to restore the pr_debug() which Thomas applies, and Catalin
  and myself then pull Thomas' tree again, which potentially creates
  a messier history.

* Catalin drops the ARM64 change and Thomas' tree from the ARM64 tree,
  Thomas drops the original commit, and we start again doing it
  correctly.

Which is up to Catalin and Thomas.

I've dropped it from my tree as an easy way to fix the regression
on ARM for the time being, pending the outcome of deciding how to
fix this.

-- 
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
--
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/