linux-kernel - Re: mutex_unlock() in interrupt context

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] [day] [month] [year] [list]

Message-Id: <20070717000138.0d255ed5.akpm@linux-foundation.org>
Date:	Tue, 17 Jul 2007 00:01:38 -0700
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	Jerry Cooperstein <jerry.cooperstein@...rter.net>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: mutex_unlock() in interrupt context

On Fri, 13 Jul 2007 19:14:56 -0500 Jerry Cooperstein <jerry.cooperstein@...rter.net> wrote:

> kernel/mutex.c says about mutex_unlock():
> 
>   * This function must not be used in interrupt context.
> 
> However I have done some simple test cases that show
> it works without complaint.  Now I understand that one
> shouldn't do this for good reasons.  So is this a
> good coding practice rule, but something that
> could appear in sloppy or poorly designed code?
> 

mutex_unlock() must be called by the process which did the mutex_lock(). 
Doing the mutex_unlock() from an interrupt will cause warnings when run
with debugging enabled.  You should run with debugging enabled when doing
any development.  

Also, mutex_unlock() takes a mutex-internal spinlock in a non-irq-safe
fashion - if the timing is right, your mutex_unlock() in IRQ context will
deadlock.

-
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/