From: Rahul Rameshbabu via ltp <ltp@lists.linux.it>
To: Andrew Lunn <andrew@lunn.ch>
Cc: Linux Kernel Functional Testing <lkft@linaro.org>,
netdev@vger.kernel.org,
Richard Cochran <richardcochran@gmail.com>,
lkft-triage@lists.linaro.org,
"David S. Miller" <davem@davemloft.net>,
Nathan Chancellor <nathan@kernel.org>,
Saeed Mahameed <saeed@kernel.org>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Gal Pressman <gal@nvidia.com>, LTP List <ltp@lists.linux.it>
Subject: Re: [LTP] [PATCH net v1] ptp: Make max_phase_adjustment sysfs device attribute invisible when not supported
Date: Wed, 28 Jun 2023 10:48:21 -0700 [thread overview]
Message-ID: <87ilb7qxzu.fsf@nvidia.com> (raw)
In-Reply-To: <0e82eff0-16ba-49b0-933d-26f49515d434@lunn.ch> (Andrew Lunn's message of "Wed, 28 Jun 2023 16:35:41 +0200")
On Wed, 28 Jun, 2023 16:35:41 +0200 Andrew Lunn <andrew@lunn.ch> wrote:
>> > I also wounder if this really is something for net. How do you think
>> > this patch matches against the stable rules?
>>
>> Apologize in advance but not sure I am following along. The commit for
>> the patch the introduces the problematic logic has made its way to net
>> and this patch is a fix. Therefore, isn't net the right tree to target?
>
> Humm. So c3b60ab7a4df is in net-next, and the tag net-next-6.5. So it
> was passed to Linus yesterday for merging. You would like this fix
> merged either before -rc1, or just after -rc1.
It can be after -rc1. I understand your point now from this elaboration.
Since the change is not heading towards a final release yet but a
release candidate, it's not an "urgent" patch to be applied before -rc1.
>
> We are in the grey area where it is less clear which tree it should be
> against. So it is good to explain after the --- what your intention
> is, so the Maintainers get a heads up and understand what you are
> trying to achieve.
Agreed, I could have used git notes for that in my patch generation.
Noted for the future. Just to be clear, my intention is for this fix to
make its way before the final 6.5 release (before the changes make their
way to an end user since the NULL pointer dereference when reading that
sysfs node from a PHC not supporting phase adjustment is problematic). I
think the issue being present in a release candidate is a minor problem.
Would I still keep the Fixes tag however if targeting net-next? I
remember this email from Jakub where if a Fixes tag is used, the patch
should end up in net rather than net-next. However, I fear that without
a Fixes tag, targeting net-next would cause me to miss applying this
fix before the 6.5 release.
Link: https://lore.kernel.org/netdev/20230607091909.321fc5d7@kernel.org/
----- BEGIN QUOTE -----
We'll obviously apply our own judgment but submitter should send all
fixes against net.
------ END QUOTE ------
I personally think this fix is "worthy" of targeting net based on the
discussion Jakub previously provided, given the impact of reading the
sysfs node on a system without this patch on PHCs that do not support
phase adjustment.
>
> I actually thought you were trying to fix an older issue, something in
> 6.4 or older, which is what net is mostly used for. Under those
> conditions, the stable rules apply. Things like, is this fixing an
> issue which really effects users....
Right, this was caught before it made its way to general users. I was
basing targeting net still from the previous conversation about Fixes
tags.
>
> Andrew
Thanks,
Rahul Rameshbabu
--
Mailing list info: https://lists.linux.it/listinfo/ltp
next prev parent reply other threads:[~2023-06-29 9:06 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-27 23:21 [LTP] [PATCH net v1] ptp: Make max_phase_adjustment sysfs device attribute invisible when not supported Rahul Rameshbabu via ltp
2023-06-27 23:33 ` Nathan Chancellor
2023-06-28 1:16 ` Andrew Lunn
2023-06-28 2:22 ` Rahul Rameshbabu via ltp
2023-06-28 14:35 ` Andrew Lunn
2023-06-28 17:48 ` Rahul Rameshbabu via ltp [this message]
2023-06-28 18:15 ` Andrew Lunn
2023-06-28 20:38 ` Jakub Kicinski
2023-06-28 20:46 ` Andrew Lunn
2023-06-28 20:55 ` Rahul Rameshbabu via ltp
2023-06-29 18:06 ` Jakub Kicinski
2023-06-30 3:33 ` Richard Cochran
2023-06-30 3:32 ` Richard Cochran
2023-07-03 5:10 ` Petr Vorel
2023-07-03 12:53 ` Cyril Hrubis
2023-07-03 20:40 ` patchwork-bot+netdevbpf
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=87ilb7qxzu.fsf@nvidia.com \
--to=ltp@lists.linux.it \
--cc=andrew@lunn.ch \
--cc=davem@davemloft.net \
--cc=gal@nvidia.com \
--cc=kuba@kernel.org \
--cc=lkft-triage@lists.linaro.org \
--cc=lkft@linaro.org \
--cc=nathan@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=richardcochran@gmail.com \
--cc=rrameshbabu@nvidia.com \
--cc=saeed@kernel.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