On 10/17/2013 06:41 AM, Douglas Gilbert wrote:
> That seems to be the case. Vaughan acknowledged the
> problem and forwarded it to me 8 days ago. Yes, it
> seems to be a "no-no" to hold a any kernel semaphore
> when returning to the user space; in this case from
> sg_open(). I was hoping a revised
On 13-10-16 09:24 AM, James Bottomley wrote:
On Tue, 2013-10-08 at 09:45 -0400, Douglas Gilbert wrote:
On 13-10-08 02:44 AM, vaughan wrote:
Hi Madper,
CC to Douglas to get comments.
I use the rw_semaphore o_sem to protect excl open, introduced in commit
15b06f9a02406e5460001db6d5af5c738cd3d4e7
On Tue, 2013-10-08 at 09:45 -0400, Douglas Gilbert wrote:
> On 13-10-08 02:44 AM, vaughan wrote:
> > Hi Madper,
> >
> > CC to Douglas to get comments.
> > I use the rw_semaphore o_sem to protect excl open, introduced in commit
> > 15b06f9a02406e5460001db6d5af5c738cd3d4e7 since v3.12-rc1.
> > Is it
64680]
[ 12.864681] [ BUG: lock held when returning to user space! ]
[ 12.864682] 3.12.0-rc2 #1 Not tainted
[ 12.864683]
[ 12.864684] iprinit/719 is leaving the kernel with locks still
.12-rc2 the dmesg shows following logs:
>> [ 12.864680] ============
>> [ 12.864681] [ BUG: lock held when returning to user space! ]
>> [ 12.864682] 3.12.0-rc2 #1 Not tainted
>> [ 12.864683]
lowing logs:
> [ 12.864680]
> [ 12.864681] [ BUG: lock held when returning to user space! ]
> [ 12.864682] 3.12.0-rc2 #1 Not tainted
> [ 12.864683]
> [ 12.864684] iprinit/719 is lea
Hi all,
With kernel3.12-rc2 the dmesg shows following logs:
[ 12.864680]
[ 12.864681] [ BUG: lock held when returning to user space! ]
[ 12.864682] 3.12.0-rc2 #1 Not tainted
[ 12.864683
t; > >
> > > > Signed-off-by: Davidlohr Bueso
> > > > Tested-by: Sedat Dilek
> > > > Cc: Rik van Riel
> > > > Cc: Manfred Spraul
> > > > Signed-off-by: Andrew Morton
>
: Sedat Dilek
> > > Cc: Rik van Riel
> > > Cc: Manfred Spraul
> > > Signed-off-by: Andrew Morton
> > >
> > > [ 20.702156]
> > > [ 20.702493]
> > > [ 20.703511] [ BUG: lock held when returning to user space! ]
>
> > Signed-off-by: Davidlohr Bueso
> > Tested-by: Sedat Dilek
> > Cc: Rik van Riel
> > Cc: Manfred Spraul
> > Signed-off-by: Andrew Morton
> >
> > [ 20.702156]
> > [ 20.702493] =
t; Signed-off-by: Andrew Morton
>
> [ 20.702156]
> [ 20.702493] ================
> [ 20.703511] [ BUG: lock held when returning to user space! ]
> [ 20.704532] 3.11.0-rc1-next-20130719 #50 Not tainted
> [ 20.705416] ---
On Sun, 28 Oct 2007 00:47:15 +0200 (CEST)
Jiri Kosina <[EMAIL PROTECTED]> wrote:
> Yes, but the fact is that is really is invalid use of mutex -- because the
> mutex owner could become seriously wrong after fork() or sending the
> filedescriptor through unix socket ... this easily leads to broke
On Sun, 28 Oct 2007 12:12:19 +0100 (CET)
Jiri Kosina <[EMAIL PROTECTED]> wrote:
> On Sat, 27 Oct 2007, Andrew Morton wrote:
>
> > It's a fairly daft thing to do. I think it'd be saner to teach rtc about
> > test_and_set_bit() personally..
>
>
> From: Jiri Kosina <[EMAIL PROTECTED]>
>
> RTC:
(CC list stripped)
On Sat, 27 Oct 2007, Andrew Morton wrote:
> It's a fairly daft thing to do. I think it'd be saner to teach rtc about
> test_and_set_bit() personally..
From: Jiri Kosina <[EMAIL PROTECTED]>
RTC: convert mutex to bitfield
RTC code is using mutex to assure exclusive access to
On Sat, 27 Oct 2007, Peter Zijlstra wrote:
> > > [ 592.752781]
> > > [ 592.753478] [ BUG: lock held when returning to user space! ]
> > > [ 592.753880]
> > > [
On Sat, 27 Oct 2007 18:09:29 +0200
Peter Zijlstra <[EMAIL PROTECTED]> wrote:
>
>
> Right, the fd could be transferred using unix sockets or fork(). That
> would indeed seriously break a mutex.
>
or just multi-threaded app..
>
--
If you want to reach me at my work email, use [EMAIL PROTEC
On Sat, 27 Oct 2007, Peter Zijlstra wrote:
>
> Now I could probably come up with an annotation to hide it, but what do
> other people think, Ingo, Linus, Andrew, do we want to keep kernel locks
> held over userspace?
Definitely not a sane thing to do. It should use ref-counting and/or a
single
y in dmesg after booting current git (
> > > ec3b67c11df42362ccda81261d62829042f223f0 ) :
> > > ...
> > > [ 592.752777]
> > > [ 592.752781] ================
> > > [ 592.753478] [ BUG: lock held when returning to user space! ]
> > > [ 592.753880] ---
gt; [ 592.752777]
> > [ 592.752781] ========
> > [ 592.753478] [ BUG: lock held when returning to user space! ]
> > [ 592.753880]
> > [ 592.754262] hwclock/1452 is leaving the kernel with lock
; ec3b67c11df42362ccda81261d62829042f223f0 ) :
> > > ...
> > > [ 592.752777]
> > > [ 592.752781] ====================
> > > [ 592.753478] [ BUG: lock held when returning to user space! ]
> > > [ 592.753880] -
592.752777]
> > [ 592.752781] ========
> > [ 592.753478] [ BUG: lock held when returning to user space! ]
> > [ 592.753880]
> > [ 592.754262] hwclock/1452 is leaving the kernel with locks still held!
> > [ 592.754655]
On Sat, 27 Oct 2007, Gabriel C wrote:
> I found that today in dmesg after booting current git (
> ec3b67c11df42362ccda81261d62829042f223f0 ) :
> ...
> [ 592.752777]
> [ 592.752781]
> [ 592.753478] [ BUG: lock held when retur
Hi,
I found that today in dmesg after booting current git (
ec3b67c11df42362ccda81261d62829042f223f0 ) :
...
[ 592.752777]
[ 592.752781]
[ 592.753478] [ BUG: lock held when returning to user space! ]
[ 592.753880
23 matches
Mail list logo
