Re: [PATCH] fuse: don't check for file->private_data on open().
On Thu, Nov 13, 2014 at 12:13:32PM +0100, Martin Kepplinger wrote: > Am 13. November 2014 11:53:29 MEZ, schrieb Miklos Szeredi : > >On Thu, Nov 13, 2014 at 11:05 AM, Martin Kepplinger > >wrote: > > > >> 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. > > > >Please be more careful with such patches. Have you audited all of the > >(ca. 200) misc drivers? If not, this might be a good time to do so. > >If it turns out to be too much, then consider not doing the change. > >The gain might not be worth the cost. > > > >NACK in this form. > > > >Thanks, > >Miklos > > Definitely should have been more careful as I checked fs too late now. I > totally unnecessarily broke -next. > > But If fuse-devel is ok with a fix like the one i sent (still has to get > tested too) i believe we're covered. I still call for independent review > though. I don't think it's worth it anymore, I'm going to revert the original patch that caused these problems, as it has the potential to break other drivers in ways that are not obvious (i.e. not at build time.) Sorry, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] fuse: don't check for file->private_data on open().
Am 13. November 2014 11:53:29 MEZ, schrieb Miklos Szeredi : >On Thu, Nov 13, 2014 at 11:05 AM, Martin Kepplinger >wrote: > >> 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. > >Please be more careful with such patches. Have you audited all of the >(ca. 200) misc drivers? If not, this might be a good time to do so. >If it turns out to be too much, then consider not doing the change. >The gain might not be worth the cost. > >NACK in this form. > >Thanks, >Miklos Definitely should have been more careful as I checked fs too late now. I totally unnecessarily broke -next. But If fuse-devel is ok with a fix like the one i sent (still has to get tested too) i believe we're covered. I still call for independent review though. -- 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] fuse: don't check for file->private_data on open().
On Thu, Nov 13, 2014 at 11:05 AM, Martin Kepplinger wrote: > 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. Please be more careful with such patches. Have you audited all of the (ca. 200) misc drivers? If not, this might be a good time to do so. If it turns out to be too much, then consider not doing the change. The gain might not be worth the cost. NACK in this form. Thanks, Miklos -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] fuse: don't check for file->private_data on open().
Am 13. November 2014 10:40:38 MEZ, schrieb Miklos Szeredi :
>On Wed, Nov 12, 2014 at 5:31 PM, Martin Kepplinger
>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
>> Signed-off-by: Martin Kepplinger
>> ---
>> 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(_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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] fuse: don't check for file->private_data on open().
On Wed, Nov 12, 2014 at 5:31 PM, Martin Kepplinger 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
> Signed-off-by: Martin Kepplinger
> ---
> 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(_mutex);
> - err = -EINVAL;
> - if (file->private_data)
> - goto err_unlock;
>
> err = fuse_ctl_add_conn(fc);
> if (err)
> --
> 1.7.10.4
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] fuse: don't check for file-private_data on open().
On Wed, Nov 12, 2014 at 5:31 PM, Martin Kepplinger mart...@posteo.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.red...@gmail.com
Signed-off-by: Martin Kepplinger mart...@posteo.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
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] fuse: don't check for file-private_data on open().
Am 13. November 2014 10:40:38 MEZ, schrieb Miklos Szeredi mik...@szeredi.hu:
On Wed, Nov 12, 2014 at 5:31 PM, Martin Kepplinger mart...@posteo.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.red...@gmail.com
Signed-off-by: Martin Kepplinger mart...@posteo.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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] fuse: don't check for file-private_data on open().
On Thu, Nov 13, 2014 at 11:05 AM, Martin Kepplinger mart...@posteo.de wrote: 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. Please be more careful with such patches. Have you audited all of the (ca. 200) misc drivers? If not, this might be a good time to do so. If it turns out to be too much, then consider not doing the change. The gain might not be worth the cost. NACK in this form. Thanks, Miklos -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] fuse: don't check for file-private_data on open().
Am 13. November 2014 11:53:29 MEZ, schrieb Miklos Szeredi mik...@szeredi.hu: On Thu, Nov 13, 2014 at 11:05 AM, Martin Kepplinger mart...@posteo.de wrote: 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. Please be more careful with such patches. Have you audited all of the (ca. 200) misc drivers? If not, this might be a good time to do so. If it turns out to be too much, then consider not doing the change. The gain might not be worth the cost. NACK in this form. Thanks, Miklos Definitely should have been more careful as I checked fs too late now. I totally unnecessarily broke -next. But If fuse-devel is ok with a fix like the one i sent (still has to get tested too) i believe we're covered. I still call for independent review though. -- 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] fuse: don't check for file-private_data on open().
On Thu, Nov 13, 2014 at 12:13:32PM +0100, Martin Kepplinger wrote: Am 13. November 2014 11:53:29 MEZ, schrieb Miklos Szeredi mik...@szeredi.hu: On Thu, Nov 13, 2014 at 11:05 AM, Martin Kepplinger mart...@posteo.de wrote: 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. Please be more careful with such patches. Have you audited all of the (ca. 200) misc drivers? If not, this might be a good time to do so. If it turns out to be too much, then consider not doing the change. The gain might not be worth the cost. NACK in this form. Thanks, Miklos Definitely should have been more careful as I checked fs too late now. I totally unnecessarily broke -next. But If fuse-devel is ok with a fix like the one i sent (still has to get tested too) i believe we're covered. I still call for independent review though. I don't think it's worth it anymore, I'm going to revert the original patch that caused these problems, as it has the potential to break other drivers in ways that are not obvious (i.e. not at build time.) Sorry, greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] fuse: Don't check for file->private_data on open(). It is set by the core.
The miscdevice core now sets file->private_data to the struct miscdevice so don't fail when this is not NULL. Reported-by: Giedrius Statkevicius Signed-off-by: Martin Kepplinger --- sorry, I can't read ;) Is this a fix for your problem (instead of the first patch)? in case of fuse_ctl_add_conn(fc) failing things should proceed as before. fs/fuse/inode.c |4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/fs/fuse/inode.c b/fs/fuse/inode.c index 03246cd..a97a475 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(_mutex); - err = -EINVAL; - if (file->private_data) - goto err_unlock; err = fuse_ctl_add_conn(fc); if (err) @@ -1117,6 +1114,7 @@ static int fuse_fill_super(struct super_block *sb, void *data, int silent) return 0; err_unlock: + file->private_data = NULL; mutex_unlock(_mutex); err_free_init_req: fuse_request_free(init_req); -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] fuse: don't check for file->private_data on open().
On 2014.11.12 18:31, Martin Kepplinger wrote: > The miscdevice core now sets file->private_data to the struct miscdevice > so don't fail when this is not NULL. > > Reported-by: Thierry Reding > Signed-off-by: Martin Kepplinger > --- Hello, Looks like this patch does not solve the problem with FUSE I have mentioned in the original report. I have gone ahead and patched 3.18.0-rc4-next-20141112 with your patch and tested it. Was not able to get into gdm, barely got into another tty but was not able to do anything, still experiencing lockups. I cannot comment on the patch as I am not familiar with the code. The whole journal of that boot with only 'kernel:' lines: Lap 12 19:01:15 ghost kernel: Initializing cgroup subsys cpuset Lap 12 19:01:15 ghost kernel: Initializing cgroup subsys cpu Lap 12 19:01:15 ghost kernel: Initializing cgroup subsys cpuacct Lap 12 19:01:15 ghost kernel: Linux version 3.18.0-rc4-next-20141112-dirty (giedrius@ghost) (gcc version 4.9.2 (GCC) ) #51 SMP PREEMPT Wed Nov 12 18:41:54 EET 2014 Lap 12 19:01:15 ghost kernel: Command line: initrd=\intel-ucode.img initrd=\initramfs-linux-next.img root=/dev/mapper/lvm-root cryptdevice=/dev/sda2:lvm rw Lap 12 19:01:15 ghost kernel: e820: BIOS-provided physical RAM map: Lap 12 19:01:15 ghost kernel: BIOS-e820: [mem 0x-0x0009cfff] usable Lap 12 19:01:15 ghost kernel: BIOS-e820: [mem 0x0009d000-0x0009] reserved Lap 12 19:01:15 ghost kernel: BIOS-e820: [mem 0x0010-0xb8a9cfff] usable Lap 12 19:01:15 ghost kernel: BIOS-e820: [mem 0xb8a9d000-0xb9ebdfff] reserved Lap 12 19:01:15 ghost kernel: BIOS-e820: [mem 0xb9ebe000-0xb9fbdfff] ACPI NVS Lap 12 19:01:15 ghost kernel: BIOS-e820: [mem 0xb9fbe000-0xb9ffefff] ACPI data Lap 12 19:01:15 ghost kernel: BIOS-e820: [mem 0xb9fff000-0xb9ff] usable Lap 12 19:01:15 ghost kernel: BIOS-e820: [mem 0xe00f8000-0xe00f8fff] reserved Lap 12 19:01:15 ghost kernel: BIOS-e820: [mem 0xfed1c000-0xfed1] reserved Lap 12 19:01:15 ghost kernel: BIOS-e820: [mem 0xffec-0xffedefff] reserved Lap 12 19:01:15 ghost kernel: BIOS-e820: [mem 0x0001-0x00013fdf] usable Lap 12 19:01:15 ghost kernel: NX (Execute Disable) protection: active Lap 12 19:01:15 ghost kernel: e820: update [mem 0xb2d7d018-0xb2d8d057] usable ==> usable Lap 12 19:01:15 ghost kernel: e820: update [mem 0xb2d70018-0xb2d7c857] usable ==> usable Lap 12 19:01:15 ghost kernel: extended physical RAM map: Lap 12 19:01:15 ghost kernel: reserve setup_data: [mem 0x-0x0009cfff] usable Lap 12 19:01:15 ghost kernel: reserve setup_data: [mem 0x0009d000-0x0009] reserved Lap 12 19:01:15 ghost kernel: reserve setup_data: [mem 0x0010-0xb2d70017] usable Lap 12 19:01:15 ghost kernel: reserve setup_data: [mem 0xb2d70018-0xb2d7c857] usable Lap 12 19:01:15 ghost kernel: reserve setup_data: [mem 0xb2d7c858-0xb2d7d017] usable Lap 12 19:01:15 ghost kernel: reserve setup_data: [mem 0xb2d7d018-0xb2d8d057] usable Lap 12 19:01:15 ghost kernel: reserve setup_data: [mem 0xb2d8d058-0xb8a9cfff] usable Lap 12 19:01:15 ghost kernel: reserve setup_data: [mem 0xb8a9d000-0xb9ebdfff] reserved Lap 12 19:01:15 ghost kernel: reserve setup_data: [mem 0xb9ebe000-0xb9fbdfff] ACPI NVS Lap 12 19:01:15 ghost kernel: reserve setup_data: [mem 0xb9fbe000-0xb9ffefff] ACPI data Lap 12 19:01:15 ghost kernel: reserve setup_data: [mem 0xb9fff000-0xb9ff] usable Lap 12 19:01:15 ghost kernel: reserve setup_data: [mem 0xe00f8000-0xe00f8fff] reserved Lap 12 19:01:15 ghost kernel: reserve setup_data: [mem 0xfed1c000-0xfed1] reserved Lap 12 19:01:15 ghost kernel: reserve setup_data: [mem 0xffec-0xffedefff] reserved Lap 12 19:01:15 ghost kernel: reserve setup_data: [mem 0x0001-0x00013fdf] usable Lap 12 19:01:15 ghost kernel: efi: EFI v2.10 by HPQ Lap 12 19:01:15 ghost kernel: efi: ACPI=0xb9ffe000 ACPI 2.0=0xb9ffe014 SMBIOS=0xb956d598 Lap 12 19:01:15 ghost kernel: efi: mem00: [Conventional Memory| | | | | |WB|WT|WC|UC] range=[0x-0x1000) (0MB) Lap 12 19:01:15 ghost kernel: efi: mem01: [Loader Data| | | | | |WB|WT|WC|UC] range=[0x1000-0x7000) (0MB) Lap 12 19:01:15 ghost kernel: efi: mem02: [Conventional Memory| | | | | |WB|WT|WC|UC] range=[0x7000-0x00058000) (0MB) Lap 12 19:01:15 ghost kernel: efi: mem03: [Boot Data | | | | | |WB|WT|WC|UC] range=[0x00058000-0x00059000) (0MB) Lap 12 19:01:15 ghost kernel: efi: mem04: [Conventional Memory| | | | | |WB|WT|WC|UC]
Re: [PATCH] fuse: don't check for file->private_data on open().
Am 2014-11-12 um 17:31 schrieb Martin Kepplinger: > The miscdevice core now sets file->private_data to the struct miscdevice > so don't fail when this is not NULL. > > Reported-by: Thierry Reding > Signed-off-by: Martin Kepplinger > --- > 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!! > if ok, please add Reported-by: Giedrius Statkevicius thanks -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] fuse: don't check for file->private_data on open().
The miscdevice core now sets file->private_data to the struct miscdevice so don't fail when this is not NULL. Reported-by: Thierry Reding Signed-off-by: Martin Kepplinger --- 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(_mutex); - err = -EINVAL; - if (file->private_data) - goto err_unlock; err = fuse_ctl_add_conn(fc); if (err) -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] fuse: don't check for file-private_data on open().
The miscdevice core now sets file-private_data to the struct miscdevice so don't fail when this is not NULL. Reported-by: Thierry Reding thierry.red...@gmail.com Signed-off-by: Martin Kepplinger mart...@posteo.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 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] fuse: don't check for file-private_data on open().
Am 2014-11-12 um 17:31 schrieb Martin Kepplinger: The miscdevice core now sets file-private_data to the struct miscdevice so don't fail when this is not NULL. Reported-by: Thierry Reding thierry.red...@gmail.com Signed-off-by: Martin Kepplinger mart...@posteo.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!! if ok, please add Reported-by: Giedrius Statkevicius giedriusw...@gmail.com thanks -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] fuse: don't check for file-private_data on open().
On 2014.11.12 18:31, Martin Kepplinger wrote: The miscdevice core now sets file-private_data to the struct miscdevice so don't fail when this is not NULL. Reported-by: Thierry Reding thierry.red...@gmail.com Signed-off-by: Martin Kepplinger mart...@posteo.de --- Hello, Looks like this patch does not solve the problem with FUSE I have mentioned in the original report. I have gone ahead and patched 3.18.0-rc4-next-20141112 with your patch and tested it. Was not able to get into gdm, barely got into another tty but was not able to do anything, still experiencing lockups. I cannot comment on the patch as I am not familiar with the code. The whole journal of that boot with only 'kernel:' lines: Lap 12 19:01:15 ghost kernel: Initializing cgroup subsys cpuset Lap 12 19:01:15 ghost kernel: Initializing cgroup subsys cpu Lap 12 19:01:15 ghost kernel: Initializing cgroup subsys cpuacct Lap 12 19:01:15 ghost kernel: Linux version 3.18.0-rc4-next-20141112-dirty (giedrius@ghost) (gcc version 4.9.2 (GCC) ) #51 SMP PREEMPT Wed Nov 12 18:41:54 EET 2014 Lap 12 19:01:15 ghost kernel: Command line: initrd=\intel-ucode.img initrd=\initramfs-linux-next.img root=/dev/mapper/lvm-root cryptdevice=/dev/sda2:lvm rw Lap 12 19:01:15 ghost kernel: e820: BIOS-provided physical RAM map: Lap 12 19:01:15 ghost kernel: BIOS-e820: [mem 0x-0x0009cfff] usable Lap 12 19:01:15 ghost kernel: BIOS-e820: [mem 0x0009d000-0x0009] reserved Lap 12 19:01:15 ghost kernel: BIOS-e820: [mem 0x0010-0xb8a9cfff] usable Lap 12 19:01:15 ghost kernel: BIOS-e820: [mem 0xb8a9d000-0xb9ebdfff] reserved Lap 12 19:01:15 ghost kernel: BIOS-e820: [mem 0xb9ebe000-0xb9fbdfff] ACPI NVS Lap 12 19:01:15 ghost kernel: BIOS-e820: [mem 0xb9fbe000-0xb9ffefff] ACPI data Lap 12 19:01:15 ghost kernel: BIOS-e820: [mem 0xb9fff000-0xb9ff] usable Lap 12 19:01:15 ghost kernel: BIOS-e820: [mem 0xe00f8000-0xe00f8fff] reserved Lap 12 19:01:15 ghost kernel: BIOS-e820: [mem 0xfed1c000-0xfed1] reserved Lap 12 19:01:15 ghost kernel: BIOS-e820: [mem 0xffec-0xffedefff] reserved Lap 12 19:01:15 ghost kernel: BIOS-e820: [mem 0x0001-0x00013fdf] usable Lap 12 19:01:15 ghost kernel: NX (Execute Disable) protection: active Lap 12 19:01:15 ghost kernel: e820: update [mem 0xb2d7d018-0xb2d8d057] usable == usable Lap 12 19:01:15 ghost kernel: e820: update [mem 0xb2d70018-0xb2d7c857] usable == usable Lap 12 19:01:15 ghost kernel: extended physical RAM map: Lap 12 19:01:15 ghost kernel: reserve setup_data: [mem 0x-0x0009cfff] usable Lap 12 19:01:15 ghost kernel: reserve setup_data: [mem 0x0009d000-0x0009] reserved Lap 12 19:01:15 ghost kernel: reserve setup_data: [mem 0x0010-0xb2d70017] usable Lap 12 19:01:15 ghost kernel: reserve setup_data: [mem 0xb2d70018-0xb2d7c857] usable Lap 12 19:01:15 ghost kernel: reserve setup_data: [mem 0xb2d7c858-0xb2d7d017] usable Lap 12 19:01:15 ghost kernel: reserve setup_data: [mem 0xb2d7d018-0xb2d8d057] usable Lap 12 19:01:15 ghost kernel: reserve setup_data: [mem 0xb2d8d058-0xb8a9cfff] usable Lap 12 19:01:15 ghost kernel: reserve setup_data: [mem 0xb8a9d000-0xb9ebdfff] reserved Lap 12 19:01:15 ghost kernel: reserve setup_data: [mem 0xb9ebe000-0xb9fbdfff] ACPI NVS Lap 12 19:01:15 ghost kernel: reserve setup_data: [mem 0xb9fbe000-0xb9ffefff] ACPI data Lap 12 19:01:15 ghost kernel: reserve setup_data: [mem 0xb9fff000-0xb9ff] usable Lap 12 19:01:15 ghost kernel: reserve setup_data: [mem 0xe00f8000-0xe00f8fff] reserved Lap 12 19:01:15 ghost kernel: reserve setup_data: [mem 0xfed1c000-0xfed1] reserved Lap 12 19:01:15 ghost kernel: reserve setup_data: [mem 0xffec-0xffedefff] reserved Lap 12 19:01:15 ghost kernel: reserve setup_data: [mem 0x0001-0x00013fdf] usable Lap 12 19:01:15 ghost kernel: efi: EFI v2.10 by HPQ Lap 12 19:01:15 ghost kernel: efi: ACPI=0xb9ffe000 ACPI 2.0=0xb9ffe014 SMBIOS=0xb956d598 Lap 12 19:01:15 ghost kernel: efi: mem00: [Conventional Memory| | | | | |WB|WT|WC|UC] range=[0x-0x1000) (0MB) Lap 12 19:01:15 ghost kernel: efi: mem01: [Loader Data| | | | | |WB|WT|WC|UC] range=[0x1000-0x7000) (0MB) Lap 12 19:01:15 ghost kernel: efi: mem02: [Conventional Memory| | | | | |WB|WT|WC|UC] range=[0x7000-0x00058000) (0MB) Lap 12 19:01:15 ghost kernel: efi: mem03: [Boot Data | | | | | |WB|WT|WC|UC] range=[0x00058000-0x00059000) (0MB) Lap 12 19:01:15 ghost kernel: efi: mem04: [Conventional Memory| | | | |
[PATCH] fuse: Don't check for file-private_data on open(). It is set by the core.
The miscdevice core now sets file-private_data to the struct miscdevice so don't fail when this is not NULL. Reported-by: Giedrius Statkevicius giedriusw...@gmail.com Signed-off-by: Martin Kepplinger mart...@posteo.de --- sorry, I can't read ;) Is this a fix for your problem (instead of the first patch)? in case of fuse_ctl_add_conn(fc) failing things should proceed as before. fs/fuse/inode.c |4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/fs/fuse/inode.c b/fs/fuse/inode.c index 03246cd..a97a475 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) @@ -1117,6 +1114,7 @@ static int fuse_fill_super(struct super_block *sb, void *data, int silent) return 0; err_unlock: + file-private_data = NULL; mutex_unlock(fuse_mutex); err_free_init_req: fuse_request_free(init_req); -- 1.7.10.4 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
