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
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
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 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
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
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
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
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
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
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
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 (I
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
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
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"
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,
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,
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,
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,
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
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
On Fri, Sep 13, 2013 at 12:12 PM, Linus Torvalds
torva...@linux-foundation.org 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
On Thu, Sep 12, 2013 at 6:12 PM, Linus Torvalds
torva...@linux-foundation.org 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
On Fri, Sep 13, 2013 at 12:12 PM, Linus Torvalds
torva...@linux-foundation.org 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
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, and
On Fri, Sep 13, 2013 at 4:25 PM, Linus Torvalds
torva...@linux-foundation.org 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
On Fri, Sep 13, 2013 at 04:25:48PM -0400, Linus Torvalds wrote:
On Fri, Sep 13, 2013 at 4:00 PM, Al Viro v...@zeniv.linux.org.uk 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
On Fri, Sep 13, 2013 at 4:31 PM, Al Viro v...@zeniv.linux.org.uk 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
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 actually take the
On Fri, Sep 13, 2013 at 4:00 PM, Al Viro v...@zeniv.linux.org.uk 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
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 thing. Those we
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
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
On Tue, Sep 10, 2013 at 4:37 PM, Linus Torvalds
wrote:
>
> From a quick look, this looks pretty broken:
>
> if (list_lru_add(>d_sb->s_dentry_lru, >d_lru))
> this_cpu_inc(nr_dentry_unused);
> dentry->d_flags |= DCACHE_LRU_LIST;
>
> because if that list_lru_add() can fail, then we
On Tue, Sep 10, 2013 at 4:37 PM, Linus Torvalds
torva...@linux-foundation.org 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
On Thu, Sep 12, 2013 at 5:56 PM, Linus Torvalds
torva...@linux-foundation.org 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
On Thu, Sep 12, 2013 at 06:12:24PM -0700, Linus Torvalds wrote:
On Thu, Sep 12, 2013 at 5:56 PM, Linus Torvalds
torva...@linux-foundation.org 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
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
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
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
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
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
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:
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:
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
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:
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 -
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.
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
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
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
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
>
On Tue, 10 Sep 2013 14:38:07 +1000 Stephen Rothwell s...@canb.auug.org.au
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
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 list:
On Tue, Sep 10, 2013 at 3:27 PM, Andrew Morton
a...@linux-foundation.org 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
On Tue, 10 Sep 2013 23:29:24 +0100 Al Viro v...@zeniv.linux.org.uk 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
On Tue, Sep 10, 2013 at 03:35:20PM -0700, Andrew Morton wrote:
On Tue, 10 Sep 2013 23:29:24 +0100 Al Viro v...@zeniv.linux.org.uk 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
On Tue, 10 Sep 2013 23:59:34 +0100 Al Viro v...@zeniv.linux.org.uk 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
On Tue, 10 Sep 2013 15:35:04 -0700 Linus Torvalds
torva...@linux-foundation.org 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
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 v...@zeniv.linux.org.uk wrote:
On Tue, Sep 10, 2013 at 03:27:53PM -0700, Andrew Morton wrote:
This is rather a fiasco.
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 the
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 into
On Tue, 10 Sep 2013 23:36:24 +0100 Al Viro v...@zeniv.linux.org.uk 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 v...@zeniv.linux.org.uk wrote:
On Tue, Sep 10, 2013 at 03:27:53PM -0700, Andrew Morton wrote:
This
On Tue, Sep 10, 2013 at 3:59 PM, Al Viro v...@zeniv.linux.org.uk 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
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 (well, the
On Tue, Sep 10, 2013 at 4:53 PM, Al Viro v...@zeniv.linux.org.uk 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
On Tue, Sep 10, 2013 at 04:37:19PM -0700, Linus Torvalds wrote:
On Tue, Sep 10, 2013 at 3:59 PM, Al Viro v...@zeniv.linux.org.uk 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
Hi Linus,
On Tue, 10 Sep 2013 15:44:00 -0700 Andrew Morton a...@linux-foundation.org
wrote:
On Tue, 10 Sep 2013 15:35:04 -0700 Linus Torvalds
torva...@linux-foundation.org wrote:
So I'd (once again) suggest you base your pile of patches on the
previous stable kernel, and that
On Tue, Sep 10, 2013 at 05:01:23PM -0700, Linus Torvalds wrote:
On Tue, Sep 10, 2013 at 4:53 PM, Al Viro v...@zeniv.linux.org.uk 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
On Tue, Sep 10, 2013 at 5:30 PM, Stephen Rothwell s...@canb.auug.org.au 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
Hi Andrew,
On Tue, 10 Sep 2013 16:13:02 -0700 Andrew Morton a...@linux-foundation.org
wrote:
On Tue, 10 Sep 2013 23:59:34 +0100 Al Viro v...@zeniv.linux.org.uk wrote:
It's not that bad, actually; I think the variant I've pushed right now
(vfs.git#for-next, head at
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
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
[ 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
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
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
[ Just adding Dave Chinner to the cc list]
On Tue, 10 Sep 2013 14:09:23 +1000 Stephen Rothwell s...@canb.auug.org.au
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'
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
LRU
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
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
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
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 carry
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 from
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 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
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 up
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
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 from a
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:
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: prep work
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
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 it
...@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 Rothw
...@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, Step
1 - 100 of 156 matches
Mail list logo
