linux-kernel - Re: [PATCH] staging: axis-fifo: initialize timeouts in probe only

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: <2510576.EEEGcR9oU2@suse>
Date:   Tue, 14 Mar 2023 20:07:07 +0100
From:   "Fabio M. De Francesco" <fmdefrancesco@...il.com>
To:     Khadija Kamran <kamrankhadijadj@...il.com>
Cc:     Nathan Chancellor <nathan@...nel.org>,
        Alison Schofield <alison.schofield@...el.com>,
        outreachy@...ts.linux.dev, llvm@...ts.linux.dev,
        oe-kbuild-all@...ts.linux.dev,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        linux-staging@...ts.linux.dev, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] staging: axis-fifo: initialize timeouts in probe only

On martedì 14 marzo 2023 16:13:53 CET Alison Schofield wrote:
> On Tue, Mar 14, 2023 at 07:42:07AM -0700, Nathan Chancellor wrote:
> > Hi Khadija,
> > 
> > On Tue, Mar 14, 2023 at 07:08:31PM +0500, Khadija Kamran wrote:
> > > On Tue, Mar 14, 2023 at 11:45:51AM +0800, kernel test robot wrote:
> > > >
> > > > [...]
> > > 
> > > Hi everyone!
> > > Kindly let me know if I should look into these warnings.
> > > Thank you!
> > 
> > You should always avoid introducing new warnings whenever possible. In
> > this case, it appears that read_timeout and write_timeout should be
> > changed from 'int' to 'long' to account for the fact that
> > MAX_SCHEDULE_TIMEOUT is being assigned to it directly now, versus being
> > passed as a parameter to wait_event_interruptible_timeout(), which
> > assigned it to 'long' anyways.
> > 
> > If you have any other questions or need further help, let me know :)
> > 
> > Cheers,
> > Nathan
> 
> Hi Khadija,
> 
> Echoing Nathan's feedback - yes, you need to correct these.
> 
> Do you see these warnings when you compiled?  If yes, then your path to
> fixing them is easier. Make sure it recompiles with no warnings.
> 
> If you don't see these warnings, then you need to follow the steps to
> reproduce in the lkp email. You have to be able to 'see the warning'
> make a change and 'see it go away'.
> 
> Alison
> 

Hi Khadija,

I would suggest trying to recompile using "make W=1 -j...". Not sure if you'll 
see the warnings (depends on your compiler, version and target architecture). 
However, it's worth a try as it may save you the time it takes to go through 
the steps for reproduction.

Anyway, as Nathan said, that warning is triggered by assigning 'long' to 'int' 
(i.e., "MAX_SCHEDULE_TIMEOUT" is cast to 'long', while the types of 
"read_timeout" and "write_timeout " are both 'int'). Obviously, these kinds of  
assignments overflow wherever the representation of type 'long' uses more bits 
than the type 'int'.

That implies that you should try to understand where the module's parameters 
are defined and how to work with the related macros.

I hope it helps.

Fabio

P.S.: If you don't know yet what to do, take a look at the following document:
https://sysprog21.github.io/lkmpg/ (The Linux Kernel Module Programming 
Guide).