From: Andrew Morton <akpm@digeo.com>
To: Alex Tomas <bzzz@tmi.comex.ru>
Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: 2.5.64-mm1
Date: Thu, 6 Mar 2003 02:21:40 -0800 [thread overview]
Message-ID: <20030306022140.7c816f32.akpm@digeo.com> (raw)
In-Reply-To: <m365qw3jcx.fsf@lexa.home.net>
Alex Tomas <bzzz@tmi.comex.ru> wrote:
>
>
> As far as I understand this isn't error path.
>
> lock_kernel();
>
> sb = inode->i_sb;
>
> if (is_dx(inode)) {
> err = ext3_dx_readdir(filp, dirent, filldir);
> if (err != ERR_BAD_DX_DIR)
> return err;
> /*
> * We don't set the inode dirty flag since it's not
> * critical that it get flushed back to the disk.
> */
> EXT3_I(filp->f_dentry->d_inode)->i_flags &= ~EXT3_INDEX_FL;
> }
>
> So, if ext3_dx_readdir() returns 0 (OK path), then ext3_readdir() finish
> w/o unlock_kernel(). The remain part of ext3_readdir() gets used if
> ext3_dx_readdir() can't use HTree and returns ERR_BAD_DX_DIR.
>
hm, yes, it does look that way.
It could be that any task which travels that path ends up running under
lock_kernel() for the rest of its existence, and nobody noticed.
WARNING: multiple messages have this Message-ID (diff)
From: Andrew Morton <akpm@digeo.com>
To: Alex Tomas <bzzz@tmi.comex.ru>
Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: 2.5.64-mm1
Date: Thu, 6 Mar 2003 02:21:40 -0800 [thread overview]
Message-ID: <20030306022140.7c816f32.akpm@digeo.com> (raw)
In-Reply-To: <m365qw3jcx.fsf@lexa.home.net>
Alex Tomas <bzzz@tmi.comex.ru> wrote:
>
>
> As far as I understand this isn't error path.
>
> lock_kernel();
>
> sb = inode->i_sb;
>
> if (is_dx(inode)) {
> err = ext3_dx_readdir(filp, dirent, filldir);
> if (err != ERR_BAD_DX_DIR)
> return err;
> /*
> * We don't set the inode dirty flag since it's not
> * critical that it get flushed back to the disk.
> */
> EXT3_I(filp->f_dentry->d_inode)->i_flags &= ~EXT3_INDEX_FL;
> }
>
> So, if ext3_dx_readdir() returns 0 (OK path), then ext3_readdir() finish
> w/o unlock_kernel(). The remain part of ext3_readdir() gets used if
> ext3_dx_readdir() can't use HTree and returns ERR_BAD_DX_DIR.
>
hm, yes, it does look that way.
It could be that any task which travels that path ends up running under
lock_kernel() for the rest of its existence, and nobody noticed.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org">aart@kvack.org</a>
next prev parent reply other threads:[~2003-03-06 10:11 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-03-06 7:07 2.5.64-mm1 Andrew Morton
2003-03-06 7:07 ` 2.5.64-mm1 Andrew Morton
2003-03-06 10:00 ` 2.5.64-mm1 Alex Tomas
2003-03-06 10:00 ` 2.5.64-mm1 Alex Tomas
2003-03-06 10:21 ` Andrew Morton [this message]
2003-03-06 10:21 ` 2.5.64-mm1 Andrew Morton
2003-03-06 13:50 ` 2.5.64-mm1 Alex Tomas
2003-03-06 13:50 ` 2.5.64-mm1 Alex Tomas
2003-03-06 11:01 ` 2.5.64-mm1 Andrew Morton
2003-03-06 11:01 ` 2.5.64-mm1 Andrew Morton
2003-03-09 7:50 ` 2.5.64-mm1 Alexander Hoogerhuis
2003-03-09 7:54 ` 2.5.64-mm1 Alexander Hoogerhuis
2003-03-09 7:54 ` 2.5.64-mm1 Alexander Hoogerhuis
2003-03-11 22:46 ` [opps] 2.5.64-mm1 Ed Tomlinson
2003-03-11 22:46 ` Ed Tomlinson
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=20030306022140.7c816f32.akpm@digeo.com \
--to=akpm@digeo.com \
--cc=bzzz@tmi.comex.ru \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.