From: "Souza, Jose" <jose.souza@intel.com>
To: "intel-xe@lists.freedesktop.org" <intel-xe@lists.freedesktop.org>,
"johannes@sipsolutions.net" <johannes@sipsolutions.net>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Cc: "Vivi, Rodrigo" <rodrigo.vivi@intel.com>,
"quic_mojha@quicinc.com" <quic_mojha@quicinc.com>,
"Cavitt, Jonathan" <jonathan.cavitt@intel.com>,
"De Marchi, Lucas" <lucas.demarchi@intel.com>
Subject: Re: [PATCH v3 2/4] devcoredump: Add dev_coredumpm_timeout()
Date: Mon, 25 Mar 2024 18:28:03 +0000 [thread overview]
Message-ID: <c9c5436eb51f181aa78d63e0842457dc0c4da887.camel@intel.com> (raw)
In-Reply-To: <50c40ce746f1497cbc36ad82d6d0d3ca3ac28547.camel@sipsolutions.net>
On Mon, 2024-03-25 at 18:00 +0100, Johannes Berg wrote:
> On Mon, 2024-03-04 at 06:39 -0800, José Roberto de Souza wrote:
> > Add function to set a custom coredump timeout.
> >
> > Current 5-minute timeout may be too short for users to search and
> > understand what needs to be done to capture coredump to report bugs.
>
> > + */
> > +static inline void dev_coredumpm(struct device *dev, struct module *owner,
> > + void *data, size_t datalen, gfp_t gfp,
> > + ssize_t (*read)(char *buffer, loff_t offset, size_t count,
> > + void *data, size_t datalen),
> > + void (*free)(void *data))
>
> nit: looks like you missed a space on the 'free' line
>
> I don't think we'll actually _solve_ the discussion of whether or not
> this makes sense.
>
> I still think it's a bad idea to hang on to the dumps in core kernel
> memory since they can be big (I would've said ath12k is big with 55MB,
> but Rodrigo said graphics could be up to 2GB!), without being able to
> page it out, etc. That's just a waste of memory, for what I don't think
> is even a good reason.
>
There is a discussion to have a udev script to copy dump from memory to disk and then the script can write 0 to coredump/data and erase it from
memory. But if distro don't have this udev script it is still good to have larger timeout to allow user to capture it.
The 2GB usage are for cases when UMD developers enables the capture of every single buffer, regular capture size depends on the complexity of the
application but it is generally round 2MB.
> So dunno.
>
> However, I also don't like to exercise any power that I might randomly
> hold just because I happened to write the code in the first place... And
> if you want to shoot yourselves in the foot with any of this, should I
> really disagree? I feel I've voiced my objections enough, and Lucas has
> also tried to find ways of making a userspace implementation work for
> you.
>
> I'd perhaps argue that the documentation for the functions should be
> more opinionated and actually recommend against using a large timeout
> (like you want) for all these reasons, but other than that, the code
> looks fine to me.
@timeout: time in jiffies to remove coredump. DEVCOREDUMP_TIMEOUT is the value for dev_coredumpm() and it should be used unless it is absolutely
necessary a larger timeout.
Or do you have a better suggestion?
>
> johannes
next prev parent reply other threads:[~2024-03-25 18:28 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-04 14:39 [PATCH v3 1/4] devcoredump: Add dev_coredump_put() José Roberto de Souza
2024-03-04 14:39 ` [PATCH v3 2/4] devcoredump: Add dev_coredumpm_timeout() José Roberto de Souza
2024-03-04 23:56 ` Lucas De Marchi
2024-03-11 20:56 ` Souza, Jose
2024-03-25 17:00 ` Johannes Berg
2024-03-25 18:28 ` Souza, Jose [this message]
2024-03-04 14:39 ` [PATCH v3 3/4] drm/xe: Remove devcoredump during driver release José Roberto de Souza
2024-03-04 14:39 ` [PATCH v3 4/4] drm/xe: Increase devcoredump timeout José Roberto de Souza
2024-03-25 16:48 ` [PATCH v3 1/4] devcoredump: Add dev_coredump_put() Johannes Berg
2024-03-25 18:36 ` Souza, Jose
2024-04-05 15:47 ` Souza, Jose
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=c9c5436eb51f181aa78d63e0842457dc0c4da887.camel@intel.com \
--to=jose.souza@intel.com \
--cc=intel-xe@lists.freedesktop.org \
--cc=johannes@sipsolutions.net \
--cc=jonathan.cavitt@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lucas.demarchi@intel.com \
--cc=quic_mojha@quicinc.com \
--cc=rodrigo.vivi@intel.com \
/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