Re: [PATCH -rt] MIPS: Octeon: convert smp_reserve_lock to rawspinlock

[Yong Zhang]

On Thu, May 17, 2012 at 10:50:03PM +0200, Ralf Baechle wrote:
> On Thu, May 17, 2012 at 09:30:42AM -0700, David Daney wrote:
> > Date:   Thu, 17 May 2012 09:30:42 -0700
> > From: David Daney <ddaney.cavm@xxxxxxxxx>
> > To: Yong Zhang <yong.zhang0@xxxxxxxxx>, ralf@xxxxxxxxxxxxxx
> > CC: linux-rt-users@xxxxxxxxxxxxxxx, linux-kernel@xxxxxxxxxxxxxxx,
> >  david.daney@xxxxxxxxxx, tglx@xxxxxxxxxxxxx
> > Subject: Re: [PATCH -rt] MIPS: Octeon: convert smp_reserve_lock to raw
> >  spinlock
> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> > 
> > On 05/17/2012 03:15 AM, Yong Zhang wrote:
> > >From: Yong Zhang<yong.zhang@xxxxxxxxxxxxx>
> > >
> > >Because __cpu_disable is called in atomic context and spinlock
> > >is a mutex on -rt.
> > >
> > >Signed-off-by: Yong Zhang<yong.zhang0@xxxxxxxxx>
> > >---
> > >  arch/mips/cavium-octeon/smp.c |    6 +++---
> > >  1 files changed, 3 insertions(+), 3 deletions(-)
> > >
> > >diff --git a/arch/mips/cavium-octeon/smp.c b/arch/mips/cavium-octeon/smp.c
> > >index ef9c34a..473c72b 100644
> > >--- a/arch/mips/cavium-octeon/smp.c
> > >+++ b/arch/mips/cavium-octeon/smp.c
> > >@@ -257,7 +257,7 @@ DEFINE_PER_CPU(int, cpu_state);
> > >
> > >  extern void fixup_irqs(void);
> > >
> > >-static DEFINE_SPINLOCK(smp_reserve_lock);
> > >+static DEFINE_RAW_SPINLOCK(smp_reserve_lock);
> > >
> > 
> > Ralf added this in 773cb77d (MIPS: Cavium: Add CPU hotplugging code.)
> > 
> > I'm not even sure what this lock is supposed to be protecting, so I
> > would like Ralf to take a look.
> > 
> > You can add an Acked-by: from me for either this patch as is, or if
> > Ralf thinks it is OK, removing the lock entirely.
> > 
> > In any event we can merge this via Ralf's tree.
> 
> The 773cb77d patch has a long history but I think I first worked on it for
> Wind River Linux 2.0 which was 2.6.21-based, then broke it out and pushed
> it upstream.  In 2.6.21 it was probably infected by the the smp_reserve_lock
> virus in the s390 code for no good reason.  So I agree, the lock can
> be dropped and I'm queueing a patch to do so for 3.5.

I'm OK with dropping it ;-)

Thanks,
Yong
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/