[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <bd7abc05-da24-8c65-c93e-ec30fe582233@suse.cz>
Date: Wed, 12 Apr 2017 22:53:41 +0200
From: Vlastimil Babka <vbabka@...e.cz>
To: Stephen Rothwell <sfr@...b.auug.org.au>,
Andrew Morton <akpm@...ux-foundation.org>,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...e.hu>, "H. Peter Anvin" <hpa@...or.com>,
Peter Zijlstra <peterz@...radead.org>
Cc: Linux-Next Mailing List <linux-next@...r.kernel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
NeilBrown <neilb@...e.com>, Michal Hocko <mhocko@...nel.org>
Subject: Re: linux-next: manual merge of the akpm-current tree with the tip
tree
On 12.4.2017 8:46, Stephen Rothwell wrote:
> Hi Andrew,
>
> Today's linux-next merge of the akpm-current tree got conflicts in:
>
> drivers/block/nbd.c
> drivers/scsi/iscsi_tcp.c
> net/core/dev.c
> net/core/sock.c
>
> between commit:
>
> 717a94b5fc70 ("sched/core: Remove 'task' parameter and rename tsk_restore_flags() to current_restore_flags()")
>
> from the tip tree and commit:
>
> 61d5ad5b2e8a ("treewide: convert PF_MEMALLOC manipulations to new helpers")
>
> from the akpm-current tree.
Yeah, the first patch from Neil renames a function (as its subject says) and the
second patch from me converts most of its users to new helpers specific to the
PF_MEMALLOC flags.
> I fixed it up (the latter is just a superset of the former, so I used
It's not a complete superset though, more on that below.
> that) and can carry the fix as necessary. This is now fixed as far as
> linux-next is concerned, but any non trivial conflicts should be mentioned
> to your upstream maintainer when your tree is submitted for merging.
> You may also want to consider cooperating with the maintainer of the
> conflicting tree to minimise any particularly complex conflicts.
Hmm I could redo my patch on top of Neil's patch, but then Andrew would have to
carry Neil's patch as well just to have a working mmotm? And then make sure to
send my patch (but not Neil's) only after the tip tree is pulled? Would that
work for the maintainers involved?
> It looks like there may be more instances that the latter patch should
> update.
I see two remaining instances of current_restore_flags(). One in __do_softirq()
is even for PF_MEMALLOC, but there the flag is cleared first and then set back,
which is opposite of the common case that my helpers provide. The other in nfsd
is for PF_LESS_THROTTLE which is not common enough to earn own helpers yet. IIRC
Neil originally wanted to add a new one?
Powered by blists - more mailing lists