On 2019-08-21 08:44:22 [+0200], Juri Lelli wrote:
> > Hi Juri, currently if the mail subject has RFC, we will test it but send
> > report
> > privately to author only.
>
> OK. But, my email had "RT" and not "RFC" in the subject (since it is
> meant for one of the PREEMPT_RT stable trees [1]).
On 2018-11-27 15:10:07 [+], Joe Korty wrote:
> Hi Clark,
Hi Clark,
> No I don't, sorry. I am attaching the LAG version, it is a few
> dozen lines shorter than the version I first sent out to the
> mailing list.
Did this make its way to rt-tests? I have some changes on top of it
while I was
On 2018-06-28 19:53:21 [+], Calciano, Jess wrote:
> So although the problem has already been reported, we're wondering if there
> are any updates on the status of the fix, or if it will be available in an
> upcoming mainline build.
In Linus' tree:
4bb6e96ab808 ("lib/percpu_ida.c: don't do
On 2018-06-28 19:53:21 [+], Calciano, Jess wrote:
> So although the problem has already been reported, we're wondering if there
> are any updates on the status of the fix, or if it will be available in an
> upcoming mainline build.
In Linus' tree:
4bb6e96ab808 ("lib/percpu_ida.c: don't do
On 2018-03-28 08:31:38 [-0700], Bart Van Assche wrote:
> On 03/28/18 08:14, bige...@linutronix.de wrote:
> > On 2018-03-28 15:05:41 [+], Bart Van Assche wrote:
> > > The names of the two functions touched by patch 1/2 start with a double
> > > underscore. That
On 2018-03-28 08:31:38 [-0700], Bart Van Assche wrote:
> On 03/28/18 08:14, bige...@linutronix.de wrote:
> > On 2018-03-28 15:05:41 [+], Bart Van Assche wrote:
> > > The names of the two functions touched by patch 1/2 start with a double
> > > underscore. That
On 2018-03-28 15:05:41 [+], Bart Van Assche wrote:
> The names of the two functions touched by patch 1/2 start with a double
> underscore. That by itself is already a hint that these should be called with
> a lock held (I know that this is not a universal convention in the Linux
> kernel). I'm
On 2018-03-28 15:05:41 [+], Bart Van Assche wrote:
> The names of the two functions touched by patch 1/2 start with a double
> underscore. That by itself is already a hint that these should be called with
> a lock held (I know that this is not a universal convention in the Linux
> kernel). I'm
On 2018-03-26 11:13:59 [-0400], Steven Rostedt wrote:
> > diff --git a/drivers/target/target_core_tmr.c
> > b/drivers/target/target_core_tmr.c
> > index 9c7bc1ca341a..3d35dad1de2c 100644
> > --- a/drivers/target/target_core_tmr.c
> > +++ b/drivers/target/target_core_tmr.c
>
> Can you add a
On 2018-03-26 11:13:59 [-0400], Steven Rostedt wrote:
> > diff --git a/drivers/target/target_core_tmr.c
> > b/drivers/target/target_core_tmr.c
> > index 9c7bc1ca341a..3d35dad1de2c 100644
> > --- a/drivers/target/target_core_tmr.c
> > +++ b/drivers/target/target_core_tmr.c
>
> Can you add a
On 2018-03-23 17:44:46 [+], Bart Van Assche wrote:
> On Fri, 2018-03-23 at 18:19 +0100, bige...@linutronix.de wrote:
> > __target_attach_tg_pt_gp() and __target_detach_tg_pt_gp() check if the
> > caller
> > holds lun_tg_pt_gp_lock(). Both functions are static, the call
On 2018-03-23 17:44:46 [+], Bart Van Assche wrote:
> On Fri, 2018-03-23 at 18:19 +0100, bige...@linutronix.de wrote:
> > __target_attach_tg_pt_gp() and __target_detach_tg_pt_gp() check if the
> > caller
> > holds lun_tg_pt_gp_lock(). Both functions are static, the call
__target_attach_tg_pt_gp() and __target_detach_tg_pt_gp() check if the caller
holds lun_tg_pt_gp_lock(). Both functions are static, the callers are
acquiring the lock before the invocation of the function so the check
looks superfluous.
Remove it.
Signed-off-by: Sebastian Andrzej Siewior <b
__target_attach_tg_pt_gp() and __target_detach_tg_pt_gp() check if the caller
holds lun_tg_pt_gp_lock(). Both functions are static, the callers are
acquiring the lock before the invocation of the function so the check
looks superfluous.
Remove it.
Signed-off-by: Sebastian Andrzej Siewior
---
ion that is exported to random users,
|and we should check that the calling convention is right.
|
|This looks like "it may have been useful during coding to document
|things, but it's not useful long-term".
Remove those checks.
Signed-off-by: Sebastian Andrzej Siewior <bige.
There are a few functions which check for if the lock is held
(spin_lock_assert()) and the interrupts are disabled (irqs_disabled()).
>From looking at the code, each function is static, the caller is near by
and does spin_lock_irq|safe(). As Linus puts it:
|It's not like this is some function
On 2018-03-23 16:25:25 [+], Bart Van Assche wrote:
> On Fri, 2018-03-23 at 16:55 +0100, Sebastian Andrzej Siewior wrote:
> > I am going take this into -RT tree for now until we have different
> > solution.
>
> Have you considered to delete the WARN_ON_ONCE(!irqs_disabled()) statement?
> I
On 2018-03-23 16:25:25 [+], Bart Van Assche wrote:
> On Fri, 2018-03-23 at 16:55 +0100, Sebastian Andrzej Siewior wrote:
> > I am going take this into -RT tree for now until we have different
> > solution.
>
> Have you considered to delete the WARN_ON_ONCE(!irqs_disabled()) statement?
> I
acing/cpuhotplug: Fix locking order")
> Signed-off-by: Alexander Levin <alexander.le...@verizon.com>
Acked-by: Sebastian Andrzej Siewior <bige...@linutronix.de>
Sebastian
On 2017-06-03 03:39:13 [+], Levin, Alexander (Sasha Levin) wrote:
> From: Alexander Levin
>
> If we failed to acquire task's cred_guard_mutex we shouldn't proceed
> to release it in the error path.
>
> Fixes: a63fbed776c ("perf/tracing/cpuhotplug: Fix locking order")
> Signed-off-by:
20 matches
Mail list logo
