linux-kernel - Re: [PATCH v1 1/1] pps: clients: parport: Switch to use module_parport

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] [day] [month] [year] [list]

Date:   Tue, 11 May 2021 17:11:30 +0300
From:   Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
To:     Rodolfo Giometti <giometti@...eenne.com>
Cc:     linux-kernel@...r.kernel.org, gregkh@...uxfoundation.org,
        Alexander Gordeev <lasaine@....cs.msu.su>
Subject: Re: [PATCH v1 1/1] pps: clients: parport: Switch to use
 module_parport_driver()

On Tue, May 11, 2021 at 10:46:01AM +0200, Rodolfo Giometti wrote:
> On 11/05/21 09:50, Andy Shevchenko wrote:
> > On Tue, May 11, 2021 at 09:26:36AM +0200, Rodolfo Giometti wrote:
> >> On 11/05/21 09:18, Andy Shevchenko wrote:
> >>> On Tue, May 11, 2021 at 09:05:00AM +0200, Rodolfo Giometti wrote:
> >>>> On 10/05/21 16:13, Andy Shevchenko wrote:

...

> >>>>> +	if (clear_wait > CLEAR_WAIT_MAX) {
> >>>>> +		pr_err("clear_wait value should be not greater then %d\n",
> >>>>> +		       CLEAR_WAIT_MAX);
> >>>>> +		return;
> >>>>> +	}
> >>>>> +
> >>>>
> >>>> Why do you need to do so? Maybe a comment would be welcomed.
> >>>
> >>> It's in original code, I just moved it to ->probe().
> >>>
> >>> What comment do you want to have here, because original code has no comment (I
> >>> think in any case it's out of scope of this change, but may be prepended or
> >>> appended to the series)?
> >>
> >> Mmm... these functions can be called at different times, so I don't know if we
> >> can just move the code safely.
> > 
> > I do not see any issue here. TL;DR: it won't be worse, but might even give an
> > improvement.
> > 
> > Before it prevented to module to be initialized,
> > now one may amend this at run time. the downside is that now it will require
> > module removal and inserting versus just two attempts of inserting in a row.
> > 
> > For the built-in case it shouldn't change much (but if
> > /sys/module/.../parameters/... is writable for this, then it will allow to do
> > the similar trick as above, so extending functionality with the flexibility,
> > means direct improvement).
> > 
> > Okay, permissions are 0 there, I don't remember what it means, maybe the
> > parameter won't be available under /sysfs at all, but again, it won't change
> > the functional behaviour, the downside is the memory consumed by the 'built-in'
> > code at run time.
> 
> OK, I see. If so

At least this is my understanding how it works before and after the change.
If anybody has something to clarify here, I would be glad to learn!

> it's OK for me:
> 
> Acked-by: Rodolfo Giometti <giometti@...eenne.com>

Thanks!

-- 
With Best Regards,
Andy Shevchenko