Re: [PATCH v2] ASoC: atmel_ssc_dai: Allow more rates

2015-02-09 Thread Bo Shen

Hi Peter,

On 02/09/2015 03:35 PM, Peter Rosin wrote:

Bo Shen wrote:

Hi Peter,


Hi!


On 02/07/2015 06:51 PM, Peter Rosin wrote:

Mark Brown wrote:

On Wed, Feb 04, 2015 at 12:52:25PM +0100, Peter Rosin wrote:


One thing remains a bit unclear, and that is the 500ppm deduction.
Is that really warranted? The number was just pulled out of my hat...


I don't really get what this is supposed to be protecting against.


+   case SND_SOC_DAIFMT_CBM_CFS:
+   case SND_SOC_DAIFMT_CBM_CFM:
+   t.min = 8000;
+   t.max = ssc_p->mck_rate / mck_div / frame_size;
+   /* Take away 500ppm, just to be on the safe side. */
+   t.max -= t.max / 2000;
+   t.openmin = t.openmax = 0;
+   t.integer = 0;
+   ret = snd_interval_refine(i, &t);


As I understand it this is a straight divider rather than something
that's doing dithering or anything else more fancy.  Given that it
seems as well just to trust the clock rate we've got - we don't do
any error tracking with the clock API (perhaps we should) and for
many applications some degree of divergence from the nominal rate is
not
*too* bad for audio systems (for application specific values of "some"
and "too" of course).  If it is just dividers I'm not sure the
situation is really improved materially by knocking off the top frequency.

If we are doing something more fancy than divididing my analysis is
off base of course.


I'm thinking that the SSC samples the selected BCK pin using the
(possibly
divided) peripheral clock. Getting too near the theoretical rate limit
would be bad, if these two independent clocks drift the wrong way. At
least that is my take on it, but I don't know the internal workings of the SSC, 
so...

I was hoping that someone from Atmel could chime in? Maybe I'm totally


Sorry for late response.


No problem!


off base, and the SSC is doing this completely differently?


What you mean here? I am not sure I fully understand.


The SSC spec list a maximum rate (which varies with the direction
of various signals, ignoring that for the sake of this explanation). Lets
assume that this maximum rate is 11MHz, derived from the peripheral
clock which might be 66MHz. If you then try to input an 11MHz signal
derived from some unrelated xtal you might think it should work. My
theory was that the rate limit would be broken if the peripheral clock
wasn't really 66MHz, but instead a few ppm lower than nominal, and
the unrelated xtal was a few ppm higher than nominal.

If this matters or not depends on how the SSC is implemented.


This is to let the user to know the clock limitation, am I right?

And at the same time deal with the un-precise clock which come to SSC? 
If this case, I think we should trust the clock come to SSC.



There might be other reasons for not caring all that much about
this fringe case, and just trust the nominal rates and limits.


In our application, we're not near the limit. Therefore, it really
doesn't matter much to us.

Should I resend w/o the 500ppm deduction?

Cheers,
Peter



Best Regards,
Bo Shen


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


Re: gpio-pxa: getting GPIOs by devicetree phandle broken

2015-02-09 Thread Robert Jarzmik
Alexandre Courbot  writes:

> Adding Robert who reported the same thing.
>
> On Sat, Feb 7, 2015 at 6:28 AM, Tyler Hall  wrote:
>> 1. Require child nodes in DT for each bank
>
> This would break DT compatibility.
Agreed.

>
>> 2. Refactor gpio-pxa to only register one gpiochip
>
> Sounds better, especially since this would reflect the hardware more
> accurately. One DT node should translate into one GPIO chip.
Could I know where "should translate into _one_ GPIO chip" comes from ? Is it a
specification, or is it a new rule we're creating ?

And if it's a new rule, I'd like to know what backs it up .

> problem is that I'm afraid several other drivers are doing the same
> thing and thus are now similarly broken.
That's also what I'm afraid of.

> The following is also likely to work as a workaround, but I would not
> go as far as saying this should be taken as a fix. Hans, since you
> wrote 7b8792b, could we have your input on this?
I was going to suggest the very same approach. If this one (or a similar one)
doesn't meet success, then my weekend of revert queries is not over ... and I
don't like reverts.

Cheers.

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


linux-next: manual merge of the target-updates tree with the net-next tree

2015-02-09 Thread Stephen Rothwell
Hi Nicholas,

Today's linux-next merge of the target-updates tree got a conflict in
drivers/vhost/scsi.c between commit 57dd8a0735aa ("vhost:
vhost_scsi_handle_vq() should just use copy_from_user()") from the
net-next tree and commit 09b13fa8c1a1 ("vhost/scsi: Add ANY_LAYOUT
support in vhost_scsi_handle_vq") from the target-updates tree.

I fixed it up (the latter removes the code modified by the former) and
can carry the fix as necessary (no action is required).

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


pgpk3RQ7G7OSA.pgp
Description: OpenPGP digital signature


RE: [PATCH v2] ASoC: atmel_ssc_dai: Allow more rates

2015-02-09 Thread Peter Rosin
Bo Shen wrote:
> Hi Peter,

Hi!

> On 02/04/2015 07:52 PM, Peter Rosin wrote:
> > From: Peter Rosin 
> >
> > When the SSC acts as BCK master, use a ratnum rule to limit the rate
> > instead of only doing the standard rates. When the SSC acts as BCK
> > slave, allow any BCK frequency up to within 500ppm of the SSC master
> > clock, possibly divided by 2, 3 or 6.
> >
> > Put a cap at 384kHz. Who's /ever/ going to need more than that?
> >
> > The divider of 2, 3 or 6 is selected based on the Serial Clock Ratio
> > Considerations section from the SSC documentation:
> >
> >  The Transmitter and the Receiver can be programmed to operate
> >  with the clock signals provided on either the TK or RK pins.
> >  This allows the SSC to support many slave-mode data transfers.
> >  In this case, the maximum clock speed allowed on the RK pin is:
> >  - Peripheral clock divided by 2 if Receiver Frame Synchro is input
> >  - Peripheral clock divided by 3 if Receiver Frame Synchro is output
> >  In addition, the maximum clock speed allowed on the TK pin is:
> >  - Peripheral clock divided by 6 if Transmit Frame Synchro is input
> >  - Peripheral clock divided by 2 if Transmit Frame Synchro is
> > output
> >
> > Signed-off-by: Peter Rosin 
> > ---
> >   sound/soc/atmel/atmel_ssc_dai.c |  113
> +--
> >   sound/soc/atmel/atmel_ssc_dai.h |1 +
> >   2 files changed, 110 insertions(+), 4 deletions(-)
> >
> > Changes since v1:
> >
> > - I have checked all Atmel datasheets I could get my hands on (and
> >that seemed relevant), and in every instance where they have
> >described the SSC, the description have the exact rate limitations
> >on the RK and TK pin that I have implemented here.
> >
> > - Improved the comments.
> >
> > - Rebased on top of the latest patches from Bo Chen.
> >
> > One thing remains a bit unclear, and that is the 500ppm deduction. Is
> > that really warranted? The number was just pulled out of my hat...
> >
> > Cheers,
> > Peter
> >
> > diff --git a/sound/soc/atmel/atmel_ssc_dai.c
> > b/sound/soc/atmel/atmel_ssc_dai.c index 379ac2a6ab16..767f65bab25d
> > 100644
> > --- a/sound/soc/atmel/atmel_ssc_dai.c
> > +++ b/sound/soc/atmel/atmel_ssc_dai.c
> > @@ -187,6 +187,96 @@ static irqreturn_t atmel_ssc_interrupt(int irq, void 
> > *dev_id)
> > return IRQ_HANDLED;
> >   }
> >
> > +/*
> > + * When the bit clock is input, limit the maximum rate according to
> > +the
> > + * Serial Clock Ratio Considerations section from the SSC documentation:
> > + *
> > + *   The Transmitter and the Receiver can be programmed to operate
> > + *   with the clock signals provided on either the TK or RK pins.
> > + *   This allows the SSC to support many slave-mode data transfers.
> > + *   In this case, the maximum clock speed allowed on the RK pin is:
> > + *   - Peripheral clock divided by 2 if Receiver Frame Synchro is input
> > + *   - Peripheral clock divided by 3 if Receiver Frame Synchro is output
> > + *   In addition, the maximum clock speed allowed on the TK pin is:
> > + *   - Peripheral clock divided by 6 if Transmit Frame Synchro is input
> > + *   - Peripheral clock divided by 2 if Transmit Frame Synchro is output
> > + *
> > + * When the bit clock is output, limit the rate according to the
> > + * SSC divider restrictions.
> > + */
> > +static int atmel_ssc_hw_rule_rate(struct snd_pcm_hw_params *params,
> > + struct snd_pcm_hw_rule *rule)
> > +{
> > +   struct atmel_ssc_info *ssc_p = rule->private;
> > +   struct ssc_device *ssc = ssc_p->ssc;
> > +   struct snd_interval *i = hw_param_interval(params, rule->var);
> > +   struct snd_interval t;
> > +   struct snd_ratnum r = {
> > +   .den_min = 1,
> > +   .den_max = 4095,
> > +   .den_step = 1,
> > +   };
> > +   unsigned int num = 0, den = 0;
> > +   int frame_size;
> > +   int mck_div = 2;
> > +   int ret;
> > +
> > +   frame_size = snd_soc_params_to_frame_size(params);
> > +   if (frame_size < 0)
> > +   return frame_size;
> > +
> > +   switch (ssc_p->daifmt & SND_SOC_DAIFMT_MASTER_MASK) {
> > +   case SND_SOC_DAIFMT_CBM_CFS:
> > +   if ((ssc_p->dir_mask & SSC_DIR_MASK_CAPTURE)
> > +   && ssc->clk_from_rk_pin)
> > +   /* Receiver Frame Synchro (i.e. capture)
> > +* is output (format is _CFS) and the RK pin
> > +* is used for input (format is _CBM_).
> > +*/
> > +   mck_div = 3;
> > +   break;
> > +
> > +   case SND_SOC_DAIFMT_CBM_CFM:
> > +   if ((ssc_p->dir_mask & SSC_DIR_MASK_PLAYBACK)
> > +   && !ssc->clk_from_rk_pin)
> > +   /* Transmit Frame Synchro (i.e. playback)
> > +* is input (format is _CFM) and the TK pin
> > +* is used for input (format _CBM_ but not
> > +* using the RK pin).
> > +  

[PATCH 2/3] powerpc: Relax secure computing on syscall entry trace

2015-02-09 Thread Bogdan Purcareata
The secure_computing_strict will just force the kernel to panic on
secure_computing failure. Once SECCOMP_FILTER support is enabled in the kernel,
syscalls can be denied without system failure.

Signed-off-by: Bogdan Purcareata 
---
 arch/powerpc/kernel/ptrace.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/arch/powerpc/kernel/ptrace.c b/arch/powerpc/kernel/ptrace.c
index 100e01c..5c654ac 100644
--- a/arch/powerpc/kernel/ptrace.c
+++ b/arch/powerpc/kernel/ptrace.c
@@ -1772,7 +1772,9 @@ long do_syscall_trace_enter(struct pt_regs *regs)
 
user_exit();
 
-   secure_computing_strict(regs->gpr[0]);
+   /* Do the secure computing check first; failures should be fast. */
+   if (secure_computing(regs->gpr[0]) == -1)
+   return -1L;
 
if (test_thread_flag(TIF_SYSCALL_TRACE) &&
tracehook_report_syscall_entry(regs))
-- 
2.1.4

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


[PATCH] powerpc: Enable HAVE_ARCH_SECCOMP_FILTER

2015-02-09 Thread Bogdan Purcareata
Signed-off-by: Bogdan Purcareata 
---
 arch/powerpc/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index a2a168e..72f363e 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -104,6 +104,7 @@ config PPC
select HAVE_EFFICIENT_UNALIGNED_ACCESS if !CPU_LITTLE_ENDIAN
select HAVE_KPROBES
select HAVE_ARCH_KGDB
+   select HAVE_ARCH_SECCOMP_FILTER
select HAVE_KRETPROBES
select HAVE_ARCH_TRACEHOOK
select HAVE_MEMBLOCK
-- 
2.1.4

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


[RFC][PATCH 1/3] powerpc: Don't force ENOSYS as error on syscall fail

2015-02-09 Thread Bogdan Purcareata
In certain scenarios - e.g. seccomp filtering with ERRNO as default action -
the system call fails for other reasons than the syscall not being available.
The seccomp filter can be configured to store a user-defined error code on
return from a blacklisted syscall.

The RFC is this: are there currently any user-space scenarios where it is
required that the system call return ENOSYS as error code on failure, no matter
the circumstances? I don't want to break userspace requirements. I have not
added code to force this error code in situations different than
secure_computing failure, in order to keep overhead at a minimum.

Signed-off-by: Bogdan Purcareata 
---
 arch/powerpc/kernel/entry_32.S | 3 ++-
 arch/powerpc/kernel/entry_64.S | 2 +-
 2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/kernel/entry_32.S b/arch/powerpc/kernel/entry_32.S
index 59848e5..52e48dd 100644
--- a/arch/powerpc/kernel/entry_32.S
+++ b/arch/powerpc/kernel/entry_32.S
@@ -425,7 +425,8 @@ END_FTR_SECTION_IFSET(CPU_FTR_NEED_PAIRED_STWCX)
b   1b
 #endif  /* CONFIG_44x */
 
-66:li  r3,-ENOSYS
+66:
+#  li  r3,-ENOSYS
b   ret_from_syscall
 
.globl  ret_from_fork
diff --git a/arch/powerpc/kernel/entry_64.S b/arch/powerpc/kernel/entry_64.S
index e6bfe8e..80db02e 100644
--- a/arch/powerpc/kernel/entry_64.S
+++ b/arch/powerpc/kernel/entry_64.S
@@ -269,7 +269,7 @@ syscall_dotrace:
b   .Lsyscall_dotrace_cont
 
 syscall_enosys:
-   li  r3,-ENOSYS
+#  li  r3,-ENOSYS
b   syscall_exit

 syscall_exit_work:
-- 
2.1.4

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


RE: [PATCH v2] ASoC: atmel_ssc_dai: Allow more rates

2015-02-09 Thread Peter Rosin
Bo Shen wrote:
> Hi Peter,
> 
> On 02/09/2015 03:35 PM, Peter Rosin wrote:
> > Bo Shen wrote:
> >> Hi Peter,
> >
> > Hi!
> >
> >> On 02/07/2015 06:51 PM, Peter Rosin wrote:
> >>> Mark Brown wrote:
>  On Wed, Feb 04, 2015 at 12:52:25PM +0100, Peter Rosin wrote:
> 
> > One thing remains a bit unclear, and that is the 500ppm deduction.
> > Is that really warranted? The number was just pulled out of my hat...
> 
>  I don't really get what this is supposed to be protecting against.
> 
> > +   case SND_SOC_DAIFMT_CBM_CFS:
> > +   case SND_SOC_DAIFMT_CBM_CFM:
> > +   t.min = 8000;
> > +   t.max = ssc_p->mck_rate / mck_div / frame_size;
> > +   /* Take away 500ppm, just to be on the safe side. */
> > +   t.max -= t.max / 2000;
> > +   t.openmin = t.openmax = 0;
> > +   t.integer = 0;
> > +   ret = snd_interval_refine(i, &t);
> 
>  As I understand it this is a straight divider rather than something
>  that's doing dithering or anything else more fancy.  Given that it
>  seems as well just to trust the clock rate we've got - we don't do
>  any error tracking with the clock API (perhaps we should) and for
>  many applications some degree of divergence from the nominal rate
>  is not
>  *too* bad for audio systems (for application specific values of "some"
>  and "too" of course).  If it is just dividers I'm not sure the
>  situation is really improved materially by knocking off the top 
>  frequency.
> 
>  If we are doing something more fancy than divididing my analysis is
>  off base of course.
> >>>
> >>> I'm thinking that the SSC samples the selected BCK pin using the
> >>> (possibly
> >>> divided) peripheral clock. Getting too near the theoretical rate
> >>> limit would be bad, if these two independent clocks drift the wrong
> >>> way. At least that is my take on it, but I don't know the internal 
> >>> workings of the SSC, so...
> >>>
> >>> I was hoping that someone from Atmel could chime in? Maybe I'm
> >>> totally
> >>
> >> Sorry for late response.
> >
> > No problem!
> >
> >>> off base, and the SSC is doing this completely differently?
> >>
> >> What you mean here? I am not sure I fully understand.
> >
> > The SSC spec list a maximum rate (which varies with the direction of
> > various signals, ignoring that for the sake of this explanation). Lets
> > assume that this maximum rate is 11MHz, derived from the peripheral
> > clock which might be 66MHz. If you then try to input an 11MHz signal
> > derived from some unrelated xtal you might think it should work. My
> > theory was that the rate limit would be broken if the peripheral clock
> > wasn't really 66MHz, but instead a few ppm lower than nominal, and the
> > unrelated xtal was a few ppm higher than nominal.
> >
> > If this matters or not depends on how the SSC is implemented.
> 
> This is to let the user to know the clock limitation, am I right?

Yes, sort of, to prevent the user from even attempting to go too
near the nominal limit.

> And at the same time deal with the un-precise clock which come to SSC?
> If this case, I think we should trust the clock come to SSC.

Ok, I'll just kill the 500ppm thing for the next round. I'll wait a bit
for the discussion in the other branch to fade out though. :-)

Cheers,
Peter

> > There might be other reasons for not caring all that much about this
> > fringe case, and just trust the nominal rates and limits.
> >
> >>> In our application, we're not near the limit. Therefore, it really
> >>> doesn't matter much to us.
> >>>
> >>> Should I resend w/o the 500ppm deduction?
> >>>
> >>> Cheers,
> >>> Peter
> >>>
> >>
> >> Best Regards,
> >> Bo Shen
> 
> Best Regards,
> Bo Shen
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


RE: [RFC] change non-atomic bitops method

2015-02-09 Thread Wang, Yalin
> -Original Message-
> From: Andrew Morton [mailto:a...@linux-foundation.org]
> Sent: Tuesday, February 03, 2015 6:59 PM
> To: Wang, Yalin
> Cc: 'Kirill A. Shutemov'; 'a...@arndb.de'; 'linux-a...@vger.kernel.org';
> 'linux-kernel@vger.kernel.org'; 'li...@arm.linux.org.uk'; 'linux-arm-
> ker...@lists.infradead.org'
> Subject: Re: [RFC] change non-atomic bitops method
> 
> On Tue, 3 Feb 2015 16:42:14 +0800 "Wang, Yalin" 
> wrote:
> 
> > I make a change in kernel to test hit/miss ratio:
> 
> Neat, thanks.
> 
> >
> > ...
> >
> > After use the phone some time:
> > root@D5303:/ # cat /proc/meminfo
> > VmallocUsed:   10348 kB
> > VmallocChunk:  75632 kB
> > __set_bit_miss_count:10002 __set_bit_success_count:1096661
> > __clear_bit_miss_count:359484 __clear_bit_success_count:3674617
> > __test_and_set_bit_miss_count:7 __test_and_set_bit_success_count:221
> > __test_and_clear_bit_miss_count:924611
> __test_and_clear_bit_success_count:193
> >
> > __test_and_clear_bit_miss_count has a very high miss rate.
> > In fact, I think set/clear/test_and_set(clear)_bit atomic version can
> also
> > Be investigated to see its miss ratio,
> > I have not tested the atomic version,
> > Because it reside in different architectures.
> 
> Hopefully misses in test_and_X_bit are not a problem.  The CPU
> implementation would be pretty stupid to go and dirty the cacheline
> when it knows it didn't change anything.  But maybe I'm wrong about
> that.
> 
> That we're running clear_bit against a cleared bit 10% of the time is a
> bit alarming.  I wonder where that's coming from.
> 
> The enormous miss count in test_and_clear_bit() might indicate an
> inefficiency somewhere.
I te-test the patch on 3.10 kernel.
The result like this:

VmallocChunk:   251498164 kB
__set_bit_miss_count:11730 __set_bit_success_count:1036316
__clear_bit_miss_count:209640 __clear_bit_success_count:4806556
__test_and_set_bit_miss_count:0 __test_and_set_bit_success_count:121
__test_and_clear_bit_miss_count:0 __test_and_clear_bit_success_count:445

__clear_bit miss rate is a little high,
I check the log, and most miss coming from this code:

<6>[  442.701798] [] warn_slowpath_fmt+0x4c/0x58
<6>[  442.701805] [] __clear_bit+0x98/0xa4
<6>[  442.701813] [] __alloc_fd+0xc8/0x124
<6>[  442.701821] [] get_unused_fd_flags+0x28/0x34
<6>[  442.701828] [] do_sys_open+0x10c/0x1c0
<6>[  442.701835] [] SyS_openat+0xc/0x18
In __clear_close_on_exec(fd, fdt);



<6>[  442.695354] [] warn_slowpath_fmt+0x4c/0x58
<6>[  442.695359] [] __clear_bit+0x98/0xa4
<6>[  442.695367] [] dup_fd+0x1d4/0x280
<6>[  442.695375] [] copy_process.part.56+0x42c/0xe38
<6>[  442.695382] [] do_fork+0xe0/0x360
<6>[  442.695389] [] SyS_clone+0x10/0x1c
In __clear_open_fd(open_files - i, new_fdt);

Do we need test_bit() before clear_bit()at these 2 place?

Thanks




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


Re: [E1000-devel] [PATCH 1/3] ixgbe, ixgbevf: Add new mbox API to enable MC promiscuous mode

2015-02-09 Thread Jeff Kirsher
On Mon, 2015-02-09 at 06:59 +, Hiroshi Shimamoto wrote:
> > > Subject: Re: [E1000-devel] [PATCH 1/3] ixgbe, ixgbevf: Add new mbox API 
> > > to enable MC promiscuous mode
> > >
> > > On Fri, 2015-01-30 at 11:37 +, Hiroshi Shimamoto wrote:
> > > > From: Hiroshi Shimamoto 
> > > >
> > > > The limitation of the number of multicast address for VF is not enough
> > > > for the large scale server with SR-IOV feature.
> > > > IPv6 requires the multicast MAC address for each IP address to handle
> > > > the Neighbor Solicitation message.
> > > > We couldn't assign over 30 IPv6 addresses to a single VF interface.
> > > >
> > > > The easy way to solve this is enabling multicast promiscuous mode.
> > > > It is good to have a functionality to enable multicast promiscuous
> > > > mode
> > > > for each VF from VF driver.
> > > >
> > > > This patch introduces the new mbox API, IXGBE_VF_SET_MC_PROMISC, to
> > > > enable/disable multicast promiscuous mode in VF. If multicast
> > > > promiscuous
> > > > mode is enabled the VF can receive all multicast packets.
> > > >
> > > > With this patch, the ixgbevf driver automatically enable multicast
> > > > promiscuous mode when the number of multicast addresses is over than
> > > > 30
> > > > if possible.
> > > >
> > > > This also bump the API version up to 1.2 to check whether the API,
> > > > IXGBE_VF_SET_MC_PROMISC is available.
> > > >
> > > > Signed-off-by: Hiroshi Shimamoto 
> > > > Reviewed-by: Hayato Momma 
> > > > CC: Choi, Sy Jong 
> > > > ---
> > > >  drivers/net/ethernet/intel/ixgbe/ixgbe.h  |  1 +
> > > >  drivers/net/ethernet/intel/ixgbe/ixgbe_mbx.h  |  4 +
> > > >  drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c| 89
> > > > ++-
> > > >  drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c | 13 +++-
> > > >  drivers/net/ethernet/intel/ixgbevf/mbx.h  |  4 +
> > > >  drivers/net/ethernet/intel/ixgbevf/vf.c   | 29 +++-
> > > >  drivers/net/ethernet/intel/ixgbevf/vf.h   |  1 +
> > > >  7 files changed, 137 insertions(+), 4 deletions(-)
> > >
> > > Hiroshi, I tried to apply your patches to my queue but they do not apply
> > > cleanly and they are in a DOS file format, not UNIX.  I also noted
> > > several checkpatch.pl issues with your patches, so please fix those up
> > > as well.
> > 
> > I'm sorry to bother you.
> > Will fix.
> > 
> > >
> > > Can you please fix up your patches based on my tree:
> > > git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/queue.git
> > 
> > Yes. I haven't noticed your tree.
> > Will resend patches against it.
> > 
> 
> I encountered an issue with your tree, the commit id is below.
> 
> $ git log | head
> commit e6f1649780f8f5a87299bf6af04453f93d1e3d5e
> Author: Rasmus Villemoes 
> Date:   Fri Jan 23 20:43:14 2015 -0800
> 
> ethernet: fm10k: Actually drop 4 bits
> 
> The comment explains the intention, but vid has type u16. Before the
> inner shift, it is promoted to int, which has plenty of space for all
> vid's bits, so nothing is dropped. Use a simple mask instead.
> 
> 
> I use the kernel from your tree in both host and guest.
> 
> Assign an IPv6 for VF in guest.
> # ip -6 addr add 2001:db8::18:1/64 dev ens0
> 
> Send ping packet from other server to the VM.
> # ping6  2001:db8::18:1 -I eth0
> 
> The following message was shown.
> ixgbevf :00:08.0: partial checksum but l4 proto=3a!
> 
> If I did the same operation in the host, I saw the same error message in host 
> too.
> ixgbe :2d:00.0: partial checksum but l4 proto=3a!
> 
> Do you have any idea about that?

Ah, sorry about that, try this tree again:
git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/queue.git

That patch was dropped for favor of a patch that Matthew Vick put
together (and recently got pushed upstream).  So my queue no longer has
that patch in the queue, since it got dropped.


signature.asc
Description: This is a digitally signed message part


Re: [tip:sched/urgent] sched/fair: Avoid using uninitialized variable in preferred_group_nid()

2015-02-09 Thread Ingo Molnar

* Peter Zijlstra  wrote:

> On Wed, Jan 28, 2015 at 02:46:19PM +, Jan Beulich wrote:
> > >>> On 28.01.15 at 15:29,  wrote:
> > > Commit-ID:  81907478c4311a679849216abf723999184ab984
> > > Gitweb: 
> > > http://git.kernel.org/tip/81907478c4311a679849216abf723999184ab984 
> > > Author: Jan Beulich 
> > > AuthorDate: Fri, 23 Jan 2015 08:25:38 +
> > > Committer:  Ingo Molnar 
> > > CommitDate: Wed, 28 Jan 2015 13:14:12 +0100
> > > 
> > > sched/fair: Avoid using uninitialized variable in preferred_group_nid()
> > > 
> > > At least some gcc versions - validly afaict - warn about potentially
> > > using max_group uninitialized: There's no way the compiler can prove
> > > that the body of the conditional where it and max_faults get set/
> > > updated gets executed; in fact, without knowing all the details of
> > > other scheduler code, I can't prove this either.
> > > 
> > > Generally the necessary change would appear to be to clear max_group
> > > prior to entering the inner loop, and break out of the outer loop when
> > > it ends up being all clear after the inner one. This, however, seems
> > > inefficient, and afaict the same effect can be achieved by exiting the
> > > outer loop when max_faults is still zero after the inner loop.
> > > 
> > > [ mingo: changed the solution to zero initialization: uninitialized_var()
> > >   needs to die, as it's an actively dangerous construct: if in the future
> > >   a known-proven-good piece of code is changed to have a true, buggy
> > >   uninitialized variable, the compiler warning is then supressed...
> > 
> > But you went farther than that: You also dropped the breaking
> > out of the outer loop. Yet that has - beyond the fixing of the bug
> > here - the desirable effect of not continuing for perhaps many
> > iterations when nothing new can ever be found anymore.
> 
> That break is indeed desired. The 'problem' it fixes is 
> that when group_faults() returns 0, faults will be 0, 
> which will not > max_faults, and therefore we will not 
> set max_group.
> 
> Without that break, we'll now set nodes to 
> NODE_MASK_NONE, which will mean the for_each_node(a, 
> nodes) loop will NOP and our dist loop will iterate 
> pointlessly.

Ok, agreed, please send a separate patch to fix this.

Thanks,

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


Re: [PATCH] kvm: add halt_poll_ns module parameter

2015-02-09 Thread Xiao Guangrong



On 02/06/2015 08:48 PM, Paolo Bonzini wrote:



+unsigned int halt_poll_ns = 0;
+module_param(halt_poll_ns, uint, S_IRUGO | S_IWUSR);
+


Can we make this parameter be changeable? So that we can tune it
on the fly.


finish_wait(&vcpu->wq, &wait);
+   cur = ktime_get();


We can move this into the tracepoint to avoid the workload if the
tracepoint is not enabled.

Otherwise looks good to me.

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


Re: [tip:irq/core] genirq: Set initial affinity in irq_set_affinity_hint()

2015-02-09 Thread Ingo Molnar

* Jesse Brandeburg  wrote:

> On Tue, 27 Jan 2015 22:36:23 -0800
> Yinghai Lu  wrote:
> 
> > On Fri, Jan 23, 2015 at 2:42 AM, tip-bot for Jesse Brandeburg
> >  wrote:
> > > Commit-ID:  e2e64a932556cdfae455497dbe94a8db151fc9fa
> > > Gitweb: 
> > > http://git.kernel.org/tip/e2e64a932556cdfae455497dbe94a8db151fc9fa
> > > Author: Jesse Brandeburg 
> > > AuthorDate: Thu, 18 Dec 2014 17:22:06 -0800
> > > Committer:  Thomas Gleixner 
> > > CommitDate: Fri, 23 Jan 2015 11:38:25 +0100
> > >
> > > genirq: Set initial affinity in irq_set_affinity_hint()
>  
> > there are lots of irq_set_affinity_hint(irq, NULL);
> > 
> > git grep -A 1 irq_set_affinity_hint | grep NULL | wc -l
> > 26
> > 
> > You may need to add check ...in irq_set_affinity_hint()
> 
> Patch posted to fix the issue (added a null check)

Under what subject line was this fix sent? I don't seem to 
find it in my mbox.

Thanks,

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


Re: [PATCH 0/2] ARM: omap2+: omap_hwmod: Fix false lockdep warning

2015-02-09 Thread Peter Ujfalusi
On 02/06/2015 09:26 PM, Peter Ujfalusi wrote:
>> Yeah, I've never really bothered with data too much, its a debug
>> feature. So lock_class_key is 8 bytes, and strictly speaking you could
>> union them over other fields, all we really need is unique addresses, we
>> don't actually use the storage.
> 
> True. our omap2plus defconfig does not have LOCKDEP enabled so it should not
> add anything to the data when running default kernel.
> I'll test the lockdep_set_class() method you suggested on Monday (not
> tomorrow), but still as first thing.
> If it is working as expected I'll send a patch with you as author.

With omap2plus_defconfig my build produces (vmlinux size):
Base:   99905522
with my series: 99908385 (base + 2863)
with Peter Zijlstra's patch:99910625 (base + 5103)

The reason for this is that we will only have
struct lock_class_key { };
in case of !CONFIG_LOCKDEP. On ARM however CONFIG_LOCKDEP is enabled by
default, while the CONFIG_DEBUG_LOCKDEP is disabled.

So it does add more data to our default omap2plus config.

Tony: do you have preference on the way we fix this issue?

As I recall there is a plan to remove the hwmod static database and move it or
generate it from DT? Not sure when and how this will be done, but will it
affect the lockdep_set_class() way?

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


Re: [LKP] [sched/core] 9edfbfed3f5: +88.2% hackbench.time.involuntary_context_switches

2015-02-09 Thread Peter Zijlstra
On Mon, Feb 09, 2015 at 01:58:33PM +0800, Huang Ying wrote:
> FYI, we noticed the below changes on
> 
> git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git sched/core
> commit 9edfbfed3f544a7830d99b341f0c175995a02950 ("sched/core: Rework 
> rq->clock update skips")
> 
> 
> testbox/testcase/testparams: xps2/hackbench/performance-1600%-process-socket
> 
> cebde6d681aa45f9  9edfbfed3f544a7830d99b341f  
>   --  
>  %stddev %change %stddev
>  \  |\  
>1839273 ±  6% +88.2%3462337 ±  4%  
> hackbench.time.involuntary_context_switches
>   41965851 ±  5%  +5.6%   44307403 ±  1%  
> hackbench.time.voluntary_context_switches
>388 ± 39% -58.6%160 ± 10%  
> sched_debug.cfs_rq[1]:/.tg_load_contrib
>  12957 ± 14% -60.5%   5117 ± 11%  
> sched_debug.cfs_rq[2]:/.tg_load_avg
>  30505 ± 14% -57.7%  12905 ±  6%  
> sched_debug.cfs_rq[3]:/.tg_load_avg
>   2790 ± 24% -65.4%964 ± 32%  
> sched_debug.cfs_rq[3]:/.blocked_load_avg
>   2915 ± 23% -62.2%   1101 ± 29%  
> sched_debug.cfs_rq[3]:/.tg_load_contrib
>1839273 ±  6% +88.2%3462337 ±  4%  
> time.involuntary_context_switches
>   1474 ± 28% -61.7%565 ± 43%  
> sched_debug.cfs_rq[2]:/.tg_load_contrib
>  11830 ± 15% +63.0%  19285 ± 11%  sched_debug.cpu#4.sched_goidle
>  19319 ± 29% +91.1%  36913 ±  7%  sched_debug.cpu#3.sched_goidle
>   5899 ± 31% -35.6%   3801 ± 11%  
> sched_debug.cfs_rq[4]:/.blocked_load_avg
>   5999 ± 30% -34.5%   3929 ± 11%  
> sched_debug.cfs_rq[4]:/.tg_load_contrib
>  37884 ± 13% -33.5%  25207 ±  7%  
> sched_debug.cfs_rq[4]:/.tg_load_avg
> 229547 ±  5% +47.9% 339519 ±  5%  cpuidle.C1-NHM.usage
>  35712 ±  3% +31.7%  47036 ±  9%  cpuidle.C3-NHM.usage
>   5010 ±  9% -29.0%   3556 ± 20%  
> sched_debug.cfs_rq[6]:/.blocked_load_avg
>   5139 ±  9% -28.2%   3690 ± 19%  
> sched_debug.cfs_rq[6]:/.tg_load_contrib
>  49568 ±  6% +24.8%  61867 ±  7%  sched_debug.cpu#1.sched_goidle
>  26369 ± 35% -42.0%  15289 ± 29%  cpuidle.C6-NHM.usage
> 18 ± 16% +36.5% 25 ±  7%  sched_debug.cpu#4.nr_running
>   1.41 ± 12% -19.3%   1.14 ± 13%  
> perf-profile.cpu-cycles.sock_wfree.unix_destruct_scm.skb_release_head_state.skb_release_all.consume_skb
> 25 ± 15% +28.7% 32 ±  9%  sched_debug.cpu#3.nr_running
>   1.63 ± 11% -18.0%   1.34 ± 12%  
> perf-profile.cpu-cycles.unix_destruct_scm.skb_release_head_state.skb_release_all.consume_skb.unix_stream_recvmsg
>   0.57 ±  8%  +9.6%   0.62 ±  5%  turbostat.CPU%c1
>148 ± 11% -16.7%123 ±  7%  sched_debug.cfs_rq[1]:/.load
>109 ±  6% +17.1%128 ±  6%  sched_debug.cpu#6.cpu_load[0]
>   2.41 ±  8% -13.3%   2.09 ± 11%  
> perf-profile.cpu-cycles.skb_release_head_state.skb_release_all.consume_skb.unix_stream_recvmsg.sock_aio_read
>147 ± 12% -16.4%123 ±  7%  sched_debug.cpu#1.load
>111 ±  5% +15.4%129 ±  5%  sched_debug.cpu#6.cpu_load[2]
>110 ±  5% +14.9%127 ±  5%  
> sched_debug.cfs_rq[6]:/.runnable_load_avg
>112 ±  5% +14.5%128 ±  4%  sched_debug.cpu#6.cpu_load[3]
>113 ±  5% +13.2%128 ±  3%  sched_debug.cpu#6.cpu_load[4]
> 789953 ±  2% -10.8% 704528 ±  4%  sched_debug.cpu#3.avg_idle
>  15471 ±  5%  -7.7%  14278 ±  2%  sched_debug.cpu#5.curr->pid
>2675106 ± 10% +16.2%3109411 ±  1%  sched_debug.cpu#4.nr_switches
>2675140 ± 10% +16.2%3109440 ±  1%  sched_debug.cpu#4.sched_count
> 155201 ±  5% +14.6% 177901 ±  3%  softirqs.RCU
>   8.64 ±  6%  -9.6%   7.82 ±  5%  
> perf-profile.cpu-cycles.skb_release_all.consume_skb.unix_stream_recvmsg.sock_aio_read.sock_aio_read
>2658351 ± 11% +13.7%3021564 ±  2%  sched_debug.cpu#5.sched_count
>2658326 ± 11% +13.7%3021539 ±  2%  sched_debug.cpu#5.nr_switches
>  71443 ±  5%  +9.9%  78486 ±  0%  vmstat.system.cs
>   8209 ±  5%  +7.3%   8805 ±  0%  vmstat.system.in
> 

OK, so the interesting number is total runtime; I cannot find it.
Therefore I cannot say what if anything changed. This is just a bunch of
random numbers afaict.

> To reproduce:
> 
> apt-get install ruby ruby-oj

Mostly likely, you requiring ruby just means I will not be reproducing.

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


Re: [PATCH v3 1/3] lib: find_*_bit reimplementation

2015-02-09 Thread George Spelvin
Two more comments on the code.  Two minor, but one that
seems like a bug, so for now, it's

Nacked-by: George Spelvin  

Specifically, it seems like find_last_bit used to ignore trailing
garbage in the bitmap, but now will stop searching if the last word
contains some set bits not within size.


The minor one is that I don't think the first-word masking needs to
be conditional.  The general code works fine if the start is aligned
(HIGH_BITS_MASK just generates an all-ones mask), is quite quick, and
saves a test & conditional branch.

A second minor one is that the comment in include/linux/bitops.h has
an obvious typo, and should probably be fixed, too.

Here's a diff on top of yours with all my suggested changes, both
these two and the ones from my previous e-mail.

diff --git a/find_last_bit.c b/find_last_bit.c
index e67e970..106050f 100644
--- a/find_last_bit.c
+++ b/find_last_bit.c
@@ -13,6 +13,7 @@
  * 2 of the License, or (at your option) any later version.
  */
 
+#include 
 #include 
 #include 
 
diff --git a/find_next_bit.c b/find_next_bit.c
index 71aa497..9d01d4a 100644
--- a/find_next_bit.c
+++ b/find_next_bit.c
@@ -16,41 +16,34 @@
 #include 
 #include 
 
-#define HIGH_BITS_MASK(nr) (ULONG_MAX << (nr))
+#define HIGH_BITS_MASK(nr) (~0UL << (nr))
 
 #if !defined(find_next_bit) || !defined(find_next_zero_bit)
+
+/*
+ * This is a common helper function for find_next_bit and
+ * find_next_zero_bit.  The difference is the "invert" argument, which
+ * is XORed with each fetched word before searching it for one bits.
+ */
 static unsigned long _find_next_bit(const unsigned long *addr,
-   unsigned long nbits, unsigned long start, unsigned long mask)
+   unsigned long nbits, unsigned long start, unsigned long invert)
 {
unsigned long tmp;
 
if (start >= nbits)
return nbits;
 
-   tmp = addr[start / BITS_PER_LONG] ^ mask;
+   tmp = addr[start / BITS_PER_LONG] ^ invert;
 
/* Handle 1st word. */
-   if (!IS_ALIGNED(start, BITS_PER_LONG)) {
-   tmp &= HIGH_BITS_MASK(start % BITS_PER_LONG);
-   start = round_down(start, BITS_PER_LONG);
-   }
+   tmp &= HIGH_BITS_MASK(start % BITS_PER_LONG);
+   start = round_down(start, BITS_PER_LONG);
 
while (!tmp) {
start += BITS_PER_LONG;
if (start >= nbits)
return nbits;
-
-   /*
-* This is an equvalent for:
-*
-* tmp = find_set ? addr[start / BITS_PER_LONG]
-*  : ~addr[start / BITS_PER_LONG];
-*
-* but saves a branch condition.
-*
-* Thanks George Spelvin  for idea.
-*/
-   tmp = addr[start / BITS_PER_LONG] ^ mask;
+   tmp = addr[start / BITS_PER_LONG] ^ invert;
}
 
return min(start + __ffs(tmp), nbits);
@@ -105,7 +98,7 @@ unsigned long find_first_zero_bit(const unsigned long *addr, 
unsigned long size)
unsigned long idx;
 
for (idx = 0; idx * BITS_PER_LONG < size; idx++) {
-   if (addr[idx] != ULONG_MAX)
+   if (~addr[idx])
return min(idx * BITS_PER_LONG + ffz(addr[idx]), size);
}
 
@@ -130,14 +123,14 @@ static inline unsigned long ext2_swab(const unsigned long 
y)
 
 #if !defined(find_next_bit_le) || !defined(find_next_zero_bit_le)
 static unsigned long _find_next_bit_le(const unsigned long *addr,
-   unsigned long nbits, unsigned long start, unsigned long mask)
+   unsigned long nbits, unsigned long start, unsigned long invert)
 {
unsigned long tmp;
 
if (start >= nbits)
return nbits;
 
-   tmp = addr[start / BITS_PER_LONG] ^ mask;
+   tmp = addr[start / BITS_PER_LONG] ^ invert;
 
/* Handle 1st word. */
if (!IS_ALIGNED(start, BITS_PER_LONG)) {
@@ -150,7 +143,7 @@ static unsigned long _find_next_bit_le(const unsigned long 
*addr,
if (start >= nbits)
return nbits;
 
-   tmp = addr[start / BITS_PER_LONG] ^ mask;
+   tmp = addr[start / BITS_PER_LONG] ^ invert;
}
 
return min(start + __ffs(ext2_swab(tmp)), nbits);
diff --git a/include/linux/bitops.h b/include/linux/bitops.h
index 5d858e02..4a5e5934 100644
--- a/include/linux/bitops.h
+++ b/include/linux/bitops.h
@@ -218,9 +218,9 @@ static inline unsigned long __ffs64(u64 word)
 /**
  * find_last_bit - find the last set bit in a memory region
  * @addr: The address to start the search at
- * @size: The maximum size to search
+ * @size: The number of bits to search
  *
- * Returns the bit number of the first set bit, or size.
+ * Returns the bit number of the last set bit, or size if no bits are set.
  */
 extern unsigned long find_last_bit(const unsigned long *addr,
   uns

[GIT PULL] RCU tree changes for v3.20

2015-02-09 Thread Ingo Molnar
Linus,

Please pull the latest core-rcu-for-linus git tree from:

   git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git core-rcu-for-linus

   # HEAD: f49028292c13b958fdf4f36c8cc8119d0dde187b Merge branch 'for-mingo' of 
git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu into core/rcu

The main RCU changes in this cycle are:

- Documentation updates.

- Miscellaneous fixes.

- Preemptible-RCU fixes, including fixing an old bug in the
  interaction of RCU priority boosting and CPU hotplug.

- SRCU updates.

- RCU CPU stall-warning updates.

- RCU torture-test updates.

 Thanks,

Ingo

-->
Alexander Gordeev (1):
  rcu: Remove redundant rcu_is_cpu_rrupt_from_idle() from tiny RCU

Calvin Owens (1):
  ksoftirqd: Enable IRQs and call cond_resched() before poking RCU

David Hildenbrand (1):
  hotplugcpu: Avoid deadlocks by waking active_writer

Davidlohr Bueso (1):
  documentation: Fix smp typo in memory-barriers.txt

Lai Jiangshan (3):
  tiny_rcu: Directly force QS when call_rcu_[bh|sched]() on idle_task
  rcu: Remove "select IRQ_WORK" from config TREE_RCU
  rcu: Revert "Allow post-unlock reference for rt_mutex" to avoid 
priority-inversion

Miroslav Benes (1):
  rcu: Fix RCU CPU stall detection in tiny implementation

Paul E. McKenney (42):
  rcu: Make rcu_nmi_enter() handle nesting
  rcu: Fix invoke_rcu_callbacks() comment
  compiler: Allow 1- and 2-byte smp_load_acquire() and smp_store_release()
  rcu: Fix rcu_barrier() race that could result in too-short wait
  rcu: Protect rcu_boost() lockless accesses with ACCESS_ONCE()
  rcu: Rename "empty" to "empty_norm" in preparation for boost rework
  rcu: Abstract rcu_cleanup_dead_rnp() from rcu_cleanup_dead_cpu()
  rcu: Make rcu_read_unlock_special() propagate ->qsmaskinit bit clearing
  rcu: Don't migrate blocked tasks even if all corresponding CPUs offline
  rcu: Shorten irq-disable region in rcu_cleanup_dead_cpu()
  rcu: Make use of rcu_preempt_has_tasks()
  rcu: Don't spawn rcub kthreads on root rcu_node structure
  rcu: Don't initiate RCU priority boosting on root rcu_node
  rcu: Don't bother affinitying rcub kthreads away from offline CPUs
  rcu: Note quiescent state when CPU goes offline
  rcu: Don't scan root rcu_node structure for stalled tasks
  rcu: Remove redundant callback-list initialization
  rcu: Expand SRCU ->completed to 64 bits
  rcu: Combine DEFINE_SRCU() and DEFINE_STATIC_SRCU()
  rcu: Set default to RCU_CPU_STALL_INFO=y
  rcutorture: Add checks for stall ending before dump start
  rcu: Make RCU_CPU_STALL_INFO include number of fqs attempts
  rcu: Improve diagnostics for spurious RCU CPU stall warnings
  rcu: Handle gpnum/completed wrap while dyntick idle
  documentation: Record limitations of bitfields and small variables
  rcutorture: Issue warnings on close calls due to Reader Batch blows
  rcu: Make _batches_completed() functions return unsigned long
  rcutorture: Make build-output parsing correctly flag RCU's warnings
  rcutorture: Use unsigned for Reader Batch computations
  rcu: Provide rcu_batches_completed_sched() for TINY_RCU
  rcutorture: Drop rcu_torture_completed() and friends
  rcu: Remove redundant rcu_batches_completed() declaration
  rcutorture: Check from beginning to end of grace period
  rcutorture: Handle different mpstat versions
  torture: Add "-enable-kvm -soundhw pcspk" to qemu command line
  torture: Flag console.log file to prevent holdovers from earlier runs
  rcutorture: Add more diagnostics in rcu_barrier() test failure case
  ksoftirqd: Use new cond_resched_rcu_qs() function
  rcu: Optionally run grace-period kthreads at real-time priority
  rcu: Make cond_resched_rcu_qs() apply to normal RCU flavors
  rcu: Add GP-kthread-starvation checks to CPU stall warnings
  rcu: Initialize tiny RCU stall-warning timeouts at boot

Pranith Kumar (2):
  rcupdate: Replace smp_read_barrier_depends() with lockless_dereference()
  rcu: Make SRCU optional by using CONFIG_SRCU

Xie XiuQi (1):
  documentation: Update sysfs path for rcu_cpu_stall_timeout

Ying Xue (1):
  rculist: Fix sparse warning


 Documentation/RCU/stallwarn.txt|  16 +-
 Documentation/RCU/trace.txt|  32 +-
 Documentation/memory-barriers.txt  |  46 ++-
 arch/arm/kvm/Kconfig   |   1 +
 arch/arm64/kvm/Kconfig |   1 +
 arch/mips/kvm/Kconfig  |   1 +
 arch/powerpc/kvm/Kconfig   |   1 +
 arch/s390/kvm/Kconfig  |   1 +
 arch/tile/kvm/Kconfig  |   1 +
 arch/x86/Kconfig   |   1 +
 arch/x86/kvm/Kconfig

Re: [PATCH] net:ethernet:intel:Remove outdated fix me comment in the function,gb_acquire_swfw_sync_i210

2015-02-09 Thread Jeff Kirsher
On Mon, 2015-02-09 at 02:17 -0500, Andrej Manduch wrote:
> Hi,
> 
> Can you please leave full patch with git diff when you're replying to
> Nicks e-mails? Nick is banned in *@vger.kernel.org so we cannot see his
> patches and rest of the world is seeing only replyies to his e-mail. And
> it's really hard to test anything when we don't see changes.

Oh, I am well aware of Nick's current ban on @vger,kernel.org mailing
lists.  If you want to see Nick's patch, feel free to view his patch on
my queue tree:
https://git.kernel.org/cgit/linux/kernel/git/jkirsher/queue.git/

It is the top most patch (i.e. last one applied to my queue).

> 
> On 02/08/2015 08:21 PM, Jeff Kirsher wrote:
> > On Sun, 2015-02-08 at 00:21 -0500, Nicholas Krause wrote:
> >> Removes the outdated fix me comment in the
> >> function,gb_acquire_swfw_sync_i210
> >> for setting the variables, i and timeout to the intended correct
> >> values for
> >> the function,gb_acquire_swfw_sync_i210 to function correctly. This
> >> comment is
> >> no longer due to these values having been no changed in the last few
> >> years and
> >> no known issues have been found for these variables being set to their
> >> current
> >> values. Due to this the comment can now be removed as the values set
> >> for these
> >> variables are known to be correct after years of no known issues or
> >> bugs related
> >> to their current values.
> >>
> >> Signed-off-by: Nicholas Krause 
> >> ---
> >>  drivers/net/ethernet/intel/igb/e1000_i210.c | 2 +-
> >>  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > Thank Nick, I will add your patch to my queue.
> > 
> 




signature.asc
Description: This is a digitally signed message part


Re: [LKP] [genetlink] WARNING: CPU: 0 PID: 804 at net/netlink/genetlink.c:1037 genl_unbind+0xc0/0xd0()

2015-02-09 Thread Huang Ying
I found the test summary table for the test, just FYI.

+---+++
|   | f555f3d76a | 5ad6300524 |
+---+++
| boot_successes| 10 | 21 |
| boot_failures | 36 | 25 |
| WARNING:at_net/netlink/genetlink.c:#genl_unbind() | 36 | 3  |
+---+++

Best Regards,
Huang, Ying

On Mon, 2015-02-09 at 16:07 +0800, Huang Ying wrote:
> FYI, we noticed the below changes on
> 
> commit 5ad6300524c0332ac67e912c20d6e5cf262ba58f ("genetlink: disallow 
> subscribing to unknown mcast groups")
> 
> Although the frequency decreased a lot, from 100% to about 8.33%, we still 
> find the warning in dmesg after applying the commit.
> 
> [  299.872857] [ cut here ]
> [  300.039960] WARNING: CPU: 0 PID: 804 at net/netlink/genetlink.c:1037 
> genl_unbind+0xc0/0xd0()
> [  300.360780] CPU: 0 PID: 804 Comm: trinity-main Not tainted 
> 3.19.0-rc4-00160-g5ad6300 #11
> [  300.360783] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
> [  300.360793]  823ad820 88001556be68 81d86b84 
> 0065
> [  300.360795]   88001556bea8 810c2f30 
> 82635dc0
> [  300.360796]   82635dc0 0001 
> 836d7000
> [  300.360799] Call Trace:
> [  300.361185]  [] dump_stack+0x4f/0x7b
> [  300.361254]  [] warn_slowpath_common+0x80/0xc0
> [  300.361256]  [] warn_slowpath_null+0x15/0x20
> [  300.361270]  [] genl_unbind+0xc0/0xd0
> [  300.361272]  [] netlink_setsockopt+0x24b/0x270
> [  300.361279]  [] SyS_setsockopt+0x5e/0xc0
> [  300.361285]  [] system_call_fastpath+0x12/0x17
> [  300.361296] ---[ end trace 5d4dac2c7bb8ca45 ]---
> 
> Thanks,
> Huang, Ying
> 
> ___
> LKP mailing list
> l...@linux.intel.com


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


[PATCH 3.10 10/17] ext4: prevent bugon on race between write/fcntl

2015-02-09 Thread Greg Kroah-Hartman
3.10-stable review patch.  If anyone has any objections, please let me know.

--

From: Dmitry Monakhov 

commit a41537e69b4aa43f0fea02498c2595a81267383b upstream.

O_DIRECT flags can be toggeled via fcntl(F_SETFL). But this value checked
twice inside ext4_file_write_iter() and __generic_file_write() which
result in BUG_ON inside ext4_direct_IO.

Let's initialize iocb->private unconditionally.

TESTCASE: xfstest:generic/036  https://patchwork.ozlabs.org/patch/402445/

#TYPICAL STACK TRACE:
kernel BUG at fs/ext4/inode.c:2960!
invalid opcode:  [#1] SMP
Modules linked in: brd iTCO_wdt lpc_ich mfd_core igb ptp dm_mirror 
dm_region_hash dm_log dm_mod
CPU: 6 PID: 5505 Comm: aio-dio-fcntl-r Not tainted 3.17.0-rc2-00176-gff5c017 
#161
Hardware name: Intel Corporation W2600CR/W2600CR, BIOS 
SE5C600.86B.99.99.x028.061320111235 06/13/2011
task: 88080e95a7c0 ti: 88080f908000 task.ti: 88080f908000
RIP: 0010:[]  [] ext4_direct_IO+0x162/0x3d0
RSP: 0018:88080f90bb58  EFLAGS: 00010246
RAX: 0400 RBX: 88080fdb2a28 RCX: a802c818
RDX: 0408 RSI: 88080d8aeb80 RDI: 0001
RBP: 88080f90bbc8 R08:  R09: 1581
R10:  R11:  R12: 88080d8aeb80
R13: 88080f90bbf8 R14: 88080fdb28c8 R15: 88080fdb2a28
FS:  7f23b2055700() GS:88081840() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 7f23b2045000 CR3: 00080cedf000 CR4: 000407e0
Stack:
 88080f90bb98  7ffe 88080fdb2c30
 0200 0200 0001 0200
 88080f90bbc8 88080fdb2c30 88080f90be08 0200
Call Trace:
 [] generic_file_direct_write+0xed/0x180
 [] __generic_file_write_iter+0x222/0x370
 [] ext4_file_write_iter+0x34b/0x400
 [] ? aio_run_iocb+0x239/0x410
 [] ? aio_run_iocb+0x239/0x410
 [] ? local_clock+0x25/0x30
 [] ? __lock_acquire+0x274/0x700
 [] ? ext4_unwritten_wait+0xb0/0xb0
 [] aio_run_iocb+0x286/0x410
 [] ? local_clock+0x25/0x30
 [] ? lock_release_holdtime+0x29/0x190
 [] ? lookup_ioctx+0x4b/0xf0
 [] do_io_submit+0x55b/0x740
 [] ? do_io_submit+0x3ca/0x740
 [] SyS_io_submit+0x10/0x20
 [] system_call_fastpath+0x16/0x1b
Code: 01 48 8b 80 f0 01 00 00 48 8b 18 49 8b 45 10 0f 85 f1 01 00 00 48 03 45 
c8 48 3b 43 48 0f 8f e3 01 00 00 49 83 7c
24 18 00 75 04 <0f> 0b eb fe f0 ff 83 ec 01 00 00 49 8b 44 24 18 8b 00 85 c0 89
RIP  [] ext4_direct_IO+0x162/0x3d0
 RSP 

Reported-by: Sasha Levin 
Signed-off-by: Theodore Ts'o 
Signed-off-by: Dmitry Monakhov 
[hujianyang: Backported to 3.10
 - Move initialization of iocb->private to ext4_file_write() as we don't
   have ext4_file_write_iter(), which is introduced by commit 9b884164.
 - Adjust context to make 'overwrite' changes apply to ext4_file_dio_write()
   as ext4_file_dio_write() is not move into ext4_file_write()]
Signed-off-by: hujianyang 
Signed-off-by: Greg Kroah-Hartman 

---
 fs/ext4/file.c |8 
 1 file changed, 4 insertions(+), 4 deletions(-)

--- a/fs/ext4/file.c
+++ b/fs/ext4/file.c
@@ -100,7 +100,7 @@ ext4_file_dio_write(struct kiocb *iocb,
struct blk_plug plug;
int unaligned_aio = 0;
ssize_t ret;
-   int overwrite = 0;
+   int *overwrite = iocb->private;
size_t length = iov_length(iov, nr_segs);
 
if (ext4_test_inode_flag(inode, EXT4_INODE_EXTENTS) &&
@@ -118,8 +118,6 @@ ext4_file_dio_write(struct kiocb *iocb,
mutex_lock(&inode->i_mutex);
blk_start_plug(&plug);
 
-   iocb->private = &overwrite;
-
/* check whether we do a DIO overwrite or not */
if (ext4_should_dioread_nolock(inode) && !unaligned_aio &&
!file->f_mapping->nrpages && pos + length <= i_size_read(inode)) {
@@ -143,7 +141,7 @@ ext4_file_dio_write(struct kiocb *iocb,
 * So we should check these two conditions.
 */
if (err == len && (map.m_flags & EXT4_MAP_MAPPED))
-   overwrite = 1;
+   *overwrite = 1;
}
 
ret = __generic_file_aio_write(iocb, iov, nr_segs, &iocb->ki_pos);
@@ -170,6 +168,7 @@ ext4_file_write(struct kiocb *iocb, cons
 {
struct inode *inode = file_inode(iocb->ki_filp);
ssize_t ret;
+   int overwrite = 0;
 
/*
 * If we have encountered a bitmap-format file, the size limit
@@ -190,6 +189,7 @@ ext4_file_write(struct kiocb *iocb, cons
}
}
 
+   iocb->private = &overwrite;
if (unlikely(iocb->ki_filp->f_flags & O_DIRECT))
ret = ext4_file_dio_write(iocb, iov, nr_segs, pos);
else


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


[PATCH 3.10 01/17] gpio: sysfs: fix memory leak in gpiod_export_link

2015-02-09 Thread Greg Kroah-Hartman
3.10-stable review patch.  If anyone has any objections, please let me know.

--

From: Johan Hovold 

commit 0f303db08df0df9bd0966443ad6001e63960af16 upstream.

Fix memory leak in the gpio sysfs interface due to failure to drop
reference to device returned by class_find_device when creating a link.

Fixes: a4177ee7f1a8 ("gpiolib: allow exported GPIO nodes to be named using 
sysfs links")
Signed-off-by: Johan Hovold 
Signed-off-by: Linus Walleij 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/gpio/gpiolib.c |1 +
 1 file changed, 1 insertion(+)

--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -874,6 +874,7 @@ static int gpiod_export_link(struct devi
if (tdev != NULL) {
status = sysfs_create_link(&dev->kobj, &tdev->kobj,
name);
+   put_device(tdev);
} else {
status = -ENODEV;
}


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


[PATCH 3.10 13/17] ASoC: sgtl5000: add delay before first I2C access

2015-02-09 Thread Greg Kroah-Hartman
3.10-stable review patch.  If anyone has any objections, please let me know.

--

From: Eric Nelson 

commit 58cc9c9a175885bbf6bae3acf18233d0a8229a84 upstream.

To quote from section 1.3.1 of the data sheet:
The SGTL5000 has an internal reset that is deasserted
8 SYS_MCLK cycles after all power rails have been brought
up. After this time, communication can start

...
1.0us represents 8 SYS_MCLK cycles at the minimum 8.0 MHz SYS_MCLK.

Signed-off-by: Eric Nelson 
Reviewed-by: Fabio Estevam 
Signed-off-by: Mark Brown 
Signed-off-by: Greg Kroah-Hartman 

---
 sound/soc/codecs/sgtl5000.c |3 +++
 1 file changed, 3 insertions(+)

--- a/sound/soc/codecs/sgtl5000.c
+++ b/sound/soc/codecs/sgtl5000.c
@@ -1242,6 +1242,9 @@ static int sgtl5000_enable_regulators(st
/* wait for all power rails bring up */
udelay(10);
 
+   /* Need 8 clocks before I2C accesses */
+   udelay(1);
+
/* read chip information */
reg = snd_soc_read(codec, SGTL5000_CHIP_ID);
if (((reg & SGTL5000_PARTID_MASK) >> SGTL5000_PARTID_SHIFT) !=


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


[PATCH 3.10 08/17] nilfs2: fix deadlock of segment constructor over I_SYNC flag

2015-02-09 Thread Greg Kroah-Hartman
3.10-stable review patch.  If anyone has any objections, please let me know.

--

From: Ryusuke Konishi 

commit 7ef3ff2fea8bf5e4a21cef47ad87710a3d0fdb52 upstream.

Nilfs2 eventually hangs in a stress test with fsstress program.  This
issue was caused by the following deadlock over I_SYNC flag between
nilfs_segctor_thread() and writeback_sb_inodes():

  nilfs_segctor_thread()
nilfs_segctor_thread_construct()
  nilfs_segctor_unlock()
nilfs_dispose_list()
  iput()
iput_final()
  evict()
inode_wait_for_writeback()  * wait for I_SYNC flag

  writeback_sb_inodes()
 * set I_SYNC flag on inode->i_state
__writeback_single_inode()
  do_writepages()
nilfs_writepages()
  nilfs_construct_dsync_segment()
nilfs_segctor_sync()
   * wait for completion of segment constructor
inode_sync_complete()
   * clear I_SYNC flag after __writeback_single_inode() completed

writeback_sb_inodes() calls do_writepages() for dirty inodes after
setting I_SYNC flag on inode->i_state.  do_writepages() in turn calls
nilfs_writepages(), which can run segment constructor and wait for its
completion.  On the other hand, segment constructor calls iput(), which
can call evict() and wait for the I_SYNC flag on
inode_wait_for_writeback().

Since segment constructor doesn't know when I_SYNC will be set, it
cannot know whether iput() will block or not unless inode->i_nlink has a
non-zero count.  We can prevent evict() from being called in iput() by
implementing sop->drop_inode(), but it's not preferable to leave inodes
with i_nlink == 0 for long periods because it even defers file
truncation and inode deallocation.  So, this instead resolves the
deadlock by calling iput() asynchronously with a workqueue for inodes
with i_nlink == 0.

Signed-off-by: Ryusuke Konishi 
Cc: Al Viro 
Tested-by: Ryusuke Konishi 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman 

---
 fs/nilfs2/nilfs.h   |2 --
 fs/nilfs2/segment.c |   44 +++-
 fs/nilfs2/segment.h |5 +
 3 files changed, 44 insertions(+), 7 deletions(-)

--- a/fs/nilfs2/nilfs.h
+++ b/fs/nilfs2/nilfs.h
@@ -141,7 +141,6 @@ enum {
  * @ti_save: Backup of journal_info field of task_struct
  * @ti_flags: Flags
  * @ti_count: Nest level
- * @ti_garbage:List of inode to be put when releasing semaphore
  */
 struct nilfs_transaction_info {
u32 ti_magic;
@@ -150,7 +149,6 @@ struct nilfs_transaction_info {
   one of other filesystems has a bug. */
unsigned short  ti_flags;
unsigned short  ti_count;
-   struct list_headti_garbage;
 };
 
 /* ti_magic */
--- a/fs/nilfs2/segment.c
+++ b/fs/nilfs2/segment.c
@@ -305,7 +305,6 @@ static void nilfs_transaction_lock(struc
ti->ti_count = 0;
ti->ti_save = cur_ti;
ti->ti_magic = NILFS_TI_MAGIC;
-   INIT_LIST_HEAD(&ti->ti_garbage);
current->journal_info = ti;
 
for (;;) {
@@ -332,8 +331,6 @@ static void nilfs_transaction_unlock(str
 
up_write(&nilfs->ns_segctor_sem);
current->journal_info = ti->ti_save;
-   if (!list_empty(&ti->ti_garbage))
-   nilfs_dispose_list(nilfs, &ti->ti_garbage, 0);
 }
 
 static void *nilfs_segctor_map_segsum_entry(struct nilfs_sc_info *sci,
@@ -746,6 +743,15 @@ static void nilfs_dispose_list(struct th
}
 }
 
+static void nilfs_iput_work_func(struct work_struct *work)
+{
+   struct nilfs_sc_info *sci = container_of(work, struct nilfs_sc_info,
+sc_iput_work);
+   struct the_nilfs *nilfs = sci->sc_super->s_fs_info;
+
+   nilfs_dispose_list(nilfs, &sci->sc_iput_queue, 0);
+}
+
 static int nilfs_test_metadata_dirty(struct the_nilfs *nilfs,
 struct nilfs_root *root)
 {
@@ -1899,8 +1905,8 @@ static int nilfs_segctor_collect_dirty_f
 static void nilfs_segctor_drop_written_files(struct nilfs_sc_info *sci,
 struct the_nilfs *nilfs)
 {
-   struct nilfs_transaction_info *ti = current->journal_info;
struct nilfs_inode_info *ii, *n;
+   int defer_iput = false;
 
spin_lock(&nilfs->ns_inode_lock);
list_for_each_entry_safe(ii, n, &sci->sc_dirty_files, i_dirty) {
@@ -1911,9 +1917,24 @@ static void nilfs_segctor_drop_written_f
clear_bit(NILFS_I_BUSY, &ii->i_state);
brelse(ii->i_bh);
ii->i_bh = NULL;
-   list_move_tail(&ii->i_dirty, &ti->ti_garbage);
+   list_del_init(&ii->i_dirty);
+   if (!ii->vfs_inode.i_nlink) {
+   /*
+* Defer calling iput() to avoid a deadlock
+* over I_SYNC flag for inodes with i_nlink == 0
+   

[PATCH 3.14 10/20] lib/checksum.c: fix carry in csum_tcpudp_nofold

2015-02-09 Thread Greg Kroah-Hartman
3.14-stable review patch.  If anyone has any objections, please let me know.

--

From: karl beldan 

commit 150ae0e94634714b23919f0c333fee28a5b199d5 upstream.

The carry from the 64->32bits folding was dropped, e.g with:
saddr=0x daddr=0xFFFF len=0x proto=0 sum=1,
csum_tcpudp_nofold returned 0 instead of 1.

Signed-off-by: Karl Beldan 
Cc: Al Viro 
Cc: Eric Dumazet 
Cc: Arnd Bergmann 
Cc: Mike Frysinger 
Cc: net...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Eric Dumazet 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman 

---
 lib/checksum.c |   12 ++--
 1 file changed, 10 insertions(+), 2 deletions(-)

--- a/lib/checksum.c
+++ b/lib/checksum.c
@@ -47,6 +47,15 @@ static inline unsigned short from32to16(
return x;
 }
 
+static inline u32 from64to32(u64 x)
+{
+   /* add up 32-bit and 32-bit for 32+c bit */
+   x = (x & 0x) + (x >> 32);
+   /* add up carry.. */
+   x = (x & 0x) + (x >> 32);
+   return (u32)x;
+}
+
 static unsigned int do_csum(const unsigned char *buff, int len)
 {
int odd;
@@ -195,8 +204,7 @@ __wsum csum_tcpudp_nofold(__be32 saddr,
 #else
s += (proto + len) << 8;
 #endif
-   s += (s >> 32);
-   return (__force __wsum)s;
+   return (__force __wsum)from64to32(s);
 }
 EXPORT_SYMBOL(csum_tcpudp_nofold);
 #endif


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


[PATCH 3.14 13/20] arm64: Fix up /proc/cpuinfo

2015-02-09 Thread Greg Kroah-Hartman
3.14-stable review patch.  If anyone has any objections, please let me know.

--

From: Mark Rutland 

commit 44b82b7700d05a52cd983799d3ecde1a976b3bed upstream.

Commit d7a49086f263164a (arm64: cpuinfo: print info for all CPUs)
attempted to clean up /proc/cpuinfo, but due to concerns regarding
further changes was reverted in commit 5e39977edf6500fd (Revert "arm64:
cpuinfo: print info for all CPUs").

There are two major issues with the arm64 /proc/cpuinfo format
currently:

* The "Features" line describes (only) the 64-bit hwcaps, which is
  problematic for some 32-bit applications which attempt to parse it. As
  the same names are used for analogous ISA features (e.g. aes) despite
  these generally being architecturally unrelated, it is not possible to
  simply append the 64-bit and 32-bit hwcaps in a manner that might not
  be misleading to some applications.

  Various potential solutions have appeared in vendor kernels. Typically
  the format of the Features line varies depending on whether the task
  is 32-bit.

* Information is only printed regarding a single CPU. This does not
  match the ARM format, and does not provide sufficient information in
  big.LITTLE systems where CPUs are heterogeneous. The CPU information
  printed is queried from the current CPU's registers, which is racy
  w.r.t. cross-cpu migration.

This patch attempts to solve these issues. The following changes are
made:

* When a task with a LINUX32 personality attempts to read /proc/cpuinfo,
  the "Features" line contains the decoded 32-bit hwcaps, as with the
  arm port. Otherwise, the decoded 64-bit hwcaps are shown. This aligns
  with the behaviour of COMPAT_UTS_MACHINE and COMPAT_ELF_PLATFORM. In
  the absense of compat support, the Features line is empty.

  The set of hwcaps injected into a task's auxval are unaffected.

* Properties are printed per-cpu, as with the ARM port. The per-cpu
  information is queried from pre-recorded cpu information (as used by
  the sanity checks).

* As with the previous attempt at fixing up /proc/cpuinfo, the hardware
  field is removed. The only users so far are 32-bit applications tied
  to particular boards, so no portable applications should be affected,
  and this should prevent future tying to particular boards.

The following differences remain:

* No model_name is printed, as this cannot be queried from the hardware
  and cannot be provided in a stable fashion. Use of the CPU
  {implementor,variant,part,revision} fields is sufficient to identify a
  CPU and is portable across arm and arm64.

* The following system-wide properties are not provided, as they are not
  possible to provide generally. Programs relying on these are already
  tied to particular (32-bit only) boards:
  - Hardware
  - Revision
  - Serial

No software has yet been identified for which these remaining
differences are problematic.

Cc: Greg Hackmann 
Cc: Ian Campbell 
Cc: Serban Constantinescu 
Cc: Will Deacon 
Cc: cross-dis...@lists.linaro.org
Cc: linux-...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Acked-by: Catalin Marinas 
Signed-off-by: Mark Rutland 
Signed-off-by: Will Deacon 
Signed-off-by: Greg Kroah-Hartman 

---
 arch/arm64/include/asm/cputype.h |2 
 arch/arm64/kernel/setup.c|   99 ---
 arch/arm64/kernel/smp.c  |5 +
 3 files changed, 80 insertions(+), 26 deletions(-)

--- a/arch/arm64/include/asm/cputype.h
+++ b/arch/arm64/include/asm/cputype.h
@@ -77,6 +77,8 @@ static inline u32 __attribute_const__ re
return read_cpuid(CTR_EL0);
 }
 
+void cpuinfo_store_cpu(void);
+
 #endif /* __ASSEMBLY__ */
 
 #endif
--- a/arch/arm64/kernel/setup.c
+++ b/arch/arm64/kernel/setup.c
@@ -41,6 +41,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -73,7 +74,6 @@ unsigned int compat_elf_hwcap __read_mos
 #endif
 
 static const char *cpu_name;
-static const char *machine_name;
 phys_addr_t __fdt_pointer __initdata;
 
 /*
@@ -193,6 +193,19 @@ static void __init smp_build_mpidr_hash(
 }
 #endif
 
+struct cpuinfo_arm64 {
+   struct cpu  cpu;
+   u32 reg_midr;
+};
+
+static DEFINE_PER_CPU(struct cpuinfo_arm64, cpu_data);
+
+void cpuinfo_store_cpu(void)
+{
+   struct cpuinfo_arm64 *info = this_cpu_ptr(&cpu_data);
+   info->reg_midr = read_cpuid_id();
+}
+
 static void __init setup_processor(void)
 {
struct cpu_info *cpu_info;
@@ -213,6 +226,8 @@ static void __init setup_processor(void)
sprintf(init_utsname()->machine, ELF_PLATFORM);
elf_hwcap = 0;
 
+   cpuinfo_store_cpu();
+
/*
 * ID_AA64ISAR0_EL1 contains 4-bit wide signed feature blocks.
 * The blocks we test below represent incremental functionality
@@ -257,8 +272,6 @@ static void __init setup_machine_fdt(phy
while (true)
cpu_relax();
}
-
-   machine_name = of_flat_dt_get_machine_name();
 

[PATCH 3.10 14/17] ALSA: ak411x: Fix stall in work callback

2015-02-09 Thread Greg Kroah-Hartman
3.10-stable review patch.  If anyone has any objections, please let me know.

--

From: Takashi Iwai 

commit 4161b4505f1690358ac0a9ee59845a7887336b21 upstream.

When ak4114 work calls its callback and the callback invokes
ak4114_reinit(), it stalls due to flush_delayed_work().  For avoiding
this, control the reentrance by introducing a refcount.  Also
flush_delayed_work() is replaced with cancel_delayed_work_sync().

The exactly same bug is present in ak4113.c and fixed as well.

Reported-by: Pavel Hofman 
Acked-by: Jaroslav Kysela 
Tested-by: Pavel Hofman 
Signed-off-by: Takashi Iwai 
Signed-off-by: Greg Kroah-Hartman 

---
 include/sound/ak4113.h   |2 +-
 include/sound/ak4114.h   |2 +-
 sound/i2c/other/ak4113.c |   17 -
 sound/i2c/other/ak4114.c |   18 --
 4 files changed, 18 insertions(+), 21 deletions(-)

--- a/include/sound/ak4113.h
+++ b/include/sound/ak4113.h
@@ -286,7 +286,7 @@ struct ak4113 {
ak4113_write_t *write;
ak4113_read_t *read;
void *private_data;
-   unsigned int init:1;
+   atomic_t wq_processing;
spinlock_t lock;
unsigned char regmap[AK4113_WRITABLE_REGS];
struct snd_kcontrol *kctls[AK4113_CONTROLS];
--- a/include/sound/ak4114.h
+++ b/include/sound/ak4114.h
@@ -168,7 +168,7 @@ struct ak4114 {
ak4114_write_t * write;
ak4114_read_t * read;
void * private_data;
-   unsigned int init: 1;
+   atomic_t wq_processing;
spinlock_t lock;
unsigned char regmap[7];
unsigned char txcsb[5];
--- a/sound/i2c/other/ak4113.c
+++ b/sound/i2c/other/ak4113.c
@@ -56,8 +56,7 @@ static inline unsigned char reg_read(str
 
 static void snd_ak4113_free(struct ak4113 *chip)
 {
-   chip->init = 1; /* don't schedule new work */
-   mb();
+   atomic_inc(&chip->wq_processing);   /* don't schedule new work */
cancel_delayed_work_sync(&chip->work);
kfree(chip);
 }
@@ -89,6 +88,7 @@ int snd_ak4113_create(struct snd_card *c
chip->write = write;
chip->private_data = private_data;
INIT_DELAYED_WORK(&chip->work, ak4113_stats);
+   atomic_set(&chip->wq_processing, 0);
 
for (reg = 0; reg < AK4113_WRITABLE_REGS ; reg++)
chip->regmap[reg] = pgm[reg];
@@ -139,13 +139,11 @@ static void ak4113_init_regs(struct ak41
 
 void snd_ak4113_reinit(struct ak4113 *chip)
 {
-   chip->init = 1;
-   mb();
-   flush_delayed_work(&chip->work);
+   if (atomic_inc_return(&chip->wq_processing) == 1)
+   cancel_delayed_work_sync(&chip->work);
ak4113_init_regs(chip);
/* bring up statistics / event queing */
-   chip->init = 0;
-   if (chip->kctls[0])
+   if (atomic_dec_and_test(&chip->wq_processing))
schedule_delayed_work(&chip->work, HZ / 10);
 }
 EXPORT_SYMBOL_GPL(snd_ak4113_reinit);
@@ -632,8 +630,9 @@ static void ak4113_stats(struct work_str
 {
struct ak4113 *chip = container_of(work, struct ak4113, work.work);
 
-   if (!chip->init)
+   if (atomic_inc_return(&chip->wq_processing) == 1)
snd_ak4113_check_rate_and_errors(chip, chip->check_flags);
 
-   schedule_delayed_work(&chip->work, HZ / 10);
+   if (atomic_dec_and_test(&chip->wq_processing))
+   schedule_delayed_work(&chip->work, HZ / 10);
 }
--- a/sound/i2c/other/ak4114.c
+++ b/sound/i2c/other/ak4114.c
@@ -66,8 +66,7 @@ static void reg_dump(struct ak4114 *ak41
 
 static void snd_ak4114_free(struct ak4114 *chip)
 {
-   chip->init = 1; /* don't schedule new work */
-   mb();
+   atomic_inc(&chip->wq_processing);   /* don't schedule new work */
cancel_delayed_work_sync(&chip->work);
kfree(chip);
 }
@@ -100,6 +99,7 @@ int snd_ak4114_create(struct snd_card *c
chip->write = write;
chip->private_data = private_data;
INIT_DELAYED_WORK(&chip->work, ak4114_stats);
+   atomic_set(&chip->wq_processing, 0);
 
for (reg = 0; reg < 7; reg++)
chip->regmap[reg] = pgm[reg];
@@ -152,13 +152,11 @@ static void ak4114_init_regs(struct ak41
 
 void snd_ak4114_reinit(struct ak4114 *chip)
 {
-   chip->init = 1;
-   mb();
-   flush_delayed_work(&chip->work);
+   if (atomic_inc_return(&chip->wq_processing) == 1)
+   cancel_delayed_work_sync(&chip->work);
ak4114_init_regs(chip);
/* bring up statistics / event queing */
-   chip->init = 0;
-   if (chip->kctls[0])
+   if (atomic_dec_and_test(&chip->wq_processing))
schedule_delayed_work(&chip->work, HZ / 10);
 }
 
@@ -612,10 +610,10 @@ static void ak4114_stats(struct work_str
 {
struct ak4114 *chip = container_of(work, struct ak4114, work.work);
 
-   if (!chip->init)
+   if (atomic_inc_return(&chip->wq_processing) == 1)
snd_ak4114_check_rate_and_errors(chip, chip->check_flags);
-
-   schedule_delayed_work(&chip->wo

[PATCH 3.18 11/39] MIPS: IRQ: Fix disable_irq on CPU IRQs

2015-02-09 Thread Greg Kroah-Hartman
3.18-stable review patch.  If anyone has any objections, please let me know.

--

From: Felix Fietkau 

commit a3e6c1eff54878506b2dddcc202df9cc8180facb upstream.

If the irq_chip does not define .irq_disable, any call to disable_irq
will defer disabling the IRQ until it fires while marked as disabled.
This assumes that the handler function checks for this condition, which
handle_percpu_irq does not. In this case, calling disable_irq leads to
an IRQ storm, if the interrupt fires while disabled.

This optimization is only useful when disabling the IRQ is slow, which
is not true for the MIPS CPU IRQ.

Disable this optimization by implementing .irq_disable and .irq_enable

Signed-off-by: Felix Fietkau 
Cc: linux-m...@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/8949/
Signed-off-by: Ralf Baechle 
Signed-off-by: Greg Kroah-Hartman 

---
 arch/mips/kernel/irq_cpu.c |4 
 1 file changed, 4 insertions(+)

--- a/arch/mips/kernel/irq_cpu.c
+++ b/arch/mips/kernel/irq_cpu.c
@@ -56,6 +56,8 @@ static struct irq_chip mips_cpu_irq_cont
.irq_mask_ack   = mask_mips_irq,
.irq_unmask = unmask_mips_irq,
.irq_eoi= unmask_mips_irq,
+   .irq_disable= mask_mips_irq,
+   .irq_enable = unmask_mips_irq,
 };
 
 /*
@@ -92,6 +94,8 @@ static struct irq_chip mips_mt_cpu_irq_c
.irq_mask_ack   = mips_mt_cpu_irq_ack,
.irq_unmask = unmask_mips_irq,
.irq_eoi= unmask_mips_irq,
+   .irq_disable= mask_mips_irq,
+   .irq_enable = unmask_mips_irq,
 };
 
 void __init mips_cpu_irq_init(void)


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


[PATCH 3.18 16/39] ARM: 8299/1: mm: ensure local active ASID is marked as allocated on rollover

2015-02-09 Thread Greg Kroah-Hartman
3.18-stable review patch.  If anyone has any objections, please let me know.

--

From: Will Deacon 

commit 8e64806672466392acf19e14427d1c29df3e58b9 upstream.

Commit e1a5848e3398 ("ARM: 7924/1: mm: don't bother with reserved ttbr0
when running with LPAE") removed the use of the reserved TTBR0 value
for LPAE systems, since the ASID is held in the TTBR and can be updated
atomicly with the pgd of the next mm.

Unfortunately, this patch forgot to update flush_context, which
deliberately avoids marking the local active ASID as allocated, since we
used to switch via ASID zero and didn't need to allocate the ASID of
the previous mm. The side-effect of this is that we can allocate the
same ASID to the next mm and, between flushing the local TLB and updating
TTBR0, we can perform speculative TLB fills for userspace nG mappings
using the page table of the previous mm.

The consequence of this is that the next mm can erroneously hit some
mappings of the previous mm. Note that this was made significantly
harder to hit by a391263cd84e ("ARM: 8203/1: mm: try to re-use old ASID
assignments following a rollover") but is still theoretically possible.

This patch fixes the problem by removing the code from flush_context
that forces the allocated ASID to zero for the local CPU. Many thanks
to the Broadcom guys for tracking this one down.

Fixes: e1a5848e3398 ("ARM: 7924/1: mm: don't bother with reserved ttbr0 when 
running with LPAE")

Reported-by: Raymond Ngun 
Tested-by: Raymond Ngun 
Reviewed-by: Gregory Fong 
Signed-off-by: Will Deacon 
Signed-off-by: Russell King 
Signed-off-by: Greg Kroah-Hartman 

---
 arch/arm/mm/context.c |   26 +++---
 1 file changed, 11 insertions(+), 15 deletions(-)

--- a/arch/arm/mm/context.c
+++ b/arch/arm/mm/context.c
@@ -144,21 +144,17 @@ static void flush_context(unsigned int c
/* Update the list of reserved ASIDs and the ASID bitmap. */
bitmap_clear(asid_map, 0, NUM_USER_ASIDS);
for_each_possible_cpu(i) {
-   if (i == cpu) {
-   asid = 0;
-   } else {
-   asid = atomic64_xchg(&per_cpu(active_asids, i), 0);
-   /*
-* If this CPU has already been through a
-* rollover, but hasn't run another task in
-* the meantime, we must preserve its reserved
-* ASID, as this is the only trace we have of
-* the process it is still running.
-*/
-   if (asid == 0)
-   asid = per_cpu(reserved_asids, i);
-   __set_bit(asid & ~ASID_MASK, asid_map);
-   }
+   asid = atomic64_xchg(&per_cpu(active_asids, i), 0);
+   /*
+* If this CPU has already been through a
+* rollover, but hasn't run another task in
+* the meantime, we must preserve its reserved
+* ASID, as this is the only trace we have of
+* the process it is still running.
+*/
+   if (asid == 0)
+   asid = per_cpu(reserved_asids, i);
+   __set_bit(asid & ~ASID_MASK, asid_map);
per_cpu(reserved_asids, i) = asid;
}
 


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


[PATCH 3.14 17/20] ASoC: sgtl5000: add delay before first I2C access

2015-02-09 Thread Greg Kroah-Hartman
3.14-stable review patch.  If anyone has any objections, please let me know.

--

From: Eric Nelson 

commit 58cc9c9a175885bbf6bae3acf18233d0a8229a84 upstream.

To quote from section 1.3.1 of the data sheet:
The SGTL5000 has an internal reset that is deasserted
8 SYS_MCLK cycles after all power rails have been brought
up. After this time, communication can start

...
1.0us represents 8 SYS_MCLK cycles at the minimum 8.0 MHz SYS_MCLK.

Signed-off-by: Eric Nelson 
Reviewed-by: Fabio Estevam 
Signed-off-by: Mark Brown 
Signed-off-by: Greg Kroah-Hartman 

---
 sound/soc/codecs/sgtl5000.c |3 +++
 1 file changed, 3 insertions(+)

--- a/sound/soc/codecs/sgtl5000.c
+++ b/sound/soc/codecs/sgtl5000.c
@@ -1521,6 +1521,9 @@ static int sgtl5000_i2c_probe(struct i2c
if (ret)
return ret;
 
+   /* Need 8 clocks before I2C accesses */
+   udelay(1);
+
/* read chip information */
ret = regmap_read(sgtl5000->regmap, SGTL5000_CHIP_ID, ®);
if (ret)


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


[PATCH 3.14 09/20] mm: pagewalk: call pte_hole() for VM_PFNMAP during walk_page_range

2015-02-09 Thread Greg Kroah-Hartman
3.14-stable review patch.  If anyone has any objections, please let me know.

--

From: Shiraz Hashim 

commit 23aaed6659df9adfabe9c583e67a36b54e21df46 upstream.

walk_page_range() silently skips vma having VM_PFNMAP set, which leads
to undesirable behaviour at client end (who called walk_page_range).
Userspace applications get the wrong data, so the effect is like just
confusing users (if the applications just display the data) or sometimes
killing the processes (if the applications do something with
misunderstanding virtual addresses due to the wrong data.)

For example for pagemap_read, when no callbacks are called against
VM_PFNMAP vma, pagemap_read may prepare pagemap data for next virtual
address range at wrong index.

Eventually userspace may get wrong pagemap data for a task.
Corresponding to a VM_PFNMAP marked vma region, kernel may report
mappings from subsequent vma regions.  User space in turn may account
more pages (than really are) to the task.

In my case I was using procmem, procrack (Android utility) which uses
pagemap interface to account RSS pages of a task.  Due to this bug it
was giving a wrong picture for vmas (with VM_PFNMAP set).

Fixes: a9ff785e4437 ("mm/pagewalk.c: walk_page_range should avoid VM_PFNMAP 
areas")
Signed-off-by: Shiraz Hashim 
Acked-by: Naoya Horiguchi 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman 

---
 mm/pagewalk.c |5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

--- a/mm/pagewalk.c
+++ b/mm/pagewalk.c
@@ -199,7 +199,10 @@ int walk_page_range(unsigned long addr,
 */
if ((vma->vm_start <= addr) &&
(vma->vm_flags & VM_PFNMAP)) {
-   next = vma->vm_end;
+   if (walk->pte_hole)
+   err = walk->pte_hole(addr, next, walk);
+   if (err)
+   break;
pgd = pgd_offset(walk->mm, next);
continue;
}


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


[PATCH 3.18 13/39] MIPS: Fix kernel lockup or crash after CPU offline/online

2015-02-09 Thread Greg Kroah-Hartman
3.18-stable review patch.  If anyone has any objections, please let me know.

--

From: Hemmo Nieminen 

commit c7754e75100ed5e3068ac5085747f2bfc386c8d6 upstream.

As printk() invocation can cause e.g. a TLB miss, printk() cannot be
called before the exception handlers have been properly initialized.
This can happen e.g. when netconsole has been loaded as a kernel module
and the TLB table has been cleared when a CPU was offline.

Call cpu_report() in start_secondary() only after the exception handlers
have been initialized to fix this.

Without the patch the kernel will randomly either lockup or crash
after a CPU is onlined and the console driver is a module.

Signed-off-by: Hemmo Nieminen 
Signed-off-by: Aaro Koskinen 
Cc: David Daney 
Cc: linux-m...@linux-mips.org
Cc: linux-kernel@vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/8953/
Signed-off-by: Ralf Baechle 
Signed-off-by: Greg Kroah-Hartman 

---
 arch/mips/kernel/smp.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/arch/mips/kernel/smp.c
+++ b/arch/mips/kernel/smp.c
@@ -123,10 +123,10 @@ asmlinkage void start_secondary(void)
unsigned int cpu;
 
cpu_probe();
-   cpu_report();
per_cpu_trap_init(false);
mips_clockevent_init();
mp_ops->init_secondary();
+   cpu_report();
 
/*
 * XXX parity protection should be folded in here when it's converted


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


[PATCH 3.14 07/20] ARM: 8299/1: mm: ensure local active ASID is marked as allocated on rollover

2015-02-09 Thread Greg Kroah-Hartman
3.14-stable review patch.  If anyone has any objections, please let me know.

--

From: Will Deacon 

commit 8e64806672466392acf19e14427d1c29df3e58b9 upstream.

Commit e1a5848e3398 ("ARM: 7924/1: mm: don't bother with reserved ttbr0
when running with LPAE") removed the use of the reserved TTBR0 value
for LPAE systems, since the ASID is held in the TTBR and can be updated
atomicly with the pgd of the next mm.

Unfortunately, this patch forgot to update flush_context, which
deliberately avoids marking the local active ASID as allocated, since we
used to switch via ASID zero and didn't need to allocate the ASID of
the previous mm. The side-effect of this is that we can allocate the
same ASID to the next mm and, between flushing the local TLB and updating
TTBR0, we can perform speculative TLB fills for userspace nG mappings
using the page table of the previous mm.

The consequence of this is that the next mm can erroneously hit some
mappings of the previous mm. Note that this was made significantly
harder to hit by a391263cd84e ("ARM: 8203/1: mm: try to re-use old ASID
assignments following a rollover") but is still theoretically possible.

This patch fixes the problem by removing the code from flush_context
that forces the allocated ASID to zero for the local CPU. Many thanks
to the Broadcom guys for tracking this one down.

Fixes: e1a5848e3398 ("ARM: 7924/1: mm: don't bother with reserved ttbr0 when 
running with LPAE")

Reported-by: Raymond Ngun 
Tested-by: Raymond Ngun 
Reviewed-by: Gregory Fong 
Signed-off-by: Will Deacon 
Signed-off-by: Russell King 
Signed-off-by: Greg Kroah-Hartman 

---
 arch/arm/mm/context.c |   26 +++---
 1 file changed, 11 insertions(+), 15 deletions(-)

--- a/arch/arm/mm/context.c
+++ b/arch/arm/mm/context.c
@@ -144,21 +144,17 @@ static void flush_context(unsigned int c
/* Update the list of reserved ASIDs and the ASID bitmap. */
bitmap_clear(asid_map, 0, NUM_USER_ASIDS);
for_each_possible_cpu(i) {
-   if (i == cpu) {
-   asid = 0;
-   } else {
-   asid = atomic64_xchg(&per_cpu(active_asids, i), 0);
-   /*
-* If this CPU has already been through a
-* rollover, but hasn't run another task in
-* the meantime, we must preserve its reserved
-* ASID, as this is the only trace we have of
-* the process it is still running.
-*/
-   if (asid == 0)
-   asid = per_cpu(reserved_asids, i);
-   __set_bit(asid & ~ASID_MASK, asid_map);
-   }
+   asid = atomic64_xchg(&per_cpu(active_asids, i), 0);
+   /*
+* If this CPU has already been through a
+* rollover, but hasn't run another task in
+* the meantime, we must preserve its reserved
+* ASID, as this is the only trace we have of
+* the process it is still running.
+*/
+   if (asid == 0)
+   asid = per_cpu(reserved_asids, i);
+   __set_bit(asid & ~ASID_MASK, asid_map);
per_cpu(reserved_asids, i) = asid;
}
 


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


[PATCH 3.18 02/39] gpio: sysfs: fix memory leak in gpiod_sysfs_set_active_low

2015-02-09 Thread Greg Kroah-Hartman
3.18-stable review patch.  If anyone has any objections, please let me know.

--

From: Johan Hovold 

commit 49d2ca84e433dab854c7a866bc6add09cfab682d upstream.

Fix memory leak in the gpio sysfs interface due to failure to drop
reference to device returned by class_find_device when setting the
gpio-line polarity.

Fixes: 0769746183ca ("gpiolib: add support for changing value polarity in 
sysfs")
Signed-off-by: Johan Hovold 
Signed-off-by: Linus Walleij 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/gpio/gpiolib-sysfs.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/gpio/gpiolib-sysfs.c
+++ b/drivers/gpio/gpiolib-sysfs.c
@@ -678,7 +678,7 @@ int gpiod_sysfs_set_active_low(struct gp
}
 
status = sysfs_set_active_low(desc, dev, value);
-
+   put_device(dev);
 unlock:
mutex_unlock(&sysfs_lock);
 


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


[PATCH 3.18 08/39] spi: imx: use pio mode for i.mx6dl

2015-02-09 Thread Greg Kroah-Hartman
3.18-stable review patch.  If anyone has any objections, please let me know.

--

From: Robin Gong 

commit a02bb401f8ae264be782ee57d98bdd99f14c8022 upstream.

For TKT238285 hardware issue which may cause txfifo store data twice can only
be caught on i.mx6dl, we use pio mode instead of DMA mode on i.mx6dl.

Fixes: f62caccd12c17e4 (spi: spi-imx: add DMA support)
Signed-off-by: Robin Gong 
Signed-off-by: Mark Brown 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/spi/spi-imx.c |4 
 1 file changed, 4 insertions(+)

--- a/drivers/spi/spi-imx.c
+++ b/drivers/spi/spi-imx.c
@@ -823,6 +823,10 @@ static int spi_imx_sdma_init(struct devi
struct dma_slave_config slave_config = {};
int ret;
 
+   /* use pio mode for i.mx6dl chip TKT238285 */
+   if (of_machine_is_compatible("fsl,imx6dl"))
+   return 0;
+
/* Prepare for TX DMA: */
master->dma_tx = dma_request_slave_channel(dev, "tx");
if (!master->dma_tx) {


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


[PATCH 3.18 18/39] md/raid5: fix another livelock caused by non-aligned writes.

2015-02-09 Thread Greg Kroah-Hartman
3.18-stable review patch.  If anyone has any objections, please let me know.

--

From: NeilBrown 

commit b1b02fe97f75b12ab34b2303bfd4e3526d903a58 upstream.

If a non-page-aligned write is destined for a device which
is missing/faulty, we can deadlock.

As the target device is missing, a read-modify-write cycle
is not possible.
As the write is not for a full-page, a recontruct-write cycle
is not possible.

This should be handled by logic in fetch_block() which notices
there is a non-R5_OVERWRITE write to a missing device, and so
loads all blocks.

However since commit 67f455486d2ea2, that code requires
STRIPE_PREREAD_ACTIVE before it will active, and those circumstances
never set STRIPE_PREREAD_ACTIVE.

So: in handle_stripe_dirtying, if neither rmw or rcw was possible,
set STRIPE_DELAYED, which will cause STRIPE_PREREAD_ACTIVE be set
after a suitable delay.

Fixes: 67f455486d2ea20b2d94d6adf5b9b783d079e321
Reported-by: Mikulas Patocka 
Tested-by: Heinz Mauelshagen 
Signed-off-by: NeilBrown 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/md/raid5.c |5 +
 1 file changed, 5 insertions(+)

--- a/drivers/md/raid5.c
+++ b/drivers/md/raid5.c
@@ -3195,6 +3195,11 @@ static void handle_stripe_dirtying(struc
  (unsigned long long)sh->sector,
  rcw, qread, test_bit(STRIPE_DELAYED, 
&sh->state));
}
+
+   if (rcw > disks && rmw > disks &&
+   !test_bit(STRIPE_PREREAD_ACTIVE, &sh->state))
+   set_bit(STRIPE_DELAYED, &sh->state);
+
/* now if nothing is locked, and if we have enough data,
 * we can start a write request
 */


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


[PATCH 3.18 27/39] drm/radeon: properly set vm fragment size for TN/RL

2015-02-09 Thread Greg Kroah-Hartman
3.18-stable review patch.  If anyone has any objections, please let me know.

--

From: Alex Deucher 

commit a124d068bf5be6be2ff4b9fab77b1b7509107e68 upstream.

Should be the same as cayman.  We don't use VM by default
on NI parts so this isn't critical.

Signed-off-by: Alex Deucher 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/gpu/drm/radeon/radeon_vm.c |6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

--- a/drivers/gpu/drm/radeon/radeon_vm.c
+++ b/drivers/gpu/drm/radeon/radeon_vm.c
@@ -753,9 +753,11 @@ static void radeon_vm_frag_ptes(struct r
 */
 
/* NI is optimized for 256KB fragments, SI and newer for 64KB */
-   uint64_t frag_flags = rdev->family == CHIP_CAYMAN ?
+   uint64_t frag_flags = ((rdev->family == CHIP_CAYMAN) ||
+  (rdev->family == CHIP_ARUBA)) ?
R600_PTE_FRAG_256KB : R600_PTE_FRAG_64KB;
-   uint64_t frag_align = rdev->family == CHIP_CAYMAN ? 0x200 : 0x80;
+   uint64_t frag_align = ((rdev->family == CHIP_CAYMAN) ||
+  (rdev->family == CHIP_ARUBA)) ? 0x200 : 0x80;
 
uint64_t frag_start = ALIGN(pe_start, frag_align);
uint64_t frag_end = pe_end & ~(frag_align - 1);


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


[PATCH 3.18 38/39] tracing: Add condition check to RCU lockdep checks

2015-02-09 Thread Greg Kroah-Hartman
3.18-stable review patch.  If anyone has any objections, please let me know.

--

From: "Steven Rostedt (Red Hat)" 

commit a05d59a5673339ef6936d6940cdf68172ce75b9f upstream.

The trace_tlb_flush() tracepoint can be called when a CPU is going offline.
When a CPU is offline, RCU is no longer watching that CPU and since the
tracepoint is protected by RCU, it must not be called. To prevent the
tlb_flush tracepoint from being called when the CPU is offline, it was
converted to a TRACE_EVENT_CONDITION where the condition checks if the
CPU is online before calling the tracepoint.

Unfortunately, this was not enough to stop lockdep from complaining about
it. Even though the RCU protected code of the tracepoint will never be
called, the condition is hidden within the tracepoint, and even though the
condition prevents RCU code from being called, the lockdep checks are
outside the tracepoint (this is to test tracepoints even when they are not
enabled).

Even though tracepoints should be checked to be RCU safe when they are not
enabled, the condition should still be considered when checking RCU.

Link: 
http://lkml.kernel.org/r/CA+icZUUGiGDoL5NU8RuxKzFjoLjEKRtUWx=jb8b9a0eqv-e...@mail.gmail.com

Fixes: 3a630178fd5f "tracing: generate RCU warnings even when tracepoints are 
disabled"
Acked-by: Dave Hansen 
Reported-by: Sedat Dilek 
Tested-by: Sedat Dilek 
Signed-off-by: Steven Rostedt 
Signed-off-by: Greg Kroah-Hartman 

diff --git a/include/linux/tracepoint.h b/include/linux/tracepoint.h
index e08e21e5f601..c72851328ca9 100644
--- a/include/linux/tracepoint.h
+++ b/include/linux/tracepoint.h
@@ -173,7 +173,7 @@ extern void syscall_unregfunc(void);
TP_PROTO(data_proto),   \
TP_ARGS(data_args), \
TP_CONDITION(cond),,);  \
-   if (IS_ENABLED(CONFIG_LOCKDEP)) {   \
+   if (IS_ENABLED(CONFIG_LOCKDEP) && (cond)) { \
rcu_read_lock_sched_notrace();  \
rcu_dereference_sched(__tracepoint_##name.funcs);\
rcu_read_unlock_sched_notrace();\


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


Re: [PATCH v2] brcmfmac: avoid duplicated suspend/resume operation

2015-02-09 Thread Arend van Spriel

On 02/09/15 05:43, Fu, Zhonghui wrote:

 From ff39ed4af9f1c50358fe92ec4c8eaac9db183e00 Mon Sep 17 00:00:00 2001
From: Zhonghui Fu
Date: Mon, 26 Jan 2015 10:13:21 +0800
Subject: [PATCH v2] brcmfmac: avoid duplicated suspend/resume operation

WiFi chip has 2 SDIO functions, and PM core will trigger
twice suspend/resume operations for one WiFi chip to do
the same things. This patch avoid this case.


Well, another remark from Kalle was that this patch does not apply to 
wireless-drivers-next/master branch. So I tried to apply this patch and 
it failed. Please rebase this patch.


Regards,
Arend


Acked-by: Arend van Spriel
Signed-off-by: Zhonghui Fu
---
Changes in v2:
  - Remove two "Acked-by" lines

  drivers/net/wireless/brcm80211/brcmfmac/bcmsdh.c |   17 +++--
  1 files changed, 15 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/brcm80211/brcmfmac/bcmsdh.c 
b/drivers/net/wireless/brcm80211/brcmfmac/bcmsdh.c
index 9880dae..618b545 100644
--- a/drivers/net/wireless/brcm80211/brcmfmac/bcmsdh.c
+++ b/drivers/net/wireless/brcm80211/brcmfmac/bcmsdh.c
@@ -1139,11 +1139,17 @@ void brcmf_sdio_wowl_config(struct device *dev, bool 
enabled)
  static int brcmf_ops_sdio_suspend(struct device *dev)
  {
struct brcmf_bus *bus_if = dev_get_drvdata(dev);
-   struct brcmf_sdio_dev *sdiodev = bus_if->bus_priv.sdio;
+   struct brcmf_sdio_dev *sdiodev;
mmc_pm_flag_t sdio_flags;
+   struct sdio_func *func = dev_to_sdio_func(dev);

brcmf_dbg(SDIO, "Enter\n");

+   if (func->num == 2)
+   return 0;
+
+   sdiodev = bus_if->bus_priv.sdio;
+
atomic_set(&sdiodev->suspend, true);

if (sdiodev->wowl_enabled) {
@@ -1164,9 +1170,16 @@ static int brcmf_ops_sdio_suspend(struct device *dev)
  static int brcmf_ops_sdio_resume(struct device *dev)
  {
struct brcmf_bus *bus_if = dev_get_drvdata(dev);
-   struct brcmf_sdio_dev *sdiodev = bus_if->bus_priv.sdio;
+   struct brcmf_sdio_dev *sdiodev;
+   struct sdio_func *func = dev_to_sdio_func(dev);

brcmf_dbg(SDIO, "Enter\n");
+
+   if (func->num == 2)
+   return 0;
+
+   sdiodev = bus_if->bus_priv.sdio;
+
if (sdiodev->pdata&&  sdiodev->pdata->oob_irq_supported)
disable_irq_wake(sdiodev->pdata->oob_irq_nr);
brcmf_sdio_wd_timer(sdiodev->bus, BRCMF_WD_POLL_MS);
-- 1.7.1



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


[PATCH 3.18 09/39] sd: Fix max transfer length for 4k disks

2015-02-09 Thread Greg Kroah-Hartman
3.18-stable review patch.  If anyone has any objections, please let me know.

--

From: Brian King 

commit 3a9794d32984b67a6d8992226918618f0e51e5d5 upstream.

The following patch fixes an issue observed with 4k sector disks
where the max_hw_sectors attribute was getting set too large in
sd_revalidate_disk. Since sdkp->max_xfer_blocks is in units
of SCSI logical blocks and queue_max_hw_sectors is in units of
512 byte blocks, on a 4k sector disk, every time we went through
sd_revalidate_disk, we were taking the current value of
queue_max_hw_sectors and increasing it by a factor of 8. Fix
this by only shifting sdkp->max_xfer_blocks.

Signed-off-by: Brian King 
Reviewed-by: Paolo Bonzini 
Reviewed-by: Martin K. Petersen 
Signed-off-by: Christoph Hellwig 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/scsi/sd.c |6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

--- a/drivers/scsi/sd.c
+++ b/drivers/scsi/sd.c
@@ -2818,9 +2818,11 @@ static int sd_revalidate_disk(struct gen
 */
sd_set_flush_flag(sdkp);
 
-   max_xfer = min_not_zero(queue_max_hw_sectors(sdkp->disk->queue),
-   sdkp->max_xfer_blocks);
+   max_xfer = sdkp->max_xfer_blocks;
max_xfer <<= ilog2(sdp->sector_size) - 9;
+
+   max_xfer = min_not_zero(queue_max_hw_sectors(sdkp->disk->queue),
+   max_xfer);
blk_queue_max_hw_sectors(sdkp->disk->queue, max_xfer);
set_capacity(disk, sdkp->capacity);
sd_config_write_same(sdkp);


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


[PATCH 3.18 35/39] x86, microcode: Return error from driver init code when loader is disabled

2015-02-09 Thread Greg Kroah-Hartman
3.18-stable review patch.  If anyone has any objections, please let me know.

--

From: Boris Ostrovsky 

commit da63865a01c6384d459464e5165d95d4f04878d8 upstream.

Commits 65cef1311d5d ("x86, microcode: Add a disable chicken bit") and
a18a0f6850d4 ("x86, microcode: Don't initialize microcode code on
paravirt") allow microcode driver skip initialization when microcode
loading is not permitted.

However, they don't prevent the driver from being loaded since the
init code returns 0. If at some point later the driver gets unloaded
this will result in an oops while trying to deregister the (never
registered) device.

To avoid this, make init code return an error on paravirt or when
microcode loading is disabled. The driver will then never be loaded.

Signed-off-by: Boris Ostrovsky 
Link: 
http://lkml.kernel.org/r/1422411669-25147-1-git-send-email-boris.ostrov...@oracle.com
Reported-by: James Digwall 
Signed-off-by: Borislav Petkov 
Signed-off-by: Greg Kroah-Hartman 

---
 arch/x86/kernel/cpu/microcode/core.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/arch/x86/kernel/cpu/microcode/core.c
+++ b/arch/x86/kernel/cpu/microcode/core.c
@@ -552,7 +552,7 @@ static int __init microcode_init(void)
int error;
 
if (paravirt_enabled() || dis_ucode_ldr)
-   return 0;
+   return -EINVAL;
 
if (c->x86_vendor == X86_VENDOR_INTEL)
microcode_ops = init_intel_microcode();


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


[PATCH 3.18 23/39] drm/radeon: dont init gpuvm if accel is disabled (v3)

2015-02-09 Thread Greg Kroah-Hartman
3.18-stable review patch.  If anyone has any objections, please let me know.

--

From: Alex Deucher 

commit 544143f9e01a60a93eb00ab4bfcb9bf4702a2a7d upstream.

If acceleration is disabled, it does not make sense
to init gpuvm since nothing will use it.  Moreover,
if radeon_vm_init() gets called it uses accel to try
and clear the pde tables, etc. which results in a bug.

v2: handle vm_fini as well
v3: handle bo_open/close as well

Bug:
https://bugs.freedesktop.org/show_bug.cgi?id=88786

Signed-off-by: Alex Deucher 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/gpu/drm/radeon/radeon_gem.c |6 --
 drivers/gpu/drm/radeon/radeon_kms.c |   16 
 2 files changed, 12 insertions(+), 10 deletions(-)

--- a/drivers/gpu/drm/radeon/radeon_gem.c
+++ b/drivers/gpu/drm/radeon/radeon_gem.c
@@ -146,7 +146,8 @@ int radeon_gem_object_open(struct drm_ge
struct radeon_bo_va *bo_va;
int r;
 
-   if (rdev->family < CHIP_CAYMAN) {
+   if ((rdev->family < CHIP_CAYMAN) ||
+   (!rdev->accel_working)) {
return 0;
}
 
@@ -176,7 +177,8 @@ void radeon_gem_object_close(struct drm_
struct radeon_bo_va *bo_va;
int r;
 
-   if (rdev->family < CHIP_CAYMAN) {
+   if ((rdev->family < CHIP_CAYMAN) ||
+   (!rdev->accel_working)) {
return;
}
 
--- a/drivers/gpu/drm/radeon/radeon_kms.c
+++ b/drivers/gpu/drm/radeon/radeon_kms.c
@@ -598,14 +598,14 @@ int radeon_driver_open_kms(struct drm_de
return -ENOMEM;
}
 
-   vm = &fpriv->vm;
-   r = radeon_vm_init(rdev, vm);
-   if (r) {
-   kfree(fpriv);
-   return r;
-   }
-
if (rdev->accel_working) {
+   vm = &fpriv->vm;
+   r = radeon_vm_init(rdev, vm);
+   if (r) {
+   kfree(fpriv);
+   return r;
+   }
+
r = radeon_bo_reserve(rdev->ring_tmp_bo.bo, false);
if (r) {
radeon_vm_fini(rdev, vm);
@@ -663,9 +663,9 @@ void radeon_driver_postclose_kms(struct
radeon_vm_bo_rmv(rdev, vm->ib_bo_va);
radeon_bo_unreserve(rdev->ring_tmp_bo.bo);
}
+   radeon_vm_fini(rdev, vm);
}
 
-   radeon_vm_fini(rdev, vm);
kfree(fpriv);
file_priv->driver_priv = NULL;
}


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


[PATCH 3.18 21/39] memcg, shmem: fix shmem migration to use lrucare

2015-02-09 Thread Greg Kroah-Hartman
3.18-stable review patch.  If anyone has any objections, please let me know.

--

From: Michal Hocko 

commit f5e03a4989e80a86f8b514659dca8539132e6e09 upstream.

It has been reported that 965GM might trigger

  VM_BUG_ON_PAGE(!lrucare && PageLRU(oldpage), oldpage)

in mem_cgroup_migrate when shmem wants to replace a swap cache page
because of shmem_should_replace_page (the page is allocated from an
inappropriate zone).  shmem_replace_page expects that the oldpage is not
on LRU list and calls mem_cgroup_migrate without lrucare.  This is
obviously incorrect because swapcache pages might be on the LRU list
(e.g. swapin readahead page).

Fix this by enabling lrucare for the migration in shmem_replace_page.
Also clarify that lrucare should be used even if one of the pages might
be on LRU list.

The BUG_ON will trigger only when CONFIG_DEBUG_VM is enabled but even
without that the migration code might leave the old page on an
inappropriate memcg' LRU which is not that critical because the page
would get removed with its last reference but it is still confusing.

Fixes: 0a31bc97c80c ("mm: memcontrol: rewrite uncharge API")
Signed-off-by: Michal Hocko 
Reported-by: Chris Wilson 
Reported-by: Dave Airlie 
Acked-by: Hugh Dickins 
Acked-by: Johannes Weiner 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman 

---
 mm/memcontrol.c |2 +-
 mm/shmem.c  |2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -6589,7 +6589,7 @@ void mem_cgroup_uncharge_list(struct lis
  * mem_cgroup_migrate - migrate a charge to another page
  * @oldpage: currently charged page
  * @newpage: page to transfer the charge to
- * @lrucare: both pages might be on the LRU already
+ * @lrucare: either or both pages might be on the LRU already
  *
  * Migrate the charge from @oldpage to @newpage.
  *
--- a/mm/shmem.c
+++ b/mm/shmem.c
@@ -1013,7 +1013,7 @@ static int shmem_replace_page(struct pag
 */
oldpage = newpage;
} else {
-   mem_cgroup_migrate(oldpage, newpage, false);
+   mem_cgroup_migrate(oldpage, newpage, true);
lru_cache_add_anon(newpage);
*pagep = newpage;
}


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


[PATCH 3.18 39/39] x86/tlb/trace: Do not trace on CPU that is offline

2015-02-09 Thread Greg Kroah-Hartman
3.18-stable review patch.  If anyone has any objections, please let me know.

--

From: "Steven Rostedt (Red Hat)" 

commit 6c8465a82a605bc692304bab42703017dcfff013 upstream.

When taking a CPU down for suspend and resume, a tracepoint may be called
when the CPU has been designated offline. As tracepoints require RCU for
protection, they must not be called if the current CPU is offline.

Unfortunately, trace_tlb_flush() is called in this scenario as was noted
by LOCKDEP:

...

 Disabling non-boot CPUs ...
 intel_pstate CPU 1 exiting

 ===
 smpboot: CPU 1 didn't die...
 [ INFO: suspicious RCU usage. ]
 3.19.0-rc7-next-20150204.1-iniza-small #1 Not tainted
 ---
 include/trace/events/tlb.h:35 suspicious rcu_dereference_check() usage!

 other info that might help us debug this:

 RCU used illegally from offline CPU!
 rcu_scheduler_active = 1, debug_locks = 0
 no locks held by swapper/1/0.

 stack backtrace:
 CPU: 1 PID: 0 Comm: swapper/1 Not tainted 
3.19.0-rc7-next-20150204.1-iniza-small #1
 Hardware name: SAMSUNG ELECTRONICS CO., LTD. 
530U3BI/530U4BI/530U4BH/530U3BI/530U4BI/530U4BH, BIOS 13XK 03/28/2013
  0001 88011a44fe18 817e370d 0011
  88011a448290 88011a44fe48 810d6847 8800c66b9600
  0001 88011a44c000 81cb3900 88011a44fe78
 Call Trace:
  [] dump_stack+0x4c/0x65
  [] lockdep_rcu_suspicious+0xe7/0x120
  [] idle_task_exit+0x205/0x2c0
  [] play_dead_common+0xe/0x50
  [] native_play_dead+0x15/0x140
  [] arch_cpu_idle_dead+0xf/0x20
  [] cpu_startup_entry+0x37e/0x580
  [] start_secondary+0x140/0x150
 intel_pstate CPU 2 exiting

...

By converting the tlb_flush tracepoint to a TRACE_EVENT_CONDITION where the
condition is cpu_online(smp_processor_id()), we can avoid calling RCU protected
code when the CPU is offline.

Link: 
http://lkml.kernel.org/r/CA+icZUUGiGDoL5NU8RuxKzFjoLjEKRtUWx=jb8b9a0eqv-e...@mail.gmail.com

Fixes: d17d8f9dedb9 "x86/mm: Add tracepoints for TLB flushes"
Reported-by: Sedat Dilek 
Tested-by: Sedat Dilek 
Suggested-by: Paul E. McKenney 
Acked-by: Paul E. McKenney 
Acked-by: Dave Hansen 
Signed-off-by: Steven Rostedt 
Signed-off-by: Greg Kroah-Hartman 

diff --git a/include/trace/events/tlb.h b/include/trace/events/tlb.h
index 13391d288107..0e7635765153 100644
--- a/include/trace/events/tlb.h
+++ b/include/trace/events/tlb.h
@@ -13,11 +13,13 @@
{ TLB_LOCAL_SHOOTDOWN,  "local shootdown" },\
{ TLB_LOCAL_MM_SHOOTDOWN,   "local mm shootdown" }
 
-TRACE_EVENT(tlb_flush,
+TRACE_EVENT_CONDITION(tlb_flush,
 
TP_PROTO(int reason, unsigned long pages),
TP_ARGS(reason, pages),
 
+   TP_CONDITION(cpu_online(smp_processor_id())),
+
TP_STRUCT__entry(
__field(  int, reason)
__field(unsigned long,  pages)


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


[PATCH RFC v5 net-next 5/6] vhost: let vhost_signal() returns whether signalled

2015-02-09 Thread Jason Wang
Let vhost_signal() return whether or not vhost has injected an
interrupt to guest. This is used for interrupt coalescing
implementation to calculate the interval between two interrupts.

Signed-off-by: Jason Wang 
---
 drivers/vhost/vhost.c | 7 +--
 drivers/vhost/vhost.h | 2 +-
 2 files changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
index cb807d0..20d6b84 100644
--- a/drivers/vhost/vhost.c
+++ b/drivers/vhost/vhost.c
@@ -1480,11 +1480,14 @@ static bool vhost_notify(struct vhost_dev *dev, struct 
vhost_virtqueue *vq)
 }
 
 /* This actually signals the guest, using eventfd. */
-void vhost_signal(struct vhost_dev *dev, struct vhost_virtqueue *vq)
+bool vhost_signal(struct vhost_dev *dev, struct vhost_virtqueue *vq)
 {
/* Signal the Guest tell them we used something up. */
-   if (vq->call_ctx && vhost_notify(dev, vq))
+   if (vq->call_ctx && vhost_notify(dev, vq)) {
eventfd_signal(vq->call_ctx, 1);
+   return true;
+   }
+   return false;
 }
 EXPORT_SYMBOL_GPL(vhost_signal);
 
diff --git a/drivers/vhost/vhost.h b/drivers/vhost/vhost.h
index 8c1c792..a482563 100644
--- a/drivers/vhost/vhost.h
+++ b/drivers/vhost/vhost.h
@@ -148,7 +148,7 @@ void vhost_add_used_and_signal(struct vhost_dev *, struct 
vhost_virtqueue *,
   unsigned int id, int len);
 void vhost_add_used_and_signal_n(struct vhost_dev *, struct vhost_virtqueue *,
   struct vring_used_elem *heads, unsigned count);
-void vhost_signal(struct vhost_dev *, struct vhost_virtqueue *);
+bool vhost_signal(struct vhost_dev *, struct vhost_virtqueue *);
 void vhost_disable_notify(struct vhost_dev *, struct vhost_virtqueue *);
 bool vhost_enable_notify(struct vhost_dev *, struct vhost_virtqueue *);
 
-- 
1.8.3.1

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


[PATCH RFC v5 net-next 2/6] virtio_ring: try to disable event index callbacks in virtqueue_disable_cb()

2015-02-09 Thread Jason Wang
Currently, we do nothing to prevent the callbacks in
virtqueue_disable_cb() when event index is used. This may cause
spurious interrupts which may damage the performance. This patch tries
to publish avail event as the used even to prevent the callbacks.

Signed-off-by: Jason Wang 
---
 drivers/virtio/virtio_ring.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c
index 545fed5..e9ffbfb 100644
--- a/drivers/virtio/virtio_ring.c
+++ b/drivers/virtio/virtio_ring.c
@@ -539,6 +539,8 @@ void virtqueue_disable_cb(struct virtqueue *_vq)
struct vring_virtqueue *vq = to_vvq(_vq);
 
vq->vring.avail->flags |= cpu_to_virtio16(_vq->vdev, 
VRING_AVAIL_F_NO_INTERRUPT);
+   vring_used_event(&vq->vring) = cpu_to_virtio16(_vq->vdev,
+  vq->vring.avail->idx);
 }
 EXPORT_SYMBOL_GPL(virtqueue_disable_cb);
 
-- 
1.8.3.1

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


Re: [PATCH v2] ASoC: atmel_ssc_dai: Allow more rates

2015-02-09 Thread Bo Shen

Hi Peter,

On 02/09/2015 04:09 PM, Peter Rosin wrote:

[Snip]



   /*-*\
* DAI functions
@@ -200,6 +290,7 @@ static int atmel_ssc_startup(struct snd_pcm_substream 
*substream,
struct atmel_ssc_info *ssc_p = &ssc_info[dai->id];
struct atmel_pcm_dma_params *dma_params;
int dir, dir_mask;
+   int ret;

pr_debug("atmel_ssc_startup: SSC_SR=0x%u\n",
ssc_readl(ssc_p->ssc->regs, SR));
@@ -207,6 +298,7 @@ static int atmel_ssc_startup(struct snd_pcm_substream 
*substream,
/* Enable PMC peripheral clock for this SSC */
pr_debug("atmel_ssc_dai: Starting clock\n");
clk_enable(ssc_p->ssc->clk);
+   ssc_p->mck_rate = clk_get_rate(ssc_p->ssc->clk) * 2;


Why the mck_rate is calculated in this form?


What did you have in mind? Add another clock to the ssc node in the
device tree?

IIUC, the device tree (at least normally) has the ssc clk as the peripheral
clock divided by 2, but the ssc specifies (when capturing in the CBM/CFS
case) the rate limit as the peripheral clock divided by 3 (i.e. ssc clk / 1.5).
Since the SSC spec expresses the rate limit in terms of the peripheral
clock, this was what I came up with. I didn't want to require dt changes...


You make a misunderstand for the mck for ssc peripheral. The mck here is 
not the system mck, it only related with the ssc, it is the PMC output. 
For example, in device tree, the ssc clock divided by 2, then the pmc 
output for ssc is "system mck / 2", so the ssc mck is "system mck / 2". 
If divided by 4, then the ssc mck is "system / 4"



/* Reset the SSC to keep it at a clean status */
ssc_writel(ssc_p->ssc->regs, CR, SSC_BIT(CR_SWRST)); @@ -219,6
+311,17 @@ static int atmel_ssc_startup(struct snd_pcm_substream *substream,
dir_mask = SSC_DIR_MASK_CAPTURE;
}

+   ret = snd_pcm_hw_rule_add(substream->runtime, 0,
+ SNDRV_PCM_HW_PARAM_RATE,
+ atmel_ssc_hw_rule_rate,
+ ssc_p,
+ SNDRV_PCM_HW_PARAM_FRAME_BITS,
+ SNDRV_PCM_HW_PARAM_CHANNELS, -1);
+   if (ret < 0) {
+   dev_err(dai->dev, "Failed to specify rate rule: %d\n", ret);
+   return ret;
+   }
+
dma_params = &ssc_dma_params[dai->id][dir];
dma_params->ssc = ssc_p->ssc;
dma_params->substream = substream;
@@ -783,8 +886,6 @@ static int atmel_ssc_resume(struct snd_soc_dai *cpu_dai)
   #  define atmel_ssc_resume   NULL
   #endif /* CONFIG_PM */

-#define ATMEL_SSC_RATES (SNDRV_PCM_RATE_8000_96000)
-
   #define ATMEL_SSC_FORMATS (SNDRV_PCM_FMTBIT_S8 | SNDRV_PCM_FMTBIT_S16_LE 
|\
  SNDRV_PCM_FMTBIT_S24_LE | SNDRV_PCM_FMTBIT_S32_LE)

@@ -804,12 +905,16 @@ static struct snd_soc_dai_driver atmel_ssc_dai = {
.playback = {
.channels_min = 1,
.channels_max = 2,
-   .rates = ATMEL_SSC_RATES,
+   .rates = SNDRV_PCM_RATE_CONTINUOUS,
+   .rate_min = 8000,
+   .rate_max = 384000,


Why this need to be changed? Do you mean in your application, the rates will
exceed 96000?


Yes, we have designed for 250kHz and this works just fine. Why limit
to 96kHz?

Our application isn't audio, we're generating an FM subcarrier (DARC)
and need to output signals up to about 100kHz, give or take a few kHz
depending on how pedantic you are. Basically, we need a sampling rate
above 208kHz or so (DACs will normally not be usable all the way up to
the Nyquist frequency), or things are simply not usable for us.


For me, I should consider this is an another application for SSC, but 
not audio, however similar to audio. And as you specified, it is tested 
OK. So, no objection here, then.



.formats = ATMEL_SSC_FORMATS,},
.capture = {
.channels_min = 1,
.channels_max = 2,
-   .rates = ATMEL_SSC_RATES,
+   .rates = SNDRV_PCM_RATE_CONTINUOUS,
+   .rate_min = 8000,
+   .rate_max = 384000,


Ditto.


We are not capturing in our application, I changed this for symmetry.

Best regards,
Peter


.formats = ATMEL_SSC_FORMATS,},
.ops = &atmel_ssc_dai_ops,
   };
diff --git a/sound/soc/atmel/atmel_ssc_dai.h
b/sound/soc/atmel/atmel_ssc_dai.h index b1f08d511495..80b153857a88
100644
--- a/sound/soc/atmel/atmel_ssc_dai.h
+++ b/sound/soc/atmel/atmel_ssc_dai.h
@@ -115,6 +115,7 @@ struct atmel_ssc_info {
unsigned short rcmr_period;
struct atmel_pcm_dma_params *dma_params[2];
struct atmel_ssc_state ssc_state;
+   unsigned long mck_rate;
   };

   int atmel_ssc_set_audio(i

[PATCH 3.18 22/39] nilfs2: fix deadlock of segment constructor over I_SYNC flag

2015-02-09 Thread Greg Kroah-Hartman
3.18-stable review patch.  If anyone has any objections, please let me know.

--

From: Ryusuke Konishi 

commit 7ef3ff2fea8bf5e4a21cef47ad87710a3d0fdb52 upstream.

Nilfs2 eventually hangs in a stress test with fsstress program.  This
issue was caused by the following deadlock over I_SYNC flag between
nilfs_segctor_thread() and writeback_sb_inodes():

  nilfs_segctor_thread()
nilfs_segctor_thread_construct()
  nilfs_segctor_unlock()
nilfs_dispose_list()
  iput()
iput_final()
  evict()
inode_wait_for_writeback()  * wait for I_SYNC flag

  writeback_sb_inodes()
 * set I_SYNC flag on inode->i_state
__writeback_single_inode()
  do_writepages()
nilfs_writepages()
  nilfs_construct_dsync_segment()
nilfs_segctor_sync()
   * wait for completion of segment constructor
inode_sync_complete()
   * clear I_SYNC flag after __writeback_single_inode() completed

writeback_sb_inodes() calls do_writepages() for dirty inodes after
setting I_SYNC flag on inode->i_state.  do_writepages() in turn calls
nilfs_writepages(), which can run segment constructor and wait for its
completion.  On the other hand, segment constructor calls iput(), which
can call evict() and wait for the I_SYNC flag on
inode_wait_for_writeback().

Since segment constructor doesn't know when I_SYNC will be set, it
cannot know whether iput() will block or not unless inode->i_nlink has a
non-zero count.  We can prevent evict() from being called in iput() by
implementing sop->drop_inode(), but it's not preferable to leave inodes
with i_nlink == 0 for long periods because it even defers file
truncation and inode deallocation.  So, this instead resolves the
deadlock by calling iput() asynchronously with a workqueue for inodes
with i_nlink == 0.

Signed-off-by: Ryusuke Konishi 
Cc: Al Viro 
Tested-by: Ryusuke Konishi 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman 

---
 fs/nilfs2/nilfs.h   |2 --
 fs/nilfs2/segment.c |   44 +++-
 fs/nilfs2/segment.h |5 +
 3 files changed, 44 insertions(+), 7 deletions(-)

--- a/fs/nilfs2/nilfs.h
+++ b/fs/nilfs2/nilfs.h
@@ -141,7 +141,6 @@ enum {
  * @ti_save: Backup of journal_info field of task_struct
  * @ti_flags: Flags
  * @ti_count: Nest level
- * @ti_garbage:List of inode to be put when releasing semaphore
  */
 struct nilfs_transaction_info {
u32 ti_magic;
@@ -150,7 +149,6 @@ struct nilfs_transaction_info {
   one of other filesystems has a bug. */
unsigned short  ti_flags;
unsigned short  ti_count;
-   struct list_headti_garbage;
 };
 
 /* ti_magic */
--- a/fs/nilfs2/segment.c
+++ b/fs/nilfs2/segment.c
@@ -305,7 +305,6 @@ static void nilfs_transaction_lock(struc
ti->ti_count = 0;
ti->ti_save = cur_ti;
ti->ti_magic = NILFS_TI_MAGIC;
-   INIT_LIST_HEAD(&ti->ti_garbage);
current->journal_info = ti;
 
for (;;) {
@@ -332,8 +331,6 @@ static void nilfs_transaction_unlock(str
 
up_write(&nilfs->ns_segctor_sem);
current->journal_info = ti->ti_save;
-   if (!list_empty(&ti->ti_garbage))
-   nilfs_dispose_list(nilfs, &ti->ti_garbage, 0);
 }
 
 static void *nilfs_segctor_map_segsum_entry(struct nilfs_sc_info *sci,
@@ -746,6 +743,15 @@ static void nilfs_dispose_list(struct th
}
 }
 
+static void nilfs_iput_work_func(struct work_struct *work)
+{
+   struct nilfs_sc_info *sci = container_of(work, struct nilfs_sc_info,
+sc_iput_work);
+   struct the_nilfs *nilfs = sci->sc_super->s_fs_info;
+
+   nilfs_dispose_list(nilfs, &sci->sc_iput_queue, 0);
+}
+
 static int nilfs_test_metadata_dirty(struct the_nilfs *nilfs,
 struct nilfs_root *root)
 {
@@ -1900,8 +1906,8 @@ static int nilfs_segctor_collect_dirty_f
 static void nilfs_segctor_drop_written_files(struct nilfs_sc_info *sci,
 struct the_nilfs *nilfs)
 {
-   struct nilfs_transaction_info *ti = current->journal_info;
struct nilfs_inode_info *ii, *n;
+   int defer_iput = false;
 
spin_lock(&nilfs->ns_inode_lock);
list_for_each_entry_safe(ii, n, &sci->sc_dirty_files, i_dirty) {
@@ -1912,9 +1918,24 @@ static void nilfs_segctor_drop_written_f
clear_bit(NILFS_I_BUSY, &ii->i_state);
brelse(ii->i_bh);
ii->i_bh = NULL;
-   list_move_tail(&ii->i_dirty, &ti->ti_garbage);
+   list_del_init(&ii->i_dirty);
+   if (!ii->vfs_inode.i_nlink) {
+   /*
+* Defer calling iput() to avoid a deadlock
+* over I_SYNC flag for inodes with i_nlink == 0
+   

[PATCH RFC v5 net-next 0/6] enable tx interrupts for virtio-net

2015-02-09 Thread Jason Wang
Hi:

This is a new version of trying to enable tx interrupts for
virtio-net.

We used to try to avoid tx interrupts and orphan packets before
transmission for virtio-net. This breaks socket accounting and can
lead serveral other side effects e.g:

- Several other functions which depends on socket accounting can not
  work  correctly (e.g  TCP Small Queue)
- No tx completion which make BQL or packet generator can not work
  correctly.

This series tries to solve the issue by enabling tx interrupts. To
minize the performance impacts of this, several optimizations were
used:

- In guest side, try to use delayed callbacks as much as possible.
- In host side, try to use interrupt coalescing for reduce tx
  interrupts. About 10% - 15% performance were improved with this.

Perforamnce test shows:
- Very few regression (less than 5%) were noticed TCP_RR on 1 vcpu 1
  queue guest.
- CPU utilization is increased in some cases.
- All other cases, tx interrupts can perform equal or better than
  orphaning (much more obvious when testing small packet transmission
  as a byproduct since socket accounting works for TCP packet).

Changes from RFCv4:
- fix the virtqueue_enable_cb_delayed() return value when only 1
  buffer is pending.
- try to disable callbacks by publish event index in
  virtqueue_disable_cb(). Tests shows about 2% - 3% improvement on
  multiple sessions of TCP_RR.
- Revert some of Micahel's tweaks from RFC v1 (see patch 3 for
  details).
- use netif_wake_subqueue() instead of netif_start_subqueue() in
  free_old_xmit_skbs(), since it may be called in tx napi.
- in start_xmit(), try to enable the callback only when current skb is
  the last in the list or tx has already been stopped. This avoid the
  callbacks enabling in heavy load.
- return ns instead of us in vhost_net_check_coalesce_and_signal()
- measure the time interval of real interrupts instead of calls to
  vhost_signal()
- drop bql from the series since it does not affact performance from
  the test result.
Changes from RFC V3:
- Don't free tx packets in ndo_start_xmit()
- Add interrupt coalescing support for virtio-net
Changes from RFC v2:
- clean up code, address issues raised by Jason
Changes from RFC v1:
- address comments by Jason Wang, use delayed cb everywhere
- rebased Jason's patch on top of mine and include it (with some
tweaks)

Test result:

Environment:
Host: net-next.git
Guest: net-next.git
Qemu: qemu.git
CPU: Two Intel(R) Xeon(R) CPU E5620  @ 2.40GHz
Card: Two Intel Corporation 82599ES 10-Gigabit SFI/SFP+ Network
Connection (rev 01) connected back to back
Coalescing in host: rx-usecs: 1
Coalescing in guest:
- none if no tx interrupt
- tx-frames 8 tx-usecs 64
Zerocopy disabled for vhost_net

1 VCPU 1 queue:

Guest TX:
sessions/sizes/+-throughput%/+-cpu%/+-per_cpu_throughput%/
1/64/+41.2/-2.6/+45.1/
2/64/+40.8/-2.7/+44.7/
4/64/+38.5/-2.8/+42.5/
8/64/+36.1/-2.1/+38.9/
1/256/+158.5/-5.0/+172.3/
2/256/+155.3/-4.7/+167.9/
4/256/+156.4/-5.3/+170.6/
8/256/+155.4/-4.9/+168.6/
1/512/+276.5/-3.0/+288.3/
2/512/+280.1/-3.3/+293.1/
4/512/+276.1/-2.7/+286.7/
8/512/+267.1/-3.2/+279.1/
1/1024/+344.0/-6.9/+376.9/
2/1024/+362.3/-2.2/+372.8/
4/1024/+370.4/-1.1/+375.8/
8/1024/+374.0/+0.6/+371.1/
1/4096/+15.1/-30.4/+65.5/
2/4096/+6.3/-32.9/+58.4/
4/4096/+6.9/-32.4/+58.3/
8/4096/+6.7/-26.4/+45.0/
1/16384/-0.6/-4.6/+4.2/
2/16384/+0.0/-5.0/+5.4/
4/16384/+0.0/-2.5/+2.6/
8/16384/-0.0/-13.8/+13.2/
1/65535/-0.5/-0.5/0.0/
2/65535/-0.0/+4.0/-3.9/
4/65535/-0.0/+9.4/-8.6/
8/65535/+0.1/+8.6/-7.8/

TCP_RR:
sessions/sizes/+-throughput%/+-cpu%/+-per_cpu_throughput%/
1/1/-2.4/+16.3/-16.6/
50/1/-3.4/-0.2/-3.2/
1/64/+3.3/+0.7/+2.7/
50/64/-3.6/+0.2/-3.8/
1/256/-0.4/+16.6/-14.7/
50/256/-6.1/+0.2/-6.2/

Guest RX:
sessions/sizes/+-throughput%/+-cpu%/+-per_cpu_throughput%/
1/64/+17.3/+4.9/+10.0/
2/64/+13.8/+1.1/+12.3/
4/64/+3.8/+1.0/+2.7/
8/64/+1.4/+2.1/-0.7
1/256/+24.5/-1.3/+19.1/
2/256/-3.9/+3.8/-7.5/
4/256/-1.3/+1.5/-2.8/
8/256/+1.5/+1.7/-0.2/
1/512/+2.9/+12.7/-8.6/
2/512/-0.0/+3.5/-3.4/
4/512/-1.4/+2.6/-4.0/
8/512/-1.3/+3.1/-4.2/
1/1024/-0.2/+6.0/-5.9/
2/1024/+0.0/+3.1/-3.1/
4/1024/+0.1/+0.9/-0.7/
8/1024/-1.1/-4.1/+3.2/
1/4096/-0.6/+4.0/-4.4/
2/4096/-0.0/+3.6/-3.4/
4/4096/+0.7/+3.8/-3.1/
8/4096/-0.5/+2.4/-2.9/
1/16384/-1.1/+4.9/-5.7/
2/16384/-0.0/+2.4/-2.4/
4/16384/-0.1/+4.7/-4.6/
8/16384/+1.3/-2.0/+3.2/
1/65535/+1.9/+6.0/-3.8/
2/65535/+0.0/+3.3/-3.2/
4/65535/+0.1/+5.1/-4.7/
8/65535/-0.7/+8.0/-8.5/

4 VCPU 1 queue:

Guest TX:
sessions/sizes/+-throughput%/+-cpu%/+-per_cpu_throughput%/
1/64/+45.9/+2.7/+41.9/
2/64/+28.8/+0.2/+28.4/
4/64/+11.2/-0.6/+11.9/
8/64/+10.0/-0.5/+10.6/
1/256/+162.4/+1.0/+160.1/
2/256/+99.7/-0.2/+99.9/
4/256/+10.2/-11.3/+24.2/
8/256/-0.0/-13.8/+16.0/
1/512/+232.4/-0.2/+232.8/
2/512/+105.9/-9.9/+128.5/
4/512/+6.7/-18.8/+31.4/
8/512/+0.0/-21.0/+26.6/
1/1024/+285.1/-2.9/+296.9/
2/1024/+99.3/-22.4/+156.8/
4/1024/+3.7/-24.0/+36.4/
8/1024/+0.1/-23.9/+31.6/
1/4096/+35.9/-17.4/+64.6/
2/4096/+11.4/-27.4/+53.4/
4/4096/+0.1/-36.0/+56.3/
8/4096/+0.0/-34.9/+53.7

Re: [PATCH V5 6/8] USB: f81232: clarify f81232_ioctl()

2015-02-09 Thread Johan Hovold
On Mon, Feb 09, 2015 at 02:59:12PM +0800, Peter Hung wrote:
> Hello,
> 
> Sergei Shtylyov 於 2015/2/6 下午 08:21 寫道:
> >> We extract TIOCGSERIAL section in f81232_ioctl() to
> >> f81232_get_serial_info()
> >> to make it clarify
> >
> > You're also changing 'ser.baud_rate' from 460800 to 115200. And
> > explicitly overriding some previously initialized to 0 fields.
> 
> F81232 max baudrate is only 115200bps, so I set it for
> 1.8432MHz/16 = 115200.
> 
> We had add some closing time referenced from serial_core.c. The default
> value is:
> 
> port->close_delay = HZ / 2;   /* .5 seconds */
> port->closing_wait= 30 * HZ;/* 30 seconds */
> 
> We had increasing close_delay about 10x to
> 
> port->close_delay = 5 * HZ ;

You're never changing anything, you're just reporting an incorrect value
to userspace here.

The value you should be returning is
jiffies_to_msecs(port->port.closing_wait) / 10, unless the value is
ASYNC_CLOSING_WAIT_NONE in which case you simply return that, and
similarly for close_delay.

> >> The f81232_set_mctrl() replace set_control_lines() to do MCR control
> >> so we clean-up the set_control_lines() function.
> >
> > I don't see where are you doing this...
> >
> 
> This text is my patch V5 5/8 second section. I had wrong operation of 
> copy & paste. It's doesn't need for this patch, sorry for it.

Make sure to update the commit log for the next revision so that it
describes what you actually do.

I will probably not have time to review this version this week I'm
afraid.

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


[PATCH RFC v5 net-next 3/6] virtio_net: enable tx interrupt

2015-02-09 Thread Jason Wang
On newer hosts that support delayed tx interrupts,
we probably don't have much to gain from orphaning
packets early.

Note: this might degrade performance for
hosts without event idx support.
Should be addressed by the next patch.

Signed-off-by: Jason Wang 
---
Changes from RFCv4:
- change:
virtqueue_disable_cb(sq->vq);
napi_schedule(&sq->napi);

  in skb_xmit_done() to:

  if (__napi_schedule_prep(&sq->napi)) {
 virtqueue_diable_cb(sq->vq);
 __napi_schedule(&sq->napi);
  }

  to solve the race on architectures that atomic operations were not
  serialized. And do solve a similar issue in virtnet_poll_tx().
- use netif_wake_subqueue() instead of netif_start_subqueue() in
  free_old_xmit_skbs(), since it may be called in tx napi.
- in start_xmit(), try to enable the callback only when current skb is
  the last in the list or tx has already been stopped. This avoid the
  callbacks enabling in heavy load.
---
 drivers/net/virtio_net.c | 136 +++
 1 file changed, 90 insertions(+), 46 deletions(-)

diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index 11e2e81..cc5f5de 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -72,6 +72,8 @@ struct send_queue {
 
/* Name of the send queue: output.$index */
char name[40];
+
+   struct napi_struct napi;
 };
 
 /* Internal representation of a receive virtqueue */
@@ -140,6 +142,9 @@ struct virtnet_info {
 
/* CPU hot plug notifier */
struct notifier_block nb;
+
+   /* Budget for polling tx completion */
+   u32 tx_work_limit;
 };
 
 struct padded_vnet_hdr {
@@ -207,15 +212,43 @@ static struct page *get_a_page(struct receive_queue *rq, 
gfp_t gfp_mask)
return p;
 }
 
+static unsigned int free_old_xmit_skbs(struct netdev_queue *txq,
+  struct send_queue *sq, int budget)
+{
+   struct sk_buff *skb;
+   unsigned int len;
+   struct virtnet_info *vi = sq->vq->vdev->priv;
+   struct virtnet_stats *stats = this_cpu_ptr(vi->stats);
+   unsigned int packets = 0;
+
+   while (packets < budget &&
+  (skb = virtqueue_get_buf(sq->vq, &len)) != NULL) {
+   pr_debug("Sent skb %p\n", skb);
+
+   u64_stats_update_begin(&stats->tx_syncp);
+   stats->tx_bytes += skb->len;
+   stats->tx_packets++;
+   u64_stats_update_end(&stats->tx_syncp);
+
+   dev_kfree_skb_any(skb);
+   packets++;
+   }
+
+   if (sq->vq->num_free >= 2 + MAX_SKB_FRAGS)
+   netif_wake_subqueue(vi->dev, vq2txq(sq->vq));
+
+   return packets;
+}
+
 static void skb_xmit_done(struct virtqueue *vq)
 {
struct virtnet_info *vi = vq->vdev->priv;
+   struct send_queue *sq = &vi->sq[vq2txq(vq)];
 
-   /* Suppress further interrupts. */
-   virtqueue_disable_cb(vq);
-
-   /* We were probably waiting for more output buffers. */
-   netif_wake_subqueue(vi->dev, vq2txq(vq));
+   if (napi_schedule_prep(&sq->napi)) {
+   virtqueue_disable_cb(sq->vq);
+   __napi_schedule(&sq->napi);
+   }
 }
 
 static unsigned int mergeable_ctx_to_buf_truesize(unsigned long mrg_ctx)
@@ -776,6 +809,30 @@ static int virtnet_poll(struct napi_struct *napi, int 
budget)
return received;
 }
 
+static int virtnet_poll_tx(struct napi_struct *napi, int budget)
+{
+   struct send_queue *sq =
+   container_of(napi, struct send_queue, napi);
+   struct virtnet_info *vi = sq->vq->vdev->priv;
+   struct netdev_queue *txq = netdev_get_tx_queue(vi->dev, vq2txq(sq->vq));
+   u32 limit = vi->tx_work_limit;
+   unsigned int r, sent;
+
+   __netif_tx_lock(txq, smp_processor_id());
+   sent = free_old_xmit_skbs(txq, sq, limit);
+   if (sent < limit) {
+   r = virtqueue_enable_cb_prepare(sq->vq);
+   napi_complete(napi);
+   if (unlikely(virtqueue_poll(sq->vq, r)) &&
+   napi_schedule_prep(napi)) {
+   virtqueue_disable_cb(sq->vq);
+   __napi_schedule(napi);
+   }
+   }
+   __netif_tx_unlock(txq);
+   return sent < limit ? 0 : budget;
+}
+
 #ifdef CONFIG_NET_RX_BUSY_POLL
 /* must be called with local_bh_disable()d */
 static int virtnet_busy_poll(struct napi_struct *napi)
@@ -824,30 +881,12 @@ static int virtnet_open(struct net_device *dev)
if (!try_fill_recv(vi, &vi->rq[i], GFP_KERNEL))
schedule_delayed_work(&vi->refill, 0);
virtnet_napi_enable(&vi->rq[i]);
+   napi_enable(&vi->sq[i].napi);
}
 
return 0;
 }
 
-static void free_old_xmit_skbs(struct send_queue *sq)
-{
-   struct sk_buff *skb;
-   unsigned int len;
-   struct virtnet_info *vi = sq->vq->vdev->priv;
-   struct virtnet_stats *stats = this_cpu_ptr(vi

[PATCH RFC v5 net-next 6/6] vhost_net: interrupt coalescing support

2015-02-09 Thread Jason Wang
This patch implements interrupt coalescing support for vhost_net. And provides
ioctl()s for userspace to get and set coalescing parameters. Two kinds of
parameters were allowed to be set:

- max_coalesced_frames: which is the maximum numbers of packets were allowed
  before issuing an irq.
- coalesced_usecs: which is the maximum number of micro seconds were allowed
  before issuing an irq if at least one packet were pending.

A per virtqueue hrtimer were used for coalesced_usecs.

Cc: Michael S. Tsirkin 
Signed-off-by: Jason Wang 
---
Changes from RFCv4:
- return ns instead of us in vhost_net_check_coalesce_and_signal()
- measure the time interval of real interrupts instead of calls to 
vhost_signal().
---
 drivers/vhost/net.c| 199 +++--
 include/uapi/linux/vhost.h |  12 +++
 2 files changed, 202 insertions(+), 9 deletions(-)

diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c
index 6906f76..3222ac9 100644
--- a/drivers/vhost/net.c
+++ b/drivers/vhost/net.c
@@ -18,6 +18,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -62,7 +63,8 @@ enum {
VHOST_NET_FEATURES = VHOST_FEATURES |
 (1ULL << VHOST_NET_F_VIRTIO_NET_HDR) |
 (1ULL << VIRTIO_NET_F_MRG_RXBUF) |
-(1ULL << VIRTIO_F_VERSION_1),
+(1ULL << VIRTIO_F_VERSION_1) |
+(1ULL << VIRTIO_NET_F_CTRL_COALESCE),
 };
 
 enum {
@@ -100,6 +102,15 @@ struct vhost_net_virtqueue {
/* Reference counting for outstanding ubufs.
 * Protected by vq mutex. Writers must also take device mutex. */
struct vhost_net_ubuf_ref *ubufs;
+   /* Microseconds after at least 1 paket is processed before
+* generating an interrupt.
+*/
+   __u32 coalesce_usecs;
+   /* Packets are processed before genearting an interrupt. */
+   __u32 max_coalesced_frames;
+   __u32 coalesced;
+   ktime_t last_signal;
+   struct hrtimer c_timer;
 };
 
 struct vhost_net {
@@ -197,11 +208,16 @@ static void vhost_net_vq_reset(struct vhost_net *n)
vhost_net_clear_ubuf_info(n);
 
for (i = 0; i < VHOST_NET_VQ_MAX; i++) {
+   hrtimer_cancel(&n->vqs[i].c_timer);
n->vqs[i].done_idx = 0;
n->vqs[i].upend_idx = 0;
n->vqs[i].ubufs = NULL;
n->vqs[i].vhost_hlen = 0;
n->vqs[i].sock_hlen = 0;
+   n->vqs[i].max_coalesced_frames = 0;
+   n->vqs[i].coalesce_usecs = 0;
+   n->vqs[i].last_signal = ktime_get();
+   n->vqs[i].coalesced = 0;
}
 
 }
@@ -273,6 +289,55 @@ static void copy_iovec_hdr(const struct iovec *from, 
struct iovec *to,
}
 }
 
+static int vhost_net_check_coalesce_and_signal(struct vhost_dev *dev,
+  struct vhost_net_virtqueue *nvq)
+{
+   struct vhost_virtqueue *vq = &nvq->vq;
+   int left = 0;
+   ktime_t now;
+
+   if (nvq->coalesced) {
+   now = ktime_get();
+   left = nvq->coalesce_usecs -
+  ktime_to_us(ktime_sub(now, nvq->last_signal));
+   if (left <= 0) {
+   vhost_signal(dev, vq);
+   nvq->last_signal = now;
+   nvq->coalesced = 0;
+   }
+   }
+
+   return left * NSEC_PER_USEC;
+}
+
+static bool vhost_net_add_used_and_signal_n(struct vhost_dev *dev,
+   struct vhost_net_virtqueue *nvq,
+   struct vring_used_elem *heads,
+   unsigned count)
+{
+   struct vhost_virtqueue *vq = &nvq->vq;
+   bool can_coalesce = nvq->max_coalesced_frames && nvq->coalesce_usecs;
+   bool ret = false;
+
+   vhost_add_used_n(vq, heads, count);
+
+   if (can_coalesce) {
+   ktime_t now = ktime_get();
+
+   nvq->coalesced += count;
+   if (((nvq->coalesced >= nvq->max_coalesced_frames) ||
+(ktime_to_us(ktime_sub(now, nvq->last_signal)) >=
+ nvq->coalesce_usecs)) && vhost_signal(dev, vq)) {
+   nvq->coalesced = 0;
+   nvq->last_signal = now;
+   ret = true;
+   }
+   } else {
+   vhost_signal(dev, vq);
+   }
+   return ret;
+}
+
 /* In case of DMA done not in order in lower device driver for some reason.
  * upend_idx is used to track end of used idx, done_idx is used to track head
  * of used idx. Once lower device DMA done contiguously, we will signal KVM
@@ -297,8 +362,8 @@ static void vhost_zerocopy_signal_used(struct vhost_net 
*net,
}
while (j) {
add = min(UIO_MAXIOV - nvq->done_idx, j);
-   vhost_add_used_and_signal_n(vq->dev, vq,
-  

[PATCH RFC v5 net-next 4/6] virtio-net: add basic interrupt coalescing support

2015-02-09 Thread Jason Wang
This patch enables the interrupt coalescing setting through ethtool.

Cc: Rusty Russell 
Cc: Michael S. Tsirkin 
Signed-off-by: Jason Wang 
---
 drivers/net/virtio_net.c| 67 +
 include/uapi/linux/virtio_net.h | 12 
 2 files changed, 79 insertions(+)

diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index cc5f5de..2b958fb 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -145,6 +145,11 @@ struct virtnet_info {
 
/* Budget for polling tx completion */
u32 tx_work_limit;
+
+   __u32 rx_coalesce_usecs;
+   __u32 rx_max_coalesced_frames;
+   __u32 tx_coalesce_usecs;
+   __u32 tx_max_coalesced_frames;
 };
 
 struct padded_vnet_hdr {
@@ -1404,12 +1409,73 @@ static void virtnet_get_channels(struct net_device *dev,
channels->other_count = 0;
 }
 
+static int virtnet_set_coalesce(struct net_device *dev,
+   struct ethtool_coalesce *ec)
+{
+   struct virtnet_info *vi = netdev_priv(dev);
+   struct scatterlist sg;
+   struct virtio_net_ctrl_coalesce c;
+
+   if (!vi->has_cvq ||
+   !virtio_has_feature(vi->vdev, VIRTIO_NET_F_CTRL_COALESCE))
+   return -EOPNOTSUPP;
+   if (vi->rx_coalesce_usecs != ec->rx_coalesce_usecs ||
+   vi->rx_max_coalesced_frames != ec->rx_max_coalesced_frames) {
+   c.coalesce_usecs = ec->rx_coalesce_usecs;
+   c.max_coalesced_frames = ec->rx_max_coalesced_frames;
+   sg_init_one(&sg, &c, sizeof(c));
+   if (!virtnet_send_command(vi, VIRTIO_NET_CTRL_COALESCE,
+ VIRTIO_NET_CTRL_COALESCE_RX_SET,
+ &sg)) {
+   dev_warn(&dev->dev, "Fail to set rx coalescing\n");
+   return -EINVAL;
+   }
+   vi->rx_coalesce_usecs = ec->rx_coalesce_usecs;
+   vi->rx_max_coalesced_frames = ec->rx_max_coalesced_frames;
+   }
+
+   if (vi->tx_coalesce_usecs != ec->tx_coalesce_usecs ||
+   vi->tx_max_coalesced_frames != ec->tx_max_coalesced_frames) {
+   c.coalesce_usecs = ec->tx_coalesce_usecs;
+   c.max_coalesced_frames = ec->tx_max_coalesced_frames;
+   sg_init_one(&sg, &c, sizeof(c));
+   if (!virtnet_send_command(vi, VIRTIO_NET_CTRL_COALESCE,
+ VIRTIO_NET_CTRL_COALESCE_TX_SET,
+ &sg)) {
+   dev_warn(&dev->dev, "Fail to set tx coalescing\n");
+   return -EINVAL;
+   }
+   vi->tx_coalesce_usecs = ec->tx_coalesce_usecs;
+   vi->tx_max_coalesced_frames = ec->tx_max_coalesced_frames;
+   }
+
+   vi->tx_work_limit = ec->tx_max_coalesced_frames_irq;
+
+   return 0;
+}
+
+static int virtnet_get_coalesce(struct net_device *dev,
+   struct ethtool_coalesce *ec)
+{
+   struct virtnet_info *vi = netdev_priv(dev);
+
+   ec->rx_coalesce_usecs = vi->rx_coalesce_usecs;
+   ec->rx_max_coalesced_frames = vi->rx_max_coalesced_frames;
+   ec->tx_coalesce_usecs = vi->tx_coalesce_usecs;
+   ec->tx_max_coalesced_frames = vi->tx_max_coalesced_frames;
+   ec->tx_max_coalesced_frames_irq = vi->tx_work_limit;
+
+   return 0;
+}
+
 static const struct ethtool_ops virtnet_ethtool_ops = {
.get_drvinfo = virtnet_get_drvinfo,
.get_link = ethtool_op_get_link,
.get_ringparam = virtnet_get_ringparam,
.set_channels = virtnet_set_channels,
.get_channels = virtnet_get_channels,
+   .set_coalesce = virtnet_set_coalesce,
+   .get_coalesce = virtnet_get_coalesce,
 };
 
 #define MIN_MTU 68
@@ -2048,6 +2114,7 @@ static unsigned int features[] = {
VIRTIO_NET_F_GUEST_ANNOUNCE, VIRTIO_NET_F_MQ,
VIRTIO_NET_F_CTRL_MAC_ADDR,
VIRTIO_F_ANY_LAYOUT,
+   VIRTIO_NET_F_CTRL_COALESCE,
 };
 
 static struct virtio_driver virtio_net_driver = {
diff --git a/include/uapi/linux/virtio_net.h b/include/uapi/linux/virtio_net.h
index b5f1677..332009d 100644
--- a/include/uapi/linux/virtio_net.h
+++ b/include/uapi/linux/virtio_net.h
@@ -34,6 +34,7 @@
 /* The feature bitmap for virtio net */
 #define VIRTIO_NET_F_CSUM  0   /* Host handles pkts w/ partial csum */
 #define VIRTIO_NET_F_GUEST_CSUM1   /* Guest handles pkts w/ 
partial csum */
+#define VIRTIO_NET_F_CTRL_COALESCE 3   /* Set coalescing */
 #define VIRTIO_NET_F_MAC   5   /* Host has given MAC address. */
 #define VIRTIO_NET_F_GSO   6   /* Host handles pkts w/ any GSO type */
 #define VIRTIO_NET_F_GUEST_TSO47   /* Guest can handle TSOv4 in. */
@@ -202,4 +203,15 @@ struct virtio_net_ctrl_mq {
  #define VIRTIO_NET_CTRL_MQ_VQ_PAIRS_MIN1
  #define VIRTIO_NET_CTRL_MQ_VQ_PAIRS_MAX0x8000
 
+struct virtio_ne

[PATCH RFC v5 net-next 1/6] virtio_ring: fix virtqueue_enable_cb() when only 1 buffers were pending

2015-02-09 Thread Jason Wang
We currently does:

bufs = (avail->idx - last_used_idx) * 3 / 4;

This is ok now since we only try to enable the delayed callbacks when
the queue is about to be full. This may not work well when there is
only one pending buffer in the virtqueue (this may be the case after
tx interrupt was enabled). Since virtqueue_enable_cb() will return
false which may cause unnecessary triggering of napis. This patch
correct this by only calculate the four thirds when bufs is not one.

Signed-off-by: Jason Wang 
---
 drivers/virtio/virtio_ring.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c
index 00ec6b3..545fed5 100644
--- a/drivers/virtio/virtio_ring.c
+++ b/drivers/virtio/virtio_ring.c
@@ -636,7 +636,10 @@ bool virtqueue_enable_cb_delayed(struct virtqueue *_vq)
 * entry. Always do both to keep code simple. */
vq->vring.avail->flags &= cpu_to_virtio16(_vq->vdev, 
~VRING_AVAIL_F_NO_INTERRUPT);
/* TODO: tune this threshold */
-   bufs = (u16)(virtio16_to_cpu(_vq->vdev, vq->vring.avail->idx) - 
vq->last_used_idx) * 3 / 4;
+   bufs = (u16)(virtio16_to_cpu(_vq->vdev, vq->vring.avail->idx) -
+vq->last_used_idx);
+   if (bufs != 1)
+   bufs = bufs * 3 / 4;
vring_used_event(&vq->vring) = cpu_to_virtio16(_vq->vdev, 
vq->last_used_idx + bufs);
virtio_mb(vq->weak_barriers);
if (unlikely((u16)(virtio16_to_cpu(_vq->vdev, vq->vring.used->idx) - 
vq->last_used_idx) > bufs)) {
-- 
1.8.3.1

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


[PATCH] devicetree: Add TI-NSPIRE USB OTG support to device tree

2015-02-09 Thread Daniel Tang
Signed-off-by: Daniel Tang 
---
 arch/arm/boot/dts/nspire-classic.dtsi |  5 +
 arch/arm/boot/dts/nspire-cx.dts   |  4 
 arch/arm/boot/dts/nspire.dtsi | 21 +
 3 files changed, 30 insertions(+)

diff --git a/arch/arm/boot/dts/nspire-classic.dtsi 
b/arch/arm/boot/dts/nspire-classic.dtsi
index 9565199..4907c50 100644
--- a/arch/arm/boot/dts/nspire-classic.dtsi
+++ b/arch/arm/boot/dts/nspire-classic.dtsi
@@ -51,6 +51,11 @@
compatible = "lsi,nspire-classic-ahb-divider";
 };
 
+
+&vbus_reg {
+   gpio = <&gpio 5 0>;
+};
+
 / {
memory {
device_type = "memory";
diff --git a/arch/arm/boot/dts/nspire-cx.dts b/arch/arm/boot/dts/nspire-cx.dts
index 375b924..08e0b81 100644
--- a/arch/arm/boot/dts/nspire-cx.dts
+++ b/arch/arm/boot/dts/nspire-cx.dts
@@ -69,6 +69,10 @@
0x0709001d  0x070a0033  >;
 };
 
+&vbus_reg {
+   gpio = <&gpio 2 0>;
+};
+
 / {
model = "TI-NSPIRE CX";
compatible = "ti,nspire-cx";
diff --git a/arch/arm/boot/dts/nspire.dtsi b/arch/arm/boot/dts/nspire.dtsi
index a22ffe6..390c91a 100644
--- a/arch/arm/boot/dts/nspire.dtsi
+++ b/arch/arm/boot/dts/nspire.dtsi
@@ -54,6 +54,20 @@
clocks = <&ahb_clk>;
};
 
+   usb_phy: usb_phy {
+   compatible = "usb-nop-xceiv";
+   };
+
+   vbus_reg: vbus_reg {
+   compatible = "regulator-fixed";
+
+   regulator-name = "USB VBUS output";
+   regulator-type = "voltage";
+
+   regulator-min-microvolt = <500>;
+   regulator-max-microvolt = <500>;
+   };
+
ahb {
compatible = "simple-bus";
#address-cells = <1>;
@@ -65,8 +79,12 @@
};
 
usb0: usb@B000 {
+   compatible = "lsi,zevio-usb";
reg = <0xB000 0x1000>;
interrupts = <8>;
+
+   usb-phy = <&usb_phy>;
+   vbus-supply = <&vbus_reg>;
};
 
usb1: usb@B400 {
@@ -105,8 +123,11 @@
ranges;
 
gpio: gpio@9000 {
+   compatible = "lsi,zevio-gpio";
reg = <0x9000 0x1000>;
interrupts = <7>;
+   gpio-controller;
+   #gpio-cells = <2>;
};
 
fast_timer: timer@9001 {
-- 
2.1.3

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


[PATCH] ath9k_htc: add adaptive usb receive flow control to repair soft lockup with monitor mode

2015-02-09 Thread yuweizheng
From: Yuwei Zheng 

In the environment with heavy wifi traffic, set the ar9271 into monitor mode, 
will
trigger a deadloop panic.
 
The ath9k_hif_usb_rx_cb function excute on  the interrupt context, and 
ath9k_rx_tasklet excute
on the soft irq context. In other words, the ath9k_hif_usb_rx_cb have more 
chance to excute than
ath9k_rx_tasklet.  So in the worst condition,  the rx.rxbuf receive list is 
always full,
and the do {}while(true) loop will not be break. The kernel get a soft lockup 
panic. 
 
[59011.007210] BUG: soft lockup - CPU#0 stuck for 23s!
[kworker/0:0:30609]
[59011.030560] BUG: scheduling while atomic: kworker/0:0/30609/0x40010100
[59013.804486] BUG: scheduling while atomic: kworker/0:0/30609/0x40010100
[59013.858522] Kernel panic - not syncing: softlockup: hung tasks
 
[59014.038891] Exception stack(0xdf4bbc38 to 0xdf4bbc80)
[59014.046834] bc20:   
de57b950 6113
[59014.059579] bc40:  bb32bb32 6113 de57b948 de57b500 dc7bb440 
df4bbcd0 
[59014.072337] bc60: de57b950 6113 df4bbcd0 df4bbc80 c04c259d c04c25a0 
6133 
[59014.085233] [] (__irq_svc+0x3b/0x5c) from [] 
(_raw_spin_unlock_irqrestore+0xc/0x10)
[59014.100437] [] (_raw_spin_unlock_irqrestore+0xc/0x10) from 
[] (ath9k_rx_tasklet+0x290/0x490 [ath9k_htc])
[59014.118267] [] (ath9k_rx_tasklet+0x290/0x490 [ath9k_htc]) from 
[] (tasklet_action+0x3b/0x98)
[59014.134132] [] (tasklet_action+0x3b/0x98) from [] 
(__do_softirq+0x99/0x16c)
[59014.147784] [] (__do_softirq+0x99/0x16c) from [] 
(irq_exit+0x5b/0x5c)
[59014.160653] [] (irq_exit+0x5b/0x5c) from [] 
(handle_IRQ+0x37/0x78)
[59014.173124] [] (handle_IRQ+0x37/0x78) from [] 
(omap3_intc_handle_irq+0x5f/0x68)
[59014.187225] [] (omap3_intc_handle_irq+0x5f/0x68) from 
[](__irq_svc+0x3b/0x5c)
 
This bug can be see with low performance board, such as uniprocessor beagle 
bone board. 
 
Signed-off-by: Yuwei Zheng 

---
 drivers/net/wireless/ath/ath9k/hif_usb.c   | 75 +++---
 drivers/net/wireless/ath/ath9k/hif_usb.h   |  9 
 drivers/net/wireless/ath/ath9k/htc.h   | 19 +++
 drivers/net/wireless/ath/ath9k/htc_drv_debug.c | 53 ++
 drivers/net/wireless/ath/ath9k/htc_drv_txrx.c  | 44 +++
 5 files changed, 193 insertions(+), 7 deletions(-)

diff --git a/drivers/net/wireless/ath/ath9k/hif_usb.c 
b/drivers/net/wireless/ath/ath9k/hif_usb.c
index 8e7153b..d05cc0b 100644
--- a/drivers/net/wireless/ath/ath9k/hif_usb.c
+++ b/drivers/net/wireless/ath/ath9k/hif_usb.c
@@ -640,6 +640,7 @@ static void ath9k_hif_usb_rx_cb(struct urb *urb)
struct hif_device_usb *hif_dev =
usb_get_intfdata(usb_ifnum_to_if(urb->dev, 0));
int ret;
+   int delay;
 
if (!skb)
return;
@@ -658,7 +659,6 @@ static void ath9k_hif_usb_rx_cb(struct urb *urb)
default:
goto resubmit;
}
-
if (likely(urb->actual_length != 0)) {
skb_put(skb, urb->actual_length);
ath9k_hif_usb_rx_stream(hif_dev, skb);
@@ -667,12 +667,22 @@ static void ath9k_hif_usb_rx_cb(struct urb *urb)
 resubmit:
skb_reset_tail_pointer(skb);
skb_trim(skb, 0);
-
-   usb_anchor_urb(urb, &hif_dev->rx_submitted);
-   ret = usb_submit_urb(urb, GFP_ATOMIC);
-   if (ret) {
-   usb_unanchor_urb(urb);
-   goto free;
+   spin_lock(&hif_dev->aurfc_lock);
+   if (atomic_read(&hif_dev->aurfc_submit_delay) > 0 &&
+   hif_dev->aurfc_active == 1) {
+   usb_anchor_urb(urb, &hif_dev->rx_delayed_submitted);
+   delay = atomic_read(&hif_dev->aurfc_submit_delay);
+   schedule_delayed_work(&hif_dev->aurfc_delayed_work,
+ msecs_to_jiffies(delay));
+   spin_unlock(&hif_dev->aurfc_lock);
+   } else {
+   spin_unlock(&hif_dev->aurfc_lock);
+   usb_anchor_urb(urb, &hif_dev->rx_submitted);
+   ret = usb_submit_urb(urb, GFP_ATOMIC);
+   if (ret) {
+   usb_unanchor_urb(urb);
+   goto free;
+   }
}
 
return;
@@ -818,9 +828,51 @@ err:
return -ENOMEM;
 }
 
+static void aurfc_submit_handler(struct work_struct *work)
+{
+   struct hif_device_usb *hif_dev =
+   container_of(work,
+struct hif_device_usb,
+aurfc_delayed_work.work);
+   struct urb *urb = NULL;
+   struct sk_buff *skb = NULL;
+   int ret;
+   int loop_times = 0;
+
+   AURFC_STAT_INC(aurfc_called);
+   while (true) {
+   loop_times++;
+   if (loop_times > MAX_RX_URB_NUM)
+   atomic_add(AURFC_STEP,
+  &hif_dev->aurfc_submit_delay);
+
+   urb = usb_get_from_anchor(
+   &hif_dev->rx_delayed_s

[PATCH 3.18 20/39] lib/checksum.c: fix carry in csum_tcpudp_nofold

2015-02-09 Thread Greg Kroah-Hartman
3.18-stable review patch.  If anyone has any objections, please let me know.

--

From: karl beldan 

commit 150ae0e94634714b23919f0c333fee28a5b199d5 upstream.

The carry from the 64->32bits folding was dropped, e.g with:
saddr=0x daddr=0xFFFF len=0x proto=0 sum=1,
csum_tcpudp_nofold returned 0 instead of 1.

Signed-off-by: Karl Beldan 
Cc: Al Viro 
Cc: Eric Dumazet 
Cc: Arnd Bergmann 
Cc: Mike Frysinger 
Cc: net...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Eric Dumazet 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman 

---
 lib/checksum.c |   12 ++--
 1 file changed, 10 insertions(+), 2 deletions(-)

--- a/lib/checksum.c
+++ b/lib/checksum.c
@@ -47,6 +47,15 @@ static inline unsigned short from32to16(
return x;
 }
 
+static inline u32 from64to32(u64 x)
+{
+   /* add up 32-bit and 32-bit for 32+c bit */
+   x = (x & 0x) + (x >> 32);
+   /* add up carry.. */
+   x = (x & 0x) + (x >> 32);
+   return (u32)x;
+}
+
 static unsigned int do_csum(const unsigned char *buff, int len)
 {
int odd;
@@ -195,8 +204,7 @@ __wsum csum_tcpudp_nofold(__be32 saddr,
 #else
s += (proto + len) << 8;
 #endif
-   s += (s >> 32);
-   return (__force __wsum)s;
+   return (__force __wsum)from64to32(s);
 }
 EXPORT_SYMBOL(csum_tcpudp_nofold);
 #endif


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


[GIT PULL] locking tree updates for v3.20

2015-02-09 Thread Ingo Molnar
Linus,

Please pull the latest locking-core-for-linus git tree from:

   git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git 
locking-core-for-linus

   # HEAD: afffc6c1805d98e08e778cddb644a666e78cfcfd locking/rtmutex: Optimize 
setting task running after being blocked

The main changes are:

  - mutex, completions and rtmutex micro-optimizations
  - lock debugging fix
  - various cleanups in the MCS and the futex code

 Thanks,

Ingo

-->
Davidlohr Bueso (8):
  locking/mutex: Checking the stamp is WW only
  locking/mutex: Move MCS related comments to proper location
  locking/mutex: Introduce ww_mutex_set_context_slowpath()
  locking/mcs: Better differentiate between MCS variants
  locking/osq: No need for load/acquire when acquire-polling
  locking/mutex: Explicitly mark task as running after wakeup
  locking/rwsem: Use task->state helpers
  locking/rtmutex: Optimize setting task running after being blocked

Heiko Carstens (1):
  softirq/preempt: Add missing current->preempt_disable_ip update

Michael Kerrisk (2):
  doc: Fix misnamed FUTEX_CMP_REQUEUE_PI op constants
  futex: Fix argument handling in futex_lock_pi() calls

Nicholas Mc Guire (2):
  sched/completion: Remove unnecessary ->wait.lock serialization when 
reading completion state
  sched/completion: Add lock-free checking of the blocking case

SeongJae Park (1):
  locking/Documentation: Update code path


 Documentation/futex-requeue-pi.txt|  8 ++--
 Documentation/locking/lockdep-design.txt  |  2 +-
 include/linux/osq_lock.h  | 12 +-
 kernel/Kconfig.locks  |  4 ++
 kernel/futex.c|  6 +--
 kernel/locking/Makefile   |  3 +-
 kernel/locking/mcs_spinlock.h | 16 ---
 kernel/locking/mutex.c| 60 ++-
 kernel/locking/{mcs_spinlock.c => osq_lock.c} |  9 +---
 kernel/locking/rtmutex.c  |  7 ++--
 kernel/locking/rwsem-spinlock.c   |  2 +-
 kernel/locking/rwsem-xadd.c   |  3 +-
 kernel/sched/completion.c | 18 
 kernel/softirq.c  |  6 ++-
 14 files changed, 78 insertions(+), 78 deletions(-)
 rename kernel/locking/{mcs_spinlock.c => osq_lock.c} (98%)

diff --git a/Documentation/futex-requeue-pi.txt 
b/Documentation/futex-requeue-pi.txt
index 31b16610c416..77b36f59d16b 100644
--- a/Documentation/futex-requeue-pi.txt
+++ b/Documentation/futex-requeue-pi.txt
@@ -98,7 +98,7 @@ rt_mutex_start_proxy_lock() and rt_mutex_finish_proxy_lock(), 
which
 allow the requeue code to acquire an uncontended rt_mutex on behalf
 of the waiter and to enqueue the waiter on a contended rt_mutex.
 Two new system calls provide the kernel<->user interface to
-requeue_pi: FUTEX_WAIT_REQUEUE_PI and FUTEX_REQUEUE_CMP_PI.
+requeue_pi: FUTEX_WAIT_REQUEUE_PI and FUTEX_CMP_REQUEUE_PI.
 
 FUTEX_WAIT_REQUEUE_PI is called by the waiter (pthread_cond_wait()
 and pthread_cond_timedwait()) to block on the initial futex and wait
@@ -107,7 +107,7 @@ result of a high-speed collision between futex_wait() and
 futex_lock_pi(), with some extra logic to check for the additional
 wake-up scenarios.
 
-FUTEX_REQUEUE_CMP_PI is called by the waker
+FUTEX_CMP_REQUEUE_PI is called by the waker
 (pthread_cond_broadcast() and pthread_cond_signal()) to requeue and
 possibly wake the waiting tasks. Internally, this system call is
 still handled by futex_requeue (by passing requeue_pi=1).  Before
@@ -120,12 +120,12 @@ task as a waiter on the underlying rt_mutex.  It is 
possible that
 the lock can be acquired at this stage as well, if so, the next
 waiter is woken to finish the acquisition of the lock.
 
-FUTEX_REQUEUE_PI accepts nr_wake and nr_requeue as arguments, but
+FUTEX_CMP_REQUEUE_PI accepts nr_wake and nr_requeue as arguments, but
 their sum is all that really matters.  futex_requeue() will wake or
 requeue up to nr_wake + nr_requeue tasks.  It will wake only as many
 tasks as it can acquire the lock for, which in the majority of cases
 should be 0 as good programming practice dictates that the caller of
 either pthread_cond_broadcast() or pthread_cond_signal() acquire the
-mutex prior to making the call. FUTEX_REQUEUE_PI requires that
+mutex prior to making the call. FUTEX_CMP_REQUEUE_PI requires that
 nr_wake=1.  nr_requeue should be INT_MAX for broadcast and 0 for
 signal.
diff --git a/Documentation/locking/lockdep-design.txt 
b/Documentation/locking/lockdep-design.txt
index 5dbc99c04f6e..5001280e9d82 100644
--- a/Documentation/locking/lockdep-design.txt
+++ b/Documentation/locking/lockdep-design.txt
@@ -34,7 +34,7 @@ State
 - 'ever held with STATE enabled'
 - 'ever held as readlock with STATE enabled'
 
-Where STATE can be either one of (kernel/lockdep_states.h)
+Where STATE can be either one of (kernel/locking/lockdep_states.h)
  - ha

[PATCH 3.18 34/39] ARM: dts: Fix I2S1, I2S2 compatible for exynos4 SoCs

2015-02-09 Thread Greg Kroah-Hartman
3.18-stable review patch.  If anyone has any objections, please let me know.

--

From: Sylwester Nawrocki 

commit fddcd300732dad5b822d27de7aa78998dca43162 upstream.

I2S1, I2S2 on Exynos4 SoC series have limited functionality compared
to I2S0, "samsung,s3c6410-i2s" compatible should be used for them.

Signed-off-by: Sylwester Nawrocki 
Signed-off-by: Mark Brown 
Signed-off-by: Greg Kroah-Hartman 

---
 arch/arm/boot/dts/exynos4.dtsi |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

--- a/arch/arm/boot/dts/exynos4.dtsi
+++ b/arch/arm/boot/dts/exynos4.dtsi
@@ -368,7 +368,7 @@
};
 
i2s1: i2s@1396 {
-   compatible = "samsung,s5pv210-i2s";
+   compatible = "samsung,s3c6410-i2s";
reg = <0x1396 0x100>;
clocks = <&clock CLK_I2S1>;
clock-names = "iis";
@@ -378,7 +378,7 @@
};
 
i2s2: i2s@1397 {
-   compatible = "samsung,s5pv210-i2s";
+   compatible = "samsung,s3c6410-i2s";
reg = <0x1397 0x100>;
clocks = <&clock CLK_I2S2>;
clock-names = "iis";


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


Re: [PATCH] tpm, tpm_tis: fix TPM 2.0 probing

2015-02-09 Thread Jarkko Sakkinen
On Mon, Feb 09, 2015 at 12:08:46AM +0100, Peter Hüwe wrote:
> Am Mittwoch, 4. Februar 2015, 15:21:09 schrieb Jarkko Sakkinen:
> > If during transmission system error was returned, the logic was to
> > incorrectly deduce that chip is a TPM 1.x chip. This patch fixes this
> > issue. Also, this patch changes probing so that message tag is used as the
> > measure for TPM 2.x, which should be much more stable.
> Is it aware that some TPMs may respond with 0x00C1 as TAG for TPM1.2 commands?

I guess none of the TPM 1.2 command answer with the tag 0x8002?

> > A separate function
> > called tpm2_probe() is encapsulated because it can be used with any
> > chipset.
> 
> > 
> > Signed-off-by: Jarkko Sakkinen 
> > ---
> >  drivers/char/tpm/tpm.h  |  3 ++-
> >  drivers/char/tpm/tpm2-cmd.c | 40 +---
> >  drivers/char/tpm/tpm_tis.c  | 11 ---
> >  3 files changed, 39 insertions(+), 15 deletions(-)
> > 
> > diff --git a/drivers/char/tpm/tpm.h b/drivers/char/tpm/tpm.h
> > index 7b0727c..a4b0f5e 100644
> > --- a/drivers/char/tpm/tpm.h
> > +++ b/drivers/char/tpm/tpm.h
> > @@ -435,4 +435,5 @@ extern int tpm2_startup(struct tpm_chip *chip, u16
> > startup_type); extern int tpm2_shutdown(struct tpm_chip *chip, u16
> > shutdown_type); extern unsigned long tpm2_calc_ordinal_duration(struct
> > tpm_chip *, u32); extern int tpm2_do_selftest(struct tpm_chip *chip);
> > -extern int tpm2_gen_interrupt(struct tpm_chip *chip, bool quiet);
> > +extern int tpm2_gen_interrupt(struct tpm_chip *chip);
> > +extern int tpm2_probe(struct tpm_chip *chip);
> > diff --git a/drivers/char/tpm/tpm2-cmd.c b/drivers/char/tpm/tpm2-cmd.c
> > index 1abe650..49cd354 100644
> > --- a/drivers/char/tpm/tpm2-cmd.c
> > +++ b/drivers/char/tpm/tpm2-cmd.c
> > @@ -598,20 +598,46 @@ EXPORT_SYMBOL_GPL(tpm2_do_selftest);
> >  /**
> >   * tpm2_gen_interrupt() - generate an interrupt
> >   * @chip: TPM chip to use
> > - * @quiet: surpress the error message
> >   *
> >   * 0 is returned when the operation is successful. If a negative number is
> >   * returned it remarks a POSIX error code. If a positive number is
> > returned * it remarks a TPM error.
> >   */
> > -int tpm2_gen_interrupt(struct tpm_chip *chip, bool quiet)
> > +int tpm2_gen_interrupt(struct tpm_chip *chip)
> >  {
> > -   const char *desc = NULL;
> > u32 dummy;
> > 
> > -   if (!quiet)
> > -   desc = "attempting to generate an interrupt";
> > -
> > -   return tpm2_get_tpm_pt(chip, TPM2_CAP_TPM_PROPERTIES, &dummy, desc);
> > +   return tpm2_get_tpm_pt(chip, 0x100, &dummy,
> > +  "attempting to generate an interrupt");
> Why the change from TPM2_CAP_TPM_PROPERTIES = 6 to 0x100 and what does 0x100 
> stand for?

In TPM 2.0 there are two levels: capabilities and properties. Using
capability ID of "TPM properties" property set was a sloppy mistake
although it didn't matter because interrupt is still generate.

The properties in the "TPM properties" property set start with the
index 0x100.

> >  }
> >  EXPORT_SYMBOL_GPL(tpm2_gen_interrupt);
> > +
> > +/**
> > + * tpm2_probe() - probe TPM 2.0
> > + * @chip: TPM chip to use
> > + *
> > + * Send idempotent TPM 2.0 command and see whether TPM 2.0 chip replied
> > based on + * the reply tag.
> > + */
> > +int tpm2_probe(struct tpm_chip *chip)
> > +{
> > +   struct tpm2_cmd cmd;
> > +   int rc;
> > +
> > +   cmd.header.in = tpm2_get_tpm_pt_header;
> > +   cmd.params.get_tpm_pt_in.cap_id = cpu_to_be32(TPM2_CAP_TPM_PROPERTIES);
> > +   cmd.params.get_tpm_pt_in.property_id = cpu_to_be32(0x100);
> > +   cmd.params.get_tpm_pt_in.property_cnt = cpu_to_be32(1);
> > +
> > +   rc = tpm_transmit(chip, (const char *) &cmd, sizeof(cmd));
> > +   if (rc <  0)
> > +   return rc;
> > +   else if (rc < TPM_HEADER_SIZE)
> > +   return -EFAULT;
> > +
> > +   if (be16_to_cpu(cmd.header.out.tag) == TPM2_ST_NO_SESSIONS)
> > +   chip->flags |= TPM_CHIP_FLAG_TPM2;
> > +
> > +   return 0;
> > +}
> > +EXPORT_SYMBOL_GPL(tpm2_probe);
> > diff --git a/drivers/char/tpm/tpm_tis.c b/drivers/char/tpm/tpm_tis.c
> > index 6725bef..ee6e0bd 100644
> > --- a/drivers/char/tpm/tpm_tis.c
> > +++ b/drivers/char/tpm/tpm_tis.c
> > @@ -639,12 +639,9 @@ static int tpm_tis_init(struct device *dev,
> > acpi_handle acpi_dev_handle, goto out_err;
> > }
> > 
> > -   /* Every TPM 2.x command has a higher ordinal than TPM 1.x commands.
> > -* Therefore, we can use an idempotent TPM 2.x command to probe TPM 2.x.
> > -*/
> > -   rc = tpm2_gen_interrupt(chip, true);
> > -   if (rc == 0 || rc == TPM2_RC_INITIALIZE)
> > -   chip->flags |= TPM_CHIP_FLAG_TPM2;
> > +   rc = tpm2_probe(chip);
> > +   if (rc)
> > +   goto out_err;
> > 
> > vendor = ioread32(chip->vendor.iobase + TPM_DID_VID(0));
> > chip->vendor.manufacturer_id = vendor;
> > @@ -747,7 +744,7 @@ static int tpm_tis_init(struct device *dev, acpi_handle
> > acpi_dev_handle,
> > 
> > /* Generate Interrupt

[PATCH 3.18 37/39] hrtimer: Fix incorrect tai offset calculation for non high-res timer systems

2015-02-09 Thread Greg Kroah-Hartman
3.18-stable review patch.  If anyone has any objections, please let me know.

--

From: John Stultz 

commit 2d926c15d629a13914ce3e5f26354f6a0ac99e70 upstream.

I noticed some CLOCK_TAI timer test failures on one of my
less-frequently used configurations. And after digging in I
found in 76f4108892d9 (Cleanup hrtimer accessors to the
timekepeing state), the hrtimer_get_softirq_time tai offset
calucation was incorrectly rewritten, as the tai offset we
return shold be from CLOCK_MONOTONIC, and not CLOCK_REALTIME.

This results in CLOCK_TAI timers expiring early on non-highres
capable machines.

This patch fixes the issue, calculating the tai time properly
from the monotonic base.

Signed-off-by: John Stultz 
Cc: Thomas Gleixner 
Link: 
http://lkml.kernel.org/r/1423097126-10236-1-git-send-email-john.stu...@linaro.org
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman 

---
 kernel/time/hrtimer.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/kernel/time/hrtimer.c
+++ b/kernel/time/hrtimer.c
@@ -122,7 +122,7 @@ static void hrtimer_get_softirq_time(str
mono = ktime_get_update_offsets_tick(&off_real, &off_boot, &off_tai);
boot = ktime_add(mono, off_boot);
xtim = ktime_add(mono, off_real);
-   tai = ktime_add(xtim, off_tai);
+   tai = ktime_add(mono, off_tai);
 
base->clock_base[HRTIMER_BASE_REALTIME].softirq_time = xtim;
base->clock_base[HRTIMER_BASE_MONOTONIC].softirq_time = mono;


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


[PATCH 3.18 33/39] ALSA: ak411x: Fix stall in work callback

2015-02-09 Thread Greg Kroah-Hartman
3.18-stable review patch.  If anyone has any objections, please let me know.

--

From: Takashi Iwai 

commit 4161b4505f1690358ac0a9ee59845a7887336b21 upstream.

When ak4114 work calls its callback and the callback invokes
ak4114_reinit(), it stalls due to flush_delayed_work().  For avoiding
this, control the reentrance by introducing a refcount.  Also
flush_delayed_work() is replaced with cancel_delayed_work_sync().

The exactly same bug is present in ak4113.c and fixed as well.

Reported-by: Pavel Hofman 
Acked-by: Jaroslav Kysela 
Tested-by: Pavel Hofman 
Signed-off-by: Takashi Iwai 
Signed-off-by: Greg Kroah-Hartman 

---
 include/sound/ak4113.h   |2 +-
 include/sound/ak4114.h   |2 +-
 sound/i2c/other/ak4113.c |   17 -
 sound/i2c/other/ak4114.c |   18 --
 4 files changed, 18 insertions(+), 21 deletions(-)

--- a/include/sound/ak4113.h
+++ b/include/sound/ak4113.h
@@ -286,7 +286,7 @@ struct ak4113 {
ak4113_write_t *write;
ak4113_read_t *read;
void *private_data;
-   unsigned int init:1;
+   atomic_t wq_processing;
spinlock_t lock;
unsigned char regmap[AK4113_WRITABLE_REGS];
struct snd_kcontrol *kctls[AK4113_CONTROLS];
--- a/include/sound/ak4114.h
+++ b/include/sound/ak4114.h
@@ -168,7 +168,7 @@ struct ak4114 {
ak4114_write_t * write;
ak4114_read_t * read;
void * private_data;
-   unsigned int init: 1;
+   atomic_t wq_processing;
spinlock_t lock;
unsigned char regmap[6];
unsigned char txcsb[5];
--- a/sound/i2c/other/ak4113.c
+++ b/sound/i2c/other/ak4113.c
@@ -56,8 +56,7 @@ static inline unsigned char reg_read(str
 
 static void snd_ak4113_free(struct ak4113 *chip)
 {
-   chip->init = 1; /* don't schedule new work */
-   mb();
+   atomic_inc(&chip->wq_processing);   /* don't schedule new work */
cancel_delayed_work_sync(&chip->work);
kfree(chip);
 }
@@ -89,6 +88,7 @@ int snd_ak4113_create(struct snd_card *c
chip->write = write;
chip->private_data = private_data;
INIT_DELAYED_WORK(&chip->work, ak4113_stats);
+   atomic_set(&chip->wq_processing, 0);
 
for (reg = 0; reg < AK4113_WRITABLE_REGS ; reg++)
chip->regmap[reg] = pgm[reg];
@@ -139,13 +139,11 @@ static void ak4113_init_regs(struct ak41
 
 void snd_ak4113_reinit(struct ak4113 *chip)
 {
-   chip->init = 1;
-   mb();
-   flush_delayed_work(&chip->work);
+   if (atomic_inc_return(&chip->wq_processing) == 1)
+   cancel_delayed_work_sync(&chip->work);
ak4113_init_regs(chip);
/* bring up statistics / event queing */
-   chip->init = 0;
-   if (chip->kctls[0])
+   if (atomic_dec_and_test(&chip->wq_processing))
schedule_delayed_work(&chip->work, HZ / 10);
 }
 EXPORT_SYMBOL_GPL(snd_ak4113_reinit);
@@ -632,8 +630,9 @@ static void ak4113_stats(struct work_str
 {
struct ak4113 *chip = container_of(work, struct ak4113, work.work);
 
-   if (!chip->init)
+   if (atomic_inc_return(&chip->wq_processing) == 1)
snd_ak4113_check_rate_and_errors(chip, chip->check_flags);
 
-   schedule_delayed_work(&chip->work, HZ / 10);
+   if (atomic_dec_and_test(&chip->wq_processing))
+   schedule_delayed_work(&chip->work, HZ / 10);
 }
--- a/sound/i2c/other/ak4114.c
+++ b/sound/i2c/other/ak4114.c
@@ -66,8 +66,7 @@ static void reg_dump(struct ak4114 *ak41
 
 static void snd_ak4114_free(struct ak4114 *chip)
 {
-   chip->init = 1; /* don't schedule new work */
-   mb();
+   atomic_inc(&chip->wq_processing);   /* don't schedule new work */
cancel_delayed_work_sync(&chip->work);
kfree(chip);
 }
@@ -100,6 +99,7 @@ int snd_ak4114_create(struct snd_card *c
chip->write = write;
chip->private_data = private_data;
INIT_DELAYED_WORK(&chip->work, ak4114_stats);
+   atomic_set(&chip->wq_processing, 0);
 
for (reg = 0; reg < 6; reg++)
chip->regmap[reg] = pgm[reg];
@@ -152,13 +152,11 @@ static void ak4114_init_regs(struct ak41
 
 void snd_ak4114_reinit(struct ak4114 *chip)
 {
-   chip->init = 1;
-   mb();
-   flush_delayed_work(&chip->work);
+   if (atomic_inc_return(&chip->wq_processing) == 1)
+   cancel_delayed_work_sync(&chip->work);
ak4114_init_regs(chip);
/* bring up statistics / event queing */
-   chip->init = 0;
-   if (chip->kctls[0])
+   if (atomic_dec_and_test(&chip->wq_processing))
schedule_delayed_work(&chip->work, HZ / 10);
 }
 
@@ -612,10 +610,10 @@ static void ak4114_stats(struct work_str
 {
struct ak4114 *chip = container_of(work, struct ak4114, work.work);
 
-   if (!chip->init)
+   if (atomic_inc_return(&chip->wq_processing) == 1)
snd_ak4114_check_rate_and_errors(chip, chip->check_flags);
-
-   schedule_delayed_work(&chip->wo

[PATCH 3.18 36/39] smpboot: Add missing get_online_cpus() in smpboot_register_percpu_thread()

2015-02-09 Thread Greg Kroah-Hartman
3.18-stable review patch.  If anyone has any objections, please let me know.

--

From: Lai Jiangshan 

commit 4bee96860a65c3a62d332edac331b3cf936ba3ad upstream.

The following race exists in the smpboot percpu threads management:

CPU0 CPU1
cpu_up(2)
  get_online_cpus();
  smpboot_create_threads(2);
 smpboot_register_percpu_thread();
 for_each_online_cpu();
   __smpboot_create_thread();
  __cpu_up(2);

This results in a missing per cpu thread for the newly onlined cpu2 and
in a NULL pointer dereference on a consecutive offline of that cpu.

Proctect smpboot_register_percpu_thread() with get_online_cpus() to
prevent that.

[ tglx: Massaged changelog and removed the change in
smpboot_unregister_percpu_thread() because that's an
optimization and therefor not stable material. ]

Signed-off-by: Lai Jiangshan 
Cc: Thomas Gleixner 
Cc: Rusty Russell 
Cc: Peter Zijlstra 
Cc: Srivatsa S. Bhat 
Cc: David Rientjes 
Link: 
http://lkml.kernel.org/r/1406777421-12830-1-git-send-email-la...@cn.fujitsu.com
Signed-off-by: Thomas Gleixner 
Signed-off-by: Greg Kroah-Hartman 

---
 kernel/smpboot.c |2 ++
 1 file changed, 2 insertions(+)

--- a/kernel/smpboot.c
+++ b/kernel/smpboot.c
@@ -279,6 +279,7 @@ int smpboot_register_percpu_thread(struc
unsigned int cpu;
int ret = 0;
 
+   get_online_cpus();
mutex_lock(&smpboot_threads_lock);
for_each_online_cpu(cpu) {
ret = __smpboot_create_thread(plug_thread, cpu);
@@ -291,6 +292,7 @@ int smpboot_register_percpu_thread(struc
list_add(&plug_thread->list, &hotplug_threads);
 out:
mutex_unlock(&smpboot_threads_lock);
+   put_online_cpus();
return ret;
 }
 EXPORT_SYMBOL_GPL(smpboot_register_percpu_thread);


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


[PATCH 3.18 32/39] ASoC: sgtl5000: add delay before first I2C access

2015-02-09 Thread Greg Kroah-Hartman
3.18-stable review patch.  If anyone has any objections, please let me know.

--

From: Eric Nelson 

commit 58cc9c9a175885bbf6bae3acf18233d0a8229a84 upstream.

To quote from section 1.3.1 of the data sheet:
The SGTL5000 has an internal reset that is deasserted
8 SYS_MCLK cycles after all power rails have been brought
up. After this time, communication can start

...
1.0us represents 8 SYS_MCLK cycles at the minimum 8.0 MHz SYS_MCLK.

Signed-off-by: Eric Nelson 
Reviewed-by: Fabio Estevam 
Signed-off-by: Mark Brown 
Signed-off-by: Greg Kroah-Hartman 

---
 sound/soc/codecs/sgtl5000.c |3 +++
 1 file changed, 3 insertions(+)

--- a/sound/soc/codecs/sgtl5000.c
+++ b/sound/soc/codecs/sgtl5000.c
@@ -1452,6 +1452,9 @@ static int sgtl5000_i2c_probe(struct i2c
if (ret)
return ret;
 
+   /* Need 8 clocks before I2C accesses */
+   udelay(1);
+
/* read chip information */
ret = regmap_read(sgtl5000->regmap, SGTL5000_CHIP_ID, ®);
if (ret)


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


[PATCH 3.18 31/39] ASoC: atmel_ssc_dai: fix start event for I2S mode

2015-02-09 Thread Greg Kroah-Hartman
3.18-stable review patch.  If anyone has any objections, please let me know.

--

From: Bo Shen 

commit a43bd7e125143b875caae6d4f9938855b440faaf upstream.

According to the I2S specification information as following:
  - WS = 0, channel 1 (left)
  - WS = 1, channel 2 (right)
So, the start event should be TF/RF falling edge.

Reported-by: Songjun Wu 
Signed-off-by: Bo Shen 
Signed-off-by: Mark Brown 
Signed-off-by: Greg Kroah-Hartman 

---
 sound/soc/atmel/atmel_ssc_dai.c |   18 --
 1 file changed, 4 insertions(+), 14 deletions(-)

--- a/sound/soc/atmel/atmel_ssc_dai.c
+++ b/sound/soc/atmel/atmel_ssc_dai.c
@@ -345,7 +345,6 @@ static int atmel_ssc_hw_params(struct sn
struct atmel_pcm_dma_params *dma_params;
int dir, channels, bits;
u32 tfmr, rfmr, tcmr, rcmr;
-   int start_event;
int ret;
int fslen, fslen_ext;
 
@@ -454,19 +453,10 @@ static int atmel_ssc_hw_params(struct sn
 * The SSC transmit clock is obtained from the BCLK signal on
 * on the TK line, and the SSC receive clock is
 * generated from the transmit clock.
-*
-*  For single channel data, one sample is transferred
-* on the falling edge of the LRC clock.
-* For two channel data, one sample is
-* transferred on both edges of the LRC clock.
 */
-   start_event = ((channels == 1)
-   ? SSC_START_FALLING_RF
-   : SSC_START_EDGE_RF);
-
rcmr =SSC_BF(RCMR_PERIOD, 0)
| SSC_BF(RCMR_STTDLY, START_DELAY)
-   | SSC_BF(RCMR_START, start_event)
+   | SSC_BF(RCMR_START, SSC_START_FALLING_RF)
| SSC_BF(RCMR_CKI, SSC_CKI_RISING)
| SSC_BF(RCMR_CKO, SSC_CKO_NONE)
| SSC_BF(RCMR_CKS, ssc->clk_from_rk_pin ?
@@ -475,14 +465,14 @@ static int atmel_ssc_hw_params(struct sn
rfmr =SSC_BF(RFMR_FSEDGE, SSC_FSEDGE_POSITIVE)
| SSC_BF(RFMR_FSOS, SSC_FSOS_NONE)
| SSC_BF(RFMR_FSLEN, 0)
-   | SSC_BF(RFMR_DATNB, 0)
+   | SSC_BF(RFMR_DATNB, (channels - 1))
| SSC_BIT(RFMR_MSBF)
| SSC_BF(RFMR_LOOP, 0)
| SSC_BF(RFMR_DATLEN, (bits - 1));
 
tcmr =SSC_BF(TCMR_PERIOD, 0)
| SSC_BF(TCMR_STTDLY, START_DELAY)
-   | SSC_BF(TCMR_START, start_event)
+   | SSC_BF(TCMR_START, SSC_START_FALLING_RF)
| SSC_BF(TCMR_CKI, SSC_CKI_FALLING)
| SSC_BF(TCMR_CKO, SSC_CKO_NONE)
| SSC_BF(TCMR_CKS, ssc->clk_from_rk_pin ?
@@ -492,7 +482,7 @@ static int atmel_ssc_hw_params(struct sn
| SSC_BF(TFMR_FSDEN, 0)
| SSC_BF(TFMR_FSOS, SSC_FSOS_NONE)
| SSC_BF(TFMR_FSLEN, 0)
-   | SSC_BF(TFMR_DATNB, 0)
+   | SSC_BF(TFMR_DATNB, (channels - 1))
| SSC_BIT(TFMR_MSBF)
| SSC_BF(TFMR_DATDEF, 0)
| SSC_BF(TFMR_DATLEN, (bits - 1));


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


[PATCH 3.18 03/39] gpio: mcp23s08: handle default gpio base

2015-02-09 Thread Greg Kroah-Hartman
3.18-stable review patch.  If anyone has any objections, please let me know.

--

From: Sonic Zhang 

commit b184c388f773f30b6c707d3d4599b2db80f4390c upstream.

Create default gpio base if neither device node nor
platform data is defined.

Signed-off-by: Sonic Zhang 
Reviewed-by: Alexandre Courbot 
Tested-by: Antonio Fiol 
Signed-off-by: Linus Walleij 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/gpio/gpio-mcp23s08.c |   17 ++---
 1 file changed, 10 insertions(+), 7 deletions(-)

--- a/drivers/gpio/gpio-mcp23s08.c
+++ b/drivers/gpio/gpio-mcp23s08.c
@@ -785,9 +785,11 @@ static int mcp230xx_probe(struct i2c_cli
client->irq = irq_of_parse_and_map(client->dev.of_node, 0);
} else {
pdata = dev_get_platdata(&client->dev);
-   if (!pdata || !gpio_is_valid(pdata->base)) {
-   dev_dbg(&client->dev, "invalid platform data\n");
-   return -EINVAL;
+   if (!pdata) {
+   pdata = devm_kzalloc(&client->dev,
+   sizeof(struct mcp23s08_platform_data),
+   GFP_KERNEL);
+   pdata->base = -1;
}
}
 
@@ -908,10 +910,11 @@ static int mcp23s08_probe(struct spi_dev
} else {
type = spi_get_device_id(spi)->driver_data;
pdata = dev_get_platdata(&spi->dev);
-   if (!pdata || !gpio_is_valid(pdata->base)) {
-   dev_dbg(&spi->dev,
-   "invalid or missing platform data\n");
-   return -EINVAL;
+   if (!pdata) {
+   pdata = devm_kzalloc(&spi->dev,
+   sizeof(struct mcp23s08_platform_data),
+   GFP_KERNEL);
+   pdata->base = -1;
}
 
for (addr = 0; addr < ARRAY_SIZE(pdata->chip); addr++) {


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


[PATCH 3.18 29/39] arm64: Fix up /proc/cpuinfo

2015-02-09 Thread Greg Kroah-Hartman
3.18-stable review patch.  If anyone has any objections, please let me know.

--

From: Mark Rutland 

commit 44b82b7700d05a52cd983799d3ecde1a976b3bed upstream.

Commit d7a49086f263164a (arm64: cpuinfo: print info for all CPUs)
attempted to clean up /proc/cpuinfo, but due to concerns regarding
further changes was reverted in commit 5e39977edf6500fd (Revert "arm64:
cpuinfo: print info for all CPUs").

There are two major issues with the arm64 /proc/cpuinfo format
currently:

* The "Features" line describes (only) the 64-bit hwcaps, which is
  problematic for some 32-bit applications which attempt to parse it. As
  the same names are used for analogous ISA features (e.g. aes) despite
  these generally being architecturally unrelated, it is not possible to
  simply append the 64-bit and 32-bit hwcaps in a manner that might not
  be misleading to some applications.

  Various potential solutions have appeared in vendor kernels. Typically
  the format of the Features line varies depending on whether the task
  is 32-bit.

* Information is only printed regarding a single CPU. This does not
  match the ARM format, and does not provide sufficient information in
  big.LITTLE systems where CPUs are heterogeneous. The CPU information
  printed is queried from the current CPU's registers, which is racy
  w.r.t. cross-cpu migration.

This patch attempts to solve these issues. The following changes are
made:

* When a task with a LINUX32 personality attempts to read /proc/cpuinfo,
  the "Features" line contains the decoded 32-bit hwcaps, as with the
  arm port. Otherwise, the decoded 64-bit hwcaps are shown. This aligns
  with the behaviour of COMPAT_UTS_MACHINE and COMPAT_ELF_PLATFORM. In
  the absense of compat support, the Features line is empty.

  The set of hwcaps injected into a task's auxval are unaffected.

* Properties are printed per-cpu, as with the ARM port. The per-cpu
  information is queried from pre-recorded cpu information (as used by
  the sanity checks).

* As with the previous attempt at fixing up /proc/cpuinfo, the hardware
  field is removed. The only users so far are 32-bit applications tied
  to particular boards, so no portable applications should be affected,
  and this should prevent future tying to particular boards.

The following differences remain:

* No model_name is printed, as this cannot be queried from the hardware
  and cannot be provided in a stable fashion. Use of the CPU
  {implementor,variant,part,revision} fields is sufficient to identify a
  CPU and is portable across arm and arm64.

* The following system-wide properties are not provided, as they are not
  possible to provide generally. Programs relying on these are already
  tied to particular (32-bit only) boards:
  - Hardware
  - Revision
  - Serial

No software has yet been identified for which these remaining
differences are problematic.

Cc: Greg Hackmann 
Cc: Ian Campbell 
Cc: Serban Constantinescu 
Cc: Will Deacon 
Cc: cross-dis...@lists.linaro.org
Cc: linux-...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Acked-by: Catalin Marinas 
Signed-off-by: Mark Rutland 
Signed-off-by: Will Deacon 
Signed-off-by: Greg Kroah-Hartman 

---
 arch/arm64/kernel/setup.c |   94 ++
 1 file changed, 71 insertions(+), 23 deletions(-)

--- a/arch/arm64/kernel/setup.c
+++ b/arch/arm64/kernel/setup.c
@@ -43,6 +43,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -79,7 +80,6 @@ unsigned int compat_elf_hwcap2 __read_mo
 #endif
 
 static const char *cpu_name;
-static const char *machine_name;
 phys_addr_t __fdt_pointer __initdata;
 
 /*
@@ -311,8 +311,6 @@ static void __init setup_machine_fdt(phy
while (true)
cpu_relax();
}
-
-   machine_name = of_flat_dt_get_machine_name();
 }
 
 /*
@@ -449,14 +447,50 @@ static const char *hwcap_str[] = {
NULL
 };
 
+#ifdef CONFIG_COMPAT
+static const char *compat_hwcap_str[] = {
+   "swp",
+   "half",
+   "thumb",
+   "26bit",
+   "fastmult",
+   "fpa",
+   "vfp",
+   "edsp",
+   "java",
+   "iwmmxt",
+   "crunch",
+   "thumbee",
+   "neon",
+   "vfpv3",
+   "vfpv3d16",
+   "tls",
+   "vfpv4",
+   "idiva",
+   "idivt",
+   "vfpd32",
+   "lpae",
+   "evtstrm"
+};
+
+static const char *compat_hwcap2_str[] = {
+   "aes",
+   "pmull",
+   "sha1",
+   "sha2",
+   "crc32",
+   NULL
+};
+#endif /* CONFIG_COMPAT */
+
 static int c_show(struct seq_file *m, void *v)
 {
-   int i;
-
-   seq_printf(m, "Processor\t: %s rev %d (%s)\n",
-  cpu_name, read_cpuid_id() & 15, ELF_PLATFORM);
+   int i, j;
 
for_each_online_cpu(i) {
+   struct cpuinfo_arm64 *cpuinfo = &per_cpu(cpu_data, i);
+   u32 midr = cpuinfo->reg_midr;
+
/*
 * glibc read

[PATCH 3.18 30/39] lib/checksum.c: fix build for generic csum_tcpudp_nofold

2015-02-09 Thread Greg Kroah-Hartman
3.18-stable review patch.  If anyone has any objections, please let me know.

--

From: karl beldan 

commit 9ce357795ef208faa0d59894d9d119a7434e37f3 upstream.

Fixed commit added from64to32 under _#ifndef do_csum_ but used it
under _#ifndef csum_tcpudp_nofold_, breaking some builds (Fengguang's
robot reported TILEGX's). Move from64to32 under the latter.

Fixes: 150ae0e94634 ("lib/checksum.c: fix carry in csum_tcpudp_nofold")
Reported-by: kbuild test robot 
Signed-off-by: Karl Beldan 
Cc: Eric Dumazet 
Cc: David S. Miller 
Signed-off-by: David S. Miller 
Cc: Guenter Roeck 
Signed-off-by: Greg Kroah-Hartman 

---
 lib/checksum.c |   18 +-
 1 file changed, 9 insertions(+), 9 deletions(-)

--- a/lib/checksum.c
+++ b/lib/checksum.c
@@ -47,15 +47,6 @@ static inline unsigned short from32to16(
return x;
 }
 
-static inline u32 from64to32(u64 x)
-{
-   /* add up 32-bit and 32-bit for 32+c bit */
-   x = (x & 0x) + (x >> 32);
-   /* add up carry.. */
-   x = (x & 0x) + (x >> 32);
-   return (u32)x;
-}
-
 static unsigned int do_csum(const unsigned char *buff, int len)
 {
int odd;
@@ -190,6 +181,15 @@ csum_partial_copy(const void *src, void
 EXPORT_SYMBOL(csum_partial_copy);
 
 #ifndef csum_tcpudp_nofold
+static inline u32 from64to32(u64 x)
+{
+   /* add up 32-bit and 32-bit for 32+c bit */
+   x = (x & 0x) + (x >> 32);
+   /* add up carry.. */
+   x = (x & 0x) + (x >> 32);
+   return (u32)x;
+}
+
 __wsum csum_tcpudp_nofold(__be32 saddr, __be32 daddr,
unsigned short len,
unsigned short proto,


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


[PATCH 3.18 19/39] mm: pagewalk: call pte_hole() for VM_PFNMAP during walk_page_range

2015-02-09 Thread Greg Kroah-Hartman
3.18-stable review patch.  If anyone has any objections, please let me know.

--

From: Shiraz Hashim 

commit 23aaed6659df9adfabe9c583e67a36b54e21df46 upstream.

walk_page_range() silently skips vma having VM_PFNMAP set, which leads
to undesirable behaviour at client end (who called walk_page_range).
Userspace applications get the wrong data, so the effect is like just
confusing users (if the applications just display the data) or sometimes
killing the processes (if the applications do something with
misunderstanding virtual addresses due to the wrong data.)

For example for pagemap_read, when no callbacks are called against
VM_PFNMAP vma, pagemap_read may prepare pagemap data for next virtual
address range at wrong index.

Eventually userspace may get wrong pagemap data for a task.
Corresponding to a VM_PFNMAP marked vma region, kernel may report
mappings from subsequent vma regions.  User space in turn may account
more pages (than really are) to the task.

In my case I was using procmem, procrack (Android utility) which uses
pagemap interface to account RSS pages of a task.  Due to this bug it
was giving a wrong picture for vmas (with VM_PFNMAP set).

Fixes: a9ff785e4437 ("mm/pagewalk.c: walk_page_range should avoid VM_PFNMAP 
areas")
Signed-off-by: Shiraz Hashim 
Acked-by: Naoya Horiguchi 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman 

---
 mm/pagewalk.c |5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

--- a/mm/pagewalk.c
+++ b/mm/pagewalk.c
@@ -199,7 +199,10 @@ int walk_page_range(unsigned long addr,
 */
if ((vma->vm_start <= addr) &&
(vma->vm_flags & VM_PFNMAP)) {
-   next = vma->vm_end;
+   if (walk->pte_hole)
+   err = walk->pte_hole(addr, next, walk);
+   if (err)
+   break;
pgd = pgd_offset(walk->mm, next);
continue;
}


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


[PATCH 3.18 04/39] PCI: designware: Reject MSI-X IRQs

2015-02-09 Thread Greg Kroah-Hartman
3.18-stable review patch.  If anyone has any objections, please let me know.

--

From: Lucas Stach 

commit 19c5392eb1c1e81188e898400c0e8258827eb160 upstream.

The DesignWare PCIe MSI hardware does not support MSI-X IRQs.  Setting
those up failed as a side effect of a bug which was fixed by 91f8ae823f2b
("PCI: designware: Setup and clear exactly one MSI at a time").

Now that this bug is fixed, MSI-X IRQs need to be rejected explicitly;
otherwise devices trying to use them may end up with incorrectly working
interrupts.

Fixes: 91f8ae823f2b ("PCI: designware: Setup and clear exactly one MSI at a 
time")
Signed-off-by: Lucas Stach 
Signed-off-by: Bjorn Helgaas 
Acked-by: Jingoo Han 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/pci/host/pcie-designware.c |3 +++
 1 file changed, 3 insertions(+)

--- a/drivers/pci/host/pcie-designware.c
+++ b/drivers/pci/host/pcie-designware.c
@@ -283,6 +283,9 @@ static int dw_msi_setup_irq(struct msi_c
struct msi_msg msg;
struct pcie_port *pp = sys_to_pcie(pdev->bus->sysdata);
 
+   if (desc->msi_attrib.is_msix)
+   return -EINVAL;
+
irq = assign_irq(1, desc, &pos);
if (irq < 0)
return irq;


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


[PATCH 3.18 00/39] 3.18.7-stable review

2015-02-09 Thread Greg Kroah-Hartman
This is the start of the stable review cycle for the 3.18.7 release.
There are 39 patches in this series, all will be posted as a response
to this one.  If anyone has any issues with these being applied, please
let me know.

Responses should be made by Wed Feb 11 08:33:11 UTC 2015.
Anything received after that time might be too late.

The whole patch series can be found in one patch at:
kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.18.7-rc1.gz
and the diffstat can be found below.

thanks,

greg k-h

-
Pseudo-Shortlog of commits:

Greg Kroah-Hartman 
Linux 3.18.7-rc1

Steven Rostedt (Red Hat) 
x86/tlb/trace: Do not trace on CPU that is offline

Steven Rostedt (Red Hat) 
tracing: Add condition check to RCU lockdep checks

John Stultz 
hrtimer: Fix incorrect tai offset calculation for non high-res timer systems

Lai Jiangshan 
smpboot: Add missing get_online_cpus() in smpboot_register_percpu_thread()

Boris Ostrovsky 
x86, microcode: Return error from driver init code when loader is disabled

Sylwester Nawrocki 
ARM: dts: Fix I2S1, I2S2 compatible for exynos4 SoCs

Takashi Iwai 
ALSA: ak411x: Fix stall in work callback

Eric Nelson 
ASoC: sgtl5000: add delay before first I2C access

Bo Shen 
ASoC: atmel_ssc_dai: fix start event for I2S mode

karl beldan 
lib/checksum.c: fix build for generic csum_tcpudp_nofold

Mark Rutland 
arm64: Fix up /proc/cpuinfo

Peter Kümmel 
kconfig: Fix warning "‘jump’ may be used uninitialized"

Alex Deucher 
drm/radeon: properly set vm fragment size for TN/RL

Ilija Hadzic 
drm/radeon: fix the crash in test functions

Ilija Hadzic 
drm/radeon: fix the crash in benchmark functions

Christian König 
drm/radeon: fix PLLs on RS880 and older v2

Alex Deucher 
drm/radeon: don't init gpuvm if accel is disabled (v3)

Ryusuke Konishi 
nilfs2: fix deadlock of segment constructor over I_SYNC flag

Michal Hocko 
memcg, shmem: fix shmem migration to use lrucare

karl beldan 
lib/checksum.c: fix carry in csum_tcpudp_nofold

Shiraz Hashim 
mm: pagewalk: call pte_hole() for VM_PFNMAP during walk_page_range

NeilBrown 
md/raid5: fix another livelock caused by non-aligned writes.

Sachin Prabhu 
Complete oplock break jobs before closing file handle

Will Deacon 
ARM: 8299/1: mm: ensure local active ASID is marked as allocated on rollover

James Hogan 
MIPS: traps: Fix inline asm ctc1 missing .set hardfloat

James Hogan 
MIPS: mipsregs.h: Add write_32bit_cp1_register()

Hemmo Nieminen 
MIPS: Fix kernel lockup or crash after CPU offline/online

Aaro Koskinen 
MIPS: OCTEON: fix kernel crash when offlining a CPU

Felix Fietkau 
MIPS: IRQ: Fix disable_irq on CPU IRQs

David Daney 
MIPS: Fix C0_Pagegrain[IEC] support.

Brian King 
sd: Fix max transfer length for 4k disks

Robin Gong 
spi: imx: use pio mode for i.mx6dl

Bhuvanchandra DV 
spi: spi-fsl-dspi: Remove usage of devm_kzalloc

Myron Stowe 
PCI: Handle read-only BARs on AMD CS553x devices

Charlotte Richardson 
PCI: Add NEC variants to Stratus ftServer PCIe DMI check

Lucas Stach 
PCI: designware: Reject MSI-X IRQs

Sonic Zhang 
gpio: mcp23s08: handle default gpio base

Johan Hovold 
gpio: sysfs: fix memory leak in gpiod_sysfs_set_active_low

Johan Hovold 
gpio: sysfs: fix memory leak in gpiod_export_link


-

Diffstat:

 Makefile  |  4 +-
 arch/arm/boot/dts/exynos4.dtsi|  4 +-
 arch/arm/mm/context.c | 26 -
 arch/arm64/kernel/setup.c | 96 +++
 arch/mips/cavium-octeon/smp.c |  2 -
 arch/mips/include/asm/mipsregs.h  | 15 +
 arch/mips/kernel/irq_cpu.c|  4 ++
 arch/mips/kernel/smp.c|  2 +-
 arch/mips/kernel/traps.c  |  3 +-
 arch/mips/mm/tlb-r4k.c|  2 +
 arch/x86/kernel/cpu/microcode/core.c  |  2 +-
 arch/x86/pci/common.c | 16 ++
 drivers/gpio/gpio-mcp23s08.c  | 17 +++---
 drivers/gpio/gpiolib-sysfs.c  |  3 +-
 drivers/gpu/drm/radeon/radeon_benchmark.c | 13 +++--
 drivers/gpu/drm/radeon/radeon_display.c   |  3 +
 drivers/gpu/drm/radeon/radeon_gem.c   |  6 +-
 drivers/gpu/drm/radeon/radeon_kms.c   | 16 +++---
 drivers/gpu/drm/radeon/radeon_test.c  |  8 +--
 drivers/gpu/drm/radeon/radeon_vm.c|  6 +-
 drivers/md/raid5.c|  5 ++
 drivers/pci/host/pcie-designware.c|  3 +
 drivers/pci/quirks.c  | 40 -
 drivers/scsi/sd.c |  6 +-
 drivers/spi/spi-fsl-dspi.c| 14 -
 drivers/spi/spi-imx.c |  4 ++
 fs/cifs/file.c|  6 +-
 fs/nilfs2/nilfs.h |  2 -
 fs/nilfs2/segment.c   | 44 --
 fs/

[PATCH 3.18 05/39] PCI: Add NEC variants to Stratus ftServer PCIe DMI check

2015-02-09 Thread Greg Kroah-Hartman
3.18-stable review patch.  If anyone has any objections, please let me know.

--

From: Charlotte Richardson 

commit 51ac3d2f0c505ca36ffc9715ffd518d756589ef8 upstream.

NEC OEMs the same platforms as Stratus does, which have multiple devices on
some PCIe buses under downstream ports.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=51331
Fixes: 1278998f8ff6 ("PCI: Work around Stratus ftServer broken PCIe hierarchy 
(fix DMI check)")
Signed-off-by: Charlotte Richardson 
Signed-off-by: Bjorn Helgaas 
CC: Myron Stowe 
Signed-off-by: Greg Kroah-Hartman 

---
 arch/x86/pci/common.c |   16 
 1 file changed, 16 insertions(+)

--- a/arch/x86/pci/common.c
+++ b/arch/x86/pci/common.c
@@ -448,6 +448,22 @@ static const struct dmi_system_id pcipro
DMI_MATCH(DMI_PRODUCT_NAME, "ftServer"),
},
},
+{
+.callback = set_scan_all,
+.ident = "Stratus/NEC ftServer",
+.matches = {
+DMI_MATCH(DMI_SYS_VENDOR, "NEC"),
+DMI_MATCH(DMI_PRODUCT_NAME, "Express5800/R32"),
+},
+},
+{
+.callback = set_scan_all,
+.ident = "Stratus/NEC ftServer",
+.matches = {
+DMI_MATCH(DMI_SYS_VENDOR, "NEC"),
+DMI_MATCH(DMI_PRODUCT_NAME, "Express5800/R31"),
+},
+},
{}
 };
 


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


[PATCH 3.18 07/39] spi: spi-fsl-dspi: Remove usage of devm_kzalloc

2015-02-09 Thread Greg Kroah-Hartman
3.18-stable review patch.  If anyone has any objections, please let me know.

--

From: Bhuvanchandra DV 

commit 973fbce69ed8e79b5fe3ad19cfecb581a7ef8048 upstream.

devm_* API was supposed to be used only in probe function call.
Memory is allocated at 'probe' and free automatically at 'remove'.
Usage of devm_* functions outside probe sometimes leads to memory leak.
Avoid using devm_kzalloc in dspi_setup_transfer and use kzalloc instead.
Also add the dspi_cleanup function to free the controller data upon
cleanup.

Acked-by: Stefan Agner 
Signed-off-by: Bhuvanchandra DV 
Signed-off-by: Mark Brown 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/spi/spi-fsl-dspi.c |   14 --
 1 file changed, 12 insertions(+), 2 deletions(-)

--- a/drivers/spi/spi-fsl-dspi.c
+++ b/drivers/spi/spi-fsl-dspi.c
@@ -342,8 +342,7 @@ static int dspi_setup_transfer(struct sp
/* Only alloc on first setup */
chip = spi_get_ctldata(spi);
if (chip == NULL) {
-   chip = devm_kzalloc(&spi->dev, sizeof(struct chip_data),
-   GFP_KERNEL);
+   chip = kzalloc(sizeof(struct chip_data), GFP_KERNEL);
if (!chip)
return -ENOMEM;
}
@@ -382,6 +381,16 @@ static int dspi_setup(struct spi_device
return dspi_setup_transfer(spi, NULL);
 }
 
+static void dspi_cleanup(struct spi_device *spi)
+{
+   struct chip_data *chip = spi_get_ctldata((struct spi_device *)spi);
+
+   dev_dbg(&spi->dev, "spi_device %u.%u cleanup\n",
+   spi->master->bus_num, spi->chip_select);
+
+   kfree(chip);
+}
+
 static irqreturn_t dspi_interrupt(int irq, void *dev_id)
 {
struct fsl_dspi *dspi = (struct fsl_dspi *)dev_id;
@@ -467,6 +476,7 @@ static int dspi_probe(struct platform_de
dspi->bitbang.master->setup = dspi_setup;
dspi->bitbang.master->dev.of_node = pdev->dev.of_node;
 
+   master->cleanup = dspi_cleanup;
master->mode_bits = SPI_CPOL | SPI_CPHA;
master->bits_per_word_mask = SPI_BPW_MASK(4) | SPI_BPW_MASK(8) |
SPI_BPW_MASK(16);


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


[PATCH 3.18 06/39] PCI: Handle read-only BARs on AMD CS553x devices

2015-02-09 Thread Greg Kroah-Hartman
3.18-stable review patch.  If anyone has any objections, please let me know.

--

From: Myron Stowe 

commit 06cf35f903aa6da0cc8d9f81e9bcd1f7e1b534bb upstream.

Some AMD CS553x devices have read-only BARs because of a firmware or
hardware defect.  There's a workaround in quirk_cs5536_vsa(), but it no
longer works after 36e8164882ca ("PCI: Restore detection of read-only
BARs").  Prior to 36e8164882ca, we filled in res->start; afterwards we
leave it zeroed out.  The quirk only updated the size, so the driver tried
to use a region starting at zero, which didn't work.

Expand quirk_cs5536_vsa() to read the base addresses from the BARs and
hard-code the sizes.

On Nix's system BAR 2's read-only value is 0x6200.  Prior to 36e8164882ca,
we interpret that as a 512-byte BAR based on the lowest-order bit set.  Per
datasheet sec 5.6.1, that BAR (MFGPT) requires only 64 bytes; use that to
avoid clearing any address bits if a platform uses only 64-byte alignment.

[bhelgaas: changelog, reduce BAR 2 size to 64]
Fixes: 36e8164882ca ("PCI: Restore detection of read-only BARs")
Link: https://bugzilla.kernel.org/show_bug.cgi?id=85991#c4
Link: http://support.amd.com/TechDocs/31506_cs5535_databook.pdf
Link: http://support.amd.com/TechDocs/33238G_cs5536_db.pdf
Reported-and-tested-by: Nix 
Signed-off-by: Myron Stowe 
Signed-off-by: Bjorn Helgaas 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/pci/quirks.c |   40 +---
 1 file changed, 37 insertions(+), 3 deletions(-)

--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -324,18 +324,52 @@ static void quirk_s3_64M(struct pci_dev
 DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_S3, PCI_DEVICE_ID_S3_868,   
quirk_s3_64M);
 DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_S3, PCI_DEVICE_ID_S3_968,   
quirk_s3_64M);
 
+static void quirk_io(struct pci_dev *dev, int pos, unsigned size,
+const char *name)
+{
+   u32 region;
+   struct pci_bus_region bus_region;
+   struct resource *res = dev->resource + pos;
+
+   pci_read_config_dword(dev, PCI_BASE_ADDRESS_0 + (pos << 2), ®ion);
+
+   if (!region)
+   return;
+
+   res->name = pci_name(dev);
+   res->flags = region & ~PCI_BASE_ADDRESS_IO_MASK;
+   res->flags |=
+   (IORESOURCE_IO | IORESOURCE_PCI_FIXED | IORESOURCE_SIZEALIGN);
+   region &= ~(size - 1);
+
+   /* Convert from PCI bus to resource space */
+   bus_region.start = region;
+   bus_region.end = region + size - 1;
+   pcibios_bus_to_resource(dev->bus, res, &bus_region);
+
+   dev_info(&dev->dev, FW_BUG "%s quirk: reg 0x%x: %pR\n",
+name, PCI_BASE_ADDRESS_0 + (pos << 2), res);
+}
+
 /*
  * Some CS5536 BIOSes (for example, the Soekris NET5501 board w/ comBIOS
  * ver. 1.33  20070103) don't set the correct ISA PCI region header info.
  * BAR0 should be 8 bytes; instead, it may be set to something like 8k
  * (which conflicts w/ BAR1's memory range).
+ *
+ * CS553x's ISA PCI BARs may also be read-only (ref:
+ * https://bugzilla.kernel.org/show_bug.cgi?id=85991 - Comment #4 forward).
  */
 static void quirk_cs5536_vsa(struct pci_dev *dev)
 {
+   static char *name = "CS5536 ISA bridge";
+
if (pci_resource_len(dev, 0) != 8) {
-   struct resource *res = &dev->resource[0];
-   res->end = res->start + 8 - 1;
-   dev_info(&dev->dev, "CS5536 ISA bridge bug detected (incorrect 
header); workaround applied\n");
+   quirk_io(dev, 0,   8, name);/* SMB */
+   quirk_io(dev, 1, 256, name);/* GPIO */
+   quirk_io(dev, 2,  64, name);/* MFGPT */
+   dev_info(&dev->dev, "%s bug detected (incorrect header); 
workaround applied\n",
+name);
}
 }
 DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_CS5536_ISA, 
quirk_cs5536_vsa);


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


[PATCH 3.18 14/39] MIPS: mipsregs.h: Add write_32bit_cp1_register()

2015-02-09 Thread Greg Kroah-Hartman
3.18-stable review patch.  If anyone has any objections, please let me know.

--

From: James Hogan 

commit 5e32033e14ca9c7f7341cb383f5a05699b0b5382 upstream.

Add a write_32bit_cp1_register() macro to compliment the
read_32bit_cp1_register() macro. This is to abstract whether .set
hardfloat needs to be used based on GAS_HAS_SET_HARDFLOAT.

The implementation of _read_32bit_cp1_register() .sets mips1 due to
failure of gas v2.19 to assemble cfc1 for Octeon (see commit
25c300030016 ("MIPS: Override assembler target architecture for
octeon.")). I haven't copied this over to _write_32bit_cp1_register() as
I'm uncertain whether it applies to ctc1 too, or whether anybody cares
about that version of binutils any longer.

Signed-off-by: James Hogan 
Cc: Ralf Baechle 
Cc: Paul Burton 
Cc: David Daney 
Cc: linux-m...@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/9172/
Signed-off-by: Ralf Baechle 
Cc: Guenter Roeck 
Signed-off-by: Greg Kroah-Hartman 

---
 arch/mips/include/asm/mipsregs.h |   15 +++
 1 file changed, 15 insertions(+)

--- a/arch/mips/include/asm/mipsregs.h
+++ b/arch/mips/include/asm/mipsregs.h
@@ -1343,12 +1343,27 @@ do {
\
__res;  \
 })
 
+#define _write_32bit_cp1_register(dest, val, gas_hardfloat)\
+do {   \
+   __asm__ __volatile__(   \
+   "   .setpush\n" \
+   "   .setreorder \n" \
+   "   "STR(gas_hardfloat)"\n" \
+   "   ctc1%0,"STR(dest)"  \n" \
+   "   .setpop \n" \
+   : : "r" (val)); \
+} while (0)
+
 #ifdef GAS_HAS_SET_HARDFLOAT
 #define read_32bit_cp1_register(source)
\
_read_32bit_cp1_register(source, .set hardfloat)
+#define write_32bit_cp1_register(dest, val)\
+   _write_32bit_cp1_register(dest, val, .set hardfloat)
 #else
 #define read_32bit_cp1_register(source)
\
_read_32bit_cp1_register(source, )
+#define write_32bit_cp1_register(dest, val)\
+   _write_32bit_cp1_register(dest, val, )
 #endif
 
 #ifdef HAVE_AS_DSP


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


[PATCH 3.18 10/39] MIPS: Fix C0_Pagegrain[IEC] support.

2015-02-09 Thread Greg Kroah-Hartman
3.18-stable review patch.  If anyone has any objections, please let me know.

--

From: David Daney 

commit 9ead8632bbf454cfc709b6205dc9cd8582fb0d64 upstream.

The following commits:

  5890f70f15c52d (MIPS: Use dedicated exception handler if CPU supports RI/XI 
exceptions)
  6575b1d4173eae (MIPS: kernel: cpu-probe: Detect unique RI/XI exceptions)

break the kernel for *all* existing MIPS CPUs that implement the
CP0_PageGrain[IEC] bit.  They cause the TLB exception handlers to be
generated without the legacy execute-inhibit handling, but never set
the CP0_PageGrain[IEC] bit to activate the use of dedicated exception
vectors for execute-inhibit exceptions.  The result is that upon
detection of an execute-inhibit violation, we loop forever in the TLB
exception handlers instead of sending SIGSEGV to the task.

If we are generating TLB exception handlers expecting separate
vectors, we must also enable the CP0_PageGrain[IEC] feature.

The bug was introduced in kernel version 3.17.

Signed-off-by: David Daney 
Cc: Leonid Yegoshin 
Cc: linux-m...@linux-mips.org
Patchwork: http://patchwork.linux-mips.org/patch/8880/
Signed-off-by: Ralf Baechle 
Signed-off-by: Greg Kroah-Hartman 

---
 arch/mips/mm/tlb-r4k.c |2 ++
 1 file changed, 2 insertions(+)

--- a/arch/mips/mm/tlb-r4k.c
+++ b/arch/mips/mm/tlb-r4k.c
@@ -489,6 +489,8 @@ static void r4k_tlb_configure(void)
 #ifdef CONFIG_64BIT
pg |= PG_ELPA;
 #endif
+   if (cpu_has_rixiex)
+   pg |= PG_IEC;
write_c0_pagegrain(pg);
}
 


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


[PATCH 3.18 12/39] MIPS: OCTEON: fix kernel crash when offlining a CPU

2015-02-09 Thread Greg Kroah-Hartman
3.18-stable review patch.  If anyone has any objections, please let me know.

--

From: Aaro Koskinen 

commit 63a87fe0d0de2ce126a8cec9a299a133cfd5658e upstream.

octeon_cpu_disable() will unconditionally enable interrupts when called.
We can assume that the routine is always called with interrupts disabled,
so just delete the incorrect local_irq_disable/enable().

The patch fixes the following crash when offlining a CPU:

[   93.818785] [ cut here ]
[   93.823421] WARNING: CPU: 1 PID: 10 at kernel/smp.c:231 
flush_smp_call_function_queue+0x1c4/0x1d0()
[   93.836215] Modules linked in:
[   93.839287] CPU: 1 PID: 10 Comm: migration/1 Not tainted 
3.19.0-rc4-octeon-los_b5f0 #1
[   93.847212] Stack : 0001 81b2cf90 0004 
8163
     004a
  0006 8117e550  
  81b3 81b26808 800032c77748 81627e07
  81595ec8 81b26808 000a 0001
  0001 0003 10008ce1 815030c8
  800032cbbb38 8113d42c 10008ce1 8117f36c
  800032c77300 800032cbba50 0001 81503984
     
   81121668  
  ...
[   93.912819] Call Trace:
[   93.915273] [] show_stack+0x68/0x80
[   93.920335] [] dump_stack+0x6c/0x90
[   93.925395] [] warn_slowpath_common+0x94/0xd8
[   93.931324] [] flush_smp_call_function_queue+0x1c4/0x1d0
[   93.938208] [] hotplug_cfd+0xf0/0x108
[   93.943444] [] notifier_call_chain+0x5c/0xb8
[   93.949286] [] cpu_notify+0x24/0x60
[   93.954348] [] take_cpu_down+0x38/0x58
[   93.959670] [] multi_cpu_stop+0x154/0x180
[   93.965250] [] cpu_stopper_thread+0xd8/0x160
[   93.971093] [] smpboot_thread_fn+0x1ec/0x1f8
[   93.976936] [] kthread+0xd4/0xf0
[   93.981735] [] ret_from_kernel_thread+0x14/0x1c
[   93.987835]
[   93.989326] ---[ end trace c9e3815ee655bda9 ]---
[   93.993951] Kernel bug detected[#1]:
[   93.997533] CPU: 1 PID: 10 Comm: migration/1 Tainted: GW  
3.19.0-rc4-octeon-los_b5f0 #1
[   94.006591] task: 800032c77300 ti: 800032cb8000 task.ti: 
800032cb8000
[   94.014081] $ 0   :  1ce1 0001 
8162
[   94.022146] $ 4   : 82c72ac0  01a7 
813b06f0
[   94.030210] $ 8   : 813b20d8   
8163
[   94.038275] $12   : 0087  0086 

[   94.046339] $16   : 81623168 0001  
0008
[   94.054405] $20   : 0001 0001 0001 
0003
[   94.062470] $24   : 0038 813b7f10
[   94.070536] $28   : 800032cb8000 800032cbbc20 10008ce1 
811bcaf4
[   94.078601] Hi: 00f188e8
[   94.082179] Lo: d4fdf3b646c09d55
[   94.085760] epc   : 811bc9d0 irq_work_run_list+0x8/0xf8
[   94.091686] Tainted: GW
[   94.095613] ra: 811bcaf4 irq_work_run+0x34/0x60
[   94.101192] Status: 1ce3 KX SX UX KERNEL EXL IE
[   94.106235] Cause : 40808034
[   94.109119] PrId  : 000d9301 (Cavium Octeon II)
[   94.113653] Modules linked in:
[   94.116721] Process migration/1 (pid: 10, threadinfo=800032cb8000, 
task=800032c77300, tls=)
[   94.127168] Stack : 82c74c80 811a4128 0001 
81635720
  fff2 8115bacc 8000320fbce0 8000320fbca4
  8000320fbc80 0002 0004 8113d704
  8000320fbce0 81501738 0003 811b343c
  82c72aa0 82c72aa8 8159cae8 8159caa0
  8165 8000320fbbf0 8000320fbc80 811b32e8
   811b3768 81622b80 815148a8
  800032c77300 82c73e80 815148a8 800032c77300
  81622b80 815148a8 800032c77300 81503f48
  8115ea0c 8162  81174d64
  ...
[   94.192771] Call Trace:
[   94.195222] [] irq_work_run_list+0x8/0xf8
[   94.200802] [] irq_work_run+0x34/0x60
[   94.206036] [] hotplug_cfd+0xf0/0x108
[   94.211269] [] notifier_call_chain+0x5c/0xb8
[   94.217111] [] cpu_notify+0x24/0x60
[   94.222171] [] take_cpu_down+0x38/0x58
[   94.227491] [] multi_cpu_stop+0x154/0x180
[   94.233072] [] cpu_stopper_thread+0xd8/0x160
[   94.238914] [] smpboot_thread_fn+0x1ec/0x1f8
[   94.244757] [] kthread+0xd4/0xf0
[   94.249555] [] ret_from_kernel_thread+0x14/0x

[PATCH 3.18 15/39] MIPS: traps: Fix inline asm ctc1 missing .set hardfloat

2015-02-09 Thread Greg Kroah-Hartman
3.18-stable review patch.  If anyone has any objections, please let me know.

--

From: James Hogan 

commit d76e9b9fc5de7e8fc4fd0e72a94e8c723929ffea upstream.

Commit 842dfc11ea9a ("MIPS: Fix build with binutils 2.24.51+") in v3.18
enabled -msoft-float and sprinkled ".set hardfloat" where necessary to
use FP instructions. However it missed enable_restore_fp_context() which
since v3.17 does a ctc1 with inline assembly, causing the following
assembler errors on Mentor's 2014.05 toolchain:

{standard input}: Assembler messages:
{standard input}:2913: Error: opcode not supported on this processor: mips32r2 
(mips32r2) `ctc1 $2,$31'
scripts/Makefile.build:257: recipe for target 'arch/mips/kernel/traps.o' failed

Fix that to use the new write_32bit_cp1_register() macro so that ".set
hardfloat" is automatically added when -msoft-float is in use.

Fixes 842dfc11ea9a ("MIPS: Fix build with binutils 2.24.51+")
Signed-off-by: James Hogan 
Cc: Ralf Baechle 
Cc: Paul Burton 
Cc: linux-m...@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/9173/
Signed-off-by: Ralf Baechle 
Signed-off-by: Greg Kroah-Hartman 

---
 arch/mips/kernel/traps.c |3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

--- a/arch/mips/kernel/traps.c
+++ b/arch/mips/kernel/traps.c
@@ -1184,7 +1184,8 @@ static int enable_restore_fp_context(int
 
/* Restore the scalar FP control & status register */
if (!was_fpu_owner)
-   asm volatile("ctc1 %0, $31" : : 
"r"(current->thread.fpu.fcr31));
+   write_32bit_cp1_register(CP1_STATUS,
+current->thread.fpu.fcr31);
}
 
 out:


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


[PATCH 3.14 00/20] 3.14.33-stable review

2015-02-09 Thread Greg Kroah-Hartman
This is the start of the stable review cycle for the 3.14.33 release.
There are 20 patches in this series, all will be posted as a response
to this one.  If anyone has any issues with these being applied, please
let me know.

Responses should be made by Wed Feb 11 08:30:18 UTC 2015.
Anything received after that time might be too late.

The whole patch series can be found in one patch at:
kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.14.33-rc1.gz
and the diffstat can be found below.

thanks,

greg k-h

-
Pseudo-Shortlog of commits:

Greg Kroah-Hartman 
Linux 3.14.33-rc1

Andy Lutomirski 
x86,kvm,vmx: Preserve CR4 across VM entry

Lai Jiangshan 
smpboot: Add missing get_online_cpus() in smpboot_register_percpu_thread()

Takashi Iwai 
ALSA: ak411x: Fix stall in work callback

Eric Nelson 
ASoC: sgtl5000: add delay before first I2C access

Bo Shen 
ASoC: atmel_ssc_dai: fix start event for I2S mode

karl beldan 
lib/checksum.c: fix build for generic csum_tcpudp_nofold

Dmitry Monakhov 
ext4: prevent bugon on race between write/fcntl

Mark Rutland 
arm64: Fix up /proc/cpuinfo

Peter Kümmel 
kconfig: Fix warning "‘jump’ may be used uninitialized"

Ryusuke Konishi 
nilfs2: fix deadlock of segment constructor over I_SYNC flag

karl beldan 
lib/checksum.c: fix carry in csum_tcpudp_nofold

Shiraz Hashim 
mm: pagewalk: call pte_hole() for VM_PFNMAP during walk_page_range

Sachin Prabhu 
Complete oplock break jobs before closing file handle

Will Deacon 
ARM: 8299/1: mm: ensure local active ASID is marked as allocated on rollover

Hemmo Nieminen 
MIPS: Fix kernel lockup or crash after CPU offline/online

Aaro Koskinen 
MIPS: OCTEON: fix kernel crash when offlining a CPU

Felix Fietkau 
MIPS: IRQ: Fix disable_irq on CPU IRQs

Charlotte Richardson 
PCI: Add NEC variants to Stratus ftServer PCIe DMI check

Johan Hovold 
gpio: sysfs: fix memory leak in gpiod_sysfs_set_active_low

Johan Hovold 
gpio: sysfs: fix memory leak in gpiod_export_link


-

Diffstat:

 Makefile |  4 +-
 arch/arm/mm/context.c| 26 +--
 arch/arm64/include/asm/cputype.h |  2 +
 arch/arm64/kernel/setup.c| 99 +---
 arch/arm64/kernel/smp.c  |  5 ++
 arch/mips/cavium-octeon/smp.c|  2 -
 arch/mips/kernel/irq_cpu.c   |  4 ++
 arch/mips/kernel/smp.c   |  2 +-
 arch/x86/kvm/vmx.c   | 16 ++-
 arch/x86/pci/common.c| 16 +++
 drivers/gpio/gpiolib.c   |  3 +-
 fs/cifs/file.c   |  6 ++-
 fs/ext4/file.c   |  8 ++--
 fs/nilfs2/nilfs.h|  2 -
 fs/nilfs2/segment.c  | 44 --
 fs/nilfs2/segment.h  |  5 ++
 include/sound/ak4113.h   |  2 +-
 include/sound/ak4114.h   |  2 +-
 kernel/smpboot.c |  2 +
 lib/checksum.c   | 12 -
 mm/pagewalk.c|  5 +-
 scripts/kconfig/menu.c   |  4 +-
 sound/i2c/other/ak4113.c | 17 ---
 sound/i2c/other/ak4114.c | 18 
 sound/soc/atmel/atmel_ssc_dai.c  | 18 ++--
 sound/soc/codecs/sgtl5000.c  |  3 ++
 26 files changed, 226 insertions(+), 101 deletions(-)


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


[PATCH 3.18 01/39] gpio: sysfs: fix memory leak in gpiod_export_link

2015-02-09 Thread Greg Kroah-Hartman
3.18-stable review patch.  If anyone has any objections, please let me know.

--

From: Johan Hovold 

commit 0f303db08df0df9bd0966443ad6001e63960af16 upstream.

Fix memory leak in the gpio sysfs interface due to failure to drop
reference to device returned by class_find_device when creating a link.

Fixes: a4177ee7f1a8 ("gpiolib: allow exported GPIO nodes to be named using 
sysfs links")
Signed-off-by: Johan Hovold 
Signed-off-by: Linus Walleij 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/gpio/gpiolib-sysfs.c |1 +
 1 file changed, 1 insertion(+)

--- a/drivers/gpio/gpiolib-sysfs.c
+++ b/drivers/gpio/gpiolib-sysfs.c
@@ -630,6 +630,7 @@ int gpiod_export_link(struct device *dev
if (tdev != NULL) {
status = sysfs_create_link(&dev->kobj, &tdev->kobj,
name);
+   put_device(tdev);
} else {
status = -ENODEV;
}


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


[PATCH 3.18 17/39] Complete oplock break jobs before closing file handle

2015-02-09 Thread Greg Kroah-Hartman
3.18-stable review patch.  If anyone has any objections, please let me know.

--

From: Sachin Prabhu 

commit ca7df8e0bb2a5ec79691de8a1a4c0e611fe04e60 upstream.

Commit
c11f1df5003d534fd067f0168bfad7befffb3b5c
requires writers to wait for any pending oplock break handler to
complete before proceeding to write. This is done by waiting on bit
CIFS_INODE_PENDING_OPLOCK_BREAK in cifsFileInfo->flags. This bit is
cleared by the oplock break handler job queued on the workqueue once it
has completed handling the oplock break allowing writers to proceed with
writing to the file.

While testing, it was noticed that the filehandle could be closed while
there is a pending oplock break which results in the oplock break
handler on the cifsiod workqueue being cancelled before it has had a
chance to execute and clear the CIFS_INODE_PENDING_OPLOCK_BREAK bit.
Any subsequent attempt to write to this file hangs waiting for the
CIFS_INODE_PENDING_OPLOCK_BREAK bit to be cleared.

We fix this by ensuring that we also clear the bit
CIFS_INODE_PENDING_OPLOCK_BREAK when we remove the oplock break handler
from the workqueue.

The bug was found by Red Hat QA while testing using ltp's fsstress
command.

Signed-off-by: Sachin Prabhu 
Acked-by: Shirish Pargaonkar 
Signed-off-by: Jeff Layton 
Signed-off-by: Steve French 
Signed-off-by: Greg Kroah-Hartman 

---
 fs/cifs/file.c |6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

--- a/fs/cifs/file.c
+++ b/fs/cifs/file.c
@@ -366,6 +366,7 @@ void cifsFileInfo_put(struct cifsFileInf
struct cifsLockInfo *li, *tmp;
struct cifs_fid fid;
struct cifs_pending_open open;
+   bool oplock_break_cancelled;
 
spin_lock(&cifs_file_list_lock);
if (--cifs_file->count > 0) {
@@ -397,7 +398,7 @@ void cifsFileInfo_put(struct cifsFileInf
}
spin_unlock(&cifs_file_list_lock);
 
-   cancel_work_sync(&cifs_file->oplock_break);
+   oplock_break_cancelled = cancel_work_sync(&cifs_file->oplock_break);
 
if (!tcon->need_reconnect && !cifs_file->invalidHandle) {
struct TCP_Server_Info *server = tcon->ses->server;
@@ -409,6 +410,9 @@ void cifsFileInfo_put(struct cifsFileInf
_free_xid(xid);
}
 
+   if (oplock_break_cancelled)
+   cifs_done_oplock_break(cifsi);
+
cifs_del_pending_open(&open);
 
/*


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


[PATCH 3.14 08/20] Complete oplock break jobs before closing file handle

2015-02-09 Thread Greg Kroah-Hartman
3.14-stable review patch.  If anyone has any objections, please let me know.

--

From: Sachin Prabhu 

commit ca7df8e0bb2a5ec79691de8a1a4c0e611fe04e60 upstream.

Commit
c11f1df5003d534fd067f0168bfad7befffb3b5c
requires writers to wait for any pending oplock break handler to
complete before proceeding to write. This is done by waiting on bit
CIFS_INODE_PENDING_OPLOCK_BREAK in cifsFileInfo->flags. This bit is
cleared by the oplock break handler job queued on the workqueue once it
has completed handling the oplock break allowing writers to proceed with
writing to the file.

While testing, it was noticed that the filehandle could be closed while
there is a pending oplock break which results in the oplock break
handler on the cifsiod workqueue being cancelled before it has had a
chance to execute and clear the CIFS_INODE_PENDING_OPLOCK_BREAK bit.
Any subsequent attempt to write to this file hangs waiting for the
CIFS_INODE_PENDING_OPLOCK_BREAK bit to be cleared.

We fix this by ensuring that we also clear the bit
CIFS_INODE_PENDING_OPLOCK_BREAK when we remove the oplock break handler
from the workqueue.

The bug was found by Red Hat QA while testing using ltp's fsstress
command.

Signed-off-by: Sachin Prabhu 
Acked-by: Shirish Pargaonkar 
Signed-off-by: Jeff Layton 
Signed-off-by: Steve French 
Signed-off-by: Greg Kroah-Hartman 

---
 fs/cifs/file.c |6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

--- a/fs/cifs/file.c
+++ b/fs/cifs/file.c
@@ -366,6 +366,7 @@ void cifsFileInfo_put(struct cifsFileInf
struct cifsLockInfo *li, *tmp;
struct cifs_fid fid;
struct cifs_pending_open open;
+   bool oplock_break_cancelled;
 
spin_lock(&cifs_file_list_lock);
if (--cifs_file->count > 0) {
@@ -397,7 +398,7 @@ void cifsFileInfo_put(struct cifsFileInf
}
spin_unlock(&cifs_file_list_lock);
 
-   cancel_work_sync(&cifs_file->oplock_break);
+   oplock_break_cancelled = cancel_work_sync(&cifs_file->oplock_break);
 
if (!tcon->need_reconnect && !cifs_file->invalidHandle) {
struct TCP_Server_Info *server = tcon->ses->server;
@@ -409,6 +410,9 @@ void cifsFileInfo_put(struct cifsFileInf
_free_xid(xid);
}
 
+   if (oplock_break_cancelled)
+   cifs_done_oplock_break(cifsi);
+
cifs_del_pending_open(&open);
 
/*


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


[LKP] [nfs] mount.nfs: an incorrect mount option was specified

2015-02-09 Thread Huang Ying
FYI, we noticed the below changes on

git://git.infradead.org/users/hch/pnfs.git pnfs-testing
commit 418f5019f1a8cd6fc50db11303e5a9297522d814 ("nfs: force version 4.1")

Our test script uses the following command line:

$ mount.nfs -o v3,nolock  

And found something as follow in the stderr after the commit

mount.nfs: an incorrect mount option was specified

Thanks,
Huang, Ying

#
# Automatically generated file; DO NOT EDIT.
# Linux/x86_64 3.19.0-rc4 Kernel Configuration
#
CONFIG_64BIT=y
CONFIG_X86_64=y
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
CONFIG_PERF_EVENTS_INTEL_UNCORE=y
CONFIG_OUTPUT_FORMAT="elf64-x86-64"
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/x86_64_defconfig"
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_HAVE_LATENCYTOP_SUPPORT=y
CONFIG_MMU=y
CONFIG_NEED_DMA_MAP_STATE=y
CONFIG_NEED_SG_DMA_LENGTH=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_BUG_RELATIVE_POINTERS=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_ARCH_HAS_CPU_RELAX=y
CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
CONFIG_HAVE_SETUP_PER_CPU_AREA=y
CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y
CONFIG_ARCH_WANT_GENERAL_HUGETLB=y
CONFIG_ZONE_DMA32=y
CONFIG_AUDIT_ARCH=y
CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
CONFIG_X86_64_SMP=y
CONFIG_X86_HT=y
CONFIG_ARCH_HWEIGHT_CFLAGS="-fcall-saved-rdi -fcall-saved-rsi -fcall-saved-rdx 
-fcall-saved-rcx -fcall-saved-r8 -fcall-saved-r9 -fcall-saved-r10 
-fcall-saved-r11"
CONFIG_ARCH_SUPPORTS_UPROBES=y
CONFIG_FIX_EARLYCON_MEM=y
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_EXTABLE_SORT=y

#
# General setup
#
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_CROSS_COMPILE=""
# CONFIG_COMPILE_TEST is not set
CONFIG_LOCALVERSION=""
CONFIG_LOCALVERSION_AUTO=y
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_BZIP2=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_XZ=y
CONFIG_HAVE_KERNEL_LZO=y
CONFIG_HAVE_KERNEL_LZ4=y
CONFIG_KERNEL_GZIP=y
# CONFIG_KERNEL_BZIP2 is not set
# CONFIG_KERNEL_LZMA is not set
# CONFIG_KERNEL_XZ is not set
# CONFIG_KERNEL_LZO is not set
# CONFIG_KERNEL_LZ4 is not set
CONFIG_DEFAULT_HOSTNAME="(none)"
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SYSCTL=y
CONFIG_POSIX_MQUEUE=y
CONFIG_POSIX_MQUEUE_SYSCTL=y
CONFIG_CROSS_MEMORY_ATTACH=y
# CONFIG_FHANDLE is not set
CONFIG_USELIB=y
CONFIG_AUDIT=y
CONFIG_HAVE_ARCH_AUDITSYSCALL=y
CONFIG_AUDITSYSCALL=y
CONFIG_AUDIT_WATCH=y
CONFIG_AUDIT_TREE=y

#
# IRQ subsystem
#
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_IRQ_SHOW=y
CONFIG_GENERIC_IRQ_LEGACY_ALLOC_HWIRQ=y
CONFIG_GENERIC_PENDING_IRQ=y
CONFIG_IRQ_DOMAIN=y
CONFIG_GENERIC_MSI_IRQ=y
# CONFIG_IRQ_DOMAIN_DEBUG is not set
CONFIG_IRQ_FORCED_THREADING=y
CONFIG_SPARSE_IRQ=y
CONFIG_CLOCKSOURCE_WATCHDOG=y
CONFIG_ARCH_CLOCKSOURCE_DATA=y
CONFIG_CLOCKSOURCE_VALIDATE_LAST_CYCLE=y
CONFIG_GENERIC_TIME_VSYSCALL=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_GENERIC_CLOCKEVENTS_BUILD=y
CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y
CONFIG_GENERIC_CLOCKEVENTS_MIN_ADJUST=y
CONFIG_GENERIC_CMOS_UPDATE=y

#
# Timers subsystem
#
CONFIG_TICK_ONESHOT=y
CONFIG_NO_HZ_COMMON=y
# CONFIG_HZ_PERIODIC is not set
CONFIG_NO_HZ_IDLE=y
# CONFIG_NO_HZ_FULL is not set
CONFIG_NO_HZ=y
CONFIG_HIGH_RES_TIMERS=y

#
# CPU/Task time and stats accounting
#
CONFIG_TICK_CPU_ACCOUNTING=y
# CONFIG_VIRT_CPU_ACCOUNTING_GEN is not set
# CONFIG_IRQ_TIME_ACCOUNTING is not set
CONFIG_BSD_PROCESS_ACCT=y
CONFIG_BSD_PROCESS_ACCT_V3=y
CONFIG_TASKSTATS=y
CONFIG_TASK_DELAY_ACCT=y
CONFIG_TASK_XACCT=y
CONFIG_TASK_IO_ACCOUNTING=y

#
# RCU Subsystem
#
CONFIG_TREE_RCU=y
# CONFIG_TASKS_RCU is not set
CONFIG_RCU_STALL_COMMON=y
# CONFIG_RCU_USER_QS is not set
CONFIG_RCU_FANOUT=64
CONFIG_RCU_FANOUT_LEAF=16
# CONFIG_RCU_FANOUT_EXACT is not set
# CONFIG_RCU_FAST_NO_HZ is not set
CONFIG_TREE_RCU_TRACE=y
# CONFIG_RCU_NOCB_CPU is not set
CONFIG_BUILD_BIN2C=y
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
CONFIG_LOG_BUF_SHIFT=18
CONFIG_LOG_CPU_MAX_BUF_SHIFT=12
CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y
CONFIG_ARCH_SUPPORTS_NUMA_BALANCING=y
CONFIG_ARCH_SUPPORTS_INT128=y
# CONFIG_NUMA_BALANCING is not set
CONFIG_CGROUPS=y
CONFIG_CGROUP_DEBUG=y
CONFIG_CGROUP_FREEZER=y
CONFIG_CGROUP_DEVICE=y
CONFIG_CPUSETS=y
CONFIG_PROC_PID_CPUSET=y
# CONFIG_CGROUP_CPUACCT is not set
# CONFIG_MEMCG is not set
# CONFIG_CGROUP_HUGETLB is not set
# CONFIG_CGROUP_PERF is not set
CONFIG_CGROUP_SCHED=y
CONFIG_FAIR_GROUP_SCHED=y
# CONFIG_CFS_BANDWIDTH is not set
# CONFIG_RT_GROUP_SCHED is not set
CONFIG_BLK_CGROUP=y
CONFIG_DEBUG_BLK_CGROUP=y
# CONFIG_CHECKPOINT_RESTORE is not set
# CONFIG_NAMESPACES is not set
CONFIG_SCHED_AUTOGROUP=y
# CONFIG_SYSFS_DEPRECATED is not set
CONFIG_RELAY=y
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE=""
CONFIG_RD_GZIP=y
# CONFIG_RD_BZIP2 is not set
# CONFIG_RD_LZMA is not set
# CONFIG_RD_XZ is not set
#

[PATCH 3.14 02/20] gpio: sysfs: fix memory leak in gpiod_sysfs_set_active_low

2015-02-09 Thread Greg Kroah-Hartman
3.14-stable review patch.  If anyone has any objections, please let me know.

--

From: Johan Hovold 

commit 49d2ca84e433dab854c7a866bc6add09cfab682d upstream.

Fix memory leak in the gpio sysfs interface due to failure to drop
reference to device returned by class_find_device when setting the
gpio-line polarity.

Fixes: 0769746183ca ("gpiolib: add support for changing value polarity in 
sysfs")
Signed-off-by: Johan Hovold 
Signed-off-by: Linus Walleij 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/gpio/gpiolib.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -959,7 +959,7 @@ int gpiod_sysfs_set_active_low(struct gp
}
 
status = sysfs_set_active_low(desc, dev, value);
-
+   put_device(dev);
 unlock:
mutex_unlock(&sysfs_lock);
 


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


[PATCH 3.14 19/20] smpboot: Add missing get_online_cpus() in smpboot_register_percpu_thread()

2015-02-09 Thread Greg Kroah-Hartman
3.14-stable review patch.  If anyone has any objections, please let me know.

--

From: Lai Jiangshan 

commit 4bee96860a65c3a62d332edac331b3cf936ba3ad upstream.

The following race exists in the smpboot percpu threads management:

CPU0 CPU1
cpu_up(2)
  get_online_cpus();
  smpboot_create_threads(2);
 smpboot_register_percpu_thread();
 for_each_online_cpu();
   __smpboot_create_thread();
  __cpu_up(2);

This results in a missing per cpu thread for the newly onlined cpu2 and
in a NULL pointer dereference on a consecutive offline of that cpu.

Proctect smpboot_register_percpu_thread() with get_online_cpus() to
prevent that.

[ tglx: Massaged changelog and removed the change in
smpboot_unregister_percpu_thread() because that's an
optimization and therefor not stable material. ]

Signed-off-by: Lai Jiangshan 
Cc: Thomas Gleixner 
Cc: Rusty Russell 
Cc: Peter Zijlstra 
Cc: Srivatsa S. Bhat 
Cc: David Rientjes 
Link: 
http://lkml.kernel.org/r/1406777421-12830-1-git-send-email-la...@cn.fujitsu.com
Signed-off-by: Thomas Gleixner 
Signed-off-by: Greg Kroah-Hartman 

---
 kernel/smpboot.c |2 ++
 1 file changed, 2 insertions(+)

--- a/kernel/smpboot.c
+++ b/kernel/smpboot.c
@@ -279,6 +279,7 @@ int smpboot_register_percpu_thread(struc
unsigned int cpu;
int ret = 0;
 
+   get_online_cpus();
mutex_lock(&smpboot_threads_lock);
for_each_online_cpu(cpu) {
ret = __smpboot_create_thread(plug_thread, cpu);
@@ -291,6 +292,7 @@ int smpboot_register_percpu_thread(struc
list_add(&plug_thread->list, &hotplug_threads);
 out:
mutex_unlock(&smpboot_threads_lock);
+   put_online_cpus();
return ret;
 }
 EXPORT_SYMBOL_GPL(smpboot_register_percpu_thread);


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


[PATCH 3.14 20/20] x86,kvm,vmx: Preserve CR4 across VM entry

2015-02-09 Thread Greg Kroah-Hartman
3.14-stable review patch.  If anyone has any objections, please let me know.

--

From: Andy Lutomirski 

commit d974baa398f34393db76be45f7d4d04fbdbb4a0a upstream.

CR4 isn't constant; at least the TSD and PCE bits can vary.

TBH, treating CR0 and CR3 as constant scares me a bit, too, but it looks
like it's correct.

This adds a branch and a read from cr4 to each vm entry.  Because it is
extremely likely that consecutive entries into the same vcpu will have
the same host cr4 value, this fixes up the vmcs instead of restoring cr4
after the fact.  A subsequent patch will add a kernel-wide cr4 shadow,
reducing the overhead in the common case to just two memory reads and a
branch.

Signed-off-by: Andy Lutomirski 
Acked-by: Paolo Bonzini 
Cc: Petr Matousek 
Cc: Gleb Natapov 
Signed-off-by: Linus Torvalds 
[wangkai: Backport to 3.10: adjust context]
Signed-off-by: Wang Kai 
Signed-off-by: Greg Kroah-Hartman 
---
 arch/x86/kvm/vmx.c |   16 ++--
 1 file changed, 14 insertions(+), 2 deletions(-)

--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -441,6 +441,7 @@ struct vcpu_vmx {
 #endif
int   gs_ldt_reload_needed;
int   fs_reload_needed;
+   unsigned long vmcs_host_cr4;/* May not match real cr4 */
} host_state;
struct {
int vm86_active;
@@ -4165,11 +4166,16 @@ static void vmx_set_constant_host_state(
u32 low32, high32;
unsigned long tmpl;
struct desc_ptr dt;
+   unsigned long cr4;
 
vmcs_writel(HOST_CR0, read_cr0() & ~X86_CR0_TS);  /* 22.2.3 */
-   vmcs_writel(HOST_CR4, read_cr4());  /* 22.2.3, 22.2.5 */
vmcs_writel(HOST_CR3, read_cr3());  /* 22.2.3  FIXME: shadow tables */
 
+   /* Save the most likely value for this task's CR4 in the VMCS. */
+   cr4 = read_cr4();
+   vmcs_writel(HOST_CR4, cr4); /* 22.2.3, 22.2.5 */
+   vmx->host_state.vmcs_host_cr4 = cr4;
+
vmcs_write16(HOST_CS_SELECTOR, __KERNEL_CS);  /* 22.2.4 */
 #ifdef CONFIG_X86_64
/*
@@ -7196,7 +7202,7 @@ static void atomic_switch_perf_msrs(stru
 static void __noclone vmx_vcpu_run(struct kvm_vcpu *vcpu)
 {
struct vcpu_vmx *vmx = to_vmx(vcpu);
-   unsigned long debugctlmsr;
+   unsigned long debugctlmsr, cr4;
 
/* Record the guest's net vcpu time for enforced NMI injections. */
if (unlikely(!cpu_has_virtual_nmis() && vmx->soft_vnmi_blocked))
@@ -7217,6 +7223,12 @@ static void __noclone vmx_vcpu_run(struc
if (test_bit(VCPU_REGS_RIP, (unsigned long *)&vcpu->arch.regs_dirty))
vmcs_writel(GUEST_RIP, vcpu->arch.regs[VCPU_REGS_RIP]);
 
+   cr4 = read_cr4();
+   if (unlikely(cr4 != vmx->host_state.vmcs_host_cr4)) {
+   vmcs_writel(HOST_CR4, cr4);
+   vmx->host_state.vmcs_host_cr4 = cr4;
+   }
+
/* When single-stepping over STI and MOV SS, we must clear the
 * corresponding interruptibility bits in the guest state. Otherwise
 * vmentry fails as it then expects bit 14 (BS) in pending debug


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


[PATCH 3.14 04/20] MIPS: IRQ: Fix disable_irq on CPU IRQs

2015-02-09 Thread Greg Kroah-Hartman
3.14-stable review patch.  If anyone has any objections, please let me know.

--

From: Felix Fietkau 

commit a3e6c1eff54878506b2dddcc202df9cc8180facb upstream.

If the irq_chip does not define .irq_disable, any call to disable_irq
will defer disabling the IRQ until it fires while marked as disabled.
This assumes that the handler function checks for this condition, which
handle_percpu_irq does not. In this case, calling disable_irq leads to
an IRQ storm, if the interrupt fires while disabled.

This optimization is only useful when disabling the IRQ is slow, which
is not true for the MIPS CPU IRQ.

Disable this optimization by implementing .irq_disable and .irq_enable

Signed-off-by: Felix Fietkau 
Cc: linux-m...@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/8949/
Signed-off-by: Ralf Baechle 
Signed-off-by: Greg Kroah-Hartman 

---
 arch/mips/kernel/irq_cpu.c |4 
 1 file changed, 4 insertions(+)

--- a/arch/mips/kernel/irq_cpu.c
+++ b/arch/mips/kernel/irq_cpu.c
@@ -56,6 +56,8 @@ static struct irq_chip mips_cpu_irq_cont
.irq_mask_ack   = mask_mips_irq,
.irq_unmask = unmask_mips_irq,
.irq_eoi= unmask_mips_irq,
+   .irq_disable= mask_mips_irq,
+   .irq_enable = unmask_mips_irq,
 };
 
 /*
@@ -92,6 +94,8 @@ static struct irq_chip mips_mt_cpu_irq_c
.irq_mask_ack   = mips_mt_cpu_irq_ack,
.irq_unmask = unmask_mips_irq,
.irq_eoi= unmask_mips_irq,
+   .irq_disable= mask_mips_irq,
+   .irq_enable = unmask_mips_irq,
 };
 
 void __init mips_cpu_irq_init(void)


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


[PATCH 3.14 03/20] PCI: Add NEC variants to Stratus ftServer PCIe DMI check

2015-02-09 Thread Greg Kroah-Hartman
3.14-stable review patch.  If anyone has any objections, please let me know.

--

From: Charlotte Richardson 

commit 51ac3d2f0c505ca36ffc9715ffd518d756589ef8 upstream.

NEC OEMs the same platforms as Stratus does, which have multiple devices on
some PCIe buses under downstream ports.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=51331
Fixes: 1278998f8ff6 ("PCI: Work around Stratus ftServer broken PCIe hierarchy 
(fix DMI check)")
Signed-off-by: Charlotte Richardson 
Signed-off-by: Bjorn Helgaas 
CC: Myron Stowe 
Signed-off-by: Greg Kroah-Hartman 

---
 arch/x86/pci/common.c |   16 
 1 file changed, 16 insertions(+)

--- a/arch/x86/pci/common.c
+++ b/arch/x86/pci/common.c
@@ -448,6 +448,22 @@ static const struct dmi_system_id pcipro
DMI_MATCH(DMI_PRODUCT_NAME, "ftServer"),
},
},
+{
+.callback = set_scan_all,
+.ident = "Stratus/NEC ftServer",
+.matches = {
+DMI_MATCH(DMI_SYS_VENDOR, "NEC"),
+DMI_MATCH(DMI_PRODUCT_NAME, "Express5800/R32"),
+},
+},
+{
+.callback = set_scan_all,
+.ident = "Stratus/NEC ftServer",
+.matches = {
+DMI_MATCH(DMI_SYS_VENDOR, "NEC"),
+DMI_MATCH(DMI_PRODUCT_NAME, "Express5800/R31"),
+},
+},
{}
 };
 


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


[PATCH 3.14 05/20] MIPS: OCTEON: fix kernel crash when offlining a CPU

2015-02-09 Thread Greg Kroah-Hartman
3.14-stable review patch.  If anyone has any objections, please let me know.

--

From: Aaro Koskinen 

commit 63a87fe0d0de2ce126a8cec9a299a133cfd5658e upstream.

octeon_cpu_disable() will unconditionally enable interrupts when called.
We can assume that the routine is always called with interrupts disabled,
so just delete the incorrect local_irq_disable/enable().

The patch fixes the following crash when offlining a CPU:

[   93.818785] [ cut here ]
[   93.823421] WARNING: CPU: 1 PID: 10 at kernel/smp.c:231 
flush_smp_call_function_queue+0x1c4/0x1d0()
[   93.836215] Modules linked in:
[   93.839287] CPU: 1 PID: 10 Comm: migration/1 Not tainted 
3.19.0-rc4-octeon-los_b5f0 #1
[   93.847212] Stack : 0001 81b2cf90 0004 
8163
     004a
  0006 8117e550  
  81b3 81b26808 800032c77748 81627e07
  81595ec8 81b26808 000a 0001
  0001 0003 10008ce1 815030c8
  800032cbbb38 8113d42c 10008ce1 8117f36c
  800032c77300 800032cbba50 0001 81503984
     
   81121668  
  ...
[   93.912819] Call Trace:
[   93.915273] [] show_stack+0x68/0x80
[   93.920335] [] dump_stack+0x6c/0x90
[   93.925395] [] warn_slowpath_common+0x94/0xd8
[   93.931324] [] flush_smp_call_function_queue+0x1c4/0x1d0
[   93.938208] [] hotplug_cfd+0xf0/0x108
[   93.943444] [] notifier_call_chain+0x5c/0xb8
[   93.949286] [] cpu_notify+0x24/0x60
[   93.954348] [] take_cpu_down+0x38/0x58
[   93.959670] [] multi_cpu_stop+0x154/0x180
[   93.965250] [] cpu_stopper_thread+0xd8/0x160
[   93.971093] [] smpboot_thread_fn+0x1ec/0x1f8
[   93.976936] [] kthread+0xd4/0xf0
[   93.981735] [] ret_from_kernel_thread+0x14/0x1c
[   93.987835]
[   93.989326] ---[ end trace c9e3815ee655bda9 ]---
[   93.993951] Kernel bug detected[#1]:
[   93.997533] CPU: 1 PID: 10 Comm: migration/1 Tainted: GW  
3.19.0-rc4-octeon-los_b5f0 #1
[   94.006591] task: 800032c77300 ti: 800032cb8000 task.ti: 
800032cb8000
[   94.014081] $ 0   :  1ce1 0001 
8162
[   94.022146] $ 4   : 82c72ac0  01a7 
813b06f0
[   94.030210] $ 8   : 813b20d8   
8163
[   94.038275] $12   : 0087  0086 

[   94.046339] $16   : 81623168 0001  
0008
[   94.054405] $20   : 0001 0001 0001 
0003
[   94.062470] $24   : 0038 813b7f10
[   94.070536] $28   : 800032cb8000 800032cbbc20 10008ce1 
811bcaf4
[   94.078601] Hi: 00f188e8
[   94.082179] Lo: d4fdf3b646c09d55
[   94.085760] epc   : 811bc9d0 irq_work_run_list+0x8/0xf8
[   94.091686] Tainted: GW
[   94.095613] ra: 811bcaf4 irq_work_run+0x34/0x60
[   94.101192] Status: 1ce3 KX SX UX KERNEL EXL IE
[   94.106235] Cause : 40808034
[   94.109119] PrId  : 000d9301 (Cavium Octeon II)
[   94.113653] Modules linked in:
[   94.116721] Process migration/1 (pid: 10, threadinfo=800032cb8000, 
task=800032c77300, tls=)
[   94.127168] Stack : 82c74c80 811a4128 0001 
81635720
  fff2 8115bacc 8000320fbce0 8000320fbca4
  8000320fbc80 0002 0004 8113d704
  8000320fbce0 81501738 0003 811b343c
  82c72aa0 82c72aa8 8159cae8 8159caa0
  8165 8000320fbbf0 8000320fbc80 811b32e8
   811b3768 81622b80 815148a8
  800032c77300 82c73e80 815148a8 800032c77300
  81622b80 815148a8 800032c77300 81503f48
  8115ea0c 8162  81174d64
  ...
[   94.192771] Call Trace:
[   94.195222] [] irq_work_run_list+0x8/0xf8
[   94.200802] [] irq_work_run+0x34/0x60
[   94.206036] [] hotplug_cfd+0xf0/0x108
[   94.211269] [] notifier_call_chain+0x5c/0xb8
[   94.217111] [] cpu_notify+0x24/0x60
[   94.222171] [] take_cpu_down+0x38/0x58
[   94.227491] [] multi_cpu_stop+0x154/0x180
[   94.233072] [] cpu_stopper_thread+0xd8/0x160
[   94.238914] [] smpboot_thread_fn+0x1ec/0x1f8
[   94.244757] [] kthread+0xd4/0xf0
[   94.249555] [] ret_from_kernel_thread+0x14/0x

[PATCH 3.14 06/20] MIPS: Fix kernel lockup or crash after CPU offline/online

2015-02-09 Thread Greg Kroah-Hartman
3.14-stable review patch.  If anyone has any objections, please let me know.

--

From: Hemmo Nieminen 

commit c7754e75100ed5e3068ac5085747f2bfc386c8d6 upstream.

As printk() invocation can cause e.g. a TLB miss, printk() cannot be
called before the exception handlers have been properly initialized.
This can happen e.g. when netconsole has been loaded as a kernel module
and the TLB table has been cleared when a CPU was offline.

Call cpu_report() in start_secondary() only after the exception handlers
have been initialized to fix this.

Without the patch the kernel will randomly either lockup or crash
after a CPU is onlined and the console driver is a module.

Signed-off-by: Hemmo Nieminen 
Signed-off-by: Aaro Koskinen 
Cc: David Daney 
Cc: linux-m...@linux-mips.org
Cc: linux-kernel@vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/8953/
Signed-off-by: Ralf Baechle 
Signed-off-by: Greg Kroah-Hartman 

---
 arch/mips/kernel/smp.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/arch/mips/kernel/smp.c
+++ b/arch/mips/kernel/smp.c
@@ -109,10 +109,10 @@ asmlinkage void start_secondary(void)
else
 #endif /* CONFIG_MIPS_MT_SMTC */
cpu_probe();
-   cpu_report();
per_cpu_trap_init(false);
mips_clockevent_init();
mp_ops->init_secondary();
+   cpu_report();
 
/*
 * XXX parity protection should be folded in here when it's converted


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


[PATCH 3.14 18/20] ALSA: ak411x: Fix stall in work callback

2015-02-09 Thread Greg Kroah-Hartman
3.14-stable review patch.  If anyone has any objections, please let me know.

--

From: Takashi Iwai 

commit 4161b4505f1690358ac0a9ee59845a7887336b21 upstream.

When ak4114 work calls its callback and the callback invokes
ak4114_reinit(), it stalls due to flush_delayed_work().  For avoiding
this, control the reentrance by introducing a refcount.  Also
flush_delayed_work() is replaced with cancel_delayed_work_sync().

The exactly same bug is present in ak4113.c and fixed as well.

Reported-by: Pavel Hofman 
Acked-by: Jaroslav Kysela 
Tested-by: Pavel Hofman 
Signed-off-by: Takashi Iwai 
Signed-off-by: Greg Kroah-Hartman 

---
 include/sound/ak4113.h   |2 +-
 include/sound/ak4114.h   |2 +-
 sound/i2c/other/ak4113.c |   17 -
 sound/i2c/other/ak4114.c |   18 --
 4 files changed, 18 insertions(+), 21 deletions(-)

--- a/include/sound/ak4113.h
+++ b/include/sound/ak4113.h
@@ -286,7 +286,7 @@ struct ak4113 {
ak4113_write_t *write;
ak4113_read_t *read;
void *private_data;
-   unsigned int init:1;
+   atomic_t wq_processing;
spinlock_t lock;
unsigned char regmap[AK4113_WRITABLE_REGS];
struct snd_kcontrol *kctls[AK4113_CONTROLS];
--- a/include/sound/ak4114.h
+++ b/include/sound/ak4114.h
@@ -168,7 +168,7 @@ struct ak4114 {
ak4114_write_t * write;
ak4114_read_t * read;
void * private_data;
-   unsigned int init: 1;
+   atomic_t wq_processing;
spinlock_t lock;
unsigned char regmap[6];
unsigned char txcsb[5];
--- a/sound/i2c/other/ak4113.c
+++ b/sound/i2c/other/ak4113.c
@@ -56,8 +56,7 @@ static inline unsigned char reg_read(str
 
 static void snd_ak4113_free(struct ak4113 *chip)
 {
-   chip->init = 1; /* don't schedule new work */
-   mb();
+   atomic_inc(&chip->wq_processing);   /* don't schedule new work */
cancel_delayed_work_sync(&chip->work);
kfree(chip);
 }
@@ -89,6 +88,7 @@ int snd_ak4113_create(struct snd_card *c
chip->write = write;
chip->private_data = private_data;
INIT_DELAYED_WORK(&chip->work, ak4113_stats);
+   atomic_set(&chip->wq_processing, 0);
 
for (reg = 0; reg < AK4113_WRITABLE_REGS ; reg++)
chip->regmap[reg] = pgm[reg];
@@ -139,13 +139,11 @@ static void ak4113_init_regs(struct ak41
 
 void snd_ak4113_reinit(struct ak4113 *chip)
 {
-   chip->init = 1;
-   mb();
-   flush_delayed_work(&chip->work);
+   if (atomic_inc_return(&chip->wq_processing) == 1)
+   cancel_delayed_work_sync(&chip->work);
ak4113_init_regs(chip);
/* bring up statistics / event queing */
-   chip->init = 0;
-   if (chip->kctls[0])
+   if (atomic_dec_and_test(&chip->wq_processing))
schedule_delayed_work(&chip->work, HZ / 10);
 }
 EXPORT_SYMBOL_GPL(snd_ak4113_reinit);
@@ -632,8 +630,9 @@ static void ak4113_stats(struct work_str
 {
struct ak4113 *chip = container_of(work, struct ak4113, work.work);
 
-   if (!chip->init)
+   if (atomic_inc_return(&chip->wq_processing) == 1)
snd_ak4113_check_rate_and_errors(chip, chip->check_flags);
 
-   schedule_delayed_work(&chip->work, HZ / 10);
+   if (atomic_dec_and_test(&chip->wq_processing))
+   schedule_delayed_work(&chip->work, HZ / 10);
 }
--- a/sound/i2c/other/ak4114.c
+++ b/sound/i2c/other/ak4114.c
@@ -66,8 +66,7 @@ static void reg_dump(struct ak4114 *ak41
 
 static void snd_ak4114_free(struct ak4114 *chip)
 {
-   chip->init = 1; /* don't schedule new work */
-   mb();
+   atomic_inc(&chip->wq_processing);   /* don't schedule new work */
cancel_delayed_work_sync(&chip->work);
kfree(chip);
 }
@@ -100,6 +99,7 @@ int snd_ak4114_create(struct snd_card *c
chip->write = write;
chip->private_data = private_data;
INIT_DELAYED_WORK(&chip->work, ak4114_stats);
+   atomic_set(&chip->wq_processing, 0);
 
for (reg = 0; reg < 6; reg++)
chip->regmap[reg] = pgm[reg];
@@ -152,13 +152,11 @@ static void ak4114_init_regs(struct ak41
 
 void snd_ak4114_reinit(struct ak4114 *chip)
 {
-   chip->init = 1;
-   mb();
-   flush_delayed_work(&chip->work);
+   if (atomic_inc_return(&chip->wq_processing) == 1)
+   cancel_delayed_work_sync(&chip->work);
ak4114_init_regs(chip);
/* bring up statistics / event queing */
-   chip->init = 0;
-   if (chip->kctls[0])
+   if (atomic_dec_and_test(&chip->wq_processing))
schedule_delayed_work(&chip->work, HZ / 10);
 }
 
@@ -612,10 +610,10 @@ static void ak4114_stats(struct work_str
 {
struct ak4114 *chip = container_of(work, struct ak4114, work.work);
 
-   if (!chip->init)
+   if (atomic_inc_return(&chip->wq_processing) == 1)
snd_ak4114_check_rate_and_errors(chip, chip->check_flags);
-
-   schedule_delayed_work(&chip->wo

[PATCH 3.14 16/20] ASoC: atmel_ssc_dai: fix start event for I2S mode

2015-02-09 Thread Greg Kroah-Hartman
3.14-stable review patch.  If anyone has any objections, please let me know.

--

From: Bo Shen 

commit a43bd7e125143b875caae6d4f9938855b440faaf upstream.

According to the I2S specification information as following:
  - WS = 0, channel 1 (left)
  - WS = 1, channel 2 (right)
So, the start event should be TF/RF falling edge.

Reported-by: Songjun Wu 
Signed-off-by: Bo Shen 
Signed-off-by: Mark Brown 
Signed-off-by: Greg Kroah-Hartman 

---
 sound/soc/atmel/atmel_ssc_dai.c |   18 --
 1 file changed, 4 insertions(+), 14 deletions(-)

--- a/sound/soc/atmel/atmel_ssc_dai.c
+++ b/sound/soc/atmel/atmel_ssc_dai.c
@@ -344,7 +344,6 @@ static int atmel_ssc_hw_params(struct sn
struct atmel_pcm_dma_params *dma_params;
int dir, channels, bits;
u32 tfmr, rfmr, tcmr, rcmr;
-   int start_event;
int ret;
 
/*
@@ -451,19 +450,10 @@ static int atmel_ssc_hw_params(struct sn
 * The SSC transmit clock is obtained from the BCLK signal on
 * on the TK line, and the SSC receive clock is
 * generated from the transmit clock.
-*
-*  For single channel data, one sample is transferred
-* on the falling edge of the LRC clock.
-* For two channel data, one sample is
-* transferred on both edges of the LRC clock.
 */
-   start_event = ((channels == 1)
-   ? SSC_START_FALLING_RF
-   : SSC_START_EDGE_RF);
-
rcmr =SSC_BF(RCMR_PERIOD, 0)
| SSC_BF(RCMR_STTDLY, START_DELAY)
-   | SSC_BF(RCMR_START, start_event)
+   | SSC_BF(RCMR_START, SSC_START_FALLING_RF)
| SSC_BF(RCMR_CKI, SSC_CKI_RISING)
| SSC_BF(RCMR_CKO, SSC_CKO_NONE)
| SSC_BF(RCMR_CKS, SSC_CKS_CLOCK);
@@ -471,14 +461,14 @@ static int atmel_ssc_hw_params(struct sn
rfmr =SSC_BF(RFMR_FSEDGE, SSC_FSEDGE_POSITIVE)
| SSC_BF(RFMR_FSOS, SSC_FSOS_NONE)
| SSC_BF(RFMR_FSLEN, 0)
-   | SSC_BF(RFMR_DATNB, 0)
+   | SSC_BF(RFMR_DATNB, (channels - 1))
| SSC_BIT(RFMR_MSBF)
| SSC_BF(RFMR_LOOP, 0)
| SSC_BF(RFMR_DATLEN, (bits - 1));
 
tcmr =SSC_BF(TCMR_PERIOD, 0)
| SSC_BF(TCMR_STTDLY, START_DELAY)
-   | SSC_BF(TCMR_START, start_event)
+   | SSC_BF(TCMR_START, SSC_START_FALLING_RF)
| SSC_BF(TCMR_CKI, SSC_CKI_FALLING)
| SSC_BF(TCMR_CKO, SSC_CKO_NONE)
| SSC_BF(TCMR_CKS, SSC_CKS_PIN);
@@ -487,7 +477,7 @@ static int atmel_ssc_hw_params(struct sn
| SSC_BF(TFMR_FSDEN, 0)
| SSC_BF(TFMR_FSOS, SSC_FSOS_NONE)
| SSC_BF(TFMR_FSLEN, 0)
-   | SSC_BF(TFMR_DATNB, 0)
+   | SSC_BF(TFMR_DATNB, (channels - 1))
| SSC_BIT(TFMR_MSBF)
| SSC_BF(TFMR_DATDEF, 0)
| SSC_BF(TFMR_DATLEN, (bits - 1));


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


[GIT PULL] perf tree updates for v3.20

2015-02-09 Thread Ingo Molnar
Linus,

Please pull the latest perf-core-for-linus git tree from:

   git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git perf-core-for-linus

   # HEAD: 2fde4f94e0a9531251e706fa57131b51b0df042e perf: Decouple unthrottling 
and rotating

Kernel side changes:

- AMD range breakpoints support:

  Extend breakpoint tools and core to support address range through perf
  event with initial backend support for AMD extended breakpoints.

Syntax is:

   perf record -e mem:addr/len:type

For example set write breakpoint from 0x1000 to 0x1200 (0x1000 + 512)

   perf record -e mem:0x1000/512:w

- event throttling/rotating fixes

- various event group handling fixes, cleanups and 
  general paranoia code to be more robust against bugs 
  in the future.

- kernel stack overhead fixes

Tooling side changes:

   User visible changes:

  - Show precise number of samples in at the end of a 'record' session, if
processing build ids, since we will then traverse the whole perf.data 
file
and see all the PERF_RECORD_SAMPLE records, otherwise stop showing the
previous off-base heuristicly counted number of "samples"  (Namhyung 
Kim).

  - Support to read compressed module from build-id cache (Namhyung Kim)

  - Enable sampling loads and stores simultaneously in 'perf mem' (Stephane 
Eranian)

  - 'perf diff' output improvements (Namhyung Kim)

  - Fix error reporting for evsel pgfault constructor (Arnaldo Carvalho de 
Melo)

   Infrastructure changes:

  - Cache eh/debug frame offset for dwarf unwind (Namhyung Kim)

  - Support parsing parameterized events (Cody P Schafer)

  - Add support for IP address formats in libtraceevent (David Ahern)

Plus other misc fixes.

 Thanks,

Ingo

-->
Arnaldo Carvalho de Melo (9):
  perf mem: Move the mem_operations global to struct perf_mem
  perf tools: Remove EOL whitespaces
  perf hists: Rename hist_entry__free to __delete
  perf hists: Introduce function for deleting/removing hist_entry
  tools lib fs: Adopt debugfs open strerrno method
  tools lib fs: Pass filename to debugfs__strerror_open
  perf trace: Fix error reporting for evsel pgfault constructor
  tools lib fs debugfs: Introduce debugfs__strerror_open_tp
  tools lib fs debugfs: Check if debugfs is mounted when handling ENOENT

Cody P Schafer (4):
  perf tools: Support parsing parameterized events
  perf tools: Extend format_alias() to include event parameters
  perf Documentation: Add event parameters
  perf tools: Document parameterized and symbolic events

David Ahern (1):
  tools lib traceevent: Add support for IP address formats

Jacob Shin (4):
  perf/x86/amd: AMD support for bp_len > HW_BREAKPOINT_LEN_8
  perf tools: allow user to specify hardware breakpoint bp_len
  perf tools: add hardware breakpoint bp_len test cases
  perf/x86: Remove get_hbp_len and replace with bp_len

Jiri Olsa (1):
  perf: Use POLLIN instead of POLL_IN for perf poll data in flag

Mark Rutland (2):
  perf: Drop module reference on event init failure
  perf: Decouple unthrottling and rotating

Namhyung Kim (17):
  perf report: Get rid of report__inc_stat()
  perf tools: Allow use of an exclusive option more than once
  perf diff: Get rid of hists__compute_resort()
  perf diff: Print diff result more precisely
  perf diff: Introduce fmt_to_data_file() helper
  perf tools: Pass struct perf_hpp_fmt to its callbacks
  perf diff: Fix output ordering to honor next column
  perf diff: Fix -o/--order option behavior
  perf ui/tui: Show fatal error message only if exists
  perf callchain: Cache eh/debug frame offset for dwarf unwind
  perf tools: Do not use __perf_session__process_events() directly
  perf record: Show precise number of samples
  perf header: Set header version correctly
  perf evsel: Set attr.task bit for a tracking event
  perf symbols: Support to read compressed module from build-id cache
  perf tools: Use perf_data_file__fd() consistently
  perf symbols: Convert lseek + read to pread

Peter Zijlstra (3):
  perf: Add a bit of paranoia
  perf: Fix event->ctx locking
  perf: Fix put_event() ctx lock

Peter Zijlstra (Intel) (2):
  perf: Avoid horrible stack usage
  perf: Fix move_group() order

Rasmus Villemoes (1):
  perf tests: Fix typo in sample-parsing.c

Rickard Strandqvist (1):
  perf tools: Remove some unused functions from color.c

Stephane Eranian (1):
  perf mem: Enable sampling loads and stores simultaneously

Vineet Gupta (2):
  perf evsel: Don't rely on malloc working for sz 0
  perf tools: Provide stub for missing pthread_attr_setaffinity_np


 .../testing/sysfs-bus-event_source-devices-events  |   6 +
 arch/x86/include/asm/cpufeature.h  |   2 +
 arch/x86/include/asm/deb

Re: [PATCH 7/8] fbdev: ssd1307fb: Add sysfs handles to expose contrast and dim setting to userspace.

2015-02-09 Thread Maxime Ripard
On Sat, Feb 07, 2015 at 05:42:44PM +0100, Thomas Niederprüm wrote:
> > > +static struct device_attribute device_attrs[] = {
> > > + __ATTR(contrast, S_IRUGO|S_IWUSR, show_contrast,
> > > store_contrast),
> > > + __ATTR(dim, S_IRUGO|S_IWUSR, show_dim, store_dim),
> > > +
> > > +};
> > > +
> > 
> > I would have thought this was something accessible through the
> > framebuffer ioctl.
> > 
> > Apparently it's not, at least for the contrast, so maybe it should be
> > added there, instead of doing it for a single driver?
> 
> I think the contrast setting for an OLED display is much like the
> backlight setting for LCD panel. Since there is also no ioctl to set
> the backlight of an LCD I wonder if the contrast of an OLED should have
> one.

It's too much of framebuffer interface debate for me here. Tomi?

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com


signature.asc
Description: Digital signature


Re: [RFC][PATCH 1/3] powerpc: Don't force ENOSYS as error on syscall fail

2015-02-09 Thread Purcareata Bogdan
Obvious mistake on my behalf to send the patch with lines commented out. 
I will fix it in v2.


On 09.02.2015 09:55, Bogdan Purcareata wrote:

In certain scenarios - e.g. seccomp filtering with ERRNO as default action -
the system call fails for other reasons than the syscall not being available.
The seccomp filter can be configured to store a user-defined error code on
return from a blacklisted syscall.

The RFC is this: are there currently any user-space scenarios where it is
required that the system call return ENOSYS as error code on failure, no matter
the circumstances? I don't want to break userspace requirements. I have not
added code to force this error code in situations different than
secure_computing failure, in order to keep overhead at a minimum.

Signed-off-by: Bogdan Purcareata 
---
  arch/powerpc/kernel/entry_32.S | 3 ++-
  arch/powerpc/kernel/entry_64.S | 2 +-
  2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/kernel/entry_32.S b/arch/powerpc/kernel/entry_32.S
index 59848e5..52e48dd 100644
--- a/arch/powerpc/kernel/entry_32.S
+++ b/arch/powerpc/kernel/entry_32.S
@@ -425,7 +425,8 @@ END_FTR_SECTION_IFSET(CPU_FTR_NEED_PAIRED_STWCX)
b   1b
  #endif  /* CONFIG_44x */

-66:li  r3,-ENOSYS
+66:
+#  li  r3,-ENOSYS
b   ret_from_syscall

.globl  ret_from_fork
diff --git a/arch/powerpc/kernel/entry_64.S b/arch/powerpc/kernel/entry_64.S
index e6bfe8e..80db02e 100644
--- a/arch/powerpc/kernel/entry_64.S
+++ b/arch/powerpc/kernel/entry_64.S
@@ -269,7 +269,7 @@ syscall_dotrace:
b   .Lsyscall_dotrace_cont

  syscall_enosys:
-   li  r3,-ENOSYS
+#  li  r3,-ENOSYS
b   syscall_exit

  syscall_exit_work:


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


[PATCH 3.14 15/20] lib/checksum.c: fix build for generic csum_tcpudp_nofold

2015-02-09 Thread Greg Kroah-Hartman
3.14-stable review patch.  If anyone has any objections, please let me know.

--

From: karl beldan 

commit 9ce357795ef208faa0d59894d9d119a7434e37f3 upstream.

Fixed commit added from64to32 under _#ifndef do_csum_ but used it
under _#ifndef csum_tcpudp_nofold_, breaking some builds (Fengguang's
robot reported TILEGX's). Move from64to32 under the latter.

Fixes: 150ae0e94634 ("lib/checksum.c: fix carry in csum_tcpudp_nofold")
Reported-by: kbuild test robot 
Signed-off-by: Karl Beldan 
Cc: Eric Dumazet 
Cc: David S. Miller 
Signed-off-by: David S. Miller 
Cc: Guenter Roeck 
Signed-off-by: Greg Kroah-Hartman 

---
 lib/checksum.c |   18 +-
 1 file changed, 9 insertions(+), 9 deletions(-)

--- a/lib/checksum.c
+++ b/lib/checksum.c
@@ -47,15 +47,6 @@ static inline unsigned short from32to16(
return x;
 }
 
-static inline u32 from64to32(u64 x)
-{
-   /* add up 32-bit and 32-bit for 32+c bit */
-   x = (x & 0x) + (x >> 32);
-   /* add up carry.. */
-   x = (x & 0x) + (x >> 32);
-   return (u32)x;
-}
-
 static unsigned int do_csum(const unsigned char *buff, int len)
 {
int odd;
@@ -190,6 +181,15 @@ csum_partial_copy(const void *src, void
 EXPORT_SYMBOL(csum_partial_copy);
 
 #ifndef csum_tcpudp_nofold
+static inline u32 from64to32(u64 x)
+{
+   /* add up 32-bit and 32-bit for 32+c bit */
+   x = (x & 0x) + (x >> 32);
+   /* add up carry.. */
+   x = (x & 0x) + (x >> 32);
+   return (u32)x;
+}
+
 __wsum csum_tcpudp_nofold(__be32 saddr, __be32 daddr,
unsigned short len,
unsigned short proto,


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


[PATCH 3.10 16/17] kvm: vmx: handle invvpid vm exit gracefully

2015-02-09 Thread Greg Kroah-Hartman
3.10-stable review patch.  If anyone has any objections, please let me know.

--

From: Petr Matousek 

commit a642fc305053cc1c6e47e4f4df327895747ab485 upstream.

On systems with invvpid instruction support (corresponding bit in
IA32_VMX_EPT_VPID_CAP MSR is set) guest invocation of invvpid
causes vm exit, which is currently not handled and results in
propagation of unknown exit to userspace.

Fix this by installing an invvpid vm exit handler.

This is CVE-2014-3646.

Cc: sta...@vger.kernel.org
Signed-off-by: Petr Matousek 
Signed-off-by: Paolo Bonzini 
[wangkai: Backport to 3.10: adjust context]
Signed-off-by: Wang Kai 
Signed-off-by: Greg Kroah-Hartman 
---
 arch/x86/include/uapi/asm/vmx.h |2 ++
 arch/x86/kvm/vmx.c  |9 -
 2 files changed, 10 insertions(+), 1 deletion(-)

--- a/arch/x86/include/uapi/asm/vmx.h
+++ b/arch/x86/include/uapi/asm/vmx.h
@@ -67,6 +67,7 @@
 #define EXIT_REASON_EPT_MISCONFIG   49
 #define EXIT_REASON_INVEPT  50
 #define EXIT_REASON_PREEMPTION_TIMER52
+#define EXIT_REASON_INVVPID 53
 #define EXIT_REASON_WBINVD  54
 #define EXIT_REASON_XSETBV  55
 #define EXIT_REASON_APIC_WRITE  56
@@ -112,6 +113,7 @@
{ EXIT_REASON_EOI_INDUCED,   "EOI_INDUCED" }, \
{ EXIT_REASON_INVALID_STATE, "INVALID_STATE" }, \
{ EXIT_REASON_INVD,  "INVD" }, \
+   { EXIT_REASON_INVVPID,   "INVVPID" }, \
{ EXIT_REASON_INVPCID,   "INVPCID" }, \
{ EXIT_REASON_PREEMPTION_TIMER,  "PREEMPTION_TIMER" }
 
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -6248,6 +6248,12 @@ static int handle_invept(struct kvm_vcpu
return 1;
 }
 
+static int handle_invvpid(struct kvm_vcpu *vcpu)
+{
+   kvm_queue_exception(vcpu, UD_VECTOR);
+   return 1;
+}
+
 /*
  * The exit handlers return 1 if the exit was handled fully and guest execution
  * may resume.  Otherwise they set the kvm_run parameter to indicate what needs
@@ -6293,6 +6299,7 @@ static int (*const kvm_vmx_exit_handlers
[EXIT_REASON_MWAIT_INSTRUCTION]   = handle_invalid_op,
[EXIT_REASON_MONITOR_INSTRUCTION] = handle_invalid_op,
[EXIT_REASON_INVEPT]  = handle_invept,
+   [EXIT_REASON_INVVPID] = handle_invvpid,
 };
 
 static const int kvm_vmx_max_exit_handlers =
@@ -6519,7 +6526,7 @@ static bool nested_vmx_exit_handled(stru
case EXIT_REASON_VMPTRST: case EXIT_REASON_VMREAD:
case EXIT_REASON_VMRESUME: case EXIT_REASON_VMWRITE:
case EXIT_REASON_VMOFF: case EXIT_REASON_VMON:
-   case EXIT_REASON_INVEPT:
+   case EXIT_REASON_INVEPT: case EXIT_REASON_INVVPID:
/*
 * VMX instructions trap unconditionally. This allows L1 to
 * emulate them for its L2 guest, i.e., allows 3-level nesting!


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


[PATCH 3.10 05/17] MIPS: Fix kernel lockup or crash after CPU offline/online

2015-02-09 Thread Greg Kroah-Hartman
3.10-stable review patch.  If anyone has any objections, please let me know.

--

From: Hemmo Nieminen 

commit c7754e75100ed5e3068ac5085747f2bfc386c8d6 upstream.

As printk() invocation can cause e.g. a TLB miss, printk() cannot be
called before the exception handlers have been properly initialized.
This can happen e.g. when netconsole has been loaded as a kernel module
and the TLB table has been cleared when a CPU was offline.

Call cpu_report() in start_secondary() only after the exception handlers
have been initialized to fix this.

Without the patch the kernel will randomly either lockup or crash
after a CPU is onlined and the console driver is a module.

Signed-off-by: Hemmo Nieminen 
Signed-off-by: Aaro Koskinen 
Cc: David Daney 
Cc: linux-m...@linux-mips.org
Cc: linux-kernel@vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/8953/
Signed-off-by: Ralf Baechle 
Signed-off-by: Greg Kroah-Hartman 

---
 arch/mips/kernel/smp.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/arch/mips/kernel/smp.c
+++ b/arch/mips/kernel/smp.c
@@ -109,10 +109,10 @@ asmlinkage __cpuinit void start_secondar
else
 #endif /* CONFIG_MIPS_MT_SMTC */
cpu_probe();
-   cpu_report();
per_cpu_trap_init(false);
mips_clockevent_init();
mp_ops->init_secondary();
+   cpu_report();
 
/*
 * XXX parity protection should be folded in here when it's converted


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


[PATCH 3.10 06/17] mm: pagewalk: call pte_hole() for VM_PFNMAP during walk_page_range

2015-02-09 Thread Greg Kroah-Hartman
3.10-stable review patch.  If anyone has any objections, please let me know.

--

From: Shiraz Hashim 

commit 23aaed6659df9adfabe9c583e67a36b54e21df46 upstream.

walk_page_range() silently skips vma having VM_PFNMAP set, which leads
to undesirable behaviour at client end (who called walk_page_range).
Userspace applications get the wrong data, so the effect is like just
confusing users (if the applications just display the data) or sometimes
killing the processes (if the applications do something with
misunderstanding virtual addresses due to the wrong data.)

For example for pagemap_read, when no callbacks are called against
VM_PFNMAP vma, pagemap_read may prepare pagemap data for next virtual
address range at wrong index.

Eventually userspace may get wrong pagemap data for a task.
Corresponding to a VM_PFNMAP marked vma region, kernel may report
mappings from subsequent vma regions.  User space in turn may account
more pages (than really are) to the task.

In my case I was using procmem, procrack (Android utility) which uses
pagemap interface to account RSS pages of a task.  Due to this bug it
was giving a wrong picture for vmas (with VM_PFNMAP set).

Fixes: a9ff785e4437 ("mm/pagewalk.c: walk_page_range should avoid VM_PFNMAP 
areas")
Signed-off-by: Shiraz Hashim 
Acked-by: Naoya Horiguchi 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman 

---
 mm/pagewalk.c |5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

--- a/mm/pagewalk.c
+++ b/mm/pagewalk.c
@@ -199,7 +199,10 @@ int walk_page_range(unsigned long addr,
 */
if ((vma->vm_start <= addr) &&
(vma->vm_flags & VM_PFNMAP)) {
-   next = vma->vm_end;
+   if (walk->pte_hole)
+   err = walk->pte_hole(addr, next, walk);
+   if (err)
+   break;
pgd = pgd_offset(walk->mm, next);
continue;
}


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


[PATCH 3.10 07/17] lib/checksum.c: fix carry in csum_tcpudp_nofold

2015-02-09 Thread Greg Kroah-Hartman
3.10-stable review patch.  If anyone has any objections, please let me know.

--

From: karl beldan 

commit 150ae0e94634714b23919f0c333fee28a5b199d5 upstream.

The carry from the 64->32bits folding was dropped, e.g with:
saddr=0x daddr=0xFFFF len=0x proto=0 sum=1,
csum_tcpudp_nofold returned 0 instead of 1.

Signed-off-by: Karl Beldan 
Cc: Al Viro 
Cc: Eric Dumazet 
Cc: Arnd Bergmann 
Cc: Mike Frysinger 
Cc: net...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Eric Dumazet 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman 

---
 lib/checksum.c |   12 ++--
 1 file changed, 10 insertions(+), 2 deletions(-)

--- a/lib/checksum.c
+++ b/lib/checksum.c
@@ -47,6 +47,15 @@ static inline unsigned short from32to16(
return x;
 }
 
+static inline u32 from64to32(u64 x)
+{
+   /* add up 32-bit and 32-bit for 32+c bit */
+   x = (x & 0x) + (x >> 32);
+   /* add up carry.. */
+   x = (x & 0x) + (x >> 32);
+   return (u32)x;
+}
+
 static unsigned int do_csum(const unsigned char *buff, int len)
 {
int odd;
@@ -195,8 +204,7 @@ __wsum csum_tcpudp_nofold(__be32 saddr,
 #else
s += (proto + len) << 8;
 #endif
-   s += (s >> 32);
-   return (__force __wsum)s;
+   return (__force __wsum)from64to32(s);
 }
 EXPORT_SYMBOL(csum_tcpudp_nofold);
 #endif


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


[PATCH 3.14 01/20] gpio: sysfs: fix memory leak in gpiod_export_link

2015-02-09 Thread Greg Kroah-Hartman
3.14-stable review patch.  If anyone has any objections, please let me know.

--

From: Johan Hovold 

commit 0f303db08df0df9bd0966443ad6001e63960af16 upstream.

Fix memory leak in the gpio sysfs interface due to failure to drop
reference to device returned by class_find_device when creating a link.

Fixes: a4177ee7f1a8 ("gpiolib: allow exported GPIO nodes to be named using 
sysfs links")
Signed-off-by: Johan Hovold 
Signed-off-by: Linus Walleij 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/gpio/gpiolib.c |1 +
 1 file changed, 1 insertion(+)

--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -911,6 +911,7 @@ int gpiod_export_link(struct device *dev
if (tdev != NULL) {
status = sysfs_create_link(&dev->kobj, &tdev->kobj,
name);
+   put_device(tdev);
} else {
status = -ENODEV;
}


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


  1   2   3   4   5   6   7   8   >