> On Thu, 27 Nov 2014, David Hildenbrand wrote:
> > > OTOH, there is no reason why we need to disable preemption over that
> > > page_fault_disabled() region. There are code pathes which really do
> > > not require to disable preemption for that.
> > >
> > > We have that seperated in preempt-rt
On Thu, 27 Nov 2014, David Hildenbrand wrote:
> > OTOH, there is no reason why we need to disable preemption over that
> > page_fault_disabled() region. There are code pathes which really do
> > not require to disable preemption for that.
> >
> > We have that seperated in preempt-rt for obvious
Simple prototype to enable might_sleep() checks in might_fault(), avoiding false
positives for scenarios involving explicit pagefault_disable().
So this should work:
spin_lock(); /* also if left away */
pagefault_disable()
rc = copy_to_user(...)
pagefault_enable();
> From: David Hildenbrand [mailto:d...@linux.vnet.ibm.com]
> > > From: David Hildenbrand
> > > ...
> > > > Although it might not be optimal, but keeping a separate counter for
> > > > pagefault_disable() as part of the preemption counter seems to be the
> > > > only
> > > > doable thing right
From: David Hildenbrand [mailto:d...@linux.vnet.ibm.com]
> > From: David Hildenbrand
> > ...
> > > Although it might not be optimal, but keeping a separate counter for
> > > pagefault_disable() as part of the preemption counter seems to be the only
> > > doable thing right now. I am not sure if a
> From: David Hildenbrand
> ...
> > Although it might not be optimal, but keeping a separate counter for
> > pagefault_disable() as part of the preemption counter seems to be the only
> > doable thing right now. I am not sure if a completely separated counter is
> > even
> > possible, increasing
From: David Hildenbrand
...
> Although it might not be optimal, but keeping a separate counter for
> pagefault_disable() as part of the preemption counter seems to be the only
> doable thing right now. I am not sure if a completely separated counter is
> even
> possible, increasing the size of
> OTOH, there is no reason why we need to disable preemption over that
> page_fault_disabled() region. There are code pathes which really do
> not require to disable preemption for that.
>
> We have that seperated in preempt-rt for obvious reasons and IIRC
> Peter Zijlstra tried to distangle it
On Thu, 27 Nov 2014, Heiko Carstens wrote:
> On Thu, Nov 27, 2014 at 09:03:01AM +0100, David Hildenbrand wrote:
> > > Code like
> > > spin_lock();
> > > if (copy_to_user(...))
> > > rc = ...
> > > spin_unlock();
> > > really *should* generate warnings like it did before.
> > >
> >
> On Thu, Nov 27, 2014 at 09:03:01AM +0100, David Hildenbrand wrote:
> > > Code like
> > > spin_lock();
> > > if (copy_to_user(...))
> > > rc = ...
> > > spin_unlock();
> > > really *should* generate warnings like it did before.
> > >
> > > And *only* code like
> > >
On Thu, Nov 27, 2014 at 09:03:01AM +0100, David Hildenbrand wrote:
> > Code like
> > spin_lock();
> > if (copy_to_user(...))
> > rc = ...
> > spin_unlock();
> > really *should* generate warnings like it did before.
> >
> > And *only* code like
> > spin_lock();
>
> Is
> Code like
> spin_lock();
> if (copy_to_user(...))
> rc = ...
> spin_unlock();
> really *should* generate warnings like it did before.
>
> And *only* code like
> spin_lock();
Is only code like this valid or also with the spin_lock() dropped?
(e.g. the
Code like
spin_lock(lock);
if (copy_to_user(...))
rc = ...
spin_unlock(lock);
really *should* generate warnings like it did before.
And *only* code like
spin_lock(lock);
Is only code like this valid or also with the spin_lock() dropped?
(e.g. the
On Thu, Nov 27, 2014 at 09:03:01AM +0100, David Hildenbrand wrote:
Code like
spin_lock(lock);
if (copy_to_user(...))
rc = ...
spin_unlock(lock);
really *should* generate warnings like it did before.
And *only* code like
spin_lock(lock);
Is only
On Thu, Nov 27, 2014 at 09:03:01AM +0100, David Hildenbrand wrote:
Code like
spin_lock(lock);
if (copy_to_user(...))
rc = ...
spin_unlock(lock);
really *should* generate warnings like it did before.
And *only* code like
spin_lock(lock);
Is only
On Thu, 27 Nov 2014, Heiko Carstens wrote:
On Thu, Nov 27, 2014 at 09:03:01AM +0100, David Hildenbrand wrote:
Code like
spin_lock(lock);
if (copy_to_user(...))
rc = ...
spin_unlock(lock);
really *should* generate warnings like it did before.
And *only*
OTOH, there is no reason why we need to disable preemption over that
page_fault_disabled() region. There are code pathes which really do
not require to disable preemption for that.
We have that seperated in preempt-rt for obvious reasons and IIRC
Peter Zijlstra tried to distangle it in
From: David Hildenbrand
...
Although it might not be optimal, but keeping a separate counter for
pagefault_disable() as part of the preemption counter seems to be the only
doable thing right now. I am not sure if a completely separated counter is
even
possible, increasing the size of
From: David Hildenbrand
...
Although it might not be optimal, but keeping a separate counter for
pagefault_disable() as part of the preemption counter seems to be the only
doable thing right now. I am not sure if a completely separated counter is
even
possible, increasing the size of
From: David Hildenbrand [mailto:d...@linux.vnet.ibm.com]
From: David Hildenbrand
...
Although it might not be optimal, but keeping a separate counter for
pagefault_disable() as part of the preemption counter seems to be the only
doable thing right now. I am not sure if a completely
From: David Hildenbrand [mailto:d...@linux.vnet.ibm.com]
From: David Hildenbrand
...
Although it might not be optimal, but keeping a separate counter for
pagefault_disable() as part of the preemption counter seems to be the
only
doable thing right now. I am not sure if a
Simple prototype to enable might_sleep() checks in might_fault(), avoiding false
positives for scenarios involving explicit pagefault_disable().
So this should work:
spin_lock(lock); /* also if left away */
pagefault_disable()
rc = copy_to_user(...)
On Thu, 27 Nov 2014, David Hildenbrand wrote:
OTOH, there is no reason why we need to disable preemption over that
page_fault_disabled() region. There are code pathes which really do
not require to disable preemption for that.
We have that seperated in preempt-rt for obvious reasons and
On Thu, 27 Nov 2014, David Hildenbrand wrote:
OTOH, there is no reason why we need to disable preemption over that
page_fault_disabled() region. There are code pathes which really do
not require to disable preemption for that.
We have that seperated in preempt-rt for obvious
On Thu, Nov 27, 2014 at 08:09:19AM +0100, Heiko Carstens wrote:
> On Wed, Nov 26, 2014 at 07:04:47PM +0200, Michael S. Tsirkin wrote:
> > On Wed, Nov 26, 2014 at 05:51:08PM +0100, Christian Borntraeger wrote:
> > > > But this one was > giving users in field false positives.
> > >
> > > So lets
On Wed, Nov 26, 2014 at 07:04:47PM +0200, Michael S. Tsirkin wrote:
> On Wed, Nov 26, 2014 at 05:51:08PM +0100, Christian Borntraeger wrote:
> > > But this one was > giving users in field false positives.
> >
> > So lets try to fix those, ok? If we cant, then tough luck.
>
> Sure.
> I think the
On Wed, Nov 26, 2014 at 07:04:47PM +0200, Michael S. Tsirkin wrote:
> On Wed, Nov 26, 2014 at 05:51:08PM +0100, Christian Borntraeger wrote:
> > > But this one was > giving users in field false positives.
> >
> > So lets try to fix those, ok? If we cant, then tough luck.
>
> Sure.
> I think the
On Wed, Nov 26, 2014 at 05:51:08PM +0100, Christian Borntraeger wrote:
> > But this one was > giving users in field false positives.
>
> So lets try to fix those, ok? If we cant, then tough luck.
Sure.
I think the simplest way might be to make spinlock disable
premption when
Am 26.11.2014 um 17:32 schrieb Michael S. Tsirkin:
[...]
This is what happened on our side (very recent kernel):
spin_lock()
copy_to_user(...)
spin_unlock()
>>>
>>> That's a deadlock even without copy_to_user - it's
>>> enough for the thread to be preempted and another one
On Wed, Nov 26, 2014 at 05:30:35PM +0100, Christian Borntraeger wrote:
> Am 26.11.2014 um 17:19 schrieb Michael S. Tsirkin:
> > On Wed, Nov 26, 2014 at 05:02:23PM +0100, David Hildenbrand wrote:
> This is what happened on our side (very recent kernel):
>
> spin_lock()
>
On Wed, Nov 26, 2014 at 05:07:13PM +0100, Christian Borntraeger wrote:
> Am 26.11.2014 um 16:47 schrieb Michael S. Tsirkin:
> > On Wed, Nov 26, 2014 at 04:32:07PM +0100, David Hildenbrand wrote:
> >>> On Wed, Nov 26, 2014 at 05:17:29PM +0200, Michael S. Tsirkin wrote:
> On Wed, Nov 26, 2014
Am 26.11.2014 um 17:19 schrieb Michael S. Tsirkin:
> On Wed, Nov 26, 2014 at 05:02:23PM +0100, David Hildenbrand wrote:
This is what happened on our side (very recent kernel):
spin_lock()
copy_to_user(...)
spin_unlock()
>>>
>>> That's a deadlock even without copy_to_user -
On Wed, Nov 26, 2014 at 05:02:23PM +0100, David Hildenbrand wrote:
> > > This is what happened on our side (very recent kernel):
> > >
> > > spin_lock()
> > > copy_to_user(...)
> > > spin_unlock()
> >
> > That's a deadlock even without copy_to_user - it's
> > enough for the thread to be
Am 26.11.2014 um 16:47 schrieb Michael S. Tsirkin:
> On Wed, Nov 26, 2014 at 04:32:07PM +0100, David Hildenbrand wrote:
>>> On Wed, Nov 26, 2014 at 05:17:29PM +0200, Michael S. Tsirkin wrote:
On Wed, Nov 26, 2014 at 11:05:04AM +0100, David Hildenbrand wrote:
>> What's the path you are
> > This is what happened on our side (very recent kernel):
> >
> > spin_lock()
> > copy_to_user(...)
> > spin_unlock()
>
> That's a deadlock even without copy_to_user - it's
> enough for the thread to be preempted and another one
> to try taking the lock.
>
>
> > 1. s390 locks/unlocks a spin
Am 26.11.2014 um 16:37 schrieb Michael S. Tsirkin:
> On Wed, Nov 26, 2014 at 04:30:32PM +0100, Christian Borntraeger wrote:
>> Am 26.11.2014 um 16:17 schrieb Michael S. Tsirkin:
>>> On Wed, Nov 26, 2014 at 11:05:04AM +0100, David Hildenbrand wrote:
> What's the path you are trying to debug?
On Wed, Nov 26, 2014 at 04:32:07PM +0100, David Hildenbrand wrote:
> > On Wed, Nov 26, 2014 at 05:17:29PM +0200, Michael S. Tsirkin wrote:
> > > On Wed, Nov 26, 2014 at 11:05:04AM +0100, David Hildenbrand wrote:
> > > > > What's the path you are trying to debug?
> > > >
> > > > Well, we had a
On Wed, Nov 26, 2014 at 04:30:32PM +0100, Christian Borntraeger wrote:
> Am 26.11.2014 um 16:17 schrieb Michael S. Tsirkin:
> > On Wed, Nov 26, 2014 at 11:05:04AM +0100, David Hildenbrand wrote:
> >>> What's the path you are trying to debug?
> >>
> >> Well, we had a problem where we held a
> On Wed, Nov 26, 2014 at 05:17:29PM +0200, Michael S. Tsirkin wrote:
> > On Wed, Nov 26, 2014 at 11:05:04AM +0100, David Hildenbrand wrote:
> > > > What's the path you are trying to debug?
> > >
> > > Well, we had a problem where we held a spin_lock and called
> > > copy_(from|to)_user(). We
Am 26.11.2014 um 16:17 schrieb Michael S. Tsirkin:
> On Wed, Nov 26, 2014 at 11:05:04AM +0100, David Hildenbrand wrote:
>>> What's the path you are trying to debug?
>>
>> Well, we had a problem where we held a spin_lock and called
>> copy_(from|to)_user(). We experienced very random deadlocks that
On Wed, Nov 26, 2014 at 05:17:29PM +0200, Michael S. Tsirkin wrote:
> On Wed, Nov 26, 2014 at 11:05:04AM +0100, David Hildenbrand wrote:
> > > What's the path you are trying to debug?
> >
> > Well, we had a problem where we held a spin_lock and called
> > copy_(from|to)_user(). We experienced
Hmm you sent same mail to me off-list, and I replied there.
Now there's a copy on list - I'm just going to assume
it's exactly identical, pasting my response here as well.
If there are more questions I missed, let me know.
On Wed, Nov 26, 2014 at 09:23:31AM +0100, David Hildenbrand wrote:
> Sorry
On Wed, Nov 26, 2014 at 11:05:04AM +0100, David Hildenbrand wrote:
> > What's the path you are trying to debug?
>
> Well, we had a problem where we held a spin_lock and called
> copy_(from|to)_user(). We experienced very random deadlocks that took some guy
> almost a week to debug. The simple
Hi Michael,
thanks for your reply! some general thought:
This change was introduced mid 2013 but we don't have a single user relying
on this code change yet, right?
Disabling might_sleep() for functions that clearly state that they may sleep to
get some special case running feels wrong to me.
Hi Michael,
thanks for your reply! some general thought:
This change was introduced mid 2013 but we don't have a single user relying
on this code change yet, right?
Disabling might_sleep() for functions that clearly state that they may sleep to
get some special case running feels wrong to me.
On Wed, Nov 26, 2014 at 11:05:04AM +0100, David Hildenbrand wrote:
What's the path you are trying to debug?
Well, we had a problem where we held a spin_lock and called
copy_(from|to)_user(). We experienced very random deadlocks that took some guy
almost a week to debug. The simple
Hmm you sent same mail to me off-list, and I replied there.
Now there's a copy on list - I'm just going to assume
it's exactly identical, pasting my response here as well.
If there are more questions I missed, let me know.
On Wed, Nov 26, 2014 at 09:23:31AM +0100, David Hildenbrand wrote:
Sorry
On Wed, Nov 26, 2014 at 05:17:29PM +0200, Michael S. Tsirkin wrote:
On Wed, Nov 26, 2014 at 11:05:04AM +0100, David Hildenbrand wrote:
What's the path you are trying to debug?
Well, we had a problem where we held a spin_lock and called
copy_(from|to)_user(). We experienced very random
Am 26.11.2014 um 16:17 schrieb Michael S. Tsirkin:
On Wed, Nov 26, 2014 at 11:05:04AM +0100, David Hildenbrand wrote:
What's the path you are trying to debug?
Well, we had a problem where we held a spin_lock and called
copy_(from|to)_user(). We experienced very random deadlocks that took some
On Wed, Nov 26, 2014 at 05:17:29PM +0200, Michael S. Tsirkin wrote:
On Wed, Nov 26, 2014 at 11:05:04AM +0100, David Hildenbrand wrote:
What's the path you are trying to debug?
Well, we had a problem where we held a spin_lock and called
copy_(from|to)_user(). We experienced very
On Wed, Nov 26, 2014 at 04:30:32PM +0100, Christian Borntraeger wrote:
Am 26.11.2014 um 16:17 schrieb Michael S. Tsirkin:
On Wed, Nov 26, 2014 at 11:05:04AM +0100, David Hildenbrand wrote:
What's the path you are trying to debug?
Well, we had a problem where we held a spin_lock and called
On Wed, Nov 26, 2014 at 04:32:07PM +0100, David Hildenbrand wrote:
On Wed, Nov 26, 2014 at 05:17:29PM +0200, Michael S. Tsirkin wrote:
On Wed, Nov 26, 2014 at 11:05:04AM +0100, David Hildenbrand wrote:
What's the path you are trying to debug?
Well, we had a problem where we held
Am 26.11.2014 um 16:37 schrieb Michael S. Tsirkin:
On Wed, Nov 26, 2014 at 04:30:32PM +0100, Christian Borntraeger wrote:
Am 26.11.2014 um 16:17 schrieb Michael S. Tsirkin:
On Wed, Nov 26, 2014 at 11:05:04AM +0100, David Hildenbrand wrote:
What's the path you are trying to debug?
Well, we
This is what happened on our side (very recent kernel):
spin_lock(lock)
copy_to_user(...)
spin_unlock(lock)
That's a deadlock even without copy_to_user - it's
enough for the thread to be preempted and another one
to try taking the lock.
1. s390 locks/unlocks a spin lock with
Am 26.11.2014 um 16:47 schrieb Michael S. Tsirkin:
On Wed, Nov 26, 2014 at 04:32:07PM +0100, David Hildenbrand wrote:
On Wed, Nov 26, 2014 at 05:17:29PM +0200, Michael S. Tsirkin wrote:
On Wed, Nov 26, 2014 at 11:05:04AM +0100, David Hildenbrand wrote:
What's the path you are trying to debug?
On Wed, Nov 26, 2014 at 05:02:23PM +0100, David Hildenbrand wrote:
This is what happened on our side (very recent kernel):
spin_lock(lock)
copy_to_user(...)
spin_unlock(lock)
That's a deadlock even without copy_to_user - it's
enough for the thread to be preempted and another
Am 26.11.2014 um 17:19 schrieb Michael S. Tsirkin:
On Wed, Nov 26, 2014 at 05:02:23PM +0100, David Hildenbrand wrote:
This is what happened on our side (very recent kernel):
spin_lock(lock)
copy_to_user(...)
spin_unlock(lock)
That's a deadlock even without copy_to_user - it's
enough for
On Wed, Nov 26, 2014 at 05:07:13PM +0100, Christian Borntraeger wrote:
Am 26.11.2014 um 16:47 schrieb Michael S. Tsirkin:
On Wed, Nov 26, 2014 at 04:32:07PM +0100, David Hildenbrand wrote:
On Wed, Nov 26, 2014 at 05:17:29PM +0200, Michael S. Tsirkin wrote:
On Wed, Nov 26, 2014 at 11:05:04AM
On Wed, Nov 26, 2014 at 05:30:35PM +0100, Christian Borntraeger wrote:
Am 26.11.2014 um 17:19 schrieb Michael S. Tsirkin:
On Wed, Nov 26, 2014 at 05:02:23PM +0100, David Hildenbrand wrote:
This is what happened on our side (very recent kernel):
spin_lock(lock)
copy_to_user(...)
Am 26.11.2014 um 17:32 schrieb Michael S. Tsirkin:
[...]
This is what happened on our side (very recent kernel):
spin_lock(lock)
copy_to_user(...)
spin_unlock(lock)
That's a deadlock even without copy_to_user - it's
enough for the thread to be preempted and another one
to try taking the
On Wed, Nov 26, 2014 at 05:51:08PM +0100, Christian Borntraeger wrote:
But this one was giving users in field false positives.
So lets try to fix those, ok? If we cant, then tough luck.
Sure.
I think the simplest way might be to make spinlock disable
premption when CONFIG_DEBUG_ATOMIC_SLEEP
On Wed, Nov 26, 2014 at 07:04:47PM +0200, Michael S. Tsirkin wrote:
On Wed, Nov 26, 2014 at 05:51:08PM +0100, Christian Borntraeger wrote:
But this one was giving users in field false positives.
So lets try to fix those, ok? If we cant, then tough luck.
Sure.
I think the simplest way
On Wed, Nov 26, 2014 at 07:04:47PM +0200, Michael S. Tsirkin wrote:
On Wed, Nov 26, 2014 at 05:51:08PM +0100, Christian Borntraeger wrote:
But this one was giving users in field false positives.
So lets try to fix those, ok? If we cant, then tough luck.
Sure.
I think the simplest way
On Thu, Nov 27, 2014 at 08:09:19AM +0100, Heiko Carstens wrote:
On Wed, Nov 26, 2014 at 07:04:47PM +0200, Michael S. Tsirkin wrote:
On Wed, Nov 26, 2014 at 05:51:08PM +0100, Christian Borntraeger wrote:
But this one was giving users in field false positives.
So lets try to fix
On Tue, Nov 25, 2014 at 12:43:24PM +0100, David Hildenbrand wrote:
> I recently discovered that commit 662bbcb2747c2422cf98d3d97619509379eee466
> removed/skipped all might_sleep checks for might_fault() calls when in atomic.
Yes. You can add e.g. might_sleep in your code if, for some reason, it
I recently discovered that commit 662bbcb2747c2422cf98d3d97619509379eee466
removed/skipped all might_sleep checks for might_fault() calls when in atomic.
Reason was to allow calling copy_(to|from)_user while in pagefault_disabled(),
because otherwise, CONFIG_DEBUG_ATOMIC_SLEEP would find false
I recently discovered that commit 662bbcb2747c2422cf98d3d97619509379eee466
removed/skipped all might_sleep checks for might_fault() calls when in atomic.
Reason was to allow calling copy_(to|from)_user while in pagefault_disabled(),
because otherwise, CONFIG_DEBUG_ATOMIC_SLEEP would find false
On Tue, Nov 25, 2014 at 12:43:24PM +0100, David Hildenbrand wrote:
I recently discovered that commit 662bbcb2747c2422cf98d3d97619509379eee466
removed/skipped all might_sleep checks for might_fault() calls when in atomic.
Yes. You can add e.g. might_sleep in your code if, for some reason, it is
68 matches
Mail list logo
