On Tue, Jul 24, 2018 at 2:18 AM Peter Zijlstra wrote:
>
> On Mon, Jul 23, 2018 at 06:44:43PM -0700, Cong Wang wrote:
> > On Mon, Jul 23, 2018 at 6:35 PM Cong Wang wrote:
> > >
> > > Hi, Peter, Andi
> > >
> > > While reviewing the deadlock, I find out it looks like we could have the
> > >
On Tue, Jul 24, 2018 at 2:18 AM Peter Zijlstra wrote:
>
> On Mon, Jul 23, 2018 at 06:44:43PM -0700, Cong Wang wrote:
> > On Mon, Jul 23, 2018 at 6:35 PM Cong Wang wrote:
> > >
> > > Hi, Peter, Andi
> > >
> > > While reviewing the deadlock, I find out it looks like we could have the
> > >
On Mon, Jul 23, 2018 at 06:44:43PM -0700, Cong Wang wrote:
> On Mon, Jul 23, 2018 at 6:35 PM Cong Wang wrote:
> >
> > Hi, Peter, Andi
> >
> > While reviewing the deadlock, I find out it looks like we could have the
> > following infinite recursion too:
> >
> > perf_event_account_interrupt()
> >
On Mon, Jul 23, 2018 at 06:44:43PM -0700, Cong Wang wrote:
> On Mon, Jul 23, 2018 at 6:35 PM Cong Wang wrote:
> >
> > Hi, Peter, Andi
> >
> > While reviewing the deadlock, I find out it looks like we could have the
> > following infinite recursion too:
> >
> > perf_event_account_interrupt()
> >
On Mon, Jul 23, 2018 at 04:16:23PM -0700, Cong Wang wrote:
> > > +#define PERF_EF_NO_WAIT 0x08/* do not wait when
> > > stopping, for
> > > + * example, waiting for a timer
> > > + */
> >
> > That's a
On Mon, Jul 23, 2018 at 04:16:23PM -0700, Cong Wang wrote:
> > > +#define PERF_EF_NO_WAIT 0x08/* do not wait when
> > > stopping, for
> > > + * example, waiting for a timer
> > > + */
> >
> > That's a
On Mon, Jul 23, 2018 at 6:35 PM Cong Wang wrote:
>
> Hi, Peter, Andi
>
> While reviewing the deadlock, I find out it looks like we could have the
> following infinite recursion too:
>
> perf_event_account_interrupt()
> __perf_event_account_interrupt()
> perf_adjust_period()
> event->pmu->stop
>
On Mon, Jul 23, 2018 at 6:35 PM Cong Wang wrote:
>
> Hi, Peter, Andi
>
> While reviewing the deadlock, I find out it looks like we could have the
> following infinite recursion too:
>
> perf_event_account_interrupt()
> __perf_event_account_interrupt()
> perf_adjust_period()
> event->pmu->stop
>
Hi, Peter, Andi
While reviewing the deadlock, I find out it looks like we could have the
following infinite recursion too:
perf_event_account_interrupt()
__perf_event_account_interrupt()
perf_adjust_period()
event->pmu->stop
x86_pmu_stop()
x86_pmu.disable()
intel_pmu_disable_event()
Hi, Peter, Andi
While reviewing the deadlock, I find out it looks like we could have the
following infinite recursion too:
perf_event_account_interrupt()
__perf_event_account_interrupt()
perf_adjust_period()
event->pmu->stop
x86_pmu_stop()
x86_pmu.disable()
intel_pmu_disable_event()
On Fri, Jul 20, 2018 at 4:52 AM Peter Zijlstra wrote:
>
> On Thu, Jul 19, 2018 at 12:12:53PM -0700, Cong Wang wrote:
> > hrtimer_cancel() busy-waits for the hrtimer callback to stop,
> > pretty much like del_timer_sync(). This creates a possible deadlock
> > scenario where we hold a spinlock
On Fri, Jul 20, 2018 at 4:52 AM Peter Zijlstra wrote:
>
> On Thu, Jul 19, 2018 at 12:12:53PM -0700, Cong Wang wrote:
> > hrtimer_cancel() busy-waits for the hrtimer callback to stop,
> > pretty much like del_timer_sync(). This creates a possible deadlock
> > scenario where we hold a spinlock
On Thu, Jul 19, 2018 at 12:12:53PM -0700, Cong Wang wrote:
> hrtimer_cancel() busy-waits for the hrtimer callback to stop,
> pretty much like del_timer_sync(). This creates a possible deadlock
> scenario where we hold a spinlock before calling hrtimer_cancel()
> while in trying to acquire the same
On Thu, Jul 19, 2018 at 12:12:53PM -0700, Cong Wang wrote:
> hrtimer_cancel() busy-waits for the hrtimer callback to stop,
> pretty much like del_timer_sync(). This creates a possible deadlock
> scenario where we hold a spinlock before calling hrtimer_cancel()
> while in trying to acquire the same
hrtimer_cancel() busy-waits for the hrtimer callback to stop,
pretty much like del_timer_sync(). This creates a possible deadlock
scenario where we hold a spinlock before calling hrtimer_cancel()
while in trying to acquire the same spinlock in the callback.
This kind of deadlock is already known
hrtimer_cancel() busy-waits for the hrtimer callback to stop,
pretty much like del_timer_sync(). This creates a possible deadlock
scenario where we hold a spinlock before calling hrtimer_cancel()
while in trying to acquire the same spinlock in the callback.
This kind of deadlock is already known
16 matches
Mail list logo
