From: Ming Zhang <blackmagic02881@gmail.com>
To: "John Anthony Kazos Jr." <jakj@j-a-k-j.com>
Cc: Dave Kleikamp <shaggy@linux.vnet.ibm.com>, linux-ext4@vger.kernel.org
Subject: Re: (un)lock_kernel() ?
Date: Tue, 10 Apr 2007 12:03:15 -0400 [thread overview]
Message-ID: <1176220995.3696.24.camel@fs0004.ibrix.com> (raw)
In-Reply-To: <alpine.DEB.0.83.0704041244560.4770@sigma.j-a-k-j.com>
On Wed, 2007-04-04 at 12:52 -0400, John Anthony Kazos Jr. wrote:
> > According to Documentation/filesystems/Locking, ->get_sb() is called
> > with the BKL held, but looking through the code, I'm not able to find
> > where it is being taken.
>
> I noticed that too. Unless I'm just dumb and can't see it, I'm not able to
> find any BKL references during filesystem mounting until you get into
> FS-specific code. I looked through everything from sys_mount through to
> vfs_kern_mount. Documentation/filesystems/porting talks about several
> situations where the VFS code was modified to not take the BKL, and BLK
> calls were added by FS non-maintainers for safety until each FS could be
> audited independently, but that wouldn't be the case, would it?
sys_mount->do_mount->do_new_mount->do_kern_mount path
part of sys_mount()
1570 goto out3;
1571
1572 lock_kernel();
1573 retval = do_mount((char *)dev_page, dir_page, (char *)type_page,
1574 flags, (void *)data_page);
1575 unlock_kernel();
1576 free_page(data_page);
1577
1578 out3:
1579 free_page(dev_page)
;
>
> The ext2 code takes the BKL in three places: ext2_update_inode,
> write_super, and ext2_compat_ioctl. Starting with ext3, it's in
> ext3_compat_ioctl and ext3_fill_super, and the same with ext4.
>
> I suppose the BKL does have to be held, somehow, somewhere, during
> mounting, or anybody using ext3 on a multiprocessor box would lock their
> system from unmatched locking calls. Unless the first unlock_kernel()
> would make the count -1 and the lock would bring it back to zero?
> -
> To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2007-04-10 16:03 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-04-04 12:57 (un)lock_kernel() ? John Anthony Kazos Jr.
2007-04-04 15:36 ` Dave Kleikamp
2007-04-04 16:52 ` John Anthony Kazos Jr.
2007-04-10 16:03 ` Ming Zhang [this message]
2007-04-10 16:10 ` Dave Kleikamp
2007-04-10 16:55 ` Ming Zhang
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=1176220995.3696.24.camel@fs0004.ibrix.com \
--to=blackmagic02881@gmail.com \
--cc=jakj@j-a-k-j.com \
--cc=linux-ext4@vger.kernel.org \
--cc=shaggy@linux.vnet.ibm.com \
/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.