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]
Message-ID: <YJo3LoDSqr18YiNh@smile.fi.intel.com>
Date:   Tue, 11 May 2021 10:50:06 +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 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:
> >>> Switch to use module_parport_driver() to reduce boilerplate code.
> >>>
> >>> Signed-off-by: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
> >>> ---
> >>>  drivers/pps/clients/pps_parport.c | 42 ++++++-------------------------
> >>>  1 file changed, 8 insertions(+), 34 deletions(-)
> >>>
> >>> diff --git a/drivers/pps/clients/pps_parport.c b/drivers/pps/clients/pps_parport.c
> >>> index 7a41fb7b0dec..42f93d4c6ee3 100644
> >>> --- a/drivers/pps/clients/pps_parport.c
> >>> +++ b/drivers/pps/clients/pps_parport.c
> >>> @@ -22,8 +22,6 @@
> >>>  #include <linux/parport.h>
> >>>  #include <linux/pps_kernel.h>
> >>>  
> >>> -#define DRVDESC "parallel port PPS client"
> >>> -
> >>>  /* module parameters */
> >>>  
> >>>  #define CLEAR_WAIT_MAX		100
> >>> @@ -138,6 +136,12 @@ static void parport_attach(struct parport *port)
> >>>  		.dev		= NULL
> >>>  	};
> >>>  
> >>> +	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.

> Maybe Alexander (in CC) can help us? :)

-- 
With Best Regards,
Andy Shevchenko


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ