On Thu, Jul 31, 2014 at 01:31:30AM +0300, Kirill A. Shutemov wrote:
...
> >
> > *cringe*
> >
> > I don't like it. That really should be a responsiblity of specific
> > ->show();
> > "I'm going to take that mutex, bugger off if we are in execve()" makes a lot
> > more sense than having e.g.
On Thu, Jul 31, 2014 at 01:31:30AM +0300, Kirill A. Shutemov wrote:
...
*cringe*
I don't like it. That really should be a responsiblity of specific
-show();
I'm going to take that mutex, bugger off if we are in execve() makes a lot
more sense than having e.g. seq_read() care of
On Thu, Jul 31, 2014 at 01:31:30AM +0300, Kirill A. Shutemov wrote:
> I don't know why we allow "chmod +x" on some proc files, notably net-related.
> Is it a bug?
# ls -l /proc/{1,157}/net/packet
-r--r--r-- 1 root 0 0 Jul 30 23:01 /proc/1/net/packet
-r--r--r-- 1 root 0 0 Jul 30 23:01
On Fri, Apr 11, 2014 at 04:07:25PM +0100, Al Viro wrote:
> On Fri, Apr 11, 2014 at 03:50:27PM +0100, David Howells wrote:
> > Peter Zijlstra wrote:
> >
> > > Al, David, any bright ideas on how to best fix this?
> >
> > Have the seq_xxx() code throw an error if current->in_execve is true. I
>
On Fri, Apr 11, 2014 at 04:07:25PM +0100, Al Viro wrote:
On Fri, Apr 11, 2014 at 03:50:27PM +0100, David Howells wrote:
Peter Zijlstra pet...@infradead.org wrote:
Al, David, any bright ideas on how to best fix this?
Have the seq_xxx() code throw an error if current-in_execve is true.
On Thu, Jul 31, 2014 at 01:31:30AM +0300, Kirill A. Shutemov wrote:
I don't know why we allow chmod +x on some proc files, notably net-related.
Is it a bug?
# ls -l /proc/{1,157}/net/packet
-r--r--r-- 1 root 0 0 Jul 30 23:01 /proc/1/net/packet
-r--r--r-- 1 root 0 0 Jul 30 23:01
On Fri, Apr 11, 2014 at 03:50:27PM +0100, David Howells wrote:
> Peter Zijlstra wrote:
>
> > Al, David, any bright ideas on how to best fix this?
>
> Have the seq_xxx() code throw an error if current->in_execve is true. I can't
> think of any circumstance where execve() should be reading
Peter Zijlstra wrote:
> Al, David, any bright ideas on how to best fix this?
Have the seq_xxx() code throw an error if current->in_execve is true. I can't
think of any circumstance where execve() should be reading anything that uses
seq_xxx().
David
--
To unsubscribe from this list: send the
On Thu, 10 Apr 2014 16:15:59 +0200, Peter Zijlstra said:
> On Thu, Apr 10, 2014 at 11:18:24AM +0200, Peter Zijlstra wrote:
> > So I managed to reproduce, and the below makes it go away. I just don't
> > understand why though. will stare more.
>
> /me kicks himself.. bloody obvious fail there :-)
>
On Wed, 9 Apr 2014, Jason Low wrote:
> On Wed, 2014-04-09 at 15:19 +0300, Kirill A. Shutemov wrote:
> > On Sun, Apr 06, 2014 at 01:12:14AM -0400, Michael L. Semon wrote:
> > > Hi! Starting early in this merge window for 3.15, lockdep has been
> > > giving me trouble. Normally, a splat will
On Wed, 9 Apr 2014, Jason Low wrote:
On Wed, 2014-04-09 at 15:19 +0300, Kirill A. Shutemov wrote:
On Sun, Apr 06, 2014 at 01:12:14AM -0400, Michael L. Semon wrote:
Hi! Starting early in this merge window for 3.15, lockdep has been
giving me trouble. Normally, a splat will happen,
On Thu, 10 Apr 2014 16:15:59 +0200, Peter Zijlstra said:
On Thu, Apr 10, 2014 at 11:18:24AM +0200, Peter Zijlstra wrote:
So I managed to reproduce, and the below makes it go away. I just don't
understand why though. will stare more.
/me kicks himself.. bloody obvious fail there :-)
Not
Peter Zijlstra pet...@infradead.org wrote:
Al, David, any bright ideas on how to best fix this?
Have the seq_xxx() code throw an error if current-in_execve is true. I can't
think of any circumstance where execve() should be reading anything that uses
seq_xxx().
David
--
To unsubscribe from
On Fri, Apr 11, 2014 at 03:50:27PM +0100, David Howells wrote:
Peter Zijlstra pet...@infradead.org wrote:
Al, David, any bright ideas on how to best fix this?
Have the seq_xxx() code throw an error if current-in_execve is true. I can't
think of any circumstance where execve() should be
On Thu, Apr 10, 2014 at 07:26:52PM -0400, Dave Jones wrote:
> On Thu, Apr 10, 2014 at 10:14:44AM -0700, Jason Low wrote:
> > On Thu, 2014-04-10 at 11:18 +0200, Peter Zijlstra wrote:
> > > On Wed, Apr 09, 2014 at 10:42:59PM -0700, Jason Low wrote:
> > > > As a starting point, would either of you
On Thu, Apr 10, 2014 at 07:26:52PM -0400, Dave Jones wrote:
> On Thu, Apr 10, 2014 at 10:14:44AM -0700, Jason Low wrote:
> > On Thu, 2014-04-10 at 11:18 +0200, Peter Zijlstra wrote:
> > > On Wed, Apr 09, 2014 at 10:42:59PM -0700, Jason Low wrote:
> > > > As a starting point, would either of
On Thu, Apr 10, 2014 at 10:14:44AM -0700, Jason Low wrote:
> On Thu, 2014-04-10 at 11:18 +0200, Peter Zijlstra wrote:
> > On Wed, Apr 09, 2014 at 10:42:59PM -0700, Jason Low wrote:
> > > As a starting point, would either of you like to test the following
> > > patch to see if it fixes the
On Thu, 2014-04-10 at 19:28 +0200, Peter Zijlstra wrote:
> On Thu, Apr 10, 2014 at 10:14:44AM -0700, Jason Low wrote:
> > So one thing I noticed that is different in the current code is that in
> > debug_mutex_unlock(), there is is a possibility that it does not unlock
> > the mutex (when
On Wed, Apr 09, 2014 at 03:19:40PM +0300, Kirill A. Shutemov wrote:
> [ 26.747484] ==
> [ 26.748725] [ INFO: possible circular locking dependency detected ]
> [ 26.748725] 3.13.0-11331-g6f008e72cd11 #1162 Not tainted
> [ 26.748725]
On Thu, Apr 10, 2014 at 12:15:44PM +0300, Kirill A. Shutemov wrote:
> I'm not able to trigger the lockdep report with the patch applied so far.
So what I've found it that the lockdep reports are valid; the only
difference is a lockup after the report or not.
So linus.git will hang after a
On Thu, Apr 10, 2014 at 11:18:24AM +0200, Peter Zijlstra wrote:
> So I managed to reproduce, and the below makes it go away. I just don't
> understand why though. will stare more.
/me kicks himself.. bloody obvious fail there :-)
Not unlocking the lock after a lockdep trigger will make things
On Thu, Apr 10, 2014 at 10:14:44AM -0700, Jason Low wrote:
> So one thing I noticed that is different in the current code is that in
> debug_mutex_unlock(), there is is a possibility that it does not unlock
> the mutex (when !debug_locks). May be interesting to try out this
> patch too:
Yeah;
On Thu, 2014-04-10 at 11:18 +0200, Peter Zijlstra wrote:
> On Wed, Apr 09, 2014 at 10:42:59PM -0700, Jason Low wrote:
> > As a starting point, would either of you like to test the following
> > patch to see if it fixes the issue? This patch essentially generates the
> > same code as in older
On Wed, Apr 09, 2014 at 10:42:59PM -0700, Jason Low wrote:
> As a starting point, would either of you like to test the following
> patch to see if it fixes the issue? This patch essentially generates the
> same code as in older kernels in the debug case. This applies on top of
> kernels with both
On Wed, Apr 09, 2014 at 10:42:59PM -0700, Jason Low wrote:
> On Wed, 2014-04-09 at 15:19 +0300, Kirill A. Shutemov wrote:
> > On Sun, Apr 06, 2014 at 01:12:14AM -0400, Michael L. Semon wrote:
> > > Hi! Starting early in this merge window for 3.15, lockdep has been
> > > giving me trouble.
On Wed, Apr 09, 2014 at 10:42:59PM -0700, Jason Low wrote:
> +#if defined(CONFIG_DEBUG_MUTEXES) || defined(CONFIG_DEBUG_LOCK_ALLOC)
DEBUG_LOCK_ALLOC always implies DEBUG_MUTEXES, see lib/Kconfig.debug
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a
On Wed, Apr 09, 2014 at 03:19:40PM +0300, Kirill A. Shutemov wrote:
> On Sun, Apr 06, 2014 at 01:12:14AM -0400, Michael L. Semon wrote:
> > Hi! Starting early in this merge window for 3.15, lockdep has been
> > giving me trouble. Normally, a splat will happen, lockdep will shut
> > itself off,
On Wed, Apr 09, 2014 at 03:19:40PM +0300, Kirill A. Shutemov wrote:
> I have troble with the commit as well:
How so? As far as I can tell the below is a genuine bug and not related
to the mutex debug thing.
> [ 26.745741]
> [ 26.747484] ==
On Wed, Apr 09, 2014 at 03:19:40PM +0300, Kirill A. Shutemov wrote:
I have troble with the commit as well:
How so? As far as I can tell the below is a genuine bug and not related
to the mutex debug thing.
[ 26.745741]
[ 26.747484] ==
[
On Wed, Apr 09, 2014 at 03:19:40PM +0300, Kirill A. Shutemov wrote:
On Sun, Apr 06, 2014 at 01:12:14AM -0400, Michael L. Semon wrote:
Hi! Starting early in this merge window for 3.15, lockdep has been
giving me trouble. Normally, a splat will happen, lockdep will shut
itself off, and my
On Wed, Apr 09, 2014 at 10:42:59PM -0700, Jason Low wrote:
+#if defined(CONFIG_DEBUG_MUTEXES) || defined(CONFIG_DEBUG_LOCK_ALLOC)
DEBUG_LOCK_ALLOC always implies DEBUG_MUTEXES, see lib/Kconfig.debug
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message
On Wed, Apr 09, 2014 at 10:42:59PM -0700, Jason Low wrote:
On Wed, 2014-04-09 at 15:19 +0300, Kirill A. Shutemov wrote:
On Sun, Apr 06, 2014 at 01:12:14AM -0400, Michael L. Semon wrote:
Hi! Starting early in this merge window for 3.15, lockdep has been
giving me trouble. Normally, a
On Wed, Apr 09, 2014 at 10:42:59PM -0700, Jason Low wrote:
As a starting point, would either of you like to test the following
patch to see if it fixes the issue? This patch essentially generates the
same code as in older kernels in the debug case. This applies on top of
kernels with both
On Thu, 2014-04-10 at 11:18 +0200, Peter Zijlstra wrote:
On Wed, Apr 09, 2014 at 10:42:59PM -0700, Jason Low wrote:
As a starting point, would either of you like to test the following
patch to see if it fixes the issue? This patch essentially generates the
same code as in older kernels in
On Thu, Apr 10, 2014 at 10:14:44AM -0700, Jason Low wrote:
So one thing I noticed that is different in the current code is that in
debug_mutex_unlock(), there is is a possibility that it does not unlock
the mutex (when !debug_locks). May be interesting to try out this
patch too:
Yeah; look at
On Thu, Apr 10, 2014 at 11:18:24AM +0200, Peter Zijlstra wrote:
So I managed to reproduce, and the below makes it go away. I just don't
understand why though. will stare more.
/me kicks himself.. bloody obvious fail there :-)
Not unlocking the lock after a lockdep trigger will make things get
On Thu, Apr 10, 2014 at 12:15:44PM +0300, Kirill A. Shutemov wrote:
I'm not able to trigger the lockdep report with the patch applied so far.
So what I've found it that the lockdep reports are valid; the only
difference is a lockup after the report or not.
So linus.git will hang after a lockdep
On Wed, Apr 09, 2014 at 03:19:40PM +0300, Kirill A. Shutemov wrote:
[ 26.747484] ==
[ 26.748725] [ INFO: possible circular locking dependency detected ]
[ 26.748725] 3.13.0-11331-g6f008e72cd11 #1162 Not tainted
[ 26.748725]
On Thu, 2014-04-10 at 19:28 +0200, Peter Zijlstra wrote:
On Thu, Apr 10, 2014 at 10:14:44AM -0700, Jason Low wrote:
So one thing I noticed that is different in the current code is that in
debug_mutex_unlock(), there is is a possibility that it does not unlock
the mutex (when !debug_locks).
On Thu, Apr 10, 2014 at 10:14:44AM -0700, Jason Low wrote:
On Thu, 2014-04-10 at 11:18 +0200, Peter Zijlstra wrote:
On Wed, Apr 09, 2014 at 10:42:59PM -0700, Jason Low wrote:
As a starting point, would either of you like to test the following
patch to see if it fixes the issue? This
On Thu, Apr 10, 2014 at 07:26:52PM -0400, Dave Jones wrote:
On Thu, Apr 10, 2014 at 10:14:44AM -0700, Jason Low wrote:
On Thu, 2014-04-10 at 11:18 +0200, Peter Zijlstra wrote:
On Wed, Apr 09, 2014 at 10:42:59PM -0700, Jason Low wrote:
As a starting point, would either of you like
On Thu, Apr 10, 2014 at 07:26:52PM -0400, Dave Jones wrote:
On Thu, Apr 10, 2014 at 10:14:44AM -0700, Jason Low wrote:
On Thu, 2014-04-10 at 11:18 +0200, Peter Zijlstra wrote:
On Wed, Apr 09, 2014 at 10:42:59PM -0700, Jason Low wrote:
As a starting point, would either of you like to
On Wed, 2014-04-09 at 15:19 +0300, Kirill A. Shutemov wrote:
> On Sun, Apr 06, 2014 at 01:12:14AM -0400, Michael L. Semon wrote:
> > Hi! Starting early in this merge window for 3.15, lockdep has been
> > giving me trouble. Normally, a splat will happen, lockdep will shut
> > itself off, and my
On Wed, 2014-04-09 at 15:19 +0300, Kirill A. Shutemov wrote:
On Sun, Apr 06, 2014 at 01:12:14AM -0400, Michael L. Semon wrote:
Hi! Starting early in this merge window for 3.15, lockdep has been
giving me trouble. Normally, a splat will happen, lockdep will shut
itself off, and my i686
Hi! Starting early in this merge window for 3.15, lockdep has been
giving me trouble. Normally, a splat will happen, lockdep will shut
itself off, and my i686 Pentium 4 PC will continue. Now, after the
splat, it will allow one key of input at either a VGA console or over
serial. After that,
Hi! Starting early in this merge window for 3.15, lockdep has been
giving me trouble. Normally, a splat will happen, lockdep will shut
itself off, and my i686 Pentium 4 PC will continue. Now, after the
splat, it will allow one key of input at either a VGA console or over
serial. After that,
46 matches
Mail list logo
