Hi all,
Today's linux-next merge of the akpm tree got a conflict in:
arch/arm64/kernel/setup.c
between commit:
d91680e687f4 ("arm64: Fix /proc/iomem for reserved but not memory regions")
from Linus' tree and patch:
"memblock: stop using implicit alignment to SMP_CACHE_BYTES"
from the a
Hi all,
Today's linux-next merge of the akpm tree got a conflict in:
arch/arm64/kernel/setup.c
between commit:
d91680e687f4 ("arm64: Fix /proc/iomem for reserved but not memory regions")
from Linus' tree and patch:
"memblock: replace alloc_bootmem_low with memblock_alloc_low (2)"
from
Hi Andrew,
Today's linux-next merge of the akpm tree got a conflict in:
ipc/mqueue.c
between commit:
cfb2f6f6e0ba ("Revert "mqueue: switch to on-demand creation of internal
mount"")
from Linus' tree and patch:
"ipc/mqueue: add missing error code in init_mqueue_fs()"
from the akpm tree
Hi Andrew,
Today's linux-next merge of the akpm tree got a conflict in:
include/linux/radix-tree.h
between commit:
ea07b862ac8e ("mm: workingset: fix use-after-free in shadow node shrinker")
from Linus' tree and patch:
"Reimplement IDR and IDA using the radix tree"
from the akpm tree.
Hi Andrew,
Today's linux-next merge of the akpm tree got a conflict in:
lib/radix-tree.c
between commit:
2b41226b39b6 ("Revert "radix tree test suite: fix compilation"")
from Linus' tree and patch:
"reimplement IDR and IDA using the radix tree"
from the akpm tree.
I fixed it up (I add
Hi Andrew,
Today's linux-next merge of the akpm tree got a conflict in:
arch/x86/mm/mpx.c
between commit:
a89652769470 ("x86/mpx: Do not set ->vm_ops on MPX VMAs")
from Linus' tree and patch:
"mm, mpx: add "vm_flags_t vm_flags" arg to do_mmap_pgoff()"
from the akpm tree.
I fixed it up
On Fri, Sep 13, 2013 at 4:00 PM, Al Viro wrote:
\>
> It is right - for one thing, we are holding the lock on that LRU list,
> so list_lru_del() would deadlock right there. For another, the same
> list_lru_walk (OK, list_lru_walk_node()) will do ->nr_items decrement
> when we return LRU_REMOVED to
On Fri, Sep 13, 2013 at 09:00:00PM +0100, Al Viro wrote:
> > - d_lru_shrink_move: move from the "global" lru list to a private shrinker
> > list
> > - d_shrink_add/del: fairly obvious.
> >
> > And then "denty_lru_add/del" that actually take the current state into
> > account and do the right th
On Fri, Sep 13, 2013 at 09:18:03PM +0100, Al Viro wrote:
> On Fri, Sep 13, 2013 at 09:00:00PM +0100, Al Viro wrote:
> > > - d_lru_shrink_move: move from the "global" lru list to a private
> > > shrinker list
> > > - d_shrink_add/del: fairly obvious.
> > >
> > > And then "denty_lru_add/del" that
On Fri, Sep 13, 2013 at 4:31 PM, Al Viro wrote:
> On Fri, Sep 13, 2013 at 04:25:48PM -0400, Linus Torvalds wrote:
>>
>> Yes. And I found the opposite bug in one place: when we are collecting
>> dentries by walking the parents etc, we do *not* hold the global RCU
>> lock,
>
> ??? LRU list lock, pr
On Fri, Sep 13, 2013 at 04:25:48PM -0400, Linus Torvalds wrote:
> On Fri, Sep 13, 2013 at 4:00 PM, Al Viro wrote:
> \>
> > It is right - for one thing, we are holding the lock on that LRU list,
> > so list_lru_del() would deadlock right there. For another, the same
> > list_lru_walk (OK, list_lru
On Fri, Sep 13, 2013 at 4:25 PM, Linus Torvalds
wrote:
>
> Yes. And I found the opposite bug in one place: when we are collecting
> dentries by walking the parents etc, we do *not* hold the global RCU
> lock, so we cannot use the "d_lru_shrink_list()" thing after all. It's
> correct as far as the
On Fri, Sep 13, 2013 at 12:12:20PM -0700, Linus Torvalds wrote:
> It tries to consolidate the dentry LRU stuff into a few helper
> functions that right now have anal checking of the flags. Maybe I
> overdid it, but the code was really confusing, and I think we got the
> free dentry counts wrong, a
On Fri, Sep 13, 2013 at 12:12 PM, Linus Torvalds
wrote:
>
> - d_lru_isolate: this is when the LRU callbacks ask us to remove the
> entry from the list. This is different from d_lru_del() only in that
> it uses the raw list removal, not the lru list helper function. I'm
> not sure that's right, bu
On Thu, Sep 12, 2013 at 6:12 PM, Linus Torvalds
wrote:
>
> Damn, the code is too confused. I have to go to a highschool parent
> back-to-school meeting, so I won't get to this until maybe on a plane
> tomorrow. Al, can you please give this a look?
I'm on a plane. I have gogo. Here's my current TO
On Fri, Sep 13, 2013 at 12:12 PM, Linus Torvalds
wrote:
>
> Does it work? Who knows.. But *if* it works, I think it has a higher
> chance of getting all the rules for bits and free object counting
> right.
>
> Somebody not in a plane please double-check my low-oxygen-pressure thinking..
Ok, it se
On Thu, Sep 12, 2013 at 06:12:24PM -0700, Linus Torvalds wrote:
> On Thu, Sep 12, 2013 at 5:56 PM, Linus Torvalds
> wrote:
> >
> > I'll walk through the code, it looked suspicious. Maybe there's
> > something subtle that makes it work, but I don't see it.
>
> Btw, it's not just the DCACHE_LRU_LIS
On Thu, Sep 12, 2013 at 5:56 PM, Linus Torvalds
wrote:
>
> I'll walk through the code, it looked suspicious. Maybe there's
> something subtle that makes it work, but I don't see it.
Btw, it's not just the DCACHE_LRU_LIST bit. The games with
"nr_dentry_unused" look totally broken too. It's decreme
On Tue, Sep 10, 2013 at 4:37 PM, Linus Torvalds
wrote:
>
> From a quick look, this looks pretty broken:
>
> if (list_lru_add(&dentry->d_sb->s_dentry_lru, &dentry->d_lru))
> this_cpu_inc(nr_dentry_unused);
> dentry->d_flags |= DCACHE_LRU_LIST;
>
> because if that list_lru_add() can
Hi Andrew,
On Tue, 10 Sep 2013 16:13:02 -0700 Andrew Morton
wrote:
>
> On Tue, 10 Sep 2013 23:59:34 +0100 Al Viro wrote:
> >
> > It's not that bad, actually; I think the variant I've pushed right now
> > (vfs.git#for-next, head at f5e1dd34561e0fb06400b378d595198918833021) should
> > be doing th
On Tue, Sep 10, 2013 at 5:30 PM, Stephen Rothwell wrote:
>
> So, Andrew, you should be able to just about send those 375 patches to
> Linus (I know that there may be some fix folding to do before that) and
> have him apply them on top of v3.11-rc7-14-gfa8218d in a separate branch
> and then merge
On Tue, Sep 10, 2013 at 05:01:23PM -0700, Linus Torvalds wrote:
> On Tue, Sep 10, 2013 at 4:53 PM, Al Viro wrote:
> >
> > list_lru_add() can fail if it's already on the list; leaving the counter
> > alone should've been conditional on that, setting the flag - no. Said
> > that, it probably should
Hi Linus,
On Tue, 10 Sep 2013 15:44:00 -0700 Andrew Morton
wrote:
>
> On Tue, 10 Sep 2013 15:35:04 -0700 Linus Torvalds
> wrote:
>
> > So I'd (once again) suggest you base your pile of patches on the
> > previous stable kernel, and that linux-next take it *first* rather
> > than take it last.
On Tue, Sep 10, 2013 at 04:37:19PM -0700, Linus Torvalds wrote:
> On Tue, Sep 10, 2013 at 3:59 PM, Al Viro wrote:
> >
> > It's not that bad, actually; I think the variant I've pushed right now
> > (vfs.git#for-next, head at f5e1dd34561e0fb06400b378d595198918833021) should
> > be doing the right th
On Tue, Sep 10, 2013 at 04:13:02PM -0700, Andrew Morton wrote:
> > in -next from "fs: bump inode and dentry counters to long" on to the
> > end of queue.
>
> That's the correct starting point. The end point should be
> "staging/lustre/libcfs: cleanup linux-mem.h".
... which is the end of queue (
On Tue, Sep 10, 2013 at 4:53 PM, Al Viro wrote:
>
> list_lru_add() can fail if it's already on the list; leaving the counter
> alone should've been conditional on that, setting the flag - no. Said
> that, it probably should be WARN_ON(!...); this_cpu_inc(); ... |= ...;
That WARN_ON_(!..) might i
On Tue, Sep 10, 2013 at 3:59 PM, Al Viro wrote:
>
> It's not that bad, actually; I think the variant I've pushed right now
> (vfs.git#for-next, head at f5e1dd34561e0fb06400b378d595198918833021) should
> be doing the right thing. It ought to cover everything in your branch
> in -next from "fs: bum
On Tue, 10 Sep 2013 23:36:24 +0100 Al Viro wrote:
> On Tue, Sep 10, 2013 at 03:35:20PM -0700, Andrew Morton wrote:
> > On Tue, 10 Sep 2013 23:29:24 +0100 Al Viro wrote:
> >
> > > On Tue, Sep 10, 2013 at 03:27:53PM -0700, Andrew Morton wrote:
> > >
> > > > This is rather a fiasco. "vfs: reorga
On Tue, Sep 10, 2013 at 03:41:16PM -0700, Andrew Morton wrote:
> Obtained from where? There are a whole pile of fixes resulting from
> review and linux-next testing. Are they included?
-next and yes. The trivial ones - folded into the commits they are fixing
(I mean, ones directly following th
On Tue, 10 Sep 2013 15:35:04 -0700 Linus Torvalds
wrote:
> So I'd (once again) suggest you base your pile of patches on the
> previous stable kernel, and that linux-next take it *first* rather
> than take it last.
That's what we're now doing. But this particular patchset was
different because
On Tue, Sep 10, 2013 at 11:36:24PM +0100, Al Viro wrote:
> On Tue, Sep 10, 2013 at 03:35:20PM -0700, Andrew Morton wrote:
> > On Tue, 10 Sep 2013 23:29:24 +0100 Al Viro wrote:
> >
> > > On Tue, Sep 10, 2013 at 03:27:53PM -0700, Andrew Morton wrote:
> > >
> > > > This is rather a fiasco. "vfs: r
On Tue, Sep 10, 2013 at 11:48:23PM +0100, Al Viro wrote:
> On Tue, Sep 10, 2013 at 03:41:16PM -0700, Andrew Morton wrote:
>
> > Obtained from where? There are a whole pile of fixes resulting from
> > review and linux-next testing. Are they included?
>
> -next and yes. The trivial ones - folded
On Tue, 10 Sep 2013 23:59:34 +0100 Al Viro wrote:
> On Tue, Sep 10, 2013 at 11:48:23PM +0100, Al Viro wrote:
> > On Tue, Sep 10, 2013 at 03:41:16PM -0700, Andrew Morton wrote:
> >
> > > Obtained from where? There are a whole pile of fixes resulting from
> > > review and linux-next testing. Are
On Tue, Sep 10, 2013 at 03:35:20PM -0700, Andrew Morton wrote:
> On Tue, 10 Sep 2013 23:29:24 +0100 Al Viro wrote:
>
> > On Tue, Sep 10, 2013 at 03:27:53PM -0700, Andrew Morton wrote:
> >
> > > This is rather a fiasco. "vfs: reorganize dput() memory accesses" made
> > > rather a mess of a 46 pa
On Tue, 10 Sep 2013 23:29:24 +0100 Al Viro wrote:
> On Tue, Sep 10, 2013 at 03:27:53PM -0700, Andrew Morton wrote:
>
> > This is rather a fiasco. "vfs: reorganize dput() memory accesses" made
> > rather a mess of a 46 patch series which has been under development and
> > test for two cycles so
On Tue, Sep 10, 2013 at 3:27 PM, Andrew Morton
wrote:
>
> This is rather a fiasco. "vfs: reorganize dput() memory accesses" made
> rather a mess of a 46 patch series which has been under development and
> test for two cycles so far.
Andrew, *please* don't do the insane rebasing you keep on doing
On Tue, Sep 10, 2013 at 03:27:53PM -0700, Andrew Morton wrote:
> This is rather a fiasco. "vfs: reorganize dput() memory accesses" made
> rather a mess of a 46 patch series which has been under development and
> test for two cycles so far.
Check vfs.git#for-next...
--
To unsubscribe from this li
On Tue, 10 Sep 2013 14:38:07 +1000 Stephen Rothwell
wrote:
> Hi Andrew,
>
> Today's linux-next merge of the akpm tree got a conflict in fs/dcache.c
> between commit 8aab6a27332b ("vfs: reorganize dput() memory accesses")
> from Linus' tree and commit "dcache: convert to use new lru list
> infra
Hi Andrew,
Today's linux-next merge of the akpm tree got a conflict in fs/dcache.c
between commit 8aab6a27332b ("vfs: reorganize dput() memory accesses")
from Linus' tree and commit "dcache: convert to use new lru list
infrastructure" from the akpm tree.
/me mutters about development happening du
Hi Andrew,
Today's linux-next merge of the akpm tree got a conflict in fs/dcache.c
between commits 8aab6a27332b ("vfs: reorganize dput() memory accesses")
and 0d98439ea3c6 ("vfs: use lockred "dead" flag to mark unrecoverably
dead dentries") from Linus' tree and commit "dcache: remove dentries from
[ Just adding Dave Chinner to the cc list]
On Tue, 10 Sep 2013 14:09:23 +1000 Stephen Rothwell
wrote:
>
> Hi Andrew,
>
> Today's linux-next merge of the akpm tree got a conflict in fs/dcache.c
> between commit 8aab6a27332b ("vfs: reorganize dput() memory accesses")
> from Linus' tree and commit
Hi Andrew,
Today's linux-next merge of the akpm tree got a conflict in fs/dcache.c
between commit 8aab6a27332b ("vfs: reorganize dput() memory accesses")
from Linus' tree and commit "dentry: move to per-sb LRU locks" from the
akpm tree.
I fixed it up (I think - see below) and can carry the fix as
Hi Andrew,
Today's linux-next merge of the akpm tree got a conflict in fs/dcache.c
between commit db14fc3abcd5 ("vfs: add d_walk()") from Linus' tree and
commit "dcache: convert to use new lru list infrastructure" from the akpm
tree.
I fixed it up (hopefully - see below) and can carry the fix as
Hi Andrew,
Today's linux-next merge of the akpm tree got a conflict in fs/dcache.c
between commit db14fc3abcd5 ("vfs: add d_walk()") from Linus' tree and
commit "shrinker: convert superblock shrinkers to new API" from the akpm
tree.
I fixed it up (I just used the version of shrink_dcache_parent f
Hi Andrew,
Today's linux-next merge of the akpm tree got a conflict in fs/internal.h
between commit eed810076685 ("vfs: check unlinked ancestors before
mount") from Linus' tree and commit "shrinker: convert superblock
shrinkers to new API" from the akpm tree.
I fixed it up (see below) and can ca
Hi Andrew,
Today's linux-next merge of the akpm tree got a conflict in fs/dcache.c
between commit 98474236f72e ("vfs: make the dentry cache use the lockref
infrastructure") from Linus' tree and commit "dcache: remove dentries
from LRU before putting on dispose list" from the akpm tree.
I fixed it
Hi Andrew,
Today's linux-next merge of the akpm tree got a conflict in fs/aio.c
between commit 03e04f048d27 ("aio: fix kioctx not being freed after
cancellation at exit time") from Linus' tree and commit "aio: reqs_active
-> reqs_available" from the akpm tree.
I fixed it up (see below - taken fro
Quoting Stephen Rothwell (2013-05-20 00:04:49)
> Hi Andrew,
>
> Today's linux-next merge of the akpm tree got conflicts in
> fs/btrfs/inode.c and fs/btrfs/volumes.c between commit 9be3395bcd4a
> ("Btrfs: use a btrfs bioset instead of abusing bio internals") from
> Linus' tree and commit "block: pr
Hi Andrew,
Today's linux-next merge of the akpm tree got conflicts in
fs/btrfs/inode.c and fs/btrfs/volumes.c between commit 9be3395bcd4a
("Btrfs: use a btrfs bioset instead of abusing bio internals") from
Linus' tree and commit "block: prep work for batch completion" from the
akpm tree.
I fixed
...@vger.kernel.org]; LKML [linux-kernel@vger.kernel.org]; Jeff Layton
[jlay...@redhat.com]; Al Viro [v...@zeniv.linux.org.uk]
Subject: Re: linux-next: manual merge of the akpm tree with Linus' tree
On Sun, May 12, 2013 at 7:11 PM, Eric Paris wrote:
> On Mon, 2013-05-13 at 12:07 +1000, Stephen
...@vger.kernel.org]; LKML [linux-kernel@vger.kernel.org]; Jeff Layton
[jlay...@redhat.com]; Al Viro [v...@zeniv.linux.org.uk]
Subject: Re: linux-next: manual merge of the akpm tree with Linus' tree
On Sun, May 12, 2013 at 7:11 PM, Eric Paris wrote:
> On Mon, 2013-05-13 at 12:07 +1000,
On Sun, May 12, 2013 at 7:11 PM, Eric Paris wrote:
> On Mon, 2013-05-13 at 12:07 +1000, Stephen Rothwell wrote:
>> Hi Andrew,
>>
>> Today's linux-next merge of the akpm tree got a conflict in
>> kernel/auditsc.c between commit b24a30a73054 ("audit: fix event coverage
>> of AUDIT_ANOM_LINK") from L
Hi Eric,
On Sun, 12 May 2013 22:11:10 -0400 Eric Paris wrote:
>
> I thought I sent you a note asking for audit to get pulled into -next
> quite a while back. I'll resend...
You sent an email on Jan 4:
> I know that Al hates audit so I created a new audit tree and decided to
> start trying to a
On Mon, 2013-05-13 at 12:07 +1000, Stephen Rothwell wrote:
> Hi Andrew,
>
> Today's linux-next merge of the akpm tree got a conflict in
> kernel/auditsc.c between commit b24a30a73054 ("audit: fix event coverage
> of AUDIT_ANOM_LINK") from Linus' tree and commit "audit: fix mq_open and
> mq_unlink
Hi Andrew,
Today's linux-next merge of the akpm tree got a conflict in
kernel/auditsc.c between commit b24a30a73054 ("audit: fix event coverage
of AUDIT_ANOM_LINK") from Linus' tree and commit "audit: fix mq_open and
mq_unlink to add the MQ root as a hidden parent audit_names record" from
the akpm
Hi Andrew,
Today's linux-next merge of the akpm tree got a conflict in ipc/msg.c
between commit 8ac6ed5857c8 ("ipc: implement MSG_COPY as a new receive
mode") from Linus' tree and commit "revert "ipc: don't allocate a copy
larger than max"" from the akpm tree.
I fixed it up (see below) and can ca
Hi Andrew,
Today's linux-next merge of the akpm tree got a conflict in fs/aio.c
between commit 91d80a84bbc8 ("aio: fix possible invalid memory access
when DEBUG is enabled") from Linus' tree and commit "aio: dprintk() ->
pr_debug()" from the akpm tree.
I fixed it up (see below) and can carry the
Hi Andrew,
Today's linux-next merge of the akpm tree got a conflict in fs/bio.c
between commit 0a82a8d132b2 ("Revert "block: add missing
block_bio_complete() tracepoint"") from Linus' tree and commit "block,
aio: batch completion for bios/kiocbs" from the akpm tree.
I fixed it up (see below) and
Hi Andrew,
Today's linux-next merge of the akpm tree got a conflict in
kernel/kthread.c between commit f2530dc71cf0 ("kthread: Prevent unpark
race which puts threads on the wrong cpu") from Linus' tree and commit
"kthread: kill task_get_live_kthread()" from the akpm tree.
I fixed it up (see below
Hi Andrew,
Today's linux-next merge of the akpm tree got a conflict in ipc/msg.c
between commit 2dc958fa2fe6 ("ipc: set msg back to -EAGAIN if copy wasn't
performed") from Linus' tree and commit "ipc: remove msg handling from
queue scan" from the akpm tree.
I fixed it up (I think - see below) and
Hi Andrew,
Today's linux-next merge of the akpm tree got a conflict in
fs/proc/inode.c between commit ("vfs,proc: guarantee unique inodes
in /proc") from Linus' tree and commit
"procfs-improve-scaling-in-proc-v5" from the akpm tree.
I fixed it up (see below) and can carry the fix as necessary (n
Hi Andrew,
Today's linux-next merge of the akpm tree got a conflict in mm/shmem.c
between commit 26567cdbbf1a ("fix nommu breakage in shmem.c") from Linus'
tree and commit "shmem-fix-build-regression-fix" from the akpm tree.
I fixed it up (I used the latter version - see the full new version
belo
Hi Andrew,
Today's linux-next merge of the akpm tree got conflicts in
include/linux/mempolicy.h and mm/mempolicy.c between commit 42288fe366c4
("mm: mempolicy: Convert shared_policy mutex to spinlock") from Linus'
tree and commit "mm, mempolicy: introduce spinlock to read shared policy
tree" from
On 12/11/2012 09:22 AM, Stephen Rothwell wrote:
> Hi Andrew,
>
> Today's linux-next merge of the akpm tree got a conflict in
> include/linux/gfp.h between commit caf491916b1c ("Revert "revert "Revert
> "mm: remove __GFP_NO_KSWAPD""" and associated damage") from Linus' tree
> and commit "mm: add a
Hi Andrew,
Today's linux-next merge of the akpm tree got a conflict in
include/linux/gfp.h between commit caf491916b1c ("Revert "revert "Revert
"mm: remove __GFP_NO_KSWAPD""" and associated damage") from Linus' tree
and commit "mm: add a reminder comment for __GFP_BITS_SHIFT" from the
akpm tree.
Hi Andrew,
Today's linux-next merge of the akpm tree got a conflict in
include/linux/gfp.h between commit caf491916b1c ("Revert "revert "Revert
"mm: remove __GFP_NO_KSWAPD""" and associated damage") from Linus' tree
and commit "mm: add a __GFP_KMEMCG flag" from the akpm tree.
I fixed it up (see b
Hi Andrew,
Today's linux-next merge of the akpm tree got a conflict in mm/vmscan.c
between commit c702418f8a2f ("mm: vmscan: do not keep kswapd looping
forever due to individual uncompactable zones") from Linus' tree and
commit "mm: use IS_ENABLED(CONFIG_COMPACTION) instead of
COMPACTION_BUILD" fr
Hi Andrew,
Today's linux-next merge of the akpm tree got a conflict in
include/linux/percpu-rwsem.h between commit 4b05a1c74d1c ("percpu-rwsem:
use synchronize_sched_expedited") from Linus' tree and commit
"percpu_rw_semaphore: reimplement to not block the readers unnecessarily"
from the akpm tree
On Mon, Nov 26, 2012 at 8:48 PM, Stephen Rothwell wrote:
> Hi Andrew,
>
> Today's linux-next merge of the akpm tree got a conflict in
> drivers/net/ethernet/jme.c between commit 71c6c837a0fe ("drivers/net: fix
> tasklet misuse issue") from Linus' tree and commit "tasklet: ignore
> disabled taskle
Hi Andrew,
Today's linux-next merge of the akpm tree got a conflict in mm/highmem.c
between commit 498c22802123 ("mm: highmem: don't treat PKMAP_ADDR
(LAST_PKMAP) as a highmem address") from Linus' tree and commit "mm,
highmem: use PKMAP_NR() to calculate an index of pkmap" from the akpm
tree.
I
Hi Andrew,
Today's linux-next merge of the akpm tree got a conflict in
drivers/net/ethernet/jme.c between commit 71c6c837a0fe ("drivers/net: fix
tasklet misuse issue") from Linus' tree and commit "tasklet: ignore
disabled tasklet in tasklet_action()" from the akpm tree.
I am not sure what to do
Hi Andrew,
Today's linux-next merge of the akpm tree got a conflict in
mm/page_alloc.c between commit 5576646f3c1a ("revert "mm: fix-up zone
present pages"") from Linus' tree and commit "mm: fix a regression with
HIGHMEM" from the akpm tree.
I fixed it up (by dropping the akpm tree patch) and can
Hi Stephen,
On Mon, Oct 15, 2012 at 03:07:28AM +0100, Stephen Rothwell wrote:
> Today's linux-next merge of the akpm tree got a conflict in
> arch/arm64/include/asm/unistd32.h between commit f3d447a97f24 ("arm64: Do
> not include asm/unistd32.h in asm/unistd.h") from Linus' tree and commit
> "comp
Hi Andrew,
Today's linux-next merge of the akpm tree got a conflict in
arch/arm64/include/asm/unistd32.h between commit f3d447a97f24 ("arm64: Do
not include asm/unistd32.h in asm/unistd.h") from Linus' tree and commit
"compat: generic compat_sys_sched_rr_get_interval implementation" from
the akpm
Hi Andrew,
Today's linux-next merge of the akpm tree got a conflict in
drivers/mtd/mtdchar.c between commit 9c603e53d380 ("mtdchar: fix offset
overflow detection") from Linus' tree and commit "mm: kill vma flag
VM_RESERVED and mm->reserved_vm counter" from the akpm tree.
I fixed it up (see below)
On Wed, Aug 22, 2012 at 03:59:41PM +1000, Stephen Rothwell wrote:
> Hi Andrew,
>
> Today's linux-next merge of the akpm tree got a conflict in
> mm/page_alloc.c between commit c67fe3752abe ("mm: compaction: Abort async
> compaction if locks are contended or taking too long") from Linus' tree
> and
Hi Andrew,
Today's linux-next merge of the akpm tree got a conflict in
mm/page_alloc.c between commit c67fe3752abe ("mm: compaction: Abort async
compaction if locks are contended or taking too long") from Linus' tree
and commit "mm: remove __GFP_NO_KSWAPD" from the akpm tree.
I fixed it up (see b
Hi Andrew,
Today's linux-next merge of the akpm tree got a conflict in
fs/btrfs/relocation.c between commit 23291a044c31 ("Btrfs: fix error
handling in __add_reloc_root()") from Linus' tree and commit "btrfs: use
printk_get_level and printk_skip_level, add __printf, fix fallout" from
the akpm tree
78 matches
Mail list logo
