Re: [PATCH 1/1] kernel/fork.c: avoid division by zero

2015-02-16 Thread Vladimir Davydov
On Mon, Feb 16, 2015 at 07:00:44PM +0100, Heinrich Schuchardt wrote:
> diff --git a/kernel/fork.c b/kernel/fork.c
> index cf65139..71e2583 100644
> --- a/kernel/fork.c
> +++ b/kernel/fork.c
> @@ -273,7 +273,8 @@ void __init fork_init(unsigned long mempages)
>* value: the thread structures can take up at most half
>* of memory.
>*/
> - max_threads = mempages / (8 * THREAD_SIZE / PAGE_SIZE);
> + max_threads = (u64) PAGE_SIZE * (u64) mempages
> + / (u64) THREAD_SIZE / 8UL;

This won't compile for a 32 bit arch, will it? Should you use div_u64?

Thanks,
Vladimir
--
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 v4 2/4] mfd: lubbock_cplds: add lubbock IO board

2015-02-16 Thread Lee Jones
Arnd, Greg,

  Perhaps you have some ideas WRT programmables (PLDs/CPLDs/FPGAs)?

On Mon, 16 Feb 2015, Robert Jarzmik wrote:
> Lee Jones wrote:
> > What's all this?  Please configure your mail client correctly.
> >
> > For advice, see:
> >
> >   Documentation/email-clients.txt
> While at day work, I have only access to web mail ...

Probably best to hold off your reply until you get home then.  It's
not just a formatting issue, you also exposed many raw email addresses
to the internet, which are easily harvested up by web crawlers.

See this:
  https://lkml.org/lkml/2015/2/16/247

> >>  2) after v2, we _both_ agreed that the accurate name is "cplds"
> >> which exactly what is in this patch
> >> (see device registering with lubbock_cplds).
> >
> > There is no mention of this decision in the changelogs.  If it's not
> > in the change logs, it didn't happen. ;)
> Ah right.
> 
> > I'm still concerned with the fact that the driver file is named using
> > and is populated by lots of instances of a "board" name.  I'm sure you
> > would share my thoughts is someone submitted a driver called
> > beaglebone.c or raspberrypi.c to MFD.
> I understand your concern. Arnd, a thought about it ? The only viable
> alternative would be to move it to arch/arm/plat-pxa AFAIS.

I don't think this is correct either.  CPLD handling would probably be
slightly less out of place in drivers/misc, but perhaps a new
subsystem for PLDs/CPLDs/FPGAs would be more appropriate
drivers/programmables or similar maybe.

> >> > Besides, this is MFD, where we support single pieces of silicon which
> >> > happen to support multiple devices.  I definitely don't want to support
> >> > boards here.
> >> > You might want to re-think the naming and your (sales) pitch.
> >> I might need help. As for the (sales), no comment.
> >
> > By pitch, I mean to convince me that this belongs in MFD.
> I've been trying.

I'm pretty convinced that it doesn't belong in MFD now, but it doesn't
mean I'm going to leave you on the curb.  I'd like to help you get it
into a better home.

[...]

> > Understanding was lost when I learned that the whole file was centred
> > around the premise of board support.  I understand now that this is a
> > driver for a CPLD, which I'm not sure is even MFD.  Also, if it is
> > really a CPLD driver, shouldn't be named after the manufacturer/model
> > number of the chip, rather than the PCB which it's connected to?
> >
> > I'm also concerned that this driver has no functional CPLD code
> > contained.  All you're doing is defining an IRQ domain.  Why then
> > isn't this really an drivers/irqchip (Suggested-by: Josh Cartwright)
> > driver?
> Is not only a irqchip because, as explained at the bottom of the commit 
> message,
> quoting myself :
>   This patch moves all that handling to a mfd driver. It's only purpose
>   for the time being is the interrupt handling, but in the future it
>   should encompass all the motherboard CPLDs handling :
>- leds
>- switches
>- hexleds

I had a conversation about this on IRC yesterday and some good
points/questions were posed.  This is a difficult area, because you
can program these things to do whatever you like.  Depending on the
'intention' (and it is only an intention -- someone else can come
along and reprogram these devices on a whim), the CPLD code could live
anywhere.  If you wanted to put watchdog functionality in there, then
there is an argument for it to live in drivers/watchdog, etc etc.  So
just because the plan is to support a few (i.e. more than one) simple
devices, it doesn't necessarily mean that the handling should be done
in MFD.

Yesterday I was asked "Are you wanting to restrict drivers in
drivers/mfd to those that make use of MFD_CORE functionality?".  My
answer to that was "No, however; I only want devices which
_intrinsically_ operate in multiple subsystems", which these
programmables no not do.

FYI, you're not on your own here.  There is at least one of these
devices in the kernel already and upon a short inspection there
appears to be a number of Out-of-Tree (OoT) drivers out there which
will require a home in Mainline sooner or later.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
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 01/15] h8300: Assembly headers.

2015-02-16 Thread Yoshinori Sato
At Sun, 15 Feb 2015 10:11:58 +0100,
Geert Uytterhoeven wrote:
> 
> Hi Sato-san,
> 
> On Sun, Feb 15, 2015 at 8:49 AM, Yoshinori Sato
>  wrote:
> > --- /dev/null
> > +++ b/arch/h8300/include/asm/io.h
> > @@ -0,0 +1,372 @@
> > +#ifndef _H8300_IO_H
> > +#define _H8300_IO_H
> > +
> > +#ifdef __KERNEL__
> > +
> > +#include 
> > +
> > +/*
> > + * These are for ISA/PCI shared memory _only_ and should never be used
> > + * on any other type of memory, including Zorro memory. They are meant to
> > + * access the bus in the bus byte order which is little-endian!.
> > + *
> > + * readX/writeX() are used to access memory mapped devices. On some
> > + * architectures the memory mapped IO stuff needs to be accessed
> > + * differently. On the m68k architecture, we just read/write the
> > + * memory location directly.
> > + */
> > +/* ++roman: The assignments to temp. vars avoid that gcc sometimes 
> > generates
> > + * two accesses to memory, which may be undesirable for some devices.
> > + */
> 
> While some of the above applies to h8300, I think you should remove
> the parts that don't apply.

It's necessary by several drivers, so it has been left.
An unnecessary part is also included, so I have to remove the part.

> Gr{oetje,eeting}s,
> 
> Geert
> 
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- 
> ge...@linux-m68k.org
> 
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like 
> that.
> -- Linus Torvalds

-- 
Yoshinori Sato

--
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 05/15] h8300: Process and signal

2015-02-16 Thread Yoshinori Sato
At Sun, 15 Feb 2015 11:33:25 +0100,
Paul Bolle wrote:
> 
> On Sun, 2015-02-15 at 17:11 +0900, Yoshinori Sato wrote:
> > Sorry. I send too old files.
> > This patch is correct.
> > 
> > Signed-off-by: Yoshinori Sato 
> > ---
> >  arch/h8300/kernel/process.c | 170 +++
> >  arch/h8300/kernel/ptrace.c  | 203 +++
> >  arch/h8300/kernel/signal.c  | 326 
> > 
> >  3 files changed, 699 insertions(+)
> >  create mode 100644 arch/h8300/kernel/process.c
> >  create mode 100644 arch/h8300/kernel/ptrace.c
> >  create mode 100644 arch/h8300/kernel/signal.c
> > 
> >[...]
> > diff --git a/arch/h8300/kernel/signal.c b/arch/h8300/kernel/signal.c
> > new file mode 100644
> > index 000..1222783
> > --- /dev/null
> > +++ b/arch/h8300/kernel/signal.c
> > @@ -0,1 +1,326 @@
> 
> That line should read
> @@ -0,0 +1,326 @@
> 
> shouldn't it? At least, currently that line makes "git am" here barf
> with
> fatal: new file arch/h8300/kernel/signal.c depends on old contents
> 
> 
> Paul Bolle
> 

Hmm.
When fixing it, maybe it was broken.

It's checked next patch.

-- 
Yoshinori Sato

--
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 05/15] h8300: Process and signal

2015-02-16 Thread Yoshinori Sato
At Sun, 15 Feb 2015 20:38:25 +0100,
Richard Weinberger wrote:
> 
> On Sun, Feb 15, 2015 at 8:49 AM, Yoshinori Sato
>  wrote:
> > +   usig = current_thread_info()->exec_domain
> > +   && current_thread_info()->exec_domain->signal_invmap
> > +   && sig < 32
> > +   ? current_thread_info()->exec_domain->signal_invmap[sig]
> > +   : sig;
> 
> Does h8300 really need signal mapping?
> I'm very sure you can drop this.
> In fact I'm working in patch set to rip it out tree wide as we have
> only a single (broken)
> in-tree user.
>

I agree.
It remove forgot.

> -- 
> Thanks,
> //richard

-- 
Yoshinori Sato

--
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 00/15] Revert h8300 archtecture

2015-02-16 Thread Yoshinori Sato
At Sun, 15 Feb 2015 11:59:19 +0100,
Paul Bolle wrote:
> 
> On Sun, 2015-02-15 at 16:49 +0900, Yoshinori Sato wrote:
> > Yoshinori Sato (15):
> >   h8300: Assembly headers.
> >   h8300: UAPI headers
> >   h8300: Exception and Interrupt handling
> >   h8300: kernel booting
> >   h8300: Process and signal
> >   h8300 CPU depend helpers
> >   h8300: miscellaneous functions
> >   h8300: Memory management
> >   h8300: library functions
> >   h8300: Build scripts
> >   h8300: clock driver
> >   h8300: clocksource
> >   h8300: configs
> >   serial: Add h8300
> >   Add ELF machine
> 
> git am warns about various whitespace issues:
> 
> Applying: h8300: Assembly headers.
> [...]/.git/rebase-apply/patch:831: new blank line at EOF.
> +
> [...]/.git/rebase-apply/patch:1674: new blank line at EOF.
> +
> warning: 2 lines add whitespace errors.
> Applying: h8300: UAPI headers
> Applying: h8300: Exception and Interrupt handling
> [...]/.git/rebase-apply/patch:223: trailing whitespace.
> /* r1l is saved ccr */
> warning: 1 line adds whitespace errors.
> Applying: h8300: kernel booting
> [...]/.git/rebase-apply/patch:54: new blank line at EOF.
> +
> warning: 1 line adds whitespace errors.
> Applying: h8300: Process and signal
> [...]/.git/rebase-apply/patch:314: trailing whitespace.
>   
> warning: 1 line adds whitespace errors.
> Applying: h8300 CPU depend helpers
> [...]/.git/rebase-apply/patch:32: new blank line at EOF.
> +
> [...]/.git/rebase-apply/patch:827: new blank line at EOF.
> +
> warning: 2 lines add whitespace errors.
> Applying: h8300: miscellaneous functions
> Applying: h8300: Memory management
> [...]/.git/rebase-apply/patch:88: new blank line at EOF.
> +
> [...]/.git/rebase-apply/patch:247: new blank line at EOF.
> +
> [...]/.git/rebase-apply/patch:374: new blank line at EOF.
> +
> warning: 3 lines add whitespace errors.
> Applying: h8300: library functions
> [...]/.git/rebase-apply/patch:279: trailing whitespace.
>   
> [...]/.git/rebase-apply/patch:1170: trailing whitespace.
>   
> [...]/.git/rebase-apply/patch:1188: space before tab in indent.
>   ; er0 = er0 / er1
> [...]/.git/rebase-apply/patch:1189: space before tab in indent.
>   ; er3 = er0 % er1
> [...]/.git/rebase-apply/patch:1190: space before tab in indent.
>   ; trashes er1 er2
> warning: squelched 3 whitespace errors
> warning: 8 lines add whitespace errors.
> Applying: h8300: Build scripts
> [...]/.git/rebase-apply/patch:197: space before tab in indent.
> 
> 
> warning: 1 line adds whitespace errors.
> Applying: h8300: clock driver
> [...]/.git/rebase-apply/patch:161: trailing whitespace.
>   
> [...]/.git/rebase-apply/patch:216: trailing whitespace.
>   
> [...]/.git/rebase-apply/patch:236: trailing whitespace.
>   
> warning: 3 lines add whitespace errors.
> Applying: h8300: clocksource
> [...]/.git/rebase-apply/patch:22: trailing whitespace.
>   
> warning: 1 line adds whitespace errors.
> Applying: h8300: configs
> Applying: serial: Add h8300
> Applying: Add ELF machine
> 
> (I did fix patch 12/15 ("h8300: clocksource") manually, to make it apply
> on top of next-20150213, but I don't think I introduced the warning in
> that patch.)
> 
> 
> Paul Bolle
> 

OK.
I wll cleanup next patch.

-- 
Yoshinori Sato

--
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 10/15] h8300: Build scripts

2015-02-16 Thread Yoshinori Sato
At Sun, 15 Feb 2015 20:23:04 +0100,
Paul Bolle wrote:
> 
> On Sun, 2015-02-15 at 16:49 +0900, Yoshinori Sato wrote:
> > Signed-off-by: Yoshinori Sato 
> > ---
> >  arch/h8300/Kconfig  | 119 +++
> >  arch/h8300/Kconfig.cpu  | 136 
> > 
> >  arch/h8300/Kconfig.debug|  23 +++
> >  arch/h8300/Makefile |  45 +
> >  arch/h8300/kernel/Makefile  |  16 +
> >  arch/h8300/kernel/vmlinux.lds.S |  85 +
> >  6 files changed, 424 insertions(+)
> >  create mode 100644 arch/h8300/Kconfig
> >  create mode 100644 arch/h8300/Kconfig.cpu
> >  create mode 100644 arch/h8300/Kconfig.debug
> >  create mode 100644 arch/h8300/Makefile
> >  create mode 100644 arch/h8300/kernel/Makefile
> >  create mode 100644 arch/h8300/kernel/vmlinux.lds.S
> > 
> > diff --git a/arch/h8300/Kconfig b/arch/h8300/Kconfig
> > new file mode 100644
> > index 000..828c356
> > --- /dev/null
> > +++ b/arch/h8300/Kconfig
> > @@ -0,0 +1,119 @@
> > +config H8300
> > +   bool
> > +   default y
> > +   select HAVE_IDE
> > +   select GENERIC_ATOMIC64
> > +   select HAVE_UID16
> > +   select VIRT_TO_BUS
> > +   select ARCH_WANT_IPC_PARSE_VERSION
> > +   select GENERIC_IRQ_SHOW
> > +   select FRAME_POINTER
> > +   select GENERIC_CPU_DEVICES
> > +   select MODULES_USE_ELF_RELA
> > +   select GENERIC_CLOCKEVENTS
> > +   select CLKDEV_LOOKUP
> > +   select COMMON_CLK
> > +   select HAVE_ARCH_TRACEHOOK
> > +   select ARCH_WANT_FRAME_POINTERS
> > +
> > +config MMU
> > +   bool
> > +   default n
> > +
> > +config SWAP
> > +   bool
> > +   default n
> > +
> 
> MMU will always be 'n'. (So the entry for MMU is not strictly needed,
> but I guess it is clearer to explicitly set this to 'n'.) But that means
> there's no reason here to mask the global SWAP config (see
> init/Kconfig), as that will also always be 'n' for H8300.

OK.
remove it.

> > +config ZONE_DMA
> > +   bool
> > +   default y
> > +
> > +config FPU
> > +   bool
> > +   default n
> 
> Why is this needed?

Inneeded.
Remove it.

> > +
> > +config RWSEM_GENERIC_SPINLOCK
> > +   bool
> > +   default y
> > +
> > +config RWSEM_XCHGADD_ALGORITHM
> > +   bool
> > +   default n
> 
> Not strictly needed.

OK.

> 
> > +config ARCH_HAS_ILOG2_U32
> > +   bool
> > +   default n
> > +
> 
> Ditto.
> 
> > +config ARCH_HAS_ILOG2_U64
> > +   bool
> > +   default n
> > +
> 
> Ditto.
> 
> > +config GENERIC_HWEIGHT
> > +   bool
> > +   default y
> > +
> > +config GENERIC_CALIBRATE_DELAY
> > +   bool
> > +   default y
> > +
> > +config GENERIC_BUG
> > +bool
> > +depends on BUG
> > +
> 
> GENERIC_BUG can never be set for H8300, so this entry is not needed.

OK.
Remove.

> > +config TIME_LOW_RES
> > +   bool
> > +   default y
> > +
> > +config NO_IOPORT_MAP
> > +   def_bool y
> > +
> > +config NO_DMA
> > +   def_bool n
> 
> Not needed (please note that only a few architectures have an entry for
> NO_DMA).

OK.
Remove.

> > +config ISA
> > +def_bool n
> > +
> > +config PCI
> > +   def_bool n
> > +
> 
> Neither ISA nor PCI will ever be set, won't they? So you might as well
> drop these too.
> 
> > +config HZ
> > +   int
> > +   default 100
> > +
> > +config NR_CPUS
> > +int
> 
> Eight spaces instead of one tab.

OK.

> > +   default 1
> > +
> > +source "init/Kconfig"
> > +
> > +source "kernel/Kconfig.freezer"
> > +
> > +source "arch/h8300/Kconfig.cpu"
> > +
> > +menu "Kernel Features"
> > +
> > +source "kernel/Kconfig.preempt"
> > +
> > +source "mm/Kconfig"
> > +
> > +endmenu
> > +
> > +menu "Executable file formats"
> > +
> > +source "fs/Kconfig.binfmt"
> > +
> > +endmenu
> > +
> > +source "net/Kconfig"
> > +
> > +source "drivers/Kconfig"
> > +
> > +source "fs/Kconfig"
> > +
> > +source "arch/h8300/Kconfig.debug"
> > +
> > +source "security/Kconfig"
> > +
> > +source "crypto/Kconfig"
> > +
> > +source "lib/Kconfig"
> > diff --git a/arch/h8300/Kconfig.cpu b/arch/h8300/Kconfig.cpu
> > new file mode 100644
> > index 000..2eaa797
> > --- /dev/null
> > +++ b/arch/h8300/Kconfig.cpu
> > @@ -0,0 +1,136 @@
> > +menu "Processor type and features"
> > +
> > +choice
> > +   prompt "H8/300 platform"
> > +
> > +config H8300_AE3068
> > +   bool "AE-3068/69"
> > +   select H83069
> > +   select RAMKERNEL
> > +   help
> > + AKI-H8/3068F / AKI-H8/3069F Flashmicom LAN Board Support
> > + More Information. (Japanese Only)
> > + 
> > + AE-3068/69 Evaluation Board Support
> > + More Information.
> > + 
> > +
> > +config H8300_H8MAX
> > +   bool "H8MAX"
> > +   select H83069
> > +   select RAMKERNEL
> > +   help
> > + H8MAX Evaluation Board Support
> > + More Information. (Japanese Only)
> > + 
> > +
> > +config H8300_KANEBEBE
> > +   bool "KaneBebe"
> > +   select H83069
> > +   select RAMKERNEL

Re: [PATCH] compat: Fix endian issue in union sigval

2015-02-16 Thread Bamvor Jian Zhang
On 2015/2/13 18:44, Catalin Marinas wrote:
> On Fri, Feb 13, 2015 at 04:00:43PM +0800, Bamvor Jian Zhang wrote:
>> On 2015/2/11 23:40, Catalin Marinas wrote:
>>> On Wed, Feb 11, 2015 at 07:22:08PM +0800, Bamvor Jian Zhang wrote:
 On 2015/2/10 20:27, Catalin Marinas wrote:
> On Tue, Feb 10, 2015 at 10:10:11AM +, Zhang Jian(Bamvor) wrote:
>> ...
>>> The native sigval_t is also a union but on 64-bit big endian, the
>>> sival_int overlaps with the most significant 32-bit of the sival_ptr.
>>> So reading sival_int would always be 0. When the compat siginfo is
>>> copied to user, arm64 reads the native sival_ptr (si_ptr) and converts
>>> it to the compat one, getting the correct 32-bit value. However, other
>>> architectures access sival_int (si_int) instead which breaks with your
>>> get_compat_sigevent() changes.
>>>
> I think the correct fix is in the arm64 code:

 The following code could fix my issue.
>>>
>>> Without any parts of your patch?
>>
>> Yes. As you mentioned above, sival_int overlaps the most significant 32bit
>> of the sival_ptr, it seems that your patch is right if sival_ptr is less than
>> 32bit.
> 
> I don't follow you here. sival_ptr is greater than 32-bit on a 64-bit
> kernel.
Sorry for confuse. I was considering if the pointer in sival_ptr is greater
than 32bit in 64bit application. But it seems that it is not relative to my
issue: We only talk about the 32bit application here.
>>> I think that's correct fix since in the SIGEV_THREAD mq_notify case, we
>>> would not deliver a signal as notification, so the sival_int value is
>>> irrelevant (it would be 0 for big-endian compat tasks because of the
>>> sigval_t union on 64-bit).
>>>
>>> Your patch would work as well but you have to change all the other
>>> architectures to use si_ptr when copying to a compat siginfo.
>>
>> Yeah, it seems that my patch is useful only if the sival_ptr is bigger
>> than 32bit. It need the similar changes with following catalin's patch
>> in the following 64bit architecture:
>>
>> x86: arch/x86/ia32/ia32_signal.c
> 
> That's a little endian architecture and the use of ptr_to_compat() looks
> fine to me.
> 
>> tile, s390:  arch/xxx/kernel/compat_signal.c
> 
> s390 uses si_int already, as in my proposed arm64 patch.
> 
> tile seems to be bi-endian, though I couldn't see a Kconfig option, nor
> something defining __BIG_ENDIAN__ in headers or Makefile. I guess it's
> coming from the compiler directly. Anyway, on big endian tile, I we have
> the same issue as on big endian arm64.
> 
>> parisc, sparc, mips: arch/xxx/kernel/signal32.c
> 
> paris, sparc and mips all use si_int instead of si_ptr, so that's fine.
> 
>> powerpc: arch/xxx/kernel/signal_32.c
> 
> Same for powerpc, it uses si_int instead of si_ptr.
> 
>> cc these maintainers for input.
> 
> I think it's only tile that needs fixing for big endian, something like
> the arm64 patch below:
Agree. I was thinking if it is not very clear that app write to si_ptr in
userspace while kernel only read/write si_int.

regards

bamvor

> diff --git a/arch/arm64/kernel/signal32.c b/arch/arm64/kernel/signal32.c
> index e299de396e9b..32601939a3c8 100644
> --- a/arch/arm64/kernel/signal32.c
> +++ b/arch/arm64/kernel/signal32.c
> @@ -154,8 +154,7 @@ int copy_siginfo_to_user32(compat_siginfo_t __user 
> *to, const siginfo_t *from)
>   case __SI_TIMER:
>err |= __put_user(from->si_tid, >si_tid);
>err |= __put_user(from->si_overrun, >si_overrun);
> -  err |= __put_user((compat_uptr_t)(unsigned long)from->si_ptr,
> ->si_ptr);
> +  err |= __put_user(from->si_int, >si_int);
>   break;
>   case __SI_POLL:
>   err |= __put_user(from->si_band, >si_band);
> @@ -184,7 +183,7 @@ int copy_siginfo_to_user32(compat_siginfo_t __user 
> *to, const siginfo_t *from)
>   case __SI_MESGQ: /* But this is */
>   err |= __put_user(from->si_pid, >si_pid);
>   err |= __put_user(from->si_uid, >si_uid);
> - err |= __put_user((compat_uptr_t)(unsigned long)from->si_ptr, 
> >si_ptr);
> + err |= __put_user(from->si_int, >si_int);
>   break;
>   case __SI_SYS:
>   err |= __put_user((compat_uptr_t)(unsigned long)
> 


--
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/


powerpc: fsl,pq2-localbus is broken for ages

2015-02-16 Thread Nikita Yushchenko
Hi

arch/powerpc/sysdev/fsl_lbc.c driver claims that it is compatible with
fsl,pq2-localbus and fsl,pq2pro-localbus

arch/powerpc/sysdev/fsl_lbc.c driver requires irq configured in device
tree since very old times (commit 3ab8f2a2 from 2.6.37 times)

None of in-tree dts files that have either fsl,pq2-localbus or
fsl,pq2pro-localbus, ever defined irq for that. As far as I understand,
that hardware did not have an irq.

This leads to problems running recent kernels on legacy Freescale boards.

I don't know if support for legacy boards worths fixing. Especially
since nobody cared for years. But maybe at least remove these
"compatible" lines from the drivers (and perhaps completely remove
broken support for pq2 boards at all)?

Nikita
--
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 02/45] scripts/headers.sh: add verbose option to make calls if defined

2015-02-16 Thread Masahiro Yamada

On Tue, 17 Feb 2015 00:05:05 +0100
Mikko Rapeli  wrote:

> Useful when debugging the scripts.
> 
> Signed-off-by: Mikko Rapeli 
> ---
>  scripts/headers.sh | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/scripts/headers.sh b/scripts/headers.sh
> index 95ece06..aa62fd8 100755
> --- a/scripts/headers.sh
> +++ b/scripts/headers.sh
> @@ -7,7 +7,7 @@ set -e
>  do_command()
>  {
>   if [ -f ${srctree}/arch/$2/include/asm/Kbuild ]; then
> - make ARCH=$2 KBUILD_HEADERS=$1 headers_$1
> + make V=$KBUILD_VERBOSE ARCH=$2 KBUILD_HEADERS=$1 headers_$1
>   else
>   printf "Ignoring arch: %s\n" ${arch}
>   fi
> -- 


KBUILD_VERBOSE is already exported.

Why do you need to set V=... again here?


Best Regards
Masahiro Yamada

--
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 01/45] Makefile: propagate verbose options

2015-02-16 Thread Masahiro Yamada
Hi Mikko,

On Tue, 17 Feb 2015 00:05:04 +0100
Mikko Rapeli  wrote:

> Usefull when debugging the make scripts.
> 
> Signed-off-by: Mikko Rapeli 
> ---
>  Makefile | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/Makefile b/Makefile
> index 4e93284..c1b515d 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -912,13 +912,13 @@ quiet_cmd_link-vmlinux = LINK$@
>  # execute if the rest of the kernel build went well.
>  vmlinux: scripts/link-vmlinux.sh $(vmlinux-deps) FORCE
>  ifdef CONFIG_HEADERS_CHECK
> - $(Q)$(MAKE) -f $(srctree)/Makefile headers_check
> + $(Q)$(MAKE) V=$(KBUILD_VERBOSE) -f $(srctree)/Makefile headers_check
>  endif
>  ifdef CONFIG_SAMPLES
> - $(Q)$(MAKE) $(build)=samples
> + $(Q)$(MAKE) V=$(KBUILD_VERBOSE) $(build)=samples
>  endif
>  ifdef CONFIG_BUILD_DOCSRC
> - $(Q)$(MAKE) $(build)=Documentation
> + $(Q)$(MAKE) V=$(KBUILD_VERBOSE) $(build)=Documentation
>  endif
>   +$(call if_changed,link-vmlinux)
>  
> @@ -1069,7 +1069,7 @@ headers_check_all: headers_install_all
>  PHONY += headers_check
>  headers_check: headers_install
>   $(Q)$(MAKE) $(hdr-inst)=include/uapi HDRCHECK=1
> - $(Q)$(MAKE) $(hdr-inst)=arch/$(hdr-arch)/include/uapi/asm $(hdr-dst) 
> HDRCHECK=1
> + $(Q)$(MAKE) V=$(KBUILD_VERBOSE) 
> $(hdr-inst)=arch/$(hdr-arch)/include/uapi/asm $(hdr-dst) HDRCHECK=1
>  
>  # ---
>  # Kernel selftest



If you give V=... from the command line, it is automatically propagated
to its sub-makes.

I think this patch has no point.


Best Regards
Masahiro Yamada

--
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 2/2] ocfs2: remove unneeded 'rc' for kfree()

2015-02-16 Thread Daeseok Youn
If kzalloc() is failed, just goto 'out' label and
'out_free' label doesn't need to check 'rc' variable.

Signed-off-by: Daeseok Youn 
---
 fs/ocfs2/stack_o2cb.c |5 ++---
 1 files changed, 2 insertions(+), 3 deletions(-)

diff --git a/fs/ocfs2/stack_o2cb.c b/fs/ocfs2/stack_o2cb.c
index 813d726..46ab104 100644
--- a/fs/ocfs2/stack_o2cb.c
+++ b/fs/ocfs2/stack_o2cb.c
@@ -347,7 +347,7 @@ static int o2cb_cluster_connect(struct 
ocfs2_cluster_connection *conn)
priv = kzalloc(sizeof(struct o2dlm_private), GFP_KERNEL);
if (!priv) {
rc = -ENOMEM;
-   goto out_free;
+   goto out;
}
 
/* This just fills the structure in.  It is safe to pass conn. */
@@ -376,8 +376,7 @@ static int o2cb_cluster_connect(struct 
ocfs2_cluster_connection *conn)
dlm_register_eviction_cb(dlm, >op_eviction_cb);
 
 out_free:
-   if (rc)
-   kfree(conn->cc_private);
+   kfree(conn->cc_private);
 
 out:
return rc;
-- 
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 1/2] ocfs2: remove useless if statement

2015-02-16 Thread Daeseok Youn
The Local variable "i" in for loop is always less then
O2CB_MAP_STABILIZE_COUNT.

Signed-off-by: Daeseok Youn 
---
 fs/ocfs2/stack_o2cb.c |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/fs/ocfs2/stack_o2cb.c b/fs/ocfs2/stack_o2cb.c
index 1724d43..813d726 100644
--- a/fs/ocfs2/stack_o2cb.c
+++ b/fs/ocfs2/stack_o2cb.c
@@ -295,8 +295,8 @@ static int o2cb_cluster_check(void)
set_bit(node_num, netmap);
if (!memcmp(hbmap, netmap, sizeof(hbmap)))
return 0;
-   if (i < O2CB_MAP_STABILIZE_COUNT)
-   msleep(1000);
+
+   msleep(1000);
}
 
printk(KERN_ERR "o2cb: This node could not connect to nodes:");
-- 
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 V2 1/3] xen: mark pvscsi frontend request consumed only after last read

2015-02-16 Thread Juergen Gross
A request in the ring buffer mustn't be read after it has been marked
as consumed. Otherwise it might already have been reused by the
frontend without violating the ring protocol.

To avoid inconsistencies in the backend only work on a private copy
of the request. This will ensure a malicious guest not being able to
bypass consistency checks of the backend by modifying an active
request.

Signed-off-by: Juergen Gross 
---
 drivers/xen/xen-scsiback.c | 14 ++
 1 file changed, 6 insertions(+), 8 deletions(-)

diff --git a/drivers/xen/xen-scsiback.c b/drivers/xen/xen-scsiback.c
index 61653a0..9faca6a 100644
--- a/drivers/xen/xen-scsiback.c
+++ b/drivers/xen/xen-scsiback.c
@@ -709,12 +709,11 @@ static int prepare_pending_reqs(struct vscsibk_info *info,
 static int scsiback_do_cmd_fn(struct vscsibk_info *info)
 {
struct vscsiif_back_ring *ring = >ring;
-   struct vscsiif_request *ring_req;
+   struct vscsiif_request ring_req;
struct vscsibk_pend *pending_req;
RING_IDX rc, rp;
int err, more_to_do;
uint32_t result;
-   uint8_t act;
 
rc = ring->req_cons;
rp = ring->sring->req_prod;
@@ -735,11 +734,10 @@ static int scsiback_do_cmd_fn(struct vscsibk_info *info)
if (!pending_req)
return 1;
 
-   ring_req = RING_GET_REQUEST(ring, rc);
+   ring_req = *RING_GET_REQUEST(ring, rc);
ring->req_cons = ++rc;
 
-   act = ring_req->act;
-   err = prepare_pending_reqs(info, ring_req, pending_req);
+   err = prepare_pending_reqs(info, _req, pending_req);
if (err) {
switch (err) {
case -ENODEV:
@@ -755,9 +753,9 @@ static int scsiback_do_cmd_fn(struct vscsibk_info *info)
return 1;
}
 
-   switch (act) {
+   switch (ring_req.act) {
case VSCSIIF_ACT_SCSI_CDB:
-   if (scsiback_gnttab_data_map(ring_req, pending_req)) {
+   if (scsiback_gnttab_data_map(_req, pending_req)) {
scsiback_fast_flush_area(pending_req);
scsiback_do_resp_with_sense(NULL,
DRIVER_ERROR << 24, 0, pending_req);
@@ -768,7 +766,7 @@ static int scsiback_do_cmd_fn(struct vscsibk_info *info)
break;
case VSCSIIF_ACT_SCSI_ABORT:
scsiback_device_action(pending_req, TMR_ABORT_TASK,
-   ring_req->ref_rqid);
+   ring_req.ref_rqid);
break;
case VSCSIIF_ACT_SCSI_RESET:
scsiback_device_action(pending_req, TMR_LUN_RESET, 0);
-- 
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 V2 2/3] xen: scsiback: add LUN of restored domain

2015-02-16 Thread Juergen Gross
When a xen domain is being restored the LUN state of a pvscsi device
is "Connected" and not "Initialising" as in case of attaching a new
pvscsi LUN.

This must be taken into account when adding a new pvscsi device for
a domain as otherwise the pvscsi LUN won't be connected to the
SCSI target associated with it.

Signed-off-by: Juergen Gross 
---
 drivers/xen/xen-scsiback.c | 19 ++-
 1 file changed, 14 insertions(+), 5 deletions(-)

diff --git a/drivers/xen/xen-scsiback.c b/drivers/xen/xen-scsiback.c
index 9faca6a..9d60176 100644
--- a/drivers/xen/xen-scsiback.c
+++ b/drivers/xen/xen-scsiback.c
@@ -992,7 +992,7 @@ found:
 }
 
 static void scsiback_do_add_lun(struct vscsibk_info *info, const char *state,
-   char *phy, struct ids_tuple *vir)
+   char *phy, struct ids_tuple *vir, int try)
 {
if (!scsiback_add_translation_entry(info, phy, vir)) {
if (xenbus_printf(XBT_NIL, info->dev->nodename, state,
@@ -1000,7 +1000,7 @@ static void scsiback_do_add_lun(struct vscsibk_info 
*info, const char *state,
pr_err("xen-pvscsi: xenbus_printf error %s\n", state);
scsiback_del_translation_entry(info, vir);
}
-   } else {
+   } else if (!try) {
xenbus_printf(XBT_NIL, info->dev->nodename, state,
  "%d", XenbusStateClosed);
}
@@ -1060,10 +1060,19 @@ static void scsiback_do_1lun_hotplug(struct 
vscsibk_info *info, int op,
 
switch (op) {
case VSCSIBACK_OP_ADD_OR_DEL_LUN:
-   if (device_state == XenbusStateInitialising)
-   scsiback_do_add_lun(info, state, phy, );
-   if (device_state == XenbusStateClosing)
+   switch (device_state) {
+   case XenbusStateInitialising:
+   scsiback_do_add_lun(info, state, phy, , 0);
+   break;
+   case XenbusStateConnected:
+   scsiback_do_add_lun(info, state, phy, , 1);
+   break;
+   case XenbusStateClosing:
scsiback_do_del_lun(info, state, );
+   break;
+   default:
+   break;
+   }
break;
 
case VSCSIBACK_OP_UPDATEDEV_STATE:
-- 
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 V2 0/3] xen: pvscsi: avoid race, support suspend/resume

2015-02-16 Thread Juergen Gross
In the pvscsi backend copy the frontend request to ensure it is not
changed by the frontend during processing it in the backend.

Support suspend/resume of the domain to be able to access a pvscsi
device n the frontend afterwards.

Changes in V2:
- changed scsiback_do_cmd_fn() as sugested by Jan Beulich
- added adaption of backend parameters in frontend after resuming

Juergen Gross (3):
  xen: mark pvscsi frontend request consumed only after last read
  xen: scsiback: add LUN of restored domain
  xen: support suspend/resume in pvscsi frontend

 drivers/scsi/xen-scsifront.c | 214 ---
 drivers/xen/xen-scsiback.c   |  33 ---
 2 files changed, 199 insertions(+), 48 deletions(-)

-- 
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 V2 3/3] xen: support suspend/resume in pvscsi frontend

2015-02-16 Thread Juergen Gross
Up to now the pvscsi frontend hasn't supported domain suspend and
resume. When a domain with an assigned pvscsi device was suspended
and resumed again, it was not able to use the device any more: trying
to do so resulted in hanging processes.

Support suspend and resume of pvscsi devices.

Signed-off-by: Juergen Gross 
---
 drivers/scsi/xen-scsifront.c | 214 ---
 1 file changed, 179 insertions(+), 35 deletions(-)

diff --git a/drivers/scsi/xen-scsifront.c b/drivers/scsi/xen-scsifront.c
index 34199d2..78d9506 100644
--- a/drivers/scsi/xen-scsifront.c
+++ b/drivers/scsi/xen-scsifront.c
@@ -63,6 +63,7 @@
 
 #define VSCSIFRONT_OP_ADD_LUN  1
 #define VSCSIFRONT_OP_DEL_LUN  2
+#define VSCSIFRONT_OP_READD_LUN3
 
 /* Tuning point. */
 #define VSCSIIF_DEFAULT_CMD_PER_LUN 10
@@ -113,8 +114,13 @@ struct vscsifrnt_info {
DECLARE_BITMAP(shadow_free_bitmap, VSCSIIF_MAX_REQS);
struct vscsifrnt_shadow *shadow[VSCSIIF_MAX_REQS];
 
+   /* Following items are protected by the host lock. */
wait_queue_head_t wq_sync;
+   wait_queue_head_t wq_pause;
unsigned int wait_ring_available:1;
+   unsigned int waiting_pause:1;
+   unsigned int pause:1;
+   unsigned callers;
 
char dev_state_path[64];
struct task_struct *curr;
@@ -274,31 +280,31 @@ static void scsifront_sync_cmd_done(struct vscsifrnt_info 
*info,
wake_up(>wq_reset);
 }
 
-static int scsifront_cmd_done(struct vscsifrnt_info *info)
+static void scsifront_do_response(struct vscsifrnt_info *info,
+ struct vscsiif_response *ring_rsp)
+{
+   if (WARN(ring_rsp->rqid >= VSCSIIF_MAX_REQS ||
+test_bit(ring_rsp->rqid, info->shadow_free_bitmap),
+"illegal rqid %u returned by backend!\n", ring_rsp->rqid))
+   return;
+
+   if (info->shadow[ring_rsp->rqid]->act == VSCSIIF_ACT_SCSI_CDB)
+   scsifront_cdb_cmd_done(info, ring_rsp);
+   else
+   scsifront_sync_cmd_done(info, ring_rsp);
+}
+
+static int scsifront_ring_drain(struct vscsifrnt_info *info)
 {
struct vscsiif_response *ring_rsp;
RING_IDX i, rp;
int more_to_do = 0;
-   unsigned long flags;
-
-   spin_lock_irqsave(info->host->host_lock, flags);
 
rp = info->ring.sring->rsp_prod;
rmb();  /* ordering required respective to dom0 */
for (i = info->ring.rsp_cons; i != rp; i++) {
-
ring_rsp = RING_GET_RESPONSE(>ring, i);
-
-   if (WARN(ring_rsp->rqid >= VSCSIIF_MAX_REQS ||
-test_bit(ring_rsp->rqid, info->shadow_free_bitmap),
-"illegal rqid %u returned by backend!\n",
-ring_rsp->rqid))
-   continue;
-
-   if (info->shadow[ring_rsp->rqid]->act == VSCSIIF_ACT_SCSI_CDB)
-   scsifront_cdb_cmd_done(info, ring_rsp);
-   else
-   scsifront_sync_cmd_done(info, ring_rsp);
+   scsifront_do_response(info, ring_rsp);
}
 
info->ring.rsp_cons = i;
@@ -308,6 +314,18 @@ static int scsifront_cmd_done(struct vscsifrnt_info *info)
else
info->ring.sring->rsp_event = i + 1;
 
+   return more_to_do;
+}
+
+static int scsifront_cmd_done(struct vscsifrnt_info *info)
+{
+   int more_to_do;
+   unsigned long flags;
+
+   spin_lock_irqsave(info->host->host_lock, flags);
+
+   more_to_do = scsifront_ring_drain(info);
+
info->wait_ring_available = 0;
 
spin_unlock_irqrestore(info->host->host_lock, flags);
@@ -328,6 +346,24 @@ static irqreturn_t scsifront_irq_fn(int irq, void *dev_id)
return IRQ_HANDLED;
 }
 
+static void scsifront_finish_all(struct vscsifrnt_info *info)
+{
+   unsigned i;
+   struct vscsiif_response resp;
+
+   scsifront_ring_drain(info);
+
+   for (i = 0; i < VSCSIIF_MAX_REQS; i++) {
+   if (test_bit(i, info->shadow_free_bitmap))
+   continue;
+   resp.rqid = i;
+   resp.sense_len = 0;
+   resp.rslt = DID_RESET << 16;
+   resp.residual_len = 0;
+   scsifront_do_response(info, );
+   }
+}
+
 static int map_data_for_request(struct vscsifrnt_info *info,
struct scsi_cmnd *sc,
struct vscsiif_request *ring_req,
@@ -475,6 +511,27 @@ static struct vscsiif_request *scsifront_command2ring(
return ring_req;
 }
 
+static int scsifront_enter(struct vscsifrnt_info *info)
+{
+   if (info->pause)
+   return 1;
+   info->callers++;
+   return 0;
+}
+
+static void scsifront_return(struct vscsifrnt_info *info)
+{
+   info->callers--;
+   if (info->callers)
+   return;
+
+   if (!info->waiting_pause)
+   return;
+
+   info->waiting_pause = 0;
+   

[PATCH v4] modify the IO_TLB_SEGSIZE and IO_TLB_DEFAULT_SIZE configurable as flexible requirement about SW-IOMMU.

2015-02-16 Thread Wang Xiaoming
The maximum of SW-IOMMU is limited to 2^11*128 = 256K.
And the size of IO_TLB_DEFAULT_SIZE is limited to (64UL<<20) 64M.
While in different platform and different requirement this seems improper.
So modifing the IO_TLB_SEGSIZE to io_tlb_segsize and IO_TLB_DEFAULT_SIZE
to io_tlb_default_size which can configure by kernel cmdline.
This can meet different requirement.

Signed-off-by: Chuansheng Liu 
Signed-off-by: Zhang Dongxing 
Signed-off-by: Wang Xiaoming 
---
patch v1 make this change at Kconfig
which needs to edit the .config manually.
https://lkml.org/lkml/2015/1/25/571

patch v2 only change IO_TLB_SEGSIZE configurable
https://lkml.org/lkml/2015/2/5/812

patch v3 parsing io_tlb_segsize and 
io_tlb_default_size independently
https://lkml.org/lkml/2015/2/15/217

 Documentation/kernel-parameters.txt  |4 ++-
 arch/mips/cavium-octeon/dma-octeon.c |2 +-
 arch/mips/netlogic/common/nlm-dma.c  |2 +-
 drivers/xen/swiotlb-xen.c|6 ++--
 include/linux/swiotlb.h  |8 +
 lib/swiotlb.c|   57 --
 6 files changed, 49 insertions(+), 30 deletions(-)

diff --git a/Documentation/kernel-parameters.txt 
b/Documentation/kernel-parameters.txt
index 4df73da..dd03ff0 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -3438,10 +3438,12 @@ bytes respectively. Such letter suffixes can also be 
entirely omitted.
it if 0 is given (See Documentation/cgroups/memory.txt)
 
swiotlb=[ARM,IA-64,PPC,MIPS,X86]
-   Format: {  | force }
+   Format: {  | force |  | }
 -- Number of I/O TLB slabs
force -- force using of bounce buffers even if they
 wouldn't be automatically used by the kernel
+-- Maximum allowable number of contiguous slabs 
to map
+-- The size of SW-MMU mapped.
 
switches=   [HW,M68k]
 
diff --git a/arch/mips/cavium-octeon/dma-octeon.c 
b/arch/mips/cavium-octeon/dma-octeon.c
index 3778655..a521af6 100644
--- a/arch/mips/cavium-octeon/dma-octeon.c
+++ b/arch/mips/cavium-octeon/dma-octeon.c
@@ -312,7 +312,7 @@ void __init plat_swiotlb_setup(void)
swiotlbsize = 64 * (1<<20);
 #endif
swiotlb_nslabs = swiotlbsize >> IO_TLB_SHIFT;
-   swiotlb_nslabs = ALIGN(swiotlb_nslabs, IO_TLB_SEGSIZE);
+   swiotlb_nslabs = ALIGN(swiotlb_nslabs, io_tlb_segsize);
swiotlbsize = swiotlb_nslabs << IO_TLB_SHIFT;
 
octeon_swiotlb = alloc_bootmem_low_pages(swiotlbsize);
diff --git a/arch/mips/netlogic/common/nlm-dma.c 
b/arch/mips/netlogic/common/nlm-dma.c
index f3d4ae8..eeffa8f 100644
--- a/arch/mips/netlogic/common/nlm-dma.c
+++ b/arch/mips/netlogic/common/nlm-dma.c
@@ -99,7 +99,7 @@ void __init plat_swiotlb_setup(void)
 
swiotlbsize = 1 << 20; /* 1 MB for now */
swiotlb_nslabs = swiotlbsize >> IO_TLB_SHIFT;
-   swiotlb_nslabs = ALIGN(swiotlb_nslabs, IO_TLB_SEGSIZE);
+   swiotlb_nslabs = ALIGN(swiotlb_nslabs, io_tlb_segsize);
swiotlbsize = swiotlb_nslabs << IO_TLB_SHIFT;
 
nlm_swiotlb = alloc_bootmem_low_pages(swiotlbsize);
diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
index 810ad41..3b3e9fe 100644
--- a/drivers/xen/swiotlb-xen.c
+++ b/drivers/xen/swiotlb-xen.c
@@ -164,11 +164,11 @@ xen_swiotlb_fixup(void *buf, size_t size, unsigned long 
nslabs)
dma_addr_t dma_handle;
phys_addr_t p = virt_to_phys(buf);
 
-   dma_bits = get_order(IO_TLB_SEGSIZE << IO_TLB_SHIFT) + PAGE_SHIFT;
+   dma_bits = get_order(io_tlb_segsize << IO_TLB_SHIFT) + PAGE_SHIFT;
 
i = 0;
do {
-   int slabs = min(nslabs - i, (unsigned long)IO_TLB_SEGSIZE);
+   int slabs = min(nslabs - i, (unsigned long)io_tlb_segsize);
 
do {
rc = xen_create_contiguous_region(
@@ -187,7 +187,7 @@ static unsigned long xen_set_nslabs(unsigned long nr_tbl)
 {
if (!nr_tbl) {
xen_io_tlb_nslabs = (64 * 1024 * 1024 >> IO_TLB_SHIFT);
-   xen_io_tlb_nslabs = ALIGN(xen_io_tlb_nslabs, IO_TLB_SEGSIZE);
+   xen_io_tlb_nslabs = ALIGN(xen_io_tlb_nslabs, io_tlb_segsize);
} else
xen_io_tlb_nslabs = nr_tbl;
 
diff --git a/include/linux/swiotlb.h b/include/linux/swiotlb.h
index e7a018e..13506db 100644
--- a/include/linux/swiotlb.h
+++ b/include/linux/swiotlb.h
@@ -8,13 +8,7 @@ struct dma_attrs;
 struct scatterlist;
 
 extern int swiotlb_force;
-
-/*
- * Maximum allowable number of contiguous slabs to map,
- * must be a power of 2.  What is the appropriate value ?
- * The complexity of {map,unmap}_single is linearly dependent on this value.
- */
-#define IO_TLB_SEGSIZE 128
+extern int io_tlb_segsize;
 
 /*
  * log of the size of each IO TLB slab.  The number of slabs is command line
diff 

Re: [PATCH 39/45] include/uapi/sound/asequencer.h: include sound/asound.h

2015-02-16 Thread Takashi Iwai
At Tue, 17 Feb 2015 00:05:42 +0100,
Mikko Rapeli wrote:
> 
> Fixes userspace compilation error:
> error: unknown type name ‘snd_seq_client_type_t’
> snd_seq_client_type_t type; /* client type */
> 
> Signed-off-by: Mikko Rapeli 

Applied for 3.21, thanks.


Takashi

> ---
>  include/uapi/sound/asequencer.h | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/include/uapi/sound/asequencer.h b/include/uapi/sound/asequencer.h
> index 09c8a00..5a5fa49 100644
> --- a/include/uapi/sound/asequencer.h
> +++ b/include/uapi/sound/asequencer.h
> @@ -22,6 +22,7 @@
>  #ifndef _UAPI__SOUND_ASEQUENCER_H
>  #define _UAPI__SOUND_ASEQUENCER_H
>  
> +#include 
>  
>  /** version of the sequencer */
>  #define SNDRV_SEQ_VERSION SNDRV_PROTOCOL_VERSION (1, 0, 1)
> -- 
> 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 35/45] include/uapi/sound/asound.h: include stdlib.h in userspace

2015-02-16 Thread Takashi Iwai
At Tue, 17 Feb 2015 00:05:38 +0100,
Mikko Rapeli wrote:
> 
> Fixes compiler errors like:
> error: field ‘trigger_tstamp’ has incomplete type
> error: invalid application of ‘sizeof’ to incomplete t
> ype ‘struct timespec’
> 
> Signed-off-by: Mikko Rapeli 

Applied for 3.21, thanks.


Takashi

> ---
>  include/uapi/sound/asound.h | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/include/uapi/sound/asound.h b/include/uapi/sound/asound.h
> index 941d32f..af156b0 100644
> --- a/include/uapi/sound/asound.h
> +++ b/include/uapi/sound/asound.h
> @@ -25,6 +25,9 @@
>  
>  #include 
>  
> +#ifndef __KERNEL__
> +#include 
> +#endif
>  
>  /*
>   *  protocol version
> -- 
> 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 40/45] include/uapi/sound/emu10k1.h: include sound/asound.h

2015-02-16 Thread Takashi Iwai
At Tue, 17 Feb 2015 00:05:43 +0100,
Mikko Rapeli wrote:
> 
> Fixes userspace compilation errors like:
> error: field ‘id’ has incomplete type
> struct snd_ctl_elem_id id;  /* full control ID definition */
> 
> Signed-off-by: Mikko Rapeli 

Applied for 3.21, thanks.


Takashi

> ---
>  include/uapi/sound/emu10k1.h | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/include/uapi/sound/emu10k1.h b/include/uapi/sound/emu10k1.h
> index d1bbaf7..ec1535b 100644
> --- a/include/uapi/sound/emu10k1.h
> +++ b/include/uapi/sound/emu10k1.h
> @@ -23,8 +23,7 @@
>  #define _UAPI__SOUND_EMU10K1_H
>  
>  #include 
> -
> -
> +#include 
>  
>  /*
>   *  FX8010 
> -- 
> 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 24/45] hdspm.h: include stdint.h in userspace

2015-02-16 Thread Takashi Iwai
At Tue, 17 Feb 2015 00:05:27 +0100,
Mikko Rapeli wrote:
> 
> Fixes compilation error:
> 
> sound/hdspm.h:43:2: error: unknown type name ‘uint32_t’
> 
> Signed-off-by: Mikko Rapeli 

Applied for 3.21, thanks.


Takashi

> ---
>  include/uapi/sound/hdspm.h | 6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/include/uapi/sound/hdspm.h b/include/uapi/sound/hdspm.h
> index d956c35..f799828 100644
> --- a/include/uapi/sound/hdspm.h
> +++ b/include/uapi/sound/hdspm.h
> @@ -20,6 +20,12 @@
>   *   Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
>   */
>  
> +#ifdef __KERNEL__
> +#include 
> +#else
> +#include 
> +#endif
> +
>  /* Maximum channels is 64 even on 56Mode you have 64playbacks to matrix */
>  #define HDSPM_MAX_CHANNELS  64
>  
> -- 
> 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] compat: Fix endian issue in union sigval

2015-02-16 Thread Bamvor Jian Zhang
On 2015/2/14 19:22, Catalin Marinas wrote:
> On Fri, Feb 13, 2015 at 04:56:29PM -0500, Chris Metcalf wrote:
>> On 2/13/2015 5:44 AM, Catalin Marinas wrote:
>>> On Fri, Feb 13, 2015 at 04:00:43PM +0800, Bamvor Jian Zhang wrote:
 diff --git a/arch/arm64/kernel/signal32.c b/arch/arm64/kernel/signal32.c
 index e299de396e9b..32601939a3c8 100644
 --- a/arch/arm64/kernel/signal32.c
 +++ b/arch/arm64/kernel/signal32.c
 @@ -154,8 +154,7 @@ int copy_siginfo_to_user32(compat_siginfo_t __user 
 *to, const siginfo_t *from)
case __SI_TIMER:
 err |= __put_user(from->si_tid, >si_tid);
 err |= __put_user(from->si_overrun, >si_overrun);
 -   err |= __put_user((compat_uptr_t)(unsigned long)from->si_ptr,
 - >si_ptr);
 +   err |= __put_user(from->si_int, >si_int);
break;
case __SI_POLL:
err |= __put_user(from->si_band, >si_band);
 @@ -184,7 +183,7 @@ int copy_siginfo_to_user32(compat_siginfo_t __user 
 *to, const siginfo_t *from)
case __SI_MESGQ: /* But this is */
err |= __put_user(from->si_pid, >si_pid);
err |= __put_user(from->si_uid, >si_uid);
 -  err |= __put_user((compat_uptr_t)(unsigned long)from->si_ptr, 
 >si_ptr);
 +  err |= __put_user(from->si_int, >si_int);
break;
case __SI_SYS:
err |= __put_user((compat_uptr_t)(unsigned long)
>>
>> I must be confused here, but I don't see that these do anything different.
>>
>> If we are writing 32 bits to to->si_ptr or to->si_int, either way the high 
>> 32 bits
>> are irrelevant.  So whether we read it from from->si_ptr and massage the 
>> high bits,
>> or just read it from from->si_int as a straight-up 32-bit quantity, either 
>> way it
>> seems we should end up writing the same bits to userspace.
>>
>> I would understand the argument if we were overlaying the si_ptr/si_int union
>> from a kernel-side siginfo_t where si_ptr and si_int are different sizes
>> onto userspace, but it doesn't seem we ever do that.
> 
> That's the problem, "from" above is a kernel siginfo_t while "to" is a
> compat_siginfo_t. The call paths go something like:
> 
> 1. user populates sival_int compat_sigevent and invokes
>compat_sys_mq_notify()
> 2. kernel get_compat_sigevent() copies compat_sigevent into the native
>sigevent. compat and native sival_int are the same, no problem so
>far. The other half of 64-bit sival_ptr is zeroed by a memset in this
>function (this other half can be top or bottom, depending on
>endianness)
> 3. signal is about to be delivered to user via arch code. The
>compat_ptr(from->si_ptr) conversion always takes the least
>significant part of the native si_ptr. On big endian 64-bit, this is
>zero because get_compat_sigevent() populated the top part of si_ptr
>with si_int.
> 
> So delivering such signals to compat user always sets si_int to 0.
> Little endian is fine.
> 
> A similar example is sys_timer_create() which takes a sigevent argument.
> Maybe Bamvor has a test case.
> A similar example is sys_timer_create() which takes a sigevent argument.
> Maybe Bamvor has a test case.
Yeap, this issue is came from glibc rt testcases(tst-cputimer1,
tst-cputimer2, tst-cputimer3, tst-timer4, tst-timer5). The above test
cases include timer_create syscall with sigevent.sigev_notify = SIGEV_THREAD.
They failed when they compiled as armeb elf and run on aarch64_be kernel.
When I try to fix it, I found sys_mq_notify is similar.

regards

bamvor
> (btw, I'm off for a week, I'll follow up when I get back)
> 


--
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 41/45] include/uapi/sound/emu10k1.h: hide gpr_valid, tram_valid and code_valid in userspace

2015-02-16 Thread Takashi Iwai
At Tue, 17 Feb 2015 00:05:44 +0100,
Mikko Rapeli wrote:
> 
> The DECLARE_BITMAP macro is not available in userspace headers.
> Fixes userspace compile error:
> error: expected specifier-qualifier-list before ‘DECLARE_BITMAP’

It's nonsense.  This results in an incompatible structure, thus ABI
would be broken completely (actually this will break the compile of
ld10k1).


Takashi

> 
> Signed-off-by: Mikko Rapeli 
> ---
>  include/uapi/sound/emu10k1.h | 6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/include/uapi/sound/emu10k1.h b/include/uapi/sound/emu10k1.h
> index ec1535b..f2fd870 100644
> --- a/include/uapi/sound/emu10k1.h
> +++ b/include/uapi/sound/emu10k1.h
> @@ -300,7 +300,9 @@ struct snd_emu10k1_fx8010_control_old_gpr {
>  struct snd_emu10k1_fx8010_code {
>   char name[128];
>  
> +#ifdef __KERNEL__
>   DECLARE_BITMAP(gpr_valid, 0x200); /* bitmask of valid initializers */
> +#endif
>   __u32 __user *gpr_map;  /* initializers */
>  
>   unsigned int gpr_add_control_count; /* count of GPR controls to 
> add/replace */
> @@ -313,11 +315,15 @@ struct snd_emu10k1_fx8010_code {
>   unsigned int gpr_list_control_total; /* total count of GPR controls */
>   struct snd_emu10k1_fx8010_control_gpr __user *gpr_list_controls; /* 
> listed GPR controls */
>  
> +#ifdef __KERNEL__
>   DECLARE_BITMAP(tram_valid, 0x100); /* bitmask of valid initializers */
> +#endif
>   __u32 __user *tram_data_map;  /* data initializers */
>   __u32 __user *tram_addr_map;  /* map initializers */
>  
> +#ifdef __KERNEL__
>   DECLARE_BITMAP(code_valid, 1024); /* bitmask of valid instructions */
> +#endif
>   __u32 __user *code;   /* one instruction - 64 bits */
>  };
>  
> -- 
> 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: [PATCHv2 1/2] pci: spear: Use platform_driver_probe instead of platform_driver_register

2015-02-16 Thread Viresh Kumar
On 15 February 2015 at 21:16, Matwey V. Kornilov  wrote:
> Or maybe it doesn't work at all.

It wouldn't have as that wasn't required earlier. But when we are fixing it, we
fix it proper.
--
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 v4 4/5] usb: dwc3: Add quirk for Synopsis device disconnection errata

2015-02-16 Thread Sneeker Yeh
Synopsis Designware USB3 IP earlier than v3.00a which is configured in silicon
with DWC_USB3_SUSPEND_ON_DISCONNECT_EN=1, would need a specific quirk to prevent
xhci host controller from dying when device is disconnected.

Since DWC_USB3_SUSPEND_ON_DISCONNECT_EN is an IP configuration whose state
cannot be checked from software in runtime, it has to be enabled via platform
data or device tree.

Signed-off-by: Sneeker Yeh 
---
 Documentation/devicetree/bindings/usb/dwc3.txt |   17 +
 drivers/usb/dwc3/core.c|6 ++
 drivers/usb/dwc3/core.h|4 
 drivers/usb/dwc3/host.c|4 
 drivers/usb/dwc3/platform_data.h   |8 
 5 files changed, 39 insertions(+)

diff --git a/Documentation/devicetree/bindings/usb/dwc3.txt 
b/Documentation/devicetree/bindings/usb/dwc3.txt
index cd7f045..1b78b29 100644
--- a/Documentation/devicetree/bindings/usb/dwc3.txt
+++ b/Documentation/devicetree/bindings/usb/dwc3.txt
@@ -37,6 +37,23 @@ Optional properties:
  - snps,is-utmi-l1-suspend: true when DWC3 asserts output signal
utmi_l1_suspend_n, false when asserts utmi_sleep_n
  - snps,hird-threshold: HIRD threshold
+ - snps,has_suspend_on_disconnect: true when IP is configured in silicon with
+   DWC_USB3_SUSPEND_ON_DISCONNECT_EN=1, it can inject a
+   specific quirk to prevent xhci host controller from
+   dying when usb device is disconnected from root hub.
+   Since DWC_USB3_SUSPEND_ON_DISCONNECT_EN is an IP
+   configuration whose state cannot be checked from
+   software in runtime, it has to be enabled via platform
+   data or device tree.
+
+   xhci host dying symptom here is caused by that
+   DWC_USB3_SUSPEND_ON_DISCONNECT_EN=1
+   configuration makes IP auto-suspended after PORTCSC is
+   cleared when usb device detached, then an asynchronous
+   disconnection procedure might fail using endpoint
+   command that suspened IP won't have any response to.
+
+   this issue is fixed when IP version >= 3.00a.
 
 This is usually a subnode to DWC3 glue to which it is connected.
 
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 9f0e209..705980c 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -838,6 +838,9 @@ static int dwc3_probe(struct platform_device *pdev)
"snps,tx_de_emphasis_quirk");
of_property_read_u8(node, "snps,tx_de_emphasis",
_de_emphasis);
+
+   dwc->suspend_on_disconnect_quirk = of_property_read_bool(node,
+   "snps,has_suspend_on_disconnect");
} else if (pdata) {
dwc->maximum_speed = pdata->maximum_speed;
dwc->has_lpm_erratum = pdata->has_lpm_erratum;
@@ -864,6 +867,9 @@ static int dwc3_probe(struct platform_device *pdev)
dwc->tx_de_emphasis_quirk = pdata->tx_de_emphasis_quirk;
if (pdata->tx_de_emphasis)
tx_de_emphasis = pdata->tx_de_emphasis;
+
+   dwc->suspend_on_disconnect_quirk =
+   pdata->has_suspend_on_disconnect;
}
 
/* default to superspeed if no maximum_speed passed */
diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
index 0b3bb0f..dfc7d63 100644
--- a/drivers/usb/dwc3/core.h
+++ b/drivers/usb/dwc3/core.h
@@ -688,6 +688,9 @@ struct dwc3_scratchpad_array {
  * @resize_fifos: tells us it's ok to reconfigure our TxFIFO sizes.
  * @setup_packet_pending: true when there's a Setup Packet in FIFO. Workaround
  * @start_config_issued: true when StartConfig command has been issued
+ * @suspend_on_disconnect_quirk: set if core was configured with
+ * DWC_USB3_SUSPEND_ON_DISCONNECT_EN=1. Note that there's
+ * now way for software to detect this in runtime.
  * @three_stage_setup: set if we perform a three phase setup
  * @disable_scramble_quirk: set if we enable the disable scramble quirk
  * @u2exit_lfps_quirk: set if we enable u2exit lfps quirk
@@ -813,6 +816,7 @@ struct dwc3 {
unsignedresize_fifos:1;
unsignedsetup_packet_pending:1;
unsignedstart_config_issued:1;
+   unsignedsuspend_on_disconnect_quirk:1;
unsignedthree_stage_setup:1;
 
unsigneddisable_scramble_quirk:1;
diff --git a/drivers/usb/dwc3/host.c b/drivers/usb/dwc3/host.c
index 12bfd3c..9c42074 100644
--- a/drivers/usb/dwc3/host.c
+++ b/drivers/usb/dwc3/host.c
@@ -53,6 +53,10 @@ int dwc3_host_init(struct dwc3 *dwc)
pdata.usb3_lpm_capable = 1;

[PATCH v4 1/5] xhci: add a quirk for device disconnection errata for Synopsis Designware USB3 core

2015-02-16 Thread Sneeker Yeh
This issue is defined by a three-way race at disconnect, between
1) Class driver interrupt endpoint resheduling attempts if the ISR gave an ep
   error event due to device detach (it would try 3 times)
2) Disconnect interrupt on PORTSC_CSC, which is cleared by hub thread
   asynchronously
3) The hardware IP was configured in silicon with
   - DWC_USB3_SUSPEND_ON_DISCONNECT_EN=1
   - Synopsys IP version is < 3.00a
The IP will auto-suspend itself on device detach with some phy-specific interval
after CSC is cleared by 2)

If 2) and 3) complete before 1), the interrupts it expects will not be generated
by the autosuspended IP, leading to a deadlock. Even later disconnection
procedure would detect that corresponding urb is still in-progress and issue a
ep stop command, auto-suspended IP still won't respond to that command.

this defect would result in this when device detached:
---
[   99.603544] usb 4-1: USB disconnect, device number 2
[  104.615254] xhci-hcd xhci-hcd.0.auto: xHCI host not responding to stop 
endpoint command.
[  104.623362] xhci-hcd xhci-hcd.0.auto: Assuming host is dying, halting host.
[  104.653261] xhci-hcd xhci-hcd.0.auto: Host not halted after 16000 
microseconds.
[  104.660584] xhci-hcd xhci-hcd.0.auto: Non-responsive xHCI host is not 
halting.
[  104.667817] xhci-hcd xhci-hcd.0.auto: Completing active URBs anyway.
[  104.674198] xhci-hcd xhci-hcd.0.auto: HC died; cleaning up
--
As a result, when device detached, we desired to postpone "PORTCSC clear" behind
"disable slot". it's found that all executed ep command related to disconnetion,
are executed before "disable slot".

Signed-off-by: Sneeker Yeh 
---
 drivers/usb/host/xhci-hub.c |4 
 drivers/usb/host/xhci.c |   31 +++
 drivers/usb/host/xhci.h |   24 
 3 files changed, 59 insertions(+)

diff --git a/drivers/usb/host/xhci-hub.c b/drivers/usb/host/xhci-hub.c
index a7865c4..3b8f7fc 100644
--- a/drivers/usb/host/xhci-hub.c
+++ b/drivers/usb/host/xhci-hub.c
@@ -368,6 +368,10 @@ static void xhci_clear_port_change_bit(struct xhci_hcd 
*xhci, u16 wValue,
port_change_bit = "warm(BH) reset";
break;
case USB_PORT_FEAT_C_CONNECTION:
+   if ((xhci->quirks & XHCI_DISCONNECT_QUIRK) &&
+   !(readl(addr) & PORT_CONNECT))
+   return;
+
status = PORT_CSC;
port_change_bit = "connect";
break;
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index ec8ac16..1fb8c1c 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -3580,6 +3580,35 @@ command_cleanup:
return ret;
 }
 
+static void xhci_try_to_clear_csc(struct usb_hcd *hcd, int dev_port_num)
+{
+   int max_ports;
+   struct xhci_hcd *xhci = hcd_to_xhci(hcd);
+   __le32 __iomem **port_array;
+   u32 status;
+
+   /* print debug info */
+   if (hcd->speed == HCD_USB3) {
+   max_ports = xhci->num_usb3_ports;
+   port_array = xhci->usb3_ports;
+   } else {
+   max_ports = xhci->num_usb2_ports;
+   port_array = xhci->usb2_ports;
+   }
+
+   if (dev_port_num > max_ports) {
+   xhci_err(xhci, "%s() port number invalid", __func__);
+   return;
+   }
+   status = readl(port_array[dev_port_num - 1]);
+
+   /* write 1 to clear */
+   if (!(status & PORT_CONNECT) && (status & PORT_CSC)) {
+   status = xhci_port_state_to_neutral(status);
+   writel(status | PORT_CSC, port_array[dev_port_num - 1]);
+   }
+}
+
 /*
  * At this point, the struct usb_device is about to go away, the device has
  * disconnected, and all traffic has been stopped and the endpoints have been
@@ -3645,6 +3674,8 @@ void xhci_free_dev(struct usb_hcd *hcd, struct usb_device 
*udev)
xhci_ring_cmd_db(xhci);
spin_unlock_irqrestore(>lock, flags);
 
+   if (xhci->quirks & XHCI_DISCONNECT_QUIRK)
+   xhci_try_to_clear_csc(hcd, udev->portnum);
/*
 * Event command completion handler will free any data structures
 * associated with the slot.  XXX Can free sleep?
diff --git a/drivers/usb/host/xhci.h b/drivers/usb/host/xhci.h
index 9745147..cb74706 100644
--- a/drivers/usb/host/xhci.h
+++ b/drivers/usb/host/xhci.h
@@ -1560,6 +1560,30 @@ struct xhci_hcd {
 #define XHCI_SPURIOUS_WAKEUP   (1 << 18)
 /* For controllers with a broken beyond repair streams implementation */
 #define XHCI_BROKEN_STREAMS(1 << 19)
+/*
+ * This issue is defined by a three-way race at disconnect in Synopsis USB3 IP,
+ * between
+ * 1) Class driver interrupt endpoint resheduling attempts if the ISR gave an 
ep
+ *error event due to device detach (it would try 3 times)
+ * 2) Disconnect interrupt on PORTSC_CSC, which is cleared by hub 

[PATCH v4 3/5] usb: dwc3: add revision number DWC3_REVISION_290A and DWC3_REVISION_300A

2015-02-16 Thread Sneeker Yeh
Add the contstant for v2.90a and v3.00a dwc3 IP detection

Signed-off-by: Sneeker Yeh 
---
 drivers/usb/dwc3/core.h |2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
index d201910..0b3bb0f 100644
--- a/drivers/usb/dwc3/core.h
+++ b/drivers/usb/dwc3/core.h
@@ -772,6 +772,8 @@ struct dwc3 {
 #define DWC3_REVISION_260A 0x5533260a
 #define DWC3_REVISION_270A 0x5533270a
 #define DWC3_REVISION_280A 0x5533280a
+#define DWC3_REVISION_290A 0x5533290a
+#define DWC3_REVISION_300A 0x5533300a
 
enum dwc3_ep0_next  ep0_next_event;
enum dwc3_ep0_state ep0state;
-- 
1.7.9.5

--
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 v4 5/5] usb: dwc3: add Fujitsu Specific Glue layer

2015-02-16 Thread Sneeker Yeh
This patch adds support for Synopsis DesignWare USB3 IP Core found
on Fujitsu Socs.

Signed-off-by: Sneeker Yeh 
---
 .../devicetree/bindings/usb/fujitsu-dwc3.txt   |   33 
 drivers/usb/dwc3/Kconfig   |   11 ++
 drivers/usb/dwc3/Makefile  |1 +
 drivers/usb/dwc3/dwc3-mb86s70.c|  206 
 4 files changed, 251 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/usb/fujitsu-dwc3.txt
 create mode 100644 drivers/usb/dwc3/dwc3-mb86s70.c

diff --git a/Documentation/devicetree/bindings/usb/fujitsu-dwc3.txt 
b/Documentation/devicetree/bindings/usb/fujitsu-dwc3.txt
new file mode 100644
index 000..be091eb
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/fujitsu-dwc3.txt
@@ -0,0 +1,33 @@
+FUJITSU GLUE COMPONENTS
+
+MB86S7x DWC3 GLUE
+- compatible:  Should be "fujitsu,mb86s70-dwc3"
+- clocks:  from common clock binding, handle to usb clock.
+- clock-names: Should contain the following:
+  "core"   Master/Core clock needs to run at a minimum of 125 MHz to
+   support a 4 Gbps IN or 4 Gbps OUT
+   transfer at a given time.
+
+Sub-nodes:
+The dwc3 core should be added as subnode to MB86S7x dwc3 glue.
+- dwc3 :
+   The binding details of dwc3 can be found in:
+   Documentation/devicetree/bindings/usb/dwc3.txt
+
+Example device nodes:
+
+   usb3host: mb86s70_usb3host {
+   compatible = "fujitsu,mb86s70-dwc3";
+   clocks = <_alw_1_1>;
+   clock-names = "core";
+   #address-cells = <2>;
+   #size-cells = <1>;
+   ranges;
+
+   dwc3@3220 {
+   compatible = "synopsys,dwc3";
+   reg = <0 0x3230 0x10>;
+   interrupts = <0 412 0x4>,
+   <0 414 0x4>;
+   };
+   };
diff --git a/drivers/usb/dwc3/Kconfig b/drivers/usb/dwc3/Kconfig
index edbf9c8..8ab0f2c 100644
--- a/drivers/usb/dwc3/Kconfig
+++ b/drivers/usb/dwc3/Kconfig
@@ -61,6 +61,17 @@ config USB_DWC3_EXYNOS
  Recent Exynos5 SoCs ship with one DesignWare Core USB3 IP inside,
  say 'Y' or 'M' if you have one such device.
 
+config USB_DWC3_MB86S70
+   tristate "MB86S70 Designware USB3 Platform code"
+   default USB_DWC3
+   help
+ MB86S7X SOC ship with DesignWare Core USB3 IP inside,
+ this implementation also integrated Fujitsu USB PHY inside
+ this Core USB3 IP.
+
+ say 'Y' or 'M' if you have one such device.
+
+
 config USB_DWC3_PCI
tristate "PCIe-based Platforms"
depends on PCI
diff --git a/drivers/usb/dwc3/Makefile b/drivers/usb/dwc3/Makefile
index 46172f4..76634b7 100644
--- a/drivers/usb/dwc3/Makefile
+++ b/drivers/usb/dwc3/Makefile
@@ -37,3 +37,4 @@ obj-$(CONFIG_USB_DWC3_PCI)+= dwc3-pci.o
 obj-$(CONFIG_USB_DWC3_KEYSTONE)+= dwc3-keystone.o
 obj-$(CONFIG_USB_DWC3_QCOM)+= dwc3-qcom.o
 obj-$(CONFIG_USB_DWC3_ST)  += dwc3-st.o
+obj-$(CONFIG_USB_DWC3_MB86S70) += dwc3-mb86s70.o
diff --git a/drivers/usb/dwc3/dwc3-mb86s70.c b/drivers/usb/dwc3/dwc3-mb86s70.c
new file mode 100644
index 000..301be76
--- /dev/null
+++ b/drivers/usb/dwc3/dwc3-mb86s70.c
@@ -0,0 +1,206 @@
+/**
+ * dwc3-mb86s70.c - Fujitsu mb86s70 DWC3 Specific Glue layer
+ *
+ * Copyright (c) 2013 - 2014 FUJITSU SEMICONDUCTOR LIMITED
+ * http://jp.fujitsu.com/group/fsl
+ *
+ * Authors: Alice Chan 
+ * Sneeker Yeh 
+ * based on dwc3-exynos.c
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+struct dwc3_mb86s70 {
+   struct device   *dev;
+   struct clk  *clks[5];
+   u8  clk_cnt;
+};
+
+static int dwc3_mb86s70_clk_control(struct device *dev, bool on)
+{
+   struct dwc3_mb86s70 *priv = dev_get_drvdata(dev);
+   int ret, i = priv->clk_cnt;
+
+   if (!on)
+   goto clock_off;
+
+   for (i = 0; i < priv->clk_cnt; i++) {
+   ret = clk_prepare_enable(priv->clks[i]);
+   if (ret) {
+   dev_err(dev, "failed to enable clock[%d]\n", i);
+   on = ret;
+   goto clock_off;
+   }
+   }
+
+   return 0;
+
+clock_off:
+   for (; i > 0;)
+   clk_disable_unprepare(priv->clks[--i]);
+
+   return on;
+}
+
+static int dwc3_mb86s70_remove_child(struct device *dev, void *unused)
+{
+   struct platform_device *pdev = to_platform_device(dev);
+
+   of_device_unregister(pdev);
+
+   return 0;
+}
+
+static int 

[PATCH v4 2/5] xhci: Platform: Set Synopsis device disconnection quirk based on platform data

2015-02-16 Thread Sneeker Yeh
If an xhci platform has Synopsis device disconnection errata then enable
XHCI_DISCONNECT_QUIRK quirk flag.

Signed-off-by: Sneeker Yeh 
---
 drivers/usb/host/xhci-plat.c |3 +++
 include/linux/usb/xhci_pdriver.h |4 
 2 files changed, 7 insertions(+)

diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
index 08d402b..40beb95 100644
--- a/drivers/usb/host/xhci-plat.c
+++ b/drivers/usb/host/xhci-plat.c
@@ -147,6 +147,9 @@ static int xhci_plat_probe(struct platform_device *pdev)
if ((node && of_property_read_bool(node, "usb3-lpm-capable")) ||
(pdata && pdata->usb3_lpm_capable))
xhci->quirks |= XHCI_LPM_SUPPORT;
+
+   if (pdata && pdata->delay_portcsc_clear)
+   xhci->quirks |= XHCI_DISCONNECT_QUIRK;
/*
 * Set the xHCI pointer before xhci_plat_setup() (aka hcd_driver.reset)
 * is called by usb_add_hcd().
diff --git a/include/linux/usb/xhci_pdriver.h b/include/linux/usb/xhci_pdriver.h
index 376654b..a37a3a5 100644
--- a/include/linux/usb/xhci_pdriver.h
+++ b/include/linux/usb/xhci_pdriver.h
@@ -18,10 +18,14 @@
  *
  * @usb3_lpm_capable:  determines if this xhci platform supports USB3
  * LPM capability
+ * @delay_portcsc_clear:   determines if Synopsis USB3 core has errata in
+ * "DWC_USB3_SUSPEND_ON_DISCONNECT_EN=1" hardware
+ * configuration.
  *
  */
 struct usb_xhci_pdata {
unsignedusb3_lpm_capable:1;
+   unsigneddelay_portcsc_clear:1;
 };
 
 #endif /* __USB_CORE_XHCI_PDRIVER_H */
-- 
1.7.9.5

--
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 v4 0/5] Add support for Fujitsu USB host controller

2015-02-16 Thread Sneeker Yeh
These patches add support for XHCI compliant Host controller found
on Fujitsu Socs, and are based on http://lwn.net/Articles/629162/
The first patch is to add Fujitsu glue layer of Synopsis DesignWare USB3 driver
and last four patch is about quirk implementation of errata in Synopsis
DesignWare USB3 IP.

Patch 1 introduces a quirk with device disconnection management necessary
Synopsys Designware USB3 IP with versions < 3.00a and hardware configuration
DWC_USB3_SUSPEND_ON_DISCONNECT_EN=1. It solves a problem where without the
quirk, that host controller will die after a usb device is disconnected from
port of root hub.

Patch 2 is to set Synopsis quirk in xhci platform driver based on xhci platform
data.

Patch 3 is to add a revison number 2.90a and 3.00a of Synopsis DesignWare USB3
IP core driver.

Patch 4 introduces using a quirk based on a errata of Synopsis
DesignWare USB3 IP which is versions < 3.00a and has hardware configuration
DWC_USB3_SUSPEND_ON_DISCONNECT_EN=1, which cannot be read from software. As a
result this quirk has to be enabled via platform data or device tree.

Patch 5 introduces Fujitsu Specific Glue layer in Synopsis DesignWare USB3 IP
driver. 

Successfully tested on Fujitsu mb86s7x board.

Changes since v3 (RFC):
[https://lkml.org/lkml/2014/12/15/929]
 - based on Mathias's comment, fix bug and using xhci_port_state_to_neutral()
   helper function to mask out some RW1C bits, prevent writing back all the
   bits read from the PORTSC register.

Changes since v2 (RFC):
[https://lkml.org/lkml/2014/12/15/929]
 - based on Felipe's comment, re-order patches to avoid breaking bisectability,
 - based on Felipe's comment, add comment to structure's member, and sort it
   alphabetically,
 - based on Felipe's comment, add another v2.90 revision number in dwc3 IP.

Changes since v1 (RFC):
[https://lkml.org/lkml/2014/12/15/929]
 - based on Arnd's comment, remove entire unnecessary Fujitsu EHCI/OHCI glue,
 - based on Felipe's comment, fix mis-using of runtime-pm API and setting dma
   mask, remove unnecessary comment, and refactor suspend/resume handler in
   Fujitsu Specific Glue layer in dwc3,
 - based on Felipe's comment, add more commit log and comments in Synopsis
   quirk implementation, and separate it into four patches.

Sneeker Yeh (5):
  xhci: add a quirk for device disconnection errata for Synopsis
Designware USB3 core
  xhci: Platform: Set Synopsis device disconnection quirk based on
platform data
  usb: dwc3: add revision number DWC3_REVISION_290A and
DWC3_REVISION_300A
  usb: dwc3: Add quirk for Synopsis device disconnection errata
  usb: dwc3: add Fujitsu Specific Glue layer

 Documentation/devicetree/bindings/usb/dwc3.txt |   17 ++
 .../devicetree/bindings/usb/fujitsu-dwc3.txt   |   33 
 drivers/usb/dwc3/Kconfig   |   11 ++
 drivers/usb/dwc3/Makefile  |1 +
 drivers/usb/dwc3/core.c|6 +
 drivers/usb/dwc3/core.h|6 +
 drivers/usb/dwc3/dwc3-mb86s70.c|  206 
 drivers/usb/dwc3/host.c|4 +
 drivers/usb/dwc3/platform_data.h   |8 +
 drivers/usb/host/xhci-hub.c|4 +
 drivers/usb/host/xhci-plat.c   |3 +
 drivers/usb/host/xhci.c|   31 +++
 drivers/usb/host/xhci.h|   24 +++
 include/linux/usb/xhci_pdriver.h   |4 +
 14 files changed, 358 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/usb/fujitsu-dwc3.txt
 create mode 100644 drivers/usb/dwc3/dwc3-mb86s70.c

-- 
1.7.9.5

--
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] perf_event_open.2: Clarify PERF_EVENT_IOC_REFRESH behavior

2015-02-16 Thread Michael Kerrisk (man-pages)
On 02/12/2015 06:14 PM, Vince Weaver wrote:
> 
> Currently the PERF_EVENT_IOC_REFRESH ioctl, when applied to a group
> leader, will refresh all children.  Also if a refresh value of 0
> is chosen then the refresh becomes infinite (never runs out).
> Back in 2011 PAPI was relying on these behaviors but I was told
> that both were unsupported and subject to being removed at any time.
>(See https://lkml.org/lkml/2011/5/24/337 )
> However the behavior has not been changed.  

Thanks, Vince. Applied.

Cheers,

Michael


> This patch updates the manpage to still list the behavior as
> unsupported, but removes the innacurate description of it 
> only being a problem with 2.6 kernels.
> 
> Signed-off-by: Vince Weaver 
> 
> diff --git a/man2/perf_event_open.2 b/man2/perf_event_open.2
> index 39c8d8c..76136e2 100644
> --- a/man2/perf_event_open.2
> +++ b/man2/perf_event_open.2
> @@ -2353,6 +2353,12 @@ once the counter reaches 0
>  is indicated and
>  the underlying event is disabled.
>  
> +Refreshing an event group leader refreshes all siblings and
> +refreshing with a parameter of 0 currently enables infinite
> +refreshes;
> +these behaviors are unsupported and should not be relied on.
> +.\" See https://lkml.org/lkml/2011/5/24/337
> +
>  Starting with Linux 3.18,
>  .\" commit 179033b3e064d2cd3f5f9945e76b0a0f0fbf4883
>  .B POLL_HUP
> @@ -2805,11 +2811,6 @@ Prior to Linux 2.6.35,
>  .B PERF_FORMAT_GROUP
>  did not work with attached processes.
>  
> -In older Linux 2.6 versions,
> -refreshing an event group leader refreshed all siblings,
> -and refreshing with a parameter of 0 enabled infinite refresh.
> -This behavior is unsupported and should not be relied on.
> -
>  There is a bug in the kernel code between
>  Linux 2.6.36 and Linux 3.0 that ignores the
>  "watermark" field and acts as if a wakeup_event
> 
> 


-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
--
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] perf_event_open.2: 3.19 PERF_SAMPLE_REGS_INTR support

2015-02-16 Thread Michael Kerrisk (man-pages)
Hi Stephane (and Jiri),

Would you be willing to review/comment on Vince's patch, please.

Cheers,

Michael


On 02/12/2015 06:33 AM, Vince Weaver wrote:
> 
> This manpage patch relates to the addition of PERF_SAMPLE_REGS_INTR
> support added in the following commit:
> 
> perf_sample_regs_intr; Linux 3.19
>   commit 60e2364e60e86e81bc6377f49779779e6120977f
>   Author: Stephane Eranian 
> 
> perf: Add ability to sample machine state on interrupt
> 
>   Reviewed-by: Jiri Olsa 
>   Signed-off-by: Stephane Eranian 
>   Signed-off-by: Peter Zijlstra (Intel) 
>   Cc: cebbert.l...@gmail.com
>   Cc: Arnaldo Carvalho de Melo 
>   Cc: Linus Torvalds 
>   Cc: linux-...@vger.kernel.org
>   Link: 
> http://lkml.kernel.org/r/1411559322-16548-2-git-send-email-eran...@google.com
>   Signed-off-by: Ingo Molnar 
> 
>>From what I can tell the primary difference between 
> PERF_SAMPLE_REGS_INTR and the existing PERF_SAMPLE_REGS_USER
> is that the new support will return kernel register values
> (I assume that's not some sort of info leak?).
> 
> In theory also when precise_ip is set high enough you should
> get the PEBS register state rather than the PMU interrupt
> register state, but I was unable to construct a test case
> on a Haswell system where I got different values with
> precise_ip=0, precise_ip=2, or by using PERF_SAMPLE_REGS_USER
> instead.  Am I missing something about how to use this new 
> interface?
> 
> Signed-off-by: Vince Weaver 
> 
> diff --git a/man2/perf_event_open.2 b/man2/perf_event_open.2
> index 39c8d8c..ca03928 100644
> --- a/man2/perf_event_open.2
> +++ b/man2/perf_event_open.2
> @@ -256,7 +256,7 @@ struct perf_event_attr {
>  __u32 sample_stack_user;/* size of stack to dump on
> samples */
>  __u32 __reserved_2; /* Align to u64 */
> -
> +__u64 sample_regs_intr; /* regs to dump on samples */
>  };
>  .fi
>  .in
> @@ -350,6 +350,11 @@ and
>  .I sample_stack_user
>  in Linux 3.7.
>  .\" commit 1659d129ed014b715b0b2120e6fd929bdd33ed03
> +.B PERF_ATTR_SIZE_VER4
> +is 104 corresponding to the addition of
> +.I sample_regs_intr
> +in Linux 3.19.
> +.\" commit 60e2364e60e86e81bc6377f49779779e6120977f
>  .TP
>  .I "config"
>  This specifies which event you want, in conjunction with
> @@ -752,6 +757,23 @@ event must be measured or no values will be recorded.
>  Also note that some perf_event measurements, such as sampled
>  cycle counting, may cause extraneous aborts (by causing an
>  interrupt during a transaction).
> +.TP
> +.BR PERF_SAMPLE_REGS_INTR " (since Linux 3.19)"
> +.\" commit 60e2364e60e86e81bc6377f49779779e6120977f
> +Records a subset of the current CPU register state
> +as specified by
> +.IR sample_regs_intr .
> +Unlike
> +.B PERF_SAMPLE_REGS_USER
> +the register values will return kernel register
> +state if the overflow happened while kernel
> +code is running.
> +If the CPU supports hardware sampling of
> +register state (as does PEBS on x86) and
> +.I precise_ip
> +is set higher than zero then the register
> +values returned are those captured by
> +hardware.
>  .RE
>  .TP
>  .IR "read_format"
> @@ -1855,6 +1877,9 @@ struct {
>  u64   weight; /* if PERF_SAMPLE_WEIGHT */
>  u64   data_src;   /* if PERF_SAMPLE_DATA_SRC */
>  u64   transaction;/* if PERF_SAMPLE_TRANSACTION */
> +u64   abi;/* if PERF_SAMPLE_REGS_INTR */
> +u64   regs[weight(mask)];
> +  /* if PERF_SAMPLE_REGS_INTR */
>  };
>  .fi
>  .RS 4
> @@ -2242,6 +2267,27 @@ the high 32 bits of the field by shifting right by
>  .B PERF_TXN_ABORT_SHIFT
>  and masking with
>  .BR PERF_TXN_ABORT_MASK .
> +.TP
> +.IR abi ", " regs[weight(mask)]
> +If
> +.B PERF_SAMPLE_REGS_INTR
> +is enabled, then the user CPU registers are recorded.
> +
> +The
> +.I abi
> +field is one of
> +.BR PERF_SAMPLE_REGS_ABI_NONE ", " PERF_SAMPLE_REGS_ABI_32 " or "
> +.BR PERF_SAMPLE_REGS_ABI_64 .
> +
> +The
> +.I regs
> +field is an array of the CPU registers that were specified by
> +the
> +.I sample_regs_intr
> +attr field.
> +The number of values is the number of bits set in the
> +.I sample_regs_intr
> +bit mask.
>  .RE
>  .TP
>  .B PERF_RECORD_MMAP2
> 
> 


-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
--
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] perf_event_open.2: Exclude_host/exclude_guest clarification

2015-02-16 Thread Michael Kerrisk (man-pages)
Hi Joerg,

Would you be willing to review/comment on Vince's patch, please.

Cheers,

Michael

On 02/11/2015 08:06 PM, Vince Weaver wrote:
> 
> This patch relates to the exclude_host and exclude_guest bits added 
> by the  following commit:
> 
>exclude_host, exclude_guest; Linux 3.2
> commit a240f76165e6255384d4bdb8139895fac7988799
> Author: Joerg Roedel 
> Date:   Wed Oct 5 14:01:16 2011 +0200
> 
> perf, core: Introduce attrs to count in either host or guest mode
> 
> Signed-off-by: Joerg Roedel 
> Signed-off-by: Gleb Natapov 
> Signed-off-by: Peter Zijlstra 
> Link: 
> http://lkml.kernel.org/r/1317816084-18026-2-git-send-email-g...@redhat.com
> Signed-off-by: Ingo Molnar 
> 
> The updated manpage text clarifies that the "exclude_host" and
> "exclude_guest" perf_event_open() attr bits only apply in the 
> context of a KVM environment and are currently x86 only.
> 
> This is a resend of the patch; the previous time I sent it
> (http://thread.gmane.org/gmane.linux.man/7500) it did not
> receive any comments.
> 
> Signed-off-by: Vince Weaver 
> 
> diff --git a/man2/perf_event_open.2 b/man2/perf_event_open.2
> index 39c8d8c..1ea56c9 100644
> --- a/man2/perf_event_open.2
> +++ b/man2/perf_event_open.2
> @@ -1006,11 +1006,25 @@ struct sample_id {
>  .TP
>  .IR "exclude_host" " (since Linux 3.2)"
>  .\" commit a240f76165e6255384d4bdb8139895fac7988799
> -Do not measure time spent in VM host.
> +When conducting measurements that include processes running
> +VM instances (i.e. have executed a
> +.I KVM_RUN
> +.BR ioctl (2)
> +) only measure events happening inside a guest instance.
> +This is only meaningful outside the guests; this setting does
> +not change counts gathered inside of a guest.
> +Currently this functionality is x86 only.
>  .TP
>  .IR "exclude_guest" " (since Linux 3.2)"
>  .\" commit a240f76165e6255384d4bdb8139895fac7988799
> -Do not measure time spent in VM guest.
> +When conducting measurements that include processes running
> +VM instances (i.e. have executed a
> +.I KVM_RUN
> +.BR ioctl (2)
> +) do not measure events happening inside guest instances.
> +This is only meaningful outside the guests; this setting does
> +not change counts gathered inside of a guest.
> +Currently this functionality is x86 only.
>  .TP
>  .IR "exclude_callchain_kernel" " (since Linux 3.7)"
>  .\" commit d077526485d5c9b12fe85d0b2b3b7041e6bc5f91
> 


-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
--
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] perf_event_open.2: Exclude_hv clarification

2015-02-16 Thread Michael Kerrisk (man-pages)
Hi Paul Mackerass,

Would you be willing to review/comment on Vince's patch, please.

Cheers,

Michael

On 02/11/2015 08:04 PM, Vince Weaver wrote:
> 
> This manpage patch relates to the exclude_hv bit added to the kernel
> in the following commit:
> 
> exclude_hv; Linux 2.6.31
> commit 0475f9ea8e2cc030298908949e0d5da9f2fc2cfe
> Author: Paul Mackerras 
> 
> perf_counters: allow users to count user, kernel and/or 
> hypervisor events
> 
> Signed-off-by: Paul Mackerras 
> 
> The updated manpage text points out that the exclude_hv 
> "exclude hypervisor" bit only applies on hardware that 
> supports this  feature (such as PowerPC)
> and is silently ignored on other platforms such as x86.
> 
> This is a resend of the patch; the previous time I sent it
> (http://thread.gmane.org/gmane.linux.man/7500) it did not
> receive any comments.
> 
> 
> Signed-off-by: Vince Weaver 
> 
> diff --git a/man2/perf_event_open.2 b/man2/perf_event_open.2
> index 39c8d8c..665aa31 100644
> --- a/man2/perf_event_open.2
> +++ b/man2/perf_event_open.2
> @@ -856,10 +856,9 @@ If this bit is set, the count excludes events that 
> happen in kernel-space.
>  .IR "exclude_hv"
>  If this bit is set, the count excludes events that happen in the
>  hypervisor.
> -This is mainly for PMUs that have built-in support for handling this
> -(such as POWER).
> -Extra support is needed for handling hypervisor measurements on most
> -machines.
> +This is mainly for PMUs that have built-in hardware support
> +for this feature (such as POWER; this setting is silently
> +ignored on x86).
>  .TP
>  .IR "exclude_idle"
>  If set, don't count when the CPU is idle.
> 


-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
--
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] zram: use proper type to update max_used_pages

2015-02-16 Thread Joonsoo Kim
max_used_pages are defined as atomic_long_t so we need to use
unsigned long to keep temporary value for it rather than int
which is smaller than unsigned long in 64 bit system.

Signed-off-by: Joonsoo Kim 
---
 drivers/block/zram/zram_drv.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
index 8e233ed..871bd35 100644
--- a/drivers/block/zram/zram_drv.c
+++ b/drivers/block/zram/zram_drv.c
@@ -528,7 +528,7 @@ out_cleanup:
 static inline void update_used_max(struct zram *zram,
const unsigned long pages)
 {
-   int old_max, cur_max;
+   unsigned long old_max, cur_max;
 
old_max = atomic_long_read(>stats.max_used_pages);
 
-- 
1.9.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] mm/memcontrol: fix NULL pointer dereference when use_hierarchy is 0

2015-02-16 Thread Joonsoo Kim
It can be possible to return NULL in parent_mem_cgroup()
if use_hierarchy is 0. So, we need to check NULL in the loop on
mem_cgroup_low(). Without it, following NULL pointer dereference happens.

[   33.607531] BUG: unable to handle kernel NULL pointer dereference at 
00b0
[   33.608008] IP: [] mem_cgroup_low+0x40/0x90
[   33.608008] PGD 1d893067 PUD 1cf41067 PMD 0
[   33.608008] Oops:  [#12] SMP
[   33.608008] Modules linked in:
[   33.608008] CPU: 1 PID: 3936 Comm: as Tainted: G  D 
3.19.0-next-20150216 #156
[   33.608008] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
Bochs 01/01/2011
[   33.608008] task: 88001d9c8000 ti: 88000cb14000 task.ti: 
88000cb14000
[   33.608008] RIP: 0010:[]  [] 
mem_cgroup_low+0x40/0x90
[   33.608008] RSP: :88000cb17a88  EFLAGS: 00010286
[   33.608008] RAX:  RBX: 88000cb17bc0 RCX: 
[   33.608008] RDX: 88001f491400 RSI:  RDI: 
[   33.608008] RBP: 88000cb17a88 R08: 0160 R09: 
[   33.608008] R10:  R11: 02b8c101 R12: 
[   33.608008] R13:  R14: 88001fff9e08 R15: 88001da95800
[   33.608008] FS:  2b7a12715380() GS:88001fa4() 
knlGS:
[   33.608008] CS:  0010 DS:  ES:  CR0: 80050033
[   33.608008] CR2: 00b0 CR3: 0762f000 CR4: 07e0
[   33.608008] Stack:
[   33.608008]  88000cb17b18 811838ec 88000cb17cd8 

[   33.608008]   0001 000280da 
88001fff8780
[   33.608008]  88000cb17af8 810e1d7e 88001fff8780 
0003000c
[   33.608008] Call Trace:
[   33.608008]  [] shrink_zone+0xac/0x2d0
[   33.608008]  [] ? ktime_get+0x3e/0xa0
[   33.608008]  [] do_try_to_free_pages+0x174/0x440
[   33.608008]  [] ? throttle_direct_reclaim+0x98/0x250
[   33.608008]  [] try_to_free_pages+0xba/0x150
[   33.608008]  [] __alloc_pages_nodemask+0x5a0/0x950
[   33.608008]  [] alloc_pages_vma+0xaf/0x200
[   33.608008]  [] handle_mm_fault+0x1287/0x17e0
[   33.608008]  [] ? kvm_clock_read+0x1e/0x20
[   33.608008]  [] ? kvm_clock_read+0x1e/0x20
[   33.608008]  [] ? sched_clock+0x9/0x10
[   33.608008]  [] __do_page_fault+0x191/0x440
[   33.608008]  [] trace_do_page_fault+0x45/0x100
[   33.608008]  [] do_async_page_fault+0x1e/0xd0
[   33.608008]  [] async_page_fault+0x28/0x30
[   33.608008] Code: 48 8b 15 cc 21 b4 00 48 39 d6 74 53 48 8b 8e b0 00 00 00 
48 39 8e 28 01 00 00 72 43 31 c9 48 39 fe 75 1d eb 35 66 0f 1f 44 00 00 <48> 8b 
86 b0 00 00 00 48 39 86 28 01 00 00 72 30 48 39 f7 74 1a
[   33.608008] RIP  [] mem_cgroup_low+0x40/0x90
[   33.608008]  RSP 
[   33.608008] CR2: 00b0
[   33.608008] BUG: unable to handle kernel [   33.653499] ---[ end trace 
e264a32717ffda51 ]---

Signed-off-by: Joonsoo Kim 
---
 mm/memcontrol.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index d18d3a6..507cfea 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -5431,6 +5431,8 @@ bool mem_cgroup_low(struct mem_cgroup *root, struct 
mem_cgroup *memcg)
 
while (memcg != root) {
memcg = parent_mem_cgroup(memcg);
+   if (!memcg)
+   break;
 
if (memcg == root_mem_cgroup)
break;
-- 
1.9.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 2/3] slub: Support for array operations

2015-02-16 Thread Joonsoo Kim
On Fri, Feb 13, 2015 at 09:49:24AM -0600, Christoph Lameter wrote:
> On Fri, 13 Feb 2015, Joonsoo Kim wrote:
> 
> > > + *p++ = freelist;
> > > + freelist = get_freepointer(s, freelist);
> > > + allocated++;
> > > + }
> >
> > Fetching all objects with holding node lock could result in enomourous
> > lock contention. How about getting free ojbect pointer without holding
> > the node lock? We can temporarilly store all head of freelists in
> > array p and can fetch each object pointer without holding node lock.
> 
> 
> Could do that but lets first see if there is really an issue. The other
> cpu sharing the same partial lists presumaly have cpu local objects to get
> through first before they hit this lock.

Okay.

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: [RFC 13/16] mm/cma: populate ZONE_CMA and use this zone when GFP_HIGHUSERMOVABLE

2015-02-16 Thread Joonsoo Kim
On Sat, Feb 14, 2015 at 02:02:16PM +0900, Gioh Kim wrote:
> 
> 
> 2015-02-12 오후 4:32에 Joonsoo Kim 이(가) 쓴 글:
> > Until now, reserved pages for CMA are managed altogether with normal
> > page in the same zone. This approach has numorous problems and fixing
> > them isn't easy. To fix this situation, ZONE_CMA is introduced in
> > previous patch, but, not yet populated. This patch implement population
> > of ZONE_CMA by stealing reserved pages from normal zones. This stealing
> > break one uncertain assumption on zone, that is, zone isn't overlapped.
> > In the early of this series, some check is inserted to every zone's span
> > iterator to handle zone overlap so there would be no problem with
> > this assumption break.
> > 
> > To utilize this zone, user should use GFP_HIGHUSERMOVABLE, because
> 
> I think it might be typo of GFP_HIGHUSER_MOVABLE.
> 

Yes, I will correct next time.

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: [RFC 07/16] mm/page_isolation: watch out zone range overlap

2015-02-16 Thread Joonsoo Kim
On Fri, Feb 13, 2015 at 03:40:08PM +0900, Gioh Kim wrote:
> 
> > diff --git a/mm/page_isolation.c b/mm/page_isolation.c
> > index c8778f7..883e78d 100644
> > --- a/mm/page_isolation.c
> > +++ b/mm/page_isolation.c
> > @@ -210,8 +210,8 @@ int undo_isolate_page_range(unsigned long start_pfn, 
> > unsigned long end_pfn,
> >* Returns 1 if all pages in the range are isolated.
> >*/
> >   static int
> > -__test_page_isolated_in_pageblock(unsigned long pfn, unsigned long end_pfn,
> > - bool skip_hwpoisoned_pages)
> > +__test_page_isolated_in_pageblock(struct zone *zone, unsigned long pfn,
> > +   unsigned long end_pfn, bool skip_hwpoisoned_pages)
> >   {
> > struct page *page;
> >   
> > @@ -221,6 +221,9 @@ __test_page_isolated_in_pageblock(unsigned long pfn, 
> > unsigned long end_pfn,
> > continue;
> > }
> > page = pfn_to_page(pfn);
> > +   if (page_zone(page) != zone)
> > +   break;
> > +
> > if (PageBuddy(page)) {
> > /*
> >  * If race between isolatation and allocation happens,
> > @@ -281,7 +284,7 @@ int test_pages_isolated(unsigned long start_pfn, 
> > unsigned long end_pfn,
> > /* Check all pages are free or marked as ISOLATED */
> > zone = page_zone(page);
> > spin_lock_irqsave(>lock, flags);
> > -   ret = __test_page_isolated_in_pageblock(start_pfn, end_pfn,
> > +   ret = __test_page_isolated_in_pageblock(zone, start_pfn, end_pfn,
> > skip_hwpoisoned_pages);
> > spin_unlock_irqrestore(>lock, flags);
> > return ret ? 0 : -EBUSY;
> > 
> 
> What about checking zone at test_pages_isolated?
> It might be a little bit early and without locking zone.

Hello,

Will do in next spin.

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/


[PATCH] mm/nommu: fix memory leak

2015-02-16 Thread Joonsoo Kim
Maxime reported following memory leak regression due to commit dbc8358c7237
("mm/nommu: use alloc_pages_exact() rather than its own implementation").

On v3.19, I am facing a memory leak.
Each time I run a command one page is lost. Here an example with
busybox's free command:

/ # free
 total   used   free sharedbuffers cached
Mem:  7928   1972   5956  0  0492
-/+ buffers/cache:   1480   6448
/ # free
 total   used   free sharedbuffers cached
Mem:  7928   1976   5952  0  0492
-/+ buffers/cache:   1484   6444
/ # free
 total   used   free sharedbuffers cached
Mem:  7928   1980   5948  0  0492
-/+ buffers/cache:   1488   6440
/ # free
 total   used   free sharedbuffers cached
Mem:  7928   1984   5944  0  0492
-/+ buffers/cache:   1492   6436
/ # free
 total   used   free sharedbuffers cached
Mem:  7928   1988   5940  0  0492
-/+ buffers/cache:   1496   6432

At some point, the system fails to sastisfy 256KB allocations:

[   38.72] free: page allocation failure: order:6, mode:0xd0
[   38.73] CPU: 0 PID: 67 Comm: free Not tainted
3.19.0-05389-gacf2cf1-dirty #64
[   38.74] Hardware name: STM32 (Device Tree Support)
[   38.74] [<08022e25>] (unwind_backtrace) from [<080221e7>]
(show_stack+0xb/0xc)
[   38.75] [<080221e7>] (show_stack) from [<0804fd3b>]
(warn_alloc_failed+0x97/0xbc)
[   38.76] [<0804fd3b>] (warn_alloc_failed) from [<08051171>]
(__alloc_pages_nodemask+0x295/0x35c)
[   38.77] [<08051171>] (__alloc_pages_nodemask) from [<08051243>]
(__get_free_pages+0xb/0x24)
[   38.78] [<08051243>] (__get_free_pages) from [<0805127f>]
(alloc_pages_exact+0x19/0x24)
[   38.79] [<0805127f>] (alloc_pages_exact) from [<0805bdbf>]
(do_mmap_pgoff+0x423/0x658)
[   38.80] [<0805bdbf>] (do_mmap_pgoff) from [<08056e73>]
(vm_mmap_pgoff+0x3f/0x4e)
[   38.81] [<08056e73>] (vm_mmap_pgoff) from [<08080949>]
(load_flat_file+0x20d/0x4f8)
[   38.82] [<08080949>] (load_flat_file) from [<08080dfb>]
(load_flat_binary+0x3f/0x26c)
[   38.83] [<08080dfb>] (load_flat_binary) from [<08063741>]
(search_binary_handler+0x51/0xe4)
[   38.84] [<08063741>] (search_binary_handler) from [<08063a45>]
(do_execveat_common+0x271/0x35c)
[   38.85] [<08063a45>] (do_execveat_common) from [<08063b49>]
(do_execve+0x19/0x1c)
[   38.86] [<08063b49>] (do_execve) from [<08020a01>]
(ret_fast_syscall+0x1/0x4a)
[   38.87] Mem-info:
[   38.87] Normal per-cpu:
[   38.87] CPU0: hi:0, btch:   1 usd:   0
[   38.88] active_anon:0 inactive_anon:0 isolated_anon:0
[   38.88]  active_file:0 inactive_file:0 isolated_file:0
[   38.88]  unevictable:123 dirty:0 writeback:0 unstable:0
[   38.88]  free:1515 slab_reclaimable:17 slab_unreclaimable:139
[   38.88]  mapped:0 shmem:0 pagetables:0 bounce:0
[   38.88]  free_cma:0
[   38.91] Normal free:6060kB min:352kB low:440kB high:528kB
active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB
unevictable:492kB isolated(anon):0ks
[   38.95] lowmem_reserve[]: 0 0
[   38.95] Normal: 23*4kB (U) 22*8kB (U) 24*16kB (U) 23*32kB (U)
23*64kB (U) 23*128kB (U) 1*256kB (U) 0*512kB 0*1024kB 0*2048kB
0*4096kB = 6060kB
[   38.97] 123 total pagecache pages
[   38.97] 2048 pages of RAM
[   38.98] 1538 free pages
[   38.98] 66 reserved pages
[   38.99] 109 slab pages
[   38.99] -46 pages shared
[   38.99] 0 pages swap cached
[   38.99] nommu: Allocation of length 221184 from process 67 (free) failed
[   39.00] Normal per-cpu:
[   39.01] CPU0: hi:0, btch:   1 usd:   0
[   39.01] active_anon:0 inactive_anon:0 isolated_anon:0
[   39.01]  active_file:0 inactive_file:0 isolated_file:0
[   39.01]  unevictable:123 dirty:0 writeback:0 unstable:0
[   39.01]  free:1515 slab_reclaimable:17 slab_unreclaimable:139
[   39.01]  mapped:0 shmem:0 pagetables:0 bounce:0
[   39.01]  free_cma:0
[   39.05] Normal free:6060kB min:352kB low:440kB high:528kB
active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB
unevictable:492kB isolated(anon):0ks
[   39.09] lowmem_reserve[]: 0 0
[   39.09] Normal: 23*4kB (U) 22*8kB (U) 24*16kB (U) 23*32kB (U)
23*64kB (U) 23*128kB (U) 1*256kB (U) 0*512kB 0*1024kB 0*2048kB
0*4096kB = 6060kB
[   39.10] 123 total pagecache pages
[   39.11] Unable to allocate RAM for process text/data, errno 12
SEGV

This problem happens because we allocate ordered page through
__get_free_pages() in do_mmap_private() in some cases and we
try to free individual pages rather than ordered page in
free_page_series(). In this case, freeing pages 

Re: [PATCH 1/3] Slab infrastructure for array operations

2015-02-16 Thread Joonsoo Kim
On Fri, Feb 13, 2015 at 09:47:59AM -0600, Christoph Lameter wrote:
> On Fri, 13 Feb 2015, Joonsoo Kim wrote:
> >
> > I also think that this implementation is slub-specific. For example,
> > in slab case, it is always better to access local cpu cache first than
> > page allocator since slab doesn't use list to manage free objects and
> > there is no cache line overhead like as slub. I think that,
> > in kmem_cache_alloc_array(), just call to allocator-defined
> > __kmem_cache_alloc_array() is better approach.
> 
> What do you mean by "better"? Please be specific as to where you would see
> a difference. And slab definititely manages free objects although
> differently than slub. SLAB manages per cpu (local) objects, per node
> partial lists etc. Same as SLUB. The cache line overhead is there but no
> that big a difference in terms of choosing objects to get first.
> 
> For a large allocation it is beneficial for both allocators to fist reduce
> the list of partial allocated slab pages on a node.
> 
> Going to the local objects first is enticing since these are cache hot but
> there are only a limited number of these available and there are issues
> with acquiring a large number of objects. For SLAB the objects dispersed
> and not spatially local. For SLUB the number of objects is usually much
> more limited than SLAB (but that is configurable these days via the cpu
> partial pages). SLUB allocates spatially local objects from one page
> before moving to the other. This is an advantage. However, it has to
> traverse a linked list instead of an array (SLAB).

Hello,

Hmm...so far, SLAB focus on temporal locality rather than spatial locality
as you know. Why SLAB need to consider spatial locality first in this
kmem_cache_alloc_array() case?

And, although we use partial list first, we can't reduce
fragmentation as much as SLUB. Local cache may keep some free objects
of the partial slab so just exhausting free objects of partial slab doesn't
means that there is no free object left. For SLUB, exhausting free
objects of partial slab means there is no free object left.

If we allocate objects from local cache as much as possible, we can
keep temporal locality and return objects as fast as possible since
returing objects from local cache just needs memcpy from local array
cache to destination array.

This cannot be implemented by using kmem_cache_alloc_array() you
suggested and this is why I think just calling allocator-defined
__kmem_cache_alloc_array() is better approach.

As David said, there is no implementation for SLAB yet and we have
different opinion about implementation for SLAB. It's better
to delay detailed implementation of kmem_cache_alloc_array()
until implementation for SLAB is agreed. Before it, calling
__kmem_cache_alloc_array() in kmem_cache_alloc_array() is sufficient
to provide functionality.

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/


linux-next: Tree for Feb 17

2015-02-16 Thread Stephen Rothwell
Hi all,

Please do not add any material destined for v3.21 to your linux-next
included trees until after v3.20-rc1 has been released.

Changes since 20150216:

The slave-dma tree lost its build failure.

Non-merge commits (relative to Linus' tree): 2980
 2871 files changed, 124415 insertions(+), 70264 deletions(-)



I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ).  If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one.  You should use "git fetch" and checkout or reset to the new
master.

You can see which trees have been included by looking in the Next/Trees
file in the source.  There are also quilt-import.log and merge.log files
in the Next directory.  Between each merge, the tree was built with
a ppc64_defconfig for powerpc and an allmodconfig for x86_64 and a
multi_v7_defconfig for arm. After the final fixups (if any), it is also
built with powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig and
allyesconfig (this fails its final link) and i386, sparc, sparc64 and arm
defconfig.

Below is a summary of the state of the merge.

I am currently merging 206 trees (counting Linus' and 30 trees of patches
pending for Linus' tree).

Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .

Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next .  If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.

Thanks to Randy Dunlap for doing many randconfig builds.  And to Paul
Gortmaker for triage and bug fixes.

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

$ git checkout master
$ git reset --hard stable
Merging origin/master (1fa185ebcbce Merge tag 'cris-for-3.20' of 
git://git.kernel.org/pub/scm/linux/kernel/git/jesper/cris)
Merging fixes/master (b94d525e58dc Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net)
Merging kbuild-current/rc-fixes (a16c5f99a28c kbuild: Fix removal of the 
debian/ directory)
Merging arc-current/for-curr (2ce7598c9a45 Linux 3.17-rc4)
Merging arm-current/fixes (8e6480667246 ARM: 8299/1: mm: ensure local active 
ASID is marked as allocated on rollover)
Merging m68k-current/for-linus (4436820a98cd m68k/defconfig: Enable Ethernet 
bridging)
Merging metag-fixes/fixes (ffe6902b66aa asm-generic: remove _STK_LIM_MAX)
Merging mips-fixes/mips-fixes (1795cd9b3a91 Linux 3.16-rc5)
Merging powerpc-merge/merge (31345e1a071e powerpc/pci: Remove unused 
force_32bit_msi quirk)
Merging powerpc-merge-mpe/fixes (c59c961ca511 Merge branch 'drm-fixes' of 
git://people.freedesktop.org/~airlied/linux)
Merging sparc/master (66d0f7ec9f10 sparc32: destroy_context() and switch_mm() 
needs to disable interrupts.)
Merging net/master (7afb8886a05b rtnetlink: call ->dellink on failure when 
->newlink exists)
Merging ipsec/master (ac37e2515c1a xfrm: release dst_orig in case of error in 
xfrm_lookup())
Merging sound-current/for-linus (93ceaa303b29 ALSA: hda/tegra check correct 
return value from ioremap_resource)
Merging pci-current/for-linus (feb28979c137 of/pci: Remove duplicate kfree in 
of_pci_get_host_bridge_resources())
Merging wireless-drivers/master (aeb2d2a4c0ae rtlwifi: Remove logging statement 
that is no longer needed)
Merging driver-core.current/driver-core-linus (26bc420b59a3 Linux 3.19-rc6)
Merging tty.current/tty-linus (ec6f34e5b552 Linux 3.19-rc5)
Merging usb.current/usb-linus (e36f014edff7 Linux 3.19-rc7)
Merging usb-gadget-fixes/fixes (0df8fc37f6e4 usb: phy: never defer probe in 
non-OF case)
Merging usb-serial-fixes/usb-linus (a6f0331236fa USB: cp210x: add ID for 
RUGGEDCOM USB Serial Console)
Merging staging.current/staging-linus (e36f014edff7 Linux 3.19-rc7)
Merging char-misc.current/char-misc-linus (e36f014edff7 Linux 3.19-rc7)
Merging input-current/for-linus (4ba24fef3eb3 Merge branch 'next' into 
for-linus)
Merging crypto-current/master (96692a7305c4 crypto: tcrypt - do not allocate iv 
on stack for aead speed tests)
Merging ide/master (f96fe225677b Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net)
Merging devicetree-current/devicetree/merge (6b1271de3723 of/unittest: Overlays 
with sub-devices tests)
Merging rr-fixes/fixes (dc4515ea26d6 scsi: always increment reference count)
Merging vfio-fixes/for-linus (7c2e211f3c95 vfio-pci: Fix the check on pci 
device type in vfio_pci_probe())
Merging kselftest-fixes/fixes (f5db310d77ef selftests/vm: fix link error for 
transhuge-stress test)
Merging drm-intel-fixes/for-linux-next-fixes (bfa76d495765 Linux 3.19)
Merging asm-generic/master (643165c8bbc8 Merge tag 'uaccess_for_upstream' of 
git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost into asm-

Re: [PATCH V4] tick/hotplug: Handover time related duties before cpu offline

2015-02-16 Thread Michael Ellerman
On Tue, 2015-02-17 at 09:38 +0530, Preeti U Murthy wrote:
> On 02/17/2015 07:28 AM, Michael Ellerman wrote:
> > On Sat, 2015-01-31 at 09:44 +0530, Preeti U Murthy wrote:
> >> These duties include do_timer to update jiffies and broadcast wakeups on 
> >> those
> >> platforms which do not have an external device to handle wakeup of cpus 
> >> from deep
> >> idle states. The handover of these duties is not robust against a cpu 
> >> offline
> >> operation today.
> > 
> > Hi Preeti,
> > 
> > This bug is still causing breakage for people on Power8 machines.
> > 
> > Are we just waiting for Thomas to take the patch?
> 
> Hi mpe,
> 
> Thomas has included the patch for fixing this issue in a recent patchset
> that he posted for cleaning up tick/clockevents related code.

> https://lkml.org/lkml/2015/2/16/213. I think it will go into this
> merge-window. There are a couple of issues there, once that is fixed I
> will remind him to mark it for stable.

Ah thanks. I missed it when searching LKML because it was posted by Peter.

cheers


--
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 rcu/next] One more RCU commit for 3.20

2015-02-16 Thread Paul E. McKenney
Hello, Ingo,

One more change that I should have included in my last pull, namely a
change that prevents a splat seen by Sasha Levin.  This commit passes
testing (including of course Sasha's), has been exposed to both -next
and 0day testing, and is quite small.

This change is available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git rcu/next

for you to fetch changes up to c0135d07b013fa8f7ba9ec91b4369c372e6a28cb:

  rcu: Clear need_qs flag to prevent splat (2015-02-11 15:46:43 -0800)


Paul E. McKenney (1):
  rcu: Clear need_qs flag to prevent splat

 kernel/rcu/tree_plugin.h | 1 +
 1 file changed, 1 insertion(+)

--
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] futex: Robustify wake_futex()

2015-02-16 Thread Davidlohr Bueso
Current code assumes that wake_futex() will never fail, thus
we are rather sloppy when incrementing the return value in wake
related calls, accounting for the newly woken task. Of course
this will never occur, thus not a problem. This bug is as real
as the need for the redundant pi checks in wake_futex().

These redundant checks are fine and past discussion indicates
that they will stay. However, it does introduce this mismatch,
thus it is better to robustify the function and avoid any
assumptions that could bite us in the arse the future.

Signed-off-by: Davidlohr Bueso 
---

This got my attention this while looking at Micheal's futex manpage
changes. The downside of this patch is that the return error from
wake_futex() is even more redundant now... however it still seems
like the right thing to do.

 kernel/futex.c | 45 +
 1 file changed, 33 insertions(+), 12 deletions(-)

diff --git a/kernel/futex.c b/kernel/futex.c
index 2a5e383..a01843a 100644
--- a/kernel/futex.c
+++ b/kernel/futex.c
@@ -1091,13 +1091,16 @@ static void __unqueue_futex(struct futex_q *q)
 /*
  * The hash bucket lock must be held when this is called.
  * Afterwards, the futex_q must not be accessed.
+ *
+ * Returns true only when the task was woken, otherwise false.
  */
-static void wake_futex(struct futex_q *q)
+static bool wake_futex(struct futex_q *q)
 {
struct task_struct *p = q->task;
 
-   if (WARN(q->pi_state || q->rt_waiter, "refusing to wake PI futex\n"))
-   return;
+   if (unlikely(WARN(q->pi_state || q->rt_waiter,
+ "refusing to wake PI futex\n")))
+   return false;
 
/*
 * We set q->lock_ptr = NULL _before_ we wake up the task. If
@@ -1120,6 +1123,7 @@ static void wake_futex(struct futex_q *q)
 
wake_up_state(p, TASK_NORMAL);
put_task_struct(p);
+   return true;
 }
 
 static int wake_futex_pi(u32 __user *uaddr, u32 uval, struct futex_q *this)
@@ -1244,7 +1248,10 @@ futex_wake(u32 __user *uaddr, unsigned int flags, int 
nr_wake, u32 bitset)
if (!(this->bitset & bitset))
continue;
 
-   wake_futex(this);
+   if (!wake_futex(this)) {
+   ret = -EINVAL;
+   break;
+   }
if (++ret >= nr_wake)
break;
}
@@ -1320,7 +1327,11 @@ retry_private:
ret = -EINVAL;
goto out_unlock;
}
-   wake_futex(this);
+
+   if (!wake_futex(this)) {
+   ret = -EINVAL;
+   goto out_unlock;
+   }
if (++ret >= nr_wake)
break;
}
@@ -1334,7 +1345,11 @@ retry_private:
ret = -EINVAL;
goto out_unlock;
}
-   wake_futex(this);
+
+   if (!wake_futex(this)) {
+   ret = -EINVAL;
+   goto out_unlock;
+   }
if (++op_ret >= nr_wake2)
break;
}
@@ -1674,13 +1689,19 @@ retry_private:
}
 
/*
-* Wake nr_wake waiters.  For requeue_pi, if we acquired the
-* lock, we already woke the top_waiter.  If not, it will be
-* woken by futex_unlock_pi().
+* For requeue_pi, if we acquired the lock, we already woke
+* the top_waiter. If not, it will be woken by futex_unlock_pi.
+*
+* The regular (non-pi) case is much simpler: Wake the top
+* waiter (next in line) and repeat.
 */
-   if (++task_count <= nr_wake && !requeue_pi) {
-   wake_futex(this);
-   continue;
+   if (!requeue_pi) {
+   if (!wake_futex(this)) {
+   ret = -EINVAL;
+   break;
+   }
+   if (++task_count <= nr_wake)
+   continue;
}
 
/* Ensure we requeue to the expected futex for requeue_pi. */
-- 
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 V4] tick/hotplug: Handover time related duties before cpu offline

2015-02-16 Thread Preeti U Murthy
On 02/17/2015 07:28 AM, Michael Ellerman wrote:
> On Sat, 2015-01-31 at 09:44 +0530, Preeti U Murthy wrote:
>> These duties include do_timer to update jiffies and broadcast wakeups on 
>> those
>> platforms which do not have an external device to handle wakeup of cpus from 
>> deep
>> idle states. The handover of these duties is not robust against a cpu offline
>> operation today.
>>
>> The do_timer duty is handed over in the CPU_DYING phase today to one of the 
>> online
>> cpus. This relies on the fact that *all* cpus participate in stop_machine 
>> phase.
>> But if this design is to change in the future, i.e. if all cpus are not
>> required to participate in stop_machine, the freshly nominated do_timer cpu
>> could be idle at the time of handover. In that case, unless its interrupted,
>> it will not wakeup to update jiffies and timekeeping will hang.
>>
>> With regard to broadcast wakeups, today if the cpu handling broadcast of 
>> wakeups
>> goes offline, the job of broadcasting is handed over to another cpu in the 
>> CPU_DEAD
>> phase. The CPU_DEAD notifiers are run only after the offline cpu sets its 
>> state as
>> CPU_DEAD. Meanwhile, the kthread doing the offline is scheduled out while 
>> waiting for
>> this transition by queuing a timer. This is fatal because if the cpu on which
>> this kthread was running has no other work queued on it, it can re-enter deep
>> idle state, since it sees that a broadcast cpu still exists. However the 
>> broadcast
>> wakeup will never come since the cpu which was handling it is offline, and 
>> the cpu
>> on which the kthread doing the hotplug operation was running never wakes up 
>> to see
>> this because its in deep idle state.
>>
>> Fix these issues by handing over the do_timer and broadcast wakeup duties 
>> just before
>> the offline cpu kills itself, to the cpu performing the hotplug operation. 
>> Since the
>> cpu performing the hotplug operation is up and running, it becomes aware of 
>> the handover
>> of do_timer duty and queues the broadcast timer upon itself so as to 
>> seamlessly
>> continue both these operations.
>>
>> It fixes the bug reported here:
>> http://linuxppc.10917.n7.nabble.com/offlining-cpus-breakage-td88619.html
>>
>> Signed-off-by: Preeti U Murthy 
>> ---
>> Changes from V3: https://lkml.org/lkml/2015/1/20/236
>> 1. Move handover of broadcast duty away from CPU_DYING phase to just before
>> the cpu kills itself.
>> 2. Club the handover of timekeeping duty along with broadcast duty to make
>> timekeeping robust against hotplug.
> 
> Hi Preeti,
> 
> This bug is still causing breakage for people on Power8 machines.
> 
> Are we just waiting for Thomas to take the patch?

Hi mpe,

Thomas has included the patch for fixing this issue in a recent patchset
that he posted for cleaning up tick/clockevents related code.

https://lkml.org/lkml/2015/2/16/213. I think it will go into this
merge-window. There are a couple of issues there, once that is fixed I
will remind him to mark it for stable.

Regards
Preeti U Murthy

> 
> cheers
> 
> 
> ___
> Linuxppc-dev mailing list
> linuxppc-...@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
> 

--
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 32/35] clockevents: Fix cpu down race for hrtimer based broadcasting

2015-02-16 Thread Preeti U Murthy
On 02/16/2015 05:45 PM, Peter Zijlstra wrote:

>> From: Thomas Gleixner 

>> @@ -428,7 +428,7 @@ static int __ref _cpu_down(unsigned int
>>  __cpu_die(cpu);
>>
>>  /* CPU is completely dead: tell everyone.  Too late to complain. */
>>- tick_cleanup_dead_cpu(cpu);
>>+ tick_takeover(cpu);

Why is tick_handover() called after __cpu_die()? And the function 
tick_takeover()
is not introduced until the next patch. tick_broadcast_takeover_bc() is the
function used instead in this patch. 

Regards
Preeti U Murthy

--
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] usb: move definition of PCI_VENDOR_ID_SYNOPSYS to linux/pci_ids.h

2015-02-16 Thread Greg KH
On Mon, Feb 16, 2015 at 07:32:46PM -0700, Joseph Kogut wrote:
> Removed FIXME from usb/dwc3/dwc3-pci.c by moving definition of
> PCI_VENDOR_ID_SYNOPSYS shared with usb/dwc2 to linux/pci_ids.h.
> 
> Signed-off-by: Joseph Kogut 
> ---
>  drivers/usb/dwc2/pci.c  | 1 -
>  drivers/usb/dwc3/dwc3-pci.c | 2 --
>  include/linux/pci_ids.h | 2 ++
>  3 files changed, 2 insertions(+), 3 deletions(-)

Felipe will take this through his tree when it opens back up again in a
few weeks.

thanks,

greg k-h
--
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 v2] x86: Prevent oops with >16 memory controllers

2015-02-16 Thread Daniel J Blueman
When ECC interrupts occur on memory controllers after EDAC_MAX_MCS (16), the
kernel fatally dereferences unallocated structures [1]; this occurs on at
least NumaConnect systems.

Fix by checking if a memory controller info structure was found; candidate for
stable.

v1->2: Use edac_mc_find() as per Boris's suggestion

Signed-off-by: Daniel J Blueman 

-- [1]

BUG: unable to handle kernel NULL pointer dereference at 0320
IP: [] decode_bus_error+0x2f/0x2b0
PGD 2f8b5a3067 PUD 2f8b5a2067 PMD 0
Oops:  [#2] SMP
Modules linked in:
CPU: 224 PID: 11930 Comm: stream_c.exe.gn Tainted: G   D3.19.0 #1
Hardware name: Supermicro H8QGL/H8QGL, BIOS 3.5b01/28/2015
task: 8807dbfb8c00 ti: 8807dd16c000 task.ti: 8807dd16c000
RIP: 0010:[] [] decode_bus_error+0x2f/0x2b0
RSP: :8907dfc03c48 EFLAGS: 00010297
RAX: 0001 RBX: 9c67400010080a13 RCX: 1dc6
RDX: 1dc61dc6 RSI: 8907dfc03df0 RDI: 001c
RBP: 8907dfc03ce8 R08:  R09: 0022
R10: 891fffa30380 R11: 001cfc90 R12: 0008
R13:  R14: 001c R15: 9c6740001000
FS: 7fa97ee18700() GS:8907dfc0() knlGS:
CS: 0010 DS:  ES:  CR0: 80050033
CR2: 0320 CR3: 003f889b8000 CR4: 000407e0
Stack:
  8907dfc03df0 0008 9c67400010080a13
 001c 9c6740001000 8907dfc03c88 810e4f9a
 8907dfc03ce8 81b375b9  0010
Call Trace:
 
 [] ? vprintk_default+0x1a/0x20
 [] ? printk+0x41/0x43
 [] amd_decode_mce+0x58f/0x8e0
 [] notifier_call_chain+0x4d/0x80
 [] atomic_notifier_call_chain+0x15/0x20
 [] mce_log+0x1d/0x130
 [] machine_check_poll+0x194/0x260
 [] mce_timer_fn+0x116/0x140
 [] ? mce_cpu_restart+0x40/0x40
 [] call_timer_fn.isra.29+0x17/0x80
 [] run_timer_softirq+0x18b/0x220
 [] __do_softirq+0xf9/0x200
 [] irq_exit+0x76/0xa0
 [] smp_apic_timer_interrupt+0x41/0x50
 [] apic_timer_interrupt+0x67/0x70
 
 [] ? down_read_trylock+0x15/0x20
 [] __do_page_fault+0xbb/0x4c0
 [] ? __schedule+0x25a/0x850
 [] do_page_fault+0xc/0x10
 [] page_fault+0x1f/0x30
---
 drivers/edac/amd64_edac.c | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/drivers/edac/amd64_edac.c b/drivers/edac/amd64_edac.c
index 17638d7..e8325e5 100644
--- a/drivers/edac/amd64_edac.c
+++ b/drivers/edac/amd64_edac.c
@@ -2174,14 +2174,20 @@ static void __log_bus_error(struct mem_ctl_info *mci, 
struct err_info *err,
 
 static inline void decode_bus_error(int node_id, struct mce *m)
 {
-   struct mem_ctl_info *mci = mcis[node_id];
-   struct amd64_pvt *pvt = mci->pvt_info;
+   struct mem_ctl_info *mci = edac_mc_find(node_id);
+   struct amd64_pvt *pvt;
u8 ecc_type = (m->status >> 45) & 0x3;
u8 xec = XEC(m->status, 0x1f);
u16 ec = EC(m->status);
u64 sys_addr;
struct err_info err;
 
+   /* Unable to decode where no memory controller info is allocated 
(>EDAC_MAX_MCS) */
+   if (!mci)
+   return;
+
+   pvt = mci->pvt_info;
+
/* Bail out early if this was an 'observed' error */
if (PP(ec) == NBSL_PP_OBS)
return;
-- 
1.9.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 3.2 000/152] 3.2.67-rc1 review

2015-02-16 Thread Guenter Roeck

On 02/16/2015 05:46 PM, Ben Hutchings wrote:

This is the start of the stable review cycle for the 3.2.67 release.
There are 152 patches in this series, which will be posted as responses
to this one.  If anyone has any issues with these being applied, please
let me know.

Responses should be made by Thu Feb 19 02:00:00 UTC 2015.
Anything received after that time might be too late.



Build tests:
total: 98 pass: 95 fail: 3
Failed builds:
mips:allmodconfig
xtensa:defconfig
xtensa:allmodconfig

Qemu tests:
total: 20 pass: 20 fail: 0

Results are as expected.
Detailed build results are available at 
http://server.roeck-us.net:8010/builders.

Guenter


--
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] mm, hugetlb: set PageLRU for in-use/active hugepages

2015-02-16 Thread Naoya Horiguchi
Currently we are not safe from concurrent calls of isolate_huge_page(),
which can make the victim hugepage in invalid state and results in BUG_ON().

The root problem of this is that we don't have any information on struct page
(so easily accessible) about the hugepage's activeness. Note that hugepages'
activeness means just being linked to hstate->hugepage_activelist, which is
not the same as normal pages' activeness represented by PageActive flag.

Normal pages are isolated by isolate_lru_page() which prechecks PageLRU before
isolation, so let's do similarly for hugetlb. PageLRU is unused on hugetlb,
so this change is mostly straightforward. One non-straightforward point is that
__put_compound_page() calls __page_cache_release() to do some LRU works,
but this is obviously for thps and assumes that hugetlb has always !PageLRU.
This assumption is no more true, so this patch simply adds if (!PageHuge) to
avoid calling __page_cache_release() for hugetlb.

Set/ClearPageLRU should be called within hugetlb_lock, but hugetlb_cow() and
hugetlb_no_page() don't do this. This is justified because in these function
SetPageLRU is called right after the hugepage is allocated and no other thread
tries to isolate it.

Fixes: commit 31caf665e666 ("mm: migrate: make core migration code aware of 
hugepage")
Signed-off-by: Naoya Horiguchi 
Cc: [3.12+]
---
 mm/hugetlb.c | 17 ++---
 mm/swap.c|  4 +++-
 2 files changed, 17 insertions(+), 4 deletions(-)

diff --git v3.19_with_hugemigration_fixes.orig/mm/hugetlb.c 
v3.19_with_hugemigration_fixes/mm/hugetlb.c
index a2bfd02e289f..e28489270d9a 100644
--- v3.19_with_hugemigration_fixes.orig/mm/hugetlb.c
+++ v3.19_with_hugemigration_fixes/mm/hugetlb.c
@@ -830,7 +830,7 @@ static void update_and_free_page(struct hstate *h, struct 
page *page)
page[i].flags &= ~(1 << PG_locked | 1 << PG_error |
1 << PG_referenced | 1 << PG_dirty |
1 << PG_active | 1 << PG_private |
-   1 << PG_writeback);
+   1 << PG_writeback | 1 << PG_lru);
}
VM_BUG_ON_PAGE(hugetlb_cgroup_from_page(page), page);
set_compound_page_dtor(page, NULL);
@@ -875,6 +875,7 @@ void free_huge_page(struct page *page)
ClearPagePrivate(page);
 
spin_lock(_lock);
+   ClearPageLRU(page);
hugetlb_cgroup_uncharge_page(hstate_index(h),
 pages_per_huge_page(h), page);
if (restore_reserve)
@@ -2889,6 +2890,7 @@ static int hugetlb_cow(struct mm_struct *mm, struct 
vm_area_struct *vma,
copy_user_huge_page(new_page, old_page, address, vma,
pages_per_huge_page(h));
__SetPageUptodate(new_page);
+   SetPageLRU(new_page);
 
mmun_start = address & huge_page_mask(h);
mmun_end = mmun_start + huge_page_size(h);
@@ -3001,6 +3003,7 @@ static int hugetlb_no_page(struct mm_struct *mm, struct 
vm_area_struct *vma,
}
clear_huge_page(page, address, pages_per_huge_page(h));
__SetPageUptodate(page);
+   SetPageLRU(page);
 
if (vma->vm_flags & VM_MAYSHARE) {
int err;
@@ -3794,6 +3797,7 @@ int dequeue_hwpoisoned_huge_page(struct page *hpage)
 * so let it point to itself with list_del_init().
 */
list_del_init(>lru);
+   ClearPageLRU(hpage);
set_page_refcounted(hpage);
h->free_huge_pages--;
h->free_huge_pages_node[nid]--;
@@ -3806,11 +3810,17 @@ int dequeue_hwpoisoned_huge_page(struct page *hpage)
 
 bool isolate_huge_page(struct page *page, struct list_head *list)
 {
+   bool ret = true;
+
VM_BUG_ON_PAGE(!PageHead(page), page);
-   if (!get_page_unless_zero(page))
-   return false;
spin_lock(_lock);
+   if (!PageLRU(page) || !get_page_unless_zero(page)) {
+   ret = false;
+   goto unlock;
+   }
+   ClearPageLRU(page);
list_move_tail(>lru, list);
+unlock:
spin_unlock(_lock);
return true;
 }
@@ -3819,6 +3829,7 @@ void putback_active_hugepage(struct page *page)
 {
VM_BUG_ON_PAGE(!PageHead(page), page);
spin_lock(_lock);
+   SetPageLRU(page);
list_move_tail(>lru, &(page_hstate(page))->hugepage_activelist);
spin_unlock(_lock);
put_page(page);
diff --git v3.19_with_hugemigration_fixes.orig/mm/swap.c 
v3.19_with_hugemigration_fixes/mm/swap.c
index 8a12b33936b4..ea8fe72999a8 100644
--- v3.19_with_hugemigration_fixes.orig/mm/swap.c
+++ v3.19_with_hugemigration_fixes/mm/swap.c
@@ -31,6 +31,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "internal.h"
 
@@ -75,7 +76,8 @@ static void __put_compound_page(struct page *page)
 {
compound_page_dtor *dtor;
 
-   __page_cache_release(page);
+   

Re: [PATCH v2 0/7] New Lenovos 2015 touchpads: party time!

2015-02-16 Thread Benjamin Tissoires
On Fri, Feb 6, 2015 at 3:04 PM, Benjamin Tissoires
 wrote:
> Hi,
>
> This is the second episode of the Lenovo 2015 party :)
>
> Thanks to Andrew, we now have an idea within the driver of what are the extra
> buttons aimed for, and the patch series looks cleaner.
> Many thanks for your help.
>
> I marked only patches 1/7, 2/7 and 3/7 as stable because they are really
> stable fixes. Without the rest of the series, user-space can cope with the
> kernel result, and so there is IMO no need to backport too many patches in
> stable. I bet distributions will cherry-pick the rest of the series however.
>

Guys,

any chances we consider this for 3.20 (or whatever it will be numbered)?
I'd really like to see this accepted upstream in one way or one other
so we will prevent the mess we had to deal with last year.

Cheers,
Benjamin

> Benjamin Tissoires (7):
>   Input: synaptics - fix middle button on Lenovo 2015 products
>   Input: synaptics - handle spurious release of trackstick buttons
>   Input: synaptics - do not retrieve the board id on old firmwares
>   Input: synaptics - retrieve the extended capabilities in query $10
>   Input: synaptics - remove TOPBUTTONPAD property for Lenovos 2015
>   Input: synaptics - re-route tracksticks buttons on the Lenovo 2015
> series
>   Input: synaptics - Remove X1 Carbon 3rd gen from the topbuttonpad list
>
>  drivers/input/mouse/synaptics.c | 129 
> +---
>  drivers/input/mouse/synaptics.h |  28 +
>  2 files changed, 122 insertions(+), 35 deletions(-)
>
> --
> 2.1.0
>
> --
> 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/
--
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 33/35] tick: Make hrtimer broadcasting opt-in

2015-02-16 Thread Preeti U Murthy
On 02/16/2015 05:45 PM, Peter Zijlstra wrote:

Reviewed-by: Preeti U Murthy 

--
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.2 148/152] vfs: Fix vfsmount_lock imbalance in path_init()

2015-02-16 Thread Ben Hutchings
3.2.67-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Ben Hutchings 

When backporting commit 4023bfc9f351 ("be careful with nd->inode in
path_init() and follow_dotdot_rcu()"), I failed to account for the
vfsmount_lock that is used in 3.2 but not upstream.  path_init() takes
the lock if performing RCU lookup, but must drop it if (and only if)
it subsequently fails.

Reported-by: n...@vault24.org
References: https://bugzilla.kernel.org/show_bug.cgi?id=92531
Signed-off-by: Ben Hutchings 
Tested-by: n...@vault24.org
---
--- a/fs/namei.c
+++ b/fs/namei.c
@@ -1567,6 +1567,7 @@ static int path_init(int dfd, const char
if (!(nd->flags & LOOKUP_ROOT))
nd->root.mnt = NULL;
rcu_read_unlock();
+   br_read_unlock(vfsmount_lock);
return -ECHILD;
 
 fput_fail:

--
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.2 142/152] KEYS: close race between key lookup and freeing

2015-02-16 Thread Ben Hutchings
3.2.67-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Sasha Levin 

commit a3a8784454692dd72e5d5d34dcdab17b4420e74c upstream.

When a key is being garbage collected, it's key->user would get put before
the ->destroy() callback is called, where the key is removed from it's
respective tracking structures.

This leaves a key hanging in a semi-invalid state which leaves a window open
for a different task to try an access key->user. An example is
find_keyring_by_name() which would dereference key->user for a key that is
in the process of being garbage collected (where key->user was freed but
->destroy() wasn't called yet - so it's still present in the linked list).

This would cause either a panic, or corrupt memory.

Fixes CVE-2014-9529.

Signed-off-by: Sasha Levin 
Signed-off-by: David Howells 
[bwh: Backported to 3.2: adjust indentation]
Signed-off-by: Ben Hutchings 
---
 security/keys/gc.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

--- a/security/keys/gc.c
+++ b/security/keys/gc.c
@@ -186,12 +186,12 @@ static noinline void key_gc_unused_key(s
if (test_bit(KEY_FLAG_INSTANTIATED, >flags))
atomic_dec(>user->nikeys);
 
-   key_user_put(key->user);
-
/* now throw away the key memory */
if (key->type->destroy)
key->type->destroy(key);
 
+   key_user_put(key->user);
+
kfree(key->description);
 
 #ifdef KEY_DEBUGGING

--
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.2 001/152] eCryptfs: Force RO mount when encrypted view is enabled

2015-02-16 Thread Ben Hutchings
3.2.67-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Tyler Hicks 

commit 332b122d39c9cbff8b799007a825d94b2e7c12f2 upstream.

The ecryptfs_encrypted_view mount option greatly changes the
functionality of an eCryptfs mount. Instead of encrypting and decrypting
lower files, it provides a unified view of the encrypted files in the
lower filesystem. The presence of the ecryptfs_encrypted_view mount
option is intended to force a read-only mount and modifying files is not
supported when the feature is in use. See the following commit for more
information:

  e77a56d [PATCH] eCryptfs: Encrypted passthrough

This patch forces the mount to be read-only when the
ecryptfs_encrypted_view mount option is specified by setting the
MS_RDONLY flag on the superblock. Additionally, this patch removes some
broken logic in ecryptfs_open() that attempted to prevent modifications
of files when the encrypted view feature was in use. The check in
ecryptfs_open() was not sufficient to prevent file modifications using
system calls that do not operate on a file descriptor.

Signed-off-by: Tyler Hicks 
Reported-by: Priya Bansal 
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings 
---
 fs/ecryptfs/file.c | 12 
 fs/ecryptfs/main.c | 16 +---
 2 files changed, 13 insertions(+), 15 deletions(-)

--- a/fs/ecryptfs/file.c
+++ b/fs/ecryptfs/file.c
@@ -196,24 +196,12 @@ static int ecryptfs_open(struct inode *i
 {
int rc = 0;
struct ecryptfs_crypt_stat *crypt_stat = NULL;
-   struct ecryptfs_mount_crypt_stat *mount_crypt_stat;
struct dentry *ecryptfs_dentry = file->f_path.dentry;
/* Private value of ecryptfs_dentry allocated in
 * ecryptfs_lookup() */
struct dentry *lower_dentry;
struct ecryptfs_file_info *file_info;
 
-   mount_crypt_stat = _superblock_to_private(
-   ecryptfs_dentry->d_sb)->mount_crypt_stat;
-   if ((mount_crypt_stat->flags & ECRYPTFS_ENCRYPTED_VIEW_ENABLED)
-   && ((file->f_flags & O_WRONLY) || (file->f_flags & O_RDWR)
-   || (file->f_flags & O_CREAT) || (file->f_flags & O_TRUNC)
-   || (file->f_flags & O_APPEND))) {
-   printk(KERN_WARNING "Mount has encrypted view enabled; "
-  "files may only be read\n");
-   rc = -EPERM;
-   goto out;
-   }
/* Released in ecryptfs_release or end of function if failure */
file_info = kmem_cache_zalloc(ecryptfs_file_info_cache, GFP_KERNEL);
ecryptfs_set_file_private(file, file_info);
--- a/fs/ecryptfs/main.c
+++ b/fs/ecryptfs/main.c
@@ -494,6 +494,7 @@ static struct dentry *ecryptfs_mount(str
 {
struct super_block *s;
struct ecryptfs_sb_info *sbi;
+   struct ecryptfs_mount_crypt_stat *mount_crypt_stat;
struct ecryptfs_dentry_info *root_info;
const char *err = "Getting sb failed";
struct inode *inode;
@@ -512,6 +513,7 @@ static struct dentry *ecryptfs_mount(str
err = "Error parsing options";
goto out;
}
+   mount_crypt_stat = >mount_crypt_stat;
 
s = sget(fs_type, NULL, set_anon_super, NULL);
if (IS_ERR(s)) {
@@ -557,11 +559,19 @@ static struct dentry *ecryptfs_mount(str
 
/**
 * Set the POSIX ACL flag based on whether they're enabled in the lower
-* mount. Force a read-only eCryptfs mount if the lower mount is ro.
-* Allow a ro eCryptfs mount even when the lower mount is rw.
+* mount.
 */
s->s_flags = flags & ~MS_POSIXACL;
-   s->s_flags |= path.dentry->d_sb->s_flags & (MS_RDONLY | MS_POSIXACL);
+   s->s_flags |= path.dentry->d_sb->s_flags & MS_POSIXACL;
+
+   /**
+* Force a read-only eCryptfs mount when:
+*   1) The lower mount is ro
+*   2) The ecryptfs_encrypted_view mount option is specified
+*/
+   if (path.dentry->d_sb->s_flags & MS_RDONLY ||
+   mount_crypt_stat->flags & ECRYPTFS_ENCRYPTED_VIEW_ENABLED)
+   s->s_flags |= MS_RDONLY;
 
s->s_maxbytes = path.dentry->d_sb->s_maxbytes;
s->s_blocksize = path.dentry->d_sb->s_blocksize;

--
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.2 146/152] enic: fix rx skb checksum

2015-02-16 Thread Ben Hutchings
3.2.67-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Govindarajulu Varadarajan <_gov...@gmx.com>

[ Upstream commit 17e96834fd35997ca7cdfbf15413bcd5a36ad448 ]

Hardware always provides compliment of IP pseudo checksum. Stack expects
whole packet checksum without pseudo checksum if CHECKSUM_COMPLETE is set.

This causes checksum error in nf & ovs.

kernel: qg-19546f09-f2: hw csum failure
kernel: CPU: 9 PID: 0 Comm: swapper/9 Tainted: GF  O--   
3.10.0-123.8.1.el7.x86_64 #1
kernel: Hardware name: Cisco Systems Inc UCSB-B200-M3/UCSB-B200-M3, BIOS 
B200M3.2.2.3.0.080820141339 08/08/2014
kernel: 881218f4 df68243feb35e3a8 881237a43ab8 815e237b
kernel: 881237a43ad0 814cd4ca 8829ec71eb00 881237a43af0
kernel: 814c6232 0286 8829ec71eb00 881237a43b00
kernel: Call Trace:
kernel:   [] dump_stack+0x19/0x1b
kernel: [] netdev_rx_csum_fault+0x3a/0x40
kernel: [] __skb_checksum_complete_head+0x62/0x70
kernel: [] __skb_checksum_complete+0x11/0x20
kernel: [] nf_ip_checksum+0xcc/0x100
kernel: [] icmp_error+0x1f7/0x35c [nf_conntrack_ipv4]
kernel: [] ? netif_rx+0xb9/0x1d0
kernel: [] ? internal_dev_recv+0xdb/0x130 [openvswitch]
kernel: [] nf_conntrack_in+0xf0/0xa80 [nf_conntrack]
kernel: [] ? inet_del_offload+0x40/0x40
kernel: [] ipv4_conntrack_in+0x22/0x30 [nf_conntrack_ipv4]
kernel: [] nf_iterate+0xaa/0xc0
kernel: [] ? inet_del_offload+0x40/0x40
kernel: [] nf_hook_slow+0x84/0x140
kernel: [] ? inet_del_offload+0x40/0x40
kernel: [] ip_rcv+0x344/0x380

Hardware verifies IP & tcp/udp header checksum but does not provide payload
checksum, use CHECKSUM_UNNECESSARY. Set it only if its valid IP tcp/udp packet.

Cc: Jiri Benc 
Cc: Stefan Assmann 
Reported-by: Sunil Choudhary 
Signed-off-by: Govindarajulu Varadarajan <_gov...@gmx.com>
Reviewed-by: Jiri Benc 
Signed-off-by: David S. Miller 
Signed-off-by: Ben Hutchings 
---
 drivers/net/ethernet/cisco/enic/enic_main.c | 12 
 1 file changed, 8 insertions(+), 4 deletions(-)

--- a/drivers/net/ethernet/cisco/enic/enic_main.c
+++ b/drivers/net/ethernet/cisco/enic/enic_main.c
@@ -1272,10 +1272,14 @@ static void enic_rq_indicate_buf(struct
skb_put(skb, bytes_written);
skb->protocol = eth_type_trans(skb, netdev);
 
-   if ((netdev->features & NETIF_F_RXCSUM) && !csum_not_calc) {
-   skb->csum = htons(checksum);
-   skb->ip_summed = CHECKSUM_COMPLETE;
-   }
+   /* Hardware does not provide whole packet checksum. It only
+* provides pseudo checksum. Since hw validates the packet
+* checksum but not provide us the checksum value. use
+* CHECSUM_UNNECESSARY.
+*/
+   if ((netdev->features & NETIF_F_RXCSUM) && tcp_udp_csum_ok &&
+   ipv4_csum_ok)
+   skb->ip_summed = CHECKSUM_UNNECESSARY;
 
skb->dev = netdev;
 

--
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.2 017/152] bus: omap_l3_noc: Correct returning IRQ_HANDLED unconditionally in the irq handler

2015-02-16 Thread Ben Hutchings
3.2.67-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Keerthy 

commit c4cf0935a2d8fe6d186bf4253ea3c4b4a8a8a710 upstream.

Correct returning IRQ_HANDLED unconditionally in the irq handler.
Return IRQ_NONE for some interrupt which we do not expect to be
handled in this handler. This prevents kernel stalling with back
to back spurious interrupts.

Fixes: 2722e56de6 ("OMAP4: l3: Introduce l3-interconnect error handling driver")
Acked-by: Nishanth Menon 
Signed-off-by: Keerthy 
Signed-off-by: Tony Lindgren 
[bwh: Backported to 3.2: adjust filename, indentation]
Signed-off-by: Ben Hutchings 
---
--- a/arch/arm/mach-omap2/omap_l3_noc.c
+++ b/arch/arm/mach-omap2/omap_l3_noc.c
@@ -121,11 +121,15 @@ static irqreturn_t l3_interrupt_handler(
/* Nothing to be handled here as of now */
break;
}
-   /* Error found so break the for loop */
-   break;
+   /* Error found so break the for loop */
+   return IRQ_HANDLED;
}
}
-   return IRQ_HANDLED;
+
+   dev_err(l3->dev, "L3 %s IRQ not handled!!\n",
+   inttype ? "debug" : "application");
+
+   return IRQ_NONE;
 }
 
 static int __devinit omap4_l3_probe(struct platform_device *pdev)

--
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.2 010/152] ipv6: mld: fix add_grhead skb_over_panic for devs with large MTUs

2015-02-16 Thread Ben Hutchings
3.2.67-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Daniel Borkmann 

commit 4c672e4b42bc8046d63a6eb0a2c6a450a501af32 upstream.

It has been reported that generating an MLD listener report on
devices with large MTUs (e.g. 9000) and a high number of IPv6
addresses can trigger a skb_over_panic():

skbuff: skb_over_panic: text:80612a5d len:3776 put:20
head:88046d751000 data:88046d751010 tail:0xed0 end:0xec0
dev:port1
 [ cut here ]
kernel BUG at net/core/skbuff.c:100!
invalid opcode:  [#1] SMP
Modules linked in: ixgbe(O)
CPU: 3 PID: 0 Comm: swapper/3 Tainted: G O 3.14.23+ #4
[...]
Call Trace:
 
 [] ? skb_put+0x3a/0x3b
 [] ? add_grhead+0x45/0x8e
 [] ? add_grec+0x394/0x3d4
 [] ? mld_ifc_timer_expire+0x195/0x20d
 [] ? mld_dad_timer_expire+0x45/0x45
 [] ? call_timer_fn.isra.29+0x12/0x68
 [] ? run_timer_softirq+0x163/0x182
 [] ? __do_softirq+0xe0/0x21d
 [] ? irq_exit+0x4e/0xd3
 [] ? smp_apic_timer_interrupt+0x3b/0x46
 [] ? apic_timer_interrupt+0x6a/0x70

mld_newpack() skb allocations are usually requested with dev->mtu
in size, since commit 72e09ad107e7 ("ipv6: avoid high order allocations")
we have changed the limit in order to be less likely to fail.

However, in MLD/IGMP code, we have some rather ugly AVAILABLE(skb)
macros, which determine if we may end up doing an skb_put() for
adding another record. To avoid possible fragmentation, we check
the skb's tailroom as skb->dev->mtu - skb->len, which is a wrong
assumption as the actual max allocation size can be much smaller.

The IGMP case doesn't have this issue as commit 57e1ab6eaddc
("igmp: refine skb allocations") stores the allocation size in
the cb[].

Set a reserved_tailroom to make it fit into the MTU and use
skb_availroom() helper instead. This also allows to get rid of
igmp_skb_size().

Reported-by: Wei Liu 
Fixes: 72e09ad107e7 ("ipv6: avoid high order allocations")
Signed-off-by: Daniel Borkmann 
Cc: Eric Dumazet 
Cc: Hannes Frederic Sowa 
Cc: David L Stevens 
Acked-by: Eric Dumazet 
Acked-by: Hannes Frederic Sowa 
Signed-off-by: David S. Miller 
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings 
---
 net/ipv4/igmp.c  | 11 +--
 net/ipv6/mcast.c |  9 +
 2 files changed, 10 insertions(+), 10 deletions(-)

--- a/net/ipv4/igmp.c
+++ b/net/ipv4/igmp.c
@@ -294,9 +294,7 @@ igmp_scount(struct ip_mc_list *pmc, int
return scount;
 }
 
-#define igmp_skb_size(skb) (*(unsigned int *)((skb)->cb))
-
-static struct sk_buff *igmpv3_newpack(struct net_device *dev, int size)
+static struct sk_buff *igmpv3_newpack(struct net_device *dev, unsigned int mtu)
 {
struct sk_buff *skb;
struct rtable *rt;
@@ -306,6 +304,7 @@ static struct sk_buff *igmpv3_newpack(st
struct flowi4 fl4;
int hlen = LL_RESERVED_SPACE(dev);
int tlen = dev->needed_tailroom;
+   unsigned int size = mtu;
 
while (1) {
skb = alloc_skb(size + hlen + tlen,
@@ -316,7 +315,6 @@ static struct sk_buff *igmpv3_newpack(st
if (size < 256)
return NULL;
}
-   igmp_skb_size(skb) = size;
 
rt = ip_route_output_ports(net, , NULL, IGMPV3_ALL_MCR, 0,
   0, 0,
@@ -329,6 +327,8 @@ static struct sk_buff *igmpv3_newpack(st
skb_dst_set(skb, >dst);
skb->dev = dev;
 
+   skb->reserved_tailroom = skb_end_offset(skb) -
+min(mtu, skb_end_offset(skb));
skb_reserve(skb, hlen);
 
skb_reset_network_header(skb);
@@ -398,8 +398,7 @@ static struct sk_buff *add_grhead(struct
return skb;
 }
 
-#define AVAILABLE(skb) ((skb) ? ((skb)->dev ? igmp_skb_size(skb) - (skb)->len 
: \
-   skb_tailroom(skb)) : 0)
+#define AVAILABLE(skb) ((skb) ? skb_availroom(skb) : 0)
 
 static struct sk_buff *add_grec(struct sk_buff *skb, struct ip_mc_list *pmc,
int type, int gdeleted, int sdeleted)
--- a/net/ipv6/mcast.c
+++ b/net/ipv6/mcast.c
@@ -1334,7 +1334,7 @@ mld_scount(struct ifmcaddr6 *pmc, int ty
return scount;
 }
 
-static struct sk_buff *mld_newpack(struct inet6_dev *idev, int size)
+static struct sk_buff *mld_newpack(struct inet6_dev *idev, unsigned int mtu)
 {
struct net_device *dev = idev->dev;
struct net *net = dev_net(dev);
@@ -1345,13 +1345,13 @@ static struct sk_buff *mld_newpack(struc
const struct in6_addr *saddr;
int hlen = LL_RESERVED_SPACE(dev);
int tlen = dev->needed_tailroom;
+   unsigned int size = mtu + hlen + tlen;
int err;
u8 ra[8] = { IPPROTO_ICMPV6, 0,
 IPV6_TLV_ROUTERALERT, 2, 0, 0,
 IPV6_TLV_PADN, 0 };
 
/* we assume size > sizeof(ra) here */
-   size += hlen + tlen;
/* limit our allocations to order-0 page */
size = min_t(int, size, SKB_MAX_ORDER(0, 0));
skb = sock_alloc_send_skb(sk, size, 1, );
@@ -1359,6 +1359,8 

[PATCH 3.2 013/152] driver core: Fix unbalanced device reference in drivers_probe

2015-02-16 Thread Ben Hutchings
3.2.67-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Alex Williamson 

commit 0372ffb35d00288802265586a29c117911d02fb8 upstream.

bus_find_device_by_name() acquires a device reference which is never
released.  This results in an object leak, which on older kernels
results in failure to release all resources of PCI devices.  libvirt
uses drivers_probe to re-attach devices to the host after assignment
and is therefore a common trigger for this leak.

Example:

# cd /sys/bus/pci/
# dmesg -C
# echo 1 > devices/\:01\:00.0/sriov_numvfs
# echo 0 > devices/\:01\:00.0/sriov_numvfs
# dmesg | grep 01:10
 pci :01:10.0: [8086:10ca] type 00 class 0x02
 kobject: ':01:10.0' (8801d79cd0a8): kobject_add_internal: parent: 
':00:01.0', set: 'devices'
 kobject: ':01:10.0' (8801d79cd0a8): kobject_uevent_env
 kobject: ':01:10.0' (8801d79cd0a8): fill_kobj_path: path = 
'/devices/pci:00/:00:01.0/:01:10.0'
 kobject: ':01:10.0' (8801d79cd0a8): kobject_uevent_env
 kobject: ':01:10.0' (8801d79cd0a8): fill_kobj_path: path = 
'/devices/pci:00/:00:01.0/:01:10.0'
 kobject: ':01:10.0' (8801d79cd0a8): kobject_uevent_env
 kobject: ':01:10.0' (8801d79cd0a8): fill_kobj_path: path = 
'/devices/pci:00/:00:01.0/:01:10.0'
 kobject: ':01:10.0' (8801d79cd0a8): kobject_cleanup, parent   
(null)
 kobject: ':01:10.0' (8801d79cd0a8): calling ktype release
 kobject: ':01:10.0': free name

[kobject freed as expected]

# dmesg -C
# echo 1 > devices/\:01\:00.0/sriov_numvfs
# echo :01:10.0 > drivers_probe
# echo 0 > devices/\:01\:00.0/sriov_numvfs
# dmesg | grep 01:10
 pci :01:10.0: [8086:10ca] type 00 class 0x02
 kobject: ':01:10.0' (8801d79ce0a8): kobject_add_internal: parent: 
':00:01.0', set: 'devices'
 kobject: ':01:10.0' (8801d79ce0a8): kobject_uevent_env
 kobject: ':01:10.0' (8801d79ce0a8): fill_kobj_path: path = 
'/devices/pci:00/:00:01.0/:01:10.0'
 kobject: ':01:10.0' (8801d79ce0a8): kobject_uevent_env
 kobject: ':01:10.0' (8801d79ce0a8): fill_kobj_path: path = 
'/devices/pci:00/:00:01.0/:01:10.0'
 kobject: ':01:10.0' (8801d79ce0a8): kobject_uevent_env
 kobject: ':01:10.0' (8801d79ce0a8): fill_kobj_path: path = 
'/devices/pci:00/:00:01.0/:01:10.0'

[no free]

Signed-off-by: Alex Williamson 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Ben Hutchings 
---
 drivers/base/bus.c | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

--- a/drivers/base/bus.c
+++ b/drivers/base/bus.c
@@ -240,13 +240,15 @@ static ssize_t store_drivers_probe(struc
   const char *buf, size_t count)
 {
struct device *dev;
+   int err = -EINVAL;
 
dev = bus_find_device_by_name(bus, NULL, buf);
if (!dev)
return -ENODEV;
-   if (bus_rescan_devices_helper(dev, NULL) != 0)
-   return -EINVAL;
-   return count;
+   if (bus_rescan_devices_helper(dev, NULL) == 0)
+   err = count;
+   put_device(dev);
+   return err;
 }
 #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.2 012/152] UBI: Fix invalid vfree()

2015-02-16 Thread Ben Hutchings
3.2.67-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Richard Weinberger 

commit f38aed975c0c3645bbdfc5ebe35726e64caaf588 upstream.

The logic of vfree()'ing vol->upd_buf is tied to vol->updating.
In ubi_start_update() vol->updating is set long before vmalloc()'ing
vol->upd_buf. If we encounter a write failure in ubi_start_update()
before vmalloc() the UBI device release function will try to vfree()
vol->upd_buf because vol->updating is set.
Fix this by allocating vol->upd_buf directly after setting vol->updating.

Fixes:
[   31.559338] UBI warning: vol_cdev_release: update of volume 2 not finished, 
volume is damaged
[   31.559340] [ cut here ]
[   31.559343] WARNING: CPU: 1 PID: 2747 at mm/vmalloc.c:1446 
__vunmap+0xe3/0x110()
[   31.559344] Trying to vfree() nonexistent vm area (c90001f2b000)
[   31.559345] Modules linked in:
[   31.565620]  0bba 88002a0cbdb0 818f0497 
88003b9ba148
[   31.566347]  88002a0cbde0 8156f515 88003b9ba148 
0bba
[   31.567073]    88002a0cbe88 
8156c10a
[   31.567793] Call Trace:
[   31.568034]  [] dump_stack+0x4e/0x7a
[   31.568510]  [] ubi_io_write_vid_hdr+0x155/0x160
[   31.569084]  [] ubi_eba_write_leb+0x23a/0x870
[   31.569628]  [] vol_cdev_write+0x226/0x380
[   31.570155]  [] vfs_write+0xb5/0x1f0
[   31.570627]  [] SyS_pwrite64+0x6a/0xa0
[   31.571123]  [] system_call_fastpath+0x16/0x1b

Signed-off-by: Richard Weinberger 
Signed-off-by: Artem Bityutskiy 
Signed-off-by: Ben Hutchings 
---
 drivers/mtd/ubi/upd.c | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

--- a/drivers/mtd/ubi/upd.c
+++ b/drivers/mtd/ubi/upd.c
@@ -135,6 +135,10 @@ int ubi_start_update(struct ubi_device *
ubi_assert(!vol->updating && !vol->changing_leb);
vol->updating = 1;
 
+   vol->upd_buf = vmalloc(ubi->leb_size);
+   if (!vol->upd_buf)
+   return -ENOMEM;
+
err = set_update_marker(ubi, vol);
if (err)
return err;
@@ -154,14 +158,12 @@ int ubi_start_update(struct ubi_device *
err = clear_update_marker(ubi, vol, 0);
if (err)
return err;
+
+   vfree(vol->upd_buf);
vol->updating = 0;
return 0;
}
 
-   vol->upd_buf = vmalloc(ubi->leb_size);
-   if (!vol->upd_buf)
-   return -ENOMEM;
-
vol->upd_ebs = div_u64(bytes + vol->usable_leb_size - 1,
   vol->usable_leb_size);
vol->upd_bytes = bytes;

--
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.2 003/152] [media] sound: Update au0828 quirks table

2015-02-16 Thread Ben Hutchings
3.2.67-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Mauro Carvalho Chehab 

commit 678fa12fb8e75c6dc1e781a02e3ddbbba7e1a904 upstream.

The au0828 quirks table is currently not in sync with the au0828
media driver.

Syncronize it and put them on the same order as found at au0828
driver, as all the au0828 devices with analog TV need the
same quirks.

Signed-off-by: Mauro Carvalho Chehab 
Signed-off-by: Ben Hutchings 
---
 sound/usb/quirks-table.h | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

--- a/sound/usb/quirks-table.h
+++ b/sound/usb/quirks-table.h
@@ -2563,14 +2563,22 @@ YAMAHA_DEVICE(0x7010, "UB99"),
 }
 
 AU0828_DEVICE(0x2040, 0x7200, "Hauppauge", "HVR-950Q"),
+AU0828_DEVICE(0x2040, 0x7240, "Hauppauge", "HVR-850"),
 AU0828_DEVICE(0x2040, 0x7210, "Hauppauge", "HVR-950Q"),
 AU0828_DEVICE(0x2040, 0x7217, "Hauppauge", "HVR-950Q"),
 AU0828_DEVICE(0x2040, 0x721b, "Hauppauge", "HVR-950Q"),
 AU0828_DEVICE(0x2040, 0x721e, "Hauppauge", "HVR-950Q"),
 AU0828_DEVICE(0x2040, 0x721f, "Hauppauge", "HVR-950Q"),
-AU0828_DEVICE(0x2040, 0x7240, "Hauppauge", "HVR-850"),
 AU0828_DEVICE(0x2040, 0x7280, "Hauppauge", "HVR-950Q"),
 AU0828_DEVICE(0x0fd9, 0x0008, "Hauppauge", "HVR-950Q"),
+AU0828_DEVICE(0x2040, 0x7201, "Hauppauge", "HVR-950Q-MXL"),
+AU0828_DEVICE(0x2040, 0x7211, "Hauppauge", "HVR-950Q-MXL"),
+AU0828_DEVICE(0x2040, 0x7281, "Hauppauge", "HVR-950Q-MXL"),
+AU0828_DEVICE(0x05e1, 0x0480, "Hauppauge", "Woodbury"),
+AU0828_DEVICE(0x2040, 0x8200, "Hauppauge", "Woodbury"),
+AU0828_DEVICE(0x2040, 0x7260, "Hauppauge", "HVR-950Q"),
+AU0828_DEVICE(0x2040, 0x7213, "Hauppauge", "HVR-950Q"),
+AU0828_DEVICE(0x2040, 0x7270, "Hauppauge", "HVR-950Q"),
 
 /* Digidesign Mbox */
 {

--
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.2 008/152] ipv4: Remove all uses of LL_ALLOCATED_SPACE

2015-02-16 Thread Ben Hutchings
3.2.67-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Herbert Xu 

commit 660882432909dbe611f1792eda158188065cb9f1 upstream.

ipv4: Remove all uses of LL_ALLOCATED_SPACE

The macro LL_ALLOCATED_SPACE was ill-conceived.  It applies the
alignment to the sum of needed_headroom and needed_tailroom.  As
the amount that is then reserved for head room is needed_headroom
with alignment, this means that the tail room left may be too small.

This patch replaces all uses of LL_ALLOCATED_SPACE in net/ipv4
with the macro LL_RESERVED_SPACE and direct reference to
needed_tailroom.

This also fixes the problem with needed_headroom changing between
allocating the skb and reserving the head room.

Signed-off-by: Herbert Xu 
Signed-off-by: David S. Miller 
Signed-off-by: Ben Hutchings 
---
 net/ipv4/arp.c  |  6 --
 net/ipv4/igmp.c | 13 +
 net/ipv4/ipconfig.c |  6 --
 net/ipv4/raw.c  |  7 +--
 4 files changed, 22 insertions(+), 10 deletions(-)

--- a/net/ipv4/arp.c
+++ b/net/ipv4/arp.c
@@ -592,16 +592,18 @@ struct sk_buff *arp_create(int type, int
struct sk_buff *skb;
struct arphdr *arp;
unsigned char *arp_ptr;
+   int hlen = LL_RESERVED_SPACE(dev);
+   int tlen = dev->needed_tailroom;
 
/*
 *  Allocate a buffer
 */
 
-   skb = alloc_skb(arp_hdr_len(dev) + LL_ALLOCATED_SPACE(dev), GFP_ATOMIC);
+   skb = alloc_skb(arp_hdr_len(dev) + hlen + tlen, GFP_ATOMIC);
if (skb == NULL)
return NULL;
 
-   skb_reserve(skb, LL_RESERVED_SPACE(dev));
+   skb_reserve(skb, hlen);
skb_reset_network_header(skb);
arp = (struct arphdr *) skb_put(skb, arp_hdr_len(dev));
skb->dev = dev;
--- a/net/ipv4/igmp.c
+++ b/net/ipv4/igmp.c
@@ -304,9 +304,11 @@ static struct sk_buff *igmpv3_newpack(st
struct igmpv3_report *pig;
struct net *net = dev_net(dev);
struct flowi4 fl4;
+   int hlen = LL_RESERVED_SPACE(dev);
+   int tlen = dev->needed_tailroom;
 
while (1) {
-   skb = alloc_skb(size + LL_ALLOCATED_SPACE(dev),
+   skb = alloc_skb(size + hlen + tlen,
GFP_ATOMIC | __GFP_NOWARN);
if (skb)
break;
@@ -327,7 +329,7 @@ static struct sk_buff *igmpv3_newpack(st
skb_dst_set(skb, >dst);
skb->dev = dev;
 
-   skb_reserve(skb, LL_RESERVED_SPACE(dev));
+   skb_reserve(skb, hlen);
 
skb_reset_network_header(skb);
pip = ip_hdr(skb);
@@ -647,6 +649,7 @@ static int igmp_send_report(struct in_de
__be32  group = pmc ? pmc->multiaddr : 0;
struct flowi4 fl4;
__be32  dst;
+   int hlen, tlen;
 
if (type == IGMPV3_HOST_MEMBERSHIP_REPORT)
return igmpv3_send_report(in_dev, pmc);
@@ -661,7 +664,9 @@ static int igmp_send_report(struct in_de
if (IS_ERR(rt))
return -1;
 
-   skb = alloc_skb(IGMP_SIZE+LL_ALLOCATED_SPACE(dev), GFP_ATOMIC);
+   hlen = LL_RESERVED_SPACE(dev);
+   tlen = dev->needed_tailroom;
+   skb = alloc_skb(IGMP_SIZE + hlen + tlen, GFP_ATOMIC);
if (skb == NULL) {
ip_rt_put(rt);
return -1;
@@ -669,7 +674,7 @@ static int igmp_send_report(struct in_de
 
skb_dst_set(skb, >dst);
 
-   skb_reserve(skb, LL_RESERVED_SPACE(dev));
+   skb_reserve(skb, hlen);
 
skb_reset_network_header(skb);
iph = ip_hdr(skb);
--- a/net/ipv4/ipconfig.c
+++ b/net/ipv4/ipconfig.c
@@ -767,13 +767,15 @@ static void __init ic_bootp_send_if(stru
struct sk_buff *skb;
struct bootp_pkt *b;
struct iphdr *h;
+   int hlen = LL_RESERVED_SPACE(dev);
+   int tlen = dev->needed_tailroom;
 
/* Allocate packet */
-   skb = alloc_skb(sizeof(struct bootp_pkt) + LL_ALLOCATED_SPACE(dev) + 15,
+   skb = alloc_skb(sizeof(struct bootp_pkt) + hlen + tlen + 15,
GFP_KERNEL);
if (!skb)
return;
-   skb_reserve(skb, LL_RESERVED_SPACE(dev));
+   skb_reserve(skb, hlen);
b = (struct bootp_pkt *) skb_put(skb, sizeof(struct bootp_pkt));
memset(b, 0, sizeof(struct bootp_pkt));
 
--- a/net/ipv4/raw.c
+++ b/net/ipv4/raw.c
@@ -329,6 +329,7 @@ static int raw_send_hdrinc(struct sock *
unsigned int iphlen;
int err;
struct rtable *rt = *rtp;
+   int hlen, tlen;
 
if (length > rt->dst.dev->mtu) {
ip_local_error(sk, EMSGSIZE, fl4->daddr, inet->inet_dport,
@@ -338,12 +339,14 @@ static int raw_send_hdrinc(struct sock *
if (flags_PROBE)
goto out;
 
+   hlen = LL_RESERVED_SPACE(rt->dst.dev);
+   tlen = rt->dst.dev->needed_tailroom;
skb = sock_alloc_send_skb(sk,
- length + LL_ALLOCATED_SPACE(rt->dst.dev) + 15,
+ length + hlen + tlen + 

[PATCH 3.2 007/152] usb: renesas_usbhs: gadget: fix NULL pointer dereference in ep_disable()

2015-02-16 Thread Ben Hutchings
3.2.67-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Kazuya Mizuguchi 

commit 11432050f070810ba139d0226344eef120c3a559 upstream.

This patch fixes an issue that the NULL pointer dereference happens
when we uses g_audio driver. Since the g_audio driver will call
usb_ep_disable() in afunc_set_alt() before it calls usb_ep_enable(),
the uep->pipe of renesas usbhs driver will be NULL. So, this patch
adds a condition to avoid the oops.

Signed-off-by: Kazuya Mizuguchi 
Signed-off-by: Takeshi Kihara 
Signed-off-by: Yoshihiro Shimoda 
Fixes: 2f98382dc (usb: renesas_usbhs: Add Renesas USBHS Gadget)
Signed-off-by: Felipe Balbi 
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings 
---
 drivers/usb/renesas_usbhs/mod_gadget.c | 3 +++
 1 file changed, 3 insertions(+)

--- a/drivers/usb/renesas_usbhs/mod_gadget.c
+++ b/drivers/usb/renesas_usbhs/mod_gadget.c
@@ -514,6 +514,10 @@ static int usbhsg_ep_enable(struct usb_e
 static int usbhsg_ep_disable(struct usb_ep *ep)
 {
struct usbhsg_uep *uep = usbhsg_ep_to_uep(ep);
+   struct usbhs_pipe *pipe = usbhsg_uep_to_pipe(uep);
+
+   if (!pipe)
+   return -EINVAL;
 
return usbhsg_pipe_disable(uep);
 }

--
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.2 139/152] s390/3215: fix tty output containing tabs

2015-02-16 Thread Ben Hutchings
3.2.67-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Martin Schwidefsky 

commit e512d56c799517f33b301d81e9a5e0ebf30c2d1e upstream.

git commit 37f81fa1f63ad38e16125526bb2769ae0ea8d332
"n_tty: do O_ONLCR translation as a single write"
surfaced a bug in the 3215 device driver. In combination this
broke tab expansion for tty ouput.

The cause is an asymmetry in the behaviour of tty3215_ops->write
vs tty3215_ops->put_char. The put_char function scans for '\t'
but the write function does not.

As the driver has logic for the '\t' expansion remove XTABS
from c_oflag of the initial termios as well.

Reported-by: Stephen Powell 
Signed-off-by: Martin Schwidefsky 
Signed-off-by: Ben Hutchings 
---
 drivers/s390/char/con3215.c | 20 +---
 1 file changed, 17 insertions(+), 3 deletions(-)

--- a/drivers/s390/char/con3215.c
+++ b/drivers/s390/char/con3215.c
@@ -993,12 +993,26 @@ static int tty3215_write(struct tty_stru
 const unsigned char *buf, int count)
 {
struct raw3215_info *raw;
+   int i, written;
 
if (!tty)
return 0;
raw = (struct raw3215_info *) tty->driver_data;
-   raw3215_write(raw, buf, count);
-   return count;
+   written = count;
+   while (count > 0) {
+   for (i = 0; i < count; i++)
+   if (buf[i] == '\t' || buf[i] == '\n')
+   break;
+   raw3215_write(raw, buf, i);
+   count -= i;
+   buf += i;
+   if (count > 0) {
+   raw3215_putchar(raw, *buf);
+   count--;
+   buf++;
+   }
+   }
+   return written;
 }
 
 /*
@@ -1146,7 +1160,7 @@ static int __init tty3215_init(void)
driver->subtype = SYSTEM_TYPE_TTY;
driver->init_termios = tty_std_termios;
driver->init_termios.c_iflag = IGNBRK | IGNPAR;
-   driver->init_termios.c_oflag = ONLCR | XTABS;
+   driver->init_termios.c_oflag = ONLCR;
driver->init_termios.c_lflag = ISIG;
driver->flags = TTY_DRIVER_REAL_RAW;
tty_set_operations(driver, _ops);

--
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.2 150/152] netfilter: conntrack: disable generic tracking for known protocols

2015-02-16 Thread Ben Hutchings
3.2.67-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Florian Westphal 

commit db29a9508a9246e77087c5531e45b2c88ec6988b upstream.

Given following iptables ruleset:

-P FORWARD DROP
-A FORWARD -m sctp --dport 9 -j ACCEPT
-A FORWARD -p tcp --dport 80 -j ACCEPT
-A FORWARD -p tcp -m conntrack -m state ESTABLISHED,RELATED -j ACCEPT

One would assume that this allows SCTP on port 9 and TCP on port 80.
Unfortunately, if the SCTP conntrack module is not loaded, this allows
*all* SCTP communication, to pass though, i.e. -p sctp -j ACCEPT,
which we think is a security issue.

This is because on the first SCTP packet on port 9, we create a dummy
"generic l4" conntrack entry without any port information (since
conntrack doesn't know how to extract this information).

All subsequent packets that are unknown will then be in established
state since they will fallback to proto_generic and will match the
'generic' entry.

Our originally proposed version [1] completely disabled generic protocol
tracking, but Jozsef suggests to not track protocols for which a more
suitable helper is available, hence we now mitigate the issue for in
tree known ct protocol helpers only, so that at least NAT and direction
information will still be preserved for others.

 [1] http://www.spinics.net/lists/netfilter-devel/msg33430.html

Joint work with Daniel Borkmann.

Signed-off-by: Florian Westphal 
Signed-off-by: Daniel Borkmann 
Acked-by: Jozsef Kadlecsik 
Signed-off-by: Pablo Neira Ayuso 
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings 
---
 net/netfilter/nf_conntrack_proto_generic.c | 26 +-
 1 file changed, 25 insertions(+), 1 deletion(-)

diff --git a/net/netfilter/nf_conntrack_proto_generic.c 
b/net/netfilter/nf_conntrack_proto_generic.c
index d25f293..957c1db 100644
--- a/net/netfilter/nf_conntrack_proto_generic.c
+++ b/net/netfilter/nf_conntrack_proto_generic.c
@@ -14,6 +14,30 @@
 
 static unsigned int nf_ct_generic_timeout __read_mostly = 600*HZ;
 
+static bool nf_generic_should_process(u8 proto)
+{
+   switch (proto) {
+#ifdef CONFIG_NF_CT_PROTO_SCTP_MODULE
+   case IPPROTO_SCTP:
+   return false;
+#endif
+#ifdef CONFIG_NF_CT_PROTO_DCCP_MODULE
+   case IPPROTO_DCCP:
+   return false;
+#endif
+#ifdef CONFIG_NF_CT_PROTO_GRE_MODULE
+   case IPPROTO_GRE:
+   return false;
+#endif
+#ifdef CONFIG_NF_CT_PROTO_UDPLITE_MODULE
+   case IPPROTO_UDPLITE:
+   return false;
+#endif
+   default:
+   return true;
+   }
+}
+
 static bool generic_pkt_to_tuple(const struct sk_buff *skb,
 unsigned int dataoff,
 struct nf_conntrack_tuple *tuple)
@@ -56,7 +80,7 @@ static int generic_packet(struct nf_conn *ct,
 static bool new(struct nf_conn *ct, const struct sk_buff *skb,
unsigned int dataoff)
 {
-   return true;
+   return nf_generic_should_process(nf_ct_protonum(ct));
 }
 
 #ifdef CONFIG_SYSCTL

--
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.2 018/152] genhd: check for int overflow in disk_expand_part_tbl()

2015-02-16 Thread Ben Hutchings
3.2.67-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Jens Axboe 

commit 5fabcb4c33fe11c7e3afdf805fde26c1a54d0953 upstream.

We can get here from blkdev_ioctl() -> blkpg_ioctl() -> add_partition()
with a user passed in partno value. If we pass in 0x7fff, the
new target in disk_expand_part_tbl() overflows the 'int' and we
access beyond the end of ptbl->part[] and even write to it when we
do the rcu_assign_pointer() to assign the new partition.

Reported-by: David Ramos 
Signed-off-by: Jens Axboe 
Signed-off-by: Ben Hutchings 
---
 block/genhd.c | 11 +--
 1 file changed, 9 insertions(+), 2 deletions(-)

--- a/block/genhd.c
+++ b/block/genhd.c
@@ -1070,9 +1070,16 @@ int disk_expand_part_tbl(struct gendisk
struct disk_part_tbl *old_ptbl = disk->part_tbl;
struct disk_part_tbl *new_ptbl;
int len = old_ptbl ? old_ptbl->len : 0;
-   int target = partno + 1;
+   int i, target;
size_t size;
-   int i;
+
+   /*
+* check for int overflow, since we can get here from blkpg_ioctl()
+* with a user passed 'partno'.
+*/
+   target = partno + 1;
+   if (target < 0)
+   return -EINVAL;
 
/* disk_max_parts() is zero during initialization, ignore if so */
if (disk_max_parts(disk) && target > disk_max_parts(disk))

--
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.2 014/152] drbd: merge_bvec_fn: properly remap bvm->bi_bdev

2015-02-16 Thread Ben Hutchings
3.2.67-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Lars Ellenberg 

commit 3b9d35d744bb5139f9fed57f38c019bb8c7d351c upstream.

This was not noticed for many years. Affects operation if
md raid is used a backing device for DRBD.

Signed-off-by: Philipp Reisner 
Signed-off-by: Lars Ellenberg 
Signed-off-by: Jens Axboe 
[bwh: Backported to 3.2: s/device/mdev/]
Signed-off-by: Ben Hutchings 
---
 drivers/block/drbd/drbd_req.c | 1 +
 1 file changed, 1 insertion(+)

--- a/drivers/block/drbd/drbd_req.c
+++ b/drivers/block/drbd/drbd_req.c
@@ -1184,6 +1184,7 @@ int drbd_merge_bvec(struct request_queue
struct request_queue * const b =
mdev->ldev->backing_bdev->bd_disk->queue;
if (b->merge_bvec_fn) {
+   bvm->bi_bdev = mdev->ldev->backing_bdev;
backing_limit = b->merge_bvec_fn(b, bvm, bvec);
limit = min(limit, backing_limit);
}

--
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.2 015/152] PCI: Restore detection of read-only BARs

2015-02-16 Thread Ben Hutchings
3.2.67-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Myron Stowe 

commit 36e8164882ca6d3c41cb91e6f09a3ed236841f80 upstream.

Commit 6ac665c63dca ("PCI: rewrite PCI BAR reading code") masked off
low-order bits from 'l', but not from 'sz'.  Both are passed to pci_size(),
which compares 'base == maxbase' to check for read-only BARs.  The masking
of 'l' means that comparison will never be 'true', so the check for
read-only BARs no longer works.

Resolve this by also masking off the low-order bits of 'sz' before passing
it into pci_size() as 'maxbase'.  With this change, pci_size() will once
again catch the problems that have been encountered to date:

  - AGP aperture BAR of AMD-7xx host bridges: if the AGP window is
disabled, this BAR is read-only and read as 0x0008 [1]

  - BARs 0-4 of ALi IDE controllers can be non-zero and read-only [1]

  - Intel Sandy Bridge - Thermal Management Controller [8086:0103];
BAR 0 returning 0xfed98004 [2]

  - Intel Xeon E5 v3/Core i7 Power Control Unit [8086:2fc0];
Bar 0 returning 0x1a [3]

Link: [1] 
https://git.kernel.org/cgit/linux/kernel/git/tglx/history.git/commit/drivers/pci/probe.c?id=1307ef6621991f1c4bc3cec1b5a4ebd6fd3d66b9
 ("PCI: probing read-only BARs" (pre-git))
Link: [2] https://bugzilla.kernel.org/show_bug.cgi?id=43331
Link: [3] https://bugzilla.kernel.org/show_bug.cgi?id=85991
Reported-by: William Unruh 
Reported-by: Martin Lucina 
Signed-off-by: Myron Stowe 
Signed-off-by: Bjorn Helgaas 
CC: Matthew Wilcox 
Signed-off-by: Ben Hutchings 
---
 drivers/pci/probe.c | 3 +++
 1 file changed, 3 insertions(+)

--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -175,14 +175,17 @@ int __pci_read_base(struct pci_dev *dev,
res->flags |= IORESOURCE_SIZEALIGN;
if (res->flags & IORESOURCE_IO) {
l &= PCI_BASE_ADDRESS_IO_MASK;
+   sz &= PCI_BASE_ADDRESS_IO_MASK;
mask = PCI_BASE_ADDRESS_IO_MASK & (u32) IO_SPACE_LIMIT;
} else {
l &= PCI_BASE_ADDRESS_MEM_MASK;
+   sz &= PCI_BASE_ADDRESS_MEM_MASK;
mask = (u32)PCI_BASE_ADDRESS_MEM_MASK;
}
} else {
res->flags |= (l & IORESOURCE_ROM_ENABLE);
l &= PCI_ROM_ADDRESS_MASK;
+   sz &= PCI_ROM_ADDRESS_MASK;
mask = (u32)PCI_ROM_ADDRESS_MASK;
}
 

--
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.2 009/152] ipv6: Remove all uses of LL_ALLOCATED_SPACE

2015-02-16 Thread Ben Hutchings
3.2.67-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Herbert Xu 

commit a7ae1992248e5cf9dc5bd35695ab846d27efe15f upstream.

ipv6: Remove all uses of LL_ALLOCATED_SPACE

The macro LL_ALLOCATED_SPACE was ill-conceived.  It applies the
alignment to the sum of needed_headroom and needed_tailroom.  As
the amount that is then reserved for head room is needed_headroom
with alignment, this means that the tail room left may be too small.

This patch replaces all uses of LL_ALLOCATED_SPACE in net/ipv6
with the macro LL_RESERVED_SPACE and direct reference to
needed_tailroom.

This also fixes the problem with needed_headroom changing between
allocating the skb and reserving the head room.

Signed-off-by: Herbert Xu 
Signed-off-by: David S. Miller 
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings 
---
 net/ipv6/ip6_output.c |  8 ++--
 net/ipv6/mcast.c  | 12 
 net/ipv6/ndisc.c  | 13 +
 net/ipv6/raw.c|  6 --
 4 files changed, 27 insertions(+), 12 deletions(-)

--- a/net/ipv6/ip6_output.c
+++ b/net/ipv6/ip6_output.c
@@ -623,6 +623,7 @@ int ip6_fragment(struct sk_buff *skb, in
struct ipv6hdr *tmp_hdr;
struct frag_hdr *fh;
unsigned int mtu, hlen, left, len;
+   int hroom, troom;
__be32 frag_id = 0;
int ptr, offset = 0, err=0;
u8 *prevhdr, nexthdr = 0;
@@ -789,6 +790,8 @@ slow_path:
 */
 
*prevhdr = NEXTHDR_FRAGMENT;
+   hroom = LL_RESERVED_SPACE(rt->dst.dev);
+   troom = rt->dst.dev->needed_tailroom;
 
/*
 *  Keep copying data until we run out.
@@ -807,7 +810,8 @@ slow_path:
 *  Allocate buffer.
 */
 
-   if ((frag = alloc_skb(len+hlen+sizeof(struct 
frag_hdr)+LL_ALLOCATED_SPACE(rt->dst.dev), GFP_ATOMIC)) == NULL) {
+   if ((frag = alloc_skb(len + hlen + sizeof(struct frag_hdr) +
+ hroom + troom, GFP_ATOMIC)) == NULL) {
NETDEBUG(KERN_INFO "IPv6: frag: no memory for new 
fragment!\n");
IP6_INC_STATS(net, ip6_dst_idev(skb_dst(skb)),
  IPSTATS_MIB_FRAGFAILS);
@@ -820,7 +824,7 @@ slow_path:
 */
 
ip6_copy_metadata(frag, skb);
-   skb_reserve(frag, LL_RESERVED_SPACE(rt->dst.dev));
+   skb_reserve(frag, hroom);
skb_put(frag, len + hlen + sizeof(struct frag_hdr));
skb_reset_network_header(frag);
fh = (struct frag_hdr *)(skb_network_header(frag) + hlen);
--- a/net/ipv6/mcast.c
+++ b/net/ipv6/mcast.c
@@ -1343,13 +1343,15 @@ static struct sk_buff *mld_newpack(struc
struct mld2_report *pmr;
struct in6_addr addr_buf;
const struct in6_addr *saddr;
+   int hlen = LL_RESERVED_SPACE(dev);
+   int tlen = dev->needed_tailroom;
int err;
u8 ra[8] = { IPPROTO_ICMPV6, 0,
 IPV6_TLV_ROUTERALERT, 2, 0, 0,
 IPV6_TLV_PADN, 0 };
 
/* we assume size > sizeof(ra) here */
-   size += LL_ALLOCATED_SPACE(dev);
+   size += hlen + tlen;
/* limit our allocations to order-0 page */
size = min_t(int, size, SKB_MAX_ORDER(0, 0));
skb = sock_alloc_send_skb(sk, size, 1, );
@@ -1357,7 +1359,7 @@ static struct sk_buff *mld_newpack(struc
if (!skb)
return NULL;
 
-   skb_reserve(skb, LL_RESERVED_SPACE(dev));
+   skb_reserve(skb, hlen);
 
if (__ipv6_get_lladdr(idev, _buf, IFA_F_TENTATIVE)) {
/* :
@@ -1725,6 +1727,8 @@ static void igmp6_send(struct in6_addr *
struct mld_msg *hdr;
const struct in6_addr *snd_addr, *saddr;
struct in6_addr addr_buf;
+   int hlen = LL_RESERVED_SPACE(dev);
+   int tlen = dev->needed_tailroom;
int err, len, payload_len, full_len;
u8 ra[8] = { IPPROTO_ICMPV6, 0,
 IPV6_TLV_ROUTERALERT, 2, 0, 0,
@@ -1746,7 +1750,7 @@ static void igmp6_send(struct in6_addr *
  IPSTATS_MIB_OUT, full_len);
rcu_read_unlock();
 
-   skb = sock_alloc_send_skb(sk, LL_ALLOCATED_SPACE(dev) + full_len, 1, 
);
+   skb = sock_alloc_send_skb(sk, hlen + tlen + full_len, 1, );
 
if (skb == NULL) {
rcu_read_lock();
@@ -1756,7 +1760,7 @@ static void igmp6_send(struct in6_addr *
return;
}
 
-   skb_reserve(skb, LL_RESERVED_SPACE(dev));
+   skb_reserve(skb, hlen);
 
if (ipv6_get_lladdr(dev, _buf, IFA_F_TENTATIVE)) {
/* :
--- a/net/ipv6/ndisc.c
+++ b/net/ipv6/ndisc.c
@@ -446,6 +446,8 @@ struct sk_buff *ndisc_build_skb(struct n
struct sock *sk = net->ipv6.ndisc_sk;
struct sk_buff *skb;
struct icmp6hdr *hdr;
+   int hlen = LL_RESERVED_SPACE(dev);
+   int tlen = dev->needed_tailroom;
int len;
   

[PATCH 3.2 133/152] net: sctp: fix slab corruption from use after free on INIT collisions

2015-02-16 Thread Ben Hutchings
3.2.67-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Daniel Borkmann 

commit 600ddd6825543962fb807884169e57b580dba208 upstream.

When hitting an INIT collision case during the 4WHS with AUTH enabled, as
already described in detail in commit 1be9a950c646 ("net: sctp: inherit
auth_capable on INIT collisions"), it can happen that we occasionally
still remotely trigger the following panic on server side which seems to
have been uncovered after the fix from commit 1be9a950c646 ...

[  533.876389] BUG: unable to handle kernel paging request at 
[  533.913657] IP: [] __kmalloc+0x95/0x230
[  533.940559] PGD 5030f2067 PUD 0
[  533.957104] Oops:  [#1] SMP
[  533.974283] Modules linked in: sctp mlx4_en [...]
[  534.939704] Call Trace:
[  534.951833]  [] ? crypto_init_shash_ops+0x60/0xf0
[  534.984213]  [] crypto_init_shash_ops+0x60/0xf0
[  535.015025]  [] __crypto_alloc_tfm+0x6d/0x170
[  535.045661]  [] crypto_alloc_base+0x4c/0xb0
[  535.074593]  [] ? _raw_spin_lock_bh+0x12/0x50
[  535.105239]  [] sctp_inet_listen+0x161/0x1e0 [sctp]
[  535.138606]  [] SyS_listen+0x9d/0xb0
[  535.166848]  [] system_call_fastpath+0x16/0x1b

... or depending on the the application, for example this one:

[ 1370.026490] BUG: unable to handle kernel paging request at 
[ 1370.026506] IP: [] kmem_cache_alloc+0x75/0x1d0
[ 1370.054568] PGD 633c94067 PUD 0
[ 1370.070446] Oops:  [#1] SMP
[ 1370.085010] Modules linked in: sctp kvm_amd kvm [...]
[ 1370.963431] Call Trace:
[ 1370.974632]  [] ? SyS_epoll_ctl+0x53f/0x960
[ 1371.000863]  [] SyS_epoll_ctl+0x53f/0x960
[ 1371.027154]  [] ? anon_inode_getfile+0xd3/0x170
[ 1371.054679]  [] ? __alloc_fd+0xa7/0x130
[ 1371.080183]  [] system_call_fastpath+0x16/0x1b

With slab debugging enabled, we can see that the poison has been overwritten:

[  669.826368] BUG kmalloc-128 (Tainted: GW ): Poison overwritten
[  669.826385] INFO: 0x880228b32e50-0x880228b32e50. First byte 0x6a 
instead of 0x6b
[  669.826414] INFO: Allocated in sctp_auth_create_key+0x23/0x50 [sctp] age=3 
cpu=0 pid=18494
[  669.826424]  __slab_alloc+0x4bf/0x566
[  669.826433]  __kmalloc+0x280/0x310
[  669.826453]  sctp_auth_create_key+0x23/0x50 [sctp]
[  669.826471]  sctp_auth_asoc_create_secret+0xcb/0x1e0 [sctp]
[  669.826488]  sctp_auth_asoc_init_active_key+0x68/0xa0 [sctp]
[  669.826505]  sctp_do_sm+0x29d/0x17c0 [sctp] [...]
[  669.826629] INFO: Freed in kzfree+0x31/0x40 age=1 cpu=0 pid=18494
[  669.826635]  __slab_free+0x39/0x2a8
[  669.826643]  kfree+0x1d6/0x230
[  669.826650]  kzfree+0x31/0x40
[  669.82]  sctp_auth_key_put+0x19/0x20 [sctp]
[  669.826681]  sctp_assoc_update+0x1ee/0x2d0 [sctp]
[  669.826695]  sctp_do_sm+0x674/0x17c0 [sctp]

Since this only triggers in some collision-cases with AUTH, the problem at
heart is that sctp_auth_key_put() on asoc->asoc_shared_key is called twice
when having refcnt 1, once directly in sctp_assoc_update() and yet again
from within sctp_auth_asoc_init_active_key() via sctp_assoc_update() on
the already kzfree'd memory, which is also consistent with the observation
of the poison decrease from 0x6b to 0x6a (note: the overwrite is detected
at a later point in time when poison is checked on new allocation).

Reference counting of auth keys revisited:

Shared keys for AUTH chunks are being stored in endpoints and associations
in endpoint_shared_keys list. On endpoint creation, a null key is being
added; on association creation, all endpoint shared keys are being cached
and thus cloned over to the association. struct sctp_shared_key only holds
a pointer to the actual key bytes, that is, struct sctp_auth_bytes which
keeps track of users internally through refcounting. Naturally, on assoc
or enpoint destruction, sctp_shared_key are being destroyed directly and
the reference on sctp_auth_bytes dropped.

User space can add keys to either list via setsockopt(2) through struct
sctp_authkey and by passing that to sctp_auth_set_key() which replaces or
adds a new auth key. There, sctp_auth_create_key() creates a new sctp_auth_bytes
with refcount 1 and in case of replacement drops the reference on the old
sctp_auth_bytes. A key can be set active from user space through setsockopt()
on the id via sctp_auth_set_active_key(), which iterates through either
endpoint_shared_keys and in case of an assoc, invokes (one of various places)
sctp_auth_asoc_init_active_key().

sctp_auth_asoc_init_active_key() computes the actual secret from local's
and peer's random, hmac and shared key parameters and returns a new key
directly as sctp_auth_bytes, that is asoc->asoc_shared_key, plus drops
the reference if there was a previous one. The secret, which where we
eventually double drop the ref comes from sctp_auth_asoc_set_secret() with
intitial refcount of 1, which also stays unchanged eventually in
sctp_assoc_update(). This key is later being used for crypto layer to
set the key for the hash in crypto_hash_setkey() from 

[PATCH 3.2 006/152] writeback: fix a subtle race condition in I_DIRTY clearing

2015-02-16 Thread Ben Hutchings
3.2.67-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Tejun Heo 

commit 9c6ac78eb3521c5937b2dd8a7d1b300f41092f45 upstream.

After invoking ->dirty_inode(), __mark_inode_dirty() does smp_mb() and
tests inode->i_state locklessly to see whether it already has all the
necessary I_DIRTY bits set.  The comment above the barrier doesn't
contain any useful information - memory barriers can't ensure "changes
are seen by all cpus" by itself.

And it sure enough was broken.  Please consider the following
scenario.

 CPU 0  CPU 1
 ---

enters __writeback_single_inode()
grabs inode->i_lock
tests PAGECACHE_TAG_DIRTY which is clear
 enters __set_page_dirty()
 grabs mapping->tree_lock
 sets PAGECACHE_TAG_DIRTY
 releases mapping->tree_lock
 leaves __set_page_dirty()

 enters __mark_inode_dirty()
 smp_mb()
 sees I_DIRTY_PAGES set
 leaves __mark_inode_dirty()
clears I_DIRTY_PAGES
releases inode->i_lock

Now @inode has dirty pages w/ I_DIRTY_PAGES clear.  This doesn't seem
to lead to an immediately critical problem because requeue_inode()
later checks PAGECACHE_TAG_DIRTY instead of I_DIRTY_PAGES when
deciding whether the inode needs to be requeued for IO and there are
enough unintentional memory barriers inbetween, so while the inode
ends up with inconsistent I_DIRTY_PAGES flag, it doesn't fall off the
IO list.

The lack of explicit barrier may also theoretically affect the other
I_DIRTY bits which deal with metadata dirtiness.  There is no
guarantee that a strong enough barrier exists between
I_DIRTY_[DATA]SYNC clearing and write_inode() writing out the dirtied
inode.  Filesystem inode writeout path likely has enough stuff which
can behave as full barrier but it's theoretically possible that the
writeout may not see all the updates from ->dirty_inode().

Fix it by adding an explicit smp_mb() after I_DIRTY clearing.  Note
that I_DIRTY_PAGES needs a special treatment as it always needs to be
cleared to be interlocked with the lockless test on
__mark_inode_dirty() side.  It's cleared unconditionally and
reinstated after smp_mb() if the mapping still has dirty pages.

Also add comments explaining how and why the barriers are paired.

Lightly tested.

Signed-off-by: Tejun Heo 
Cc: Jan Kara 
Cc: Mikulas Patocka 
Cc: Jens Axboe 
Cc: Al Viro 
Reviewed-by: Jan Kara 
Signed-off-by: Jens Axboe 
Signed-off-by: Ben Hutchings 
---
 fs/fs-writeback.c | 29 ++---
 1 file changed, 22 insertions(+), 7 deletions(-)

--- a/fs/fs-writeback.c
+++ b/fs/fs-writeback.c
@@ -418,12 +418,28 @@ writeback_single_inode(struct inode *ino
 * write_inode()
 */
spin_lock(>i_lock);
-   /* Clear I_DIRTY_PAGES if we've written out all dirty pages */
-   if (!mapping_tagged(mapping, PAGECACHE_TAG_DIRTY))
-   inode->i_state &= ~I_DIRTY_PAGES;
+
dirty = inode->i_state & I_DIRTY;
-   inode->i_state &= ~(I_DIRTY_SYNC | I_DIRTY_DATASYNC);
+   inode->i_state &= ~I_DIRTY;
+
+   /*
+* Paired with smp_mb() in __mark_inode_dirty().  This allows
+* __mark_inode_dirty() to test i_state without grabbing i_lock -
+* either they see the I_DIRTY bits cleared or we see the dirtied
+* inode.
+*
+* I_DIRTY_PAGES is always cleared together above even if @mapping
+* still has dirty pages.  The flag is reinstated after smp_mb() if
+* necessary.  This guarantees that either __mark_inode_dirty()
+* sees clear I_DIRTY_PAGES or we see PAGECACHE_TAG_DIRTY.
+*/
+   smp_mb();
+
+   if (mapping_tagged(mapping, PAGECACHE_TAG_DIRTY))
+   inode->i_state |= I_DIRTY_PAGES;
+
spin_unlock(>i_lock);
+
/* Don't write the inode if only I_DIRTY_PAGES was set */
if (dirty & (I_DIRTY_SYNC | I_DIRTY_DATASYNC)) {
int err = write_inode(inode, wbc);
@@ -1065,12 +1081,11 @@ void __mark_inode_dirty(struct inode *in
}
 
/*
-* make sure that changes are seen by all cpus before we test i_state
-* -- mikulas
+* Paired with smp_mb() in __writeback_single_inode() for the
+* following lockless i_state test.  See there for details.
 */
smp_mb();
 
-   /* avoid the locking if we can */
if ((inode->i_state & flags) == flags)
return;
 

--
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.2 131/152] drm/i915: Only fence tiled region of object.

2015-02-16 Thread Ben Hutchings
3.2.67-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Bob Paauwe 

commit af1a7301c7cf8912dca03065d448c4437c5c239f upstream.

When creating a fence for a tiled object, only fence the area that
makes up the actual tiles.  The object may be larger than the tiled
area and if we allow those extra addresses to be fenced, they'll
get converted to addresses beyond where the object is mapped. This
opens up the possiblity of writes beyond the end of object.

To prevent this, we adjust the size of the fence to only encompass
the area that makes up the actual tiles.  The extra space is considered
un-tiled and now behaves as if it was a linear object.

Testcase: igt/gem_tiled_fence_overflow
Reported-by: Dan Hettena 
Signed-off-by: Bob Paauwe 
Reviewed-by: Daniel Vetter 
Signed-off-by: Jani Nikula 
[bwh: Backported to 3.2:
 - Adjust context, indentation
 - Apply to both i965_write_fence_reg() and sandybridge_write_fence_reg(),
   which have been combined into one function upstream]
Signed-off-by: Ben Hutchings 
---
 drivers/gpu/drm/i915/i915_gem.c | 7 +++
 1 file changed, 7 insertions(+)

--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2248,6 +2248,13 @@ static int sandybridge_write_fence_reg(s
int regnum = obj->fence_reg;
uint64_t val;
 
+   /* Adjust fence size to match tiled area */
+   if (obj->tiling_mode != I915_TILING_NONE) {
+   uint32_t row_size = obj->stride *
+   (obj->tiling_mode == I915_TILING_Y ? 32 : 8);
+   size = (size / row_size) * row_size;
+   }
+
val = (uint64_t)((obj->gtt_offset + size - 4096) &
 0xf000) << 32;
val |= obj->gtt_offset & 0xf000;
@@ -2285,6 +2292,13 @@ static int i965_write_fence_reg(struct d
int regnum = obj->fence_reg;
uint64_t val;
 
+   /* Adjust fence size to match tiled area */
+   if (obj->tiling_mode != I915_TILING_NONE) {
+   uint32_t row_size = obj->stride *
+   (obj->tiling_mode == I915_TILING_Y ? 32 : 8);
+   size = (size / row_size) * row_size;
+   }
+
val = (uint64_t)((obj->gtt_offset + size - 4096) &
0xf000) << 32;
val |= obj->gtt_offset & 0xf000;

--
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.2 137/152] Revert "x86, 64bit, mm: Mark data/bss/brk to nx"

2015-02-16 Thread Ben Hutchings
3.2.67-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Ben Hutchings 

This reverts commit e105c8187b7101e8a8a54ac0218c9d9c9463c636 which
was commit 72212675d1c96f5db8ec6fb35701879911193158 upstream.

This caused suspend/resume to stop working on at least some systems -
specifically, the system would reboot when woken.

Signed-off-by: Ben Hutchings 
Cc: Steven Rostedt 
---
--- a/arch/x86/mm/init_64.c
+++ b/arch/x86/mm/init_64.c
@@ -778,7 +778,6 @@ void mark_rodata_ro(void)
unsigned long text_end = PAGE_ALIGN((unsigned long) &__stop___ex_table);
unsigned long rodata_end = PAGE_ALIGN((unsigned long) &__end_rodata);
unsigned long data_start = (unsigned long) &_sdata;
-   unsigned long all_end = PFN_ALIGN(&_end);
 
printk(KERN_INFO "Write protecting the kernel read-only data: %luk\n",
   (end - start) >> 10);
@@ -787,10 +786,10 @@ void mark_rodata_ro(void)
kernel_set_to_readonly = 1;
 
/*
-* The rodata/data/bss/brk section (but not the kernel text!)
-* should also be not-executable.
+* The rodata section (but not the kernel text!) should also be
+* not-executable.
 */
-   set_memory_nx(rodata_start, (all_end - rodata_start) >> PAGE_SHIFT);
+   set_memory_nx(rodata_start, (end - rodata_start) >> PAGE_SHIFT);
 
rodata_test();
 

--
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.2 005/152] writeback: Move I_DIRTY_PAGES handling

2015-02-16 Thread Ben Hutchings
3.2.67-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Jan Kara 

commit 6290be1c1dc6589eeda213aa40946b27fa4faac8 upstream.

Instead of clearing I_DIRTY_PAGES and resetting it when we didn't succeed in
writing them all, just clear the bit only when we succeeded writing all the
pages. We also move the clearing of the bit close to other i_state handling to
separate it from writeback list handling. This is desirable because list
handling will differ for flusher thread and other writeback_single_inode()
callers in future. No filesystem plays any tricks with I_DIRTY_PAGES (like
checking it in ->writepages or ->write_inode implementation) so this movement
is safe.

Signed-off-by: Jan Kara 
Signed-off-by: Fengguang Wu 
Signed-off-by: Ben Hutchings 
---
 fs/fs-writeback.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

--- a/fs/fs-writeback.c
+++ b/fs/fs-writeback.c
@@ -396,7 +396,6 @@ writeback_single_inode(struct inode *ino
 
/* Set I_SYNC, reset I_DIRTY_PAGES */
inode->i_state |= I_SYNC;
-   inode->i_state &= ~I_DIRTY_PAGES;
spin_unlock(>i_lock);
spin_unlock(>list_lock);
 
@@ -419,6 +418,9 @@ writeback_single_inode(struct inode *ino
 * write_inode()
 */
spin_lock(>i_lock);
+   /* Clear I_DIRTY_PAGES if we've written out all dirty pages */
+   if (!mapping_tagged(mapping, PAGECACHE_TAG_DIRTY))
+   inode->i_state &= ~I_DIRTY_PAGES;
dirty = inode->i_state & I_DIRTY;
inode->i_state &= ~(I_DIRTY_SYNC | I_DIRTY_DATASYNC);
spin_unlock(>i_lock);
@@ -447,7 +449,6 @@ writeback_single_inode(struct inode *ino
 * We didn't write back all the pages.  nfs_writepages()
 * sometimes bales out without doing anything.
 */
-   inode->i_state |= I_DIRTY_PAGES;
if (wbc->nr_to_write <= 0) {
/*
 * slice used up: queue for next turn

--
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.2 117/152] gpio: sysfs: fix gpio attribute-creation race

2015-02-16 Thread Ben Hutchings
3.2.67-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Johan Hovold 

commit ebbeba120ab2ec6ac5f3afc1425ec6ff0b77ad6f upstream.

Fix attribute-creation race with userspace by using the default group
to create also the contingent gpio device attributes.

Fixes: d8f388d8dc8d ("gpio: sysfs interface")
Signed-off-by: Johan Hovold 
Signed-off-by: Linus Walleij 
[bwh: Backported to 3.2:
 - Adjust filenames, context
 - Use gpio_to_desc(), not gpiod_to_desc(), in gpio_is_visible()
 - gpio_is_visible() must return mode_t]
Signed-off-by: Ben Hutchings 
---
--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -58,6 +58,7 @@ struct gpio_desc {
 #define FLAG_TRIG_FALL 5   /* trigger on falling edge */
 #define FLAG_TRIG_RISE 6   /* trigger on rising edge */
 #define FLAG_ACTIVE_LOW7   /* sysfs value has active low */
+#define FLAG_SYSFS_DIR 10  /* show sysfs direction attribute */
 
 #define ID_SHIFT   16  /* add new flags before this one */
 
@@ -543,12 +544,45 @@ static ssize_t gpio_active_low_store(str
 static DEVICE_ATTR(active_low, 0644,
gpio_active_low_show, gpio_active_low_store);
 
+static mode_t gpio_is_visible(struct kobject *kobj, struct attribute *attr,
+  int n)
+{
+   struct device *dev = container_of(kobj, struct device, kobj);
+   struct gpio_desc *desc = dev_get_drvdata(dev);
+   unsigned gpio = desc - gpio_desc;
+   mode_t mode = attr->mode;
+   bool show_direction = test_bit(FLAG_SYSFS_DIR, >flags);
+
+   if (attr == _attr_direction.attr) {
+   if (!show_direction)
+   mode = 0;
+   } else if (attr == _attr_edge.attr) {
+   if (gpio_to_irq(gpio) < 0)
+   mode = 0;
+   if (!show_direction && test_bit(FLAG_IS_OUT, >flags))
+   mode = 0;
+   }
+
+   return mode;
+}
+
 static struct attribute *gpio_attrs[] = {
+   _attr_direction.attr,
+   _attr_edge.attr,
_attr_value.attr,
_attr_active_low.attr,
NULL,
 };
-ATTRIBUTE_GROUPS(gpio);
+
+static const struct attribute_group gpio_group = {
+   .attrs = gpio_attrs,
+   .is_visible = gpio_is_visible,
+};
+
+static const struct attribute_group *gpio_groups[] = {
+   _group,
+   NULL
+};
 
 /*
  * /sys/class/gpio/gpiochipN/
@@ -723,8 +757,11 @@ int gpio_export(unsigned gpio, bool dire
return -EPERM;
}
 
-   if (!desc->chip->direction_input || !desc->chip->direction_output)
-   direction_may_change = false;
+   if (desc->chip->direction_input && desc->chip->direction_output &&
+   direction_may_change) {
+   set_bit(FLAG_SYSFS_DIR, >flags);
+   }
+
spin_unlock_irqrestore(_lock, flags);
 
if (desc->chip->names && desc->chip->names[gpio - desc->chip->base])
@@ -738,27 +775,10 @@ int gpio_export(unsigned gpio, bool dire
goto fail_unlock;
}
 
-   if (direction_may_change) {
-   status = device_create_file(dev, _attr_direction);
-   if (status)
-   goto fail_unregister_device;
-   }
-
-   if (gpio_to_irq(gpio) >= 0 && (direction_may_change ||
-  !test_bit(FLAG_IS_OUT, >flags))) {
-   status = device_create_file(dev, _attr_edge);
-   if (status)
-   goto fail_remove_attr_direction;
-   }
-
set_bit(FLAG_EXPORT, >flags);
mutex_unlock(_lock);
return 0;
 
-fail_remove_attr_direction:
-   device_remove_file(dev, _attr_direction);
-fail_unregister_device:
-   device_unregister(dev);
 fail_unlock:
mutex_unlock(_lock);
pr_debug("%s: gpio%d status %d\n", __func__, gpio, status);
@@ -889,6 +909,7 @@ void gpio_unexport(unsigned gpio)
dev = class_find_device(_class, NULL, desc, match_export);
if (dev) {
gpio_setup_irq(desc, dev, 0);
+   clear_bit(FLAG_SYSFS_DIR, >flags);
clear_bit(FLAG_EXPORT, >flags);
} else
status = -ENODEV;
@@ -896,8 +917,6 @@ void gpio_unexport(unsigned gpio)
 
mutex_unlock(_lock);
if (dev) {
-   device_remove_file(dev, _attr_edge);
-   device_remove_file(dev, _attr_direction);
device_unregister(dev);
put_device(dev);
}

--
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.2 002/152] [media] sound: simplify au0828 quirk table

2015-02-16 Thread Ben Hutchings
3.2.67-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Mauro Carvalho Chehab 

commit 5d1f00a20d2d56ed480e64e938a2391353ee565b upstream.

Add a macro to simplify au0828 quirk table. That makes easier
to check it against the USB IDs at drivers/media/usb/au0828/au0828-cards.c.

Signed-off-by: Mauro Carvalho Chehab 
[bwh: Backported to 3.2:
 - Adjust filename
 - Quirks were in a different order]
Signed-off-by: Ben Hutchings 
---
--- a/drivers/media/video/au0828/au0828-cards.c
+++ b/drivers/media/video/au0828/au0828-cards.c
@@ -36,6 +36,11 @@ void hvr950q_cs5340_audio(void *priv, in
au0828_clear(dev, REG_000, 0x10);
 }
 
+/*
+ * WARNING: There's a quirks table at sound/usb/quirks-table.h
+ * that should also be updated every time a new device with V4L2 support
+ * is added here.
+ */
 struct au0828_board au0828_boards[] = {
[AU0828_BOARD_UNKNOWN] = {
.name   = "Unknown board",
--- a/sound/usb/quirks-table.h
+++ b/sound/usb/quirks-table.h
@@ -2540,133 +2540,37 @@ YAMAHA_DEVICE(0x7010, "UB99"),
}
 },
 
-/* Hauppauge HVR-950Q and HVR-850 */
-{
-   USB_DEVICE_VENDOR_SPEC(0x2040, 0x7200),
-   .match_flags = USB_DEVICE_ID_MATCH_DEVICE |
-  USB_DEVICE_ID_MATCH_INT_CLASS |
-  USB_DEVICE_ID_MATCH_INT_SUBCLASS,
-   .bInterfaceClass = USB_CLASS_AUDIO,
-   .bInterfaceSubClass = USB_SUBCLASS_AUDIOCONTROL,
-   .driver_info = (unsigned long) &(const struct snd_usb_audio_quirk) {
-   .vendor_name = "Hauppauge",
-   .product_name = "HVR-950Q",
-   .ifnum = QUIRK_ANY_INTERFACE,
-   .type = QUIRK_AUDIO_ALIGN_TRANSFER,
-   }
-},
-{
-   USB_DEVICE_VENDOR_SPEC(0x2040, 0x7240),
-   .match_flags = USB_DEVICE_ID_MATCH_DEVICE |
-  USB_DEVICE_ID_MATCH_INT_CLASS |
-  USB_DEVICE_ID_MATCH_INT_SUBCLASS,
-   .bInterfaceClass = USB_CLASS_AUDIO,
-   .bInterfaceSubClass = USB_SUBCLASS_AUDIOCONTROL,
-   .driver_info = (unsigned long) &(const struct snd_usb_audio_quirk) {
-   .vendor_name = "Hauppauge",
-   .product_name = "HVR-850",
-   .ifnum = QUIRK_ANY_INTERFACE,
-   .type = QUIRK_AUDIO_ALIGN_TRANSFER,
-   }
-},
-{
-   USB_DEVICE_VENDOR_SPEC(0x2040, 0x7210),
-   .match_flags = USB_DEVICE_ID_MATCH_DEVICE |
-  USB_DEVICE_ID_MATCH_INT_CLASS |
-  USB_DEVICE_ID_MATCH_INT_SUBCLASS,
-   .bInterfaceClass = USB_CLASS_AUDIO,
-   .bInterfaceSubClass = USB_SUBCLASS_AUDIOCONTROL,
-   .driver_info = (unsigned long) &(const struct snd_usb_audio_quirk) {
-   .vendor_name = "Hauppauge",
-   .product_name = "HVR-950Q",
-   .ifnum = QUIRK_ANY_INTERFACE,
-   .type = QUIRK_AUDIO_ALIGN_TRANSFER,
-   }
-},
-{
-   USB_DEVICE_VENDOR_SPEC(0x2040, 0x7217),
-   .match_flags = USB_DEVICE_ID_MATCH_DEVICE |
-  USB_DEVICE_ID_MATCH_INT_CLASS |
-  USB_DEVICE_ID_MATCH_INT_SUBCLASS,
-   .bInterfaceClass = USB_CLASS_AUDIO,
-   .bInterfaceSubClass = USB_SUBCLASS_AUDIOCONTROL,
-   .driver_info = (unsigned long) &(const struct snd_usb_audio_quirk) {
-   .vendor_name = "Hauppauge",
-   .product_name = "HVR-950Q",
-   .ifnum = QUIRK_ANY_INTERFACE,
-   .type = QUIRK_AUDIO_ALIGN_TRANSFER,
-   }
-},
-{
-   USB_DEVICE_VENDOR_SPEC(0x2040, 0x721b),
-   .match_flags = USB_DEVICE_ID_MATCH_DEVICE |
-  USB_DEVICE_ID_MATCH_INT_CLASS |
-  USB_DEVICE_ID_MATCH_INT_SUBCLASS,
-   .bInterfaceClass = USB_CLASS_AUDIO,
-   .bInterfaceSubClass = USB_SUBCLASS_AUDIOCONTROL,
-   .driver_info = (unsigned long) &(const struct snd_usb_audio_quirk) {
-   .vendor_name = "Hauppauge",
-   .product_name = "HVR-950Q",
-   .ifnum = QUIRK_ANY_INTERFACE,
-   .type = QUIRK_AUDIO_ALIGN_TRANSFER,
-   }
-},
-{
-   USB_DEVICE_VENDOR_SPEC(0x2040, 0x721e),
-   .match_flags = USB_DEVICE_ID_MATCH_DEVICE |
-  USB_DEVICE_ID_MATCH_INT_CLASS |
-  USB_DEVICE_ID_MATCH_INT_SUBCLASS,
-   .bInterfaceClass = USB_CLASS_AUDIO,
-   .bInterfaceSubClass = USB_SUBCLASS_AUDIOCONTROL,
-   .driver_info = (unsigned long) &(const struct snd_usb_audio_quirk) {
-   .vendor_name = "Hauppauge",
-   .product_name = "HVR-950Q",
-   .ifnum = QUIRK_ANY_INTERFACE,
-   .type = QUIRK_AUDIO_ALIGN_TRANSFER,
-   }
-},
-{
-   USB_DEVICE_VENDOR_SPEC(0x2040, 0x721f),
-   .match_flags = USB_DEVICE_ID_MATCH_DEVICE |
-  USB_DEVICE_ID_MATCH_INT_CLASS |
-  USB_DEVICE_ID_MATCH_INT_SUBCLASS,
-   .bInterfaceClass = USB_CLASS_AUDIO,
-   .bInterfaceSubClass = 

[PATCH 3.2 143/152] netfilter: ipset: small potential read beyond the end of buffer

2015-02-16 Thread Ben Hutchings
3.2.67-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Dan Carpenter 

commit 2196937e12b1b4ba139806d132647e1651d655df upstream.

We could be reading 8 bytes into a 4 byte buffer here.  It seems
harmless but adding a check is the right thing to do and it silences a
static checker warning.

Signed-off-by: Dan Carpenter 
Acked-by: Jozsef Kadlecsik 
Signed-off-by: Pablo Neira Ayuso 
Signed-off-by: Ben Hutchings 
---
 net/netfilter/ipset/ip_set_core.c | 6 ++
 1 file changed, 6 insertions(+)

--- a/net/netfilter/ipset/ip_set_core.c
+++ b/net/netfilter/ipset/ip_set_core.c
@@ -1615,6 +1615,12 @@ ip_set_sockfn_get(struct sock *sk, int o
if (*op < IP_SET_OP_VERSION) {
/* Check the version at the beginning of operations */
struct ip_set_req_version *req_version = data;
+
+   if (*len < sizeof(struct ip_set_req_version)) {
+   ret = -EINVAL;
+   goto done;
+   }
+
if (req_version->version != IPSET_PROTOCOL) {
ret = -EPROTO;
goto done;

--
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.2 136/152] Revert "x86, mm: Set NX across entire PMD at boot"

2015-02-16 Thread Ben Hutchings
3.2.67-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Ben Hutchings 

This reverts commit a5c187d92d2ce30315f333b9dff33af832e8b443 which
was commit 45e2a9d4701d8c624d4a4bcdd1084eae31e92f58 upstream.

The previous commit caused suspend/resume to stop working on at least
some systems - specifically, the system would reboot when woken.

Signed-off-by: Ben Hutchings 
Cc: Steven Rostedt 
---
--- a/arch/x86/mm/init_64.c
+++ b/arch/x86/mm/init_64.c
@@ -778,7 +778,7 @@ void mark_rodata_ro(void)
unsigned long text_end = PAGE_ALIGN((unsigned long) &__stop___ex_table);
unsigned long rodata_end = PAGE_ALIGN((unsigned long) &__end_rodata);
unsigned long data_start = (unsigned long) &_sdata;
-   unsigned long all_end;
+   unsigned long all_end = PFN_ALIGN(&_end);
 
printk(KERN_INFO "Write protecting the kernel read-only data: %luk\n",
   (end - start) >> 10);
@@ -789,16 +789,7 @@ void mark_rodata_ro(void)
/*
 * The rodata/data/bss/brk section (but not the kernel text!)
 * should also be not-executable.
-*
-* We align all_end to PMD_SIZE because the existing mapping
-* is a full PMD. If we would align _brk_end to PAGE_SIZE we
-* split the PMD and the reminder between _brk_end and the end
-* of the PMD will remain mapped executable.
-*
-* Any PMD which was setup after the one which covers _brk_end
-* has been zapped already via cleanup_highmem().
 */
-   all_end = roundup((unsigned long)_brk_end, PMD_SIZE);
set_memory_nx(rodata_start, (all_end - rodata_start) >> PAGE_SHIFT);
 
rodata_test();

--
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.2 141/152] fsnotify: next_i is freed during fsnotify_unmount_inodes.

2015-02-16 Thread Ben Hutchings
3.2.67-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Jerry Hoemann 

commit 6424babfd68dd8a83d9c60a5242d27038856599f upstream.

During file system stress testing on 3.10 and 3.12 based kernels, the
umount command occasionally hung in fsnotify_unmount_inodes in the
section of code:

spin_lock(>i_lock);
if (inode->i_state & (I_FREEING|I_WILL_FREE|I_NEW)) {
spin_unlock(>i_lock);
continue;
}

As this section of code holds the global inode_sb_list_lock, eventually
the system hangs trying to acquire the lock.

Multiple crash dumps showed:

The inode->i_state == 0x60 and i_count == 0 and i_sb_list would point
back at itself.  As this is not the value of list upon entry to the
function, the kernel never exits the loop.

To help narrow down problem, the call to list_del_init in
inode_sb_list_del was changed to list_del.  This poisons the pointers in
the i_sb_list and causes a kernel to panic if it transverse a freed
inode.

Subsequent stress testing paniced in fsnotify_unmount_inodes at the
bottom of the list_for_each_entry_safe loop showing next_i had become
free.

We believe the root cause of the problem is that next_i is being freed
during the window of time that the list_for_each_entry_safe loop
temporarily releases inode_sb_list_lock to call fsnotify and
fsnotify_inode_delete.

The code in fsnotify_unmount_inodes attempts to prevent the freeing of
inode and next_i by calling __iget.  However, the code doesn't do the
__iget call on next_i

if i_count == 0 or
if i_state & (I_FREEING | I_WILL_FREE)

The patch addresses this issue by advancing next_i in the above two cases
until we either find a next_i which we can __iget or we reach the end of
the list.  This makes the handling of next_i more closely match the
handling of the variable "inode."

The time to reproduce the hang is highly variable (from hours to days.) We
ran the stress test on a 3.10 kernel with the proposed patch for a week
without failure.

During list_for_each_entry_safe, next_i is becoming free causing
the loop to never terminate.  Advance next_i in those cases where
__iget is not done.

Signed-off-by: Jerry Hoemann 
Cc: Jeff Kirsher 
Cc: Ken Helias 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Ben Hutchings 
Cc: Jan Kara 
---
 fs/notify/inode_mark.c | 17 +++--
 1 file changed, 11 insertions(+), 6 deletions(-)

--- a/fs/notify/inode_mark.c
+++ b/fs/notify/inode_mark.c
@@ -282,20 +282,25 @@ void fsnotify_unmount_inodes(struct list
spin_unlock(>i_lock);
 
/* In case the dropping of a reference would nuke next_i. */
-   if ((_i->i_sb_list != list) &&
-   atomic_read(_i->i_count)) {
+   while (_i->i_sb_list != list) {
spin_lock(_i->i_lock);
-   if (!(next_i->i_state & (I_FREEING | I_WILL_FREE))) {
+   if (!(next_i->i_state & (I_FREEING | I_WILL_FREE)) &&
+   atomic_read(_i->i_count)) {
__iget(next_i);
need_iput = next_i;
+   spin_unlock(_i->i_lock);
+   break;
}
spin_unlock(_i->i_lock);
+   next_i = list_entry(next_i->i_sb_list.next,
+   struct inode, i_sb_list);
}
 
/*
-* We can safely drop inode_sb_list_lock here because we hold
-* references on both inode and next_i.  Also no new inodes
-* will be added since the umount has begun.
+* We can safely drop inode_sb_list_lock here because either
+* we actually hold references on both inode and next_i or
+* end of list.  Also no new inodes will be added since the
+* umount has begun.
 */
spin_unlock(_sb_list_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.2 119/152] ALSA: usb-audio: Add mic volume fix quirk for Logitech Webcam C210

2015-02-16 Thread Ben Hutchings
3.2.67-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Jason Lee Cragg 

commit 6455931186bff407493135e74c5f32efd30860e2 upstream.

Signed-off-by: Jason Lee Cragg 
Signed-off-by: Takashi Iwai 
Signed-off-by: Ben Hutchings 
---
 sound/usb/mixer.c | 1 +
 1 file changed, 1 insertion(+)

--- a/sound/usb/mixer.c
+++ b/sound/usb/mixer.c
@@ -834,6 +834,7 @@ static void volume_control_quirks(struct
case USB_ID(0x046d, 0x0807): /* Logitech Webcam C500 */
case USB_ID(0x046d, 0x0808):
case USB_ID(0x046d, 0x0809):
+   case USB_ID(0x046d, 0x0819): /* Logitech Webcam C210 */
case USB_ID(0x046d, 0x081b): /* HD Webcam c310 */
case USB_ID(0x046d, 0x081d): /* HD Webcam c510 */
case USB_ID(0x046d, 0x0825): /* HD Webcam c270 */

--
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.2 122/152] libata: prevent HSM state change race between ISR and PIO

2015-02-16 Thread Ben Hutchings
3.2.67-rc1 review patch.  If anyone has any objections, please let me know.

--

From: David Jeffery 

commit ce7514526742c0898b837d4395f515b79dfb5a12 upstream.

It is possible for ata_sff_flush_pio_task() to set ap->hsm_task_state to
HSM_ST_IDLE in between the time __ata_sff_port_intr() checks for HSM_ST_IDLE
and before it calls ata_sff_hsm_move() causing ata_sff_hsm_move() to BUG().

This problem is hard to reproduce making this patch hard to verify, but this
fix will prevent the race.

I have not been able to reproduce the problem, but here is a crash dump from
a 2.6.32 kernel.

On examining the ata port's state, its hsm_task_state field has a value of 
HSM_ST_IDLE:

crash> struct ata_port.hsm_task_state 881c1121c000
  hsm_task_state = 0

Normally, this should not be possible as ata_sff_hsm_move() was called from 
ata_sff_host_intr(),
which checks hsm_task_state and won't call ata_sff_hsm_move() if it has a 
HSM_ST_IDLE value.

PID: 11053  TASK: 8816e846cae0  CPU: 0   COMMAND: "sshd"
 #0 [88008ba03960] machine_kexec at 81038f3b
 #1 [88008ba039c0] crash_kexec at 810c5d92
 #2 [88008ba03a90] oops_end at 8152b510
 #3 [88008ba03ac0] die at 81010e0b
 #4 [88008ba03af0] do_trap at 8152ad74
 #5 [88008ba03b50] do_invalid_op at 8100cf95
 #6 [88008ba03bf0] invalid_op at 8100bf9b
[exception RIP: ata_sff_hsm_move+317]
RIP: 813a77ad  RSP: 88008ba03ca0  RFLAGS: 00010097
RAX:   RBX: 881c1121dc60  RCX: 
RDX: 881c1121dd10  RSI: 881c1121dc60  RDI: 881c1121c000
RBP: 88008ba03d00   R8:    R9: 002e
R10: 0001003f  R11: 009b  R12: 881c1121c000
R13:   R14: 0050  R15: 881c1121dd78
ORIG_RAX:   CS: 0010  SS: 0018
 #7 [88008ba03d08] ata_sff_host_intr at 813a7fbd
 #8 [88008ba03d38] ata_sff_interrupt at 813a821e
 #9 [88008ba03d78] handle_IRQ_event at 810e6ec0
--- a/drivers/ata/libata-sff.c
+++ b/drivers/ata/libata-sff.c
@@ -1333,7 +1333,19 @@ void ata_sff_flush_pio_task(struct ata_p
DPRINTK("ENTER\n");
 
cancel_delayed_work_sync(>sff_pio_task);
+
+   /*
+* We wanna reset the HSM state to IDLE.  If we do so without
+* grabbing the port lock, critical sections protected by it which
+* expect the HSM state to stay stable may get surprised.  For
+* example, we may set IDLE in between the time
+* __ata_sff_port_intr() checks for HSM_ST_IDLE and before it calls
+* ata_sff_hsm_move() causing ata_sff_hsm_move() to BUG().
+*/
+   spin_lock_irq(ap->lock);
ap->hsm_task_state = HSM_ST_IDLE;
+   spin_unlock_irq(ap->lock);
+
ap->sff_pio_task_link = NULL;
 
if (ata_msg_ctl(ap))

--
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.2 124/152] x86, tls, ldt: Stop checking lm in LDT_empty

2015-02-16 Thread Ben Hutchings
3.2.67-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Andy Lutomirski 

commit e30ab185c490e9a9381385529e0fd32f0a399495 upstream.

32-bit programs don't have an lm bit in their ABI, so they can't
reliably cause LDT_empty to return true without resorting to memset.
They shouldn't need to do this.

This should fix a longstanding, if minor, issue in all 64-bit kernels
as well as a potential regression in the TLS hardening code.

Fixes: 41bdc78544b8 x86/tls: Validate TLS entries to protect espfix
Signed-off-by: Andy Lutomirski 
Cc: torva...@linux-foundation.org
Link: 
http://lkml.kernel.org/r/72a059de55e86ad5e2935c80aa91880ddf19d07c.1421954363.git.l...@amacapital.net
Signed-off-by: Thomas Gleixner 
Signed-off-by: Ben Hutchings 
---
 arch/x86/include/asm/desc.h | 9 ++---
 1 file changed, 2 insertions(+), 7 deletions(-)

--- a/arch/x86/include/asm/desc.h
+++ b/arch/x86/include/asm/desc.h
@@ -248,7 +248,8 @@ static inline void native_load_tls(struc
gdt[GDT_ENTRY_TLS_MIN + i] = t->tls_array[i];
 }
 
-#define _LDT_empty(info)   \
+/* This intentionally ignores lm, since 32-bit apps don't have that field. */
+#define LDT_empty(info)\
((info)->base_addr  == 0&&  \
 (info)->limit  == 0&&  \
 (info)->contents   == 0&&  \
@@ -258,12 +259,6 @@ static inline void native_load_tls(struc
 (info)->seg_not_present== 1&&  \
 (info)->useable== 0)
 
-#ifdef CONFIG_X86_64
-#define LDT_empty(info) (_LDT_empty(info) && ((info)->lm == 0))
-#else
-#define LDT_empty(info) (_LDT_empty(info))
-#endif
-
 static inline void clear_LDT(void)
 {
set_ldt(NULL, 0);

--
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.2 144/152] dcache: Fix locking bugs in backported "deal with deadlock in d_walk()"

2015-02-16 Thread Ben Hutchings
3.2.67-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Ben Hutchings 

Steven Rostedt reported:
> Porting -rt to the latest 3.2 stable tree I triggered this bug:
> 
> =
> [ BUG: bad unlock balance detected! ]
> -
> rm/1638 is trying to release lock (rcu_read_lock) at:
> [] rcu_read_unlock+0x0/0x23
> but there are no more locks to release!
> 
> other info that might help us debug this:
> 2 locks held by rm/1638:
>  #0:  (>s_type->i_mutex_key#9/1){+.+.+.}, at: [] 
> do_rmdir+0x5f/0xd2
>  #1:  (>s_type->i_mutex_key#9){+.+.+.}, at: [] 
> vfs_rmdir+0x49/0xac
> 
> stack backtrace:
> Pid: 1638, comm: rm Not tainted 3.2.66-test-rt96+ #2
> Call Trace:
>  [] ? printk+0x1d/0x1f
>  [] print_unlock_inbalance_bug+0xc3/0xcd
>  [] lock_release_non_nested+0x98/0x1ec
>  [] ? trace_hardirqs_off_caller+0x18/0x90
>  [] ? local_clock+0x2d/0x50
>  [] ? d_hash+0x2f/0x2f
>  [] ? d_hash+0x2f/0x2f
>  [] lock_release+0x192/0x1ad
>  [] rcu_read_unlock+0x17/0x23
>  [] shrink_dcache_parent+0x227/0x270
>  [] vfs_rmdir+0x68/0xac
>  [] do_rmdir+0x98/0xd2
>  [] ? fput+0x1a3/0x1ab
>  [] ? sysenter_exit+0xf/0x1a
>  [] ? trace_hardirqs_on_caller+0x118/0x149
>  [] sys_unlinkat+0x2b/0x35
>  [] sysenter_do_call+0x12/0x12
> 
> 
> 
> 
> There's a path to calling rcu_read_unlock() without calling
> rcu_read_lock() in have_submounts().
> 
>   goto positive;
> 
> positive:
>   if (!locked && read_seqretry(_lock, seq))
>   goto rename_retry;
> 
> rename_retry:
>   rcu_read_unlock();
> 
> in the above path, rcu_read_lock() is never done before calling
> rcu_read_unlock();

I reviewed locking contexts in all three functions that I changed when
backporting "deal with deadlock in d_walk()".  It's actually worse
than this:

- We don't hold this_parent->d_lock at the 'positive' label in
  have_submounts(), but it is unlocked after 'rename_retry'.
- There is an rcu_read_unlock() after the 'out' label in
  select_parent(), but it's not held at the 'goto out'.

Fix all three lock imbalances.

Reported-by: Steven Rostedt 
Signed-off-by: Ben Hutchings 
Tested-by: Steven Rostedt 
---
 fs/dcache.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

--- a/fs/dcache.c
+++ b/fs/dcache.c
@@ -1035,7 +1035,7 @@ ascend:
return 0; /* No mount points found in tree */
 positive:
if (!locked && read_seqretry(_lock, seq))
-   goto rename_retry;
+   goto rename_retry_unlocked;
if (locked)
write_sequnlock(_lock);
return 1;
@@ -1045,6 +1045,7 @@ rename_retry:
rcu_read_unlock();
if (locked)
goto again;
+rename_retry_unlocked:
locked = 1;
write_seqlock(_lock);
goto again;
@@ -1109,6 +1110,7 @@ resume:
 */
if (found && need_resched()) {
spin_unlock(>d_lock);
+   rcu_read_lock();
goto 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.2 138/152] ACPI / EC: Fix regression due to conflicting firmware behavior between Samsung and Acer.

2015-02-16 Thread Ben Hutchings
3.2.67-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Lv Zheng 

commit 79149001105f18bd2285ada109f9229ea24a7571 upstream.

It is reported that Samsung laptops that need to poll events are broken by
the following commit:
 Commit 3afcf2ece453e1a8c2c6de19cdf06da3772a1b08
 Subject: ACPI / EC: Add support to disallow QR_EC to be issued when SCI_EVT 
isn't set

The behaviors of the 2 vendor firmwares are conflict:
 1. Acer: OSPM shouldn't issue QR_EC unless SCI_EVT is set, firmware
 automatically sets SCI_EVT as long as there is event queued up.
 2. Samsung: OSPM should issue QR_EC whatever SCI_EVT is set, firmware
returns 0 when there is no event queued up.

This patch is a quick fix to distinguish the behaviors to make Acer
behavior only effective for Acer EC firmware so that the breakages on
Samsung EC firmware can be avoided.

Fixes: 3afcf2ece453 (ACPI / EC: Add support to disallow QR_EC to be issued ...)
Link: https://bugzilla.kernel.org/show_bug.cgi?id=44161
Reported-and-tested-by: Ortwin Glück 
Signed-off-by: Lv Zheng 
[ rjw : Subject ]
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Ben Hutchings 
Cc: Kamal Mostafa 
---
 drivers/acpi/ec.c | 25 ++---
 1 file changed, 18 insertions(+), 7 deletions(-)

--- a/drivers/acpi/ec.c
+++ b/drivers/acpi/ec.c
@@ -129,6 +129,7 @@ static int EC_FLAGS_MSI; /* Out-of-spec
 static int EC_FLAGS_VALIDATE_ECDT; /* ASUStec ECDTs need to be validated */
 static int EC_FLAGS_SKIP_DSDT_SCAN; /* Not all BIOS survive early DSDT scan */
 static int EC_FLAGS_CLEAR_ON_RESUME; /* Needs acpi_ec_clear() on boot/resume */
+static int EC_FLAGS_QUERY_HANDSHAKE; /* Needs QR_EC issued when SCI_EVT set */
 
 /* --
  Transaction Management
@@ -206,13 +207,8 @@ static bool advance_transaction(struct a
}
return wakeup;
} else {
-   /*
-* There is firmware refusing to respond QR_EC when SCI_EVT
-* is not set, for which case, we complete the QR_EC
-* without issuing it to the firmware.
-* https://bugzilla.kernel.org/show_bug.cgi?id=86211
-*/
-   if (!(status & ACPI_EC_FLAG_SCI) &&
+   if (EC_FLAGS_QUERY_HANDSHAKE &&
+   !(status & ACPI_EC_FLAG_SCI) &&
(t->command == ACPI_EC_COMMAND_QUERY)) {
t->flags |= ACPI_EC_COMMAND_POLL;
t->rdata[t->ri++] = 0x00;
@@ -987,6 +983,18 @@ static int ec_enlarge_storm_threshold(co
 }
 
 /*
+ * Acer EC firmware refuses to respond QR_EC when SCI_EVT is not set, for
+ * which case, we complete the QR_EC without issuing it to the firmware.
+ * https://bugzilla.kernel.org/show_bug.cgi?id=86211
+ */
+static int ec_flag_query_handshake(const struct dmi_system_id *id)
+{
+   pr_debug("Detected the EC firmware requiring QR_EC issued when SCI_EVT 
set\n");
+   EC_FLAGS_QUERY_HANDSHAKE = 1;
+   return 0;
+}
+
+/*
  * On some hardware it is necessary to clear events accumulated by the EC 
during
  * sleep. These ECs stop reporting GPEs until they are manually polled, if too
  * many events are accumulated. (e.g. Samsung Series 5/9 notebooks)
@@ -1052,6 +1060,9 @@ static struct dmi_system_id __initdata e
{
ec_clear_on_resume, "Samsung hardware", {
DMI_MATCH(DMI_SYS_VENDOR, "SAMSUNG ELECTRONICS CO., LTD.")}, NULL},
+   {
+   ec_flag_query_handshake, "Acer hardware", {
+   DMI_MATCH(DMI_SYS_VENDOR, "Acer"), }, 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.2 132/152] ALSA: seq-dummy: remove deadlock-causing events on close

2015-02-16 Thread Ben Hutchings
3.2.67-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Clemens Ladisch 

commit 0767e95bb96d7fdddcd590fb809e6975d93aebc5 upstream.

When the last subscriber to a "Through" port has been removed, the
subscribed destination ports might still be active, so it would be
wrong to send "all sounds off" and "reset controller" events to them.
The proper place for such a shutdown would be the closing of the actual
MIDI port (and close_substream() in rawmidi.c already can do this).

This also fixes a deadlock when dummy_unuse() tries to send events to
its own port that is already locked because it is being freed.

Reported-by: Peter Billam 
Signed-off-by: Clemens Ladisch 
Signed-off-by: Takashi Iwai 
Signed-off-by: Ben Hutchings 
---
 sound/core/seq/seq_dummy.c | 31 ---
 1 file changed, 31 deletions(-)

--- a/sound/core/seq/seq_dummy.c
+++ b/sound/core/seq/seq_dummy.c
@@ -82,36 +82,6 @@ struct snd_seq_dummy_port {
 static int my_client = -1;
 
 /*
- * unuse callback - send ALL_SOUNDS_OFF and RESET_CONTROLLERS events
- * to subscribers.
- * Note: this callback is called only after all subscribers are removed.
- */
-static int
-dummy_unuse(void *private_data, struct snd_seq_port_subscribe *info)
-{
-   struct snd_seq_dummy_port *p;
-   int i;
-   struct snd_seq_event ev;
-
-   p = private_data;
-   memset(, 0, sizeof(ev));
-   if (p->duplex)
-   ev.source.port = p->connect;
-   else
-   ev.source.port = p->port;
-   ev.dest.client = SNDRV_SEQ_ADDRESS_SUBSCRIBERS;
-   ev.type = SNDRV_SEQ_EVENT_CONTROLLER;
-   for (i = 0; i < 16; i++) {
-   ev.data.control.channel = i;
-   ev.data.control.param = MIDI_CTL_ALL_SOUNDS_OFF;
-   snd_seq_kernel_client_dispatch(p->client, , 0, 0);
-   ev.data.control.param = MIDI_CTL_RESET_CONTROLLERS;
-   snd_seq_kernel_client_dispatch(p->client, , 0, 0);
-   }
-   return 0;
-}
-
-/*
  * event input callback - just redirect events to subscribers
  */
 static int
@@ -175,7 +145,6 @@ create_port(int idx, int type)
| SNDRV_SEQ_PORT_TYPE_PORT;
memset(, 0, sizeof(pcb));
pcb.owner = THIS_MODULE;
-   pcb.unuse = dummy_unuse;
pcb.event_input = dummy_input;
pcb.private_free = dummy_free;
pcb.private_data = rec;

--
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.2 127/152] nl80211: fix per-station group key get/del and memory leak

2015-02-16 Thread Ben Hutchings
3.2.67-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Johannes Berg 

commit 0fa7b39131576dd1baa6ca17fca53c65d7f62249 upstream.

In case userspace attempts to obtain key information for or delete a
unicast key, this is currently erroneously rejected unless the driver
sets the WIPHY_FLAG_IBSS_RSN flag. Apparently enough drivers do so it
was never noticed.

Fix that, and while at it fix a potential memory leak: the error path
in the get_key() function was placed after allocating a message but
didn't free it - move it to a better place. Luckily admin permissions
are needed to call this operation.

Fixes: e31b82136d1ad ("cfg80211/mac80211: allow per-station GTKs")
Signed-off-by: Johannes Berg 
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings 
---
 net/wireless/nl80211.c | 9 -
 1 file changed, 4 insertions(+), 5 deletions(-)

--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -1815,6 +1815,9 @@ static int nl80211_get_key(struct sk_buf
if (!rdev->ops->get_key)
return -EOPNOTSUPP;
 
+   if (!pairwise && mac_addr && !(rdev->wiphy.flags & WIPHY_FLAG_IBSS_RSN))
+   return -ENOENT;
+
msg = nlmsg_new(NLMSG_DEFAULT_SIZE, GFP_KERNEL);
if (!msg)
return -ENOMEM;
@@ -1832,10 +1835,6 @@ static int nl80211_get_key(struct sk_buf
if (mac_addr)
NLA_PUT(msg, NL80211_ATTR_MAC, ETH_ALEN, mac_addr);
 
-   if (pairwise && mac_addr &&
-   !(rdev->wiphy.flags & WIPHY_FLAG_IBSS_RSN))
-   return -ENOENT;
-
err = rdev->ops->get_key(>wiphy, dev, key_idx, pairwise,
 mac_addr, , get_key_callback);
 
@@ -2007,7 +2006,7 @@ static int nl80211_del_key(struct sk_buf
wdev_lock(dev->ieee80211_ptr);
err = nl80211_key_allowed(dev->ieee80211_ptr);
 
-   if (key.type == NL80211_KEYTYPE_PAIRWISE && mac_addr &&
+   if (key.type == NL80211_KEYTYPE_GROUP && mac_addr &&
!(rdev->wiphy.flags & WIPHY_FLAG_IBSS_RSN))
err = -ENOENT;
 

--
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.2 114/152] gpiolib: Refactor gpio_export

2015-02-16 Thread Ben Hutchings
3.2.67-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Ryan Mallon 

commit fc4e2514995d9cd7f3e1a67098ce65d72acf8ec7 upstream.

The gpio_export function uses nested if statements and the status
variable to handle the failure cases. This makes the function logic
difficult to follow. Refactor the code to abort immediately on failure
using goto. This makes the code slightly longer, but significantly
reduces the nesting and number of split lines and makes the code easier
to read.

Signed-off-by: Ryan Mallon 
Signed-off-by: Linus Walleij 
Signed-off-by: Ben Hutchings 
---
 drivers/gpio/gpiolib.c | 85 +++---
 1 file changed, 46 insertions(+), 39 deletions(-)

--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -697,8 +697,9 @@ int gpio_export(unsigned gpio, bool dire
 {
unsigned long   flags;
struct gpio_desc*desc;
-   int status = -EINVAL;
+   int status;
const char  *ioname = NULL;
+   struct device   *dev;
 
/* can't export until sysfs is available ... */
if (!gpio_class.p) {
@@ -706,59 +707,65 @@ int gpio_export(unsigned gpio, bool dire
return -ENOENT;
}
 
-   if (!gpio_is_valid(gpio))
-   goto done;
+   if (!gpio_is_valid(gpio)) {
+   pr_debug("%s: gpio %d is not valid\n", __func__, gpio);
+   return -EINVAL;
+   }
 
mutex_lock(_lock);
 
spin_lock_irqsave(_lock, flags);
desc = _desc[gpio];
-   if (test_bit(FLAG_REQUESTED, >flags)
-   && !test_bit(FLAG_EXPORT, >flags)) {
-   status = 0;
-   if (!desc->chip->direction_input
-   || !desc->chip->direction_output)
-   direction_may_change = false;
+   if (!test_bit(FLAG_REQUESTED, >flags) ||
+test_bit(FLAG_EXPORT, >flags)) {
+   spin_unlock_irqrestore(_lock, flags);
+   pr_debug("%s: gpio %d unavailable (requested=%d, 
exported=%d)\n",
+   __func__, gpio,
+   test_bit(FLAG_REQUESTED, >flags),
+   test_bit(FLAG_EXPORT, >flags));
+   return -EPERM;
}
+
+   if (!desc->chip->direction_input || !desc->chip->direction_output)
+   direction_may_change = false;
spin_unlock_irqrestore(_lock, flags);
 
if (desc->chip->names && desc->chip->names[gpio - desc->chip->base])
ioname = desc->chip->names[gpio - desc->chip->base];
 
-   if (status == 0) {
-   struct device   *dev;
+   dev = device_create(_class, desc->chip->dev, MKDEV(0, 0),
+   desc, ioname ? ioname : "gpio%u", gpio);
+   if (IS_ERR(dev)) {
+   status = PTR_ERR(dev);
+   goto fail_unlock;
+   }
+
+   status = sysfs_create_group(>kobj, _attr_group);
+   if (status)
+   goto fail_unregister_device;
+
+   if (direction_may_change) {
+   status = device_create_file(dev, _attr_direction);
+   if (status)
+   goto fail_unregister_device;
+   }
 
-   dev = device_create(_class, desc->chip->dev, MKDEV(0, 0),
-   desc, ioname ? ioname : "gpio%u", gpio);
-   if (!IS_ERR(dev)) {
-   status = sysfs_create_group(>kobj,
-   _attr_group);
-
-   if (!status && direction_may_change)
-   status = device_create_file(dev,
-   _attr_direction);
-
-   if (!status && gpio_to_irq(gpio) >= 0
-   && (direction_may_change
-   || !test_bit(FLAG_IS_OUT,
-   >flags)))
-   status = device_create_file(dev,
-   _attr_edge);
-
-   if (status != 0)
-   device_unregister(dev);
-   } else
-   status = PTR_ERR(dev);
-   if (status == 0)
-   set_bit(FLAG_EXPORT, >flags);
+   if (gpio_to_irq(gpio) >= 0 && (direction_may_change ||
+  !test_bit(FLAG_IS_OUT, >flags))) {
+   status = device_create_file(dev, _attr_edge);
+   if (status)
+   goto fail_unregister_device;
}
 
+   set_bit(FLAG_EXPORT, >flags);
mutex_unlock(_lock);
+   return 0;
 
-done:
-   if (status)
-   pr_debug("%s: gpio%d status %d\n", __func__, gpio, status);
-
+fail_unregister_device:

[PATCH 3.2 004/152] [media] af9005: fix kernel panic on init if compiled without IR

2015-02-16 Thread Ben Hutchings
3.2.67-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Frank Schaefer 

commit 2279948735609d0d17d7384e776b674619f792ef upstream.

This patches fixes an ancient bug in the dvb_usb_af9005 driver, which
has been reported at least in the following threads:
https://lkml.org/lkml/2009/2/4/350
https://lkml.org/lkml/2014/9/18/558

If the driver is compiled in without any IR support (neither
DVB_USB_AF9005_REMOTE nor custom symbols), the symbol_request calls in
af9005_usb_module_init() return pointers != NULL although the IR
symbols are not available.

This leads to the following oops:
...
[8.529751] usbcore: registered new interface driver dvb_usb_af9005
[8.531584] BUG: unable to handle kernel paging request at 02e0
[8.533385] IP: [<7d9d67c6>] af9005_usb_module_init+0x6b/0x9d
[8.535613] *pde = 
[8.536416] Oops:  [#1] PREEMPT PREEMPT DEBUG_PAGEALLOCDEBUG_PAGEALLOC
[8.537863] CPU: 0 PID: 1 Comm: swapper Not tainted 
3.15.0-rc6-00151-ga5c075c #1
[8.539827] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
1.7.5-20140531_083030-gandalf 04/01/2014
[8.541519] task: 89c9a670 ti: 89c9c000 task.ti: 89c9c000
[8.541519] EIP: 0060:[<7d9d67c6>] EFLAGS: 00010206 CPU: 0
[8.541519] EIP is at af9005_usb_module_init+0x6b/0x9d
[8.541519] EAX: 02e0 EBX:  ECX: 0006 EDX: 
[8.541519] ESI:  EDI: 7da33ec8 EBP: 89c9df30 ESP: 89c9df2c
[8.541519]  DS: 007b ES: 007b FS:  GS: 00e0 SS: 0068
[8.541519] CR0: 8005003b CR2: 02e0 CR3: 05a54000 CR4: 0690
[8.541519] Stack:
[8.541519]  7d9d675b 89c9df90 7d992a49 7d7d5914 89c9df4c 7be3a800 7d08c58c 
8a4c3968
[8.541519]  89c9df80 7be3a966 0192 0006 0006 7d7d3ff4 8a4c397a 
0200
[8.541519]  7d6b1280 8a4c3979 0006 09a6 7da32db8 b13eec81 0006 
09a6
[8.541519] Call Trace:
[8.541519]  [<7d9d675b>] ? ttusb2_driver_init+0x16/0x16
[8.541519]  [<7d992a49>] do_one_initcall+0x77/0x106
[8.541519]  [<7be3a800>] ? parameqn+0x2/0x35
[8.541519]  [<7be3a966>] ? parse_args+0x113/0x25c
[8.541519]  [<7d992bc2>] kernel_init_freeable+0xea/0x167
[8.541519]  [<7cf01070>] kernel_init+0x8/0xb8
[8.541519]  [<7cf27ec0>] ret_from_kernel_thread+0x20/0x30
[8.541519]  [<7cf01068>] ? rest_init+0x10c/0x10c
[8.541519] Code: 08 c2 c7 05 44 ed f9 7d 00 00 e0 02 c7 05 40 ed f9 7d 00 
00 e0 02 c7 05 3c ed f9 7d 00 00 e0 02 75 1f b8 00 00 e0 02 85 c0 74 16  00 
00 e0 02 c7 05 54 84 8e 7d 00 00 e0 02 a3 58 84 8e 7d eb
[8.541519] EIP: [<7d9d67c6>] af9005_usb_module_init+0x6b/0x9d SS:ESP 
0068:89c9df2c
[8.541519] CR2: 02e0
[8.541519] ---[ end trace 768b6faf51370fc7 ]---

The prefered fix would be to convert the whole IR code to use the kernel IR
infrastructure (which wasn't available at the time this driver had been 
created).

Until anyone who still has this old hardware steps up an does the conversion,
fix it by not calling the symbol_request calls if the driver is compiled in
without the default IR symbols (CONFIG_DVB_USB_AF9005_REMOTE).
Due to the IR related pointers beeing NULL by default, IR support will then be 
disabled.

The downside of this solution is, that it will no longer be possible to
compile custom IR symbols (not using CONFIG_DVB_USB_AF9005_REMOTE) in.

Please note that this patch has NOT been tested with all possible cases.
I don't have the hardware and could only verify that it fixes the reported
bug.

Reported-by: Fengguag Wu 
Signed-off-by: Frank Schäfer 
Acked-by: Luca Olivetti 
Signed-off-by: Mauro Carvalho Chehab 
[bwh: Backported to 3.2: adjust filename]
Signed-off-by: Ben Hutchings 
---
 drivers/media/dvb/dvb-usb/af9005.c | 3 +++
 1 file changed, 3 insertions(+)

--- a/drivers/media/dvb/dvb-usb/af9005.c
+++ b/drivers/media/dvb/dvb-usb/af9005.c
@@ -1072,9 +1072,12 @@ static int __init af9005_usb_module_init
err("usb_register failed. (%d)", result);
return result;
}
+#if IS_MODULE(CONFIG_DVB_USB_AF9005) || defined(CONFIG_DVB_USB_AF9005_REMOTE)
+   /* FIXME: convert to todays kernel IR infrastructure */
rc_decode = symbol_request(af9005_rc_decode);
rc_keys = symbol_request(rc_map_af9005_table);
rc_keys_size = symbol_request(rc_map_af9005_table_size);
+#endif
if (rc_decode == NULL || rc_keys == NULL || rc_keys_size == NULL) {
err("af9005_rc_decode function not found, disabling remote");
af9005_properties.rc.legacy.rc_query = 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.2 016/152] scsi: correct return values for .eh_abort_handler implementations

2015-02-16 Thread Ben Hutchings
3.2.67-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Hannes Reinecke 

commit b6c92b7e0af575e2b8b05bdf33633cf9e1661cbf upstream.

The .eh_abort_handler needs to return SUCCESS, FAILED, or
FAST_IO_FAIL. So fixup all callers to adhere to this requirement.

Reviewed-by: Robert Elliott 
Signed-off-by: Hannes Reinecke 
Signed-off-by: Christoph Hellwig 
[bwh: Backported to 3.2: drop changes to esas2r]
Signed-off-by: Ben Hutchings 
---
--- a/drivers/scsi/NCR5380.c
+++ b/drivers/scsi/NCR5380.c
@@ -2662,14 +2662,14 @@ static void NCR5380_dma_complete(NCR5380
  *
  * Purpose : abort a command
  *
- * Inputs : cmd - the Scsi_Cmnd to abort, code - code to set the 
- *  host byte of the result field to, if zero DID_ABORTED is 
+ * Inputs : cmd - the Scsi_Cmnd to abort, code - code to set the
+ *  host byte of the result field to, if zero DID_ABORTED is
  *  used.
  *
- * Returns : 0 - success, -1 on failure.
+ * Returns : SUCCESS - success, FAILED on failure.
  *
- * XXX - there is no way to abort the command that is currently 
- * connected, you have to wait for it to complete.  If this is 
+ * XXX - there is no way to abort the command that is currently
+ * connected, you have to wait for it to complete.  If this is
  * a problem, we could implement longjmp() / setjmp(), setjmp()
  * called where the loop started in NCR5380_main().
  *
@@ -2719,7 +2719,7 @@ static int NCR5380_abort(Scsi_Cmnd * cmd
  * aborted flag and get back into our main loop.
  */
 
-   return 0;
+   return SUCCESS;
}
 #endif
 
--- a/drivers/scsi/aha1740.c
+++ b/drivers/scsi/aha1740.c
@@ -551,7 +551,7 @@ static int aha1740_eh_abort_handler (Scs
  * quiet as possible...
  */
 
-   return 0;
+   return SUCCESS;
 }
 
 static struct scsi_host_template aha1740_template = {
--- a/drivers/scsi/atari_NCR5380.c
+++ b/drivers/scsi/atari_NCR5380.c
@@ -2638,7 +2638,7 @@ static void NCR5380_reselect(struct Scsi
  * host byte of the result field to, if zero DID_ABORTED is
  * used.
  *
- * Returns : 0 - success, -1 on failure.
+ * Returns : SUCCESS - success, FAILED on failure.
  *
  * XXX - there is no way to abort the command that is currently
  *  connected, you have to wait for it to complete.  If this is
--- a/drivers/scsi/megaraid.c
+++ b/drivers/scsi/megaraid.c
@@ -1964,7 +1964,7 @@ megaraid_abort_and_reset(adapter_t *adap
 cmd->device->id, cmd->device->lun);
 
if(list_empty(>pending_list))
-   return FALSE;
+   return FAILED;
 
list_for_each_safe(pos, next, >pending_list) {
 
@@ -1987,7 +1987,7 @@ megaraid_abort_and_reset(adapter_t *adap
(aor==SCB_ABORT) ? "ABORTING":"RESET",
scb->idx);
 
-   return FALSE;
+   return FAILED;
}
else {
 
@@ -2012,12 +2012,12 @@ megaraid_abort_and_reset(adapter_t *adap
list_add_tail(SCSI_LIST(cmd),
>completed_list);
 
-   return TRUE;
+   return SUCCESS;
}
}
}
 
-   return FALSE;
+   return FAILED;
 }
 
 static inline int
--- a/drivers/scsi/sun3_NCR5380.c
+++ b/drivers/scsi/sun3_NCR5380.c
@@ -2624,15 +2624,15 @@ static void NCR5380_reselect (struct Scs
  * Purpose : abort a command
  *
  * Inputs : cmd - the struct scsi_cmnd to abort, code - code to set the
- * host byte of the result field to, if zero DID_ABORTED is 
+ * host byte of the result field to, if zero DID_ABORTED is
  * used.
  *
- * Returns : 0 - success, -1 on failure.
+ * Returns : SUCCESS - success, FAILED on failure.
  *
- * XXX - there is no way to abort the command that is currently 
- *  connected, you have to wait for it to complete.  If this is 
+ * XXX - there is no way to abort the command that is currently
+ *  connected, you have to wait for it to complete.  If this is
  *  a problem, we could implement longjmp() / setjmp(), setjmp()
- *  called where the loop started in NCR5380_main().
+ *  called where the loop started in NCR5380_main().
  */
 
 static int NCR5380_abort(struct scsi_cmnd *cmd)

--
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.2 147/152] net/core: Handle csum for CHECKSUM_COMPLETE VXLAN forwarding

2015-02-16 Thread Ben Hutchings
3.2.67-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Jay Vosburgh 

[ Upstream commit 2c26d34bbcc0b3f30385d5587aa232289e2eed8e ]

When using VXLAN tunnels and a sky2 device, I have experienced
checksum failures of the following type:

[ 4297.761899] eth0: hw csum failure
[...]
[ 4297.765223] Call Trace:
[ 4297.765224][] dump_stack+0x46/0x58
[ 4297.765235]  [] netdev_rx_csum_fault+0x42/0x50
[ 4297.765238]  [] ? skb_push+0x40/0x40
[ 4297.765240]  [] __skb_checksum_complete+0xbc/0xd0
[ 4297.765243]  [] tcp_v4_rcv+0x2e2/0x950
[ 4297.765246]  [] ? ip_rcv_finish+0x360/0x360

These are reliably reproduced in a network topology of:

container:eth0 == host(OVS VXLAN on VLAN) == bond0 == eth0 (sky2) -> switch

When VXLAN encapsulated traffic is received from a similarly
configured peer, the above warning is generated in the receive
processing of the encapsulated packet.  Note that the warning is
associated with the container eth0.

The skbs from sky2 have ip_summed set to CHECKSUM_COMPLETE, and
because the packet is an encapsulated Ethernet frame, the checksum
generated by the hardware includes the inner protocol and Ethernet
headers.

The receive code is careful to update the skb->csum, except in
__dev_forward_skb, as called by dev_forward_skb.  __dev_forward_skb
calls eth_type_trans, which in turn calls skb_pull_inline(skb, ETH_HLEN)
to skip over the Ethernet header, but does not update skb->csum when
doing so.

This patch resolves the problem by adding a call to
skb_postpull_rcsum to update the skb->csum after the call to
eth_type_trans.

Signed-off-by: Jay Vosburgh 
Signed-off-by: David S. Miller 
Signed-off-by: Ben Hutchings 
---
 net/core/dev.c | 1 +
 1 file changed, 1 insertion(+)

--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -1616,6 +1616,7 @@ int dev_forward_skb(struct net_device *d
skb->tstamp.tv64 = 0;
skb->pkt_type = PACKET_HOST;
skb->protocol = eth_type_trans(skb, dev);
+   skb_postpull_rcsum(skb, eth_hdr(skb), ETH_HLEN);
skb->mark = 0;
secpath_reset(skb);
nf_reset(skb);

--
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.2 134/152] vm: add VM_FAULT_SIGSEGV handling support

2015-02-16 Thread Ben Hutchings
3.2.67-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Linus Torvalds 

commit 33692f27597fcab536d7cbbcc8f52905133e4aa7 upstream.

The core VM already knows about VM_FAULT_SIGBUS, but cannot return a
"you should SIGSEGV" error, because the SIGSEGV case was generally
handled by the caller - usually the architecture fault handler.

That results in lots of duplication - all the architecture fault
handlers end up doing very similar "look up vma, check permissions, do
retries etc" - but it generally works.  However, there are cases where
the VM actually wants to SIGSEGV, and applications _expect_ SIGSEGV.

In particular, when accessing the stack guard page, libsigsegv expects a
SIGSEGV.  And it usually got one, because the stack growth is handled by
that duplicated architecture fault handler.

However, when the generic VM layer started propagating the error return
from the stack expansion in commit fee7e49d4514 ("mm: propagate error
from stack expansion even for guard page"), that now exposed the
existing VM_FAULT_SIGBUS result to user space.  And user space really
expected SIGSEGV, not SIGBUS.

To fix that case, we need to add a VM_FAULT_SIGSEGV, and teach all those
duplicate architecture fault handlers about it.  They all already have
the code to handle SIGSEGV, so it's about just tying that new return
value to the existing code, but it's all a bit annoying.

This is the mindless minimal patch to do this.  A more extensive patch
would be to try to gather up the mostly shared fault handling logic into
one generic helper routine, and long-term we really should do that
cleanup.

Just from this patch, you can generally see that most architectures just
copied (directly or indirectly) the old x86 way of doing things, but in
the meantime that original x86 model has been improved to hold the VM
semaphore for shorter times etc and to handle VM_FAULT_RETRY and other
"newer" things, so it would be a good idea to bring all those
improvements to the generic case and teach other architectures about
them too.

Reported-and-tested-by: Takashi Iwai 
Tested-by: Jan Engelhardt 
Acked-by: Heiko Carstens  # "s390 still compiles and 
boots"
Cc: linux-a...@vger.kernel.org
Signed-off-by: Linus Torvalds 
[bwh: Backported to 3.2:
 - Adjust filenames, context
 - Drop arc, metag, nios2 and lustre changes
 - For sh, patch both 32-bit and 64-bit implementations to use goto bad_area
 - For s390, pass int_code and trans_exc_code as arguments to do_no_context()
   and do_sigsegv()]
Signed-off-by: Ben Hutchings 
---
--- a/arch/alpha/mm/fault.c
+++ b/arch/alpha/mm/fault.c
@@ -150,6 +150,8 @@ do_page_fault(unsigned long address, uns
if (unlikely(fault & VM_FAULT_ERROR)) {
if (fault & VM_FAULT_OOM)
goto out_of_memory;
+   else if (fault & VM_FAULT_SIGSEGV)
+   goto bad_area;
else if (fault & VM_FAULT_SIGBUS)
goto do_sigbus;
BUG();
--- a/arch/avr32/mm/fault.c
+++ b/arch/avr32/mm/fault.c
@@ -136,6 +136,8 @@ good_area:
if (unlikely(fault & VM_FAULT_ERROR)) {
if (fault & VM_FAULT_OOM)
goto out_of_memory;
+   else if (fault & VM_FAULT_SIGSEGV)
+   goto bad_area;
else if (fault & VM_FAULT_SIGBUS)
goto do_sigbus;
BUG();
--- a/arch/cris/mm/fault.c
+++ b/arch/cris/mm/fault.c
@@ -166,6 +166,8 @@ do_page_fault(unsigned long address, str
if (unlikely(fault & VM_FAULT_ERROR)) {
if (fault & VM_FAULT_OOM)
goto out_of_memory;
+   else if (fault & VM_FAULT_SIGSEGV)
+   goto bad_area;
else if (fault & VM_FAULT_SIGBUS)
goto do_sigbus;
BUG();
--- a/arch/frv/mm/fault.c
+++ b/arch/frv/mm/fault.c
@@ -167,6 +167,8 @@ asmlinkage void do_page_fault(int datamm
if (unlikely(fault & VM_FAULT_ERROR)) {
if (fault & VM_FAULT_OOM)
goto out_of_memory;
+   else if (fault & VM_FAULT_SIGSEGV)
+   goto bad_area;
else if (fault & VM_FAULT_SIGBUS)
goto do_sigbus;
BUG();
--- a/arch/ia64/mm/fault.c
+++ b/arch/ia64/mm/fault.c
@@ -163,6 +163,8 @@ ia64_do_page_fault (unsigned long addres
 */
if (fault & VM_FAULT_OOM) {
goto out_of_memory;
+   } else if (fault & VM_FAULT_SIGSEGV) {
+   goto bad_area;
} else if (fault & VM_FAULT_SIGBUS) {
signal = SIGBUS;
goto bad_area;
--- a/arch/m32r/mm/fault.c
+++ b/arch/m32r/mm/fault.c
@@ -199,6 +199,8 @@ good_area:
if (unlikely(fault & VM_FAULT_ERROR)) {
if (fault & VM_FAULT_OOM)

Re: [PATCH 1/1] ptrace/x86: fix the TIF_FORCED_TF logic in handle_signal()

2015-02-16 Thread Andres Freund
Hi,

Could this patch please be picked up? I very regularly hit the problems
caused due to this in gdb (just single step out of a system call that
returns due to EINTR to reproduce and then single step some more...).

I've first spent an embarassing amount of time trying to figure out
what's wrong, to then find a closed bugzilla entry from 2010, to then
find this thread...

I've verified that applying the fix ontop 1fa185ebcbc fixes the issue
for me. So feel free to add a Tested-By. I, by far, don't understand the
code well enough for an actual review though, sorry.

Anything else I can do?

Greetings,

Andres Freund
--
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.2 111/152] sysfs.h: add ATTRIBUTE_GROUPS() macro

2015-02-16 Thread Ben Hutchings
3.2.67-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Greg Kroah-Hartman 

commit f2f37f58b1b933b06d6d84e80a31a1b500fb0db2 upstream.

To make it easier for driver subsystems to work with attribute groups,
create the ATTRIBUTE_GROUPS macro to remove some of the repetitive
typing for the most common use for attribute groups.

Reviewed-by: Guenter Roeck 
Tested-by: Guenter Roeck 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Ben Hutchings 
---
 include/linux/sysfs.h | 9 +
 1 file changed, 9 insertions(+)

--- a/include/linux/sysfs.h
+++ b/include/linux/sysfs.h
@@ -80,6 +80,15 @@ struct attribute_group {
 
 #define __ATTR_NULL { .attr = { .name = NULL } }
 
+#define ATTRIBUTE_GROUPS(name) \
+static const struct attribute_group name##_group = {   \
+   .attrs = name##_attrs,  \
+}; \
+static const struct attribute_group *name##_groups[] = {   \
+   ##_group,  \
+   NULL,   \
+}
+
 #define attr_name(_attr) (_attr).attr.name
 
 struct file;

--
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.2 140/152] x86, cpu, amd: Add workaround for family 16h, erratum 793

2015-02-16 Thread Ben Hutchings
3.2.67-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Borislav Petkov 

commit 3b56496865f9f7d9bcb2f93b44c63f274f08e3b6 upstream.

This adds the workaround for erratum 793 as a precaution in case not
every BIOS implements it.  This addresses CVE-2013-6885.

Erratum text:

[Revision Guide for AMD Family 16h Models 00h-0Fh Processors,
document 51810 Rev. 3.04 November 2013]

793 Specific Combination of Writes to Write Combined Memory Types and
Locked Instructions May Cause Core Hang

Description

Under a highly specific and detailed set of internal timing
conditions, a locked instruction may trigger a timing sequence whereby
the write to a write combined memory type is not flushed, causing the
locked instruction to stall indefinitely.

Potential Effect on System

Processor core hang.

Suggested Workaround

BIOS should set MSR
C001_1020[15] = 1b.

Fix Planned

No fix planned

[ hpa: updated description, fixed typo in MSR name ]

Signed-off-by: Borislav Petkov 
Link: http://lkml.kernel.org/r/20140114230711.gs29...@pd.tnic
Tested-by: Aravind Gopalakrishnan 
Signed-off-by: H. Peter Anvin 
[bwh: Backported to 3.2:
 - Adjust filename
 - Venkatesh Srinivas pointed out we should use {rd,wr}msrl_safe() to
   avoid crashing on KVM.  This was fixed upstream by commit 8f86a7373a1c
   ("x86, AMD: Convert to the new bit access MSR accessors") but that's too
   much trouble to backport.  Here we must use {rd,wr}msrl_amd_safe().]
Signed-off-by: Ben Hutchings 
Cc: Moritz Muehlenhoff 
Cc: Venkatesh Srinivas 
---
 arch/x86/include/asm/msr-index.h |  1 +
 arch/x86/kernel/cpu/amd.c| 10 ++
 2 files changed, 11 insertions(+)

--- a/arch/x86/include/asm/msr-index.h
+++ b/arch/x86/include/asm/msr-index.h
@@ -123,6 +123,7 @@
 #define MSR_AMD64_PATCH_LOADER 0xc0010020
 #define MSR_AMD64_OSVW_ID_LENGTH   0xc0010140
 #define MSR_AMD64_OSVW_STATUS  0xc0010141
+#define MSR_AMD64_LS_CFG   0xc0011020
 #define MSR_AMD64_DC_CFG   0xc0011022
 #define MSR_AMD64_IBSFETCHCTL  0xc0011030
 #define MSR_AMD64_IBSFETCHLINAD0xc0011031
--- a/arch/x86/kernel/cpu/amd.c
+++ b/arch/x86/kernel/cpu/amd.c
@@ -408,6 +408,16 @@ static void __cpuinit early_init_amd_mc(
 
c->x86_coreid_bits = bits;
 #endif
+
+   /* F16h erratum 793, CVE-2013-6885 */
+   if (c->x86 == 0x16 && c->x86_model <= 0xf) {
+   u64 val;
+
+   if (!rdmsrl_amd_safe(MSR_AMD64_LS_CFG, ) &&
+   !(val & BIT(15)))
+   wrmsrl_amd_safe(MSR_AMD64_LS_CFG, val | BIT(15));
+   }
+
 }
 
 static void __cpuinit bsp_init_amd(struct cpuinfo_x86 *c)

--
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.2 129/152] usb-core bInterval quirk

2015-02-16 Thread Ben Hutchings
3.2.67-rc1 review patch.  If anyone has any objections, please let me know.

--

From: James P Michels III 

commit cd83ce9e6195aa3ea15ab4db92892802c20df5d0 upstream.

This patch adds a usb quirk to support devices with interupt endpoints
and bInterval values expressed as microframes. The quirk causes the
parse endpoint function to modify the reported bInterval to a standards
conforming value.

There is currently code in the endpoint parser that checks for
bIntervals that are outside of the valid range (1-16 for USB 2+ high
speed and super speed interupt endpoints). In this case, the code assumes
the bInterval is being reported in 1ms frames. As well, the correction
is only applied if the original bInterval value is out of the 1-16 range.

With this quirk applied to the device, the bInterval will be
accurately adjusted from microframes to an exponent.

Signed-off-by: James P Michels III 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Ben Hutchings 
---
 drivers/usb/core/config.c  | 11 +++
 drivers/usb/core/quirks.c  |  4 
 include/linux/usb/quirks.h | 11 +++
 3 files changed, 26 insertions(+)

--- a/drivers/usb/core/config.c
+++ b/drivers/usb/core/config.c
@@ -201,6 +201,17 @@ static int usb_parse_endpoint(struct dev
if (n == 0)
n = 9;  /* 32 ms = 2^(9-1) uframes */
j = 16;
+
+   /*
+* Adjust bInterval for quirked devices.
+* This quirk fixes bIntervals reported in
+* linear microframes.
+*/
+   if (to_usb_device(ddev)->quirks &
+   USB_QUIRK_LINEAR_UFRAME_INTR_BINTERVAL) {
+   n = clamp(fls(d->bInterval), i, j);
+   i = j = n;
+   }
break;
default:/* USB_SPEED_FULL or _LOW */
/* For low-speed, 10 ms is the official minimum.
--- a/drivers/usb/core/quirks.c
+++ b/drivers/usb/core/quirks.c
@@ -150,6 +150,10 @@ static const struct usb_device_id usb_qu
/* SKYMEDI USB_DRIVE */
{ USB_DEVICE(0x1516, 0x8628), .driver_info = USB_QUIRK_RESET_RESUME },
 
+   /* Razer - Razer Blade Keyboard */
+   { USB_DEVICE(0x1532, 0x0116), .driver_info =
+   USB_QUIRK_LINEAR_UFRAME_INTR_BINTERVAL },
+
/* BUILDWIN Photo Frame */
{ USB_DEVICE(0x1908, 0x1315), .driver_info =
USB_QUIRK_HONOR_BNUMINTERFACES },
--- a/include/linux/usb/quirks.h
+++ b/include/linux/usb/quirks.h
@@ -30,6 +30,17 @@
descriptor */
 #define USB_QUIRK_DELAY_INIT   0x0040
 
+/*
+ * For high speed and super speed interupt endpoints, the USB 2.0 and
+ * USB 3.0 spec require the interval in microframes
+ * (1 microframe = 125 microseconds) to be calculated as
+ * interval = 2 ^ (bInterval-1).
+ *
+ * Devices with this quirk report their bInterval as the result of this
+ * calculation instead of the exponent variable used in the calculation.
+ */
+#define USB_QUIRK_LINEAR_UFRAME_INTR_BINTERVAL 0x0080
+
 /* device generates spurious wakeup, ignore remote wakeup capability */
 #define USB_QUIRK_IGNORE_REMOTE_WAKEUP 0x0200
 

--
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.2 120/152] libata: allow sata_sil24 to opt-out of tag ordered submission

2015-02-16 Thread Ben Hutchings
3.2.67-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Dan Williams 

commit 72dd299d5039a336493993dcc63413cf31d0e662 upstream.

Ronny reports: https://bugzilla.kernel.org/show_bug.cgi?id=87101
"Since commit 8a4aeec8d "libata/ahci: accommodate tag ordered
controllers" the access to the harddisk on the first SATA-port is
failing on its first access. The access to the harddisk on the
second port is working normal.

When reverting the above commit, access to both harddisks is working
fine again."

Maintain tag ordered submission as the default, but allow sata_sil24 to
continue with the old behavior.

Cc: Tejun Heo 
Reported-by: Ronny Hegewald 
Signed-off-by: Dan Williams 
Signed-off-by: Tejun Heo 
Signed-off-by: Ben Hutchings 
---
 drivers/ata/libata-core.c | 5 -
 drivers/ata/sata_sil24.c  | 2 +-
 include/linux/libata.h| 1 +
 3 files changed, 6 insertions(+), 2 deletions(-)

--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -4730,7 +4730,10 @@ static struct ata_queued_cmd *ata_qc_new
return NULL;
 
for (i = 0, tag = ap->last_tag + 1; i < max_queue; i++, tag++) {
-   tag = tag < max_queue ? tag : 0;
+   if (ap->flags & ATA_FLAG_LOWTAG)
+   tag = i;
+   else
+   tag = tag < max_queue ? tag : 0;
 
/* the last tag is reserved for internal command. */
if (tag == ATA_TAG_INTERNAL)
--- a/drivers/ata/sata_sil24.c
+++ b/drivers/ata/sata_sil24.c
@@ -246,7 +246,7 @@ enum {
/* host flags */
SIL24_COMMON_FLAGS  = ATA_FLAG_SATA | ATA_FLAG_PIO_DMA |
  ATA_FLAG_NCQ | ATA_FLAG_ACPI_SATA |
- ATA_FLAG_AN | ATA_FLAG_PMP,
+ ATA_FLAG_AN | ATA_FLAG_PMP | ATA_FLAG_LOWTAG,
SIL24_FLAG_PCIX_IRQ_WOC = (1 << 24), /* IRQ loss errata on PCI-X */
 
IRQ_STAT_4PORTS = 0xf,
--- a/include/linux/libata.h
+++ b/include/linux/libata.h
@@ -207,6 +207,7 @@ enum {
ATA_FLAG_SW_ACTIVITY= (1 << 22), /* driver supports sw activity
  * led */
ATA_FLAG_NO_DIPM= (1 << 23), /* host not happy with DIPM */
+   ATA_FLAG_LOWTAG = (1 << 24), /* host wants lowest available tag 
*/
 
/* bits 24:31 of ap->flags are reserved for LLD specific flags */
 

--
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.2 126/152] x86, tls: Interpret an all-zero struct user_desc as "no segment"

2015-02-16 Thread Ben Hutchings
3.2.67-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Andy Lutomirski 

commit 3669ef9fa7d35f573ec9c0e0341b29251c2734a7 upstream.

The Witcher 2 did something like this to allocate a TLS segment index:

struct user_desc u_info;
bzero(_info, sizeof(u_info));
u_info.entry_number = (uint32_t)-1;

syscall(SYS_set_thread_area, _info);

Strictly speaking, this code was never correct.  It should have set
read_exec_only and seg_not_present to 1 to indicate that it wanted
to find a free slot without putting anything there, or it should
have put something sensible in the TLS slot if it wanted to allocate
a TLS entry for real.  The actual effect of this code was to
allocate a bogus segment that could be used to exploit espfix.

The set_thread_area hardening patches changed the behavior, causing
set_thread_area to return -EINVAL and crashing the game.

This changes set_thread_area to interpret this as a request to find
a free slot and to leave it empty, which isn't *quite* what the game
expects but should be close enough to keep it working.  In
particular, using the code above to allocate two segments will
allocate the same segment both times.

According to FrostbittenKing on Github, this fixes The Witcher 2.

If this somehow still causes problems, we could instead allocate
a limit==0 32-bit data segment, but that seems rather ugly to me.

Fixes: 41bdc78544b8 x86/tls: Validate TLS entries to protect espfix
Signed-off-by: Andy Lutomirski 
Cc: torva...@linux-foundation.org
Link: 
http://lkml.kernel.org/r/0cb251abe1ff0958b8e468a9a9a905b80ae3a746.1421954363.git.l...@amacapital.net
Signed-off-by: Thomas Gleixner 
Signed-off-by: Ben Hutchings 
---
 arch/x86/include/asm/desc.h | 13 +
 arch/x86/kernel/tls.c   | 25 +++--
 2 files changed, 36 insertions(+), 2 deletions(-)

--- a/arch/x86/include/asm/desc.h
+++ b/arch/x86/include/asm/desc.h
@@ -259,6 +259,19 @@ static inline void native_load_tls(struc
 (info)->seg_not_present== 1&&  \
 (info)->useable== 0)
 
+/* Lots of programs expect an all-zero user_desc to mean "no segment at all". 
*/
+static inline bool LDT_zero(const struct user_desc *info)
+{
+   return (info->base_addr == 0 &&
+   info->limit == 0 &&
+   info->contents  == 0 &&
+   info->read_exec_only== 0 &&
+   info->seg_32bit == 0 &&
+   info->limit_in_pages== 0 &&
+   info->seg_not_present   == 0 &&
+   info->useable   == 0);
+}
+
 static inline void clear_LDT(void)
 {
set_ldt(NULL, 0);
--- a/arch/x86/kernel/tls.c
+++ b/arch/x86/kernel/tls.c
@@ -30,7 +30,28 @@ static int get_free_idx(void)
 
 static bool tls_desc_okay(const struct user_desc *info)
 {
-   if (LDT_empty(info))
+   /*
+* For historical reasons (i.e. no one ever documented how any
+* of the segmentation APIs work), user programs can and do
+* assume that a struct user_desc that's all zeros except for
+* entry_number means "no segment at all".  This never actually
+* worked.  In fact, up to Linux 3.19, a struct user_desc like
+* this would create a 16-bit read-write segment with base and
+* limit both equal to zero.
+*
+* That was close enough to "no segment at all" until we
+* hardened this function to disallow 16-bit TLS segments.  Fix
+* it up by interpreting these zeroed segments the way that they
+* were almost certainly intended to be interpreted.
+*
+* The correct way to ask for "no segment at all" is to specify
+* a user_desc that satisfies LDT_empty.  To keep everything
+* working, we accept both.
+*
+* Note that there's a similar kludge in modify_ldt -- look at
+* the distinction between modes 1 and 0x11.
+*/
+   if (LDT_empty(info) || LDT_zero(info))
return true;
 
/*
@@ -72,7 +93,7 @@ static void set_tls_desc(struct task_str
cpu = get_cpu();
 
while (n-- > 0) {
-   if (LDT_empty(info))
+   if (LDT_empty(info) || LDT_zero(info))
desc->a = desc->b = 0;
else
fill_ldt(desc, info);

--
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.2 110/152] can: dev: fix crtlmode_supported check

2015-02-16 Thread Ben Hutchings
3.2.67-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Oliver Hartkopp 

commit 9b1087aa5e86448fe6ad40a58964e35f3ba423d5 upstream.

When changing flags in the CAN drivers ctrlmode the provided new content has to
be checked whether the bits are allowed to be changed. The bits that are to be
changed are given as a bitfield in cm->mask. Therefore checking against
cm->flags is wrong as the content can hold any kind of values.

The iproute2 tool sets the bits in cm->mask and cm->flags depending on the
detected command line options. To be robust against bogus user space
applications additionally sanitize the provided flags with the provided mask.

Cc: Wolfgang Grandegger 
Signed-off-by: Oliver Hartkopp 
Signed-off-by: Marc Kleine-Budde 
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings 
---
 drivers/net/can/dev.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

--- a/drivers/net/can/dev.c
+++ b/drivers/net/can/dev.c
@@ -605,10 +605,14 @@ static int can_changelink(struct net_dev
if (dev->flags & IFF_UP)
return -EBUSY;
cm = nla_data(data[IFLA_CAN_CTRLMODE]);
-   if (cm->flags & ~priv->ctrlmode_supported)
+
+   /* check whether changed bits are allowed to be modified */
+   if (cm->mask & ~priv->ctrlmode_supported)
return -EOPNOTSUPP;
+
+   /* clear bits to be modified and copy the flag values */
priv->ctrlmode &= ~cm->mask;
-   priv->ctrlmode |= cm->flags;
+   priv->ctrlmode |= (cm->flags & cm->mask);
}
 
if (data[IFLA_CAN_BITTIMING]) {

--
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   9   10   >