Re: [PATCH 3/6] Input: Update vmmouse.c to use the common VMW_PORT macros

[Sinclair Yeh]

On Wed, Dec 02, 2015 at 10:45:28AM -0800, Greg Kroah-Hartman wrote:
> On Wed, Dec 02, 2015 at 09:26:34AM -0800, Dmitry Torokhov wrote:
> > On Wed, Dec 02, 2015 at 07:31:24AM -0800, Greg Kroah-Hartman wrote:
> > > On Tue, Dec 01, 2015 at 06:21:06PM -0800, Sinclair Yeh wrote:
> > > > On Tue, Dec 01, 2015 at 04:04:08PM -0800, Greg Kroah-Hartman wrote:
> > > > > On Tue, Dec 01, 2015 at 02:54:20PM -0800, Sinclair Yeh wrote:
> > > > > > Hi,
> > > > > > 
> > > > > > On Tue, Dec 01, 2015 at 02:45:27PM -0800, Dmitry Torokhov wrote:
> > > > > > > On Tue, Dec 1, 2015 at 2:32 PM, Sinclair Yeh  
> > > > > > > wrote:
> > > > > > > > Hi,
> > > > > > > >
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > > >> >   */
> > > > > > > >> > -#define VMMOUSE_CMD(cmd, in1, out1, out2, out3, out4)  \
> > > > > > > >> > -({ \
> > > > > > > >> > -   unsigned long __dummy1, __dummy2;   \
> > > > > > > >> > -   __asm__ __volatile__ ("inl %%dx" :  \
> > > > > > > >> > -   "=a"(out1), \
> > > > > > > >> > -   "=b"(out2), \
> > > > > > > >> > -   "=c"(out3), \
> > > > > > > >> > -   "=d"(out4), \
> > > > > > > >> > -   "=S"(__dummy1), \
> > > > > > > >> > -   "=D"(__dummy2) :\
> > > > > > > >> > -   "a"(VMMOUSE_PROTO_MAGIC),   \
> > > > > > > >> > -   "b"(in1),   \
> > > > > > > >> > -   "c"(VMMOUSE_PROTO_CMD_##cmd),   \
> > > > > > > >> > -   "d"(VMMOUSE_PROTO_PORT) :   \
> > > > > > > >> > -   "memory");  \
> > > > > > > >> > +#define VMMOUSE_CMD(cmd, in1, out1, out2, out3, out4)   
> > > > > > > >> >   \
> > > > > > > >> > +({  
> > > > > > > >> >   \
> > > > > > > >> > +   unsigned long __dummy1 = 0, __dummy2 = 0;
> > > > > > > >> >   \
> > > > > > > >>
> > > > > > > >> Why do we need to initialize dummies?
> > > > > > > >
> > > > > > > > Because for some commands those parameters to VMW_PORT() can be 
> > > > > > > > both
> > > > > > > > input and outout.
> > > > > > > 
> > > > > > > The vmmouse commands do not use them as input though, so it seems 
> > > > > > > we
> > > > > > > are simply wasting CPU cycles setting them to 0 just because we 
> > > > > > > are
> > > > > > > using the new VMW_PORT here. Why do we need to switch? What is the
> > > > > > > benefit of doing this?
> > > > > > 
> > > > > > There are two reasons.  One is to make the code more readable and
> > > > > > maintainable.  Rather than having mostly similar inline assembly
> > > > > > code sprinkled across multiple modules, we can just use the macros
> > > > > > and document that.
> > > > > 
> > > > > But the macro is only used here, and the variables aren't used at all,
> > > > > so it makes no sense in this file.
> > > > 
> > > > Maybe it's because I didn't CC you on the rest of the series.  I wasn't
> > > > sure what the proper distribution list is for each part.
> > > 
> > > Use scripts/get_maintainer.pl, that's what it is there for.  A number of
> > > those patches should go through me, if not all of them, if you want them
> > > merged...
> > > 
> > > > 
> > > > This new macro is also used in arch/x86/kernel/cpu/vmware.c and
> > > > vmw_balloon.c
> > > 
> > > And it's used inconsistantly in those patches (you don't set the dummy
> > > variables to 0 in all of them...)  Now maybe that's just how the asm
> > > functions work, but it's not very obvious as to why this is at all.
> > > 
> > > > > > The second reason is this organization makes some on-going future
> > > > > > development easier.
> > > > > 
> > > > > We don't plan for "future" development other than a single patch 
> > > > > series,
> > > > > as we have no idea what that development is, nor if it will really
> > > > > happen.  You can always change this file later if you need to, nothing
> > > > > is keeping that from happening.
> > > > 
> > > > So the intent of this series is to centralize similar lines of inline
> > > > assembly code that are currently used by 3 different kernel modules
> > > > to a central place.  The new vmware.h [patch 0/6] becomes the one header
> > > > to include for common guest-host communication needs.
> > > 
> > > Why can't it go into vmw_vmci_defs.h instead, or your other .h file, why
> > > create yet-another-.h-file for your bus?  You already have 2, this would
> > > make it 3, which seems like a lot...
> > 
> > Umm, you are not saying that vmmouse should include vmci header file(s),
> > are you? Because the 2 are unrelated and vmci does not use the
> > hypervisor port to communicate with host IIRC.
> 
> vmmouse should include some type of "vmware bus" .h file, if it's not
> the 

Re: [PATCH] mm: Fix mmap MAP_POPULATE for DAX pmd mapping

[Dan Williams]

On Wed, Dec 2, 2015 at 11:26 AM, Toshi Kani  wrote:
> On Wed, 2015-12-02 at 10:06 -0800, Dan Williams wrote:
>> On Wed, Dec 2, 2015 at 9:01 AM, Dan Williams  
>> wrote:
>> > On Wed, Dec 2, 2015 at 9:43 AM, Toshi Kani  wrote:
>> > > Oh, I see.  I will setup the memmap array and run the tests again.
>> > >
>> > > But, why does the PMD mapping depend on the memmap array?  We have
>> > > observed major performance improvement with PMD.  This feature should
>> > > always be enabled with DAX regardless of the option to allocate the 
>> > > memmap
>> > > array.
>> > >
>> >
>> > Several factors drove this decision, I'm open to considering
>> > alternatives but here's the reasoning:
>> >
>> > 1/ DAX pmd mappings caused crashes in the get_user_pages path leading
>> > to commit e82c9ed41e8 "dax: disable pmd mappings".  The reason pte
>> > mappings don't crash and instead trigger -EFAULT is due to the
>> > _PAGE_SPECIAL pte bit.
>> >
>> > 2/ To enable get_user_pages for DAX, in both the page and huge-page
>> > case, we need a new pte bit _PAGE_DEVMAP.
>> >
>> > 3/ Given the pte bits are hard to come I'm assuming we won't get two,
>> > i.e. both _PAGE_DEVMAP and a new _PAGE_SPECIAL for pmds.  Even if we
>> > could get a _PAGE_SPECIAL for pmds I'm not in favor of pursuing it.
>>
>> Actually, Dave says they aren't that hard to come by for pmds, so we
>> could go add _PMD_SPECIAL if we really wanted to support the limited
>> page-less DAX-pmd case.
>>
>> But I'm still of the opinion that we run away from the page-less case
>> until it can be made a full class citizen with O_DIRECT for pfn
>> support.
>
> I may be missing something, but per vm_normal_page(), I think _PAGE_SPECIAL 
> can
> be substituted by the following check when we do not have the memmap.
>
> if ((vma->vm_flags & VM_PFNMAP) ||
> ((vma->vm_flags & VM_MIXEDMAP) && (!pfn_valid(pfn {
>
> This is what I did in this patch for follow_trans_huge_pmd(), although I 
> missed
> the pfn_valid() check.

That works for __get_user_pages but not __get_user_pages_fast where we
don't have access to the vma.
--
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/6] Input: Update vmmouse.c to use the common VMW_PORT macros

[Dmitry Torokhov]

On Wed, Dec 02, 2015 at 10:45:28AM -0800, Greg Kroah-Hartman wrote:
> On Wed, Dec 02, 2015 at 09:26:34AM -0800, Dmitry Torokhov wrote:
> > On Wed, Dec 02, 2015 at 07:31:24AM -0800, Greg Kroah-Hartman wrote:
> > > On Tue, Dec 01, 2015 at 06:21:06PM -0800, Sinclair Yeh wrote:
> > > > On Tue, Dec 01, 2015 at 04:04:08PM -0800, Greg Kroah-Hartman wrote:
> > > > > On Tue, Dec 01, 2015 at 02:54:20PM -0800, Sinclair Yeh wrote:
> > > > > > Hi,
> > > > > > 
> > > > > > On Tue, Dec 01, 2015 at 02:45:27PM -0800, Dmitry Torokhov wrote:
> > > > > > > On Tue, Dec 1, 2015 at 2:32 PM, Sinclair Yeh  
> > > > > > > wrote:
> > > > > > > > Hi,
> > > > > > > >
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > > >> >   */
> > > > > > > >> > -#define VMMOUSE_CMD(cmd, in1, out1, out2, out3, out4)  \
> > > > > > > >> > -({ \
> > > > > > > >> > -   unsigned long __dummy1, __dummy2;   \
> > > > > > > >> > -   __asm__ __volatile__ ("inl %%dx" :  \
> > > > > > > >> > -   "=a"(out1), \
> > > > > > > >> > -   "=b"(out2), \
> > > > > > > >> > -   "=c"(out3), \
> > > > > > > >> > -   "=d"(out4), \
> > > > > > > >> > -   "=S"(__dummy1), \
> > > > > > > >> > -   "=D"(__dummy2) :\
> > > > > > > >> > -   "a"(VMMOUSE_PROTO_MAGIC),   \
> > > > > > > >> > -   "b"(in1),   \
> > > > > > > >> > -   "c"(VMMOUSE_PROTO_CMD_##cmd),   \
> > > > > > > >> > -   "d"(VMMOUSE_PROTO_PORT) :   \
> > > > > > > >> > -   "memory");  \
> > > > > > > >> > +#define VMMOUSE_CMD(cmd, in1, out1, out2, out3, out4)   
> > > > > > > >> >   \
> > > > > > > >> > +({  
> > > > > > > >> >   \
> > > > > > > >> > +   unsigned long __dummy1 = 0, __dummy2 = 0;
> > > > > > > >> >   \
> > > > > > > >>
> > > > > > > >> Why do we need to initialize dummies?
> > > > > > > >
> > > > > > > > Because for some commands those parameters to VMW_PORT() can be 
> > > > > > > > both
> > > > > > > > input and outout.
> > > > > > > 
> > > > > > > The vmmouse commands do not use them as input though, so it seems 
> > > > > > > we
> > > > > > > are simply wasting CPU cycles setting them to 0 just because we 
> > > > > > > are
> > > > > > > using the new VMW_PORT here. Why do we need to switch? What is the
> > > > > > > benefit of doing this?
> > > > > > 
> > > > > > There are two reasons.  One is to make the code more readable and
> > > > > > maintainable.  Rather than having mostly similar inline assembly
> > > > > > code sprinkled across multiple modules, we can just use the macros
> > > > > > and document that.
> > > > > 
> > > > > But the macro is only used here, and the variables aren't used at all,
> > > > > so it makes no sense in this file.
> > > > 
> > > > Maybe it's because I didn't CC you on the rest of the series.  I wasn't
> > > > sure what the proper distribution list is for each part.
> > > 
> > > Use scripts/get_maintainer.pl, that's what it is there for.  A number of
> > > those patches should go through me, if not all of them, if you want them
> > > merged...
> > > 
> > > > 
> > > > This new macro is also used in arch/x86/kernel/cpu/vmware.c and
> > > > vmw_balloon.c
> > > 
> > > And it's used inconsistantly in those patches (you don't set the dummy
> > > variables to 0 in all of them...)  Now maybe that's just how the asm
> > > functions work, but it's not very obvious as to why this is at all.
> > > 
> > > > > > The second reason is this organization makes some on-going future
> > > > > > development easier.
> > > > > 
> > > > > We don't plan for "future" development other than a single patch 
> > > > > series,
> > > > > as we have no idea what that development is, nor if it will really
> > > > > happen.  You can always change this file later if you need to, nothing
> > > > > is keeping that from happening.
> > > > 
> > > > So the intent of this series is to centralize similar lines of inline
> > > > assembly code that are currently used by 3 different kernel modules
> > > > to a central place.  The new vmware.h [patch 0/6] becomes the one header
> > > > to include for common guest-host communication needs.
> > > 
> > > Why can't it go into vmw_vmci_defs.h instead, or your other .h file, why
> > > create yet-another-.h-file for your bus?  You already have 2, this would
> > > make it 3, which seems like a lot...
> > 
> > Umm, you are not saying that vmmouse should include vmci header file(s),
> > are you? Because the 2 are unrelated and vmci does not use the
> > hypervisor port to communicate with host IIRC.
> 
> vmmouse should include some type of "vmware bus" .h file, if it's not
> the 

Re: [RFC PATCH 3/3] sched/fair: Use different cachelines for readers and writers of load_avg

[Waiman Long]

On 12/01/2015 03:49 AM, Peter Zijlstra wrote:

On Mon, Nov 30, 2015 at 10:55:02PM -0500, Waiman Long wrote:

On 11/30/2015 05:09 PM, Peter Zijlstra wrote:

On Mon, Nov 30, 2015 at 02:13:32PM -0500, Waiman Long wrote:

This begs the question tough; why are you running a global load in a
cgroup; and do we really need to update this for the root cgroup? It
seems to me we don't need calc_tg_weight() for the root cgroup, it
doesn't need to normalize its weight numbers.

That is; isn't this simply a problem we should avoid?

I didn't use any cgroup in my test setup. Autogroup was enabled, though.
Booting up a 4.4-rc2 kernel caused sched_create_group() to be called 56
times.

Yeah, can you kill autogroup and see if that helps? If not, we probably
should add some code to avoid calculating things for the root group.

I will try that out tomorrow. However, SCHED_AUTOGROUP was enabled in the
distribution kernels. So we still need to look at that with autogroup
enabled.

Meh, or just tell the people that have stupid large machines to use
noautogroup on boot (its of questionable benefit in the first place imo,
esp. on servers).


Yes, I was able to recover most of the lost performance by disabling 
autogroup. I did send out a new patch to disable load_avg update for 
root_task_group. I need that for backporting to earlier kernels which 
was forced to update load_avg for every clock tick even for root_task_group.


Cheers,
Longman
--
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 06/10] thermal: rockchip: consistently use int for temperatures

[Brian Norris]

Hi Caesar,

On Mon, Nov 09, 2015 at 12:48:58PM +0800, Caesar Wang wrote:
> As Temperature is currently represented as int not long in the thermal
> framework since use int intead of unsigned long/long to represent
> temperature to avoid bogus overheat detection when negative temperature
> reported.
> 
> Signed-off-by: Caesar Wang 
> 
> ---
> 
> Changes in v4:
> - fix the warning from the print message.
> 
> Changes in v3:
> - As the Patch v2 comments, Add a new patch to fix it.
> 
> Changes in v2: None
> Changes in v1: None
> 
>  drivers/thermal/rockchip_thermal.c | 16 
>  1 file changed, 8 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/thermal/rockchip_thermal.c 
> b/drivers/thermal/rockchip_thermal.c
> index 7c5b784..73d47f8 100644
> --- a/drivers/thermal/rockchip_thermal.c
> +++ b/drivers/thermal/rockchip_thermal.c
> @@ -88,7 +88,7 @@ struct rockchip_tsadc_chip {
>   int chn_num;
>  
>   /* The hardware-controlled tshut property */
> - long tshut_temp;
> + int tshut_temp;
>   enum tshut_mode tshut_mode;
>   enum tshut_polarity tshut_polarity;
>  

...

> @@ -126,7 +126,7 @@ struct rockchip_thermal_data {
>  
>   void __iomem *regs;
>  
> - long tshut_temp;
> + int tshut_temp;

FYI, this change is triggering a new warning in Coverity, below:

>   enum tshut_mode tshut_mode;
>   enum tshut_polarity tshut_polarity;
>  };

...

> @@ -477,7 +477,7 @@ static int rockchip_configure_from_dt(struct device *dev,
>   }
>  
>   if (thermal->tshut_temp > INT_MAX) {

 CID 1341498:  Integer handling issues  (CONSTANT_EXPRESSION_RESULT)
 "thermal->tshut_temp > 2147483647 /* (int)(~0U >> 1) */" is always false 
regardless of the values of its operands. This occurs as the logical operand of 
if.

I don't think this condition is even useful any more, so maybe we should
just kill the 'if' block.

> - dev_err(dev, "Invalid tshut temperature specified: %ld\n",
> + dev_err(dev, "Invalid tshut temperature specified: %d\n",
>   thermal->tshut_temp);
>   return -ERANGE;
>   }

Brian
--
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/6] Input: Update vmmouse.c to use the common VMW_PORT macros

[Greg Kroah-Hartman]

On Wed, Dec 02, 2015 at 09:26:34AM -0800, Dmitry Torokhov wrote:
> On Wed, Dec 02, 2015 at 07:31:24AM -0800, Greg Kroah-Hartman wrote:
> > On Tue, Dec 01, 2015 at 06:21:06PM -0800, Sinclair Yeh wrote:
> > > On Tue, Dec 01, 2015 at 04:04:08PM -0800, Greg Kroah-Hartman wrote:
> > > > On Tue, Dec 01, 2015 at 02:54:20PM -0800, Sinclair Yeh wrote:
> > > > > Hi,
> > > > > 
> > > > > On Tue, Dec 01, 2015 at 02:45:27PM -0800, Dmitry Torokhov wrote:
> > > > > > On Tue, Dec 1, 2015 at 2:32 PM, Sinclair Yeh  
> > > > > > wrote:
> > > > > > > Hi,
> > > > > > >
> > > > > 
> > > > > 
> > > > > 
> > > > > > >> >   */
> > > > > > >> > -#define VMMOUSE_CMD(cmd, in1, out1, out2, out3, out4)  \
> > > > > > >> > -({ \
> > > > > > >> > -   unsigned long __dummy1, __dummy2;   \
> > > > > > >> > -   __asm__ __volatile__ ("inl %%dx" :  \
> > > > > > >> > -   "=a"(out1), \
> > > > > > >> > -   "=b"(out2), \
> > > > > > >> > -   "=c"(out3), \
> > > > > > >> > -   "=d"(out4), \
> > > > > > >> > -   "=S"(__dummy1), \
> > > > > > >> > -   "=D"(__dummy2) :\
> > > > > > >> > -   "a"(VMMOUSE_PROTO_MAGIC),   \
> > > > > > >> > -   "b"(in1),   \
> > > > > > >> > -   "c"(VMMOUSE_PROTO_CMD_##cmd),   \
> > > > > > >> > -   "d"(VMMOUSE_PROTO_PORT) :   \
> > > > > > >> > -   "memory");  \
> > > > > > >> > +#define VMMOUSE_CMD(cmd, in1, out1, out2, out3, out4) 
> > > > > > >> > \
> > > > > > >> > +({
> > > > > > >> > \
> > > > > > >> > +   unsigned long __dummy1 = 0, __dummy2 = 0;  
> > > > > > >> > \
> > > > > > >>
> > > > > > >> Why do we need to initialize dummies?
> > > > > > >
> > > > > > > Because for some commands those parameters to VMW_PORT() can be 
> > > > > > > both
> > > > > > > input and outout.
> > > > > > 
> > > > > > The vmmouse commands do not use them as input though, so it seems we
> > > > > > are simply wasting CPU cycles setting them to 0 just because we are
> > > > > > using the new VMW_PORT here. Why do we need to switch? What is the
> > > > > > benefit of doing this?
> > > > > 
> > > > > There are two reasons.  One is to make the code more readable and
> > > > > maintainable.  Rather than having mostly similar inline assembly
> > > > > code sprinkled across multiple modules, we can just use the macros
> > > > > and document that.
> > > > 
> > > > But the macro is only used here, and the variables aren't used at all,
> > > > so it makes no sense in this file.
> > > 
> > > Maybe it's because I didn't CC you on the rest of the series.  I wasn't
> > > sure what the proper distribution list is for each part.
> > 
> > Use scripts/get_maintainer.pl, that's what it is there for.  A number of
> > those patches should go through me, if not all of them, if you want them
> > merged...
> > 
> > > 
> > > This new macro is also used in arch/x86/kernel/cpu/vmware.c and
> > > vmw_balloon.c
> > 
> > And it's used inconsistantly in those patches (you don't set the dummy
> > variables to 0 in all of them...)  Now maybe that's just how the asm
> > functions work, but it's not very obvious as to why this is at all.
> > 
> > > > > The second reason is this organization makes some on-going future
> > > > > development easier.
> > > > 
> > > > We don't plan for "future" development other than a single patch series,
> > > > as we have no idea what that development is, nor if it will really
> > > > happen.  You can always change this file later if you need to, nothing
> > > > is keeping that from happening.
> > > 
> > > So the intent of this series is to centralize similar lines of inline
> > > assembly code that are currently used by 3 different kernel modules
> > > to a central place.  The new vmware.h [patch 0/6] becomes the one header
> > > to include for common guest-host communication needs.
> > 
> > Why can't it go into vmw_vmci_defs.h instead, or your other .h file, why
> > create yet-another-.h-file for your bus?  You already have 2, this would
> > make it 3, which seems like a lot...
> 
> Umm, you are not saying that vmmouse should include vmci header file(s),
> are you? Because the 2 are unrelated and vmci does not use the
> hypervisor port to communicate with host IIRC.

vmmouse should include some type of "vmware bus" .h file, if it's not
the vmw_* files, what are they for?  My point being, I didn't see the
need to add another .h file when we should probably already have one for
this bus, right?

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to 

Re: [PATCH 1/3] Device tree binding documentation for chromeos-firmware

[Rob Herring]

On Wed, Dec 2, 2015 at 10:49 AM, Martyn Welch
 wrote:
>
>
> On 02/12/15 15:15, Rob Herring wrote:
>>
>> On Tue, Dec 01, 2015 at 07:12:49PM +, Martyn Welch wrote:
>>>
>>> This patch adds documentation for the chromeos-firmware binding.
>>>
>>> Cc: Rob Herring 
>>> Cc: Pawel Moll 
>>> Cc: Mark Rutland 
>>> Cc: Ian Campbell 
>>> Cc: Kumar Gala 
>>> Cc: devicet...@vger.kernel.org
>>> Signed-off-by: Martyn Welch 
>>> ---
>>>   .../devicetree/bindings/misc/chromeos-firmware.txt | 27
>>> ++
>>
>>
>> bindings/firmware/ please.
>>
>
> OK.
>
>>>   1 file changed, 27 insertions(+)
>>>   create mode 100644
>>> Documentation/devicetree/bindings/misc/chromeos-firmware.txt
>>>
>>> diff --git a/Documentation/devicetree/bindings/misc/chromeos-firmware.txt
>>> b/Documentation/devicetree/bindings/misc/chromeos-firmware.txt
>>> new file mode 100644
>>> index 000..8240611
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/misc/chromeos-firmware.txt
>>> @@ -0,0 +1,27 @@
>>> +Device-Tree bindings for chromeos-firmware.c.
>>
>>
>> Perhaps a bit more description what this is.
>>
>> What aspect of this is firmware? How does this relate to the EC?
>>
>
> With respect to write-protect, this line is the write protection for the
> flash which holds the bootloader.

What is driving the write-protect? Are trying to assign ownership of
the SOC GPIOs to the bootloader/firmware? If so, I think this is all
wrong.

Rob
--
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 PATCH 3/3] sched/fair: Use different cachelines for readers and writers of load_avg

[Waiman Long]

On 12/01/2015 03:47 AM, Peter Zijlstra wrote:

On Mon, Nov 30, 2015 at 11:00:35PM -0500, Waiman Long wrote:


I think the current kernel use power-of-2 kmemcaches to satisfy kalloc()
requests except when the size is less than or equal to 192 where there are
some non-power-of-2 kmemcaches available. Given that the task_group
structure is large enough with FAIR_GROUP_SCHED enabled, we shouldn't hit
the case that the allocated buffer is not cacheline aligned.

Using out-of-object storage is allowed (none of the existing sl*b
allocators do so iirc).

That is, its perfectly valid for a sl*b allocator for 64 byte objects to
allocate 72 bytes for each object and use the 'spare' 8 bytes for object
tracking or whatnot.

That would respect the minimum alignment guarantee of 8 bytes but not
provide the 'expected' object size alignment you're assuming.

Also, we have the proper interfaces to request the explicit alignment
for a reason. So if you need the alignment for correctness, use those.


Thanks for the tip. I have just sent out an updated patch set which 
create a cache-aligned memcache for task group. That should work under 
all kernel config setting.


Cheers,
Longman
--
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/27] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms

[Brian Norris]

Hi Roger,

On Wed, Dec 02, 2015 at 10:42:12AM +0530, Roger Quadros wrote:
> On 02/12/15 08:56, Brian Norris wrote:
> > On Tue, Dec 01, 2015 at 04:41:16PM +0200, Roger Quadros wrote:
> >> On 30/11/15 21:54, Brian Norris wrote:
> >>> But anyway, I'm not sure that completely answered my question. My
> >>> question was whether you were removing the irqchip code solely for
> >>> performance reasons, or are there others?
> >>
> >> Yes. Only for performance reasons.
> > 
> > Hmm, that's not my favorite answer. I'd prefer that more analysis was
> > done here before scrapping irqchip...
> 
> I agree. We could retain the irqchip model till we have more satisfying
> analysis.

I won't insist, though if it's not too ugly/horrible to do so, I think
that would make sense. I'll leave it as your call.

Brian
--
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] sched/fair: Move hot load_avg into its own cacheline

[Waiman Long]

If a system with large number of sockets was driven to full
utilization, it was found that the clock tick handling occupied a
rather significant proportion of CPU time when fair group scheduling
and autogroup were enabled.

Running a java benchmark on a 16-socket IvyBridge-EX system, the perf
profile looked like:

  10.52%   0.00%  java   [kernel.vmlinux]  [k] smp_apic_timer_interrupt
   9.66%   0.05%  java   [kernel.vmlinux]  [k] hrtimer_interrupt
   8.65%   0.03%  java   [kernel.vmlinux]  [k] tick_sched_timer
   8.56%   0.00%  java   [kernel.vmlinux]  [k] update_process_times
   8.07%   0.03%  java   [kernel.vmlinux]  [k] scheduler_tick
   6.91%   1.78%  java   [kernel.vmlinux]  [k] task_tick_fair
   5.24%   5.04%  java   [kernel.vmlinux]  [k] update_cfs_shares

In particular, the high CPU time consumed by update_cfs_shares()
was mostly due to contention on the cacheline that contained the
task_group's load_avg statistical counter. This cacheline may also
contains variables like shares, cfs_rq & se which are accessed rather
frequently during clock tick processing.

This patch moves the load_avg variable into another cacheline
separated from the other frequently accessed variables. It also
creates a cacheline aligned kmemcache for task_group to make sure
that all the allocated task_group's are cacheline aligned.

By doing so, the perf profile became:

   9.44%   0.00%  java   [kernel.vmlinux]  [k] smp_apic_timer_interrupt
   8.74%   0.01%  java   [kernel.vmlinux]  [k] hrtimer_interrupt
   7.83%   0.03%  java   [kernel.vmlinux]  [k] tick_sched_timer
   7.74%   0.00%  java   [kernel.vmlinux]  [k] update_process_times
   7.27%   0.03%  java   [kernel.vmlinux]  [k] scheduler_tick
   5.94%   1.74%  java   [kernel.vmlinux]  [k] task_tick_fair
   4.15%   3.92%  java   [kernel.vmlinux]  [k] update_cfs_shares

The %cpu time is still pretty high, but it is better than before. The
benchmark results before and after the patch was as follows:

  Before patch - Max-jOPs: 907533Critical-jOps: 134877
  After patch  - Max-jOPs: 916011Critical-jOps: 142366

Signed-off-by: Waiman Long 
---
 kernel/sched/core.c  |   36 ++--
 kernel/sched/sched.h |7 ++-
 2 files changed, 40 insertions(+), 3 deletions(-)

diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 4d568ac..e39204f 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -7331,6 +7331,11 @@ int in_sched_functions(unsigned long addr)
  */
 struct task_group root_task_group;
 LIST_HEAD(task_groups);
+
+#ifdef CONFIG_FAIR_GROUP_SCHED
+/* Cacheline aligned slab cache for task_group */
+static struct kmem_cache *task_group_cache __read_mostly;
+#endif
 #endif
 
 DECLARE_PER_CPU(cpumask_var_t, load_balance_mask);
@@ -7356,6 +7361,7 @@ void __init sched_init(void)
root_task_group.cfs_rq = (struct cfs_rq **)ptr;
ptr += nr_cpu_ids * sizeof(void **);
 
+   task_group_cache = KMEM_CACHE(task_group, SLAB_HWCACHE_ALIGN);
 #endif /* CONFIG_FAIR_GROUP_SCHED */
 #ifdef CONFIG_RT_GROUP_SCHED
root_task_group.rt_se = (struct sched_rt_entity **)ptr;
@@ -7668,12 +7674,38 @@ void set_curr_task(int cpu, struct task_struct *p)
 /* task_group_lock serializes the addition/removal of task groups */
 static DEFINE_SPINLOCK(task_group_lock);
 
+/*
+ * Make sure that the task_group structure is cacheline aligned when
+ * fair group scheduling is enabled.
+ */
+#ifdef CONFIG_FAIR_GROUP_SCHED
+static inline struct task_group *alloc_task_group(void)
+{
+   return kmem_cache_alloc(task_group_cache, GFP_KERNEL | __GFP_ZERO);
+}
+
+static inline void free_task_group(struct task_group *tg)
+{
+   kmem_cache_free(task_group_cache, tg);
+}
+#else /* CONFIG_FAIR_GROUP_SCHED */
+static inline struct task_group *alloc_task_group(void)
+{
+   return kzalloc(sizeof(struct task_group), GFP_KERNEL);
+}
+
+static inline void free_task_group(struct task_group *tg)
+{
+   kfree(tg);
+}
+#endif /* CONFIG_FAIR_GROUP_SCHED */
+
 static void free_sched_group(struct task_group *tg)
 {
free_fair_sched_group(tg);
free_rt_sched_group(tg);
autogroup_free(tg);
-   kfree(tg);
+   free_task_group(tg);
 }
 
 /* allocate runqueue etc for a new task group */
@@ -7681,7 +7713,7 @@ struct task_group *sched_create_group(struct task_group 
*parent)
 {
struct task_group *tg;
 
-   tg = kzalloc(sizeof(*tg), GFP_KERNEL);
+   tg = alloc_task_group();
if (!tg)
return ERR_PTR(-ENOMEM);
 
diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
index efd3bfc..e679895 100644
--- a/kernel/sched/sched.h
+++ b/kernel/sched/sched.h
@@ -248,7 +248,12 @@ struct task_group {
unsigned long shares;
 
 #ifdef CONFIG_SMP
-   atomic_long_t load_avg;
+   /*
+* load_avg can be heavily contended at clock tick time, so put
+* it in its own cacheline separated from the fields above which
+* will also be accessed 

[PATCH v2 3/3] sched/fair: Disable tg load_avg update for root_task_group

[Waiman Long]

Currently, the update_tg_load_avg() function attempts to update the
tg's load_avg value whenever the load changes even for root_task_group
where the load_avg value will never be used. This patch will disable
the load_avg update when the given task group is the root_task_group.

Running a Java benchmark with noautogroup and a 4.3 kernel on a
16-socket IvyBridge-EX system, the amount of CPU time (as reported by
perf) consumed by task_tick_fair() which includes update_tg_load_avg()
decreased from 0.71% to 0.22%, a more than 3X reduction. The Max-jOPs
results also increased slightly from 983015 to 986449.

Signed-off-by: Waiman Long 
---
 kernel/sched/fair.c |6 ++
 1 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 8f1eccc..4607cb7 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -2670,6 +2670,12 @@ static inline void update_tg_load_avg(struct cfs_rq 
*cfs_rq, int force)
 {
long delta = cfs_rq->avg.load_avg - cfs_rq->tg_load_avg_contrib;
 
+   /*
+* No need to update load_avg for root_task_group as it is not used.
+*/
+   if (cfs_rq->tg == _task_group)
+   return;
+
if (force || abs(delta) > cfs_rq->tg_load_avg_contrib / 64) {
atomic_long_add(delta, _rq->tg->load_avg);
cfs_rq->tg_load_avg_contrib = cfs_rq->avg.load_avg;
-- 
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 0/3] sched/fair: Reduce contention on tg's load_avg

[Waiman Long]

v1->v2:
 - Make a memcache for task_group to make sure that the allocated
   task_group object will always be on cacheline boundary even if
   debugging is turned on.
 - Scrap the original patch 3 and replace it with another one to
   disable load_avg update for root_task_group.

This patch series tries to reduce contention on task_group's load_avg
to improve system performance. It also tries to optimize the use of
idle_cpu() call in update_sg_lb_stats().

Waiman Long (3):
  sched/fair: Avoid redundant idle_cpu() call in update_sg_lb_stats()
  sched/fair: Move hot load_avg into its own cacheline
  sched/fair: Disable tg load_avg update for root_task_group

 kernel/sched/core.c  |   36 ++--
 kernel/sched/fair.c  |   16 +---
 kernel/sched/sched.h |7 ++-
 3 files changed, 53 insertions(+), 6 deletions(-)

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

[PATCH v2 1/3] sched/fair: Avoid redundant idle_cpu() call in update_sg_lb_stats()

[Waiman Long]

Part of the responsibility of the update_sg_lb_stats() function is to
update the idle_cpus statistical counter in struct sg_lb_stats. This
check is done by calling idle_cpu(). The idle_cpu() function, in
turn, checks a number of fields within the run queue structure such
as rq->curr and rq->nr_running.

With the current layout of the run queue structure, rq->curr and
rq->nr_running are in separate cachelines. The rq->curr variable is
checked first followed by nr_running. As nr_running is also accessed
by update_sg_lb_stats() earlier, it makes no sense to load another
cacheline when nr_running is not 0 as idle_cpu() will always return
false in this case.

This patch eliminates this redundant cacheline load by checking the
cached nr_running before calling idle_cpu().

Signed-off-by: Waiman Long 
---
 kernel/sched/fair.c |   10 +++---
 1 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index f04fda8..8f1eccc 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -6302,7 +6302,7 @@ static inline void update_sg_lb_stats(struct lb_env *env,
bool *overload)
 {
unsigned long load;
-   int i;
+   int i, nr_running;
 
memset(sgs, 0, sizeof(*sgs));
 
@@ -6319,7 +6319,8 @@ static inline void update_sg_lb_stats(struct lb_env *env,
sgs->group_util += cpu_util(i);
sgs->sum_nr_running += rq->cfs.h_nr_running;
 
-   if (rq->nr_running > 1)
+   nr_running = rq->nr_running;
+   if (nr_running > 1)
*overload = true;
 
 #ifdef CONFIG_NUMA_BALANCING
@@ -6327,7 +6328,10 @@ static inline void update_sg_lb_stats(struct lb_env *env,
sgs->nr_preferred_running += rq->nr_preferred_running;
 #endif
sgs->sum_weighted_load += weighted_cpuload(i);
-   if (idle_cpu(i))
+   /*
+* No need to call idle_cpu() if nr_running is not 0
+*/
+   if (!nr_running && idle_cpu(i))
sgs->idle_cpus++;
}
 
-- 
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/

Re: [RFC PATCH v2] iommu/amd: gray the 'irq_remap_table' object for kmemleak

[Borislav Petkov]

On Wed, Dec 02, 2015 at 05:36:32PM +, Catalin Marinas wrote:
> Defending kmemleak here ;).

Oh sure, by all means. I'm also assuming it comes across that I wasn't
attacking kmemleak. I had the same arguments with KASAN and other stuff
in the past.

> Tracking page allocations in kmemleak by intercepting
> __get_free_pages() has significant implications on false negatives for
> two main reasons:
> 
> 1. The sl?b allocators themselves use page allocations, so kmemleak
> could end up detecting the same pointer twice, hiding a potential leak
> 
> 2. Most page allocations do not contain data/pointers relevant to
> kmemleak (e.g. page cache pages), however the randomness of such data
> greatly diminishes kmemleak's ability to detect real leaks

Yeah, so can you teach kmemleak to ignore pointers from
__get_free_pages()? Since it cannot track them properly and it causes
false positives and all. Now it invites people to add annotation which
makes unrelated code obscure.

> Arguably, kmemleak could be made to detect both cases above by a
> combination of page flags, additional annotations or specific page
> alloc API. However, this has its own drawbacks in terms of code
> complexity (potentially outside mm/kmemleak.c) and overhead.
> 
> Regarding a kmemleak_alloc() annotation like in the patch I suggested,
> that's the second one I've seen needed outside alloc APIs (the first
> one is commit f75782e4e067 - "block: kmemleak: Track the page
> allocations for struct request"). If the number of such explicit
> annotations stays small, it's better to keep it this way.

Well, how do you define "small"? When is it ok and when do we say, no
more?

> There are other explicit annotations like kmemleak_not_leak() or
> kmemleak_ignore() but these are for objects kmemleak knows about and
> incorrectly reports them as leaks. Most of the time is because the
> pointers to such objects are stored in a different form (e.g. physical
> address).
> 
> Anyway, kmemleak is not the only tool requiring annotations (take
> spin_lock_nested() for example).

Yeah, and it doesn't look great. I know, it helps a lot and yadda
yadda...

> If needed, we could do with an additional page alloc/free API which
> informs kmemleak in the process but I don't think it's worth it.

Well, I think it is a big win if it gets to keep the code clean. And we
don't care about performance with kmemleak - it is a performance hit
anyway but we take that hit for a reason.

Again, I'm not attacking kmemleak or any other tool for that matter -
I just want for tools to be honest: if kmemleak cannot classify that
pointer and until it is able to do so, it should be quiet about it
because, well, honestly, it doesn't really know.

All that annotation coming with every new tool is simply annoying and
obscures the code so perhaps we should aim at keeping it close to 0. I
hope you're catching my drift exactly as I intended. If not, I'll gladly
reiterate.

Thanks.

-- 
Regards/Gruss,
Boris.

ECO tip #101: Trim your mails when you reply.
--
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/

xfstests failures with xfs, dax and v4.4-rc3

[Ross Zwisler]

I'm hitting a few more test failures in my testing setup with v4.4-rc3, xfs
and DAX.  My test setup is a pair of 4GiB PMEM partitions in a KVM virtual
machine.  Here are the failures:

# ./check generic/256 generic/274 xfs/041
FSTYP -- xfs (debug)
PLATFORM  -- Linux/x86_64 alara 4.4.0-rc3
MKFS_OPTIONS  -- -f -bsize=4096 /dev/pmem0p2
MOUNT_OPTIONS -- -o dax -o context=system_u:object_r:nfs_t:s0 /dev/pmem0p2 
/mnt/xfstests_scratch

generic/256 43s ... - output mismatch (see 
/root/xfstests/results//generic/256.out.bad)
--- tests/generic/256.out   2015-10-02 10:19:36.807795900 -0600
+++ /root/xfstests/results//generic/256.out.bad 2015-12-02 
11:22:34.838845475 -0700
@@ -1 +1,500 @@
 QA output created by 256
+fallocate: No space left on device
+fallocate: No space left on device
+fallocate: No space left on device
+fallocate: No space left on device
+fallocate: No space left on device
+fallocate: No space left on device
...
(Run 'diff -u tests/generic/256.out 
/root/xfstests/results//generic/256.out.bad'  to see the entire diff)
generic/274 7s ... [failed, exit status 1] - output mismatch (see 
/root/xfstests/results//generic/274.out.bad)
--- tests/generic/274.out   2015-10-02 10:19:36.808795907 -0600
+++ /root/xfstests/results//generic/274.out.bad 2015-12-02 
11:22:37.656868990 -0700
@@ -2,4 +2,5 @@
 --
 preallocation test
 --
-done
+failed to write to test file
+(see /root/xfstests/results//generic/274.full for details)
...
(Run 'diff -u tests/generic/274.out 
/root/xfstests/results//generic/274.out.bad'  to see the entire diff)
xfs/041 14s ... [failed, exit status 1] - output mismatch (see 
/root/xfstests/results//xfs/041.out.bad)
--- tests/xfs/041.out   2015-10-02 10:19:36.818795975 -0600
+++ /root/xfstests/results//xfs/041.out.bad 2015-12-02 11:22:42.553909854 
-0700
@@ -4,16 +4,5 @@
 Grow filesystem to 33m... done
 Flush filesystem... done
 Check files... done
-Fill filesystem... done
-Grow filesystem to 67m... done
-Flush filesystem... done
-Check files... done
...
(Run 'diff -u tests/xfs/041.out /root/xfstests/results//xfs/041.out.bad'  
to see the entire diff)
Ran: generic/256 generic/274 xfs/041
Failures: generic/256 generic/274 xfs/041
Failed 3 of 3 tests

The .bad files are attached to this mail.

These three tests pass 100% of the time with and without DAX using v4.3, pass
100% of the time with v4.4-rc3 without DAX, and fail 100% of the time with
v4.4-rc3 with DAX enabled.

I did try doubling the size of my ramdisk partition to see if that made any
difference, and the failure was still present.

I'm using xfsprogs v4.3.0.

Please let me know if you have any other questions about how to reproduce the
failure.  I'm also happy to test patches.

Thanks,
- Ross
QA output created by 041
Make 32 megabyte filesystem on SCRATCH_DEV and mount... done
Fill filesystem... done
Grow filesystem to 33m... done
Flush filesystem... done
Check files... done
Fill filesystem... fail
src/fill2fs --verbose --dir=/mnt/xfstests_scratch/fill_67 --seed=0 
--filesize=65536 --stddev=32768 --list=- >>/tmp/32491.manifest failed (returned 
1): see /root/xfstests/results//xfs/041.full
QA output created by 256
fallocate: No space left on device
fallocate: No space left on device
fallocate: No space left on device
fallocate: No space left on device
fallocate: No space left on device
fallocate: No space left on device
fallocate: No space left on device
fallocate: No space left on device
fallocate: No space left on device
fallocate: No space left on device
fallocate: No space left on device
fallocate: No space left on device
fallocate: No space left on device
fallocate: No space left on device
fallocate: No space left on device
fallocate: No space left on device
fallocate: No space left on device
fallocate: No space left on device
fallocate: No space left on device
fallocate: No space left on device
fallocate: No space left on device
fallocate: No space left on device
fallocate: No space left on device
fallocate: No space left on device
fallocate: No space left on device
fallocate: No space left on device
fallocate: No space left on device
fallocate: No space left on device
fallocate: No space left on device
fallocate: No space left on device
fallocate: No space left on device
fallocate: No space left on device
fallocate: No space left on device
fallocate: No space left on device
fallocate: No space left on device
fallocate: No space left on device
fallocate: No space left on device
fallocate: No space left on device
fallocate: No space left on device
fallocate: No space left on device
fallocate: No space left on device
fallocate: No space left on device
fallocate: No space left on device
fallocate: No space left on device
fallocate: No space left on device
fallocate: No space left on device
fallocate: No space left 

Re: [PATCH v10 1/5] configfs: Allow dynamic group creation

[Jonathan Cameron]

On 29/11/15 17:27, Jonathan Cameron wrote:
> On 18/11/15 07:33, Jonathan Cameron wrote:
>>
>>
>> On 17 November 2015 23:47:16 GMT+00:00, Andrew Morton 
>>  wrote:
>>> On Sun, 15 Nov 2015 10:39:08 + Jonathan Cameron 
>>> wrote:
>>>
 On 11/11/15 06:43, Jonathan Cameron wrote:
>
>
> On 10 November 2015 21:12:37 GMT+00:00, Andrew Morton
>>>  wrote:
>> On Tue, 10 Nov 2015 07:51:26 +0100 Christoph Hellwig 
>> wrote:
>>
>>> is this simple addition something you could still send on to
>>> Linus
>>> for this merge window?  I would make my life easier to have it in
>>> so I could start using it in patches for various trees in the
>>> next
>>> merge window.
>>
>> It's super late, but the configfs changes are obviously safe to
>> existing code.
>>
>> What about the IIO changes?  Will someone be merging them for
>>> 4.5-rc1,
>> or something else?
> Yes. I'll take the IIO bits and ultimately they'll go through Greg
>>> KH for the 4.5 
> merge window.
>
 Hi Andrew,

 Just taken a quick look at your mmotm list and see this ended up in
>>> the
 mainline later group (fair enough given the timing!).
 As such shall we fall back to plan b) a special git branch pulled
>>> into the trees
 of anyone who cares?

 I'll base such a tree on some obvious point in Linus' tree (either
>>> 4.4 or 4.5-rc1)
 That way I can get the IIO stuff queued up asap and we can build on
>>> that going
 forward during this cycle.
>>>
>>> I plan to send configfs-allow-dynamic-group-creation.patch to Linus
>>> this week.  I'll retain 
>>>
>>> iio-core-introduce-iio-configfs-support.patch
>>> iio-core-introduce-iio-software-triggers.patch
>>> iio-core-introduce-iio-software-triggers-fix.patch
>>> iio-trigger-introduce-iio-hrtimer-based-trigger.patch
>>> iio-documentation-add-iio-configfs-documentation.patch
>>>
>>> with a view to dropping them once I see them turn up in linux-next.
>>
>> That's great. Thanks.
> I've now applied the rest of the series to my local togreg branch and pushed
> out as testing for the autobuilders to play with them.
> 
> This branch will get rebased once Greg has picked up the previous PULL 
> request.
Now rebased - I also made a tiny change to take the iio_configfs_subsys
structure static in response to a sparse warning - shout if I've done
anything silly.


> 
> Thanks,
> 
> Jonathan
>>
>> Jonathan
>>
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

--
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: 4.4rc3 nfsd/btrfs kasan warning.

[Andrey Ryabinin]

2015-12-02 20:14 GMT+03:00 Chris Mason :
> On Wed, Dec 02, 2015 at 11:09:43AM -0500, Dave Jones wrote:
>> On Wed, Dec 02, 2015 at 10:11:28AM -0500, Josef Bacik wrote:
>>  > On 12/02/2015 09:59 AM, Dave Jones wrote:
>>  > > Got a few of these in the logs this morning after an overnight rsync 
>> over nfs
>>  > > to an exported btrfs volume.
>>  >
>>  > That's probably us and not NFS, what line is that in
>>  > setup_cluster_bitmap?  Thanks,
>>
>> If my math is correct, it's this..
>>
>> if (entry->offset != bitmap_offset)
>>
>> I don't seem to be able to trigger it on demand unfortunatly.
>
> Is it possible we're blowing the stack?  It seems pretty tricky to get a
> stack out of bounds out of this code without flat out blowing through
> it.
>

I think it just empty bitmaps list.
 list_first_entry() can't be used on empty list.

BTW, there is similar report
http://lkml.kernel.org/r/
--
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] mm: Fix mmap MAP_POPULATE for DAX pmd mapping

[Toshi Kani]

On Wed, 2015-12-02 at 10:06 -0800, Dan Williams wrote:
> On Wed, Dec 2, 2015 at 9:01 AM, Dan Williams  wrote:
> > On Wed, Dec 2, 2015 at 9:43 AM, Toshi Kani  wrote:
> > > Oh, I see.  I will setup the memmap array and run the tests again.
> > > 
> > > But, why does the PMD mapping depend on the memmap array?  We have 
> > > observed major performance improvement with PMD.  This feature should 
> > > always be enabled with DAX regardless of the option to allocate the memmap
> > > array.
> > > 
> > 
> > Several factors drove this decision, I'm open to considering
> > alternatives but here's the reasoning:
> > 
> > 1/ DAX pmd mappings caused crashes in the get_user_pages path leading
> > to commit e82c9ed41e8 "dax: disable pmd mappings".  The reason pte
> > mappings don't crash and instead trigger -EFAULT is due to the
> > _PAGE_SPECIAL pte bit.
> > 
> > 2/ To enable get_user_pages for DAX, in both the page and huge-page
> > case, we need a new pte bit _PAGE_DEVMAP.
> > 
> > 3/ Given the pte bits are hard to come I'm assuming we won't get two,
> > i.e. both _PAGE_DEVMAP and a new _PAGE_SPECIAL for pmds.  Even if we
> > could get a _PAGE_SPECIAL for pmds I'm not in favor of pursuing it.
> 
> Actually, Dave says they aren't that hard to come by for pmds, so we
> could go add _PMD_SPECIAL if we really wanted to support the limited
> page-less DAX-pmd case.
> 
> But I'm still of the opinion that we run away from the page-less case
> until it can be made a full class citizen with O_DIRECT for pfn
> support.

I may be missing something, but per vm_normal_page(), I think _PAGE_SPECIAL can
be substituted by the following check when we do not have the memmap.

if ((vma->vm_flags & VM_PFNMAP) ||
((vma->vm_flags & VM_MIXEDMAP) && (!pfn_valid(pfn {

This is what I did in this patch for follow_trans_huge_pmd(), although I missed
the pfn_valid() check.

Thanks,
-Toshi
--
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 v1 2/2] perf/x86: add cycles:pp alias for Intel Atom

[Stephane Eranian]

This patch updates the PEBS support for Intel Atom to provide
an alias for the cycles:pp event used by perf record/top by default
nowadays.

On Atom only INST_RETIRED:ANY supports PEBS, so we use this event
instead with a large cmask to count cycles.

Signed-off-by: Stephane Eranian 
---
 arch/x86/kernel/cpu/perf_event_intel.c| 30 ++
 arch/x86/kernel/cpu/perf_event_intel_ds.c |  2 ++
 2 files changed, 32 insertions(+)

diff --git a/arch/x86/kernel/cpu/perf_event_intel.c 
b/arch/x86/kernel/cpu/perf_event_intel.c
index 61f2577..7ff1e30 100644
--- a/arch/x86/kernel/cpu/perf_event_intel.c
+++ b/arch/x86/kernel/cpu/perf_event_intel.c
@@ -2475,6 +2475,35 @@ static void intel_pebs_aliases_snb(struct perf_event 
*event)
}
 }
 
+static void intel_pebs_aliases_atom(struct perf_event *event)
+{
+   if ((event->hw.config & X86_RAW_EVENT_MASK) == 0x003c) {
+   /*
+* Use an alternative encoding for CPU_CLK_UNHALTED.THREAD_P
+* (0x003c) so that we can use it with PEBS.
+*
+* The regular CPU_CLK_UNHALTED.THREAD_P event (0x003c) isn't
+* PEBS capable. However we can use UOPS_RETIRED.ALL
+* (0x01c2), which is a PEBS capable event, to get the same
+* count.
+*
+* INST_RETIRED.ANY counts the number of cycles that retires
+* CNTMASK instructions. By setting CNTMASK to a value (16)
+* larger than the maximum number of instructions that can be
+* retired per cycle (4) and then inverting the condition, we
+* count all cycles that retire 16 or less instructions, which
+* is every cycle.
+*
+* Thereby we gain a PEBS capable cycle counter.
+*/
+   u64 alt_config = X86_CONFIG(.event=0xc0, .umask=0x00, .inv=1, 
.cmask=16);
+
+   alt_config |= (event->hw.config & ~X86_RAW_EVENT_MASK);
+   event->hw.config = alt_config;
+   }
+}
+
+
 static unsigned long intel_pmu_free_running_flags(struct perf_event *event)
 {
unsigned long flags = x86_pmu.free_running_flags;
@@ -3332,6 +3361,7 @@ __init int intel_pmu_init(void)
 
x86_pmu.event_constraints = intel_gen_event_constraints;
x86_pmu.pebs_constraints = intel_atom_pebs_event_constraints;
+   x86_pmu.pebs_aliases = intel_pebs_aliases_atom;
pr_cont("Atom events, ");
break;
 
diff --git a/arch/x86/kernel/cpu/perf_event_intel_ds.c 
b/arch/x86/kernel/cpu/perf_event_intel_ds.c
index dae5f93..1b748ee 100644
--- a/arch/x86/kernel/cpu/perf_event_intel_ds.c
+++ b/arch/x86/kernel/cpu/perf_event_intel_ds.c
@@ -620,6 +620,8 @@ struct event_constraint intel_atom_pebs_event_constraints[] 
= {
INTEL_FLAGS_EVENT_CONSTRAINT(0xcb, 0x1),/* MEM_LOAD_RETIRED.* */
/* INST_RETIRED.ANY_P, inv=1, cmask=16 (cycles:p). */
INTEL_FLAGS_EVENT_CONSTRAINT(0x108000c0, 0x01),
+   /* Allow all events as PEBS with no flags */
+   INTEL_ALL_EVENT_CONSTRAINT(0, 0x1),
EVENT_CONSTRAINT_END
 };
 
-- 
2.5.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/

Re: [PATCH v3 14/19] irqchip/mips-gic: Use gic_vpes instead of NR_CPUS

[Sergei Shtylyov]

Hello.

On 12/02/2015 03:21 PM, Qais Yousef wrote:


NR_CPUS is set by Kconfig and could be much higher than what actually is in the
system.

gic_vpes should be a true representitives of the number of cpus in the system,
so use it instead.

Signed-off-by: Qais Yousef 
---
  drivers/irqchip/irq-mips-gic.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/irqchip/irq-mips-gic.c b/drivers/irqchip/irq-mips-gic.c
index 41ccc84c68ba..c24feb739bb3 100644
--- a/drivers/irqchip/irq-mips-gic.c
+++ b/drivers/irqchip/irq-mips-gic.c

[...]

@@ -1084,7 +1084,7 @@ static void __init __gic_init(unsigned long gic_base_addr,
gic_ipi_domain->bus_token = DOMAIN_BUS_IPI;

/* Make the last 2 * NR_CPUS available for IPIs */


   Looks like you forgot to also change this comment...


-   bitmap_set(ipi_resrv, gic_shared_intrs - 2 * NR_CPUS, 2 * NR_CPUS);
+   bitmap_set(ipi_resrv, gic_shared_intrs - 2 * gic_vpes, 2 * gic_vpes);

gic_basic_init();



MBR, Sergei

--
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 v1 0/2] perf/x86: fixes and improvement for Intel Atom PEBS support

[Stephane Eranian]

This short series fixes total breakage of Intel Atom PEBS support in recent 
kernels.
The problems were introduced with the changes in the PEBS logic to handle 
deeper buffer.

The first patch fixes PEBS and LBR problems, including NULL pointers, wrong 
pointer
arithmetic, and wrong pebs record layout assumption.

The second patch adds an alias for cycles:pp to Intel Atom given that perf 
record/top
uses cycles:pp nowadays.

Stephane Eranian (2):
  perf/x86: fix PEBS and LBR issues on Intel Atom
  perf/x86: enable cycles:pp for Intel Atom

 arch/x86/kernel/cpu/perf_event_intel.c | 30 ++
 arch/x86/kernel/cpu/perf_event_intel_ds.c  | 11 ++-
 arch/x86/kernel/cpu/perf_event_intel_lbr.c | 11 +++
 3 files changed, 47 insertions(+), 5 deletions(-)

-- 
2.5.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 v1 1/2] perf/x86: fix PEBS and LBR issues on Intel Atom

[Stephane Eranian]

This patches fixes a number of problems in the PEBS
and LBR support of Intel Atom. Those bugs were introduced
by the recent changes to the PEBS code to handle multiple
entries.

The kernel was assuming that if the CPU support 64-bit format
LBR, then it has an LBR_SELECT MSR. Atom uses 64-bit LBR format
but does not have LBR_SELECT. That was causing NULL pointer
dereferences in a couple of places.

The kernel had a pointer arithmetic error in intel_pmu_drain_pebs_core()
when calculating the number of records present in the PEBS buffer.

The get_next_pebs_record_by_bit() was called on PEBS fm0 which does
not use the pebs_record_nhm layout.

This patch fixes all those problems and has PEBS and LBR working again.

Signed-off-by: Stephane Eranian 
---
 arch/x86/kernel/cpu/perf_event_intel_ds.c  |  9 -
 arch/x86/kernel/cpu/perf_event_intel_lbr.c | 11 +++
 2 files changed, 15 insertions(+), 5 deletions(-)

diff --git a/arch/x86/kernel/cpu/perf_event_intel_ds.c 
b/arch/x86/kernel/cpu/perf_event_intel_ds.c
index 5db1c77..dae5f93 100644
--- a/arch/x86/kernel/cpu/perf_event_intel_ds.c
+++ b/arch/x86/kernel/cpu/perf_event_intel_ds.c
@@ -1101,6 +1101,13 @@ get_next_pebs_record_by_bit(void *base, void *top, int 
bit)
void *at;
u64 pebs_status;
 
+   /*
+* fmt0 does not have a status bitfield (does not use
+* perf_record_nhm format)
+*/
+   if (x86_pmu.intel_cap.pebs_format < 1)
+   return base;
+
if (base == NULL)
return NULL;
 
@@ -1186,7 +1193,7 @@ static void intel_pmu_drain_pebs_core(struct pt_regs 
*iregs)
if (!event->attr.precise_ip)
return;
 
-   n = (top - at) / x86_pmu.pebs_record_size;
+   n = top - at;
if (n <= 0)
return;
 
diff --git a/arch/x86/kernel/cpu/perf_event_intel_lbr.c 
b/arch/x86/kernel/cpu/perf_event_intel_lbr.c
index e2fad0c..1390148 100644
--- a/arch/x86/kernel/cpu/perf_event_intel_lbr.c
+++ b/arch/x86/kernel/cpu/perf_event_intel_lbr.c
@@ -161,7 +161,7 @@ static void __intel_pmu_lbr_enable(bool pmi)
 */
if (cpuc->lbr_sel)
lbr_select = cpuc->lbr_sel->config & x86_pmu.lbr_sel_mask;
-   if (!pmi)
+   if (!pmi && cpuc->lbr_sel)
wrmsrl(MSR_LBR_SELECT, lbr_select);
 
rdmsrl(MSR_IA32_DEBUGCTLMSR, debugctl);
@@ -430,7 +430,7 @@ static void intel_pmu_lbr_read_32(struct cpu_hw_events 
*cpuc)
  */
 static void intel_pmu_lbr_read_64(struct cpu_hw_events *cpuc)
 {
-   bool need_info = !(cpuc->lbr_sel->config & LBR_NO_INFO);
+   bool need_info = false;
unsigned long mask = x86_pmu.lbr_nr - 1;
int lbr_format = x86_pmu.intel_cap.lbr_format;
u64 tos = intel_pmu_lbr_tos();
@@ -438,8 +438,11 @@ static void intel_pmu_lbr_read_64(struct cpu_hw_events 
*cpuc)
int out = 0;
int num = x86_pmu.lbr_nr;
 
-   if (cpuc->lbr_sel->config & LBR_CALL_STACK)
-   num = tos;
+   if (cpuc->lbr_sel) {
+   need_info = !(cpuc->lbr_sel->config & LBR_NO_INFO);
+   if (cpuc->lbr_sel->config & LBR_CALL_STACK)
+   num = tos;
+   }
 
for (i = 0; i < num; i++) {
unsigned long lbr_idx = (tos - i) & mask;
-- 
2.5.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/

Re: [PATCH v2 0/3] tpm_tis: Clean up force module parameter

[Jason Gunthorpe]

On Tue, Dec 01, 2015 at 11:33:51PM +0200, Jarkko Sakkinen wrote:
> On Tue, Dec 01, 2015 at 11:58:26AM -0700, Jason Gunthorpe wrote:

> I went through the patches and didn't see anything that would shock me
> enough not to apply the patches in the current if they also work when
> tested *but* are these release critical for Linux v4.4?

Jarkko,

Can you explain how

commit 399235dc6e95400a1322ae92073bc572f0c8
Author: Jarkko Sakkinen 
Date:   Tue Sep 29 00:32:19 2015 +0300

tpm, tpm_tis: fix tpm_tis ACPI detection issue with TPM 2.0

Is supposed to work? I get the jist of the idea, but I'm not seeing
how it can work reliably..

The idea is to pass off TPM2_START_FIFO to tpm_tis?

I'm guessing that if the driver probe order is tpm_crb,tpm_tis then
things work because tpm_crb will claim the device first? Otherwise
tpm_tis claims these things unconditionally? If the probe order is
reversed things become broken?

What is the address tpm_tis should be using? I see two things, it
either uses the x86 default address or it expects the ACPI to have a
MEM resource. AFAIK ACPI should never rely on hard wired addresses, so
I removed that code in this series. Perhaps tpm_tis should be using
control_area_pa ? Will ACPI ever present a struct resource? (if yes,
why isn't tpm_crb using one?)

There is also something wrong with the endianness in the acpi
stuff. I don't see endianness conversions in other acpi places, so I
wonder if the ones in tpm_crb are correct. If they are correct then
the struct needs le/be notations and there are some missing
conversions.

Jason
--
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: Asterisk deadlocks since Kernel 4.1

[Hannes Frederic Sowa]

Hello,

On Wed, Dec 2, 2015, at 18:15, Philipp Hahn wrote:
> Hi,
> 
> Am 02.12.2015 um 10:45 schrieb Stefan Priebe - Profihost AG:
> > here are the results.
> > 
> > It works with 4.1.
> > It works with 4.2.
> > It does not work with 4.1.13.
> 
> the patches were first commitet in v4.3-rc3 and appear as backports only
> since v4.2.3 and v4.1.10
> 
> > git bisect tells me it stopped working after those two commits were applied:
> > 
> > commit d48623677191e0f035d7afd344f92cf880b01f8e
> > Author: Herbert Xu 
> > Date:   Tue Sep 22 11:38:56 2015 +0800
> > 
> > netlink: Replace rhash_portid with bound
> > 
> > commit 4e27762417669cb459971635be550eb7b5598286
> > Author: Herbert Xu 
> > Date:   Fri Sep 18 19:16:50 2015 +0800
> > 
> > netlink: Fix autobind race condition that leads to zero port ID
> 
> I identified the same two patches for our prpblem; see mail from
> 2015-11-17 16:53 with subject "Strange PF_NETLINK NETLINK_ROUTE stall:
> netlink: Fix autobind race condition that leads to zero port ID"
> 
> 

Thanks, I missed this mail. I have a further look. I couldn't reproduce
it myself but will check if your test program does it.

Thanks a lot,
Hannes
--
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: Regression, was [PATCH 4/4] USB: host: ohci-at91: merge loops in ohci_hcd_at91_drv_probe

[Alexandre Belloni]

Hi Peter,

On 01/12/2015 at 18:17:16 +0100, Peter Rosin wrote :
> [] (ohci_hcd_at91_overcurrent_irq) from [] 
> (handle_irq_event_percpu+0x78/0x140)
> [] (handle_irq_event_percpu) from [] 
> (handle_irq_event+0x2c/0x40)
> [] (handle_irq_event) from [] 
> (handle_simple_irq+0x6c/0x80)
> [] (handle_simple_irq) from [] 
> (generic_handle_irq+0x2c/0x3c)
> [] (generic_handle_irq) from [] 
> (gpio_irq_handler+0xa4/0x12c)
> [] (gpio_irq_handler) from [] 
> (generic_handle_irq+0x2c/0x3c)
> [] (generic_handle_irq) from [] 
> (__handle_domain_irq+0x54/0xa8)
> [] (__handle_domain_irq) from [] (__irq_svc+0x40/0x54)
> [] (__irq_svc) from [] (__setup_irq+0x248/0x530)
> [] (__setup_irq) from [] (request_threaded_irq+0xc4/0x144)
> [] (request_threaded_irq) from [] 
> (ohci_hcd_at91_drv_probe+0x460/0x518)
> [] (ohci_hcd_at91_drv_probe) from [] 
> (platform_drv_probe+0x44/0xa4)
> [] (platform_drv_probe) from [] 
> (driver_probe_device+0x1fc/0x43c)
> [] (driver_probe_device) from [] 
> (__driver_attach+0x8c/0x90)
> [] (__driver_attach) from [] (bus_for_each_dev+0x6c/0xa0)
> [] (bus_for_each_dev) from [] (bus_add_driver+0x1d0/0x268)
> [] (bus_add_driver) from [] (driver_register+0x78/0xf8)
> [] (driver_register) from [] (do_one_initcall+0xb8/0x1f0)
> [] (do_one_initcall) from [] 
> (kernel_init_freeable+0x138/0x1d8)
> [] (kernel_init_freeable) from [] (kernel_init+0x8/0xe8)
> [] (kernel_init) from [] (ret_from_fork+0x14/0x2c)
> Code: e5916058 e1a08000 e3a04000 e2865008 (e5b50004)
> ---[ end trace e66fbc480972ac43 ]---
> Kernel panic - not syncing: Fatal exception in interrupt
> ---[ end Kernel panic - not syncing: Fatal exception in interrupt

I think I understood what happens. Can you try the following patch?

8<--
>From 402f8444bc92d218edc63dcc3c87459981a56c31 Mon Sep 17 00:00:00 2001
From: Alexandre Belloni 
Date: Wed, 2 Dec 2015 18:49:34 +0100
Subject: [PATCH] USB: host: ohci-at91: fix a crash in
 ohci_hcd_at91_overcurrent_irq

Signed-off-by: Alexandre Belloni 
---
 drivers/usb/host/ohci-at91.c | 11 +--
 1 file changed, 5 insertions(+), 6 deletions(-)

diff --git a/drivers/usb/host/ohci-at91.c b/drivers/usb/host/ohci-at91.c
index 342ffd140122..8c6e15bd6ff0 100644
--- a/drivers/usb/host/ohci-at91.c
+++ b/drivers/usb/host/ohci-at91.c
@@ -473,6 +473,8 @@ static int ohci_hcd_at91_drv_probe(struct platform_device 
*pdev)
if (!pdata)
return -ENOMEM;
 
+   pdev->dev.platform_data = pdata;
+
if (!of_property_read_u32(np, "num-ports", ))
pdata->ports = ports;
 
@@ -483,6 +485,7 @@ static int ohci_hcd_at91_drv_probe(struct platform_device 
*pdev)
 */
if (i >= pdata->ports) {
pdata->vbus_pin[i] = -EINVAL;
+   pdata->overcurrent_pin[i] = -EINVAL;
continue;
}
 
@@ -513,10 +516,8 @@ static int ohci_hcd_at91_drv_probe(struct platform_device 
*pdev)
}
 
at91_for_each_port(i) {
-   if (i >= pdata->ports) {
-   pdata->overcurrent_pin[i] = -EINVAL;
-   continue;
-   }
+   if (i >= pdata->ports)
+   break;
 
pdata->overcurrent_pin[i] =
of_get_named_gpio_flags(np, "atmel,oc-gpio", i, );
@@ -552,8 +553,6 @@ static int ohci_hcd_at91_drv_probe(struct platform_device 
*pdev)
}
}
 
-   pdev->dev.platform_data = pdata;
-
device_init_wakeup(>dev, 1);
return usb_hcd_at91_probe(_at91_hc_driver, pdev);
 }
-- 
2.5.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/

Re: [PATCH v2 0/4] Add online file check feature

[Pavel Machek]

On Wed 2015-10-28 14:25:57, Gang He wrote:
> When there are errors in the ocfs2 filesystem,
> they are usually accompanied by the inode number which caused the error.
> This inode number would be the input to fixing the file.
> One of these options could be considered:
> A file in the sys filesytem which would accept inode numbers.
> This could be used to communication back what has to be fixed or is fixed.
> You could write:
> $# echo "CHECK " > /sys/fs/ocfs2/devname/filecheck
> or
> $# echo "FIX " > /sys/fs/ocfs2/devname/filecheck
> 

Are you sure this is reasonable interface? I mean sysfs is
supposed to be one value per file. And I don't think its suitable for
running commands.

...or returning back results.
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
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 1/2] extcon: add driver for Intel USB mux

[David Cohen]

Hi Heikki,

On Wed, Dec 02, 2015 at 12:27:10PM +0200, Heikki Krogerus wrote:
> Hi David,
> 
> 
> 
> > > +void intel_usb_mux_unregister(struct intel_usb_mux *mux)
> > > +{
> > 
> > There are still 2 pending comments for this unregister function:
> > 
> > 1) How about a protection against unbalanced unregistering? In case an
> > user mistakenly unregisters twice or unregisters without a previous
> > registering.
> 
> True. You already pointed that out in our off-list thread, but I
> forgot. Sorry about that.
> 
> > 2) When unregistering, you need to clear the bit CFG0_SW_IDPIN_EN to
> > set mux to automatic mode again. Or maybe you could save CFG0's initial
> > value and set it again here. Anyway, when unregistering the mux driver
> > you need to make sure the mux goes back to its original configuration.
> 
> This one is already been taken care of..
> 
> > > + extcon_unregister_notifier(>edev, EXTCON_USB_HOST, >nb);
> > > + extcon_dev_unregister(>edev);
> > > + writel(mux->cfg0_ctx, mux->regs + INTEL_MUX_CFG0);
> 
> 

Of course :)
Sorry I missed this part.

Br, David
--
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/27] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms

[Brian Norris]

On Wed, Dec 02, 2015 at 07:03:17AM -0800, Tony Lindgren wrote:
> * Roger Quadros  [151201 21:13]:
> > On 02/12/15 08:56, Brian Norris wrote:
> > > 
> > > I'll take another pass over your patch set, but if things are looking
> > > better, how do you expect to merge this? There are significant portions
> > > that touch at least 2 or 3 different subsystem trees, AFAICT.
> > 
> > Tony could create an immutable branch with all the dts and memory changes.
> > You could base the mtd changes on top of that?
> 
> If we all agree on that it will be immutable Roger can set up the branch
> with our acks and we can all merge it in as needed. I believe v4.4-rc1
> should work as a base for us all?

There are oustanding comments about the NAND ready/busy GPIO naming in
patch 18, which I'd like addressed. I'll re-review the rest before the
end of the day (West Coast U.S.A.). I'm not sure my acks are worth much
beyond the MTD stuff.

Regarding branches, 4.4-rc1 is fine with me.

Regards,
Brian
--
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 1/2] clk: Add brcm,bcm63xx-gate-clk device tree binding

[Florian Fainelli]

2015-11-30 12:52 GMT-08:00 Simon Arlott :
> Add device tree binding for the BCM63xx's gated clocks.
>
> The BCM63xx contains clocks gated with a register. Clocks are indexed
> by bits in the register and are active high. Clock gate bits are
> interleaved with other status bits and configurable clocks in the same
> register.
>
> Signed-off-by: Simon Arlott 
> ---
>  .../bindings/clock/brcm,bcm63xx-gate-clk.txt   | 58 
> ++
>  1 file changed, 58 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/clock/brcm,bcm63xx-gate-clk.txt
>
> diff --git 
> a/Documentation/devicetree/bindings/clock/brcm,bcm63xx-gate-clk.txt 
> b/Documentation/devicetree/bindings/clock/brcm,bcm63xx-gate-clk.txt
> new file mode 100644
> index 000..3f4ead1
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/clock/brcm,bcm63xx-gate-clk.txt
> @@ -0,0 +1,58 @@
> +Broadcom BCM63xx clocks
> +
> +This binding uses the common clock binding:
> +   Documentation/devicetree/bindings/clock/clock-bindings.txt
> +
> +The BCM63xx contains clocks gated with a register. Clocks are indexed
> +by bits in the register and are active high. Clock gate bits are
> +interleaved with other status bits and configurable clocks in the same
> +register.

Most MIPS-based BCM63xx SoCs have clock gating set of registers, these
SoCs are pretty much all of them except 63381 (maybe newer ones too),
this one uses the PMB interface, like 63138 to control resets and
clocks fed to peripherals.

> +
> +Required properties:
> +- compatible:  Should be "brcm,bcm-gate-clk", "brcm,bcm63xx-gate-clk"

I think we would want to start with the lowest common denominator
here, which is either 6345 or 6348.
--
Florian
--
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 0/3] tpm_tis: Clean up force module parameter

[Jason Gunthorpe]

On Wed, Dec 02, 2015 at 01:34:38PM +0100, Wilck, Martin wrote:
> On Di, 2015-12-01 at 11:58 -0700, Jason Gunthorpe wrote:
> 
> > Martin, this should fix the double loading you noticed, please confirm.  
> > There
> > is a possibility the force path needs a bit more code to be compatible with
> > devm_ioremap_resource, I'm not sure, hoping not.
> 
> Nope, this one oopses in the ACPI probing path.

This fixes this oops:

chip->vendor.iobase = devm_ioremap_resource(dev, _info->res);
-   if (!chip->vendor.iobase)
-   return -EIO;
+   if (IS_ERR(chip->vendor.iobase))
+   return PTR_ERR(chip->vendor.iobase);


And I see that the ACPI stuff needs other work :(

Jason
--
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/2] clk: bcm63xx: Add BCM63xx gated clock support

[Florian Fainelli]

2015-11-30 12:54 GMT-08:00 Simon Arlott :
> The BCM63xx contains clocks gated with a register. Clocks are indexed
> by bits in the register and are active high. Clock gate bits are
> interleaved with other status bits and configurable clocks in the same
> register.
>
> Enabled by default for BMIPS_GENERIC.
>
> Signed-off-by: Simon Arlott 
> ---

[snip]

> +
> +config CLK_BCM63XX
> +   bool "Broadcom BCM63xx clock support"
> +   depends on BMIPS_GENERIC
> +   depends on COMMON_CLK
> +   default y

default BMIPS_GENERIC?

> +   help
> + Enable clock framework support for Broadcom 63xx SoCs
> diff --git a/drivers/clk/bcm/Makefile b/drivers/clk/bcm/Makefile
> index 3fc9506..4f5f8ce 100644
> --- a/drivers/clk/bcm/Makefile
> +++ b/drivers/clk/bcm/Makefile
> @@ -8,3 +8,4 @@ obj-$(CONFIG_COMMON_CLK_IPROC)  += clk-ns2.o
>  obj-$(CONFIG_ARCH_BCM_CYGNUS)  += clk-cygnus.o
>  obj-$(CONFIG_ARCH_BCM_NSP) += clk-nsp.o
>  obj-$(CONFIG_ARCH_BCM_5301X)   += clk-nsp.o
> +obj-$(CONFIG_CLK_BCM63XX)  += clk-bcm63xx.o
> diff --git a/drivers/clk/bcm/clk-bcm63xx.c b/drivers/clk/bcm/clk-bcm63xx.c
> new file mode 100644
> index 000..0e8cc06
> --- /dev/null
> +++ b/drivers/clk/bcm/clk-bcm63xx.c

There is a pending clk-bcm63xx.c implementation, covering BCM63138 in
Stephen Boyd's clk/next tree, which you would want to base your
patches on, it is not a huge deal to resolve the conflict, and there
will be separate entry points and functions based on the compatible
string anyway...

> @@ -0,0 +1,187 @@
> +/*
> + * Copyright 2015 Simon Arlott
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * Based on clk-gate.c:
> + * Copyright (C) 2010-2011 Canonical Ltd 
> + * Copyright (C) 2011-2012 Mike Turquette, Linaro Ltd 
> + */

I am not really anything very specific to 63xx chips in there, in
fact, this looks like a fairly generic clk-gate driver using regmap to
get its masks and offsets, would it make sense to create
clk-gate-regmap.c which exposes the bulk of what you are doing and you
could match using a specific compatible string?
--
Florian
--
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] mm: Fix mmap MAP_POPULATE for DAX pmd mapping

[Dan Williams]

On Wed, Dec 2, 2015 at 9:01 AM, Dan Williams  wrote:
> On Wed, Dec 2, 2015 at 9:43 AM, Toshi Kani  wrote:
>> Oh, I see.  I will setup the memmap array and run the tests again.
>>
>> But, why does the PMD mapping depend on the memmap array?  We have observed
>> major performance improvement with PMD.  This feature should always be 
>> enabled
>> with DAX regardless of the option to allocate the memmap array.
>>
>
> Several factors drove this decision, I'm open to considering
> alternatives but here's the reasoning:
>
> 1/ DAX pmd mappings caused crashes in the get_user_pages path leading
> to commit e82c9ed41e8 "dax: disable pmd mappings".  The reason pte
> mappings don't crash and instead trigger -EFAULT is due to the
> _PAGE_SPECIAL pte bit.
>
> 2/ To enable get_user_pages for DAX, in both the page and huge-page
> case, we need a new pte bit _PAGE_DEVMAP.
>
> 3/ Given the pte bits are hard to come I'm assuming we won't get two,
> i.e. both _PAGE_DEVMAP and a new _PAGE_SPECIAL for pmds.  Even if we
> could get a _PAGE_SPECIAL for pmds I'm not in favor of pursuing it.

Actually, Dave says they aren't that hard to come by for pmds, so we
could go add _PMD_SPECIAL if we really wanted to support the limited
page-less DAX-pmd case.

But I'm still of the opinion that we run away from the page-less case
until it can be made a full class citizen with O_DIRECT for pfn
support.
--
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.19.y-ckt 004/164] drm/radeon: add quirk for ASUS R7 370

[Kamal Mostafa]

3.19.8-ckt11 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Alex Deucher 

commit 2b02ec79004388a8c65e227bc289ed891b5ac8c6 upstream.

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

Signed-off-by: Alex Deucher 
Signed-off-by: Kamal Mostafa 
---
 drivers/gpu/drm/radeon/si_dpm.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/radeon/si_dpm.c b/drivers/gpu/drm/radeon/si_dpm.c
index c884df8..d67ce4c 100644
--- a/drivers/gpu/drm/radeon/si_dpm.c
+++ b/drivers/gpu/drm/radeon/si_dpm.c
@@ -2924,6 +2924,7 @@ static struct si_dpm_quirk si_dpm_quirk_list[] = {
{ PCI_VENDOR_ID_ATI, 0x6811, 0x174b, 0xe271, 0, 12 },
{ PCI_VENDOR_ID_ATI, 0x6810, 0x174b, 0xe271, 85000, 9 },
{ PCI_VENDOR_ID_ATI, 0x6811, 0x1762, 0x2015, 0, 12 },
+   { PCI_VENDOR_ID_ATI, 0x6811, 0x1043, 0x2015, 0, 12 },
{ 0, 0, 0, 0 },
 };
 
-- 
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 3.19.y-ckt 009/164] macvtap: unbreak receiving of gro skb with frag list

[Kamal Mostafa]

3.19.8-ckt11 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Jason Wang 

[ Upstream commit f23d538bc24a83c16127c2eb82c9cf1adc2b5149 ]

We don't have fraglist support in TAP_FEATURES. This will lead
software segmentation of gro skb with frag list. Fixes by having
frag list support in TAP_FEATURES.

With this patch single session of netperf receiving were restored from
about 5Gb/s to about 12Gb/s on mlx4.

Fixes a567dd6252 ("macvtap: simplify usage of tap_features")
Cc: Vlad Yasevich 
Cc: Michael S. Tsirkin 
Signed-off-by: Jason Wang 
Signed-off-by: David S. Miller 
Signed-off-by: Kamal Mostafa 
---
 drivers/net/macvtap.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/macvtap.c b/drivers/net/macvtap.c
index 84e835e..73437568 100644
--- a/drivers/net/macvtap.c
+++ b/drivers/net/macvtap.c
@@ -82,7 +82,7 @@ static const struct proto_ops macvtap_socket_ops;
 #define TUN_OFFLOADS (NETIF_F_HW_CSUM | NETIF_F_TSO_ECN | NETIF_F_TSO | \
  NETIF_F_TSO6 | NETIF_F_UFO)
 #define RX_OFFLOADS (NETIF_F_GRO | NETIF_F_LRO)
-#define TAP_FEATURES (NETIF_F_GSO | NETIF_F_SG)
+#define TAP_FEATURES (NETIF_F_GSO | NETIF_F_SG | NETIF_F_FRAGLIST)
 
 static struct macvlan_dev *macvtap_get_vlan_rcu(const struct net_device *dev)
 {
-- 
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/

[3.19.y-ckt stable] Linux 3.19.8-ckt11 stable review

[Kamal Mostafa]

This is the start of the review cycle for the Linux 3.19.8-ckt11 stable kernel.

This version contains 164 new patches, summarized below.  The new patches are
posted as replies to this message and also available in this git branch:

http://kernel.ubuntu.com/git/ubuntu/linux.git/log/?h=linux-3.19.y-review

git://kernel.ubuntu.com/ubuntu/linux.git  linux-3.19.y-review

The review period for version 3.19.8-ckt11 will be open for the next three days.
To report a problem, please reply to the relevant follow-up patch message.

For more information about the Linux 3.19.y-ckt extended stable kernel version,
see https://wiki.ubuntu.com/Kernel/Dev/ExtendedStable .

 -Kamal

--
 .../devicetree/bindings/mmc/renesas,mmcif.txt  |   4 +-
 Documentation/devicetree/bindings/usb/dwc3.txt |   2 +
 Documentation/filesystems/proc.txt |   5 +-
 MAINTAINERS|   1 +
 arch/arm/common/edma.c |   6 +-
 arch/arm/mach-pxa/include/mach/pxa27x.h|   2 +-
 arch/arm/mach-pxa/pxa27x.c |   2 +-
 arch/arm/mach-tegra/board-paz00.c  |   4 +-
 arch/arm/mm/dma-mapping.c  |   7 +
 arch/arm64/include/asm/ptrace.h|  16 +-
 arch/arm64/net/bpf_jit.h   |   3 +-
 arch/arm64/net/bpf_jit_comp.c  |  54 --
 arch/mips/include/asm/atomic.h |   2 +-
 arch/parisc/include/asm/compat.h   |   4 +-
 arch/parisc/include/uapi/asm/ipcbuf.h  |  19 +-
 arch/parisc/include/uapi/asm/msgbuf.h  |  10 +-
 arch/parisc/include/uapi/asm/posix_types.h |   2 +
 arch/parisc/include/uapi/asm/sembuf.h  |   6 +-
 arch/parisc/include/uapi/asm/shmbuf.h  |   8 +-
 arch/parisc/mm/init.c  |  16 ++
 arch/s390/kvm/kvm-s390.c   |   4 +-
 arch/sparc/kernel/pci.c|   7 +-
 arch/sparc/kernel/pci_common.c |  17 +-
 arch/sparc/kernel/pci_impl.h   |   1 +
 arch/x86/crypto/crc32c-pcl-intel-asm_64.S  |   2 +-
 arch/x86/include/uapi/asm/svm.h|   1 +
 arch/x86/kernel/head_64.S  |   8 +
 arch/x86/kernel/setup.c|   8 +
 arch/x86/kernel/verify_cpu.S   |  12 +-
 arch/x86/kvm/svm.c |  22 +--
 arch/x86/kvm/vmx.c |  24 +--
 arch/xtensa/include/asm/asmmacro.h |   7 +-
 arch/xtensa/include/asm/vectors.h  |   9 +-
 arch/xtensa/kernel/Makefile|   1 +
 arch/xtensa/kernel/entry.S |   8 +-
 arch/xtensa/kernel/head.S  |   2 +-
 arch/xtensa/kernel/setup.c |   9 +-
 arch/xtensa/kernel/vectors.S   |   4 +-
 arch/xtensa/kernel/vmlinux.lds.S   |  12 +-
 arch/xtensa/lib/usercopy.S |   6 +-
 arch/xtensa/platforms/iss/setup.c  |   2 +
 arch/xtensa/platforms/xt2000/setup.c   |   2 +
 arch/xtensa/platforms/xtfpga/setup.c   |   2 +
 crypto/algif_hash.c|  12 +-
 drivers/acpi/osl.c |  13 +-
 drivers/acpi/sleep.c   |   6 +-
 drivers/bluetooth/ath3k.c  |   4 +
 drivers/bluetooth/btusb.c  |   2 +
 drivers/char/tpm/tpm_ibmvtpm.c |   2 +-
 drivers/char/tpm/tpm_of.c  |   3 +-
 drivers/clk/versatile/clk-icst.c   |   4 +-
 drivers/dma/dw/core.c  |  12 +-
 drivers/firewire/ohci.c|   5 +
 drivers/gpu/drm/ast/ast_drv.h  |   1 +
 drivers/gpu/drm/ast/ast_fb.c   |   7 +
 drivers/gpu/drm/ast/ast_main.c |   1 +
 drivers/gpu/drm/ast/ast_mode.c |   2 +
 drivers/gpu/drm/drm_crtc.c |   5 +-
 drivers/gpu/drm/i915/intel_display.c   |   3 +
 drivers/gpu/drm/radeon/si_dpm.c|   2 +
 drivers/hid/hid-core.c |   2 +-
 drivers/hsi/controllers/omap_ssi_port.c|   2 +-
 drivers/hsi/hsi.c  |   1 -
 drivers/i2c/busses/i2c-img-scb.c   |  71 +---
 drivers/input/mouse/elantech.c |   7 +
 drivers/iommu/intel-iommu.c|   9 +-
 drivers/md/dm-mpath.c  |   7 +-
 drivers/media/platform/vivid/vivid-core.c  |   5 +-
 drivers/media/v4l2-core/v4l2-compat-ioctl32.c  |   9 +-
 drivers/media/v4l2-core/v4l2-ctrls.c   |  12 +-
 drivers/media/v4l2-core/videobuf2-dma-contig.c |   5 +-
 

Re: [PATCH 2/2] reset: bcm63xx: Add support for the BCM63xx soft-reset controller

[Florian Fainelli]

2015-11-30 12:58 GMT-08:00 Simon Arlott :
> The BCM63xx contains a soft-reset controller activated by setting
> a bit (that must previously have cleared).
>
> Signed-off-by: Simon Arlott 
> ---
>  MAINTAINERS   |   1 +
>  drivers/reset/Kconfig |   9 +++
>  drivers/reset/Makefile|   1 +
>  drivers/reset/reset-bcm63xx.c | 134 
> ++
>  4 files changed, 145 insertions(+)
>  create mode 100644 drivers/reset/reset-bcm63xx.c


Could you create a bcm directory and then add your reset-bcm63xx.c
file there? I have a pending submission for the BCM63138 reset
controller which is not at all using the same structure and will share
nothing with your driver.

[snip]

> +static int bcm63xx_reset_xlate(struct reset_controller_dev *rcdev,
> +   const struct of_phandle_args *reset_spec)
> +{
> +   struct bcm63xx_reset_priv *priv = to_bcm63xx_reset_priv(rcdev);
> +
> +   if (WARN_ON(reset_spec->args_count != rcdev->of_reset_n_cells))
> +   return -EINVAL;
> +
> +   if (reset_spec->args[0] >= rcdev->nr_resets)
> +   return -EINVAL;

Should not these two things be moved to the core reset controller code
based on the #reset-cells value?

[snip]

> +   if (of_property_read_u32(np, "offset", >offset))
> +   return -EINVAL;
> +
> +   /* valid reset bits */
> +   if (of_property_read_u32(np, "mask", >mask))
> +   priv->mask = 0x;
> +
> +   priv->rcdev.owner = THIS_MODULE;
> +   priv->rcdev.ops = _reset_ops;
> +   priv->rcdev.nr_resets = 32;

Should not that come from Device Tree, or be computed based on the
mask property, like hweight_long() or something along these lines?

> +   priv->rcdev.of_node = pdev->dev.of_node;
> +   priv->rcdev.of_reset_n_cells = 1;
> +   priv->rcdev.of_xlate = bcm63xx_reset_xlate;

-- 
Florian
--
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.19.y-ckt 010/164] RDS-TCP: Recover correctly from pskb_pull()/pksb_trim() failure in rds_tcp_data_recv

[Kamal Mostafa]

3.19.8-ckt11 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Sowmini Varadhan 

[ Upstream commit 8ce675ff39b9958d1c10f86cf58e357efaafc856 ]

Either of pskb_pull() or pskb_trim() may fail under low memory conditions.
If rds_tcp_data_recv() ignores such failures, the application will
receive corrupted data because the skb has not been correctly
carved to the RDS datagram size.

Avoid this by handling pskb_pull/pskb_trim failure in the same
manner as the skb_clone failure: bail out of rds_tcp_data_recv(), and
retry via the deferred call to rds_send_worker() that gets set up on
ENOMEM from rds_tcp_read_sock()

Signed-off-by: Sowmini Varadhan 
Acked-by: Santosh Shilimkar 
Signed-off-by: David S. Miller 
Signed-off-by: Kamal Mostafa 
---
 net/rds/tcp_recv.c | 11 +--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/net/rds/tcp_recv.c b/net/rds/tcp_recv.c
index fbc5ef8..27a9921 100644
--- a/net/rds/tcp_recv.c
+++ b/net/rds/tcp_recv.c
@@ -214,8 +214,15 @@ static int rds_tcp_data_recv(read_descriptor_t *desc, 
struct sk_buff *skb,
}
 
to_copy = min(tc->t_tinc_data_rem, left);
-   pskb_pull(clone, offset);
-   pskb_trim(clone, to_copy);
+   if (!pskb_pull(clone, offset) ||
+   pskb_trim(clone, to_copy)) {
+   pr_warn("rds_tcp_data_recv: pull/trim failed "
+   "left %zu data_rem %zu skb_len %d\n",
+   left, tc->t_tinc_data_rem, skb->len);
+   kfree_skb(clone);
+   desc->error = -ENOMEM;
+   goto out;
+   }
skb_queue_tail(>ti_skb_list, clone);
 
rdsdebug("skb %p data %p len %d off %u to_copy %zu -> "
-- 
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 3.19.y-ckt 007/164] tipc: allow non-linear first fragment buffer

[Kamal Mostafa]

3.19.8-ckt11 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Jon Paul Maloy 

[ Upstream commit 45c8b7b175ceb2d542e0fe15247377bf3bce29ec ]

The current code for message reassembly is erroneously assuming that
the the first arriving fragment buffer always is linear, and then goes
ahead resetting the fragment list of that buffer in anticipation of
more arriving fragments.

However, if the buffer already happens to be non-linear, we will
inadvertently drop the already attached fragment list, and later
on trig a BUG() in __pskb_pull_tail().

We see this happen when running fragmented TIPC multicast across UDP,
something made possible since
commit d0f91938bede ("tipc: add ip/udp media type")

We fix this by not resetting the fragment list when the buffer is non-
linear, and by initiatlizing our private fragment list tail pointer to
the tail of the existing fragment list.

Fixes: commit d0f91938bede ("tipc: add ip/udp media type")
Signed-off-by: Jon Maloy 
Signed-off-by: David S. Miller 
Signed-off-by: Kamal Mostafa 
---
 net/tipc/msg.c | 12 +---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/net/tipc/msg.c b/net/tipc/msg.c
index a687b30..2baa992 100644
--- a/net/tipc/msg.c
+++ b/net/tipc/msg.c
@@ -98,7 +98,7 @@ int tipc_buf_append(struct sk_buff **headbuf, struct sk_buff 
**buf)
 {
struct sk_buff *head = *headbuf;
struct sk_buff *frag = *buf;
-   struct sk_buff *tail;
+   struct sk_buff *tail = NULL;
struct tipc_msg *msg;
u32 fragid;
int delta;
@@ -118,9 +118,15 @@ int tipc_buf_append(struct sk_buff **headbuf, struct 
sk_buff **buf)
if (unlikely(skb_unclone(frag, GFP_ATOMIC)))
goto err;
head = *headbuf = frag;
-   skb_frag_list_init(head);
-   TIPC_SKB_CB(head)->tail = NULL;
*buf = NULL;
+   TIPC_SKB_CB(head)->tail = NULL;
+   if (skb_is_nonlinear(head)) {
+   skb_walk_frags(head, tail) {
+   TIPC_SKB_CB(head)->tail = tail;
+   }
+   } else {
+   skb_frag_list_init(head);
+   }
return 0;
}
 
-- 
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 3.19.y-ckt 012/164] ipmr: fix possible race resulting from improper usage of IP_INC_STATS_BH() in preemptible context.

[Kamal Mostafa]

3.19.8-ckt11 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Ani Sinha 

[ Upstream commit 44f49dd8b5a606870a1f21101522a0f9c4414784 ]

Fixes the following kernel BUG :

BUG: using __this_cpu_add() in preemptible [] code: bash/2758
caller is __this_cpu_preempt_check+0x13/0x15
CPU: 0 PID: 2758 Comm: bash Tainted: P   O   3.18.19 #2
 8170eaca 880110d1b788 81482b2a 
  880110d1b7b8 812010ae 880007cab800
 88001a060800 88013a899108 880108b84240 880110d1b7c8
Call Trace:
[] dump_stack+0x52/0x80
[] check_preemption_disabled+0xce/0xe1
[] __this_cpu_preempt_check+0x13/0x15
[] ipmr_queue_xmit+0x647/0x70c
[] ip_mr_forward+0x32f/0x34e
[] ip_mroute_setsockopt+0xe03/0x108c
[] ? get_parent_ip+0x11/0x42
[] ? pollwake+0x4d/0x51
[] ? default_wake_function+0x0/0xf
[] ? get_parent_ip+0x11/0x42
[] ? __wake_up_common+0x45/0x77
[] ? _raw_spin_unlock_irqrestore+0x1d/0x32
[] ? __wake_up_sync_key+0x4a/0x53
[] ? sock_def_readable+0x71/0x75
[] do_ip_setsockopt+0x9d/0xb55
[] ? unix_seqpacket_sendmsg+0x3f/0x41
[] ? sock_sendmsg+0x6d/0x86
[] ? sockfd_lookup_light+0x12/0x5d
[] ? SyS_sendto+0xf3/0x11b
[] ? new_sync_read+0x82/0xaa
[] compat_ip_setsockopt+0x3b/0x99
[] compat_raw_setsockopt+0x11/0x32
[] compat_sock_common_setsockopt+0x18/0x1f
[] compat_SyS_setsockopt+0x1a9/0x1cf
[] compat_SyS_socketcall+0x180/0x1e3
[] cstar_dispatch+0x7/0x1e

Signed-off-by: Ani Sinha 
Acked-by: Eric Dumazet 
Signed-off-by: David S. Miller 
Signed-off-by: Kamal Mostafa 
---
 net/ipv4/ipmr.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/net/ipv4/ipmr.c b/net/ipv4/ipmr.c
index c803458..a1fc97a 100644
--- a/net/ipv4/ipmr.c
+++ b/net/ipv4/ipmr.c
@@ -1674,8 +1674,8 @@ static inline int ipmr_forward_finish(struct sk_buff *skb)
 {
struct ip_options *opt = &(IPCB(skb)->opt);
 
-   IP_INC_STATS_BH(dev_net(skb_dst(skb)->dev), 
IPSTATS_MIB_OUTFORWDATAGRAMS);
-   IP_ADD_STATS_BH(dev_net(skb_dst(skb)->dev), IPSTATS_MIB_OUTOCTETS, 
skb->len);
+   IP_INC_STATS(dev_net(skb_dst(skb)->dev), IPSTATS_MIB_OUTFORWDATAGRAMS);
+   IP_ADD_STATS(dev_net(skb_dst(skb)->dev), IPSTATS_MIB_OUTOCTETS, 
skb->len);
 
if (unlikely(opt->optlen))
ip_forward_options(skb);
@@ -1737,7 +1737,7 @@ static void ipmr_queue_xmit(struct net *net, struct 
mr_table *mrt,
 * to blackhole.
 */
 
-   IP_INC_STATS_BH(dev_net(dev), IPSTATS_MIB_FRAGFAILS);
+   IP_INC_STATS(dev_net(dev), IPSTATS_MIB_FRAGFAILS);
ip_rt_put(rt);
goto out_free;
}
-- 
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: [RFC PATCH] af_unix: fix entry locking in unix_dgram_recvmsg

[David Miller]

From: Rainer Weikusat 
Date: Tue, 01 Dec 2015 17:02:33 +

> Rainer Weikusat  writes:
> 
> [...]
> 
>> Insofar I understand the comment in this code block correctly,
>>
>> err = mutex_lock_interruptible(>readlock);
>> if (unlikely(err)) {
>> /* recvmsg() in non blocking mode is supposed to return 
>> -EAGAIN
>>  * sk_rcvtimeo is not honored by mutex_lock_interruptible()
>>  */
>> err = noblock ? -EAGAIN : -ERESTARTSYS;
>> goto out;
>> }
>>
>> setting a receive timeout for an AF_UNIX datagram socket also doesn't
>> work as intended because of this: In case of n readers with the same
>> timeout, the nth reader will end up blocking n times the timeout.
> 
> Test program which confirms this. It starts four concurrent reads on the
> same socket with a receive timeout of 3s. This means the whole program
> should take a little more than 3s to execute as each read should time
> out at about the same time. But it takes 12s instead as the reads
> pile up on the readlock mutex and each then gets its own timeout once it
> could enter the receive loop.

I'm fine with your changes.

So with your patch, the "N * timeout" behavior, where N is the number
of queues reading threads, no longer occurs?  Do they all now properly
get released at the appropriate timeout?


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

Re: [PATCH] KVM: arm/arm64: vgic: make vgic_io_ops static

[Christoffer Dall]

On Thu, Nov 12, 2015 at 07:59:14PM +0800, Jisheng Zhang wrote:
> vgic_io_ops is only referenced within vgic.c, so it can be declared
> static.
> 
> Signed-off-by: Jisheng Zhang 

Applied to queue,
-Christoffer
--
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.19.y-ckt 006/164] irda: precedence bug in irlmp_seq_hb_idx()

[Kamal Mostafa]

3.19.8-ckt11 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Dan Carpenter 

[ Upstream commit 50010c20597d14667eff0fdb628309986f195230 ]

This is decrementing the pointer, instead of the value stored in the
pointer.  KASan detects it as an out of bounds reference.

Reported-by: "Berry Cheng 程君(成淼)" 
Signed-off-by: Dan Carpenter 
Signed-off-by: David S. Miller 
Signed-off-by: Kamal Mostafa 
---
 net/irda/irlmp.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/irda/irlmp.c b/net/irda/irlmp.c
index a26c401..4396459 100644
--- a/net/irda/irlmp.c
+++ b/net/irda/irlmp.c
@@ -1839,7 +1839,7 @@ static void *irlmp_seq_hb_idx(struct irlmp_iter_state 
*iter, loff_t *off)
for (element = hashbin_get_first(iter->hashbin);
 element != NULL;
 element = hashbin_get_next(iter->hashbin)) {
-   if (!off || *off-- == 0) {
+   if (!off || (*off)-- == 0) {
/* NB: hashbin left locked */
return element;
}
-- 
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 3.19.y-ckt 011/164] stmmac: Correctly report PTP capabilities.

[Kamal Mostafa]

3.19.8-ckt11 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Phil Reid 

[ Upstream commit e6dbe1eb2db0d7a14991c06278dd3030c45fb825 ]

priv->hwts_*_en indicate if timestamping is enabled/disabled at run
time. But  priv->dma_cap.time_stamp  and priv->dma_cap.atime_stamp
indicates HW is support for PTPv1/PTPv2.

Signed-off-by: Phil Reid 
Acked-by: Richard Cochran 
Signed-off-by: David S. Miller 
Signed-off-by: Kamal Mostafa 
---
 drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c 
b/drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c
index 771cda2..2e51b81 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c
@@ -721,10 +721,13 @@ static int stmmac_get_ts_info(struct net_device *dev,
 {
struct stmmac_priv *priv = netdev_priv(dev);
 
-   if ((priv->hwts_tx_en) && (priv->hwts_rx_en)) {
+   if ((priv->dma_cap.time_stamp || priv->dma_cap.atime_stamp)) {
 
-   info->so_timestamping = SOF_TIMESTAMPING_TX_HARDWARE |
+   info->so_timestamping = SOF_TIMESTAMPING_TX_SOFTWARE |
+   SOF_TIMESTAMPING_TX_HARDWARE |
+   SOF_TIMESTAMPING_RX_SOFTWARE |
SOF_TIMESTAMPING_RX_HARDWARE |
+   SOF_TIMESTAMPING_SOFTWARE |
SOF_TIMESTAMPING_RAW_HARDWARE;
 
if (priv->ptp_clock)
-- 
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 3.19.y-ckt 008/164] qmi_wwan: add Sierra Wireless MC74xx/EM74xx

[Kamal Mostafa]

3.19.8-ckt11 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: =?UTF-8?q?Bj=C3=B8rn=20Mork?= 

[ Upstream commit 0db65fcfcded76fe4f74e3ca9f4e2baf67b683ef ]

New device IDs shamelessly lifted from the vendor driver.

Signed-off-by: Bjørn Mork 
Signed-off-by: David S. Miller 
Signed-off-by: Kamal Mostafa 
---
 drivers/net/usb/qmi_wwan.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c
index 602dc66..a33de7c 100644
--- a/drivers/net/usb/qmi_wwan.c
+++ b/drivers/net/usb/qmi_wwan.c
@@ -764,6 +764,10 @@ static const struct usb_device_id products[] = {
{QMI_FIXED_INTF(0x1199, 0x9056, 8)},/* Sierra Wireless Modem */
{QMI_FIXED_INTF(0x1199, 0x9057, 8)},
{QMI_FIXED_INTF(0x1199, 0x9061, 8)},/* Sierra Wireless Modem */
+   {QMI_FIXED_INTF(0x1199, 0x9070, 8)},/* Sierra Wireless 
MC74xx/EM74xx */
+   {QMI_FIXED_INTF(0x1199, 0x9070, 10)},   /* Sierra Wireless 
MC74xx/EM74xx */
+   {QMI_FIXED_INTF(0x1199, 0x9071, 8)},/* Sierra Wireless 
MC74xx/EM74xx */
+   {QMI_FIXED_INTF(0x1199, 0x9071, 10)},   /* Sierra Wireless 
MC74xx/EM74xx */
{QMI_FIXED_INTF(0x1bbb, 0x011e, 4)},/* Telekom Speedstick LTE II 
(Alcatel One Touch L100V LTE) */
{QMI_FIXED_INTF(0x1bbb, 0x0203, 2)},/* Alcatel L800MA */
{QMI_FIXED_INTF(0x2357, 0x0201, 4)},/* TP-LINK HSUPA Modem MA180 */
-- 
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 3.19.y-ckt 005/164] drm/radeon: fix quirk for MSI R7 370 Armor 2X

[Kamal Mostafa]

3.19.8-ckt11 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Maxim Sheviakov 

commit 515c752dabee9945c1e8686c87f7cdeb3935eea4 upstream.

There was a typo in the original.

bug:
https://bugs.freedesktop.org/show_bug.cgi?id=92865

Signed-off-by: Maxim Sheviakov 
Signed-off-by: Alex Deucher 
Signed-off-by: Kamal Mostafa 
---
 drivers/gpu/drm/radeon/si_dpm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/radeon/si_dpm.c b/drivers/gpu/drm/radeon/si_dpm.c
index d67ce4c..bec1aba 100644
--- a/drivers/gpu/drm/radeon/si_dpm.c
+++ b/drivers/gpu/drm/radeon/si_dpm.c
@@ -2923,7 +2923,7 @@ static struct si_dpm_quirk si_dpm_quirk_list[] = {
{ PCI_VENDOR_ID_ATI, 0x6810, 0x1462, 0x3036, 0, 12 },
{ PCI_VENDOR_ID_ATI, 0x6811, 0x174b, 0xe271, 0, 12 },
{ PCI_VENDOR_ID_ATI, 0x6810, 0x174b, 0xe271, 85000, 9 },
-   { PCI_VENDOR_ID_ATI, 0x6811, 0x1762, 0x2015, 0, 12 },
+   { PCI_VENDOR_ID_ATI, 0x6811, 0x1462, 0x2015, 0, 12 },
{ PCI_VENDOR_ID_ATI, 0x6811, 0x1043, 0x2015, 0, 12 },
{ 0, 0, 0, 0 },
 };
-- 
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 3.19.y-ckt 002/164] x86/setup: Fix low identity map for >= 2GB kernel range

[Kamal Mostafa]

3.19.8-ckt11 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Krzysztof Mazur 

commit 68accac392d859d24adcf1be3a90e41f978bd54c upstream.

The commit f5f3497cad8c extended the low identity mapping. However, if
the kernel uses more than 2 GB (VMSPLIT_2G_OPT or VMSPLIT_1G memory
split), the normal memory mapping is overwritten by the low identity
mapping causing a crash. To avoid overwritting, limit the low identity
map to cover only memory before kernel range (PAGE_OFFSET).

Fixes: f5f3497cad8c "x86/setup: Extend low identity map to cover whole kernel 
range
Signed-off-by: Krzysztof Mazur 
Cc: Andy Lutomirski 
Cc: Borislav Petkov 
Cc: Laszlo Ersek 
Cc: Matt Fleming 
Cc: Paolo Bonzini 
Link: 
http://lkml.kernel.org/r/1446815916-22105-1-git-send-email-krzys...@podlesie.net
Signed-off-by: Thomas Gleixner 
Signed-off-by: Kamal Mostafa 
---
 arch/x86/kernel/setup.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index 5f660ca..51a4b6b 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -1195,7 +1195,7 @@ void __init setup_arch(char **cmdline_p)
 */
clone_pgd_range(initial_page_table,
swapper_pg_dir + KERNEL_PGD_BOUNDARY,
-   KERNEL_PGD_PTRS);
+   min(KERNEL_PGD_PTRS, KERNEL_PGD_BOUNDARY));
 #endif
 
tboot_probe();
-- 
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 3.19.y-ckt 016/164] net: avoid NULL deref in inet_ctl_sock_destroy()

[Kamal Mostafa]

3.19.8-ckt11 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Eric Dumazet 

[ Upstream commit 8fa677d2706d325d71dab91bf6e6512c05214e37 ]

Under low memory conditions, tcp_sk_init() and icmp_sk_init()
can both iterate on all possible cpus and call inet_ctl_sock_destroy(),
with eventual NULL pointer.

Signed-off-by: Eric Dumazet 
Reported-by: Dmitry Vyukov 
Signed-off-by: David S. Miller 
Signed-off-by: Kamal Mostafa 
---
 include/net/inet_common.h | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/include/net/inet_common.h b/include/net/inet_common.h
index b2828a0..a7d812d 100644
--- a/include/net/inet_common.h
+++ b/include/net/inet_common.h
@@ -42,7 +42,8 @@ int inet_recv_error(struct sock *sk, struct msghdr *msg, int 
len,
 
 static inline void inet_ctl_sock_destroy(struct sock *sk)
 {
-   sk_release_kernel(sk);
+   if (sk)
+   sk_release_kernel(sk);
 }
 
 #endif
-- 
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 3.19.y-ckt 013/164] qmi_wwan: fix entry for HP lt4112 LTE/HSPA+ Gobi 4G Module

[Kamal Mostafa]

3.19.8-ckt11 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: =?UTF-8?q?Bj=C3=B8rn=20Mork?= 

[ Upstream commit 70910791731b5956171e1bfcad707766b8e18fee ]

The lt4112 is a HP branded Huawei me906e modem. Like other Huawei
modems, it does not have a fixed interface to function mapping.
Instead it uses a Huawei specific scheme: functions are mapped by
subclass and protocol.

However, the HP vendor ID is used for modems from many different
manufacturers using different schemes, so we cannot apply a generic
vendor rule like we do for the Huawei vendor ID.

Replace the previous lt4112 entry pointing to an arbitrary interface
number with a device specific subclass + protocol match.

Reported-and-tested-by: Muri Nicanor 
Tested-by: Martin Hauke 
Fixes: bb2bdeb83fb1 ("qmi_wwan: Add support for HP lt4112 LTE/HSPA+ Gobi 4G 
Modem")
Signed-off-by: Bjørn Mork 
Signed-off-by: David S. Miller 
Signed-off-by: Kamal Mostafa 
---
 drivers/net/usb/qmi_wwan.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c
index a33de7c..75aa421 100644
--- a/drivers/net/usb/qmi_wwan.c
+++ b/drivers/net/usb/qmi_wwan.c
@@ -539,6 +539,10 @@ static const struct usb_device_id products[] = {
  USB_CDC_PROTO_NONE),
.driver_info= (unsigned long)_wwan_info,
},
+   {   /* HP lt4112 LTE/HSPA+ Gobi 4G Module (Huawei me906e) */
+   USB_DEVICE_AND_INTERFACE_INFO(0x03f0, 0x581d, 
USB_CLASS_VENDOR_SPEC, 1, 7),
+   .driver_info = (unsigned long)_wwan_info,
+   },
 
/* 3. Combined interface devices matching on interface number */
{QMI_FIXED_INTF(0x0408, 0xea42, 4)},/* Yota / Megafon M100-1 */
@@ -788,7 +792,6 @@ static const struct usb_device_id products[] = {
{QMI_FIXED_INTF(0x413c, 0x81a4, 8)},/* Dell Wireless 5570e HSPA+ 
(42Mbps) Mobile Broadband Card */
{QMI_FIXED_INTF(0x413c, 0x81a8, 8)},/* Dell Wireless 5808 Gobi(TM) 
4G LTE Mobile Broadband Card */
{QMI_FIXED_INTF(0x413c, 0x81a9, 8)},/* Dell Wireless 5808e Gobi(TM) 
4G LTE Mobile Broadband Card */
-   {QMI_FIXED_INTF(0x03f0, 0x581d, 4)},/* HP lt4112 LTE/HSPA+ Gobi 4G 
Module (Huawei me906e) */
 
/* 4. Gobi 1000 devices */
{QMI_GOBI1K_DEVICE(0x05c6, 0x9212)},/* Acer Gobi Modem Device */
-- 
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 3.19.y-ckt 017/164] ipv6: clean up dev_snmp6 proc entry when we fail to initialize inet6_dev

[Kamal Mostafa]

3.19.8-ckt11 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Sabrina Dubroca 

[ Upstream commit 2a189f9e57650e9f310ddf4aad75d66c1233a064 ]

In ipv6_add_dev, when addrconf_sysctl_register fails, we do not clean up
the dev_snmp6 entry that we have already registered for this device.
Call snmp6_unregister_dev in this case.

Fixes: a317a2f19da7d ("ipv6: fail early when creating netdev named all or 
default")
Reported-by: Dmitry Vyukov 
Signed-off-by: Sabrina Dubroca 
Signed-off-by: David S. Miller 
Signed-off-by: Kamal Mostafa 
---
 net/ipv6/addrconf.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
index 167d23e..06b8921 100644
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -396,6 +396,7 @@ static struct inet6_dev *ipv6_add_dev(struct net_device 
*dev)
if (err) {
ipv6_mc_destroy_dev(ndev);
del_timer(>regen_timer);
+   snmp6_unregister_dev(ndev);
goto err_release;
}
/* protected by rtnl_lock */
-- 
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 3.19.y-ckt 014/164] sit: fix sit0 percpu double allocations

[Kamal Mostafa]

3.19.8-ckt11 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Eric Dumazet 

[ Upstream commit 4ece9009774596ee3df0acba65a324b7ea79387c ]

sit0 device allocates its percpu storage twice :
- One time in ipip6_tunnel_init()
- One time in ipip6_fb_tunnel_init()

Thus we leak 48 bytes per possible cpu per network namespace dismantle.

ipip6_fb_tunnel_init() can be much simpler and does not
return an error, and should be called after register_netdev()

Note that ipip6_tunnel_clone_6rd() also needs to be called
after register_netdev() (calling ipip6_tunnel_init())

Fixes: ebe084aafb7e ("sit: Use ipip6_tunnel_init as the ndo_init function.")
Signed-off-by: Eric Dumazet 
Reported-by: Dmitry Vyukov 
Cc: Steffen Klassert 
Signed-off-by: David S. Miller 
Signed-off-by: Kamal Mostafa 
---
 net/ipv6/sit.c | 26 --
 1 file changed, 4 insertions(+), 22 deletions(-)

diff --git a/net/ipv6/sit.c b/net/ipv6/sit.c
index cdbfe5a..eb3ea58 100644
--- a/net/ipv6/sit.c
+++ b/net/ipv6/sit.c
@@ -1395,34 +1395,20 @@ static int ipip6_tunnel_init(struct net_device *dev)
return 0;
 }
 
-static int __net_init ipip6_fb_tunnel_init(struct net_device *dev)
+static void __net_init ipip6_fb_tunnel_init(struct net_device *dev)
 {
struct ip_tunnel *tunnel = netdev_priv(dev);
struct iphdr *iph = >parms.iph;
struct net *net = dev_net(dev);
struct sit_net *sitn = net_generic(net, sit_net_id);
 
-   tunnel->dev = dev;
-   tunnel->net = dev_net(dev);
-
iph->version= 4;
iph->protocol   = IPPROTO_IPV6;
iph->ihl= 5;
iph->ttl= 64;
 
-   dev->tstats = netdev_alloc_pcpu_stats(struct pcpu_sw_netstats);
-   if (!dev->tstats)
-   return -ENOMEM;
-
-   tunnel->dst_cache = alloc_percpu(struct ip_tunnel_dst);
-   if (!tunnel->dst_cache) {
-   free_percpu(dev->tstats);
-   return -ENOMEM;
-   }
-
dev_hold(dev);
rcu_assign_pointer(sitn->tunnels_wc[0], tunnel);
-   return 0;
 }
 
 static int ipip6_validate(struct nlattr *tb[], struct nlattr *data[])
@@ -1832,23 +1818,19 @@ static int __net_init sit_init_net(struct net *net)
 */
sitn->fb_tunnel_dev->features |= NETIF_F_NETNS_LOCAL;
 
-   err = ipip6_fb_tunnel_init(sitn->fb_tunnel_dev);
-   if (err)
-   goto err_dev_free;
-
-   ipip6_tunnel_clone_6rd(sitn->fb_tunnel_dev, sitn);
err = register_netdev(sitn->fb_tunnel_dev);
if (err)
goto err_reg_dev;
 
+   ipip6_tunnel_clone_6rd(sitn->fb_tunnel_dev, sitn);
+   ipip6_fb_tunnel_init(sitn->fb_tunnel_dev);
+
t = netdev_priv(sitn->fb_tunnel_dev);
 
strcpy(t->parms.name, sitn->fb_tunnel_dev->name);
return 0;
 
 err_reg_dev:
-   dev_put(sitn->fb_tunnel_dev);
-err_dev_free:
ipip6_dev_free(sitn->fb_tunnel_dev);
 err_alloc_dev:
return err;
-- 
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 3.19.y-ckt 015/164] sfc: push partner queue for skb->xmit_more

[Kamal Mostafa]

3.19.8-ckt11 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Martin Habets 

[ Upstream commit b2663a4f30e85ec606b806f5135413e6d5c78d1e ]

When the IP stack passes SKBs the sfc driver puts them in 2 different TX
queues (called partners), one for checksummed and one for not checksummed.
If the SKB has xmit_more set the driver will delay pushing the work to the
NIC.

When later it does decide to push the buffers this patch ensures it also
pushes the partner queue, if that also has any delayed work. Before this
fix the work in the partner queue would be left for a long time and cause
a netdev watchdog.

Fixes: 70b33fb ("sfc: add support for skb->xmit_more")
Reported-by: Jianlin Shi 
Signed-off-by: Martin Habets 
Signed-off-by: David S. Miller 
Signed-off-by: Kamal Mostafa 
---
 drivers/net/ethernet/sfc/ef10.c   |  4 +++-
 drivers/net/ethernet/sfc/farch.c  |  4 +++-
 drivers/net/ethernet/sfc/net_driver.h |  2 ++
 drivers/net/ethernet/sfc/tx.c | 30 --
 4 files changed, 36 insertions(+), 4 deletions(-)

diff --git a/drivers/net/ethernet/sfc/ef10.c b/drivers/net/ethernet/sfc/ef10.c
index fbb6cfa..feca46e 100644
--- a/drivers/net/ethernet/sfc/ef10.c
+++ b/drivers/net/ethernet/sfc/ef10.c
@@ -1344,7 +1344,9 @@ static void efx_ef10_tx_write(struct efx_tx_queue 
*tx_queue)
unsigned int write_ptr;
efx_qword_t *txd;
 
-   BUG_ON(tx_queue->write_count == tx_queue->insert_count);
+   tx_queue->xmit_more_available = false;
+   if (unlikely(tx_queue->write_count == tx_queue->insert_count))
+   return;
 
do {
write_ptr = tx_queue->write_count & tx_queue->ptr_mask;
diff --git a/drivers/net/ethernet/sfc/farch.c b/drivers/net/ethernet/sfc/farch.c
index 7597532..3992406 100644
--- a/drivers/net/ethernet/sfc/farch.c
+++ b/drivers/net/ethernet/sfc/farch.c
@@ -319,7 +319,9 @@ void efx_farch_tx_write(struct efx_tx_queue *tx_queue)
unsigned write_ptr;
unsigned old_write_count = tx_queue->write_count;
 
-   BUG_ON(tx_queue->write_count == tx_queue->insert_count);
+   tx_queue->xmit_more_available = false;
+   if (unlikely(tx_queue->write_count == tx_queue->insert_count))
+   return;
 
do {
write_ptr = tx_queue->write_count & tx_queue->ptr_mask;
diff --git a/drivers/net/ethernet/sfc/net_driver.h 
b/drivers/net/ethernet/sfc/net_driver.h
index 325dd94..0bdef4a 100644
--- a/drivers/net/ethernet/sfc/net_driver.h
+++ b/drivers/net/ethernet/sfc/net_driver.h
@@ -218,6 +218,7 @@ struct efx_tx_buffer {
  * @tso_packets: Number of packets via the TSO xmit path
  * @pushes: Number of times the TX push feature has been used
  * @pio_packets: Number of times the TX PIO feature has been used
+ * @xmit_more_available: Are any packets waiting to be pushed to the NIC
  * @empty_read_count: If the completion path has seen the queue as empty
  * and the transmission path has not yet checked this, the value of
  * @read_count bitwise-added to %EFX_EMPTY_COUNT_VALID; otherwise 0.
@@ -250,6 +251,7 @@ struct efx_tx_queue {
unsigned int tso_packets;
unsigned int pushes;
unsigned int pio_packets;
+   bool xmit_more_available;
/* Statistics to supplement MAC stats */
unsigned long tx_packets;
 
diff --git a/drivers/net/ethernet/sfc/tx.c b/drivers/net/ethernet/sfc/tx.c
index aaf2987..e70edc3 100644
--- a/drivers/net/ethernet/sfc/tx.c
+++ b/drivers/net/ethernet/sfc/tx.c
@@ -431,8 +431,20 @@ finish_packet:
efx_tx_maybe_stop_queue(tx_queue);
 
/* Pass off to hardware */
-   if (!skb->xmit_more || netif_xmit_stopped(tx_queue->core_txq))
+   if (!skb->xmit_more || netif_xmit_stopped(tx_queue->core_txq)) {
+   struct efx_tx_queue *txq2 = efx_tx_queue_partner(tx_queue);
+
+   /* There could be packets left on the partner queue if those
+* SKBs had skb->xmit_more set. If we do not push those they
+* could be left for a long time and cause a netdev watchdog.
+*/
+   if (txq2->xmit_more_available)
+   efx_nic_push_buffers(txq2);
+
efx_nic_push_buffers(tx_queue);
+   } else {
+   tx_queue->xmit_more_available = skb->xmit_more;
+   }
 
tx_queue->tx_packets++;
 
@@ -721,6 +733,7 @@ void efx_init_tx_queue(struct efx_tx_queue *tx_queue)
tx_queue->read_count = 0;
tx_queue->old_read_count = 0;
tx_queue->empty_read_count = 0 | EFX_EMPTY_COUNT_VALID;
+   tx_queue->xmit_more_available = false;
 
/* Set up TX descriptor ring */
efx_nic_init_tx(tx_queue);
@@ -746,6 +759,7 @@ void efx_fini_tx_queue(struct efx_tx_queue *tx_queue)
 
++tx_queue->read_count;
}
+   tx_queue->xmit_more_available = false;
netdev_tx_reset_queue(tx_queue->core_txq);
 }
 
@@ -1301,8 +1315,20 

Re: Asterisk deadlocks since Kernel 4.1

[Philipp Hahn]

Hi,

Am 02.12.2015 um 10:45 schrieb Stefan Priebe - Profihost AG:
> here are the results.
> 
> It works with 4.1.
> It works with 4.2.
> It does not work with 4.1.13.

the patches were first commitet in v4.3-rc3 and appear as backports only
since v4.2.3 and v4.1.10

> git bisect tells me it stopped working after those two commits were applied:
> 
> commit d48623677191e0f035d7afd344f92cf880b01f8e
> Author: Herbert Xu 
> Date:   Tue Sep 22 11:38:56 2015 +0800
> 
> netlink: Replace rhash_portid with bound
> 
> commit 4e27762417669cb459971635be550eb7b5598286
> Author: Herbert Xu 
> Date:   Fri Sep 18 19:16:50 2015 +0800
> 
> netlink: Fix autobind race condition that leads to zero port ID

I identified the same two patches for our prpblem; see mail from
2015-11-17 16:53 with subject "Strange PF_NETLINK NETLINK_ROUTE stall:
netlink: Fix autobind race condition that leads to zero port ID"



Philipp
--
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: Asterisk deadlocks since Kernel 4.1

[Philipp Hahn]

Hi,

Am 02.12.2015 um 12:40 schrieb Hannes Frederic Sowa:
> Cool, thanks a lot. Does this patch make a difference?
> 
> diff --git a/net/netlink/af_netlink.c b/net/netlink/af_netlink.c
> index 59651af..278e94c 100644
> --- a/net/netlink/af_netlink.c
> +++ b/net/netlink/af_netlink.c
> @@ -1137,7 +1137,7 @@ static int netlink_insert(struct sock *sk, u32 portid)
>  
>   /* We need to ensure that the socket is hashed and visible. */
>   smp_wmb();
> - nlk_sk(sk)->bound = portid;
> + nlk_sk(sk)->bound = true;
>  
>  err:
>   release_sock(sk);

Will test that tomorrow.

What confuss me is that it works with 4.3. I compared
net/netlink/af_netlink.[ch] for differences between v4.1.10 and v4.3 and
didn't find anything which would explain only 4,1 getting stuck.

Philipp
--
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.19.y-ckt 018/164] ipv4: disable BH when changing ip local port range

[Kamal Mostafa]

3.19.8-ckt11 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: WANG Cong 

[ Upstream commit 4ee3bd4a8c7463cdef0b82ebc33fc94a9170a7e0 ]

This fixes the following lockdep warning:

 [ INFO: inconsistent lock state ]
 4.3.0-rc7+ #1197 Not tainted
 -
 inconsistent {IN-SOFTIRQ-R} -> {SOFTIRQ-ON-W} usage.
 sysctl/1019 [HC0[0]:SC0[0]:HE1:SE1] takes:
  (&(>ipv4.ip_local_ports.lock)->seqcount){+.+-..}, at: 
[] ipv4_local_port_range+0xb4/0x12a
 {IN-SOFTIRQ-R} state was registered at:
   [] __lock_acquire+0x2f6/0xdf0
   [] lock_acquire+0x11c/0x1a4
   [] inet_get_local_port_range+0x4e/0xae
   [] udp_flow_src_port.constprop.40+0x23/0x116
   [] vxlan_xmit_one+0x219/0xa6a
   [] vxlan_xmit+0xa6b/0xaa5
   [] dev_hard_start_xmit+0x2ae/0x465
   [] __dev_queue_xmit+0x531/0x633
   [] dev_queue_xmit_sk+0x13/0x15
   [] neigh_resolve_output+0x12f/0x14d
   [] ip6_finish_output2+0x344/0x39f
   [] ip6_finish_output+0x88/0x8e
   [] ip6_output+0x91/0xe5
   [] dst_output_sk+0x47/0x4c
   [] NF_HOOK_THRESH.constprop.30+0x38/0x82
   [] mld_sendpack+0x189/0x266
   [] mld_ifc_timer_expire+0x1ef/0x223
   [] call_timer_fn+0xfb/0x28c
   [] run_timer_softirq+0x1c7/0x1f1

Fixes: b8f1a55639e6 ("udp: Add function to make source port for UDP tunnels")
Cc: Tom Herbert 
Signed-off-by: Cong Wang 
Signed-off-by: David S. Miller 
Signed-off-by: Kamal Mostafa 
---
 net/ipv4/sysctl_net_ipv4.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/net/ipv4/sysctl_net_ipv4.c b/net/ipv4/sysctl_net_ipv4.c
index e0ee384..b3ee8ee 100644
--- a/net/ipv4/sysctl_net_ipv4.c
+++ b/net/ipv4/sysctl_net_ipv4.c
@@ -45,10 +45,10 @@ static int ip_ping_group_range_max[] = { GID_T_MAX, 
GID_T_MAX };
 /* Update system visible IP port range */
 static void set_local_port_range(struct net *net, int range[2])
 {
-   write_seqlock(>ipv4.ip_local_ports.lock);
+   write_seqlock_bh(>ipv4.ip_local_ports.lock);
net->ipv4.ip_local_ports.range[0] = range[0];
net->ipv4.ip_local_ports.range[1] = range[1];
-   write_sequnlock(>ipv4.ip_local_ports.lock);
+   write_sequnlock_bh(>ipv4.ip_local_ports.lock);
 }
 
 /* Validate changes from /proc interface. */
-- 
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 3.19.y-ckt 030/164] ARM: 8427/1: dma-mapping: add support for offset parameter in dma_mmap()

[Kamal Mostafa]

3.19.8-ckt11 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Marek Szyprowski 

commit 7e31210349e9e03a9a4dff31ab5f2bc83e8e84f5 upstream.

IOMMU-based dma_mmap() implementation lacked proper support for offset
parameter used in mmap call (it always assumed that mapping starts from
offset zero). This patch adds support for offset parameter to IOMMU-based
implementation.

Signed-off-by: Marek Szyprowski 
Signed-off-by: Russell King 
Signed-off-by: Kamal Mostafa 
---
 arch/arm/mm/dma-mapping.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
index 30558bb..7e5fda66 100644
--- a/arch/arm/mm/dma-mapping.c
+++ b/arch/arm/mm/dma-mapping.c
@@ -1376,6 +1376,8 @@ static int arm_iommu_mmap_attrs(struct device *dev, 
struct vm_area_struct *vma,
if (off >= nr_pages || (usize >> PAGE_SHIFT) > nr_pages - off)
return -ENXIO;
 
+   pages += off;
+
do {
int ret = vm_insert_page(vma, uaddr, *pages++);
if (ret) {
-- 
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 3.19.y-ckt 021/164] HID: core: Avoid uninitialized buffer access

[Kamal Mostafa]

3.19.8-ckt11 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Richard Purdie 

commit 79b568b9d0c7c5d81932f4486d50b38efdd6da6d upstream.

hid_connect adds various strings to the buffer but they're all
conditional. You can find circumstances where nothing would be written
to it but the kernel will still print the supposedly empty buffer with
printk. This leads to corruption on the console/in the logs.

Ensure buf is initialized to an empty string.

Signed-off-by: Richard Purdie 
[dvhart: Initialize string to "" rather than assign buf[0] = NULL;]
Cc: Jiri Kosina 
Cc: linux-in...@vger.kernel.org
Signed-off-by: Darren Hart 
Signed-off-by: Jiri Kosina 
Signed-off-by: Kamal Mostafa 
---
 drivers/hid/hid-core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
index 8b63879..d7d965f 100644
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -1562,7 +1562,7 @@ int hid_connect(struct hid_device *hdev, unsigned int 
connect_mask)
"Multi-Axis Controller"
};
const char *type, *bus;
-   char buf[64];
+   char buf[64] = "";
unsigned int i;
int len;
int ret;
-- 
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 3.19.y-ckt 033/164] usb: dwc3: pci: Add the PCI Product ID for Synopsys USB 3.1

[Kamal Mostafa]

3.19.8-ckt11 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: John Youn 

commit e8095a25364a30216ad40dbe8893ed5c3c235949 upstream.

This adds the PCI product ID for the Synopsys USB 3.1 IP core
(DWC_usb31) on a HAPS-based PCI development platform.

Signed-off-by: John Youn 
Signed-off-by: Felipe Balbi 
Signed-off-by: Kamal Mostafa 
---
 drivers/usb/dwc3/dwc3-pci.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/usb/dwc3/dwc3-pci.c b/drivers/usb/dwc3/dwc3-pci.c
index 15b0fcb..637cd3d 100644
--- a/drivers/usb/dwc3/dwc3-pci.c
+++ b/drivers/usb/dwc3/dwc3-pci.c
@@ -31,6 +31,7 @@
 #define PCI_VENDOR_ID_SYNOPSYS 0x16c3
 #define PCI_DEVICE_ID_SYNOPSYS_HAPSUSB30xabcd
 #define PCI_DEVICE_ID_SYNOPSYS_HAPSUSB3_AXI 0xabce
+#define PCI_DEVICE_ID_SYNOPSYS_HAPSUSB31 0xabcf
 #define PCI_DEVICE_ID_INTEL_BYT0x0f37
 #define PCI_DEVICE_ID_INTEL_MRFLD  0x119e
 #define PCI_DEVICE_ID_INTEL_BSW0x22B7
@@ -223,6 +224,10 @@ static const struct pci_device_id dwc3_pci_id_table[] = {
PCI_DEVICE(PCI_VENDOR_ID_SYNOPSYS,
PCI_DEVICE_ID_SYNOPSYS_HAPSUSB3_AXI),
},
+   {
+   PCI_DEVICE(PCI_VENDOR_ID_SYNOPSYS,
+   PCI_DEVICE_ID_SYNOPSYS_HAPSUSB31),
+   },
{ PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_BSW), },
{ PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_BYT), },
{ PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_MRFLD), },
-- 
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 3.19.y-ckt 027/164] [media] media: v4l2-ctrls: Fix 64bit support in get_ctrl()

[Kamal Mostafa]

3.19.8-ckt11 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Benoit Parrot 

commit a8077734055f870ba630563868a6349671ca8dfc upstream.

When trying to use v4l2_ctrl_g_ctrl_int64() to retrieve a
V4L2_CTRL_TYPE_INTEGER64 type value the internal helper function
get_ctrl() would prematurely exit because for this control type
the 'is_int' flag is not set. This would result in v4l2_ctrl_g_ctrl_int64
always returning 0.

Also v4l2_ctrl_g_ctrl_int64() is reading and returning the 32bit value
member instead of the 64bit version, so fixing that as well.

This patch extends the condition check to allow the V4L2_CTRL_TYPE_INTEGER64
type to continue processing instead of exiting.

Signed-off-by: Benoit Parrot 
Signed-off-by: Hans Verkuil 
Signed-off-by: Mauro Carvalho Chehab 
Signed-off-by: Kamal Mostafa 
---
 drivers/media/v4l2-core/v4l2-ctrls.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c 
b/drivers/media/v4l2-core/v4l2-ctrls.c
index 468a3b3..2e98f02 100644
--- a/drivers/media/v4l2-core/v4l2-ctrls.c
+++ b/drivers/media/v4l2-core/v4l2-ctrls.c
@@ -2883,7 +2883,7 @@ static int get_ctrl(struct v4l2_ctrl *ctrl, struct 
v4l2_ext_control *c)
 * cur_to_user() calls below would need to be modified not to access
 * userspace memory when called from get_ctrl().
 */
-   if (!ctrl->is_int)
+   if (!ctrl->is_int && ctrl->type != V4L2_CTRL_TYPE_INTEGER64)
return -EINVAL;
 
if (ctrl->flags & V4L2_CTRL_FLAG_WRITE_ONLY)
@@ -2941,9 +2941,9 @@ s64 v4l2_ctrl_g_ctrl_int64(struct v4l2_ctrl *ctrl)
 
/* It's a driver bug if this happens. */
WARN_ON(ctrl->is_ptr || ctrl->type != V4L2_CTRL_TYPE_INTEGER64);
-   c.value = 0;
+   c.value64 = 0;
get_ctrl(ctrl, );
-   return c.value;
+   return c.value64;
 }
 EXPORT_SYMBOL(v4l2_ctrl_g_ctrl_int64);
 
-- 
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 3.19.y-ckt 023/164] net: mvneta: Fix CPU_MAP registers initialisation

[Kamal Mostafa]

3.19.8-ckt11 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Maxime Ripard 

commit 2502d0ef272da7058ef303b849a2c8dc324c2e2e upstream.

The CPU_MAP register is duplicated for each CPUs at different addresses,
each instance being at a different address.

However, the code so far was using CONFIG_NR_CPUS to initialise the CPU_MAP
registers for each registers, while the SoCs embed at most 4 CPUs.

This is especially an issue with multi_v7_defconfig, where CONFIG_NR_CPUS
is currently set to 16, resulting in writes to registers that are not
CPU_MAP.

Fixes: c5aff18204da ("net: mvneta: driver for Marvell Armada 370/XP network 
unit")
Signed-off-by: Maxime Ripard 
Signed-off-by: Gregory CLEMENT 
Signed-off-by: David S. Miller 
Signed-off-by: Kamal Mostafa 
---
 drivers/net/ethernet/marvell/mvneta.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/marvell/mvneta.c 
b/drivers/net/ethernet/marvell/mvneta.c
index f8a081a..5ff18c1 100644
--- a/drivers/net/ethernet/marvell/mvneta.c
+++ b/drivers/net/ethernet/marvell/mvneta.c
@@ -942,7 +942,7 @@ static void mvneta_defaults_set(struct mvneta_port *pp)
/* Set CPU queue access map - all CPUs have access to all RX
 * queues and to all TX queues
 */
-   for (cpu = 0; cpu < CONFIG_NR_CPUS; cpu++)
+   for_each_present_cpu(cpu)
mvreg_write(pp, MVNETA_CPU_MAP(cpu),
(MVNETA_CPU_RXQ_ACCESS_ALL_MASK |
 MVNETA_CPU_TXQ_ACCESS_ALL_MASK));
-- 
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 3.19.y-ckt 024/164] mtd: mtdpart: fix add_mtd_partitions error path

[Kamal Mostafa]

3.19.8-ckt11 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Boris BREZILLON 

commit e5bae86797141e4a95e42d825f737cb36d7b8c37 upstream.

If we fail to allocate a partition structure in the middle of the partition
creation process, the already allocated partitions are never removed, which
means they are still present in the partition list and their resources are
never freed.

Signed-off-by: Boris Brezillon 
Signed-off-by: Brian Norris 
Signed-off-by: Kamal Mostafa 
---
 drivers/mtd/mtdpart.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/mtd/mtdpart.c b/drivers/mtd/mtdpart.c
index a3e3a7d..6e98e2c 100644
--- a/drivers/mtd/mtdpart.c
+++ b/drivers/mtd/mtdpart.c
@@ -648,8 +648,10 @@ int add_mtd_partitions(struct mtd_info *master,
 
for (i = 0; i < nbparts; i++) {
slave = allocate_partition(master, parts + i, i, cur_offset);
-   if (IS_ERR(slave))
+   if (IS_ERR(slave)) {
+   del_mtd_partitions(master);
return PTR_ERR(slave);
+   }
 
mutex_lock(_partitions_mutex);
list_add(>list, _partitions);
-- 
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 3.19.y-ckt 034/164] usb: dwc3: Support Synopsys USB 3.1 IP

[Kamal Mostafa]

3.19.8-ckt11 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: John Youn 

commit 690fb3718a70c66004342f6f5e2e8a5f95b977db upstream.

This patch allows the dwc3 driver to run on the new Synopsys USB 3.1
IP core, albeit in USB 3.0 mode only.

The Synopsys USB 3.1 IP (DWC_usb31) retains mostly the same register
interface and programming model as the existing USB 3.0 controller IP
(DWC_usb3). However the GSNPSID and version numbers are different.

Add checking for the new ID to pass driver probe.

Also, since the DWC_usb31 version number is lower in value than the
full GSNPSID of the DWC_usb3 IP, we set the high bit to identify
DWC_usb31 and to ensure the values are higher.

Finally, add a documentation note about the revision numbering scheme.
Any future revision checks (for STARS, workarounds, and new features)
should take into consideration how it applies to both the 3.1/3.0 IP.

Signed-off-by: John Youn 
Signed-off-by: Felipe Balbi 
Signed-off-by: Kamal Mostafa 
---
 drivers/usb/dwc3/core.c | 10 --
 drivers/usb/dwc3/core.h | 18 ++
 2 files changed, 26 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 25ddc39..2687d33 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -445,12 +445,18 @@ static int dwc3_core_init(struct dwc3 *dwc)
 
reg = dwc3_readl(dwc->regs, DWC3_GSNPSID);
/* This should read as U3 followed by revision number */
-   if ((reg & DWC3_GSNPSID_MASK) != 0x5533) {
+   if ((reg & DWC3_GSNPSID_MASK) == 0x5533) {
+   /* Detected DWC_usb3 IP */
+   dwc->revision = reg;
+   } else if ((reg & DWC3_GSNPSID_MASK) == 0x3331) {
+   /* Detected DWC_usb31 IP */
+   dwc->revision = dwc3_readl(dwc->regs, DWC3_VER_NUMBER);
+   dwc->revision |= DWC3_REVISION_IS_DWC31;
+   } else {
dev_err(dwc->dev, "this is not a DesignWare USB3 DRD Core\n");
ret = -ENODEV;
goto err0;
}
-   dwc->revision = reg;
 
/*
 * Write Linux Version Code to our GUID register so it's easy to figure
diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
index 192396c..87fe55c 100644
--- a/drivers/usb/dwc3/core.h
+++ b/drivers/usb/dwc3/core.h
@@ -107,6 +107,9 @@
 #define DWC3_GPRTBIMAP_FS0 0xc188
 #define DWC3_GPRTBIMAP_FS1 0xc18c
 
+#define DWC3_VER_NUMBER0xc1a0
+#define DWC3_VER_TYPE  0xc1a4
+
 #define DWC3_GUSB2PHYCFG(n)(0xc200 + (n * 0x04))
 #define DWC3_GUSB2I2CCTL(n)(0xc240 + (n * 0x04))
 
@@ -755,6 +758,14 @@ struct dwc3 {
u32 num_event_buffers;
u32 u1u2;
u32 maximum_speed;
+
+   /*
+* All 3.1 IP version constants are greater than the 3.0 IP
+* version constants. This works for most version checks in
+* dwc3. However, in the future, this may not apply as
+* features may be developed on newer versions of the 3.0 IP
+* that are not in the 3.1 IP.
+*/
u32 revision;
 
 #define DWC3_REVISION_173A 0x5533173a
@@ -777,6 +788,13 @@ struct dwc3 {
 #define DWC3_REVISION_270A 0x5533270a
 #define DWC3_REVISION_280A 0x5533280a
 
+/*
+ * NOTICE: we're using bit 31 as a "is usb 3.1" flag. This is really
+ * just so dwc31 revisions are always larger than dwc3.
+ */
+#define DWC3_REVISION_IS_DWC31 0x8000
+#define DWC3_USB31_REVISION_110A   (0x3131302a | DWC3_REVISION_IS_USB31)
+
enum dwc3_ep0_next  ep0_next_event;
enum dwc3_ep0_state ep0state;
enum dwc3_link_statelink_state;
-- 
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 3.19.y-ckt 022/164] [media] v4l2-compat-ioctl32: fix alignment for ARM64

[Kamal Mostafa]

3.19.8-ckt11 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Andrzej Hajda 

commit 655e9780ab913a3a06d4a164d55e3b755524186d upstream.

Alignment/padding rules on AMD64 and ARM64 differs. To allow properly match
compatible ioctls on ARM64 kernels without breaking AMD64 some fields
should be aligned using compat_s64 type and in one case struct should be
unpacked.

Signed-off-by: Andrzej Hajda 
[hans.verk...@cisco.com: use compat_u64 instead of compat_s64 in v4l2_input32]
Signed-off-by: Hans Verkuil 

Signed-off-by: Mauro Carvalho Chehab 
Signed-off-by: Kamal Mostafa 
---
 drivers/media/v4l2-core/v4l2-compat-ioctl32.c | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/media/v4l2-core/v4l2-compat-ioctl32.c 
b/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
index af63543..788b31c 100644
--- a/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
+++ b/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
@@ -266,7 +266,7 @@ static int put_v4l2_create32(struct v4l2_create_buffers 
*kp, struct v4l2_create_
 
 struct v4l2_standard32 {
__u32index;
-   __u32id[2]; /* __u64 would get the alignment wrong */
+   compat_u64   id;
__u8 name[24];
struct v4l2_fractframeperiod; /* Frames, not fields */
__u32framelines;
@@ -286,7 +286,7 @@ static int put_v4l2_standard32(struct v4l2_standard *kp, 
struct v4l2_standard32
 {
if (!access_ok(VERIFY_WRITE, up, sizeof(struct v4l2_standard32)) ||
put_user(kp->index, >index) ||
-   copy_to_user(up->id, >id, sizeof(__u64)) ||
+   put_user(kp->id, >id) ||
copy_to_user(up->name, kp->name, 24) ||
copy_to_user(>frameperiod, >frameperiod, 
sizeof(kp->frameperiod)) ||
put_user(kp->framelines, >framelines) ||
@@ -587,10 +587,10 @@ struct v4l2_input32 {
__u32type;  /*  Type of input */
__u32audioset;  /*  Associated audios (bitfield) */
__u32tuner; /*  Associated tuner */
-   v4l2_std_id  std;
+   compat_u64   std;
__u32status;
__u32reserved[4];
-} __attribute__ ((packed));
+};
 
 /* The 64-bit v4l2_input struct has extra padding at the end of the struct.
Otherwise it is identical to the 32-bit version. */
@@ -738,6 +738,7 @@ static int put_v4l2_ext_controls32(struct v4l2_ext_controls 
*kp, struct v4l2_ext
 struct v4l2_event32 {
__u32   type;
union {
+   compat_s64  value64;
__u8data[64];
} u;
__u32   pending;
-- 
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 3.19.y-ckt 026/164] [media] v4l2-ctrls: arrays are also considered compound controls

[Kamal Mostafa]

3.19.8-ckt11 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Hans Verkuil 

commit 35204e2e84f2dae72012f8ca319659c12f428430 upstream.

Array controls weren't skipped when only V4L2_CTRL_FLAG_NEXT_CTRL was
provided (so no V4L2_CTRL_FLAG_NEXT_COMPOUND was set). This is wrong
since arrays are also considered compound controls (i.e. with more than
one value), and applications that do not know about arrays will not
be able to handle such controls.

Fix the test to include arrays.

Signed-off-by: Hans Verkuil 
Reported-by: Ricardo Ribalda Delgado 
Signed-off-by: Mauro Carvalho Chehab 
Signed-off-by: Kamal Mostafa 
---
 drivers/media/v4l2-core/v4l2-ctrls.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c 
b/drivers/media/v4l2-core/v4l2-ctrls.c
index 45c5b47..468a3b3 100644
--- a/drivers/media/v4l2-core/v4l2-ctrls.c
+++ b/drivers/media/v4l2-core/v4l2-ctrls.c
@@ -2497,7 +2497,7 @@ int v4l2_query_ext_ctrl(struct v4l2_ctrl_handler *hdl, 
struct v4l2_query_ext_ctr
/* We found a control with the given ID, so just get
   the next valid one in the list. */
list_for_each_entry_continue(ref, >ctrl_refs, 
node) {
-   is_compound =
+   is_compound = ref->ctrl->is_array ||
ref->ctrl->type >= 
V4L2_CTRL_COMPOUND_TYPES;
if (id < ref->ctrl->id &&
(is_compound & mask) == match)
@@ -2511,7 +2511,7 @@ int v4l2_query_ext_ctrl(struct v4l2_ctrl_handler *hdl, 
struct v4l2_query_ext_ctr
   is one, otherwise the first 'if' above would have
   been true. */
list_for_each_entry(ref, >ctrl_refs, node) {
-   is_compound =
+   is_compound = ref->ctrl->is_array ||
ref->ctrl->type >= 
V4L2_CTRL_COMPOUND_TYPES;
if (id < ref->ctrl->id &&
(is_compound & mask) == match)
-- 
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 3.19.y-ckt 029/164] ARM: 8426/1: dma-mapping: add missing range check in dma_mmap()

[Kamal Mostafa]

3.19.8-ckt11 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Marek Szyprowski 

commit 371f0f085f629fc0f66695f572373ca4445a67ad upstream.

dma_mmap() function in IOMMU-based dma-mapping implementation lacked
a check for valid range of mmap parameters (offset and buffer size), what
might have caused access beyond the allocated buffer. This patch fixes
this issue.

Signed-off-by: Marek Szyprowski 
Signed-off-by: Russell King 
Signed-off-by: Kamal Mostafa 
---
 arch/arm/mm/dma-mapping.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
index bc074ef..30558bb 100644
--- a/arch/arm/mm/dma-mapping.c
+++ b/arch/arm/mm/dma-mapping.c
@@ -1365,12 +1365,17 @@ static int arm_iommu_mmap_attrs(struct device *dev, 
struct vm_area_struct *vma,
unsigned long uaddr = vma->vm_start;
unsigned long usize = vma->vm_end - vma->vm_start;
struct page **pages = __iommu_get_pages(cpu_addr, attrs);
+   unsigned long nr_pages = PAGE_ALIGN(size) >> PAGE_SHIFT;
+   unsigned long off = vma->vm_pgoff;
 
vma->vm_page_prot = __get_dma_pgprot(attrs, vma->vm_page_prot);
 
if (!pages)
return -ENXIO;
 
+   if (off >= nr_pages || (usize >> PAGE_SHIFT) > nr_pages - off)
+   return -ENXIO;
+
do {
int ret = vm_insert_page(vma, uaddr, *pages++);
if (ret) {
-- 
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 3.19.y-ckt 032/164] usb: dwc3: pci: Add the Synopsys HAPS AXI Product ID

[Kamal Mostafa]

3.19.8-ckt11 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: John Youn 

commit 41adc59caece02aa2e988a0e8f9fe8e6f426f82e upstream.

This ID is for the Synopsys DWC_usb3 core with AXI interface on PCIe
HAPS platform. This core has the debug registers mapped at a separate
BAR in order to support enhanced hibernation.

Signed-off-by: John Youn 
Signed-off-by: Felipe Balbi 
Signed-off-by: Kamal Mostafa 
---
 drivers/usb/dwc3/dwc3-pci.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/usb/dwc3/dwc3-pci.c b/drivers/usb/dwc3/dwc3-pci.c
index b642a2f..15b0fcb 100644
--- a/drivers/usb/dwc3/dwc3-pci.c
+++ b/drivers/usb/dwc3/dwc3-pci.c
@@ -30,6 +30,7 @@
 /* FIXME define these in  */
 #define PCI_VENDOR_ID_SYNOPSYS 0x16c3
 #define PCI_DEVICE_ID_SYNOPSYS_HAPSUSB30xabcd
+#define PCI_DEVICE_ID_SYNOPSYS_HAPSUSB3_AXI 0xabce
 #define PCI_DEVICE_ID_INTEL_BYT0x0f37
 #define PCI_DEVICE_ID_INTEL_MRFLD  0x119e
 #define PCI_DEVICE_ID_INTEL_BSW0x22B7
@@ -218,6 +219,10 @@ static const struct pci_device_id dwc3_pci_id_table[] = {
PCI_DEVICE(PCI_VENDOR_ID_SYNOPSYS,
PCI_DEVICE_ID_SYNOPSYS_HAPSUSB3),
},
+   {
+   PCI_DEVICE(PCI_VENDOR_ID_SYNOPSYS,
+   PCI_DEVICE_ID_SYNOPSYS_HAPSUSB3_AXI),
+   },
{ PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_BSW), },
{ PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_BYT), },
{ PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_MRFLD), },
-- 
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 3.19.y-ckt 028/164] ARM: tegra: paz00: use con_id's to refer GPIO's in gpiod_lookup table

[Kamal Mostafa]

3.19.8-ckt11 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Dmitry Osipenko 

commit e77b675f8786f38d40fc1562e1275875daf67fef upstream.

Commit 72daceb9a10a ("net: rfkill: gpio: Add default GPIO driver mappings
for ACPI") removed possibility to request GPIO by table index for non-ACPI
platforms without changing its users. As result "shutdown" GPIO request
will fail if request for "reset" GPIO succeeded or "reset" will be
requested instead of "shutdown" if "reset" wasn't defined. Fix it by
making gpiod_lookup_table use con_id's instead of indexes.

Signed-off-by: Dmitry Osipenko 
Fixes: 72daceb (net: rfkill: gpio: Add default GPIO driver mappings for ACPI)
Acked-by: Alexandre Courbot 
Reviewed-by: Marc Dietrich 
Tested-by: Marc Dietrich 
Signed-off-by: Thierry Reding 
Signed-off-by: Kamal Mostafa 
---
 arch/arm/mach-tegra/board-paz00.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-tegra/board-paz00.c 
b/arch/arm/mach-tegra/board-paz00.c
index fbe74c6..49d1110 100644
--- a/arch/arm/mach-tegra/board-paz00.c
+++ b/arch/arm/mach-tegra/board-paz00.c
@@ -39,8 +39,8 @@ static struct platform_device wifi_rfkill_device = {
 static struct gpiod_lookup_table wifi_gpio_lookup = {
.dev_id = "rfkill_gpio",
.table = {
-   GPIO_LOOKUP_IDX("tegra-gpio", 25, NULL, 0, 0),
-   GPIO_LOOKUP_IDX("tegra-gpio", 85, NULL, 1, 0),
+   GPIO_LOOKUP("tegra-gpio", 25, "reset", 0),
+   GPIO_LOOKUP("tegra-gpio", 85, "shutdown", 0),
{ },
},
 };
-- 
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 3.19.y-ckt 035/164] usb: dwc3: Add dis_enblslpm_quirk

[Kamal Mostafa]

3.19.8-ckt11 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: John Youn 

commit ec791d149bca4511e7d3a6a92bb3b030c5a443f9 upstream.

Add a quirk to clear the GUSB2PHYCFG.ENBLSLPM bit, which controls
whether the PHY receives the suspend signal from the controller.

Signed-off-by: John Youn 
Signed-off-by: Felipe Balbi 
Signed-off-by: Kamal Mostafa 
---
 Documentation/devicetree/bindings/usb/dwc3.txt | 2 ++
 drivers/usb/dwc3/core.c| 6 ++
 drivers/usb/dwc3/core.h| 4 
 drivers/usb/dwc3/platform_data.h   | 1 +
 4 files changed, 13 insertions(+)

diff --git a/Documentation/devicetree/bindings/usb/dwc3.txt 
b/Documentation/devicetree/bindings/usb/dwc3.txt
index cd7f045..e3f2c72 100644
--- a/Documentation/devicetree/bindings/usb/dwc3.txt
+++ b/Documentation/devicetree/bindings/usb/dwc3.txt
@@ -34,6 +34,8 @@ Optional properties:
LTSSM during USB3 Compliance mode.
  - snps,dis_u3_susphy_quirk: when set core will disable USB3 suspend phy.
  - snps,dis_u2_susphy_quirk: when set core will disable USB2 suspend phy.
+ - snps,dis_enblslpm_quirk: when set clears the enblslpm in GUSB2PHYCFG,
+   disabling the suspend signal to the PHY.
  - 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
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 2687d33..d84b1af 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -425,6 +425,9 @@ static void dwc3_phy_setup(struct dwc3 *dwc)
if (dwc->dis_u2_susphy_quirk)
reg &= ~DWC3_GUSB2PHYCFG_SUSPHY;
 
+   if (dwc->dis_enblslpm_quirk)
+   reg &= ~DWC3_GUSB2PHYCFG_ENBLSLPM;
+
dwc3_writel(dwc->regs, DWC3_GUSB2PHYCFG(0), reg);
 
mdelay(100);
@@ -839,6 +842,8 @@ static int dwc3_probe(struct platform_device *pdev)
"snps,dis_u3_susphy_quirk");
dwc->dis_u2_susphy_quirk = of_property_read_bool(node,
"snps,dis_u2_susphy_quirk");
+   dwc->dis_enblslpm_quirk = device_property_read_bool(dev,
+   "snps,dis_enblslpm_quirk");
 
dwc->tx_de_emphasis_quirk = of_property_read_bool(node,
"snps,tx_de_emphasis_quirk");
@@ -866,6 +871,7 @@ static int dwc3_probe(struct platform_device *pdev)
dwc->rx_detect_poll_quirk = pdata->rx_detect_poll_quirk;
dwc->dis_u3_susphy_quirk = pdata->dis_u3_susphy_quirk;
dwc->dis_u2_susphy_quirk = pdata->dis_u2_susphy_quirk;
+   dwc->dis_enblslpm_quirk = pdata->dis_enblslpm_quirk;
 
dwc->tx_de_emphasis_quirk = pdata->tx_de_emphasis_quirk;
if (pdata->tx_de_emphasis)
diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
index 87fe55c..df92ff0 100644
--- a/drivers/usb/dwc3/core.h
+++ b/drivers/usb/dwc3/core.h
@@ -176,6 +176,7 @@
 /* Global USB2 PHY Configuration Register */
 #define DWC3_GUSB2PHYCFG_PHYSOFTRST(1 << 31)
 #define DWC3_GUSB2PHYCFG_SUSPHY(1 << 6)
+#define DWC3_GUSB2PHYCFG_ENBLSLPM  (1 << 8)
 
 /* Global USB3 PIPE Control Register */
 #define DWC3_GUSB3PIPECTL_PHYSOFTRST   (1 << 31)
@@ -706,6 +707,8 @@ struct dwc3_scratchpad_array {
  * @rx_detect_poll_quirk: set if we enable rx_detect to polling lfps quirk
  * @dis_u3_susphy_quirk: set if we disable usb3 suspend phy
  * @dis_u2_susphy_quirk: set if we disable usb2 suspend phy
+ * @dis_enblslpm_quirk: set if we clear enblslpm in GUSB2PHYCFG,
+ *  disabling the suspend signal to the PHY.
  * @tx_de_emphasis_quirk: set if we enable Tx de-emphasis quirk
  * @tx_de_emphasis: Tx de-emphasis value
  * 0   - -6dB de-emphasis
@@ -846,6 +849,7 @@ struct dwc3 {
unsignedrx_detect_poll_quirk:1;
unsigneddis_u3_susphy_quirk:1;
unsigneddis_u2_susphy_quirk:1;
+   unsigneddis_enblslpm_quirk:1;
 
unsignedtx_de_emphasis_quirk:1;
unsignedtx_de_emphasis:2;
diff --git a/drivers/usb/dwc3/platform_data.h b/drivers/usb/dwc3/platform_data.h
index a3a3b6d5..f0481f1 100644
--- a/drivers/usb/dwc3/platform_data.h
+++ b/drivers/usb/dwc3/platform_data.h
@@ -41,6 +41,7 @@ struct dwc3_platform_data {
unsigned rx_detect_poll_quirk:1;
unsigned dis_u3_susphy_quirk:1;
unsigned dis_u2_susphy_quirk:1;
+   unsigned dis_enblslpm_quirk:1;
 
unsigned tx_de_emphasis_quirk:1;
unsigned tx_de_emphasis:2;
-- 
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

[PATCH 3.19.y-ckt 037/164] nfsd: serialize state seqid morphing operations

[Kamal Mostafa]

3.19.8-ckt11 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Jeff Layton 

commit 35a92fe8770ce54c5eb275cd76128645bea2d200 upstream.

Andrew was seeing a race occur when an OPEN and OPEN_DOWNGRADE were
running in parallel. The server would receive the OPEN_DOWNGRADE first
and check its seqid, but then an OPEN would race in and bump it. The
OPEN_DOWNGRADE would then complete and bump the seqid again.  The result
was that the OPEN_DOWNGRADE would be applied after the OPEN, even though
it should have been rejected since the seqid changed.

The only recourse we have here I think is to serialize operations that
bump the seqid in a stateid, particularly when we're given a seqid in
the call. To address this, we add a new rw_semaphore to the
nfs4_ol_stateid struct. We do a down_write prior to checking the seqid
after looking up the stateid to ensure that nothing else is going to
bump it while we're operating on it.

In the case of OPEN, we do a down_read, as the call doesn't contain a
seqid. Those can run in parallel -- we just need to serialize them when
there is a concurrent OPEN_DOWNGRADE or CLOSE.

LOCK and LOCKU however always take the write lock as there is no
opportunity for parallelizing those.

Reported-and-Tested-by: Andrew W Elble 
Signed-off-by: Jeff Layton 
Signed-off-by: J. Bruce Fields 
[ kamal: backport to 3.19-stable: context ]
Signed-off-by: Kamal Mostafa 
---
 fs/nfsd/nfs4state.c | 33 -
 fs/nfsd/state.h | 17 +
 2 files changed, 37 insertions(+), 13 deletions(-)

diff --git a/fs/nfsd/nfs4state.c b/fs/nfsd/nfs4state.c
index 8bb73f8..2bf99cd 100644
--- a/fs/nfsd/nfs4state.c
+++ b/fs/nfsd/nfs4state.c
@@ -3262,6 +3262,7 @@ static void init_open_stateid(struct nfs4_ol_stateid 
*stp, struct nfs4_file *fp,
stp->st_access_bmap = 0;
stp->st_deny_bmap = 0;
stp->st_openstp = NULL;
+   init_rwsem(>st_rwsem);
spin_lock(>oo_owner.so_client->cl_lock);
list_add(>st_perstateowner, >oo_owner.so_stateids);
spin_lock(>fi_lock);
@@ -4083,21 +4084,27 @@ nfsd4_process_open2(struct svc_rqst *rqstp, struct 
svc_fh *current_fh, struct nf
 */
if (stp) {
/* Stateid was found, this is an OPEN upgrade */
+   down_read(>st_rwsem);
status = nfs4_upgrade_open(rqstp, fp, current_fh, stp, open);
-   if (status)
+   if (status) {
+   up_read(>st_rwsem);
goto out;
+   }
} else {
stp = open->op_stp;
open->op_stp = NULL;
init_open_stateid(stp, fp, open);
+   down_read(>st_rwsem);
status = nfs4_get_vfs_file(rqstp, fp, current_fh, stp, open);
if (status) {
+   up_read(>st_rwsem);
release_open_stateid(stp);
goto out;
}
}
update_stateid(>st_stid.sc_stateid);
memcpy(>op_stateid, >st_stid.sc_stateid, sizeof(stateid_t));
+   up_read(>st_rwsem);
 
if (nfsd4_has_session(>cstate)) {
if (open->op_deleg_want & NFS4_SHARE_WANT_NO_DELEG) {
@@ -4665,10 +4672,13 @@ static __be32 nfs4_seqid_op_checks(struct 
nfsd4_compound_state *cstate, stateid_
 * revoked delegations are kept only for free_stateid.
 */
return nfserr_bad_stateid;
+   down_write(>st_rwsem);
status = check_stateid_generation(stateid, >st_stid.sc_stateid, 
nfsd4_has_session(cstate));
-   if (status)
-   return status;
-   return nfs4_check_fh(current_fh, stp);
+   if (status == nfs_ok)
+   status = nfs4_check_fh(current_fh, stp);
+   if (status != nfs_ok)
+   up_write(>st_rwsem);
+   return status;
 }
 
 /* 
@@ -4715,6 +4725,7 @@ static __be32 nfs4_preprocess_confirmed_seqid_op(struct 
nfsd4_compound_state *cs
return status;
oo = openowner(stp->st_stateowner);
if (!(oo->oo_flags & NFS4_OO_CONFIRMED)) {
+   up_write(>st_rwsem);
nfs4_put_stid(>st_stid);
return nfserr_bad_stateid;
}
@@ -4745,11 +4756,14 @@ nfsd4_open_confirm(struct svc_rqst *rqstp, struct 
nfsd4_compound_state *cstate,
goto out;
oo = openowner(stp->st_stateowner);
status = nfserr_bad_stateid;
-   if (oo->oo_flags & NFS4_OO_CONFIRMED)
+   if (oo->oo_flags & NFS4_OO_CONFIRMED) {
+   up_write(>st_rwsem);
goto put_stateid;
+   }
oo->oo_flags |= NFS4_OO_CONFIRMED;
update_stateid(>st_stid.sc_stateid);
memcpy(>oc_resp_stateid, >st_stid.sc_stateid, 
sizeof(stateid_t));
+   up_write(>st_rwsem);
dprintk("NFSD: %s: success, seqid=%d stateid=" STATEID_FMT "\n",
__func__, oc->oc_seqid, 

[PATCH 3.19.y-ckt 041/164] iommu/vt-d: Fix ATSR handling for Root-Complex integrated endpoints

[Kamal Mostafa]

3.19.8-ckt11 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: David Woodhouse 

commit d14053b3c714178525f22660e6aaf41263d00056 upstream.

The VT-d specification says that "Software must enable ATS on endpoint
devices behind a Root Port only if the Root Port is reported as
supporting ATS transactions."

We walk up the tree to find a Root Port, but for integrated devices we
don't find one — we get to the host bridge. In that case we *should*
allow ATS. Currently we don't, which means that we are incorrectly
failing to use ATS for the integrated graphics. Fix that.

We should never break out of this loop "naturally" with bus==NULL,
since we'll always find bridge==NULL in that case (and now return 1).

So remove the check for (!bridge) after the loop, since it can never
happen. If it did, it would be worthy of a BUG_ON(!bridge). But since
it'll oops anyway in that case, that'll do just as well.

Signed-off-by: David Woodhouse 
Signed-off-by: Kamal Mostafa 
---
 drivers/iommu/intel-iommu.c | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
index 3583db4..1babfe7 100644
--- a/drivers/iommu/intel-iommu.c
+++ b/drivers/iommu/intel-iommu.c
@@ -3945,14 +3945,17 @@ int dmar_find_matched_atsr_unit(struct pci_dev *dev)
dev = pci_physfn(dev);
for (bus = dev->bus; bus; bus = bus->parent) {
bridge = bus->self;
-   if (!bridge || !pci_is_pcie(bridge) ||
+   /* If it's an integrated device, allow ATS */
+   if (!bridge)
+   return 1;
+   /* Connected via non-PCIe: no ATS */
+   if (!pci_is_pcie(bridge) ||
pci_pcie_type(bridge) == PCI_EXP_TYPE_PCI_BRIDGE)
return 0;
+   /* If we found the root port, look it up in the ATSR */
if (pci_pcie_type(bridge) == PCI_EXP_TYPE_ROOT_PORT)
break;
}
-   if (!bridge)
-   return 0;
 
rcu_read_lock();
list_for_each_entry_rcu(atsru, _atsr_units, list) {
-- 
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 3.19.y-ckt 042/164] Btrfs: fix truncation of compressed and inlined extents

[Kamal Mostafa]

3.19.8-ckt11 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Filipe Manana 

commit 0305cd5f7fca85dae392b9ba85b116896eb7c1c7 upstream.

When truncating a file to a smaller size which consists of an inline
extent that is compressed, we did not discard (or made unusable) the
data between the new file size and the old file size, wasting metadata
space and allowing for the truncated data to be leaked and the data
corruption/loss mentioned below.
We were also not correctly decrementing the number of bytes used by the
inode, we were setting it to zero, giving a wrong report for callers of
the stat(2) syscall. The fsck tool also reported an error about a mismatch
between the nbytes of the file versus the real space used by the file.

Now because we weren't discarding the truncated region of the file, it
was possible for a caller of the clone ioctl to actually read the data
that was truncated, allowing for a security breach without requiring root
access to the system, using only standard filesystem operations. The
scenario is the following:

   1) User A creates a file which consists of an inline and compressed
  extent with a size of 2000 bytes - the file is not accessible to
  any other users (no read, write or execution permission for anyone
  else);

   2) The user truncates the file to a size of 1000 bytes;

   3) User A makes the file world readable;

   4) User B creates a file consisting of an inline extent of 2000 bytes;

   5) User B issues a clone operation from user A's file into its own
  file (using a length argument of 0, clone the whole range);

   6) User B now gets to see the 1000 bytes that user A truncated from
  its file before it made its file world readbale. User B also lost
  the bytes in the range [1000, 2000[ bytes from its own file, but
  that might be ok if his/her intention was reading stale data from
  user A that was never supposed to be public.

Note that this contrasts with the case where we truncate a file from 2000
bytes to 1000 bytes and then truncate it back from 1000 to 2000 bytes. In
this case reading any byte from the range [1000, 2000[ will return a value
of 0x00, instead of the original data.

This problem exists since the clone ioctl was added and happens both with
and without my recent data loss and file corruption fixes for the clone
ioctl (patch "Btrfs: fix file corruption and data loss after cloning
inline extents").

So fix this by truncating the compressed inline extents as we do for the
non-compressed case, which involves decompressing, if the data isn't already
in the page cache, compressing the truncated version of the extent, writing
the compressed content into the inline extent and then truncate it.

The following test case for fstests reproduces the problem. In order for
the test to pass both this fix and my previous fix for the clone ioctl
that forbids cloning a smaller inline extent into a larger one,
which is titled "Btrfs: fix file corruption and data loss after cloning
inline extents", are needed. Without that other fix the test fails in a
different way that does not leak the truncated data, instead part of
destination file gets replaced with zeroes (because the destination file
has a larger inline extent than the source).

  seq=`basename $0`
  seqres=$RESULT_DIR/$seq
  echo "QA output created by $seq"
  tmp=/tmp/$$
  status=1  # failure is the default!
  trap "_cleanup; exit \$status" 0 1 2 3 15

  _cleanup()
  {
  rm -f $tmp.*
  }

  # get standard environment, filters and checks
  . ./common/rc
  . ./common/filter

  # real QA test starts here
  _need_to_be_root
  _supported_fs btrfs
  _supported_os Linux
  _require_scratch
  _require_cloner

  rm -f $seqres.full

  _scratch_mkfs >>$seqres.full 2>&1
  _scratch_mount "-o compress"

  # Create our test files. File foo is going to be the source of a clone 
operation
  # and consists of a single inline extent with an uncompressed size of 512 
bytes,
  # while file bar consists of a single inline extent with an uncompressed size 
of
  # 256 bytes. For our test's purpose, it's important that file bar has an 
inline
  # extent with a size smaller than foo's inline extent.
  $XFS_IO_PROG -f -c "pwrite -S 0xa1 0 128"   \
  -c "pwrite -S 0x2a 128 384" \
  $SCRATCH_MNT/foo | _filter_xfs_io
  $XFS_IO_PROG -f -c "pwrite -S 0xbb 0 256" $SCRATCH_MNT/bar | _filter_xfs_io

  # Now durably persist all metadata and data. We do this to make sure that we 
get
  # on disk an inline extent with a size of 512 bytes for file foo.
  sync

  # Now truncate our file foo to a smaller size. Because it consists of a
  # compressed and inline extent, btrfs did not shrink the inline extent to the
  # new size (if the extent was not compressed, btrfs would shrink it to 128
  # bytes), it only updates the inode's i_size to 128 bytes.
  $XFS_IO_PROG -c "truncate 128" $SCRATCH_MNT/foo

  # Now clone foo's inline extent into bar.
 

[PATCH 3.19.y-ckt 019/164] packet: race condition in packet_bind

[Kamal Mostafa]

3.19.8-ckt11 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Francesco Ruggeri 

[ Upstream commit 30f7ea1c2b5f5fb7462c5ae44fe2e40cb2d6a474 ]

There is a race conditions between packet_notifier and packet_bind{_spkt}.

It happens if packet_notifier(NETDEV_UNREGISTER) executes between the
time packet_bind{_spkt} takes a reference on the new netdevice and the
time packet_do_bind sets po->ifindex.
In this case the notification can be missed.
If this happens during a dev_change_net_namespace this can result in the
netdevice to be moved to the new namespace while the packet_sock in the
old namespace still holds a reference on it. When the netdevice is later
deleted in the new namespace the deletion hangs since the packet_sock
is not found in the new namespace' >packet.sklist.
It can be reproduced with the script below.

This patch makes packet_do_bind check again for the presence of the
netdevice in the packet_sock's namespace after the synchronize_net
in unregister_prot_hook.
More in general it also uses the rcu lock for the duration of the bind
to stop dev_change_net_namespace/rollback_registered_many from
going past the synchronize_net following unlist_netdevice, so that
no NETDEV_UNREGISTER notifications can happen on the new netdevice
while the bind is executing. In order to do this some code from
packet_bind{_spkt} is consolidated into packet_do_dev.

import socket, os, time, sys
proto=7
realDev='em1'
vlanId=400
if len(sys.argv) > 1:
   vlanId=int(sys.argv[1])
dev='vlan%d' % vlanId

os.system('taskset -p 0x10 %d' % os.getpid())

s = socket.socket(socket.PF_PACKET, socket.SOCK_RAW, proto)
os.system('ip link add link %s name %s type vlan id %d' %
  (realDev, dev, vlanId))
os.system('ip netns add dummy')

pid=os.fork()

if pid == 0:
   # dev should be moved while packet_do_bind is in synchronize net
   os.system('taskset -p 0x2 %d' % os.getpid())
   os.system('ip link set %s netns dummy' % dev)
   os.system('ip netns exec dummy ip link del %s' % dev)
   s.close()
   sys.exit(0)

time.sleep(.004)
try:
   s.bind(('%s' % dev, proto+1))
except:
   print 'Could not bind socket'
   s.close()
   os.system('ip netns del dummy')
   sys.exit(0)

os.waitpid(pid, 0)
s.close()
os.system('ip netns del dummy')
sys.exit(0)

Signed-off-by: Francesco Ruggeri 
Signed-off-by: David S. Miller 
Signed-off-by: Kamal Mostafa 
---
 net/packet/af_packet.c | 80 +++---
 1 file changed, 49 insertions(+), 31 deletions(-)

diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c
index 8da43cb..bfc1880 100644
--- a/net/packet/af_packet.c
+++ b/net/packet/af_packet.c
@@ -2665,22 +2665,40 @@ static int packet_release(struct socket *sock)
  * Attach a packet hook.
  */
 
-static int packet_do_bind(struct sock *sk, struct net_device *dev, __be16 
proto)
+static int packet_do_bind(struct sock *sk, const char *name, int ifindex,
+ __be16 proto)
 {
struct packet_sock *po = pkt_sk(sk);
struct net_device *dev_curr;
__be16 proto_curr;
bool need_rehook;
+   struct net_device *dev = NULL;
+   int ret = 0;
+   bool unlisted = false;
 
-   if (po->fanout) {
-   if (dev)
-   dev_put(dev);
-
+   if (po->fanout)
return -EINVAL;
-   }
 
lock_sock(sk);
spin_lock(>bind_lock);
+   rcu_read_lock();
+
+   if (name) {
+   dev = dev_get_by_name_rcu(sock_net(sk), name);
+   if (!dev) {
+   ret = -ENODEV;
+   goto out_unlock;
+   }
+   } else if (ifindex) {
+   dev = dev_get_by_index_rcu(sock_net(sk), ifindex);
+   if (!dev) {
+   ret = -ENODEV;
+   goto out_unlock;
+   }
+   }
+
+   if (dev)
+   dev_hold(dev);
 
proto_curr = po->prot_hook.type;
dev_curr = po->prot_hook.dev;
@@ -2688,14 +2706,29 @@ static int packet_do_bind(struct sock *sk, struct 
net_device *dev, __be16 proto)
need_rehook = proto_curr != proto || dev_curr != dev;
 
if (need_rehook) {
-   unregister_prot_hook(sk, true);
+   if (po->running) {
+   rcu_read_unlock();
+   __unregister_prot_hook(sk, true);
+   rcu_read_lock();
+   dev_curr = po->prot_hook.dev;
+   if (dev)
+   unlisted = !dev_get_by_index_rcu(sock_net(sk),
+dev->ifindex);
+   }
 
po->num = proto;
po->prot_hook.type = proto;
-   po->prot_hook.dev = dev;
 
-   po->ifindex = dev ? dev->ifindex : 0;
-   packet_cached_dev_assign(po, dev);
+   if (unlikely(unlisted)) {
+ 

[PATCH 3.19.y-ckt 031/164] integrity: prevent loading untrusted certificates on the IMA trusted keyring

[Kamal Mostafa]

3.19.8-ckt11 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Dmitry Kasatkin 

commit 72e1eed8abb11c79749266d433c817ce36732893 upstream.

If IMA_LOAD_X509 is enabled, either directly or indirectly via
IMA_APPRAISE_SIGNED_INIT, certificates are loaded onto the IMA
trusted keyring by the kernel via key_create_or_update(). When
the KEY_ALLOC_TRUSTED flag is provided, certificates are loaded
without first verifying the certificate is properly signed by a
trusted key on the system keyring.  This patch removes the
KEY_ALLOC_TRUSTED flag.

Signed-off-by: Dmitry Kasatkin 
Signed-off-by: Mimi Zohar 
Signed-off-by: Kamal Mostafa 
---
 security/integrity/digsig.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/security/integrity/digsig.c b/security/integrity/digsig.c
index 5e3bd72..972eb24 100644
--- a/security/integrity/digsig.c
+++ b/security/integrity/digsig.c
@@ -105,7 +105,7 @@ int __init integrity_load_x509(const unsigned int id, char 
*path)
   rc,
   ((KEY_POS_ALL & ~KEY_POS_SETATTR) |
KEY_USR_VIEW | KEY_USR_READ),
-  KEY_ALLOC_NOT_IN_QUOTA | KEY_ALLOC_TRUSTED);
+  KEY_ALLOC_NOT_IN_QUOTA);
if (IS_ERR(key)) {
rc = PTR_ERR(key);
pr_err("Problem loading X.509 certificate (%d): %s\n",
-- 
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 3.19.y-ckt 043/164] jbd2: fix checkpoint list cleanup

[Kamal Mostafa]

3.19.8-ckt11 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Jan Kara 

commit 33d14975e5ac469963d5d63856b61698ad0bff07 upstream.

Unlike comments and expectation of callers journal_clean_one_cp_list()
returned 1 not only if it freed the transaction but also if it freed
some buffers in the transaction. That could make
__jbd2_journal_clean_checkpoint_list() skip processing
t_checkpoint_io_list and continue with processing the next transaction.
This is mostly a cosmetic issue since the only result is we can
sometimes free less memory than we could. But it's still worth fixing.
Fix journal_clean_one_cp_list() to return 1 only if the transaction was
really freed.

Fixes: 50849db32a9f529235a84bcc84a6b8e631b1d0ec
Signed-off-by: Jan Kara 
Signed-off-by: Theodore Ts'o 
Signed-off-by: Kamal Mostafa 
---
 fs/jbd2/checkpoint.c | 8 +++-
 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/fs/jbd2/checkpoint.c b/fs/jbd2/checkpoint.c
index 8c44654..684996c 100644
--- a/fs/jbd2/checkpoint.c
+++ b/fs/jbd2/checkpoint.c
@@ -427,7 +427,6 @@ static int journal_clean_one_cp_list(struct journal_head 
*jh, bool destroy)
struct journal_head *last_jh;
struct journal_head *next_jh = jh;
int ret;
-   int freed = 0;
 
if (!jh)
return 0;
@@ -441,10 +440,9 @@ static int journal_clean_one_cp_list(struct journal_head 
*jh, bool destroy)
else
ret = __jbd2_journal_remove_checkpoint(jh) + 1;
if (!ret)
-   return freed;
+   return 0;
if (ret == 2)
return 1;
-   freed = 1;
/*
 * This function only frees up some memory
 * if possible so we dont have an obligation
@@ -452,10 +450,10 @@ static int journal_clean_one_cp_list(struct journal_head 
*jh, bool destroy)
 * requested:
 */
if (need_resched())
-   return freed;
+   return 0;
} while (jh != last_jh);
 
-   return freed;
+   return 0;
 }
 
 /*
-- 
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 3.19.y-ckt 001/164] x86/setup: Extend low identity map to cover whole kernel range

[Kamal Mostafa]

3.19.8-ckt11 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Paolo Bonzini 

commit f5f3497cad8c8416a74b9aaceb127908755d020a upstream.

On 32-bit systems, the initial_page_table is reused by
efi_call_phys_prolog as an identity map to call
SetVirtualAddressMap.  efi_call_phys_prolog takes care of
converting the current CPU's GDT to a physical address too.

For PAE kernels the identity mapping is achieved by aliasing the
first PDPE for the kernel memory mapping into the first PDPE
of initial_page_table.  This makes the EFI stub's trick "just work".

However, for non-PAE kernels there is no guarantee that the identity
mapping in the initial_page_table extends as far as the GDT; in this
case, accesses to the GDT will cause a page fault (which quickly becomes
a triple fault).  Fix this by copying the kernel mappings from
swapper_pg_dir to initial_page_table twice, both at PAGE_OFFSET and at
identity mapping.

For some reason, this is only reproducible with QEMU's dynamic translation
mode, and not for example with KVM.  However, even under KVM one can clearly
see that the page table is bogus:

$ qemu-system-i386 -pflash OVMF.fd -M q35 vmlinuz0 -s -S -daemonize
$ gdb
(gdb) target remote localhost:1234
(gdb) hb *0x02858f6f
Hardware assisted breakpoint 1 at 0x2858f6f
(gdb) c
Continuing.

Breakpoint 1, 0x02858f6f in ?? ()
(gdb) monitor info registers
...
GDT= 0724e000 00ff
IDT= fffbb000 07ff
CR0=0005003b CR2=ff896000 CR3=032b7000 CR4=0690
...

The page directory is sane:

(gdb) x/4wx 0x32b7000
0x32b7000:  0x03398063  0x03399063  0x0339a063  0x0339b063
(gdb) x/4wx 0x3398000
0x3398000:  0x0163  0x1163  0x2163  0x3163
(gdb) x/4wx 0x3399000
0x3399000:  0x0043  0x00401003  0x00402003  0x00403003

but our particular page directory entry is empty:

(gdb) x/1wx 0x32b7000 + (0x724e000 >> 22) * 4
0x32b7070:  0x

[ It appears that you can skate past this issue if you don't receive
  any interrupts while the bogus GDT pointer is loaded, or if you avoid
  reloading the segment registers in general.

  Andy Lutomirski provides some additional insight:

   "AFAICT it's entirely permissible for the GDTR and/or LDT
descriptor to point to unmapped memory.  Any attempt to use them
(segment loads, interrupts, IRET, etc) will try to access that memory
as if the access came from CPL 0 and, if the access fails, will
generate a valid page fault with CR2 pointing into the GDT or
LDT."

  Up until commit 23a0d4e8fa6d ("efi: Disable interrupts around EFI
  calls, not in the epilog/prolog calls") interrupts were disabled
  around the prolog and epilog calls, and the functional GDT was
  re-installed before interrupts were re-enabled.

  Which explains why no one has hit this issue until now. ]

Signed-off-by: Paolo Bonzini 
Reported-by: Laszlo Ersek 
Cc: Borislav Petkov 
Cc: "H. Peter Anvin" 
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: Andy Lutomirski 
Signed-off-by: Matt Fleming 
[ Updated changelog. ]

Signed-off-by: Kamal Mostafa 
---
 arch/x86/kernel/setup.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index ab4734e..5f660ca 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -1188,6 +1188,14 @@ void __init setup_arch(char **cmdline_p)
clone_pgd_range(initial_page_table + KERNEL_PGD_BOUNDARY,
swapper_pg_dir + KERNEL_PGD_BOUNDARY,
KERNEL_PGD_PTRS);
+
+   /*
+* sync back low identity map too.  It is used for example
+* in the 32-bit EFI stub.
+*/
+   clone_pgd_range(initial_page_table,
+   swapper_pg_dir + KERNEL_PGD_BOUNDARY,
+   KERNEL_PGD_PTRS);
 #endif
 
tboot_probe();
-- 
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 3.19.y-ckt 046/164] ext4, jbd2: ensure entering into panic after recording an error in superblock

[Kamal Mostafa]

3.19.8-ckt11 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Daeho Jeong 

commit 4327ba52afd03fc4b5afa0ee1d774c9c5b0e85c5 upstream.

If a EXT4 filesystem utilizes JBD2 journaling and an error occurs, the
journaling will be aborted first and the error number will be recorded
into JBD2 superblock and, finally, the system will enter into the
panic state in "errors=panic" option.  But, in the rare case, this
sequence is little twisted like the below figure and it will happen
that the system enters into panic state, which means the system reset
in mobile environment, before completion of recording an error in the
journal superblock. In this case, e2fsck cannot recognize that the
filesystem failure occurred in the previous run and the corruption
wouldn't be fixed.

Task ATask B
ext4_handle_error()
-> jbd2_journal_abort()
  -> __journal_abort_soft()
-> __jbd2_journal_abort_hard()
| -> journal->j_flags |= JBD2_ABORT;
|
| __ext4_abort()
| -> jbd2_journal_abort()
| | -> __journal_abort_soft()
| |   -> if (journal->j_flags & JBD2_ABORT)
| |   return;
| -> panic()
|
-> jbd2_journal_update_sb_errno()

Tested-by: Hobin Woo 
Signed-off-by: Daeho Jeong 
Signed-off-by: Theodore Ts'o 
Signed-off-by: Kamal Mostafa 
---
 fs/ext4/super.c  | 12 ++--
 fs/jbd2/journal.c|  6 +-
 include/linux/jbd2.h |  1 +
 3 files changed, 16 insertions(+), 3 deletions(-)

diff --git a/fs/ext4/super.c b/fs/ext4/super.c
index f46b29e..7eafbc1 100644
--- a/fs/ext4/super.c
+++ b/fs/ext4/super.c
@@ -395,9 +395,13 @@ static void ext4_handle_error(struct super_block *sb)
smp_wmb();
sb->s_flags |= MS_RDONLY;
}
-   if (test_opt(sb, ERRORS_PANIC))
+   if (test_opt(sb, ERRORS_PANIC)) {
+   if (EXT4_SB(sb)->s_journal &&
+ !(EXT4_SB(sb)->s_journal->j_flags & JBD2_REC_ERR))
+   return;
panic("EXT4-fs (device %s): panic forced after error\n",
sb->s_id);
+   }
 }
 
 #define ext4_error_ratelimit(sb)   \
@@ -586,8 +590,12 @@ void __ext4_abort(struct super_block *sb, const char 
*function,
jbd2_journal_abort(EXT4_SB(sb)->s_journal, -EIO);
save_error_info(sb, function, line);
}
-   if (test_opt(sb, ERRORS_PANIC))
+   if (test_opt(sb, ERRORS_PANIC)) {
+   if (EXT4_SB(sb)->s_journal &&
+ !(EXT4_SB(sb)->s_journal->j_flags & JBD2_REC_ERR))
+   return;
panic("EXT4-fs panic from previous error\n");
+   }
 }
 
 void __ext4_msg(struct super_block *sb,
diff --git a/fs/jbd2/journal.c b/fs/jbd2/journal.c
index 7003c09..0469f32 100644
--- a/fs/jbd2/journal.c
+++ b/fs/jbd2/journal.c
@@ -2086,8 +2086,12 @@ static void __journal_abort_soft (journal_t *journal, 
int errno)
 
__jbd2_journal_abort_hard(journal);
 
-   if (errno)
+   if (errno) {
jbd2_journal_update_sb_errno(journal);
+   write_lock(>j_state_lock);
+   journal->j_flags |= JBD2_REC_ERR;
+   write_unlock(>j_state_lock);
+   }
 }
 
 /**
diff --git a/include/linux/jbd2.h b/include/linux/jbd2.h
index 4caf8ac..c035001 100644
--- a/include/linux/jbd2.h
+++ b/include/linux/jbd2.h
@@ -1007,6 +1007,7 @@ struct journal_s
 #define JBD2_ABORT_ON_SYNCDATA_ERR 0x040   /* Abort the journal on file
 * data write error in ordered
 * mode */
+#define JBD2_REC_ERR   0x080   /* The errno in the sb has been recorded */
 
 /*
  * Function declarations for the journaling transaction and buffer
-- 
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 3.19.y-ckt 044/164] ext4: fix potential use after free in __ext4_journal_stop

[Kamal Mostafa]

3.19.8-ckt11 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Lukas Czerner 

commit 6934da9238da947628be83635e365df41064b09b upstream.

There is a use-after-free possibility in __ext4_journal_stop() in the
case that we free the handle in the first jbd2_journal_stop() because
we're referencing handle->h_err afterwards. This was introduced in
9705acd63b125dee8b15c705216d7186daea4625 and it is wrong. Fix it by
storing the handle->h_err value beforehand and avoid referencing
potentially freed handle.

Fixes: 9705acd63b125dee8b15c705216d7186daea4625
Signed-off-by: Lukas Czerner 
Reviewed-by: Andreas Dilger 
Signed-off-by: Kamal Mostafa 
---
 fs/ext4/ext4_jbd2.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/fs/ext4/ext4_jbd2.c b/fs/ext4/ext4_jbd2.c
index d418431..e770c1ee 100644
--- a/fs/ext4/ext4_jbd2.c
+++ b/fs/ext4/ext4_jbd2.c
@@ -88,13 +88,13 @@ int __ext4_journal_stop(const char *where, unsigned int 
line, handle_t *handle)
return 0;
}
 
+   err = handle->h_err;
if (!handle->h_transaction) {
-   err = jbd2_journal_stop(handle);
-   return handle->h_err ? handle->h_err : err;
+   rc = jbd2_journal_stop(handle);
+   return err ? err : rc;
}
 
sb = handle->h_transaction->t_journal->j_private;
-   err = handle->h_err;
rc = jbd2_journal_stop(handle);
 
if (!err)
-- 
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 3.19.y-ckt 045/164] [PATCH] fix calculation of meta_bg descriptor backups

[Kamal Mostafa]

3.19.8-ckt11 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Andy Leiserson 

commit 904dad4742d211b7a8910e92695c0fa957483836 upstream.

"group" is the group where the backup will be placed, and is
initialized to zero in the declaration. This meant that backups for
meta_bg descriptors were erroneously written to the backup block group
descriptors in groups 1 and (desc_per_block-1).

Reproduction information:
  mke2fs -Fq -t ext4 -b 1024 -O ^resize_inode /tmp/foo.img 16G
  truncate -s 24G /tmp/foo.img
  losetup /dev/loop0 /tmp/foo.img
  mount /dev/loop0 /mnt
  resize2fs /dev/loop0
  umount /dev/loop0
  dd if=/dev/zero of=/dev/loop0 bs=1024 count=2
  e2fsck -fy /dev/loop0
  losetup -d /dev/loop0

Signed-off-by: Andy Leiserson 
Signed-off-by: Theodore Ts'o 
Signed-off-by: Kamal Mostafa 
---
 fs/ext4/resize.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/fs/ext4/resize.c b/fs/ext4/resize.c
index 8a8ec62..c30ed18 100644
--- a/fs/ext4/resize.c
+++ b/fs/ext4/resize.c
@@ -1040,7 +1040,7 @@ exit_free:
  * do not copy the full number of backups at this time.  The resize
  * which changed s_groups_count will backup again.
  */
-static void update_backups(struct super_block *sb, int blk_off, char *data,
+static void update_backups(struct super_block *sb, sector_t blk_off, char 
*data,
   int size, int meta_bg)
 {
struct ext4_sb_info *sbi = EXT4_SB(sb);
@@ -1065,7 +1065,7 @@ static void update_backups(struct super_block *sb, int 
blk_off, char *data,
group = ext4_list_backups(sb, , , );
last = sbi->s_groups_count;
} else {
-   group = ext4_meta_bg_first_group(sb, group) + 1;
+   group = ext4_get_group_number(sb, blk_off) + 1;
last = (ext4_group_t)(group + EXT4_DESC_PER_BLOCK(sb) - 2);
}
 
-- 
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 3.19.y-ckt 038/164] lockd: create NSM handles per net namespace

[Kamal Mostafa]

3.19.8-ckt11 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Andrey Ryabinin 

commit 0ad95472bf169a3501991f8f33f5147f792a8116 upstream.

Commit cb7323fffa85 ("lockd: create and use per-net NSM
 RPC clients on MON/UNMON requests") introduced per-net
NSM RPC clients. Unfortunately this doesn't make any sense
without per-net nsm_handle.

E.g. the following scenario could happen
Two hosts (X and Y) in different namespaces (A and B) share
the same nsm struct.

1. nsm_monitor(host_X) called => NSM rpc client created,
nsm->sm_monitored bit set.
2. nsm_mointor(host-Y) called => nsm->sm_monitored already set,
we just exit. Thus in namespace B ln->nsm_clnt == NULL.
3. host X destroyed => nsm->sm_count decremented to 1
4. host Y destroyed => nsm_unmonitor() => nsm_mon_unmon() => NULL-ptr
dereference of *ln->nsm_clnt

So this could be fixed by making per-net nsm_handles list,
instead of global. Thus different net namespaces will not be able
share the same nsm_handle.

Signed-off-by: Andrey Ryabinin 
Signed-off-by: J. Bruce Fields 
Signed-off-by: Kamal Mostafa 
---
 fs/lockd/host.c |  7 ---
 fs/lockd/mon.c  | 36 ++--
 fs/lockd/netns.h|  1 +
 fs/lockd/svc.c  |  1 +
 fs/lockd/svc4proc.c |  2 +-
 fs/lockd/svcproc.c  |  2 +-
 include/linux/lockd/lockd.h |  9 ++---
 7 files changed, 36 insertions(+), 22 deletions(-)

diff --git a/fs/lockd/host.c b/fs/lockd/host.c
index 969d589..b5f3c3a 100644
--- a/fs/lockd/host.c
+++ b/fs/lockd/host.c
@@ -116,7 +116,7 @@ static struct nlm_host *nlm_alloc_host(struct 
nlm_lookup_host_info *ni,
atomic_inc(>sm_count);
else {
host = NULL;
-   nsm = nsm_get_handle(ni->sap, ni->salen,
+   nsm = nsm_get_handle(ni->net, ni->sap, ni->salen,
ni->hostname, ni->hostname_len);
if (unlikely(nsm == NULL)) {
dprintk("lockd: %s failed; no nsm handle\n",
@@ -534,17 +534,18 @@ static struct nlm_host *next_host_state(struct hlist_head 
*cache,
 
 /**
  * nlm_host_rebooted - Release all resources held by rebooted host
+ * @net:  network namespace
  * @info: pointer to decoded results of NLM_SM_NOTIFY call
  *
  * We were notified that the specified host has rebooted.  Release
  * all resources held by that peer.
  */
-void nlm_host_rebooted(const struct nlm_reboot *info)
+void nlm_host_rebooted(const struct net *net, const struct nlm_reboot *info)
 {
struct nsm_handle *nsm;
struct nlm_host *host;
 
-   nsm = nsm_reboot_lookup(info);
+   nsm = nsm_reboot_lookup(net, info);
if (unlikely(nsm == NULL))
return;
 
diff --git a/fs/lockd/mon.c b/fs/lockd/mon.c
index 47a32b6..6c05cd1 100644
--- a/fs/lockd/mon.c
+++ b/fs/lockd/mon.c
@@ -51,7 +51,6 @@ struct nsm_res {
 };
 
 static const struct rpc_programnsm_program;
-static LIST_HEAD(nsm_handles);
 static DEFINE_SPINLOCK(nsm_lock);
 
 /*
@@ -264,33 +263,35 @@ void nsm_unmonitor(const struct nlm_host *host)
}
 }
 
-static struct nsm_handle *nsm_lookup_hostname(const char *hostname,
- const size_t len)
+static struct nsm_handle *nsm_lookup_hostname(const struct list_head 
*nsm_handles,
+   const char *hostname, const size_t len)
 {
struct nsm_handle *nsm;
 
-   list_for_each_entry(nsm, _handles, sm_link)
+   list_for_each_entry(nsm, nsm_handles, sm_link)
if (strlen(nsm->sm_name) == len &&
memcmp(nsm->sm_name, hostname, len) == 0)
return nsm;
return NULL;
 }
 
-static struct nsm_handle *nsm_lookup_addr(const struct sockaddr *sap)
+static struct nsm_handle *nsm_lookup_addr(const struct list_head *nsm_handles,
+   const struct sockaddr *sap)
 {
struct nsm_handle *nsm;
 
-   list_for_each_entry(nsm, _handles, sm_link)
+   list_for_each_entry(nsm, nsm_handles, sm_link)
if (rpc_cmp_addr(nsm_addr(nsm), sap))
return nsm;
return NULL;
 }
 
-static struct nsm_handle *nsm_lookup_priv(const struct nsm_private *priv)
+static struct nsm_handle *nsm_lookup_priv(const struct list_head *nsm_handles,
+   const struct nsm_private *priv)
 {
struct nsm_handle *nsm;
 
-   list_for_each_entry(nsm, _handles, sm_link)
+   list_for_each_entry(nsm, nsm_handles, sm_link)
if (memcmp(nsm->sm_priv.data, priv->data,
sizeof(priv->data)) == 0)
return nsm;
@@ -353,6 +354,7 @@ static struct nsm_handle *nsm_create_handle(const struct 
sockaddr *sap,
 
 /**
  * nsm_get_handle - Find or 

[PATCH 3.19.y-ckt 039/164] Btrfs: fix file corruption and data loss after cloning inline extents

[Kamal Mostafa]

3.19.8-ckt11 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Filipe Manana 

commit 8039d87d9e473aeb740d4fdbd59b9d2f89b2ced9 upstream.

Currently the clone ioctl allows to clone an inline extent from one file
to another that already has other (non-inlined) extents. This is a problem
because btrfs is not designed to deal with files having inline and regular
extents, if a file has an inline extent then it must be the only extent
in the file and must start at file offset 0. Having a file with an inline
extent followed by regular extents results in EIO errors when doing reads
or writes against the first 4K of the file.

Also, the clone ioctl allows one to lose data if the source file consists
of a single inline extent, with a size of N bytes, and the destination
file consists of a single inline extent with a size of M bytes, where we
have M > N. In this case the clone operation removes the inline extent
from the destination file and then copies the inline extent from the
source file into the destination file - we lose the M - N bytes from the
destination file, a read operation will get the value 0x00 for any bytes
in the the range [N, M] (the destination inode's i_size remained as M,
that's why we can read past N bytes).

So fix this by not allowing such destructive operations to happen and
return errno EOPNOTSUPP to user space.

Currently the fstest btrfs/035 tests the data loss case but it totally
ignores this - i.e. expects the operation to succeed and does not check
the we got data loss.

The following test case for fstests exercises all these cases that result
in file corruption and data loss:

  seq=`basename $0`
  seqres=$RESULT_DIR/$seq
  echo "QA output created by $seq"
  tmp=/tmp/$$
  status=1  # failure is the default!
  trap "_cleanup; exit \$status" 0 1 2 3 15

  _cleanup()
  {
  rm -f $tmp.*
  }

  # get standard environment, filters and checks
  . ./common/rc
  . ./common/filter

  # real QA test starts here
  _need_to_be_root
  _supported_fs btrfs
  _supported_os Linux
  _require_scratch
  _require_cloner
  _require_btrfs_fs_feature "no_holes"
  _require_btrfs_mkfs_feature "no-holes"

  rm -f $seqres.full

  test_cloning_inline_extents()
  {
  local mkfs_opts=$1
  local mount_opts=$2

  _scratch_mkfs $mkfs_opts >>$seqres.full 2>&1
  _scratch_mount $mount_opts

  # File bar, the source for all the following clone operations, consists
  # of a single inline extent (50 bytes).
  $XFS_IO_PROG -f -c "pwrite -S 0xbb 0 50" $SCRATCH_MNT/bar \
  | _filter_xfs_io

  # Test cloning into a file with an extent (non-inlined) where the
  # destination offset overlaps that extent. It should not be possible to
  # clone the inline extent from file bar into this file.
  $XFS_IO_PROG -f -c "pwrite -S 0xaa 0K 16K" $SCRATCH_MNT/foo \
  | _filter_xfs_io
  $CLONER_PROG -s 0 -d 0 -l 0 $SCRATCH_MNT/bar $SCRATCH_MNT/foo

  # Doing IO against any range in the first 4K of the file should work.
  # Due to a past clone ioctl bug which allowed cloning the inline extent,
  # these operations resulted in EIO errors.
  echo "File foo data after clone operation:"
  # All bytes should have the value 0xaa (clone operation failed and did
  # not modify our file).
  od -t x1 $SCRATCH_MNT/foo
  $XFS_IO_PROG -c "pwrite -S 0xcc 0 100" $SCRATCH_MNT/foo | _filter_xfs_io

  # Test cloning the inline extent against a file which has a hole in its
  # first 4K followed by a non-inlined extent. It should not be possible
  # as well to clone the inline extent from file bar into this file.
  $XFS_IO_PROG -f -c "pwrite -S 0xdd 4K 12K" $SCRATCH_MNT/foo2 \
  | _filter_xfs_io
  $CLONER_PROG -s 0 -d 0 -l 0 $SCRATCH_MNT/bar $SCRATCH_MNT/foo2

  # Doing IO against any range in the first 4K of the file should work.
  # Due to a past clone ioctl bug which allowed cloning the inline extent,
  # these operations resulted in EIO errors.
  echo "File foo2 data after clone operation:"
  # All bytes should have the value 0x00 (clone operation failed and did
  # not modify our file).
  od -t x1 $SCRATCH_MNT/foo2
  $XFS_IO_PROG -c "pwrite -S 0xee 0 90" $SCRATCH_MNT/foo2 | _filter_xfs_io

  # Test cloning the inline extent against a file which has a size of zero
  # but has a prealloc extent. It should not be possible as well to clone
  # the inline extent from file bar into this file.
  $XFS_IO_PROG -f -c "falloc -k 0 1M" $SCRATCH_MNT/foo3 | _filter_xfs_io
  $CLONER_PROG -s 0 -d 0 -l 0 $SCRATCH_MNT/bar $SCRATCH_MNT/foo3

  # Doing IO against any range in the first 4K of the file should work.
  # Due to a past clone ioctl bug which allowed cloning the inline extent,
  # these operations resulted in EIO errors.
  echo "First 50 bytes of foo3 after clone operation:"
  # Should not be able to read any bytes, 

[PATCH 3.19.y-ckt 048/164] spi: dw: explicitly free IRQ handler in dw_spi_remove_host()

[Kamal Mostafa]

3.19.8-ckt11 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Andy Shevchenko 

commit 02f20387e1bca550639c37b1945f20cd32ddfcce upstream.

The following warning occurs when DW SPI is compiled as a module and it's a PCI
device. On the removal stage pcibios_free_irq() is called earlier than
free_irq() due to the latter is called at managed resources free strage.

[ cut here ]
WARNING: CPU: 1 PID: 1003 at /home/andy/prj/linux/fs/proc/generic.c:575 
remove_proc_entry+0x118/0x150()
remove_proc_entry: removing non-empty directory 'irq/38', leaking at least 
'dw_spi1'
Modules linked in: spi_dw_midpci(-) spi_dw [last unloaded: dw_dmac_core]
CPU: 1 PID: 1003 Comm: modprobe Not tainted 4.3.0-rc5-next-20151013+ #32
   f5535d70 c12dc220 f5535db0 f5535da0 c104e912 c198a6bc
 f5535dcc 03eb c198a638 023f c11b4098 c11b4098 f54f1ec8 f54f1ea0
 f642ba20 f5535db8 c104e96e 0009 f5535db0 c198a6bc f5535dcc f5535df0
Call Trace:
 [] dump_stack+0x41/0x61
 [] warn_slowpath_common+0x82/0xb0
 [] ? remove_proc_entry+0x118/0x150
 [] ? remove_proc_entry+0x118/0x150
 [] warn_slowpath_fmt+0x2e/0x30
 [] remove_proc_entry+0x118/0x150
 [] unregister_irq_proc+0xaa/0xc0
 [] free_desc+0x1e/0x60
 [] irq_free_descs+0x32/0x70
 [] irq_domain_free_irqs+0x120/0x150
 [] mp_unmap_irq+0x5c/0x60
 [] intel_mid_pci_irq_disable+0x20/0x40
 [] pcibios_free_irq+0xf/0x20
 [] pci_device_remove+0x52/0xb0
 [] __device_release_driver+0x77/0x100
 [] driver_detach+0x87/0x90
 [] bus_remove_driver+0x4a/0xc0
 [] ? selinux_capable+0xd/0x10
 [] driver_unregister+0x23/0x60
 [] ? find_module_all+0x5a/0x80
 [] pci_unregister_driver+0x13/0x60
 [] dw_spi_driver_exit+0xd/0xf [spi_dw_midpci]
 [] SyS_delete_module+0x17a/0x210

Explicitly call free_irq() at removal stage of the DW SPI driver.

Fixes: 04f421e7b0b1 (spi: dw: use managed resources)
Signed-off-by: Andy Shevchenko 
Signed-off-by: Mark Brown 
[ luis: backported to 3.16: adjusted context ]
Signed-off-by: Luis Henriques 
Signed-off-by: Kamal Mostafa 
---
 drivers/spi/spi-dw.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/spi/spi-dw.c b/drivers/spi/spi-dw.c
index 8edcd1b..67ce090 100644
--- a/drivers/spi/spi-dw.c
+++ b/drivers/spi/spi-dw.c
@@ -650,8 +650,7 @@ int dw_spi_add_host(struct device *dev, struct dw_spi *dws)
dws->dma_addr = (dma_addr_t)(dws->paddr + 0x60);
snprintf(dws->name, sizeof(dws->name), "dw_spi%d", dws->bus_num);
 
-   ret = devm_request_irq(dev, dws->irq, dw_spi_irq, IRQF_SHARED,
-   dws->name, dws);
+   ret = request_irq(dws->irq, dw_spi_irq, IRQF_SHARED, dws->name, dws);
if (ret < 0) {
dev_err(>dev, "can not get IRQ\n");
goto err_free_master;
@@ -694,6 +693,7 @@ err_dma_exit:
if (dws->dma_ops && dws->dma_ops->dma_exit)
dws->dma_ops->dma_exit(dws);
spi_enable_chip(dws, 0);
+   free_irq(dws->irq, master);
 err_free_master:
spi_master_put(master);
return ret;
@@ -711,6 +711,8 @@ void dw_spi_remove_host(struct dw_spi *dws)
spi_enable_chip(dws, 0);
/* Disable clk */
spi_set_clk(dws, 0);
+
+   free_irq(dws->irq, dws->master);
 }
 EXPORT_SYMBOL_GPL(dw_spi_remove_host);
 
-- 
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 3.19.y-ckt 047/164] vTPM: fix memory allocation flag for rtce buffer at kernel boot

[Kamal Mostafa]

3.19.8-ckt11 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: "Hon Ching (Vicky) Lo" 

commit 60ecd86c4d985750efa0ea3d8610972b09951715 upstream.

At ibm vtpm initialzation, tpm_ibmvtpm_probe() registers its interrupt
handler, ibmvtpm_interrupt, which calls ibmvtpm_crq_process to allocate
memory for rtce buffer.  The current code uses 'GFP_KERNEL' as the
type of kernel memory allocation, which resulted a warning at
kernel/lockdep.c.  This patch uses 'GFP_ATOMIC' instead so that the
allocation is high-priority and does not sleep.

Signed-off-by: Hon Ching(Vicky) Lo 
Signed-off-by: Peter Huewe 
Signed-off-by: Kamal Mostafa 
---
 drivers/char/tpm/tpm_ibmvtpm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/char/tpm/tpm_ibmvtpm.c b/drivers/char/tpm/tpm_ibmvtpm.c
index 643bba7..9eab751 100644
--- a/drivers/char/tpm/tpm_ibmvtpm.c
+++ b/drivers/char/tpm/tpm_ibmvtpm.c
@@ -490,7 +490,7 @@ static void ibmvtpm_crq_process(struct ibmvtpm_crq *crq,
}
ibmvtpm->rtce_size = be16_to_cpu(crq->len);
ibmvtpm->rtce_buf = kmalloc(ibmvtpm->rtce_size,
-   GFP_KERNEL);
+   GFP_ATOMIC);
if (!ibmvtpm->rtce_buf) {
dev_err(ibmvtpm->dev, "Failed to allocate 
memory for rtce buffer\n");
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/

[PATCH 3.19.y-ckt 054/164] Bluetooth: ath3k: Add support of AR3012 0cf3:817b device

[Kamal Mostafa]

3.19.8-ckt11 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Dmitry Tunin 

commit 18e0afab8ce3f1230ce3fef52b2e73374fd9c0e7 upstream.

T: Bus=04 Lev=02 Prnt=02 Port=04 Cnt=01 Dev#= 3 Spd=12 MxCh= 0
D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=0cf3 ProdID=817b Rev=00.02
C: #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
I: If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
I: If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb

BugLink: https://bugs.launchpad.net/bugs/1506615

Signed-off-by: Dmitry Tunin 
Signed-off-by: Marcel Holtmann 
Signed-off-by: Kamal Mostafa 
---
 drivers/bluetooth/ath3k.c | 2 ++
 drivers/bluetooth/btusb.c | 1 +
 2 files changed, 3 insertions(+)

diff --git a/drivers/bluetooth/ath3k.c b/drivers/bluetooth/ath3k.c
index ecd520f..81f6a885 100644
--- a/drivers/bluetooth/ath3k.c
+++ b/drivers/bluetooth/ath3k.c
@@ -105,6 +105,7 @@ static const struct usb_device_id ath3k_table[] = {
{ USB_DEVICE(0x0CF3, 0x311F) },
{ USB_DEVICE(0x0cf3, 0x3121) },
{ USB_DEVICE(0x0CF3, 0x817a) },
+   { USB_DEVICE(0x0CF3, 0x817b) },
{ USB_DEVICE(0x0cf3, 0xe003) },
{ USB_DEVICE(0x0CF3, 0xE004) },
{ USB_DEVICE(0x0CF3, 0xE005) },
@@ -165,6 +166,7 @@ static const struct usb_device_id ath3k_blist_tbl[] = {
{ USB_DEVICE(0x0cf3, 0x311F), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x0cf3, 0x3121), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x0CF3, 0x817a), .driver_info = BTUSB_ATH3012 },
+   { USB_DEVICE(0x0CF3, 0x817b), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x0cf3, 0xe004), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x0cf3, 0xe005), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x0cf3, 0xe003), .driver_info = BTUSB_ATH3012 },
diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index 9565dc6..402c15c 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -193,6 +193,7 @@ static const struct usb_device_id blacklist_table[] = {
{ USB_DEVICE(0x0cf3, 0x311f), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x0cf3, 0x3121), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x0cf3, 0x817a), .driver_info = BTUSB_ATH3012 },
+   { USB_DEVICE(0x0cf3, 0x817b), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x0cf3, 0xe003), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x0cf3, 0xe004), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x0cf3, 0xe005), .driver_info = BTUSB_ATH3012 },
-- 
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 3.19.y-ckt 040/164] ARM: common: edma: Fix channel parameter for irq callbacks

[Kamal Mostafa]

3.19.8-ckt11 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Peter Ujfalusi 

commit 696d8b70c09dd421c4d037fab04341e5b30585cf upstream.

In case when the interrupt happened for the second eDMA the channel
number was incorrectly passed to the client driver.

Signed-off-by: Peter Ujfalusi 
Signed-off-by: Vinod Koul 
Signed-off-by: Kamal Mostafa 
---
 arch/arm/common/edma.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/arch/arm/common/edma.c b/arch/arm/common/edma.c
index 5662a87..3061320 100644
--- a/arch/arm/common/edma.c
+++ b/arch/arm/common/edma.c
@@ -406,7 +406,8 @@ static irqreturn_t dma_irq_handler(int irq, void *data)
BIT(slot));
if (edma_cc[ctlr]->intr_data[channel].callback)
edma_cc[ctlr]->intr_data[channel].callback(
-   channel, EDMA_DMA_COMPLETE,
+   EDMA_CTLR_CHAN(ctlr, channel),
+   EDMA_DMA_COMPLETE,
edma_cc[ctlr]->intr_data[channel].data);
}
} while (sh_ipr);
@@ -460,7 +461,8 @@ static irqreturn_t dma_ccerr_handler(int irq, void *data)
if (edma_cc[ctlr]->intr_data[k].
callback) {
edma_cc[ctlr]->intr_data[k].
-   callback(k,
+   callback(
+   EDMA_CTLR_CHAN(ctlr, k),
EDMA_DMA_CC_ERROR,
edma_cc[ctlr]->intr_data
[k].data);
-- 
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 3.19.y-ckt 051/164] [media] media/v4l2-ctrls: fix setting autocluster to manual with VIDIOC_S_CTRL

[Kamal Mostafa]

3.19.8-ckt11 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Antonio Ospite 

commit 759b26a1d916400a1a20948eb964dea6ad0bd9e9 upstream.

Since commit 5d0360a4f027576e5419d4a7c711c9ca0f1be8ca it's not possible
anymore to set auto clusters from auto to manual using VIDIOC_S_CTRL.

For example, setting autogain to manual with gspca/ov534 driver and this
sequence of commands does not work:

  v4l2-ctl --set-ctrl=gain_automatic=1
  v4l2-ctl --list-ctrls | grep gain_automatic
  # The following does not work
  v4l2-ctl --set-ctrl=gain_automatic=0
  v4l2-ctl --list-ctrls | grep gain_automatic

Changing the value using VIDIOC_S_EXT_CTRLS (like qv4l2 does) works
fine.

The apparent cause by looking at the changes in 5d0360a and comparing
with the code path for VIDIOC_S_EXT_CTRLS seems to be that the code in
v4l2-ctrls.c::set_ctrl() is not calling user_to_new() anymore after
calling update_from_auto_cluster(master).

However the root cause of the problem is that calling
update_from_auto_cluster(master) overrides also the _master_ control
state calling cur_to_new() while it was supposed to only update the
volatile controls.

Calling user_to_new() after update_from_auto_cluster(master) was just
masking the original bug by restoring the correct new value of the
master control before making the changes permanent.

Fix the original bug by making update_from_auto_cluster() not override
the new master control value.

Signed-off-by: Antonio Ospite 
Signed-off-by: Hans Verkuil 
Signed-off-by: Mauro Carvalho Chehab 
Signed-off-by: Kamal Mostafa 
---
 drivers/media/v4l2-core/v4l2-ctrls.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c 
b/drivers/media/v4l2-core/v4l2-ctrls.c
index 2e98f02..d85c260 100644
--- a/drivers/media/v4l2-core/v4l2-ctrls.c
+++ b/drivers/media/v4l2-core/v4l2-ctrls.c
@@ -3042,7 +3042,7 @@ static void update_from_auto_cluster(struct v4l2_ctrl 
*master)
 {
int i;
 
-   for (i = 0; i < master->ncontrols; i++)
+   for (i = 1; i < master->ncontrols; i++)
cur_to_new(master->cluster[i]);
if (!call_op(master, g_volatile_ctrl))
for (i = 1; i < master->ncontrols; i++)
-- 
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 3.19.y-ckt 052/164] Bluetooth: hidp: fix device disconnect on idle timeout

[Kamal Mostafa]

3.19.8-ckt11 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: David Herrmann 

commit 660f0fc07d21114549c1862e67e78b1cf0c90c29 upstream.

The HIDP specs define an idle-timeout which automatically disconnects a
device. This has always been implemented in the HIDP layer and forced a
synchronous shutdown of the hidp-scheduler. This works just fine, but
lacks a forced disconnect on the underlying l2cap channels. This has been
broken since:

commit 5205185d461d5902325e457ca80bd421127b7308
Author: David Herrmann 
Date:   Sat Apr 6 20:28:47 2013 +0200

Bluetooth: hidp: remove old session-management

The old session-management always forced an l2cap error on the ctrl/intr
channels when shutting down. The new session-management skips this, as we
don't want to enforce channel policy on the caller. In other words, if
user-space removes an HIDP device, the underlying channels (which are
*owned* and *referenced* by user-space) are still left active. User-space
needs to call shutdown(2) or close(2) to release them.

Unfortunately, this does not work with idle-timeouts. There is no way to
signal user-space that the HIDP layer has been stopped. The API simply
does not support any event-passing except for poll(2). Hence, we restore
old behavior and force EUNATCH on the sockets if the HIDP layer is
disconnected due to idle-timeouts (behavior of explicit disconnects
remains unmodified). User-space can still call

getsockopt(..., SO_ERROR, ...)

..to retrieve the EUNATCH error and clear sk_err. Hence, the channels can
still be re-used (which nobody does so far, though). Therefore, the API
still supports the new behavior, but with this patch it's also compatible
to the old implicit channel shutdown.

Reported-by: Mark Haun 
Reported-by: Luiz Augusto von Dentz 
Signed-off-by: David Herrmann 
Signed-off-by: Marcel Holtmann 
Signed-off-by: Kamal Mostafa 
---
 net/bluetooth/hidp/core.c | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/net/bluetooth/hidp/core.c b/net/bluetooth/hidp/core.c
index 07348e1..8554353 100644
--- a/net/bluetooth/hidp/core.c
+++ b/net/bluetooth/hidp/core.c
@@ -400,6 +400,20 @@ static void hidp_idle_timeout(unsigned long arg)
 {
struct hidp_session *session = (struct hidp_session *) arg;
 
+   /* The HIDP user-space API only contains calls to add and remove
+* devices. There is no way to forward events of any kind. Therefore,
+* we have to forcefully disconnect a device on idle-timeouts. This is
+* unfortunate and weird API design, but it is spec-compliant and
+* required for backwards-compatibility. Hence, on idle-timeout, we
+* signal driver-detach events, so poll() will be woken up with an
+* error-condition on both sockets.
+*/
+
+   session->intr_sock->sk->sk_err = EUNATCH;
+   session->ctrl_sock->sk->sk_err = EUNATCH;
+   wake_up_interruptible(sk_sleep(session->intr_sock->sk));
+   wake_up_interruptible(sk_sleep(session->ctrl_sock->sk));
+
hidp_session_terminate(session);
 }
 
-- 
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 3.19.y-ckt 053/164] Bluetooth: ath3k: Add new AR3012 0930:021c id

[Kamal Mostafa]

3.19.8-ckt11 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Dmitry Tunin 

commit cd355ff071cd37e7197eccf9216770b2b29369f7 upstream.

This adapter works with the existing linux-firmware.

T:  Bus=01 Lev=01 Prnt=01 Port=03 Cnt=02 Dev#=  3 Spd=12  MxCh= 0
D:  Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs=  1
P:  Vendor=0930 ProdID=021c Rev=00.01
C:  #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
I:  If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
I:  If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb

BugLink: https://bugs.launchpad.net/bugs/1502781

Signed-off-by: Dmitry Tunin 
Signed-off-by: Marcel Holtmann 
Signed-off-by: Kamal Mostafa 
---
 drivers/bluetooth/ath3k.c | 2 ++
 drivers/bluetooth/btusb.c | 1 +
 2 files changed, 3 insertions(+)

diff --git a/drivers/bluetooth/ath3k.c b/drivers/bluetooth/ath3k.c
index 8dc319d..ecd520f 100644
--- a/drivers/bluetooth/ath3k.c
+++ b/drivers/bluetooth/ath3k.c
@@ -93,6 +93,7 @@ static const struct usb_device_id ath3k_table[] = {
{ USB_DEVICE(0x04CA, 0x300f) },
{ USB_DEVICE(0x04CA, 0x3010) },
{ USB_DEVICE(0x0930, 0x0219) },
+   { USB_DEVICE(0x0930, 0x021c) },
{ USB_DEVICE(0x0930, 0x0220) },
{ USB_DEVICE(0x0930, 0x0227) },
{ USB_DEVICE(0x0b05, 0x17d0) },
@@ -152,6 +153,7 @@ static const struct usb_device_id ath3k_blist_tbl[] = {
{ USB_DEVICE(0x04ca, 0x300f), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x04ca, 0x3010), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x0930, 0x0219), .driver_info = BTUSB_ATH3012 },
+   { USB_DEVICE(0x0930, 0x021c), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x0930, 0x0220), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x0930, 0x0227), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x0b05, 0x17d0), .driver_info = BTUSB_ATH3012 },
diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index ec5c3ae..9565dc6 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -181,6 +181,7 @@ static const struct usb_device_id blacklist_table[] = {
{ USB_DEVICE(0x04ca, 0x300f), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x04ca, 0x3010), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x0930, 0x0219), .driver_info = BTUSB_ATH3012 },
+   { USB_DEVICE(0x0930, 0x021c), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x0930, 0x0220), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x0930, 0x0227), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x0b05, 0x17d0), .driver_info = BTUSB_ATH3012 },
-- 
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 3.19.y-ckt 063/164] ALSA: hda - Disable 64bit address for Creative HDA controllers

[Kamal Mostafa]

3.19.8-ckt11 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Takashi Iwai 

commit cadd16ea33a938d49aee99edd4758cc76048b399 upstream.

We've had many reports that some Creative sound cards with CA0132
don't work well.  Some reported that it starts working after reloading
the module, while some reported it starts working when a 32bit kernel
is used.  All these facts seem implying that the chip fails to
communicate when the buffer is located in 64bit address.

This patch addresses these issues by just adding AZX_DCAPS_NO_64BIT
flag to the corresponding PCI entries.  I casually had a chance to
test an SB Recon3D board, and indeed this seems helping.

Although this hasn't been tested on all Creative devices, it's safer
to assume that this restriction applies to the rest of them, too.  So
the flag is applied to all Creative entries.

Signed-off-by: Takashi Iwai 
Signed-off-by: Kamal Mostafa 
---
 sound/pci/hda/hda_intel.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c
index a4e6e2f..9de6d8f 100644
--- a/sound/pci/hda/hda_intel.c
+++ b/sound/pci/hda/hda_intel.c
@@ -324,6 +324,7 @@ enum {
 
 #define AZX_DCAPS_PRESET_CTHDA \
(AZX_DCAPS_NO_MSI | AZX_DCAPS_POSFIX_LPIB |\
+AZX_DCAPS_NO_64BIT |\
 AZX_DCAPS_4K_BDLE_BOUNDARY | AZX_DCAPS_SNOOP_OFF)
 
 /*
@@ -2196,11 +2197,13 @@ static const struct pci_device_id azx_ids[] = {
  .class = PCI_CLASS_MULTIMEDIA_HD_AUDIO << 8,
  .class_mask = 0xff,
  .driver_data = AZX_DRIVER_CTX | AZX_DCAPS_CTX_WORKAROUND |
+ AZX_DCAPS_NO_64BIT |
  AZX_DCAPS_RIRB_PRE_DELAY | AZX_DCAPS_POSFIX_LPIB },
 #else
/* this entry seems still valid -- i.e. without emu20kx chip */
{ PCI_DEVICE(0x1102, 0x0009),
  .driver_data = AZX_DRIVER_CTX | AZX_DCAPS_CTX_WORKAROUND |
+ AZX_DCAPS_NO_64BIT |
  AZX_DCAPS_RIRB_PRE_DELAY | AZX_DCAPS_POSFIX_LPIB },
 #endif
/* CM */
-- 
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 3.19.y-ckt 059/164] ACPI: Use correct IRQ when uninstalling ACPI interrupt handler

[Kamal Mostafa]

3.19.8-ckt11 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Chen Yu 

commit 49e4b84333f338d4f183f28f1f3c1131b9fb2b5a upstream.

Currently when the system is trying to uninstall the ACPI interrupt
handler, it uses acpi_gbl_FADT.sci_interrupt as the IRQ number.
However, the IRQ number that the ACPI interrupt handled is installed
for comes from acpi_gsi_to_irq() and that is the number that should
be used for the handler removal.

Fix this problem by using the mapped IRQ returned from acpi_gsi_to_irq()
as appropriate.

Acked-by: Lv Zheng 
Signed-off-by: Chen Yu 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Kamal Mostafa 
---
 drivers/acpi/osl.c   | 9 ++---
 include/linux/acpi.h | 6 ++
 2 files changed, 12 insertions(+), 3 deletions(-)

diff --git a/drivers/acpi/osl.c b/drivers/acpi/osl.c
index 4c25675..5c99219 100644
--- a/drivers/acpi/osl.c
+++ b/drivers/acpi/osl.c
@@ -83,6 +83,7 @@ static void *acpi_irq_context;
 static struct workqueue_struct *kacpid_wq;
 static struct workqueue_struct *kacpi_notify_wq;
 static struct workqueue_struct *kacpi_hotplug_wq;
+unsigned int acpi_sci_irq = INVALID_ACPI_IRQ;
 
 /*
  * This list of permanent mappings is for memory that may be accessed from
@@ -840,17 +841,19 @@ acpi_os_install_interrupt_handler(u32 gsi, 
acpi_osd_handler handler,
acpi_irq_handler = NULL;
return AE_NOT_ACQUIRED;
}
+   acpi_sci_irq = irq;
 
return AE_OK;
 }
 
-acpi_status acpi_os_remove_interrupt_handler(u32 irq, acpi_osd_handler handler)
+acpi_status acpi_os_remove_interrupt_handler(u32 gsi, acpi_osd_handler handler)
 {
-   if (irq != acpi_gbl_FADT.sci_interrupt)
+   if (gsi != acpi_gbl_FADT.sci_interrupt || !acpi_sci_irq_valid())
return AE_BAD_PARAMETER;
 
-   free_irq(irq, acpi_irq);
+   free_irq(acpi_sci_irq, acpi_irq);
acpi_irq_handler = NULL;
+   acpi_sci_irq = INVALID_ACPI_IRQ;
 
return AE_OK;
 }
diff --git a/include/linux/acpi.h b/include/linux/acpi.h
index 77d4941..0f60a01 100644
--- a/include/linux/acpi.h
+++ b/include/linux/acpi.h
@@ -157,6 +157,12 @@ int acpi_ioapic_registered(acpi_handle handle, u32 
gsi_base);
 void acpi_irq_stats_init(void);
 extern u32 acpi_irq_handled;
 extern u32 acpi_irq_not_handled;
+extern unsigned int acpi_sci_irq;
+#define INVALID_ACPI_IRQ   ((unsigned)-1)
+static inline bool acpi_sci_irq_valid(void)
+{
+   return acpi_sci_irq != INVALID_ACPI_IRQ;
+}
 
 extern int sbf_port;
 extern unsigned long acpi_realmode_flags;
-- 
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 3.19.y-ckt 055/164] Bluetooth: Fix removing connection parameters when unpairing

[Kamal Mostafa]

3.19.8-ckt11 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Johan Hedberg 

commit a6ad2a6b9cc1d9d791aee5462cfb8528f366f1d4 upstream.

The commit 89cbb0638e9b7 introduced support for deferred connection
parameter removal when unpairing by removing them only once an
existing connection gets disconnected. However, it failed to address
the scenario when we're *not* connected and do an unpair operation.

What makes things worse is that most user space BlueZ versions will
first issue a disconnect request and only then unpair, meaning the
buggy code will be triggered every time. This effectively causes the
kernel to resume scanning and reconnect to a device for which we've
removed all keys and GATT database information.

This patch fixes the issue by adding the missing call to the
hci_conn_params_del() function to a branch which handles the case of
no existing connection.

Signed-off-by: Johan Hedberg 
Signed-off-by: Marcel Holtmann 
Signed-off-by: Kamal Mostafa 
---
 net/bluetooth/mgmt.c | 12 +++-
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/net/bluetooth/mgmt.c b/net/bluetooth/mgmt.c
index 1775dbf..13bfd37 100644
--- a/net/bluetooth/mgmt.c
+++ b/net/bluetooth/mgmt.c
@@ -2772,6 +2772,11 @@ static int unpair_device(struct sock *sk, struct hci_dev 
*hdev, void *data,
} else {
u8 addr_type;
 
+   if (cp->addr.type == BDADDR_LE_PUBLIC)
+   addr_type = ADDR_LE_DEV_PUBLIC;
+   else
+   addr_type = ADDR_LE_DEV_RANDOM;
+
conn = hci_conn_hash_lookup_ba(hdev, LE_LINK,
   >addr.bdaddr);
if (conn) {
@@ -2787,13 +2792,10 @@ static int unpair_device(struct sock *sk, struct 
hci_dev *hdev, void *data,
 */
if (!cp->disconnect)
conn = NULL;
+   } else {
+   hci_conn_params_del(hdev, >addr.bdaddr, addr_type);
}
 
-   if (cp->addr.type == BDADDR_LE_PUBLIC)
-   addr_type = ADDR_LE_DEV_PUBLIC;
-   else
-   addr_type = ADDR_LE_DEV_RANDOM;
-
hci_remove_irk(hdev, >addr.bdaddr, addr_type);
 
err = hci_remove_ltk(hdev, >addr.bdaddr, addr_type);
-- 
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 3.19.y-ckt 050/164] [media] media: vb2 dma-sg: Fully cache synchronise buffers in prepare and finish

[Kamal Mostafa]

3.19.8-ckt11 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Tiffany Lin 

commit 418dae2276065680bde7ae27d2c075e612a54de6 upstream.

In videobuf2 dma-sg memory types the prepare and finish ops, instead
of passing the number of entries in the original scatterlist as the
"nents" parameter to dma_sync_sg_for_device() and dma_sync_sg_for_cpu(),
the value returned by dma_map_sg() was used. Albeit this has been
suggested in comments of some implementations (which have since been
corrected), this is wrong.

Fixes: d790b7eda953 ("vb2-dma-sg: move dma_(un)map_sg here")

Signed-off-by: Tiffany Lin 
Signed-off-by: Sakari Ailus 
Signed-off-by: Mauro Carvalho Chehab 
Signed-off-by: Kamal Mostafa 
---
 drivers/media/v4l2-core/videobuf2-dma-sg.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/media/v4l2-core/videobuf2-dma-sg.c 
b/drivers/media/v4l2-core/videobuf2-dma-sg.c
index b1838ab..91c6f56 100644
--- a/drivers/media/v4l2-core/videobuf2-dma-sg.c
+++ b/drivers/media/v4l2-core/videobuf2-dma-sg.c
@@ -209,7 +209,8 @@ static void vb2_dma_sg_prepare(void *buf_priv)
if (buf->db_attach)
return;
 
-   dma_sync_sg_for_device(buf->dev, sgt->sgl, sgt->nents, buf->dma_dir);
+   dma_sync_sg_for_device(buf->dev, sgt->sgl, sgt->orig_nents,
+  buf->dma_dir);
 }
 
 static void vb2_dma_sg_finish(void *buf_priv)
@@ -221,7 +222,7 @@ static void vb2_dma_sg_finish(void *buf_priv)
if (buf->db_attach)
return;
 
-   dma_sync_sg_for_cpu(buf->dev, sgt->sgl, sgt->nents, buf->dma_dir);
+   dma_sync_sg_for_cpu(buf->dev, sgt->sgl, sgt->orig_nents, buf->dma_dir);
 }
 
 static inline int vma_is_io(struct vm_area_struct *vma)
-- 
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 3.19.y-ckt 049/164] [media] media: vb2 dma-contig: Fully cache synchronise buffers in prepare and finish

[Kamal Mostafa]

3.19.8-ckt11 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Tiffany Lin 

commit d9a985883fa32453d099d6293188c11d75cef1fa upstream.

In videobuf2 dma-contig memory type the prepare and finish ops, instead of
passing the number of entries in the original scatterlist as the "nents"
parameter to dma_sync_sg_for_device() and dma_sync_sg_for_cpu(), the value
returned by dma_map_sg() was used. Albeit this has been suggested in
comments of some implementations (which have since been corrected), this
is wrong.

Fixes: 199d101efdba ("v4l: vb2-dma-contig: add prepare/finish to dma-contig 
allocator")

Signed-off-by: Tiffany Lin 
Signed-off-by: Sakari Ailus 
Signed-off-by: Mauro Carvalho Chehab 
Signed-off-by: Kamal Mostafa 
---
 drivers/media/v4l2-core/videobuf2-dma-contig.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/media/v4l2-core/videobuf2-dma-contig.c 
b/drivers/media/v4l2-core/videobuf2-dma-contig.c
index 69e0483..1ff0004 100644
--- a/drivers/media/v4l2-core/videobuf2-dma-contig.c
+++ b/drivers/media/v4l2-core/videobuf2-dma-contig.c
@@ -120,7 +120,8 @@ static void vb2_dc_prepare(void *buf_priv)
if (!sgt || buf->db_attach)
return;
 
-   dma_sync_sg_for_device(buf->dev, sgt->sgl, sgt->nents, buf->dma_dir);
+   dma_sync_sg_for_device(buf->dev, sgt->sgl, sgt->orig_nents,
+  buf->dma_dir);
 }
 
 static void vb2_dc_finish(void *buf_priv)
@@ -132,7 +133,7 @@ static void vb2_dc_finish(void *buf_priv)
if (!sgt || buf->db_attach)
return;
 
-   dma_sync_sg_for_cpu(buf->dev, sgt->sgl, sgt->nents, buf->dma_dir);
+   dma_sync_sg_for_cpu(buf->dev, sgt->sgl, sgt->orig_nents, buf->dma_dir);
 }
 
 /*/
-- 
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 3.19.y-ckt 069/164] can: Use correct type in sizeof() in nla_put()

[Kamal Mostafa]

3.19.8-ckt11 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Marek Vasut 

commit 562b103a21974c2f9cd67514d110f918bb3e1796 upstream.

The sizeof() is invoked on an incorrect variable, likely due to some
copy-paste error, and this might result in memory corruption. Fix this.

Signed-off-by: Marek Vasut 
Cc: Wolfgang Grandegger 
Cc: net...@vger.kernel.org
Signed-off-by: Marc Kleine-Budde 
Signed-off-by: Kamal Mostafa 
---
 drivers/net/can/dev.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/can/dev.c b/drivers/net/can/dev.c
index 62ca0e8..8202ab3 100644
--- a/drivers/net/can/dev.c
+++ b/drivers/net/can/dev.c
@@ -912,7 +912,7 @@ static int can_fill_info(struct sk_buff *skb, const struct 
net_device *dev)
 nla_put(skb, IFLA_CAN_BITTIMING_CONST,
 sizeof(*priv->bittiming_const), priv->bittiming_const)) ||
 
-   nla_put(skb, IFLA_CAN_CLOCK, sizeof(cm), >clock) ||
+   nla_put(skb, IFLA_CAN_CLOCK, sizeof(priv->clock), >clock) ||
nla_put_u32(skb, IFLA_CAN_STATE, state) ||
nla_put(skb, IFLA_CAN_CTRLMODE, sizeof(cm), ) ||
nla_put_u32(skb, IFLA_CAN_RESTART_MS, priv->restart_ms) ||
-- 
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 3.19.y-ckt 071/164] Revert "dm mpath: fix stalls when handling invalid ioctls"

[Kamal Mostafa]

3.19.8-ckt11 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Mauricio Faria de Oliveira 

commit 47796938c46b943d157ac8a6f9ed4e3b98b83cf4 upstream.

This reverts commit a1989b330093578ea5470bea0a00f940c444c466.

That commit introduced a regression at least for the case of the SG_IO ioctl()
running without CAP_SYS_RAWIO capability (e.g., unprivileged users) when there
are no active paths: the ioctl() fails with the ENOTTY errno immediately rather
than blocking due to queue_if_no_path until a path becomes active, for example.

That case happens to be exercised by QEMU KVM guests with 'scsi-block' devices
(qemu "-device scsi-block" [1], libvirt "" [2])
from multipath devices; which leads to SCSI/filesystem errors in such a guest.

More general scenarios can hit that regression too. The following demonstration
employs a SG_IO ioctl() with a standard SCSI INQUIRY command for this objective
(some output & user changes omitted for brevity and comments added for clarity).

Reverting that commit restores normal operation (queueing) in failing scenarios;
tested on linux-next (next-20151022).

1) Test-case is based on sg_simple0 [3] (just SG_IO; remove SG_GET_VERSION_NUM)

$ cat sg_simple0.c
... see [3] ...
$ sed '/SG_GET_VERSION_NUM/,/}/d' sg_simple0.c > sgio_inquiry.c
$ gcc sgio_inquiry.c -o sgio_inquiry

2) The ioctl() works fine with active paths present.

# multipath -l 85ag56
85ag56 (...) dm-19 IBM ,2145
size=60G features='1 queue_if_no_path' hwhandler='0' wp=rw
|-+- policy='service-time 0' prio=0 status=active
| |- 8:0:11:0  sdz  65:144  active undef running
| `- 9:0:9:0   sdbf 67:144  active undef running
`-+- policy='service-time 0' prio=0 status=enabled
  |- 8:0:12:0  sdae 65:224  active undef running
  `- 9:0:12:0  sdbo 68:32   active undef running

$ ./sgio_inquiry /dev/mapper/85ag56
Some of the INQUIRY command's response:
IBM   2145  
INQUIRY duration=0 millisecs, resid=0

3) The ioctl() fails with ENOTTY errno with _no_ active paths present,
   for unprivileged users (rather than blocking due to queue_if_no_path).

# for path in $(multipath -l 85ag56 | grep -o 'sd[a-z]\+'); \
  do multipathd -k"fail path $path"; done

# multipath -l 85ag56
85ag56 (...) dm-19 IBM ,2145
size=60G features='1 queue_if_no_path' hwhandler='0' wp=rw
|-+- policy='service-time 0' prio=0 status=enabled
| |- 8:0:11:0  sdz  65:144  failed undef running
| `- 9:0:9:0   sdbf 67:144  failed undef running
`-+- policy='service-time 0' prio=0 status=enabled
  |- 8:0:12:0  sdae 65:224  failed undef running
  `- 9:0:12:0  sdbo 68:32   failed undef running

$ ./sgio_inquiry /dev/mapper/85ag56
sg_simple0: Inquiry SG_IO ioctl error: Inappropriate ioctl for device

4) dmesg shows that scsi_verify_blk_ioctl() failed for SG_IO (0x2285);
   it returns -ENOIOCTLCMD, later replaced with -ENOTTY in vfs_ioctl().

$ dmesg
<...>
[] device-mapper: multipath: Failing path 65:144.
[] device-mapper: multipath: Failing path 67:144.
[] device-mapper: multipath: Failing path 65:224.
[] device-mapper: multipath: Failing path 68:32.
[] sgio_inquiry: sending ioctl 2285 to a partition!

5) The ioctl() only works if the SYS_CAP_RAWIO capability is present
   (then queueing happens -- in this example, queue_if_no_path is set);
   this is due to a conditional check in scsi_verify_blk_ioctl().

# capsh --drop=cap_sys_rawio -- -c './sgio_inquiry /dev/mapper/85ag56'
sg_simple0: Inquiry SG_IO ioctl error: Inappropriate ioctl for device

# ./sgio_inquiry /dev/mapper/85ag56 &
[1] 72830

# cat /proc/72830/stack
[] 0xc0171c0df700
[] __switch_to+0x204/0x350
[] msleep+0x5c/0x80
[] dm_blk_ioctl+0x70/0x170
[] blkdev_ioctl+0x2b0/0x9b0
[] block_ioctl+0x64/0xd0
[] do_vfs_ioctl+0x490/0x780
[] SyS_ioctl+0xd4/0xf0
[] system_call+0x38/0xd0

6) This is the function call chain exercised in this analysis:

SYSCALL_DEFINE3(ioctl, <...>) @ fs/ioctl.c
-> do_vfs_ioctl()
-> vfs_ioctl()
...
error = filp->f_op->unlocked_ioctl(filp, cmd, arg);
...
-> dm_blk_ioctl() @ drivers/md/dm.c
-> multipath_ioctl() @ drivers/md/dm-mpath.c
...
(bdev = NULL, due to no active paths)
...
if (!bdev || <...>) {
int err = scsi_verify_blk_ioctl(NULL, cmd);
if (err)
r = err;
}
...
-> scsi_verify_blk_ioctl() @ block/scsi_ioctl.c
...
if (bd && bd == bd->bd_contains) // not taken 
(bd = NULL)

[PATCH 3.19.y-ckt 070/164] mtd: blkdevs: fix potential deadlock + lockdep warnings

[Kamal Mostafa]

3.19.8-ckt11 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Brian Norris 

commit f3c63795e90f0c6238306883b6c72f14d5355721 upstream.

Commit 073db4a51ee4 ("mtd: fix: avoid race condition when accessing
mtd->usecount") fixed a race condition but due to poor ordering of the
mutex acquisition, introduced a potential deadlock.

The deadlock can occur, for example, when rmmod'ing the m25p80 module, which
will delete one or more MTDs, along with any corresponding mtdblock
devices. This could potentially race with an acquisition of the block
device as follows.

 -> blktrans_open()
->  mutex_lock(>lock);
->  mutex_lock(_table_mutex);

 -> del_mtd_device()
->  mutex_lock(_table_mutex);
->  blktrans_notify_remove() -> del_mtd_blktrans_dev()
   ->  mutex_lock(>lock);

This is a classic (potential) ABBA deadlock, which can be fixed by
making the A->B ordering consistent everywhere. There was no real
purpose to the ordering in the original patch, AFAIR, so this shouldn't
be a problem. This ordering was actually already present in
del_mtd_blktrans_dev(), for one, where the function tried to ensure that
its caller already held mtd_table_mutex before it acquired >lock:

if (mutex_trylock(_table_mutex)) {
mutex_unlock(_table_mutex);
BUG();
}

So, reverse the ordering of acquisition of >lock and _table_mutex so
we always acquire mtd_table_mutex first.

Snippets of the lockdep output follow:

  # modprobe -r m25p80
  [   53.419251]
  [   53.420838] ==
  [   53.427300] [ INFO: possible circular locking dependency detected ]
  [   53.433865] 4.3.0-rc6 #96 Not tainted
  [   53.437686] ---
  [   53.444220] modprobe/372 is trying to acquire lock:
  [   53.449320]  (>lock){+.+...}, at: [] 
del_mtd_blktrans_dev+0x80/0xdc
  [   53.457271]
  [   53.457271] but task is already holding lock:
  [   53.463372]  (mtd_table_mutex){+.+.+.}, at: [] 
del_mtd_device+0x18/0x100
  [   53.471321]
  [   53.471321] which lock already depends on the new lock.
  [   53.471321]
  [   53.479856]
  [   53.479856] the existing dependency chain (in reverse order) is:
  [   53.487660]
  -> #1 (mtd_table_mutex){+.+.+.}:
  [   53.492331][] blktrans_open+0x34/0x1a4
  [   53.497879][] __blkdev_get+0xc4/0x3b0
  [   53.503364][] blkdev_get+0x108/0x320
  [   53.508743][] do_dentry_open+0x218/0x314
  [   53.514496][] path_openat+0x4c0/0xf9c
  [   53.519959][] do_filp_open+0x5c/0xc0
  [   53.525336][] do_sys_open+0xfc/0x1cc
  [   53.530716][] ret_fast_syscall+0x0/0x1c
  [   53.536375]
  -> #0 (>lock){+.+...}:
  [   53.540587][] mutex_lock_nested+0x38/0x3cc
  [   53.546504][] del_mtd_blktrans_dev+0x80/0xdc
  [   53.552606][] blktrans_notify_remove+0x7c/0x84
  [   53.558891][] del_mtd_device+0x74/0x100
  [   53.564544][] del_mtd_partitions+0x80/0xc8
  [   53.570451][] mtd_device_unregister+0x24/0x48
  [   53.576637][] spi_drv_remove+0x1c/0x34
  [   53.582207][] __device_release_driver+0x88/0x114
  [   53.588663][] device_release_driver+0x20/0x2c
  [   53.594843][] bus_remove_device+0xd8/0x108
  [   53.600748][] device_del+0x10c/0x210
  [   53.606127][] device_unregister+0xc/0x20
  [   53.611849][] __unregister+0x10/0x20
  [   53.617211][] device_for_each_child+0x50/0x7c
  [   53.623387][] spi_unregister_master+0x58/0x8c
  [   53.629578][] release_nodes+0x15c/0x1c8
  [   53.635223][] __device_release_driver+0x90/0x114
  [   53.641689][] driver_detach+0xb4/0xb8
  [   53.647147][] bus_remove_driver+0x4c/0xa0
  [   53.652970][] SyS_delete_module+0x11c/0x1e4
  [   53.658976][] ret_fast_syscall+0x0/0x1c
  [   53.664621]
  [   53.664621] other info that might help us debug this:
  [   53.664621]
  [   53.672979]  Possible unsafe locking scenario:
  [   53.672979]
  [   53.679169]CPU0CPU1
  [   53.683900]
  [   53.688633]   lock(mtd_table_mutex);
  [   53.692383]lock(>lock);
  [   53.698306]lock(mtd_table_mutex);
  [   53.704658]   lock(>lock);
  [   53.707946]
  [   53.707946]  *** DEADLOCK ***

Fixes: 073db4a51ee4 ("mtd: fix: avoid race condition when accessing 
mtd->usecount")
Reported-by: Felipe Balbi 
Tested-by: Felipe Balbi 
Signed-off-by: Brian Norris 
Signed-off-by: Kamal Mostafa 
---
 drivers/mtd/mtd_blkdevs.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/mtd/mtd_blkdevs.c b/drivers/mtd/mtd_blkdevs.c
index 3a69b1e..861d757 100644
--- a/drivers/mtd/mtd_blkdevs.c
+++ b/drivers/mtd/mtd_blkdevs.c
@@ -199,8 +199,8 @@ static int blktrans_open(struct 

[PATCH 3.19.y-ckt 062/164] ALSA: hda/realtek - Dell XPS one ALC3260 speaker no sound after resume back

[Kamal Mostafa]

3.19.8-ckt11 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Kailang Yang 

commit 6ed1131fe196ad7ffc13acc1a1eadc08a1db0303 upstream.

This machine had I2S codec for speaker output.
It need to refill the I2S codec initial verb after resume back.

Signed-off-by: Kailang Yang 
Reported-and-tested-by: George Gugulea 
Signed-off-by: Takashi Iwai 
Signed-off-by: Kamal Mostafa 
---
 sound/pci/hda/patch_realtek.c | 13 +
 1 file changed, 13 insertions(+)

diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
index b16b63c..e851832 100644
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -4354,6 +4354,7 @@ enum {
ALC282_FIXUP_ASPIRE_V5_PINS,
ALC280_FIXUP_HP_GPIO4,
ALC286_FIXUP_HP_GPIO_LED,
+   ALC275_FIXUP_DELL_XPS,
 };
 
 static const struct hda_fixup alc269_fixups[] = {
@@ -4853,6 +4854,17 @@ static const struct hda_fixup alc269_fixups[] = {
.type = HDA_FIXUP_FUNC,
.v.func = alc286_fixup_hp_gpio_led,
},
+   [ALC275_FIXUP_DELL_XPS] = {
+   .type = HDA_FIXUP_VERBS,
+   .v.verbs = (const struct hda_verb[]) {
+   /* Enables internal speaker */
+   {0x20, AC_VERB_SET_COEF_INDEX, 0x1f},
+   {0x20, AC_VERB_SET_PROC_COEF, 0x00c0},
+   {0x20, AC_VERB_SET_COEF_INDEX, 0x30},
+   {0x20, AC_VERB_SET_PROC_COEF, 0x00b1},
+   {}
+   }
+   },
 };
 
 static const struct snd_pci_quirk alc269_fixup_tbl[] = {
@@ -4867,6 +4879,7 @@ static const struct snd_pci_quirk alc269_fixup_tbl[] = {
SND_PCI_QUIRK(0x1025, 0x0775, "Acer Aspire E1-572", 
ALC271_FIXUP_HP_GATE_MIC_JACK_E1_572),
SND_PCI_QUIRK(0x1025, 0x079b, "Acer Aspire V5-573G", 
ALC282_FIXUP_ASPIRE_V5_PINS),
SND_PCI_QUIRK(0x1028, 0x0470, "Dell M101z", ALC269_FIXUP_DELL_M101Z),
+   SND_PCI_QUIRK(0x1028, 0x054b, "Dell XPS one 2710", 
ALC275_FIXUP_DELL_XPS),
SND_PCI_QUIRK(0x1028, 0x05da, "Dell Vostro 5460", 
ALC290_FIXUP_SUBWOOFER),
SND_PCI_QUIRK(0x1028, 0x05f4, "Dell", 
ALC269_FIXUP_DELL1_MIC_NO_PRESENCE),
SND_PCI_QUIRK(0x1028, 0x05f5, "Dell", 
ALC269_FIXUP_DELL1_MIC_NO_PRESENCE),
-- 
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 3.19.y-ckt 065/164] megaraid_sas: Expose TAPE drives unconditionally

[Kamal Mostafa]

3.19.8-ckt11 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: "sumit.sax...@avagotech.com" 

commit 0d5b47a724bab0ebaaa933d6ff5e584957aaa188 upstream.

Expose non-disk (TAPE drive, CD-ROM) unconditionally.

Signed-off-by: Sumit Saxena 
Signed-off-by: Kashyap Desai 
Reviewed-by: Tomas Henzl 
Reviewed-by: Martin K. Petersen 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Kamal Mostafa 
---
 drivers/scsi/megaraid/megaraid_sas_base.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c 
b/drivers/scsi/megaraid/megaraid_sas_base.c
index e541c6c..70cf60a 100644
--- a/drivers/scsi/megaraid/megaraid_sas_base.c
+++ b/drivers/scsi/megaraid/megaraid_sas_base.c
@@ -1681,8 +1681,9 @@ static int megasas_slave_alloc(struct scsi_device *sdev)
pd_index =
(sdev->channel * MEGASAS_MAX_DEV_PER_CHANNEL) +
sdev->id;
-   if (instance->pd_list[pd_index].driveState ==
-   MR_PD_STATE_SYSTEM) {
+   if ((instance->pd_list[pd_index].driveState ==
+   MR_PD_STATE_SYSTEM) ||
+   (instance->pd_list[pd_index].driveType != TYPE_DISK)) {
return 0;
}
return -ENXIO;
-- 
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 3.19.y-ckt 064/164] MAINTAINERS: Add public mailing list for ARC

[Kamal Mostafa]

3.19.8-ckt11 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Vineet Gupta 

commit 9acdc911b55569145034b01075adf658891afbd2 upstream.

Signed-off-by: Vineet Gupta 
Signed-off-by: Kamal Mostafa 
---
 MAINTAINERS | 1 +
 1 file changed, 1 insertion(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index d66a97d..90f2094 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -9295,6 +9295,7 @@ F:include/net/switchdev.h
 
 SYNOPSYS ARC ARCHITECTURE
 M: Vineet Gupta 
+L: linux-snps-...@lists.infraded.org
 S: Supported
 F: arch/arc/
 F: Documentation/devicetree/bindings/arc/
-- 
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 3.19.y-ckt 058/164] staging: rtl8712: Add device ID for Sitecom WLA2100

[Kamal Mostafa]

3.19.8-ckt11 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Larry Finger 

commit 1e6e63283691a2a9048a35d9c6c59cf0abd342e4 upstream.

This adds the USB ID for the Sitecom WLA2100. The Windows 10 inf file
was checked to verify that the addition is correct.

Reported-by: Frans van de Wiel 
Signed-off-by: Larry Finger 
Cc: Frans van de Wiel 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Kamal Mostafa 
---
 drivers/staging/rtl8712/usb_intf.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/staging/rtl8712/usb_intf.c 
b/drivers/staging/rtl8712/usb_intf.c
index 7d0d171..6ef4d99 100644
--- a/drivers/staging/rtl8712/usb_intf.c
+++ b/drivers/staging/rtl8712/usb_intf.c
@@ -144,6 +144,7 @@ static struct usb_device_id rtl871x_usb_id_tbl[] = {
{USB_DEVICE(0x0DF6, 0x0058)},
{USB_DEVICE(0x0DF6, 0x0049)},
{USB_DEVICE(0x0DF6, 0x004C)},
+   {USB_DEVICE(0x0DF6, 0x006C)},
{USB_DEVICE(0x0DF6, 0x0064)},
/* Skyworth */
{USB_DEVICE(0x14b2, 0x3300)},
-- 
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 3.19.y-ckt 066/164] megaraid_sas: Do not use PAGE_SIZE for max_sectors

[Kamal Mostafa]

3.19.8-ckt11 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: "sumit.sax...@avagotech.com" 

commit 357ae967ad66e357f78b5cfb5ab6ca07fb4a7758 upstream.

Do not use PAGE_SIZE marco to calculate max_sectors per I/O
request. Driver code assumes PAGE_SIZE will be always 4096 which can
lead to wrongly calculated value if PAGE_SIZE is not 4096. This issue
was reported in Ubuntu Bugzilla Bug #1475166.

Signed-off-by: Sumit Saxena 
Signed-off-by: Kashyap Desai 
Reviewed-by: Tomas Henzl 
Reviewed-by: Martin K. Petersen 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Kamal Mostafa 
---
 drivers/scsi/megaraid/megaraid_sas.h  | 2 ++
 drivers/scsi/megaraid/megaraid_sas_base.c | 2 +-
 2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/scsi/megaraid/megaraid_sas.h 
b/drivers/scsi/megaraid/megaraid_sas.h
index e94f9bd..ee598a3 100644
--- a/drivers/scsi/megaraid/megaraid_sas.h
+++ b/drivers/scsi/megaraid/megaraid_sas.h
@@ -360,6 +360,8 @@ enum MR_EVT_ARGS {
MR_EVT_ARGS_GENERIC,
 };
 
+
+#define SGE_BUFFER_SIZE4096
 /*
  * define constants for device list query options
  */
diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c 
b/drivers/scsi/megaraid/megaraid_sas_base.c
index 70cf60a..543d76f 100644
--- a/drivers/scsi/megaraid/megaraid_sas_base.c
+++ b/drivers/scsi/megaraid/megaraid_sas_base.c
@@ -4661,7 +4661,7 @@ static int megasas_init_fw(struct megasas_instance 
*instance)
instance->crash_dump_buf = NULL;
}
instance->max_sectors_per_req = instance->max_num_sge *
-   PAGE_SIZE / 512;
+   SGE_BUFFER_SIZE / 512;
if (tmp_sectors && (instance->max_sectors_per_req > tmp_sectors))
instance->max_sectors_per_req = tmp_sectors;
 
-- 
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 3.19.y-ckt 068/164] arm64: Fix compat register mappings

[Kamal Mostafa]

3.19.8-ckt11 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Robin Murphy 

commit 5accd17d0eb523350c9ef754d655e379c9bb93b3 upstream.

For reasons not entirely apparent, but now enshrined in history, the
architectural mapping of AArch32 banked registers to AArch64 registers
actually orders SP_ and LR_ backwards compared to the
intuitive r13/r14 order, for all modes except FIQ.

Fix the compat__ macros accordingly, in the hope of avoiding
subtle bugs with KVM and AArch32 guests.

Signed-off-by: Robin Murphy 
Acked-by: Will Deacon 
Signed-off-by: Catalin Marinas 
Signed-off-by: Kamal Mostafa 
---
 arch/arm64/include/asm/ptrace.h | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/arch/arm64/include/asm/ptrace.h b/arch/arm64/include/asm/ptrace.h
index 41ed9e1..88d6e24 100644
--- a/arch/arm64/include/asm/ptrace.h
+++ b/arch/arm64/include/asm/ptrace.h
@@ -76,14 +76,14 @@
 #define compat_sp  regs[13]
 #define compat_lr  regs[14]
 #define compat_sp_hyp  regs[15]
-#define compat_sp_irq  regs[16]
-#define compat_lr_irq  regs[17]
-#define compat_sp_svc  regs[18]
-#define compat_lr_svc  regs[19]
-#define compat_sp_abt  regs[20]
-#define compat_lr_abt  regs[21]
-#define compat_sp_und  regs[22]
-#define compat_lr_und  regs[23]
+#define compat_lr_irq  regs[16]
+#define compat_sp_irq  regs[17]
+#define compat_lr_svc  regs[18]
+#define compat_sp_svc  regs[19]
+#define compat_lr_abt  regs[20]
+#define compat_sp_abt  regs[21]
+#define compat_lr_und  regs[22]
+#define compat_sp_und  regs[23]
 #define compat_r8_fiq  regs[24]
 #define compat_r9_fiq  regs[25]
 #define compat_r10_fiq regs[26]
-- 
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/