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: <47E3E83F.3070508@s5r6.in-berlin.de>
Date:	Fri, 21 Mar 2008 17:54:23 +0100
From:	Stefan Richter <stefanr@...6.in-berlin.de>
To:	Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>
CC:	akpm@...ux-foundation.org, linux-kernel@...r.kernel.org
Subject: Re: use of preempt_count instead of in_atomic() at leds-gpio.c

Tetsuo Handa wrote:
> Hello.
> 
>>> In short, you are saying that there is _no_ reliable way to determine
>>> am-i-called-from-inside-spinlock.
>> That's correct.
> 
> So, it is impossible to know whether I am inside a spinlock or not.
> OK. That's not what I want to do.
> 
> I want to make sure that my code (not a device driver) is called only from a context
> where use of down()/mutex_lock()/kmalloc(GFP_KERNEL)/get_user_pages()/kmap() etc. are permitted.
> Is "if (in_atomic()) return;" check a correct method for avoiding deadlocks
> when my code was accidentally called from a context
> where use of down()/mutex_lock()/kmalloc(GFP_KERNEL)/get_user_pages()/kmap() etc. are not permitted?
> I'm assuming that in_atomic() returns nonzero whenever scheduling is not permitted.

You shouldn't sleep while holding a spinlock.  As soon as another thread 
attempts to take the spinlock, it will be stuck in a busy-wait loop.

So, it's better if you specify that your code either can be called in 
atomic context or must not be called in atomic context, and all callers 
observe this restriction.  Or callers pass a flag to your code which 
says whether your code is allowed to sleep or not.
-- 
Stefan Richter
-=====-==--- --== =-=-=
http://arcgraph.de/sr/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ