Linux ARM-MSM sub-architecture
 help / color / mirror / Atom feed
From: Abhinav Kumar <quic_abhinavk@quicinc.com>
To: Johannes Berg <johannes@sipsolutions.net>,
	<linux-kernel@vger.kernel.org>
Cc: <gregkh@linuxfoundation.org>, <rafael@kernel.org>,
	<robdclark@gmail.com>, <dri-devel@lists.freedesktop.org>,
	<linux-arm-msm@vger.kernel.org>,
	<freedreno@lists.freedesktop.org>, <seanpaul@chromium.org>,
	<swboyd@chromium.org>, <nganji@codeaurora.org>,
	<aravindh@codeaurora.org>, <khsieh@codeaurora.org>,
	<daniel@ffwll.ch>, <dmitry.baryshkov@linaro.org>
Subject: Re: [PATCH] devcoredump: increase the device delete timeout to 10 mins
Date: Tue, 8 Feb 2022 13:04:43 -0800	[thread overview]
Message-ID: <ebd340e4-2a02-d484-2ed0-9ee738d5b5c5@quicinc.com> (raw)
In-Reply-To: <8d67484c7e4b9fb4560d2eca1f71c75fde8bae0d.camel@sipsolutions.net>

Hi Johannes

Thanks for the response.

On 2/8/2022 12:35 PM, Johannes Berg wrote:
> On Tue, 2022-02-08 at 11:44 -0800, Abhinav Kumar wrote:
>> There are cases where depending on the size of the devcoredump and the speed
>> at which the usermode reads the dump, it can take longer than the current 5 mins
>> timeout.
>>
>> This can lead to incomplete dumps as the device is deleted once the timeout expires.
>>
>> One example is below where it took 6 mins for the devcoredump to be completely read.
>>
>> 04:22:24.668 23916 23994 I HWDeviceDRM::DumpDebugData: Opening /sys/class/devcoredump/devcd6/data
>> 04:28:35.377 23916 23994 W HWDeviceDRM::DumpDebugData: Freeing devcoredump node
>>
>> Increase the timeout to 10 mins to accommodate system delays and large coredump
>> sizes.
>>
> 
> No real objection, I guess, but can the data actually disappear *while*
> the sysfs file is open?!
> 
> Or did it take 5 minutes to open the file?
> 
> If the former, maybe we should fix that too (or instead)?
> 
> johannes

It opened the file rightaway but could not finish reading.

The device gets deleted so the corresponding /data will disappear too ( 
as the data node is under devcd*/data)

60 static void devcd_del(struct work_struct *wk)
61 {
62 	struct devcd_entry *devcd;
63
64 	devcd = container_of(wk, struct devcd_entry, del_wk.work);
65
66 	device_del(&devcd->devcd_dev);
67 	put_device(&devcd->devcd_dev);
68 }

Are you suggesting we implement a logic like :

a) if the usermode has started reading the data but has not finished yet 
( we can detect the former with something like devcd->data_read_ongoing 
= 1 and we know it has finished when it acks and we can clear this flag 
then), in the timeout del_wk then we can delay the the delete timer by 
another TIMEOUT amount of time to give usermode time to finish the data?

b) If usermode acks, we will clear both the flag and delete the device 
as usual

But there is a corner case here:

c) If usermode starts the read, but then for some reason crashes, the 
timer will timeout and try to delete the device but will detect that 
usermode is still reading and will keep the device. How do we detect 
this case?

Thats why i thought maybe the easier way right now is to try increasing 
the timeout.

  reply	other threads:[~2022-02-08 22:22 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-08 19:44 [PATCH] devcoredump: increase the device delete timeout to 10 mins Abhinav Kumar
2022-02-08 20:35 ` Johannes Berg
2022-02-08 21:04   ` Abhinav Kumar [this message]
2022-02-08 21:12     ` Johannes Berg
2022-02-08 21:40       ` Abhinav Kumar
2022-02-08 21:54         ` Johannes Berg
2022-02-09  1:55           ` Abhinav Kumar
2022-02-09  7:50             ` Johannes Berg
2022-02-09 16:29               ` Abhinav Kumar
2022-02-11 11:09             ` Greg KH
2022-02-11 11:09 ` Greg KH
2022-02-11 18:59   ` Abhinav Kumar
2022-02-12  7:04     ` Greg KH
2022-02-12  7:52       ` Abhinav Kumar
2022-02-12  8:24         ` Johannes Berg
2022-02-12  8:35           ` Abhinav Kumar
2022-02-28 21:38             ` Abhinav Kumar
2022-03-01  6:48               ` David Laight
2022-03-01 17:45                 ` Rob Clark
2022-03-11 11:53                   ` Johannes Berg
2022-02-12  8:29         ` Greg KH
2022-02-12  8:33           ` Abhinav Kumar

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=ebd340e4-2a02-d484-2ed0-9ee738d5b5c5@quicinc.com \
    --to=quic_abhinavk@quicinc.com \
    --cc=aravindh@codeaurora.org \
    --cc=daniel@ffwll.ch \
    --cc=dmitry.baryshkov@linaro.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=freedreno@lists.freedesktop.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=johannes@sipsolutions.net \
    --cc=khsieh@codeaurora.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nganji@codeaurora.org \
    --cc=rafael@kernel.org \
    --cc=robdclark@gmail.com \
    --cc=seanpaul@chromium.org \
    --cc=swboyd@chromium.org \
    /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