From mboxrd@z Thu Jan 1 00:00:00 1970 From: Hui Wang Subject: Re: [PATCH] vfs: try to unblock evpoll if mounted filesystem is RDONLY Date: Thu, 25 Jul 2013 18:46:57 +0800 Message-ID: <51F10221.5050308@canonical.com> References: <1373248974-3272-1-git-send-email-jason77.wang@gmail.com> <20130723154555.GC18458@mtj.dyndns.org> <20130723214844.GA25333@quack.suse.cz> <51EFA7A8.4010401@canonical.com> <20130724183931.GB27307@quack.suse.cz> <51F09A50.4040805@canonical.com> <20130725100358.GC9388@quack.suse.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Tejun Heo , viro@zeniv.linux.org.uk, kay.sievers@vrfy.org, jaxboe@fusionio.com, linux-fsdevel@vger.kernel.org To: Jan Kara Return-path: Received: from youngberry.canonical.com ([91.189.89.112]:45116 "EHLO youngberry.canonical.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755329Ab3GYKrM (ORCPT ); Thu, 25 Jul 2013 06:47:12 -0400 In-Reply-To: <20130725100358.GC9388@quack.suse.cz> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On 07/25/2013 06:03 PM, Jan Kara wrote: > On Thu 25-07-13 11:24:00, Hui Wang wrote: >> On 07/25/2013 02:39 AM, Jan Kara wrote: >>> On Wed 24-07-13 18:08:40, Hui Wang wrote: >>>> On 07/24/2013 05:48 AM, Jan Kara wrote: >>>>> On Tue 23-07-13 11:45:55, Tejun Heo wrote: >>>>>> Hello, >>>>>> >>>>>> (cc'ing Jan and quoting the whole body for him) >>>>>> >>>>>> On Mon, Jul 08, 2013 at 10:02:54AM +0800, Hui Wang wrote: >>>>>>> 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 >> [...] >>>>>>> bdev = blkdev_get_by_path(dev_name, mode, fs_type); >>>>>>> | >>>>>>> blkdev_get(..., mode, ...) >>>>>>> Since mode is FMODE_WRITE and rw optical disc is a writble block >>>>>>> device, the bd_write_holder will be set in this function. >>>>>>> >>>>>>> The the mount process will go on after that, the mount_bdev() will >>>>>>> continue to call: >>>>>>> >>>>>>> s = sget(fs_type, test_bdev_super, set_bdev_super, flags | MS_NOSEC, >>>>>>> bdev); >>>>>>> the super_block got from the iso9660 filesystem is absolutely >>>>>>> MS_RDONLY, so this mount changes to a readonly mount, but no code to >>>>>>> change the bd_write_holder back to zero and unblock the event poll. >>> I see. For iso9660 filesystem it is actually pretty easy to fix since >>> there we *know* we are going to mount it read only (isofs_mount() could >>> well add S_RDONLY to the flags passed to mount_bdev() which would fix the >>> issue). With udf it is more complex as there we could mount it read-write >>> depending on the device, medium, and filesystem features. So there we >>> really need to be able to drop write access as you suggested. But maybe I'd >>> put your code into some function like bdev_drop_write_access() in >>> fs/block_dev.c so that we don't leak bdev peculiarities into superblock >>> handling functions. >>> >> Your analysis is reasonable, the iso9660 is easier to be handled than udf. >> >> I also think move the relating code to fs/block_dev.c is a good idea, and >> i am very glad this issue can raise your attention, looking forward a >> perfect solution for this issue from you. > Actually, I've now got idea that seems technically even better to me. > When we are asked to RW mount in case filesystem cannot really do RW, we > return -EROFS instead of silently falling back to RO mount. Userspace > mount(8) command will try again with MS_RDONLY set so things should still > work OK and the problems with eject button would be solved. I'll try to > code that up. > > Honza Sounds a better idea. Right now, if we mount the DVD-R without readonly, the mount will try RW mount first, but it will fail since the media is readonly, then the mount(8) command will try again with MS_RDONLY. So your design will work similarly to this case, the difference is filesystem is readonly, the first time mounting will fail from fs. Hope to see your patch soon. :-) Regards, Hui.