On Fri, 2019-02-08 at 11:43 +, Will Deacon wrote:
> I've also been trying to understand why it's necessary to check both of the
> pending_free entries, and I'm still struggling somewhat. It's true that the
> wakeup in get_pending_free_lock() could lead to both entries being used
> without the
On Fri, 2019-02-08 at 11:43 +, Will Deacon wrote:
> I've also been trying to understand why it's necessary to check both of the
> pending_free entries, and I'm still struggling somewhat. It's true that the
> wakeup in get_pending_free_lock() could lead to both entries being used
> without the
Hi Bart, Peter,
On Sun, Feb 03, 2019 at 09:36:38AM -0800, Bart Van Assche wrote:
> On 2/1/19 4:15 AM, Peter Zijlstra wrote:
> > On Fri, Jan 18, 2019 at 06:34:20PM -0800, Bart Van Assche wrote:
> > > I agree with what you wrote. The only code I know of that accesses list
> > > entries using RCU is
On 2/1/19 4:15 AM, Peter Zijlstra wrote:
On Fri, Jan 18, 2019 at 06:34:20PM -0800, Bart Van Assche wrote:
I agree with what you wrote. The only code I know of that accesses list
entries using RCU is the __bfs() function. In that function I found the
following loop:
On Fri, Jan 18, 2019 at 06:34:20PM -0800, Bart Van Assche wrote:
> I agree with what you wrote. The only code I know of that accesses list
> entries using RCU is the __bfs() function. In that function I found the
> following loop:
>
> list_for_each_entry_rcu(entry, head, entry) { [ ... ] }
On 1/18/19 1:48 AM, Peter Zijlstra wrote:
On Mon, Jan 14, 2019 at 08:52:33AM -0800, Bart Van Assche wrote:
On Mon, 2019-01-14 at 13:52 +0100, Peter Zijlstra wrote:
On Fri, Jan 11, 2019 at 09:01:41AM -0800, Bart Van Assche wrote:
The list_del_rcu() call must only happen once.
Yes; obviously.
On Mon, Jan 14, 2019 at 08:52:33AM -0800, Bart Van Assche wrote:
> On Mon, 2019-01-14 at 13:52 +0100, Peter Zijlstra wrote:
> > On Fri, Jan 11, 2019 at 09:01:41AM -0800, Bart Van Assche wrote:
> > > The list_del_rcu() call must only happen once.
> >
> > Yes; obviously. But if we need to check
On Mon, 2019-01-14 at 13:52 +0100, Peter Zijlstra wrote:
> On Fri, Jan 11, 2019 at 09:01:41AM -0800, Bart Van Assche wrote:
> > The list_del_rcu() call must only happen once.
>
> Yes; obviously. But if we need to check all @pf's, that means the entry
> is still reachable after a single
On Fri, Jan 11, 2019 at 09:01:41AM -0800, Bart Van Assche wrote:
> On Fri, 2019-01-11 at 17:55 +0100, Peter Zijlstra wrote:
> > On Fri, Jan 11, 2019 at 07:55:03AM -0800, Bart Van Assche wrote:
> > > On Fri, 2019-01-11 at 13:48 +0100, Peter Zijlstra wrote:
> > > > I spotted this new v6 in my inbox
On Fri, 2019-01-11 at 17:55 +0100, Peter Zijlstra wrote:
> On Fri, Jan 11, 2019 at 07:55:03AM -0800, Bart Van Assche wrote:
> > On Fri, 2019-01-11 at 13:48 +0100, Peter Zijlstra wrote:
> > > I spotted this new v6 in my inbox and have rebased to it.
> >
> > Thanks!
> >
> > > On Wed, Jan 09, 2019
On Fri, Jan 11, 2019 at 07:55:03AM -0800, Bart Van Assche wrote:
> On Fri, 2019-01-11 at 13:48 +0100, Peter Zijlstra wrote:
> > I spotted this new v6 in my inbox and have rebased to it.
>
> Thanks!
>
> > On Wed, Jan 09, 2019 at 01:01:48PM -0800, Bart Van Assche wrote:
> >
> > > The changes
On Fri, 2019-01-11 at 13:48 +0100, Peter Zijlstra wrote:
> I spotted this new v6 in my inbox and have rebased to it.
Thanks!
> On Wed, Jan 09, 2019 at 01:01:48PM -0800, Bart Van Assche wrote:
>
> > The changes compared to v5 are:
> > - Modified zap_class() such that it doesn't try to free a
Hi Bart,
I spotted this new v6 in my inbox and have rebased to it.
On Wed, Jan 09, 2019 at 01:01:48PM -0800, Bart Van Assche wrote:
> The changes compared to v5 are:
> - Modified zap_class() such that it doesn't try to free a list entry that
> is already being freed.
I however have a
Hi Peter and Ingo,
A known shortcoming of the current lockdep implementation is that it requires
lock keys to be allocated statically. This forces certain unrelated
synchronization objects to share keys and this key sharing can cause false
positive deadlock reports. This patch series adds support
14 matches
Mail list logo
