Received-SPF: pass (google.com: domain of linux-kernel+bounces-91428-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1;
Date: Mon, 4 Mar 2024 17:55:45 -0600
From: Lucas De Marchi <lucas.demarchi@intel.com>
To: "Souza, Jose" <jose.souza@intel.com>
CC: "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>, "Vivi,
 Rodrigo" <rodrigo.vivi@intel.com>, "quic_mojha@quicinc.com"
	<quic_mojha@quicinc.com>, "Cavitt, Jonathan" <jonathan.cavitt@intel.com>
Subject: Re: [PATCH v2 2/4] devcoredump: Add dev_coredumpm_timeout()
Message-ID: <zfrpz4vuhjwmilbqft5d4qh4s3gs3okzyxbsh4lc5rhzjy5ktx@xuu32mxhun4c>
References: <20240228165709.82089-1-jose.souza@intel.com>
 <20240228165709.82089-2-jose.souza@intel.com>
 <84e4f0d70c5552dd7fa350c61c28de9637628ee6.camel@sipsolutions.net>
 <a27ac0d3bc52c2181852a25641b7020f50a50648.camel@intel.com>
 <0f4244ea6866f451f3f8a5b5e2db8be53de1f0c2.camel@sipsolutions.net>
 <bdaf62020388d3dcf8d3a95ae465c0ae2db7eca1.camel@intel.com>
Content-Type: text/plain; charset="us-ascii"; format=flowed
Content-Disposition: inline
In-Reply-To: <bdaf62020388d3dcf8d3a95ae465c0ae2db7eca1.camel@intel.com>
Precedence: bulk
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?uJ5ZEw5fEgE3n9DJ1DGAEuyOT1MEBIZUK85pHLK0oGoSf9Lwwl2Ntff0gC1+?=
 =?us-ascii?Q?oRQLay8t3a8+0sb1FvoinBR8KxMpWfJQG9HK4QB8QVGFLbXus06wYzozz1ba?=
 =?us-ascii?Q?lFSg88dODnrbWQpbas7/jEKtF+t85UgqVjn0IFB3hT9d4y2nn62RzBS515dW?=
 =?us-ascii?Q?w2BcAQHKQW+VuAIBQYRb9sgid5U6+e4uNC+cE7qWPaoAlv1YFCvSgCoEBdmc?=
 =?us-ascii?Q?9UZc4YOHcwatUnGvDZsbzzNJzDntPy92+r45TRzQkDCC4fKlxwGDhXmDD2zQ?=
 =?us-ascii?Q?+rU6CZvFqFLgKrLXX1ZdzhyBZtm7+iVR34nw2sBBIEsV5zk+oYBF7hdM80d7?=
 =?us-ascii?Q?MFcDc2aXfV6SS0ulgy0lIFblfnlX85m/uXJZhtN/BMVwZ0Q4db+j0yo22++n?=
 =?us-ascii?Q?QqNHxTmlASN/79WXiOMogdDWW5VY/3Nch2InO3E7r1/T+UskatdQ5C5NH0zA?=
 =?us-ascii?Q?n1RVz24u4TXG0Yst1e/W3vexkXkQzXl2Hmg90dOAqsMUfjegtX+P6kEnSBJQ?=
 =?us-ascii?Q?25SVXc2TnTqVE1I8srcQbIg8+4qLdgeyzSZ4xFfo0n6ndFUW9NHTlldvzER1?=
 =?us-ascii?Q?x8r4rqeBMcK70BFVVO7gMgCK1Ph/cbaoZckyRsg2UEoSngp4GFPGqHqGaPvQ?=
 =?us-ascii?Q?g1MZXptTk4e6RQc6CppjBx+E0TNcnOiTRhFIgMkHhTTlntaB1PIYHW8nVTiW?=
 =?us-ascii?Q?NEPYSmVoxeVTyClm/V1BvPG6+45Eof2zaPy+TRGwB3M+/25x2eqWO36hDa5I?=
 =?us-ascii?Q?tP/ZE3/a1oQCCtTGmgWRjHh6mdc5tmGJxse1yM9YUvyab7o0n6wLb4nWc/mH?=
 =?us-ascii?Q?djwBdi8zdJImWSIQa82OVrURoP893VEPBZ9FG5D57BslYw1Z/NMV9DhgC9Kr?=
 =?us-ascii?Q?R0toTSjQr7XAHJ0biRHE5QFZy8Khss7rIc0ygrlLYkKtxxEGT8y0UHQ2jpiE?=
 =?us-ascii?Q?1+YJbm3FgRGLxe6mDpsYY5ZeLKCekEL8a9cNRdRL2ZiYb2JHfPQFz4kMlPwV?=
 =?us-ascii?Q?zohp0/YD3mcPfeyJ+oWFKHgolc9RkYG4l1Xz+ywSoCpw1RVvjvG4+ipXNhcr?=
 =?us-ascii?Q?Ua4hkkBVK4RPgnzXACajcicJu0+sxs2Z9oOoNIADn8jTCHPVVANv4UtTmEaI?=
 =?us-ascii?Q?LnK3JIv9zl5HviCBV77NTVoVJDtbHhAre/Atnj360gTELL3rPLRv/nmXtDZJ?=
 =?us-ascii?Q?Thy+3SBIWEHmPBTk9apgv7kfLL1dkvsy86A9Uw1vLXeo22RKYuyXFPkEyHp9?=
 =?us-ascii?Q?qCR+zm8CKDx9PpQArKO3N8HyilmbcNqlSelnKpjk2yCvcoH/DcOXEcU6Zw28?=
 =?us-ascii?Q?d3UrU+4C6ZaBvv3D+xcXSdCObUSk8JXBTg2Tatr7/113gweQBxsTLm+UwdvK?=
 =?us-ascii?Q?faPi+C6K/McrWgzPiY2dboZeIzHQcbDdq1GOsDAzhNleoHxPJv0+mpTHqeBs?=
 =?us-ascii?Q?ZmBj7RJe70Ff0vlWMwxal2HZ1yw+LWj6eV2OKUiUIdLESR9KhrFuSQjnLXc/?=
 =?us-ascii?Q?yfHSDFUrlZY6mUDdXPCqkWrAz26u2aIKFMUiEZzdV80sZLzgURGemQrVc+Xy?=
 =?us-ascii?Q?fbUGHT9IrBVaNFjcPq573vM/aJhCreBytWep7B+o5UtidgEW+b6sorAhtbe7?=
 =?us-ascii?Q?sg=3D=3D?=
X-MS-Exchange-CrossTenant-Network-Message-Id: 926eff3e-a756-4c13-1fc1-08dc3ca69d1d
X-MS-Exchange-CrossTenant-AuthSource: CY5PR11MB6139.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Mar 2024 23:55:48.0153
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 46c98d88-e344-4ed4-8496-4ed7712e255d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: slSz0UACcR16zo6XtHPEhNMuZ1e44Q+A27rBMHdwFGrG3JCBLWHjAoDajGRra/H7W+HoF78cwniQeqxrl3vj4irh/zlauuF9A88uBOwgMSw=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: LV3PR11MB8507
X-OriginatorOrg: intel.com

On Mon, Mar 04, 2024 at 02:29:03PM +0000, Jose Souza wrote:
>On Fri, 2024-03-01 at 09:38 +0100, Johannes Berg wrote:
>> > On Wed, 2024-02-28 at 17:56 +0000, Souza, Jose wrote:
>> > > >
>> > > > In my opinion, the timeout should depend on the type of device driver.
>> > > >
>> > > > In the case of server-class Ethernet cards, where corporate users automate most tasks, five minutes might even be considered excessive.
>> > > >
>> > > > For our case, GPUs, users might experience minor glitches and only search for what happened after finishing their current task (writing an email,
>> > > > ending a gaming match, watching a YouTube video, etc.).
>> > > > If they land on https://drm.pages.freedesktop.org/intel-docs/how-to-file-i915-bugs.html or the future Xe version of that page, following the
>> > > > instructions alone may take inexperienced Linux users more than five minutes.
>> >
>> > That's all not wrong, but I don't see why you wouldn't automate this
>> > even on end user machines? I feel you're boxing the problem in by
>> > wanting to solve it entirely in the kernel?
>
>The other part of the stack that we provide are the libraries implementing Vulkan and OpenGL APIs, I don't think we could ship scripts that needs
>elevated privileges to read and store coredump.

it's still a very valid point though. Why are we doing this only on
kernel side or mesa side rather than doing it in the proper place?  As
Johannes said, this could very well be automated via udev rules.
Distros automate getting the coredump already with systemd-coredump and
the like.  Why wouldn't we do it similarly for GPU?  Handling this at
the proper place you leave the policy there for "how long to retain the
log", "maximum size", "rotation", etc.... outside of the kernel.

For the purposes of reporting a bug, wouldn't it be better to instruct
users to get the log that was saved to disk so they don't risk losing
it? I view the timeout more as a "protection" from the kernel side to
not waste memory if the complete stack is not in place. It shoudln't
be viewed as a timeout for how long the *user* will take to get the log
and create bug reports.

Lucas De Marchi

>
>> >
>> > > > I have set the timeout to one hour in the Xe driver, but this could increase if we start receiving user complaints.
>> >
>> > At an hour now, people will probably start arguing that "indefinitely"
>> > is about right? But at that point you're probably back to persisting
>> > them on disk anyway? Or maybe glitches happen during logout/shutdown ...
>
>i915 driver don't use coredump and it persist the error dump in memory until user frees it or reboot it and we got no complains.
>
>> >
>> > Anyway, I don't want to block this because I just don't care enough
>> > about how you do things, but I think the kernel is the wrong place to
>> > solve this problem... The intent here was to give some userspace time to
>> > grab it (and yes for that 5 minutes is already way too long), not the
>> > users. That's also part of the reason we only hold on to a single
>> > instance, since I didn't want it to keep consuming more and more memory
>> > for it if happens repeatedly.
>> >
>
>okay so will move forward with other version applying your suggestion to make dev_coredumpm() static inline and move to the header.
>
>thank you for the feedback
>
>> > johannes
>