Hi
On 06/17/2016 04:59 PM, Daniel Bristot de Oliveira wrote:
> - using _irq and _irqsave appropriately, and
> - using raw_spin locks functions.
After some patches/tests on -rt, I figured that there is a -rt specific
patch that moves cgroup_free() calls to the non-atomic context (in the
-rt
Hi
On 06/17/2016 04:59 PM, Daniel Bristot de Oliveira wrote:
> - using _irq and _irqsave appropriately, and
> - using raw_spin locks functions.
After some patches/tests on -rt, I figured that there is a -rt specific
patch that moves cgroup_free() calls to the non-atomic context (in the
-rt
Hi Tejun,
On 06/17/2016 02:36 AM, Tejun Heo wrote:
> Please use _irq and _irqsave
> appropriately depending on the circumstances.
ack! I will do it!
Cooking a v3:
- using _irq and _irqsave appropriately, and
- using raw_spin locks functions.
Thanks! -- Daniel
Hi Tejun,
On 06/17/2016 02:36 AM, Tejun Heo wrote:
> Please use _irq and _irqsave
> appropriately depending on the circumstances.
ack! I will do it!
Cooking a v3:
- using _irq and _irqsave appropriately, and
- using raw_spin locks functions.
Thanks! -- Daniel
Hello,
On Thu, Jun 16, 2016 at 09:12:32PM -0300, Daniel Bristot de Oliveira wrote:
> The use of the irq spin_(un)lock_irq() assumes that the code is always
> called with IRQs enabled. But that is not always true in this case, as
> we call cgroup_free() in the hard IRQ context, and unconditionally
Hello,
On Thu, Jun 16, 2016 at 09:12:32PM -0300, Daniel Bristot de Oliveira wrote:
> The use of the irq spin_(un)lock_irq() assumes that the code is always
> called with IRQs enabled. But that is not always true in this case, as
> we call cgroup_free() in the hard IRQ context, and unconditionally
On 06/16/2016 07:14 PM, Tejun Heo wrote:
> Except that the patch seems to use irqsave/restore instead of plain
> irq ones in places. Care to update those?
Hi Tejun,
The use of the irq spin_(un)lock_irq() assumes that the code is always
called with IRQs enabled. But that is not always true in
On 06/16/2016 07:14 PM, Tejun Heo wrote:
> Except that the patch seems to use irqsave/restore instead of plain
> irq ones in places. Care to update those?
Hi Tejun,
The use of the irq spin_(un)lock_irq() assumes that the code is always
called with IRQs enabled. But that is not always true in
On Thu, Jun 16, 2016 at 06:03:15PM -0400, Tejun Heo wrote:
> On Thu, Jun 16, 2016 at 06:48:56PM -0300, Daniel Bristot de Oliveira wrote:
> > On 06/07/2016 05:05 PM, Daniel Bristot de Oliveira wrote:
> > > On 06/07/2016 04:30 PM, Tejun Heo wrote:
> > >> Is this something in mainline? This forces
On Thu, Jun 16, 2016 at 06:03:15PM -0400, Tejun Heo wrote:
> On Thu, Jun 16, 2016 at 06:48:56PM -0300, Daniel Bristot de Oliveira wrote:
> > On 06/07/2016 05:05 PM, Daniel Bristot de Oliveira wrote:
> > > On 06/07/2016 04:30 PM, Tejun Heo wrote:
> > >> Is this something in mainline? This forces
On Thu, Jun 16, 2016 at 06:48:56PM -0300, Daniel Bristot de Oliveira wrote:
> On 06/07/2016 05:05 PM, Daniel Bristot de Oliveira wrote:
> > On 06/07/2016 04:30 PM, Tejun Heo wrote:
> >> Is this something in mainline? This forces all task free path to be
> >> irq-safe, which *could* be fine but
On Thu, Jun 16, 2016 at 06:48:56PM -0300, Daniel Bristot de Oliveira wrote:
> On 06/07/2016 05:05 PM, Daniel Bristot de Oliveira wrote:
> > On 06/07/2016 04:30 PM, Tejun Heo wrote:
> >> Is this something in mainline? This forces all task free path to be
> >> irq-safe, which *could* be fine but
On 06/07/2016 05:05 PM, Daniel Bristot de Oliveira wrote:
> On 06/07/2016 04:30 PM, Tejun Heo wrote:
>> Is this something in mainline? This forces all task free path to be
>> irq-safe, which *could* be fine but it's weird to make cgroup free
>> path irq-safe for something which isn't in mainline.
On 06/07/2016 05:05 PM, Daniel Bristot de Oliveira wrote:
> On 06/07/2016 04:30 PM, Tejun Heo wrote:
>> Is this something in mainline? This forces all task free path to be
>> irq-safe, which *could* be fine but it's weird to make cgroup free
>> path irq-safe for something which isn't in mainline.
On 06/07/2016 04:30 PM, Tejun Heo wrote:
> Is this something in mainline? This forces all task free path to be
> irq-safe, which *could* be fine but it's weird to make cgroup free
> path irq-safe for something which isn't in mainline.
you mean, mainline linux kernel? if so, yes it is. I was
On 06/07/2016 04:30 PM, Tejun Heo wrote:
> Is this something in mainline? This forces all task free path to be
> irq-safe, which *could* be fine but it's weird to make cgroup free
> path irq-safe for something which isn't in mainline.
you mean, mainline linux kernel? if so, yes it is. I was
On Tue, Jun 07, 2016 at 03:51:15PM -0300, Daniel Bristot de Oliveira wrote:
> While testing the deadline scheduler + cgroup setup I hit this
> warning.
>
> [ 132.612935] [ cut here ]
> [ 132.612951] WARNING: CPU: 5 PID: 0 at kernel/softirq.c:150
>
On Tue, Jun 07, 2016 at 03:51:15PM -0300, Daniel Bristot de Oliveira wrote:
> While testing the deadline scheduler + cgroup setup I hit this
> warning.
>
> [ 132.612935] [ cut here ]
> [ 132.612951] WARNING: CPU: 5 PID: 0 at kernel/softirq.c:150
>
While testing the deadline scheduler + cgroup setup I hit this
warning.
[ 132.612935] [ cut here ]
[ 132.612951] WARNING: CPU: 5 PID: 0 at kernel/softirq.c:150
__local_bh_enable_ip+0x6b/0x80
[ 132.612952] Modules linked in: (a ton of modules...)
[ 132.612981] CPU: 5
While testing the deadline scheduler + cgroup setup I hit this
warning.
[ 132.612935] [ cut here ]
[ 132.612951] WARNING: CPU: 5 PID: 0 at kernel/softirq.c:150
__local_bh_enable_ip+0x6b/0x80
[ 132.612952] Modules linked in: (a ton of modules...)
[ 132.612981] CPU: 5
20 matches
Mail list logo
