[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250116174405.20a0e20b@kernel.org>
Date: Thu, 16 Jan 2025 17:44:05 -0800
From: Jakub Kicinski <kuba@...nel.org>
To: Breno Leitao <leitao@...ian.org>
Cc: Andrew Lunn <andrew+netdev@...n.ch>, "David S. Miller"
<davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>, Paolo Abeni
<pabeni@...hat.com>, Simon Horman <horms@...nel.org>, Jonathan Corbet
<corbet@....net>, Shuah Khan <shuah@...nel.org>, netdev@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-doc@...r.kernel.org,
linux-kselftest@...r.kernel.org, kernel-team@...a.com, max@...sevol.com,
thepacketgeek@...il.com
Subject: Re: [PATCH net-next v2 3/5] netconsole: add support for sysdata and
CPU population
On Wed, 15 Jan 2025 05:35:20 -0800 Breno Leitao wrote:
> + WARN_ON_ONCE(userdata_len + sysdata_len >
> + MAX_EXTRADATA_ENTRY_LEN * MAX_EXTRADATA_ITEMS);
> +
> + /* nt->sysdata_length will be used later to decide if the message
> + * needs to be fragmented.
> + * userdata_len cannot be used for it, once next sysdata append should
> + * start from the same userdata_len location, and only overwrite old
> + * sysdata.
> + */
> + nt->sysdata_length = sysdata_len;
Updating nt-> fields at runtime is something we haven't done before,
right? What's the locking? We depend on target_list_lock ?
Looks like previously all the data was on the stack, now we have a mix.
Maybe we can pack all the bits of state into a struct for easier
passing around, but still put it on the stack?
Powered by blists - more mailing lists