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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20211011082134.GM2083@kadam>
Date:   Mon, 11 Oct 2021 11:21:34 +0300
From:   Dan Carpenter <dan.carpenter@...cle.com>
To:     "Fabio M. De Francesco" <fmdefrancesco@...il.com>
Cc:     linux-staging@...ts.linux.dev, gregkh@...uxfoundation.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] staging: r8188eu: Provide a TODO file for this driver

On Sun, Oct 10, 2021 at 11:21:49AM +0200, Fabio M. De Francesco wrote:
> On Saturday, October 9, 2021 6:31:12 PM CEST Fabio M. De Francesco wrote:
> > On Thursday, August 26, 2021 3:54:13 PM CEST Dan Carpenter wrote:
> > > Another thing to fix are some of the sleeping in atomic bugs.
> > > 
> > > drivers/staging/r8188eu/core/rtw_ap.c:139 update_BCNTIM() warn: sleeping
> > > in atomic context
> > > drivers/staging/r8188eu/core/rtw_ap.c:1296 update_bcn_wps_ie() warn: 
> > > sleeping in atomic context
> > >
> > > [...]
> > >
> > Hello Dan,
> > 
> > I'd like to address these kind of bugs, but I have a couple of questions 
> > about them.
> > 
> > 1) You've listed what looks like the output of a compiler or static
> > analyzer. 
> > How did you get the warnings you copy-pasted above?
> > 
> > 2) I know that both the execution of interrupt handlers (ISRs) as well as
> > any 
> > code blocks that are executed holding spinlocks are "atomic contexts". In 
> > these cases, "sleeping" is not allowed (for obvious reasons). Besides the
> > two 
> > mentioned above, are there any further cases of "atomic contexts" in the 
> > kernel?
> 
> After some research, I've found that Softirqs and Tasklets are also executed 
> in "atomic context", as hardware interrupt service routines are.
> 
> Furthermore, I've also found a .config option named DEBUG_ATOMIC_SLEEP
> that should warn if some code is sleeping in "atomic context". However, the 
> documentation of that option does not explain where the output of these 
> checks can be read.
> 
> I would appreciate any help on this matter.

These are a new Smatch warning.

https://lkml.org/lkml/2021/9/1/950

You would need to rebuild the Smatch database probably around five times
to see the warnings.  It takes a long time to build...  It's probably
not that hard to figure out just from looking at the code without the
generating the warning.

So spin locks can't sleep.  Mutexes can.  There are read/write locks,
built on both mutexes and spin locks.  Rcu_read/write cannot sleep.

regards,
dan carpenter

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ