From: Hui Wang <jason77.wang@gmail.com>
To: viro@zeniv.linux.org.uk, tj@kernel.org, kay.sievers@vrfy.org,
jaxboe@fusionio.com
Cc: linux-fsdevel@vger.kernel.org
Subject: [PATCH] vfs: try to unblock evpoll if mounted filesystem is RDONLY
Date: Mon, 8 Jul 2013 10:02:54 +0800 [thread overview]
Message-ID: <1373248974-3272-1-git-send-email-jason77.wang@gmail.com> (raw)
When inserting a rw optical disc like a DVD/CD rw disc, and we mount
it without an explicit ro option, the vfs will block its event poll
workqueue to protect it from damaging while writing to disc, the direct
result of the blocking of event poll is to make the eject button can't
work.
This protection is reasonable when the filesystem on the rw disc is
also rw. but if the filessytem on the rw disc is ro, e.g. the iso9660
and udf readonly partition, this protection is a little bit weird and
unneeded, since most people are going to be curious why the eject
button can't work while the mount is ro?
To make the eject button work again while the mounted filesystem is ro,
we should inspect the flags of the filesytem's sb and unblock the evpoll
conditionally, the code refers to the blkdev_put() in the
fs/block_dev.c.
Signed-off-by: Hui Wang <jason77.wang@gmail.com>
---
I personally don't know if this is a real defect or not, but this
issue is reported by a customer of our company, he said from the user
experience, this is a defect, since no matter the disc is ro or rw,
the mount is ro, the eject button should work.
so far, all DVD/CD and DVD-R/CD-R follow this rule (mount is ro, eject
button can work), but DVD/CD rw discs don't, no matter the mount is ro
or rw, the eject button always can't work. So our finial goal is to make
the eject button can work while the filesystem on the rw disc is ro and
the whole mounting is ro.
fs/super.c | 19 +++++++++++++++++++
1 file changed, 19 insertions(+)
diff --git a/fs/super.c b/fs/super.c
index 7465d43..7980602 100644
--- a/fs/super.c
+++ b/fs/super.c
@@ -1011,6 +1011,25 @@ struct dentry *mount_bdev(struct file_system_type *fs_type,
s->s_flags |= MS_ACTIVE;
bdev->bd_super = s;
+
+ mutex_lock(&bdev->bd_mutex);
+
+ if ((s->s_flags & MS_RDONLY) && bdev->bd_write_holder) {
+ int bd_holders;
+
+ bd_holders = bdev->bd_holders;
+ if (bdev == bdev->bd_contains)
+ bd_holders -= 2;
+ else
+ bd_holders -= 1;
+
+ if (!bd_holders) {
+ disk_unblock_events(bdev->bd_disk);
+ bdev->bd_write_holder = false;
+ }
+ }
+
+ mutex_unlock(&bdev->bd_mutex);
}
return dget(s->s_root);
--
1.8.1.2
next reply other threads:[~2013-07-08 2:03 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-08 2:02 Hui Wang [this message]
2013-07-23 15:45 ` [PATCH] vfs: try to unblock evpoll if mounted filesystem is RDONLY Tejun Heo
2013-07-23 21:48 ` Jan Kara
2013-07-24 10:08 ` Hui Wang
2013-07-24 18:39 ` Jan Kara
2013-07-25 3:24 ` Hui Wang
2013-07-25 10:03 ` Jan Kara
2013-07-25 10:46 ` Hui Wang
2013-07-25 15:33 ` Tejun Heo
2013-07-25 17:27 ` Jan Kara
2013-07-25 17:30 ` Tejun Heo
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=1373248974-3272-1-git-send-email-jason77.wang@gmail.com \
--to=jason77.wang@gmail.com \
--cc=jaxboe@fusionio.com \
--cc=kay.sievers@vrfy.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=tj@kernel.org \
--cc=viro@zeniv.linux.org.uk \
/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;
as well as URLs for NNTP newsgroup(s).