linux-kernel - Re: [PATCH] staging: pi433: modify bit

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:   Tue, 31 Jan 2023 11:19:36 +0100
From:   Guru Mehar Rachaputi <gurumeharrachaputi@...il.com>
To:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc:     linux-staging@...ts.linux.dev, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] staging: pi433: modify bit_rate from u16 to u32

On Tue, Jan 31, 2023 at 06:22:23AM +0100, Greg Kroah-Hartman wrote:
> On Tue, Jan 31, 2023 at 03:11:38AM +0100, Guru Mehar Rachaputi wrote:
> > (struct pi433_tx_cfg)->bit_rate is modified from u16 to u32 to
> > support bit rates up to 300kbps per the spec
> 
> What spec?
> 
> And how can changing the size of a variable that crosses the user/kernel
> boundry like this change the bit rate max?
>
Honestly, I followed the TODO file suggestion.
> > 
> > Signed-off-by: Guru Mehar Rachaputi <gurumeharrachaputi@...il.com>
> > ---
> >  drivers/staging/pi433/pi433_if.h | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/drivers/staging/pi433/pi433_if.h b/drivers/staging/pi433/pi433_if.h
> > index 25ee0b77a32c..1f8ffaf02d99 100644
> > --- a/drivers/staging/pi433/pi433_if.h
> > +++ b/drivers/staging/pi433/pi433_if.h
> > @@ -51,7 +51,7 @@ enum option_on_off {
> >  #define PI433_TX_CFG_IOCTL_NR	0
> >  struct pi433_tx_cfg {
> >  	__u32			frequency;
> > -	__u16			bit_rate;
> > +	__u32			bit_rate;
> >  	__u32			dev_frequency;
> >  	enum modulation		modulation;
> >  	enum mod_shaping	mod_shaping;
> 
> And didn't you just break existing userspace code?  If not, how?  If so,
> how did you test this?
>
My apologies, I did not study code. While testing, the probe function of
pi433 driver didn't appear in the lsmod operation. I suspected my
testing was wrong.

> thanks,
> 
> greg k-h