On Tue, Jul 17, 2018 at 05:04:39PM +0200, Peter Zijlstra wrote:
> On Tue, Jul 17, 2018 at 04:24:37PM +0200, Christoph Hellwig wrote:
> > On Thu, Jul 12, 2018 at 12:17:53PM -0700, Davidlohr Bueso wrote:
> > > On Thu, 14 Dec 2017, Christoph Hellwig wrote:
> > >
> > >> Hi all,
> > >>
> > >> this serie
On Tue, Jul 17, 2018 at 04:24:37PM +0200, Christoph Hellwig wrote:
> On Thu, Jul 12, 2018 at 12:17:53PM -0700, Davidlohr Bueso wrote:
> > On Thu, 14 Dec 2017, Christoph Hellwig wrote:
> >
> >> Hi all,
> >>
> >> this series adds a strategic lockdep_assert_held to __wake_up_common
> >> to ensure call
On Thu, Jul 12, 2018 at 12:17:53PM -0700, Davidlohr Bueso wrote:
> On Thu, 14 Dec 2017, Christoph Hellwig wrote:
>
>> Hi all,
>>
>> this series adds a strategic lockdep_assert_held to __wake_up_common
>> to ensure callers really do hold the wait_queue_head lock when calling
>> the unlocked wake_up
On Thu, 14 Dec 2017, Christoph Hellwig wrote:
Hi all,
this series adds a strategic lockdep_assert_held to __wake_up_common
to ensure callers really do hold the wait_queue_head lock when calling
the unlocked wake_up variants. It turns out epoll did not do this
for a fairly common path (hit all
On Tue, Dec 05, 2017 at 10:24:34AM -0500, Jason Baron wrote:
> On 12/01/2017 06:03 PM, Christoph Hellwig wrote:
> > On Fri, Dec 01, 2017 at 05:34:50PM -0500, Jason Baron wrote:
> >> hmmm...I'm not sure how this suggestion would change the locking rules
> >> from what we currently have. Right now, w
On Tue, 05 Dec 2017, Jason Baron wrote:
On 12/01/2017 06:03 PM, Christoph Hellwig wrote:
True. The patch below survives the amazing complex booting and starting
systemd with lockdep enabled test. Do we have something resembling a
epoll test suite?
I don't think we have any in the kernel
On 12/01/2017 06:03 PM, Christoph Hellwig wrote:
> On Fri, Dec 01, 2017 at 05:34:50PM -0500, Jason Baron wrote:
>> hmmm...I'm not sure how this suggestion would change the locking rules
>> from what we currently have. Right now, we use ep->lock, if we remove
>> that and use ep->wq->lock instead, th
On Fri, Dec 01, 2017 at 05:34:50PM -0500, Jason Baron wrote:
> hmmm...I'm not sure how this suggestion would change the locking rules
> from what we currently have. Right now, we use ep->lock, if we remove
> that and use ep->wq->lock instead, there is just a 1-to-1 mapping there
> that has not chan
On 12/01/2017 05:02 PM, Christoph Hellwig wrote:
> On Fri, Dec 01, 2017 at 02:00:33PM -0500, Jason Baron wrote:
>> You could leave the annotation and do something like:
>> s/ep->lock/ep->wq->lock. And then that would remove the ep->lock saving
>> a bit of space.
>
> Looks like this isn't going to
On Fri, Dec 01, 2017 at 02:00:33PM -0500, Jason Baron wrote:
> You could leave the annotation and do something like:
> s/ep->lock/ep->wq->lock. And then that would remove the ep->lock saving
> a bit of space.
Looks like this isn't going to work due to ep_poll_safewake taking
another waitqueue lock
On 12/01/2017 12:11 PM, Christoph Hellwig wrote:
> On Thu, Nov 30, 2017 at 05:18:07PM -0500, Jason Baron wrote:
>> Yes, but for those cases it uses the ep->poll_wait waitqueue not the
>> ep->wq, which is guarded by the ep->wq->lock.
>
> True. So it looks like we have one waitqueue in the system
On Thu, Nov 30, 2017 at 05:18:07PM -0500, Jason Baron wrote:
> Yes, but for those cases it uses the ep->poll_wait waitqueue not the
> ep->wq, which is guarded by the ep->wq->lock.
True. So it looks like we have one waitqueue in the system that is
special in providing its own synchronization for w
On 11/30/2017 05:11 PM, Christoph Hellwig wrote:
> On Thu, Nov 30, 2017 at 04:38:02PM -0500, Jason Baron wrote:
>> I don't think there is a bug here. The 'wake_up_locked()' calls in epoll
>> are being protected by the ep->lock, not the wait_queue_head lock. So
>> arguably the 'annotation' is wron
On Thu, Nov 30, 2017 at 04:38:02PM -0500, Jason Baron wrote:
> I don't think there is a bug here. The 'wake_up_locked()' calls in epoll
> are being protected by the ep->lock, not the wait_queue_head lock. So
> arguably the 'annotation' is wrong, but I don't think there is a bug
> beyond that.
They
On 11/30/2017 03:50 PM, Andrew Morton wrote:
> On Thu, 30 Nov 2017 06:20:35 -0800 Christoph Hellwig wrote:
>
>> Hi all,
>>
>> this series adds a strategic lockdep_assert_held to __wake_up_common
>> to ensure callers really do hold the wait_queue_head lock when calling
>> the unlocked wake_up va
On Thu, 30 Nov 2017 06:20:35 -0800 Christoph Hellwig wrote:
> Hi all,
>
> this series adds a strategic lockdep_assert_held to __wake_up_common
> to ensure callers really do hold the wait_queue_head lock when calling
> the unlocked wake_up variants. It turns out epoll did not do this
> for a fai
16 matches
Mail list logo
