public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Andreas Gruenbacher <agruen@suse.de>
To: Akinobu Mita <amgta@yacht.ocn.ne.jp>, Andrew Morton <akpm@zip.com.au>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH] mb_cache_shrink() frees unexpected caches
Date: Sat, 16 Jul 2005 03:44:05 +0200	[thread overview]
Message-ID: <200507160344.06235.agruen@suse.de> (raw)
In-Reply-To: <1121440067.4137.2.camel@localhost.localdomain>

On Friday 15 July 2005 17:07, Akinobu Mita wrote:
> 2005-07-15 (Fri) 16:36 +0200  Andreas Gruenbacher wrote:
> > The cache parameter could indeed be removed. Not that it would matter
> > much...
>
> Currently, mbcache is used only for xattr on ext2/ext3 and reiserfs.
> In other words, only one type of mbcache is used per-filesystem.
> So any problems don't happen without the patch I sent.

Actually, reiserfs doesn't use the mbcache, so this can go:

Index: linux-2.6.12/fs/reiserfs/xattr.c
===================================================================
--- linux-2.6.12.orig/fs/reiserfs/xattr.c
+++ linux-2.6.12/fs/reiserfs/xattr.c
@@ -41,3 +41,2 @@
 #include <linux/reiserfs_acl.h>
-#include <linux/mbcache.h>
 #include <asm/uaccess.h>

> But, for example when someone use mbcache as another purpose on ext3,
> The crash will be caused by using mb_cache_shrink().
>
> Therefore, I think your patch should not be committed until
> mbcache will be limited to use only type per-filesystem.

Removing the cache parameter from mb_cache_shrink would break when more than 
one mb_cache is used per filesystem, correct. Leaving the parameter in and 
adding your patch is more "future proof", so I'm fine with it. Are you 
actually using more than one mb_cache, or is this theoretical?

As you say in your follow-up mail, without your patch the cache would become 
less effective, it won't crash anything, though.

Thanks,
-- 
Andreas Gruenbacher <agruen@suse.de>
SUSE Labs, SUSE LINUX PRODUCTS GMBH

  parent reply	other threads:[~2005-07-16  1:44 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-07-14 13:07 [PATCH] mb_cache_shrink() frees unexpected caches Akinobu Mita
2005-07-15 10:49 ` Andreas Gruenbacher
2005-07-15 13:41   ` Akinobu Mita
2005-07-15 14:36     ` Andreas Gruenbacher
2005-07-15 15:07       ` Akinobu Mita
2005-07-15 15:30         ` Akinobu Mita
2005-07-16  1:44         ` Andreas Gruenbacher [this message]
2005-07-16  3:53           ` Akinobu Mita

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200507160344.06235.agruen@suse.de \
    --to=agruen@suse.de \
    --cc=akpm@zip.com.au \
    --cc=amgta@yacht.ocn.ne.jp \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox