2022-02-09 03:01:14

by Johannes Berg

[permalink] [raw]
Subject: Re: [PATCH] devcoredump: increase the device delete timeout to 10 mins

On Tue, 2022-02-08 at 13:40 -0800, Abhinav Kumar wrote:
> >
> I am checking what usermode sees and will get back ( I didnt see an
> error do most likely it was EOF ). I didnt follow the second part.

I think probably it got -ENODEV, looking at kernfs_file_read_iter().

> If the file descriptor read returns EOF, even if we consider them
> separate how will it resolve this issue?
>
> My earlier questions were related to fixing it in devcoredump to detect
> and fix it there. Are you suggesting to fix in usermode instead? How?
>

Yeah, no, you cannot fix it in userspace.

But I just followed the rabbit hole down kernfs and all, and it looks
like indeed the read would be cut short with -ENODEV, sorry.

It doesn't look like there's good API for this, but it seems at least
from the underlying kernfs POV it should be possible to get_device() in
open and put_device() in release, so that the device sticks around while
somebody has the file open? It's entirely virtual, so this should be OK?

johannes


2022-02-09 12:19:02

by Abhinav Kumar

[permalink] [raw]
Subject: Re: [PATCH] devcoredump: increase the device delete timeout to 10 mins

Hi Johannes

On 2/8/2022 1:54 PM, Johannes Berg wrote:
> On Tue, 2022-02-08 at 13:40 -0800, Abhinav Kumar wrote:
>>>
>> I am checking what usermode sees and will get back ( I didnt see an
>> error do most likely it was EOF ). I didnt follow the second part.
>
> I think probably it got -ENODEV, looking at kernfs_file_read_iter().
>
>> If the file descriptor read returns EOF, even if we consider them
>> separate how will it resolve this issue?
>>
>> My earlier questions were related to fixing it in devcoredump to detect
>> and fix it there. Are you suggesting to fix in usermode instead? How?
>>
>
> Yeah, no, you cannot fix it in userspace.
>
> But I just followed the rabbit hole down kernfs and all, and it looks
> like indeed the read would be cut short with -ENODEV, sorry.
>
> It doesn't look like there's good API for this, but it seems at least
> from the underlying kernfs POV it should be possible to get_device() in
> open and put_device() in release, so that the device sticks around while
> somebody has the file open? It's entirely virtual, so this should be OK?
>
> johannes

Are you suggesting something like below?

diff --git a/fs/sysfs/file.c b/fs/sysfs/file.c
index 42dcf96..14203d0 100644
--- a/fs/sysfs/file.c
+++ b/fs/sysfs/file.c
@@ -32,6 +32,22 @@ static const struct sysfs_ops *sysfs_file_ops(struct
kernfs_node *kn)
return kobj->ktype ? kobj->ktype->sysfs_ops : NULL;
}

+static int sysfs_kf_open(struct kernfs_open_file *of)
+{
+ struct kobject *kobj = of->kn->parent->priv;
+ struct device *dev = kobj_to_dev(kobj);
+
+ get_device(dev);
+}
+
+static void sysfs_kf_release(struct kernfs_open_file *of)
+{
+ struct kobject *kobj = of->kn->parent->priv;
+ struct device *dev = kobj_to_dev(kobj);
+
+ put_device(dev);
+}
+
/*
* Reads on sysfs are handled through seq_file, which takes care of hairy
* details like buffering and seeking. The following function pipes
@@ -211,6 +227,8 @@ static const struct kernfs_ops sysfs_file_kfops_wo = {
};

static const struct kernfs_ops sysfs_file_kfops_rw = {
+ .open = sysfs_kf_open;
+ .release = sysfs_kf_release;
.seq_show = sysfs_kf_seq_show,
.write = sysfs_kf_write,
};

If so, dont you think this will be a more intrusive change just for the
sake of devcoredump? Any other way to keep the changes limited to
devcoredump?

Thanks

Abhinav


2022-02-09 12:50:33

by Johannes Berg

[permalink] [raw]
Subject: Re: [PATCH] devcoredump: increase the device delete timeout to 10 mins

On Tue, 2022-02-08 at 17:55 -0800, Abhinav Kumar wrote:
>
> Are you suggesting something like below?
>
> diff --git a/fs/sysfs/file.c b/fs/sysfs/file.c
> index 42dcf96..14203d0 100644
> --- a/fs/sysfs/file.c
>

No, for sure not, but I guess from the looks of this patch there's no
way to do something like that for just an individual attribute...

Oh well.

johannes

2022-02-09 16:49:42

by Abhinav Kumar

[permalink] [raw]
Subject: Re: [PATCH] devcoredump: increase the device delete timeout to 10 mins

Hi Johannes

On 2/8/2022 11:50 PM, Johannes Berg wrote:
> On Tue, 2022-02-08 at 17:55 -0800, Abhinav Kumar wrote:
>>
>> Are you suggesting something like below?
>>
>> diff --git a/fs/sysfs/file.c b/fs/sysfs/file.c
>> index 42dcf96..14203d0 100644
>> --- a/fs/sysfs/file.c
>>
>
> No, for sure not, but I guess from the looks of this patch there's no
> way to do something like that for just an individual attribute...
>
> Oh well.
>
> johannes

In that case, I was not clear on the previous solution you suggested.
Are you suggesting then we can go ahead with the timeout increase?
If so, can I please get your ack?

Thanks

Abhinav

2022-02-11 14:32:35

by Greg Kroah-Hartman

[permalink] [raw]
Subject: Re: [PATCH] devcoredump: increase the device delete timeout to 10 mins

On Tue, Feb 08, 2022 at 05:55:18PM -0800, Abhinav Kumar wrote:
> Hi Johannes
>
> On 2/8/2022 1:54 PM, Johannes Berg wrote:
> > On Tue, 2022-02-08 at 13:40 -0800, Abhinav Kumar wrote:
> > > >
> > > I am checking what usermode sees and will get back ( I didnt see an
> > > error do most likely it was EOF ). I didnt follow the second part.
> >
> > I think probably it got -ENODEV, looking at kernfs_file_read_iter().
> >
> > > If the file descriptor read returns EOF, even if we consider them
> > > separate how will it resolve this issue?
> > >
> > > My earlier questions were related to fixing it in devcoredump to detect
> > > and fix it there. Are you suggesting to fix in usermode instead? How?
> > >
> >
> > Yeah, no, you cannot fix it in userspace.
> >
> > But I just followed the rabbit hole down kernfs and all, and it looks
> > like indeed the read would be cut short with -ENODEV, sorry.
> >
> > It doesn't look like there's good API for this, but it seems at least
> > from the underlying kernfs POV it should be possible to get_device() in
> > open and put_device() in release, so that the device sticks around while
> > somebody has the file open? It's entirely virtual, so this should be OK?
> >
> > johannes
>
> Are you suggesting something like below?
>
> diff --git a/fs/sysfs/file.c b/fs/sysfs/file.c
> index 42dcf96..14203d0 100644
> --- a/fs/sysfs/file.c
> +++ b/fs/sysfs/file.c
> @@ -32,6 +32,22 @@ static const struct sysfs_ops *sysfs_file_ops(struct
> kernfs_node *kn)
> return kobj->ktype ? kobj->ktype->sysfs_ops : NULL;
> }
>
> +static int sysfs_kf_open(struct kernfs_open_file *of)
> +{
> + struct kobject *kobj = of->kn->parent->priv;
> + struct device *dev = kobj_to_dev(kobj);
> +
> + get_device(dev);
> +}
> +
> +static void sysfs_kf_release(struct kernfs_open_file *of)
> +{
> + struct kobject *kobj = of->kn->parent->priv;
> + struct device *dev = kobj_to_dev(kobj);
> +
> + put_device(dev);
> +}


That obviously does not work as not everything in sysfs is a struct
device :(