netdev - Re: [PATCH net v1] ptp: Make max_phase_adjustment sysfs device attribute invisible when not supported

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 28 Jun 2023 16:35:41 +0200
From:   Andrew Lunn <andrew@...n.ch>
To:     Rahul Rameshbabu <rrameshbabu@...dia.com>
Cc:     netdev@...r.kernel.org, Richard Cochran <richardcochran@...il.com>,
        Paolo Abeni <pabeni@...hat.com>,
        Jakub Kicinski <kuba@...nel.org>,
        Saeed Mahameed <saeed@...nel.org>,
        Gal Pressman <gal@...dia.com>,
        "David S. Miller" <davem@...emloft.net>,
        lkft-triage@...ts.linaro.org, LTP List <ltp@...ts.linux.it>,
        Nathan Chancellor <nathan@...nel.org>,
        Naresh Kamboju <naresh.kamboju@...aro.org>,
        Linux Kernel Functional Testing <lkft@...aro.org>
Subject: Re: [PATCH net v1] ptp: Make max_phase_adjustment sysfs device
 attribute invisible when not supported

> >> diff --git a/drivers/ptp/ptp_sysfs.c b/drivers/ptp/ptp_sysfs.c
> >> index 77219cdcd683..6e4d5456a885 100644
> >> --- a/drivers/ptp/ptp_sysfs.c
> >> +++ b/drivers/ptp/ptp_sysfs.c
> >> @@ -358,6 +358,9 @@ static umode_t ptp_is_attribute_visible(struct kobject *kobj,
> >>  		   attr == &dev_attr_max_vclocks.attr) {
> >>  		if (ptp->is_virtual_clock)
> >>  			mode = 0;
> >> +	} else if (attr == &dev_attr_max_phase_adjustment.attr) {
> >> +		if (!info->adjphase || !info->getmaxphase)
> >> +			mode = 0;
> >
> > Maybe it is time to turn this into a switch statement?
> 
> I agree. However, I do not want to conflate two separate things being a
> bugfix and a cleanup. I think we can do one of two options.
> 
>   1. We can take this patch as is, but I submit a subsequent cleanup patch for
>   this.

Fine by me.

> > 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.

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.

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....

       Andrew