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
[ 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
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
...@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
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
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 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
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
43 matches
Mail list logo
