[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <B51BC89F-99DB-4F9A-A1E3-14D9627E2496@posteo.de>
Date: Thu, 13 Nov 2014 11:05:01 +0100
From: Martin Kepplinger <martink@...teo.de>
To: Miklos Szeredi <miklos@...redi.hu>
CC: fuse-devel <fuse-devel@...ts.sourceforge.net>,
thierry.reding@...il.com,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
giedriuswork@...il.com,
Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] fuse: don't check for file->private_data on open().
Am 13. November 2014 10:40:38 MEZ, schrieb Miklos Szeredi <miklos@...redi.hu>:
>On Wed, Nov 12, 2014 at 5:31 PM, Martin Kepplinger <martink@...teo.de>
>wrote:
>> The miscdevice core now sets file->private_data to the struct
>miscdevice
>> so don't fail when this is not NULL.
>
>Does it? Look:
>
>static int misc_open(struct inode * inode, struct file * file)
>{
> ...
> if (file->f_op->open) {
> file->private_data = c;
> err = file->f_op->open(inode,file);
> }
>
>It only sets ->private_data if the device provides an open method.
>Fuse doesn't, so it's not clear what this patch is trying to fix.
>
>Thanks,
>Miklos
>
>
>>
>> Reported-by: Thierry Reding <thierry.reding@...il.com>
>> Signed-off-by: Martin Kepplinger <martink@...teo.de>
>> ---
>> This is a question: what does this check provide and does overwriting
>> file->private_data make any difference?
>>
>> Is open() by the user not allowed here, if file->private_data is set?
>>
>> thanks!!
>>
>> fs/fuse/inode.c | 3 ---
>> 1 file changed, 3 deletions(-)
>>
>> diff --git a/fs/fuse/inode.c b/fs/fuse/inode.c
>> index 03246cd..562407e 100644
>> --- a/fs/fuse/inode.c
>> +++ b/fs/fuse/inode.c
>> @@ -1092,9 +1092,6 @@ static int fuse_fill_super(struct super_block
>*sb, void *data, int silent)
>> }
>>
>> mutex_lock(&fuse_mutex);
>> - err = -EINVAL;
>> - if (file->private_data)
>> - goto err_unlock;
>>
>> err = fuse_ctl_add_conn(fc);
>> if (err)
>> --
>> 1.7.10.4
>>
In this week's -next this should have changed. My SSD broke down so i have to delay further work for a few days, i'm sorry.
--
Martin Kepplinger
http://martinkepplinger.com
sent from mobile
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists