Re: [PATCH] clocksource: add __ro_after_init to cyclecounter

[Bhumika Goyal]

On Mon, Feb 13, 2017 at 12:26 AM, Thomas Gleixner  wrote:
> On Sun, 12 Feb 2017, Bhumika Goyal wrote:
>
>> On Sun, Feb 12, 2017 at 2:01 AM, Ard Biesheuvel
>>  wrote:
>> > On 11 February 2017 at 19:20, Bhumika Goyal  wrote:
>> >> The object cyclecounter of type cyclecounter is not getting modified
>> >> after getting initialized by arch_counter_register. Apart from
>> >> initialization in arch_counter_register it is also passed as an argument
>> >> to the function timecounter_init but this argument is of type const.
>> >> Therefore, add __ro_after_init to its declaration.
>> >>
>> >
>> > I think adding __ro_after_init is fine if this struct is never
>> > modified after init. But the reference in the commit log to the
>> > constness of the timecounter_init() argument  makes no sense: that
>> > only means timecounter_init() will not modify the object, which allows
>> > pointers to const objects to be passed to it as well. The opposite is
>> > not true, though: there is no requirement whatsoever that objects
>> > passed into const pointer arguments should be const themselves.
>> >
>> >
>>
>> Yes, true. I will change the commit log and send a v2. Thanks for explaining.
>
> I've applied it already and fixed up the subject/changelog. You should have
> mail from tip-bot ...

Okay. Thanks. I thought the patch is not applied yet because I haven't
received a mail from tip-bot yet.

Thanks,
Bhumika

Re: [PATCH] clocksource: add __ro_after_init to cyclecounter

[Bhumika Goyal]

On Mon, Feb 13, 2017 at 12:26 AM, Thomas Gleixner  wrote:
> On Sun, 12 Feb 2017, Bhumika Goyal wrote:
>
>> On Sun, Feb 12, 2017 at 2:01 AM, Ard Biesheuvel
>>  wrote:
>> > On 11 February 2017 at 19:20, Bhumika Goyal  wrote:
>> >> The object cyclecounter of type cyclecounter is not getting modified
>> >> after getting initialized by arch_counter_register. Apart from
>> >> initialization in arch_counter_register it is also passed as an argument
>> >> to the function timecounter_init but this argument is of type const.
>> >> Therefore, add __ro_after_init to its declaration.
>> >>
>> >
>> > I think adding __ro_after_init is fine if this struct is never
>> > modified after init. But the reference in the commit log to the
>> > constness of the timecounter_init() argument  makes no sense: that
>> > only means timecounter_init() will not modify the object, which allows
>> > pointers to const objects to be passed to it as well. The opposite is
>> > not true, though: there is no requirement whatsoever that objects
>> > passed into const pointer arguments should be const themselves.
>> >
>> >
>>
>> Yes, true. I will change the commit log and send a v2. Thanks for explaining.
>
> I've applied it already and fixed up the subject/changelog. You should have
> mail from tip-bot ...

Okay. Thanks. I thought the patch is not applied yet because I haven't
received a mail from tip-bot yet.

Thanks,
Bhumika

Re: [PATCH] clocksource: add __ro_after_init to cyclecounter

[Thomas Gleixner]

On Sun, 12 Feb 2017, Bhumika Goyal wrote:

> On Sun, Feb 12, 2017 at 2:01 AM, Ard Biesheuvel
>  wrote:
> > On 11 February 2017 at 19:20, Bhumika Goyal  wrote:
> >> The object cyclecounter of type cyclecounter is not getting modified
> >> after getting initialized by arch_counter_register. Apart from
> >> initialization in arch_counter_register it is also passed as an argument
> >> to the function timecounter_init but this argument is of type const.
> >> Therefore, add __ro_after_init to its declaration.
> >>
> >
> > I think adding __ro_after_init is fine if this struct is never
> > modified after init. But the reference in the commit log to the
> > constness of the timecounter_init() argument  makes no sense: that
> > only means timecounter_init() will not modify the object, which allows
> > pointers to const objects to be passed to it as well. The opposite is
> > not true, though: there is no requirement whatsoever that objects
> > passed into const pointer arguments should be const themselves.
> >
> >
> 
> Yes, true. I will change the commit log and send a v2. Thanks for explaining.

I've applied it already and fixed up the subject/changelog. You should have
mail from tip-bot ...

Re: [PATCH] clocksource: add __ro_after_init to cyclecounter

[Thomas Gleixner]

On Sun, 12 Feb 2017, Bhumika Goyal wrote:

> On Sun, Feb 12, 2017 at 2:01 AM, Ard Biesheuvel
>  wrote:
> > On 11 February 2017 at 19:20, Bhumika Goyal  wrote:
> >> The object cyclecounter of type cyclecounter is not getting modified
> >> after getting initialized by arch_counter_register. Apart from
> >> initialization in arch_counter_register it is also passed as an argument
> >> to the function timecounter_init but this argument is of type const.
> >> Therefore, add __ro_after_init to its declaration.
> >>
> >
> > I think adding __ro_after_init is fine if this struct is never
> > modified after init. But the reference in the commit log to the
> > constness of the timecounter_init() argument  makes no sense: that
> > only means timecounter_init() will not modify the object, which allows
> > pointers to const objects to be passed to it as well. The opposite is
> > not true, though: there is no requirement whatsoever that objects
> > passed into const pointer arguments should be const themselves.
> >
> >
> 
> Yes, true. I will change the commit log and send a v2. Thanks for explaining.

I've applied it already and fixed up the subject/changelog. You should have
mail from tip-bot ...

[tip:irq/core] genirq/devres: Use dev_name(dev) as default for devname

[tip-bot for Heiner Kallweit]

Commit-ID:  899b5fbf9d3fcb721690b4d58cf58cc018517003
Gitweb: http://git.kernel.org/tip/899b5fbf9d3fcb721690b4d58cf58cc018517003
Author: Heiner Kallweit 
AuthorDate: Sun, 12 Feb 2017 16:31:44 +0100
Committer:  Thomas Gleixner 
CommitDate: Sun, 12 Feb 2017 19:49:25 +0100

genirq/devres: Use dev_name(dev) as default for devname

Allow the devname parameter to be NULL and use dev_name(dev) in this case.
This should be an appropriate default for most use cases.

Signed-off-by: Heiner Kallweit 
Link: http://lkml.kernel.org/r/05c63d67-30b4-7026-02d5-ce7fb7bc1...@gmail.com
Signed-off-by: Thomas Gleixner 

---
 kernel/irq/devres.c | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/kernel/irq/devres.c b/kernel/irq/devres.c
index 18babef..1613bfd 100644
--- a/kernel/irq/devres.c
+++ b/kernel/irq/devres.c
@@ -34,7 +34,7 @@ static int devm_irq_match(struct device *dev, void *res, void 
*data)
  * @thread_fn: function to be called in a threaded interrupt context. NULL
  * for devices which handle everything in @handler
  * @irqflags: Interrupt type flags
- * @devname: An ascii name for the claiming device
+ * @devname: An ascii name for the claiming device, dev_name(dev) if NULL
  * @dev_id: A cookie passed back to the handler function
  *
  * Except for the extra @dev argument, this function takes the
@@ -58,6 +58,9 @@ int devm_request_threaded_irq(struct device *dev, unsigned 
int irq,
if (!dr)
return -ENOMEM;
 
+   if (!devname)
+   devname = dev_name(dev);
+
rc = request_threaded_irq(irq, handler, thread_fn, irqflags, devname,
  dev_id);
if (rc) {
@@ -81,7 +84,7 @@ EXPORT_SYMBOL(devm_request_threaded_irq);
  * @thread_fn: function to be called in a threaded interrupt context. NULL
  * for devices which handle everything in @handler
  * @irqflags: Interrupt type flags
- * @devname: An ascii name for the claiming device
+ * @devname: An ascii name for the claiming device, dev_name(dev) if NULL
  * @dev_id: A cookie passed back to the handler function
  *
  * Except for the extra @dev argument, this function takes the
@@ -104,6 +107,9 @@ int devm_request_any_context_irq(struct device *dev, 
unsigned int irq,
if (!dr)
return -ENOMEM;
 
+   if (!devname)
+   devname = dev_name(dev);
+
rc = request_any_context_irq(irq, handler, irqflags, devname, dev_id);
if (rc < 0) {
devres_free(dr);

[tip:irq/core] genirq/devres: Use dev_name(dev) as default for devname

[tip-bot for Heiner Kallweit]

Commit-ID:  899b5fbf9d3fcb721690b4d58cf58cc018517003
Gitweb: http://git.kernel.org/tip/899b5fbf9d3fcb721690b4d58cf58cc018517003
Author: Heiner Kallweit 
AuthorDate: Sun, 12 Feb 2017 16:31:44 +0100
Committer:  Thomas Gleixner 
CommitDate: Sun, 12 Feb 2017 19:49:25 +0100

genirq/devres: Use dev_name(dev) as default for devname

Allow the devname parameter to be NULL and use dev_name(dev) in this case.
This should be an appropriate default for most use cases.

Signed-off-by: Heiner Kallweit 
Link: http://lkml.kernel.org/r/05c63d67-30b4-7026-02d5-ce7fb7bc1...@gmail.com
Signed-off-by: Thomas Gleixner 

---
 kernel/irq/devres.c | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/kernel/irq/devres.c b/kernel/irq/devres.c
index 18babef..1613bfd 100644
--- a/kernel/irq/devres.c
+++ b/kernel/irq/devres.c
@@ -34,7 +34,7 @@ static int devm_irq_match(struct device *dev, void *res, void 
*data)
  * @thread_fn: function to be called in a threaded interrupt context. NULL
  * for devices which handle everything in @handler
  * @irqflags: Interrupt type flags
- * @devname: An ascii name for the claiming device
+ * @devname: An ascii name for the claiming device, dev_name(dev) if NULL
  * @dev_id: A cookie passed back to the handler function
  *
  * Except for the extra @dev argument, this function takes the
@@ -58,6 +58,9 @@ int devm_request_threaded_irq(struct device *dev, unsigned 
int irq,
if (!dr)
return -ENOMEM;
 
+   if (!devname)
+   devname = dev_name(dev);
+
rc = request_threaded_irq(irq, handler, thread_fn, irqflags, devname,
  dev_id);
if (rc) {
@@ -81,7 +84,7 @@ EXPORT_SYMBOL(devm_request_threaded_irq);
  * @thread_fn: function to be called in a threaded interrupt context. NULL
  * for devices which handle everything in @handler
  * @irqflags: Interrupt type flags
- * @devname: An ascii name for the claiming device
+ * @devname: An ascii name for the claiming device, dev_name(dev) if NULL
  * @dev_id: A cookie passed back to the handler function
  *
  * Except for the extra @dev argument, this function takes the
@@ -104,6 +107,9 @@ int devm_request_any_context_irq(struct device *dev, 
unsigned int irq,
if (!dr)
return -ENOMEM;
 
+   if (!devname)
+   devname = dev_name(dev);
+
rc = request_any_context_irq(irq, handler, irqflags, devname, dev_id);
if (rc < 0) {
devres_free(dr);

[PATCH] usb: misc: usbtest: remove redundant check on retval < 0

[Colin King]

From: Colin Ian King 

The check for retval being less than zero is always true since
retval equal to -EPIPE at that point.  Replace the existing
conditional with just return retval.

Detected with CoverityScan, CID#114349 ("Logically dead code")

Signed-off-by: Colin Ian King 
---
 drivers/usb/misc/usbtest.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/misc/usbtest.c b/drivers/usb/misc/usbtest.c
index 3525626..17c0810 100644
--- a/drivers/usb/misc/usbtest.c
+++ b/drivers/usb/misc/usbtest.c
@@ -992,7 +992,7 @@ static int ch9_postconfig(struct usbtest_dev *dev)
dev_err(>dev,
"hs dev qualifier --> %d\n",
retval);
-   return (retval < 0) ? retval : -EDOM;
+   return retval;
}
/* usb2.0 but not high-speed capable; fine */
} else if (retval != sizeof(struct usb_qualifier_descriptor)) {
-- 
2.10.2

[PATCH] usb: misc: usbtest: remove redundant check on retval < 0

[Colin King]

From: Colin Ian King 

The check for retval being less than zero is always true since
retval equal to -EPIPE at that point.  Replace the existing
conditional with just return retval.

Detected with CoverityScan, CID#114349 ("Logically dead code")

Signed-off-by: Colin Ian King 
---
 drivers/usb/misc/usbtest.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/misc/usbtest.c b/drivers/usb/misc/usbtest.c
index 3525626..17c0810 100644
--- a/drivers/usb/misc/usbtest.c
+++ b/drivers/usb/misc/usbtest.c
@@ -992,7 +992,7 @@ static int ch9_postconfig(struct usbtest_dev *dev)
dev_err(>dev,
"hs dev qualifier --> %d\n",
retval);
-   return (retval < 0) ? retval : -EDOM;
+   return retval;
}
/* usb2.0 but not high-speed capable; fine */
} else if (retval != sizeof(struct usb_qualifier_descriptor)) {
-- 
2.10.2

Re: [ibm-acpi-devel] [PATCH 1/1] thinkpad_acpi: Add support for status (external cover) LED

[Adam Goode]

On Sun, Feb 12, 2017 at 1:22 PM, Sebastian Reichel  wrote:
> Hi,
>
> On Tue, Feb 07, 2017 at 11:01:32PM -0200, Henrique de Moraes Holschuh wrote:
>> Hello Adam,
>>
>> I apologise for the delay on answering you.
>>
>> On Tue, 31 Jan 2017, Adam Goode wrote:
>> > On Thu, Jan 19, 2017 at 12:21 PM, Adam Goode  wrote:
>> > > This allows the control of the red status LED, which is the dot of the 
>> > > "i"
>> > > in the word "ThinkPad" on the outside cover of newer models.
>> > >
>> > > In the manual, both this LED and the power LED are referred to as
>> > > the "system-status indicators" without distinction between the two, so
>> > > I chose "status" as the LED name.
>>
>> I seem to recall this LED had an ACPI interface that was specific for
>> it, and allowed it to on/off/sine-wave?
>
> I don't know what the ACPI interface looks like, but the lid status
> led goes into sine-wave mode during suspend. Note, that the power-led
> also goes into sine-wave mode during suspend and is already supported
> by thinkpad-acpi's LED code (without the sine-wave feature as far
> as I can tell).
>
>> > > Signed-off-by: Adam Goode 
>> > >
>> > > diff --git a/drivers/platform/x86/thinkpad_acpi.c b/drivers/platform/x86/
>> > > thinkpad_acpi.c
>> > > index cacb43fb1df7..6577bf8e5635 100644
>> > > --- a/drivers/platform/x86/thinkpad_acpi.c
>> > > +++ b/drivers/platform/x86/thinkpad_acpi.c
>> > > @@ -5611,11 +5611,11 @@ static const char * const
>> > > tpacpi_led_names[TPACPI_LED_NUMLEDS] = {
>> > > "tpacpi::standby",
>> > > "tpacpi::dock_status1",
>> > > "tpacpi::dock_status2",
>> > > -   "tpacpi::unknown_led2",
>> > > +   "tpacpi::status",
>
> "status" looks a bit generic. I suggest "external_lid_status".
>
>> > > "tpacpi::unknown_led3",
>> > > "tpacpi::thinkvantage",
>> > >  };
>> > > -#define TPACPI_SAFE_LEDS   0x1081U
>> > > +#define TPACPI_SAFE_LEDS   0x1481U
>>
>> What happens on older Lenovo models (x00, x10, x20 series?)?  I think
>> the T410 already had it...
>>
>> Also, please add code to not export it to userspace (as a led class) on
>> IBM.
>
> Adam, can you prepare an updated patch? I would like to use this
> led to notify myself about events (i.e. compilation finished)
> while my thinkpad's lid is closed.
>

Yes, I will definitely prepare a new patch at some point. The only
hardware I have to test this on is an old IBM X40 and the Lenovo X260.
(I have a T410 with a busted screen that I could try it on maybe.) But
not much else.

I don't know if I can get to this in the next few weeks, since I am
travelling. If someone would like to clean up the patch and move
forward without me, no problem. Otherwise I will get to it eventually.


Thanks,

Adam


> -- Sebastian

Re: [ibm-acpi-devel] [PATCH 1/1] thinkpad_acpi: Add support for status (external cover) LED

[Adam Goode]

On Sun, Feb 12, 2017 at 1:22 PM, Sebastian Reichel  wrote:
> Hi,
>
> On Tue, Feb 07, 2017 at 11:01:32PM -0200, Henrique de Moraes Holschuh wrote:
>> Hello Adam,
>>
>> I apologise for the delay on answering you.
>>
>> On Tue, 31 Jan 2017, Adam Goode wrote:
>> > On Thu, Jan 19, 2017 at 12:21 PM, Adam Goode  wrote:
>> > > This allows the control of the red status LED, which is the dot of the 
>> > > "i"
>> > > in the word "ThinkPad" on the outside cover of newer models.
>> > >
>> > > In the manual, both this LED and the power LED are referred to as
>> > > the "system-status indicators" without distinction between the two, so
>> > > I chose "status" as the LED name.
>>
>> I seem to recall this LED had an ACPI interface that was specific for
>> it, and allowed it to on/off/sine-wave?
>
> I don't know what the ACPI interface looks like, but the lid status
> led goes into sine-wave mode during suspend. Note, that the power-led
> also goes into sine-wave mode during suspend and is already supported
> by thinkpad-acpi's LED code (without the sine-wave feature as far
> as I can tell).
>
>> > > Signed-off-by: Adam Goode 
>> > >
>> > > diff --git a/drivers/platform/x86/thinkpad_acpi.c b/drivers/platform/x86/
>> > > thinkpad_acpi.c
>> > > index cacb43fb1df7..6577bf8e5635 100644
>> > > --- a/drivers/platform/x86/thinkpad_acpi.c
>> > > +++ b/drivers/platform/x86/thinkpad_acpi.c
>> > > @@ -5611,11 +5611,11 @@ static const char * const
>> > > tpacpi_led_names[TPACPI_LED_NUMLEDS] = {
>> > > "tpacpi::standby",
>> > > "tpacpi::dock_status1",
>> > > "tpacpi::dock_status2",
>> > > -   "tpacpi::unknown_led2",
>> > > +   "tpacpi::status",
>
> "status" looks a bit generic. I suggest "external_lid_status".
>
>> > > "tpacpi::unknown_led3",
>> > > "tpacpi::thinkvantage",
>> > >  };
>> > > -#define TPACPI_SAFE_LEDS   0x1081U
>> > > +#define TPACPI_SAFE_LEDS   0x1481U
>>
>> What happens on older Lenovo models (x00, x10, x20 series?)?  I think
>> the T410 already had it...
>>
>> Also, please add code to not export it to userspace (as a led class) on
>> IBM.
>
> Adam, can you prepare an updated patch? I would like to use this
> led to notify myself about events (i.e. compilation finished)
> while my thinkpad's lid is closed.
>

Yes, I will definitely prepare a new patch at some point. The only
hardware I have to test this on is an old IBM X40 and the Lenovo X260.
(I have a T410 with a busted screen that I could try it on maybe.) But
not much else.

I don't know if I can get to this in the next few weeks, since I am
travelling. If someone would like to clean up the patch and move
forward without me, no problem. Otherwise I will get to it eventually.


Thanks,

Adam


> -- Sebastian

Re: [ibm-acpi-devel] [PATCH 1/1] thinkpad_acpi: Add support for status (external cover) LED

[Sebastian Reichel]

Hi,

On Tue, Feb 07, 2017 at 11:01:32PM -0200, Henrique de Moraes Holschuh wrote:
> Hello Adam,
> 
> I apologise for the delay on answering you.
> 
> On Tue, 31 Jan 2017, Adam Goode wrote:
> > On Thu, Jan 19, 2017 at 12:21 PM, Adam Goode  wrote:
> > > This allows the control of the red status LED, which is the dot of the "i"
> > > in the word "ThinkPad" on the outside cover of newer models.
> > >
> > > In the manual, both this LED and the power LED are referred to as
> > > the "system-status indicators" without distinction between the two, so
> > > I chose "status" as the LED name.
> 
> I seem to recall this LED had an ACPI interface that was specific for
> it, and allowed it to on/off/sine-wave?

I don't know what the ACPI interface looks like, but the lid status
led goes into sine-wave mode during suspend. Note, that the power-led
also goes into sine-wave mode during suspend and is already supported
by thinkpad-acpi's LED code (without the sine-wave feature as far
as I can tell).

> > > Signed-off-by: Adam Goode 
> > >
> > > diff --git a/drivers/platform/x86/thinkpad_acpi.c b/drivers/platform/x86/
> > > thinkpad_acpi.c
> > > index cacb43fb1df7..6577bf8e5635 100644
> > > --- a/drivers/platform/x86/thinkpad_acpi.c
> > > +++ b/drivers/platform/x86/thinkpad_acpi.c
> > > @@ -5611,11 +5611,11 @@ static const char * const
> > > tpacpi_led_names[TPACPI_LED_NUMLEDS] = {
> > > "tpacpi::standby",
> > > "tpacpi::dock_status1",
> > > "tpacpi::dock_status2",
> > > -   "tpacpi::unknown_led2",
> > > +   "tpacpi::status",

"status" looks a bit generic. I suggest "external_lid_status".

> > > "tpacpi::unknown_led3",
> > > "tpacpi::thinkvantage",
> > >  };
> > > -#define TPACPI_SAFE_LEDS   0x1081U
> > > +#define TPACPI_SAFE_LEDS   0x1481U
> 
> What happens on older Lenovo models (x00, x10, x20 series?)?  I think
> the T410 already had it...
> 
> Also, please add code to not export it to userspace (as a led class) on
> IBM.

Adam, can you prepare an updated patch? I would like to use this
led to notify myself about events (i.e. compilation finished)
while my thinkpad's lid is closed.

-- Sebastian


signature.asc
Description: PGP signature

Re: [ibm-acpi-devel] [PATCH 1/1] thinkpad_acpi: Add support for status (external cover) LED

[Sebastian Reichel]

Hi,

On Tue, Feb 07, 2017 at 11:01:32PM -0200, Henrique de Moraes Holschuh wrote:
> Hello Adam,
> 
> I apologise for the delay on answering you.
> 
> On Tue, 31 Jan 2017, Adam Goode wrote:
> > On Thu, Jan 19, 2017 at 12:21 PM, Adam Goode  wrote:
> > > This allows the control of the red status LED, which is the dot of the "i"
> > > in the word "ThinkPad" on the outside cover of newer models.
> > >
> > > In the manual, both this LED and the power LED are referred to as
> > > the "system-status indicators" without distinction between the two, so
> > > I chose "status" as the LED name.
> 
> I seem to recall this LED had an ACPI interface that was specific for
> it, and allowed it to on/off/sine-wave?

I don't know what the ACPI interface looks like, but the lid status
led goes into sine-wave mode during suspend. Note, that the power-led
also goes into sine-wave mode during suspend and is already supported
by thinkpad-acpi's LED code (without the sine-wave feature as far
as I can tell).

> > > Signed-off-by: Adam Goode 
> > >
> > > diff --git a/drivers/platform/x86/thinkpad_acpi.c b/drivers/platform/x86/
> > > thinkpad_acpi.c
> > > index cacb43fb1df7..6577bf8e5635 100644
> > > --- a/drivers/platform/x86/thinkpad_acpi.c
> > > +++ b/drivers/platform/x86/thinkpad_acpi.c
> > > @@ -5611,11 +5611,11 @@ static const char * const
> > > tpacpi_led_names[TPACPI_LED_NUMLEDS] = {
> > > "tpacpi::standby",
> > > "tpacpi::dock_status1",
> > > "tpacpi::dock_status2",
> > > -   "tpacpi::unknown_led2",
> > > +   "tpacpi::status",

"status" looks a bit generic. I suggest "external_lid_status".

> > > "tpacpi::unknown_led3",
> > > "tpacpi::thinkvantage",
> > >  };
> > > -#define TPACPI_SAFE_LEDS   0x1081U
> > > +#define TPACPI_SAFE_LEDS   0x1481U
> 
> What happens on older Lenovo models (x00, x10, x20 series?)?  I think
> the T410 already had it...
> 
> Also, please add code to not export it to userspace (as a led class) on
> IBM.

Adam, can you prepare an updated patch? I would like to use this
led to notify myself about events (i.e. compilation finished)
while my thinkpad's lid is closed.

-- Sebastian


signature.asc
Description: PGP signature

Re: [PATCH] clocksource: add __ro_after_init to cyclecounter

[Bhumika Goyal]

On Sun, Feb 12, 2017 at 2:05 AM, Thomas Gleixner  wrote:
> On Sun, 12 Feb 2017, Bhumika Goyal wrote:
>
> Please be more careful with your subject line. The prefix for this is
> definitely not 'clocksource'. git log would have told you the proper one:
>
> clocksource/drivers/arm_arch_timer
>
> 'clocksource' is the general subsystem and used for system wide changes or
> core changes, but not for a particular driver.
>

I will be more careful about this in future.

Thanks,
Bhumika

>> The object cyclecounter of type cyclecounter is not getting modified
>> after getting initialized by arch_counter_register. Apart from
>> initialization in arch_counter_register it is also passed as an argument
>> to the function timecounter_init but this argument is of type const.
>> Therefore, add __ro_after_init to its declaration.
>
> Other than that this is fine. I'll fix it up when applying.
>
> Thanks,
>
> tglx

Re: [PATCH] clocksource: add __ro_after_init to cyclecounter

[Bhumika Goyal]

On Sun, Feb 12, 2017 at 2:05 AM, Thomas Gleixner  wrote:
> On Sun, 12 Feb 2017, Bhumika Goyal wrote:
>
> Please be more careful with your subject line. The prefix for this is
> definitely not 'clocksource'. git log would have told you the proper one:
>
> clocksource/drivers/arm_arch_timer
>
> 'clocksource' is the general subsystem and used for system wide changes or
> core changes, but not for a particular driver.
>

I will be more careful about this in future.

Thanks,
Bhumika

>> The object cyclecounter of type cyclecounter is not getting modified
>> after getting initialized by arch_counter_register. Apart from
>> initialization in arch_counter_register it is also passed as an argument
>> to the function timecounter_init but this argument is of type const.
>> Therefore, add __ro_after_init to its declaration.
>
> Other than that this is fine. I'll fix it up when applying.
>
> Thanks,
>
> tglx

Re: [PATCH] clocksource: add __ro_after_init to cyclecounter

[Bhumika Goyal]

On Sun, Feb 12, 2017 at 2:01 AM, Ard Biesheuvel
 wrote:
> On 11 February 2017 at 19:20, Bhumika Goyal  wrote:
>> The object cyclecounter of type cyclecounter is not getting modified
>> after getting initialized by arch_counter_register. Apart from
>> initialization in arch_counter_register it is also passed as an argument
>> to the function timecounter_init but this argument is of type const.
>> Therefore, add __ro_after_init to its declaration.
>>
>
> I think adding __ro_after_init is fine if this struct is never
> modified after init. But the reference in the commit log to the
> constness of the timecounter_init() argument  makes no sense: that
> only means timecounter_init() will not modify the object, which allows
> pointers to const objects to be passed to it as well. The opposite is
> not true, though: there is no requirement whatsoever that objects
> passed into const pointer arguments should be const themselves.
>
>

Yes, true. I will change the commit log and send a v2. Thanks for explaining.

Thanks,
Bhumika

>> Signed-off-by: Bhumika Goyal 
>> ---
>>  drivers/clocksource/arm_arch_timer.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/clocksource/arm_arch_timer.c 
>> b/drivers/clocksource/arm_arch_timer.c
>> index 4c8c3fb..a10506b 100644
>> --- a/drivers/clocksource/arm_arch_timer.c
>> +++ b/drivers/clocksource/arm_arch_timer.c
>> @@ -580,7 +580,7 @@ static u64 arch_counter_read_cc(const struct 
>> cyclecounter *cc)
>> .flags  = CLOCK_SOURCE_IS_CONTINUOUS,
>>  };
>>
>> -static struct cyclecounter cyclecounter = {
>> +static struct cyclecounter cyclecounter __ro_after_init = {
>> .read   = arch_counter_read_cc,
>> .mask   = CLOCKSOURCE_MASK(56),
>>  };
>> --
>> 1.9.1
>>
>>
>> ___
>> linux-arm-kernel mailing list
>> linux-arm-ker...@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH] clocksource: add __ro_after_init to cyclecounter

[Bhumika Goyal]

On Sun, Feb 12, 2017 at 2:01 AM, Ard Biesheuvel
 wrote:
> On 11 February 2017 at 19:20, Bhumika Goyal  wrote:
>> The object cyclecounter of type cyclecounter is not getting modified
>> after getting initialized by arch_counter_register. Apart from
>> initialization in arch_counter_register it is also passed as an argument
>> to the function timecounter_init but this argument is of type const.
>> Therefore, add __ro_after_init to its declaration.
>>
>
> I think adding __ro_after_init is fine if this struct is never
> modified after init. But the reference in the commit log to the
> constness of the timecounter_init() argument  makes no sense: that
> only means timecounter_init() will not modify the object, which allows
> pointers to const objects to be passed to it as well. The opposite is
> not true, though: there is no requirement whatsoever that objects
> passed into const pointer arguments should be const themselves.
>
>

Yes, true. I will change the commit log and send a v2. Thanks for explaining.

Thanks,
Bhumika

>> Signed-off-by: Bhumika Goyal 
>> ---
>>  drivers/clocksource/arm_arch_timer.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/clocksource/arm_arch_timer.c 
>> b/drivers/clocksource/arm_arch_timer.c
>> index 4c8c3fb..a10506b 100644
>> --- a/drivers/clocksource/arm_arch_timer.c
>> +++ b/drivers/clocksource/arm_arch_timer.c
>> @@ -580,7 +580,7 @@ static u64 arch_counter_read_cc(const struct 
>> cyclecounter *cc)
>> .flags  = CLOCK_SOURCE_IS_CONTINUOUS,
>>  };
>>
>> -static struct cyclecounter cyclecounter = {
>> +static struct cyclecounter cyclecounter __ro_after_init = {
>> .read   = arch_counter_read_cc,
>> .mask   = CLOCKSOURCE_MASK(56),
>>  };
>> --
>> 1.9.1
>>
>>
>> ___
>> linux-arm-kernel mailing list
>> linux-arm-ker...@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Клиентские базы +79139230330 Skype: prodawez390 Email: prodawez...@gmail.com Узнайте подробнее!

[linux-kernel]

Клиентские базы +79139230330 Skype: prodawez390 Email: prodawez...@gmail.com 
Узнайте подробнее!

Клиентские базы +79139230330 Skype: prodawez390 Email: prodawez...@gmail.com Узнайте подробнее!

[linux-kernel]

Клиентские базы +79139230330 Skype: prodawez390 Email: prodawez...@gmail.com 
Узнайте подробнее!

Re: [PATCH v5 3/8] PCI: Don't block runtime PM for Thunderbolt host hotplug ports

[Lukas Wunner]

On Fri, Feb 10, 2017 at 12:39:12PM -0600, Bjorn Helgaas wrote:
> On Sun, Jan 15, 2017 at 09:03:45PM +0100, Lukas Wunner wrote:
> > Hotplug ports generally block their parents from suspending to D3hot as
> > otherwise their interrupts couldn't be delivered.
> 
> This sounds related to PCIe r3.1, sec 5.3.1.4, which says functions
> supporting PME generation from D3 must support it for both D3cold and
> D3hot.  I think in PCIe, PMEs mean PME Messages, and the 5.3.1
> implementation note says Messages are not affected by the PM state of
> virtual bridges.
> 
> So that seems to say that hotplug ports *should* be able to deliver
> PMEs even while in D3hot.
> 
> Maybe you're referring to the hotplug interrupts themselves, not the
> PME?  I assume a hotplug event (presence detect, attention button,
> etc) would first cause a PME, then the OS would return the path to D0,
> then the hotplug interrupt would be delivered.
> 
> > An exception are Thunderbolt host controllers:  They have a separate
> > GPIO pin to side-band signal plug events even if the controller is
> > powered down or its parent ports are suspended to D3.  They can be told
> > apart from Thunderbolt controllers in attached devices by checking if
> > they're situated below a non-Thunderbolt device (typically a root port,
> > or the downstream port of a PCIe switch in the case of the MacPro6,1).
> 
> In PCIe terms, does a "Thunderbolt host controller" look like a
> downstream port that supports hotplug?
> 
> It seems like the PCIe PME mechanism *should* work pretty much like
> this sideband GPIO.  But I might be reading the spec wrong.

I am dropping this patch in v6 of my Thunderbolt runpm series.

The "Light Ridge" Thunderbolt controller in my machine claims to support
PME, but its WAKE# pin is not connected.  (It's pulled up to 3.3V.)
I also have an external Thunderbolt chassis with the same controller,
and the controller likewise claims to support PME, but its WAKE# pin is
not connected to the PCIe root im my machine in any way.

This led me to the conclusion that PME is not reliable and therefore
in a Thunderbolt daisy chain, which is a cascade of PCIe switches,
only the hotplug port at the farthest end of the chain may suspend to
D3hot, whereas all the ports between it and the root bridge must stay
awake for interrupts to come through.

What I failed to see, due to poor understanding of the (undocumented)
Thunderbolt technology, is that even though ports in the middle of the
chain may be in D3hot and prevent PCIe interrupts from coming through,
the network of Converged I/O switches underlying the PCI tunnels
continues to function and deliver plug events.  It is thus the NHI
driver's job to runtime resume the PCIe switch where a CIO plug event
occurred, as well as its parents, to ensure delivery of PCIe interrupts.
The CIO plug event essentially serves as a sideband signal.  So far the
thunderbolt NHI driver does not support daisy chaining, so this is not
yet an issue.  (Only for tunnels established by the EFI driver.)

Thanks,

Lukas

Re: [PATCH v5 3/8] PCI: Don't block runtime PM for Thunderbolt host hotplug ports

[Lukas Wunner]

On Fri, Feb 10, 2017 at 12:39:12PM -0600, Bjorn Helgaas wrote:
> On Sun, Jan 15, 2017 at 09:03:45PM +0100, Lukas Wunner wrote:
> > Hotplug ports generally block their parents from suspending to D3hot as
> > otherwise their interrupts couldn't be delivered.
> 
> This sounds related to PCIe r3.1, sec 5.3.1.4, which says functions
> supporting PME generation from D3 must support it for both D3cold and
> D3hot.  I think in PCIe, PMEs mean PME Messages, and the 5.3.1
> implementation note says Messages are not affected by the PM state of
> virtual bridges.
> 
> So that seems to say that hotplug ports *should* be able to deliver
> PMEs even while in D3hot.
> 
> Maybe you're referring to the hotplug interrupts themselves, not the
> PME?  I assume a hotplug event (presence detect, attention button,
> etc) would first cause a PME, then the OS would return the path to D0,
> then the hotplug interrupt would be delivered.
> 
> > An exception are Thunderbolt host controllers:  They have a separate
> > GPIO pin to side-band signal plug events even if the controller is
> > powered down or its parent ports are suspended to D3.  They can be told
> > apart from Thunderbolt controllers in attached devices by checking if
> > they're situated below a non-Thunderbolt device (typically a root port,
> > or the downstream port of a PCIe switch in the case of the MacPro6,1).
> 
> In PCIe terms, does a "Thunderbolt host controller" look like a
> downstream port that supports hotplug?
> 
> It seems like the PCIe PME mechanism *should* work pretty much like
> this sideband GPIO.  But I might be reading the spec wrong.

I am dropping this patch in v6 of my Thunderbolt runpm series.

The "Light Ridge" Thunderbolt controller in my machine claims to support
PME, but its WAKE# pin is not connected.  (It's pulled up to 3.3V.)
I also have an external Thunderbolt chassis with the same controller,
and the controller likewise claims to support PME, but its WAKE# pin is
not connected to the PCIe root im my machine in any way.

This led me to the conclusion that PME is not reliable and therefore
in a Thunderbolt daisy chain, which is a cascade of PCIe switches,
only the hotplug port at the farthest end of the chain may suspend to
D3hot, whereas all the ports between it and the root bridge must stay
awake for interrupts to come through.

What I failed to see, due to poor understanding of the (undocumented)
Thunderbolt technology, is that even though ports in the middle of the
chain may be in D3hot and prevent PCIe interrupts from coming through,
the network of Converged I/O switches underlying the PCI tunnels
continues to function and deliver plug events.  It is thus the NHI
driver's job to runtime resume the PCIe switch where a CIO plug event
occurred, as well as its parents, to ensure delivery of PCIe interrupts.
The CIO plug event essentially serves as a sideband signal.  So far the
thunderbolt NHI driver does not support daisy chaining, so this is not
yet an issue.  (Only for tunnels established by the EFI driver.)

Thanks,

Lukas

Re: net/llc: BUG in llc_sap_state_process/skb_set_owner_r

[Eric Dumazet]

On Sun, Feb 12, 2017 at 8:44 AM, Andrey Konovalov  wrote:
> Hi,
>
> I've got the following error report while fuzzing the kernel with syzkaller.
>
> On commit 926af6273fc683cd98cd0ce7bf0d04a02eed6742.
>
> A reproducer and .config are attached

Thanks for the report.

llc sets skb->sk   without corresponding skb->destructor.

This is considered invalid by our current standards.

As I added the sanity check in skb_destructor() back in linux-3.12
(!!!), I will send the corresponding LLC fix.

( commit 376c7311bdb6efea3322310333576a04d73fbe4c )

Re: net/llc: BUG in llc_sap_state_process/skb_set_owner_r

[Eric Dumazet]

On Sun, Feb 12, 2017 at 8:44 AM, Andrey Konovalov  wrote:
> Hi,
>
> I've got the following error report while fuzzing the kernel with syzkaller.
>
> On commit 926af6273fc683cd98cd0ce7bf0d04a02eed6742.
>
> A reproducer and .config are attached

Thanks for the report.

llc sets skb->sk   without corresponding skb->destructor.

This is considered invalid by our current standards.

As I added the sanity check in skb_destructor() back in linux-3.12
(!!!), I will send the corresponding LLC fix.

( commit 376c7311bdb6efea3322310333576a04d73fbe4c )

[PATCH 2/20] staging: rtl8192u: Fixed 'tabstop' coding style warnings

[simran singhal]

Fixed checkpatch warning "Statements should start on a tabstop" in
rtl8192u module.

Signed-off-by: simran singhal 
---
 drivers/staging/rtl8192u/ieee80211/ieee80211_wx.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/rtl8192u/ieee80211/ieee80211_wx.c 
b/drivers/staging/rtl8192u/ieee80211/ieee80211_wx.c
index 563d7fe..814ab5a 100644
--- a/drivers/staging/rtl8192u/ieee80211/ieee80211_wx.c
+++ b/drivers/staging/rtl8192u/ieee80211/ieee80211_wx.c
@@ -666,7 +666,7 @@ int ieee80211_wx_set_encode_ext(struct ieee80211_device 
*ieee,
if (ieee->set_security)
ieee->set_security(ieee->dev, );
 
-if (ieee->reset_on_keychange &&
+   if (ieee->reset_on_keychange &&
ieee->iw_mode != IW_MODE_INFRA &&
ieee->reset_port && ieee->reset_port(dev)) {
IEEE80211_DEBUG_WX("%s: reset_port failed\n", dev->name);
-- 
2.7.4

[PATCH 2/20] staging: rtl8192u: Fixed 'tabstop' coding style warnings

[simran singhal]

Fixed checkpatch warning "Statements should start on a tabstop" in
rtl8192u module.

Signed-off-by: simran singhal 
---
 drivers/staging/rtl8192u/ieee80211/ieee80211_wx.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/rtl8192u/ieee80211/ieee80211_wx.c 
b/drivers/staging/rtl8192u/ieee80211/ieee80211_wx.c
index 563d7fe..814ab5a 100644
--- a/drivers/staging/rtl8192u/ieee80211/ieee80211_wx.c
+++ b/drivers/staging/rtl8192u/ieee80211/ieee80211_wx.c
@@ -666,7 +666,7 @@ int ieee80211_wx_set_encode_ext(struct ieee80211_device 
*ieee,
if (ieee->set_security)
ieee->set_security(ieee->dev, );
 
-if (ieee->reset_on_keychange &&
+   if (ieee->reset_on_keychange &&
ieee->iw_mode != IW_MODE_INFRA &&
ieee->reset_port && ieee->reset_port(dev)) {
IEEE80211_DEBUG_WX("%s: reset_port failed\n", dev->name);
-- 
2.7.4

[PATCH 1/20] staging: rtl8192u: Replace symbolic permissions with octal permissions

[simran singhal]

WARNING: Symbolic permissions 'S_IRUGO | S_IWUSR' are not preferred.
Consider using octal permissions '0644'.
This warning is detected by checkpatch.pl

Signed-off-by: simran singhal 
---
 drivers/staging/rtl8192u/ieee80211/ieee80211_module.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/rtl8192u/ieee80211/ieee80211_module.c 
b/drivers/staging/rtl8192u/ieee80211/ieee80211_module.c
index a9a92d8..2ebc320 100644
--- a/drivers/staging/rtl8192u/ieee80211/ieee80211_module.c
+++ b/drivers/staging/rtl8192u/ieee80211/ieee80211_module.c
@@ -283,7 +283,7 @@ int __init ieee80211_debug_init(void)
" proc directory\n");
return -EIO;
}
-   e = proc_create("debug_level", S_IRUGO | S_IWUSR,
+   e = proc_create("debug_level", 0644,
  ieee80211_proc, );
if (!e) {
remove_proc_entry(DRV_NAME, init_net.proc_net);
-- 
2.7.4

[PATCH 1/20] staging: rtl8192u: Replace symbolic permissions with octal permissions

[simran singhal]

WARNING: Symbolic permissions 'S_IRUGO | S_IWUSR' are not preferred.
Consider using octal permissions '0644'.
This warning is detected by checkpatch.pl

Signed-off-by: simran singhal 
---
 drivers/staging/rtl8192u/ieee80211/ieee80211_module.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/rtl8192u/ieee80211/ieee80211_module.c 
b/drivers/staging/rtl8192u/ieee80211/ieee80211_module.c
index a9a92d8..2ebc320 100644
--- a/drivers/staging/rtl8192u/ieee80211/ieee80211_module.c
+++ b/drivers/staging/rtl8192u/ieee80211/ieee80211_module.c
@@ -283,7 +283,7 @@ int __init ieee80211_debug_init(void)
" proc directory\n");
return -EIO;
}
-   e = proc_create("debug_level", S_IRUGO | S_IWUSR,
+   e = proc_create("debug_level", 0644,
  ieee80211_proc, );
if (!e) {
remove_proc_entry(DRV_NAME, init_net.proc_net);
-- 
2.7.4

Re: net/ipv6: use-after-free in sock_wfree

[Andrey Konovalov]

On Mon, Jan 9, 2017 at 6:21 PM, Eric Dumazet  wrote:
> On Mon, Jan 9, 2017 at 9:11 AM, Andrey Konovalov  
> wrote:
>> On Mon, Jan 9, 2017 at 6:08 PM, Andrey Konovalov  
>> wrote:
>>> Hi!
>>>
>>> I've got the following error report while running the syzkaller fuzzer.
>>>
>>> On commit a121103c922847ba5010819a3f250f1f7fc84ab8 (4.10-rc3).
>>>
>>> A reproducer is attached.
>>>
>>> ==
>>> BUG: KASAN: use-after-free in sock_wfree+0x118/0x120
>>> Read of size 8 at addr 880062da0060 by task a.out/4140
>>>
>>> page:ea00018b6800 count:1 mapcount:0 mapping:  (null)
>>> index:0x0 compound_mapcount: 0
>>> flags: 0x1008100(slab|head)
>>> raw: 01008100   000180130013
>>> raw: dead0100 dead0200 88006741f140 
>>> page dumped because: kasan: bad access detected
>>>
>>> CPU: 0 PID: 4140 Comm: a.out Not tainted 4.10.0-rc3+ #59
>>> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
>>> Call Trace:
>>>  __dump_stack lib/dump_stack.c:15
>>>  dump_stack+0x292/0x398 lib/dump_stack.c:51
>>>  describe_address mm/kasan/report.c:262
>>>  kasan_report_error+0x121/0x560 mm/kasan/report.c:370
>>>  kasan_report mm/kasan/report.c:392
>>>  __asan_report_load8_noabort+0x3e/0x40 mm/kasan/report.c:413
>>>  sock_flag ./arch/x86/include/asm/bitops.h:324
>>>  sock_wfree+0x118/0x120 net/core/sock.c:1631
>>>  skb_release_head_state+0xfc/0x250 net/core/skbuff.c:655
>>>  skb_release_all+0x15/0x60 net/core/skbuff.c:668
>>>  __kfree_skb+0x15/0x20 net/core/skbuff.c:684
>>>  kfree_skb+0x16e/0x4e0 net/core/skbuff.c:705
>>>  inet_frag_destroy+0x121/0x290 net/ipv4/inet_fragment.c:304
>>>  inet_frag_put ./include/net/inet_frag.h:133
>>>  nf_ct_frag6_gather+0x1125/0x38b0 
>>> net/ipv6/netfilter/nf_conntrack_reasm.c:617
>>>  ipv6_defrag+0x21b/0x350 net/ipv6/netfilter/nf_defrag_ipv6_hooks.c:68
>>>  nf_hook_entry_hookfn ./include/linux/netfilter.h:102
>>>  nf_hook_slow+0xc3/0x290 net/netfilter/core.c:310
>>>  nf_hook ./include/linux/netfilter.h:212
>>>  __ip6_local_out+0x52c/0xaf0 net/ipv6/output_core.c:160
>>>  ip6_local_out+0x2d/0x170 net/ipv6/output_core.c:170
>>>  ip6_send_skb+0xa1/0x340 net/ipv6/ip6_output.c:1722
>>>  ip6_push_pending_frames+0xb3/0xe0 net/ipv6/ip6_output.c:1742
>>>  rawv6_push_pending_frames net/ipv6/raw.c:613
>>>  rawv6_sendmsg+0x2cff/0x4130 net/ipv6/raw.c:927
>>>  inet_sendmsg+0x164/0x5b0 net/ipv4/af_inet.c:744
>>>  sock_sendmsg_nosec net/socket.c:635
>>>  sock_sendmsg+0xca/0x110 net/socket.c:645
>>>  sock_write_iter+0x326/0x620 net/socket.c:848
>>>  new_sync_write fs/read_write.c:499
>>>  __vfs_write+0x483/0x760 fs/read_write.c:512
>>>  vfs_write+0x187/0x530 fs/read_write.c:560
>>>  SYSC_write fs/read_write.c:607
>>>  SyS_write+0xfb/0x230 fs/read_write.c:599
>>>  entry_SYSCALL_64_fastpath+0x1f/0xc2 arch/x86/entry/entry_64.S:203
>>> RIP: 0033:0x7ff26e6f5b79
>>> RSP: 002b:7ff268e0ed98 EFLAGS: 0206 ORIG_RAX: 0001
>>> RAX: ffda RBX: 7ff268e0f9c0 RCX: 7ff26e6f5b79
>>> RDX: 0010 RSI: 20f50fe1 RDI: 0003
>>> RBP: 7ff26ebc1220 R08:  R09: 
>>> R10:  R11: 0206 R12: 
>>> R13: 7ff268e0f9c0 R14: 7ff26efec040 R15: 0003
>>>
>>> The buggy address belongs to the object at 880062da
>>>  which belongs to the cache RAWv6 of size 1504
>>> The buggy address 880062da0060 is located 96 bytes inside
>>>  of 1504-byte region [880062da, 880062da05e0)
>>>
>>> Freed by task 4113:
>>>  save_stack_trace+0x16/0x20 arch/x86/kernel/stacktrace.c:57
>>>  save_stack+0x43/0xd0 mm/kasan/kasan.c:502
>>>  set_track mm/kasan/kasan.c:514
>>>  kasan_slab_free+0x73/0xc0 mm/kasan/kasan.c:578
>>>  slab_free_hook mm/slub.c:1352
>>>  slab_free_freelist_hook mm/slub.c:1374
>>>  slab_free mm/slub.c:2951
>>>  kmem_cache_free+0xb2/0x2c0 mm/slub.c:2973
>>>  sk_prot_free net/core/sock.c:1377
>>>  __sk_destruct+0x49c/0x6e0 net/core/sock.c:1452
>>>  sk_destruct+0x47/0x80 net/core/sock.c:1460
>>>  __sk_free+0x57/0x230 net/core/sock.c:1468
>>>  sk_free+0x23/0x30 net/core/sock.c:1479
>>>  sock_put ./include/net/sock.h:1638
>>>  sk_common_release+0x31e/0x4e0 net/core/sock.c:2782
>>>  rawv6_close+0x54/0x80 net/ipv6/raw.c:1214
>>>  inet_release+0xed/0x1c0 net/ipv4/af_inet.c:425
>>>  inet6_release+0x50/0x70 net/ipv6/af_inet6.c:431
>>>  sock_release+0x8d/0x1e0 net/socket.c:599
>>>  sock_close+0x16/0x20 net/socket.c:1063
>>>  __fput+0x332/0x7f0 fs/file_table.c:208
>>>  fput+0x15/0x20 fs/file_table.c:244
>>>  task_work_run+0x19b/0x270 kernel/task_work.c:116
>>>  exit_task_work ./include/linux/task_work.h:21
>>>  do_exit+0x186b/0x2800 kernel/exit.c:839
>>>  do_group_exit+0x149/0x420 kernel/exit.c:943
>>>  SYSC_exit_group kernel/exit.c:954
>>>  

Re: net/ipv6: use-after-free in sock_wfree

[Andrey Konovalov]

On Mon, Jan 9, 2017 at 6:21 PM, Eric Dumazet  wrote:
> On Mon, Jan 9, 2017 at 9:11 AM, Andrey Konovalov  
> wrote:
>> On Mon, Jan 9, 2017 at 6:08 PM, Andrey Konovalov  
>> wrote:
>>> Hi!
>>>
>>> I've got the following error report while running the syzkaller fuzzer.
>>>
>>> On commit a121103c922847ba5010819a3f250f1f7fc84ab8 (4.10-rc3).
>>>
>>> A reproducer is attached.
>>>
>>> ==
>>> BUG: KASAN: use-after-free in sock_wfree+0x118/0x120
>>> Read of size 8 at addr 880062da0060 by task a.out/4140
>>>
>>> page:ea00018b6800 count:1 mapcount:0 mapping:  (null)
>>> index:0x0 compound_mapcount: 0
>>> flags: 0x1008100(slab|head)
>>> raw: 01008100   000180130013
>>> raw: dead0100 dead0200 88006741f140 
>>> page dumped because: kasan: bad access detected
>>>
>>> CPU: 0 PID: 4140 Comm: a.out Not tainted 4.10.0-rc3+ #59
>>> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
>>> Call Trace:
>>>  __dump_stack lib/dump_stack.c:15
>>>  dump_stack+0x292/0x398 lib/dump_stack.c:51
>>>  describe_address mm/kasan/report.c:262
>>>  kasan_report_error+0x121/0x560 mm/kasan/report.c:370
>>>  kasan_report mm/kasan/report.c:392
>>>  __asan_report_load8_noabort+0x3e/0x40 mm/kasan/report.c:413
>>>  sock_flag ./arch/x86/include/asm/bitops.h:324
>>>  sock_wfree+0x118/0x120 net/core/sock.c:1631
>>>  skb_release_head_state+0xfc/0x250 net/core/skbuff.c:655
>>>  skb_release_all+0x15/0x60 net/core/skbuff.c:668
>>>  __kfree_skb+0x15/0x20 net/core/skbuff.c:684
>>>  kfree_skb+0x16e/0x4e0 net/core/skbuff.c:705
>>>  inet_frag_destroy+0x121/0x290 net/ipv4/inet_fragment.c:304
>>>  inet_frag_put ./include/net/inet_frag.h:133
>>>  nf_ct_frag6_gather+0x1125/0x38b0 
>>> net/ipv6/netfilter/nf_conntrack_reasm.c:617
>>>  ipv6_defrag+0x21b/0x350 net/ipv6/netfilter/nf_defrag_ipv6_hooks.c:68
>>>  nf_hook_entry_hookfn ./include/linux/netfilter.h:102
>>>  nf_hook_slow+0xc3/0x290 net/netfilter/core.c:310
>>>  nf_hook ./include/linux/netfilter.h:212
>>>  __ip6_local_out+0x52c/0xaf0 net/ipv6/output_core.c:160
>>>  ip6_local_out+0x2d/0x170 net/ipv6/output_core.c:170
>>>  ip6_send_skb+0xa1/0x340 net/ipv6/ip6_output.c:1722
>>>  ip6_push_pending_frames+0xb3/0xe0 net/ipv6/ip6_output.c:1742
>>>  rawv6_push_pending_frames net/ipv6/raw.c:613
>>>  rawv6_sendmsg+0x2cff/0x4130 net/ipv6/raw.c:927
>>>  inet_sendmsg+0x164/0x5b0 net/ipv4/af_inet.c:744
>>>  sock_sendmsg_nosec net/socket.c:635
>>>  sock_sendmsg+0xca/0x110 net/socket.c:645
>>>  sock_write_iter+0x326/0x620 net/socket.c:848
>>>  new_sync_write fs/read_write.c:499
>>>  __vfs_write+0x483/0x760 fs/read_write.c:512
>>>  vfs_write+0x187/0x530 fs/read_write.c:560
>>>  SYSC_write fs/read_write.c:607
>>>  SyS_write+0xfb/0x230 fs/read_write.c:599
>>>  entry_SYSCALL_64_fastpath+0x1f/0xc2 arch/x86/entry/entry_64.S:203
>>> RIP: 0033:0x7ff26e6f5b79
>>> RSP: 002b:7ff268e0ed98 EFLAGS: 0206 ORIG_RAX: 0001
>>> RAX: ffda RBX: 7ff268e0f9c0 RCX: 7ff26e6f5b79
>>> RDX: 0010 RSI: 20f50fe1 RDI: 0003
>>> RBP: 7ff26ebc1220 R08:  R09: 
>>> R10:  R11: 0206 R12: 
>>> R13: 7ff268e0f9c0 R14: 7ff26efec040 R15: 0003
>>>
>>> The buggy address belongs to the object at 880062da
>>>  which belongs to the cache RAWv6 of size 1504
>>> The buggy address 880062da0060 is located 96 bytes inside
>>>  of 1504-byte region [880062da, 880062da05e0)
>>>
>>> Freed by task 4113:
>>>  save_stack_trace+0x16/0x20 arch/x86/kernel/stacktrace.c:57
>>>  save_stack+0x43/0xd0 mm/kasan/kasan.c:502
>>>  set_track mm/kasan/kasan.c:514
>>>  kasan_slab_free+0x73/0xc0 mm/kasan/kasan.c:578
>>>  slab_free_hook mm/slub.c:1352
>>>  slab_free_freelist_hook mm/slub.c:1374
>>>  slab_free mm/slub.c:2951
>>>  kmem_cache_free+0xb2/0x2c0 mm/slub.c:2973
>>>  sk_prot_free net/core/sock.c:1377
>>>  __sk_destruct+0x49c/0x6e0 net/core/sock.c:1452
>>>  sk_destruct+0x47/0x80 net/core/sock.c:1460
>>>  __sk_free+0x57/0x230 net/core/sock.c:1468
>>>  sk_free+0x23/0x30 net/core/sock.c:1479
>>>  sock_put ./include/net/sock.h:1638
>>>  sk_common_release+0x31e/0x4e0 net/core/sock.c:2782
>>>  rawv6_close+0x54/0x80 net/ipv6/raw.c:1214
>>>  inet_release+0xed/0x1c0 net/ipv4/af_inet.c:425
>>>  inet6_release+0x50/0x70 net/ipv6/af_inet6.c:431
>>>  sock_release+0x8d/0x1e0 net/socket.c:599
>>>  sock_close+0x16/0x20 net/socket.c:1063
>>>  __fput+0x332/0x7f0 fs/file_table.c:208
>>>  fput+0x15/0x20 fs/file_table.c:244
>>>  task_work_run+0x19b/0x270 kernel/task_work.c:116
>>>  exit_task_work ./include/linux/task_work.h:21
>>>  do_exit+0x186b/0x2800 kernel/exit.c:839
>>>  do_group_exit+0x149/0x420 kernel/exit.c:943
>>>  SYSC_exit_group kernel/exit.c:954
>>>  SyS_exit_group+0x1d/0x20 kernel/exit.c:952
>>>  

Re: [PATCH v5 1/8] PCI: Recognize Thunderbolt devices

[Lukas Wunner]

On Fri, Feb 10, 2017 at 11:42:50AM -0600, Bjorn Helgaas wrote:
> On Sun, Jan 29, 2017 at 01:26:16AM +0100, Lukas Wunner wrote:
> > On Sat, Jan 28, 2017 at 03:52:08PM -0600, Bjorn Helgaas wrote:
> > > On Sun, Jan 15, 2017 at 09:03:45PM +0100, Lukas Wunner wrote:
> 
> > > > +static void set_pcie_vendor_specific(struct pci_dev *dev)
> > > 
> > > This is very specific to Thunderbolt, so let's name it something that
> > > conveys that information.  The fact that we use a vendor-specific
> > > capability to figure it out isn't really relevant in the caller.
> > 
> > I thought that we may have the necessity in the future to parse other
> > VSECs on device probe, so I gave the function this generic name.
> > 
> > Think about it, every VSEC that needs to be parsed needs the while loop
> > below.  It's more efficient to have only a single while loop that handles
> > *all* VSECs at once.
> > 
> > If someone needs to parse another VSEC, they just add it to this function.
> > So IMO the way I've solved it is preferable to just adding a Thunderbolt-
> > specific function.
> > 
> > Are you sure you want this renamed? (y/n)
> 
> Sorry for the delay; I missed this question.  If this has already been
> merged somewhere as-is, that's fine.

No, none of the patches in this series have been merged so far.  Greg's
tree is closed for the duration of the merge window, which is expected
to open today.  Therefore, please merge whatever patches in this series
you feel comfortable with.  It would be good if you could merge at least
patch [1/8] as it would allow me to fix the issues in apple-gmux and
vga_switcheroo that I'm mentioning in the changelog in v4.12.  Also,
patch [2/8] seems uncontroversial.

Greg has acked v5 of this series and suggested that you take it due to
all the PCI changes:
https://lkml.org/lkml/2017/1/19/177

Andreas Noever acked and tested v2 of this series:
https://www.spinics.net/lists/linux-pci/msg51274.html


> If you repost it for any reason,
> I would prefer to rename it so it reflects the functionality rather
> than the source of the information.  This isn't a performance path, so
> readability is more important than optimization.

Sure, I've renamed it.

Thanks,

Lukas

Re: [PATCH v5 1/8] PCI: Recognize Thunderbolt devices

[Lukas Wunner]

On Fri, Feb 10, 2017 at 11:42:50AM -0600, Bjorn Helgaas wrote:
> On Sun, Jan 29, 2017 at 01:26:16AM +0100, Lukas Wunner wrote:
> > On Sat, Jan 28, 2017 at 03:52:08PM -0600, Bjorn Helgaas wrote:
> > > On Sun, Jan 15, 2017 at 09:03:45PM +0100, Lukas Wunner wrote:
> 
> > > > +static void set_pcie_vendor_specific(struct pci_dev *dev)
> > > 
> > > This is very specific to Thunderbolt, so let's name it something that
> > > conveys that information.  The fact that we use a vendor-specific
> > > capability to figure it out isn't really relevant in the caller.
> > 
> > I thought that we may have the necessity in the future to parse other
> > VSECs on device probe, so I gave the function this generic name.
> > 
> > Think about it, every VSEC that needs to be parsed needs the while loop
> > below.  It's more efficient to have only a single while loop that handles
> > *all* VSECs at once.
> > 
> > If someone needs to parse another VSEC, they just add it to this function.
> > So IMO the way I've solved it is preferable to just adding a Thunderbolt-
> > specific function.
> > 
> > Are you sure you want this renamed? (y/n)
> 
> Sorry for the delay; I missed this question.  If this has already been
> merged somewhere as-is, that's fine.

No, none of the patches in this series have been merged so far.  Greg's
tree is closed for the duration of the merge window, which is expected
to open today.  Therefore, please merge whatever patches in this series
you feel comfortable with.  It would be good if you could merge at least
patch [1/8] as it would allow me to fix the issues in apple-gmux and
vga_switcheroo that I'm mentioning in the changelog in v4.12.  Also,
patch [2/8] seems uncontroversial.

Greg has acked v5 of this series and suggested that you take it due to
all the PCI changes:
https://lkml.org/lkml/2017/1/19/177

Andreas Noever acked and tested v2 of this series:
https://www.spinics.net/lists/linux-pci/msg51274.html


> If you repost it for any reason,
> I would prefer to rename it so it reflects the functionality rather
> than the source of the information.  This isn't a performance path, so
> readability is more important than optimization.

Sure, I've renamed it.

Thanks,

Lukas

Re: net/llc: bug in llc_pdu_init_as_xid_cmd/skb_over_panic

[Andrey Konovalov]

On Fri, Feb 10, 2017 at 4:12 PM, Andrey Konovalov  wrote:
> Hi,
>
> I've got the following error report while fuzzing the kernel with syzkaller.
>
> On commit 926af6273fc683cd98cd0ce7bf0d04a02eed6742.
>
> A reproducer and .config are attached
>
> kernel BUG at net/core/skbuff.c:105!
> invalid opcode:  [#1] SMP KASAN
> Dumping ftrace buffer:
>(ftrace buffer empty)
> Modules linked in:
> CPU: 2 PID: 6558 Comm: syz-executor4 Not tainted 4.10.0-rc7+ #126
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
> task: 88003c49c480 task.stack: 88003a5c
> RIP: 0010:skb_panic+0x16f/0x200 net/core/skbuff.c:101
> RSP: 0018:88003a5c77d0 EFLAGS: 00010286
> RAX: 0082 RBX: 88006be991c0 RCX: 
> RDX: 0082 RSI: 814567fc RDI: ed00074b8eec
> RBP: 88003a5c7838 R08: 0001 R09: 
> R10: 0002 R11: 0001 R12: 85231ee0
> R13: 834a6722 R14: 0003 R15: 88006c81c580
> FS:  7f89298c7700() GS:88006de0() knlGS:
> CS:  0010 DS:  ES:  CR0: 80050033
> CR2: 20ee5000 CR3: 58697000 CR4: 06e0
> Call Trace:
>  skb_over_panic net/core/skbuff.c:110 [inline]
>  skb_put+0x18d/0x1d0 net/core/skbuff.c:1437
>  llc_pdu_init_as_xid_cmd include/net/llc_pdu.h:377 [inline]
>  llc_sap_action_send_xid_c+0x2a2/0x3b0 net/llc/llc_s_ac.c:82
>  llc_exec_sap_trans_actions net/llc/llc_sap.c:152 [inline]
>  llc_sap_next_state net/llc/llc_sap.c:181 [inline]
>  llc_sap_state_process+0x26b/0x4e0 net/llc/llc_sap.c:212
>  llc_build_and_send_xid_pkt+0x19f/0x200 net/llc/llc_sap.c:276
>  llc_ui_sendmsg+0xad9/0x1430 net/llc/af_llc.c:938
>  sock_sendmsg_nosec net/socket.c:635 [inline]
>  sock_sendmsg+0xca/0x110 net/socket.c:645
>  ___sys_sendmsg+0x9d2/0xae0 net/socket.c:1985
>  __sys_sendmsg+0x138/0x320 net/socket.c:2019
>  SYSC_sendmsg net/socket.c:2030 [inline]
>  SyS_sendmsg+0x2d/0x50 net/socket.c:2026
>  entry_SYSCALL_64_fastpath+0x1f/0xc2
> RIP: 0033:0x4458b9
> RSP: 002b:7f89298c6b58 EFLAGS: 0286 ORIG_RAX: 002e
> RAX: ffda RBX: 0005 RCX: 004458b9
> RDX: 00040085 RSI: 20001fc8 RDI: 0005
> RBP: 006e1ae0 R08:  R09: 
> R10:  R11: 0286 R12: 00708000
> R13:  R14: c0206434 R15: 201fcfe0
> Code: 00 00 00 48 89 54 24 10 48 c7 c7 60 19 23 85 48 89 74 24 08 4c
> 89 04 24 4c 89 ea 4c 89 7c 24 18 45 89 f0 4c 89 e6 e8 1e c0 38 fe <0f>
> 0b 4c 89 4d b8 4c 89 45 c0 48 89 75 c8 48 89 55 d0 e8 6a 5e
> RIP: skb_panic+0x16f/0x200 net/core/skbuff.c:101 RSP: 88003a5c77d0
> ---[ end trace 89f0ca2ea5bc3ead ]---
> Kernel panic - not syncing: Fatal exception
> Dumping ftrace buffer:
>(ftrace buffer empty)
> Kernel Offset: disabled
> Rebooting in 86400 seconds..

+a...@redhat.com

Re: net/llc: bug in llc_pdu_init_as_xid_cmd/skb_over_panic

[Andrey Konovalov]

On Fri, Feb 10, 2017 at 4:12 PM, Andrey Konovalov  wrote:
> Hi,
>
> I've got the following error report while fuzzing the kernel with syzkaller.
>
> On commit 926af6273fc683cd98cd0ce7bf0d04a02eed6742.
>
> A reproducer and .config are attached
>
> kernel BUG at net/core/skbuff.c:105!
> invalid opcode:  [#1] SMP KASAN
> Dumping ftrace buffer:
>(ftrace buffer empty)
> Modules linked in:
> CPU: 2 PID: 6558 Comm: syz-executor4 Not tainted 4.10.0-rc7+ #126
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
> task: 88003c49c480 task.stack: 88003a5c
> RIP: 0010:skb_panic+0x16f/0x200 net/core/skbuff.c:101
> RSP: 0018:88003a5c77d0 EFLAGS: 00010286
> RAX: 0082 RBX: 88006be991c0 RCX: 
> RDX: 0082 RSI: 814567fc RDI: ed00074b8eec
> RBP: 88003a5c7838 R08: 0001 R09: 
> R10: 0002 R11: 0001 R12: 85231ee0
> R13: 834a6722 R14: 0003 R15: 88006c81c580
> FS:  7f89298c7700() GS:88006de0() knlGS:
> CS:  0010 DS:  ES:  CR0: 80050033
> CR2: 20ee5000 CR3: 58697000 CR4: 06e0
> Call Trace:
>  skb_over_panic net/core/skbuff.c:110 [inline]
>  skb_put+0x18d/0x1d0 net/core/skbuff.c:1437
>  llc_pdu_init_as_xid_cmd include/net/llc_pdu.h:377 [inline]
>  llc_sap_action_send_xid_c+0x2a2/0x3b0 net/llc/llc_s_ac.c:82
>  llc_exec_sap_trans_actions net/llc/llc_sap.c:152 [inline]
>  llc_sap_next_state net/llc/llc_sap.c:181 [inline]
>  llc_sap_state_process+0x26b/0x4e0 net/llc/llc_sap.c:212
>  llc_build_and_send_xid_pkt+0x19f/0x200 net/llc/llc_sap.c:276
>  llc_ui_sendmsg+0xad9/0x1430 net/llc/af_llc.c:938
>  sock_sendmsg_nosec net/socket.c:635 [inline]
>  sock_sendmsg+0xca/0x110 net/socket.c:645
>  ___sys_sendmsg+0x9d2/0xae0 net/socket.c:1985
>  __sys_sendmsg+0x138/0x320 net/socket.c:2019
>  SYSC_sendmsg net/socket.c:2030 [inline]
>  SyS_sendmsg+0x2d/0x50 net/socket.c:2026
>  entry_SYSCALL_64_fastpath+0x1f/0xc2
> RIP: 0033:0x4458b9
> RSP: 002b:7f89298c6b58 EFLAGS: 0286 ORIG_RAX: 002e
> RAX: ffda RBX: 0005 RCX: 004458b9
> RDX: 00040085 RSI: 20001fc8 RDI: 0005
> RBP: 006e1ae0 R08:  R09: 
> R10:  R11: 0286 R12: 00708000
> R13:  R14: c0206434 R15: 201fcfe0
> Code: 00 00 00 48 89 54 24 10 48 c7 c7 60 19 23 85 48 89 74 24 08 4c
> 89 04 24 4c 89 ea 4c 89 7c 24 18 45 89 f0 4c 89 e6 e8 1e c0 38 fe <0f>
> 0b 4c 89 4d b8 4c 89 45 c0 48 89 75 c8 48 89 55 d0 e8 6a 5e
> RIP: skb_panic+0x16f/0x200 net/core/skbuff.c:101 RSP: 88003a5c77d0
> ---[ end trace 89f0ca2ea5bc3ead ]---
> Kernel panic - not syncing: Fatal exception
> Dumping ftrace buffer:
>(ftrace buffer empty)
> Kernel Offset: disabled
> Rebooting in 86400 seconds..

+a...@redhat.com

net/llc: BUG in llc_sap_state_process/skb_set_owner_r

[Andrey Konovalov]

Hi,

I've got the following error report while fuzzing the kernel with syzkaller.

On commit 926af6273fc683cd98cd0ce7bf0d04a02eed6742.

A reproducer and .config are attached

kernel BUG at ./include/linux/skbuff.h:2389!
invalid opcode:  [#1] SMP KASAN
Dumping ftrace buffer:
   (ftrace buffer empty)
Modules linked in:
CPU: 0 PID: 9315 Comm: syz-executor2 Not tainted 4.10.0-rc7+ #126
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
task: 88006861c480 task.stack: 88006a988000
RIP: 0010:skb_set_owner_r include/linux/skbuff.h:2389 [inline]
RIP: 0010:__sock_queue_rcv_skb+0x8c0/0xda0 net/core/sock.c:425
RSP: 0018:88003ec06b58 EFLAGS: 00010206
RAX: 88006861c480 RBX: 8800371c2568 RCX: 
RDX: 0100 RSI: 110006ba08ab RDI: 880035d04560
RBP: 88003ec06dc0 R08: 0002 R09: 0001
R10:  R11: dc00 R12: 880035d04540
R13: 88003ec06d98 R14: 8800371c2590 R15: 880035d045a0
FS:  7fa8005ac700() GS:88003ec0() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 004a6f68 CR3: 38e25000 CR4: 06f0
Call Trace:
 
 sock_queue_rcv_skb+0x3a/0x50 net/core/sock.c:451
 llc_sap_state_process+0x3e3/0x4e0 net/llc/llc_sap.c:220
 llc_sap_rcv net/llc/llc_sap.c:294 [inline]
 llc_sap_handler+0x695/0x1320 net/llc/llc_sap.c:434
 llc_rcv+0x6da/0xed0 net/llc/llc_input.c:208
 __netif_receive_skb_core+0x1ae5/0x3400 net/core/dev.c:4190
 __netif_receive_skb+0x2a/0x170 net/core/dev.c:4228
 process_backlog+0xe5/0x6c0 net/core/dev.c:4839
 napi_poll net/core/dev.c:5202 [inline]
 net_rx_action+0xe70/0x1900 net/core/dev.c:5267
 __do_softirq+0x2fb/0xb7d kernel/softirq.c:284
 do_softirq_own_stack+0x1c/0x30 arch/x86/entry/entry_64.S:902
 
 do_softirq.part.17+0x1e8/0x230 kernel/softirq.c:328
 do_softirq kernel/softirq.c:176 [inline]
 __local_bh_enable_ip+0x1f2/0x200 kernel/softirq.c:181
 local_bh_enable include/linux/bottom_half.h:31 [inline]
 rcu_read_unlock_bh include/linux/rcupdate.h:971 [inline]
 __dev_queue_xmit+0xd87/0x2860 net/core/dev.c:3399
 dev_queue_xmit+0x17/0x20 net/core/dev.c:3405
 llc_build_and_send_ui_pkt+0x240/0x330 net/llc/llc_output.c:74
 llc_ui_sendmsg+0x98d/0x1430 net/llc/af_llc.c:928
 sock_sendmsg_nosec net/socket.c:635 [inline]
 sock_sendmsg+0xca/0x110 net/socket.c:645
 ___sys_sendmsg+0x9d2/0xae0 net/socket.c:1985
 __sys_sendmsg+0x138/0x320 net/socket.c:2019
 SYSC_sendmsg net/socket.c:2030 [inline]
 SyS_sendmsg+0x2d/0x50 net/socket.c:2026
 entry_SYSCALL_64_fastpath+0x1f/0xc2
RIP: 0033:0x4458b9
RSP: 002b:7fa8005abb58 EFLAGS: 0286 ORIG_RAX: 002e
RAX: ffda RBX: 0006 RCX: 004458b9
RDX: 00040880 RSI: 20003000 RDI: 0006
RBP: 006e1b00 R08:  R09: 
R10:  R11: 0286 R12: 00708000
R13: 0082 R14: 2000 R15: 
Code: 4b 50 fe e9 b1 f8 ff ff e8 3e 4a 50 fe e9 78 f8 ff ff e8 34 4a
50 fe e9 6d f9 ff ff e8 2a 4a 50 fe e9 93 f9 ff ff e8 20 0a 26 fe <0f>
0b e8 19 0a 26 fe be 3c 01 00 00 48 c7 c7 e0 e9 22 85 e8 b8
RIP: skb_set_owner_r include/linux/skbuff.h:2389 [inline] RSP: 88003ec06b58
RIP: __sock_queue_rcv_skb+0x8c0/0xda0 net/core/sock.c:425 RSP: 88003ec06b58
---[ end trace 58af2d02ad7f84f0 ]---
Kernel panic - not syncing: Fatal exception in interrupt
Dumping ftrace buffer:
   (ftrace buffer empty)
Kernel Offset: disabled
Rebooting in 86400 seconds..
// autogenerated by syzkaller (http://github.com/google/syzkaller)

#ifndef __NR_sendmsg
#define __NR_sendmsg 46
#endif
#ifndef __NR_mmap
#define __NR_mmap 9
#endif
#ifndef __NR_socket
#define __NR_socket 41
#endif
#ifndef __NR_connect
#define __NR_connect 42
#endif

#define _GNU_SOURCE

#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

#include 
#include 
#include 
#include 
#include 
#include 

#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

const int kFailStatus = 67;
const int kErrorStatus = 68;
const int kRetryStatus = 69;

__attribute__((noreturn)) void doexit(int status)
{
  volatile unsigned i;
  syscall(__NR_exit_group, status);
  for (i = 0;; i++) {
  }
}

__attribute__((noreturn)) void fail(const char* msg, ...)
{
  int e = errno;
  fflush(stdout);
  va_list args;
  va_start(args, msg);
  vfprintf(stderr, msg, args);
  va_end(args);
  fprintf(stderr, " (errno %d)\n", e);
  doexit(e == ENOMEM ? kRetryStatus : kFailStatus);
}

__attribute__((noreturn)) void exitf(const char* msg, ...)
{
  int e = errno;
  fflush(stdout);
  va_list args;
  va_start(args, msg);
  vfprintf(stderr, msg, args);
  va_end(args);
  fprintf(stderr, " (errno %d)\n", e);
  doexit(kRetryStatus);
}

static int flag_debug;

void debug(const char* 

net/llc: BUG in llc_sap_state_process/skb_set_owner_r

[Andrey Konovalov]

Hi,

I've got the following error report while fuzzing the kernel with syzkaller.

On commit 926af6273fc683cd98cd0ce7bf0d04a02eed6742.

A reproducer and .config are attached

kernel BUG at ./include/linux/skbuff.h:2389!
invalid opcode:  [#1] SMP KASAN
Dumping ftrace buffer:
   (ftrace buffer empty)
Modules linked in:
CPU: 0 PID: 9315 Comm: syz-executor2 Not tainted 4.10.0-rc7+ #126
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
task: 88006861c480 task.stack: 88006a988000
RIP: 0010:skb_set_owner_r include/linux/skbuff.h:2389 [inline]
RIP: 0010:__sock_queue_rcv_skb+0x8c0/0xda0 net/core/sock.c:425
RSP: 0018:88003ec06b58 EFLAGS: 00010206
RAX: 88006861c480 RBX: 8800371c2568 RCX: 
RDX: 0100 RSI: 110006ba08ab RDI: 880035d04560
RBP: 88003ec06dc0 R08: 0002 R09: 0001
R10:  R11: dc00 R12: 880035d04540
R13: 88003ec06d98 R14: 8800371c2590 R15: 880035d045a0
FS:  7fa8005ac700() GS:88003ec0() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 004a6f68 CR3: 38e25000 CR4: 06f0
Call Trace:
 
 sock_queue_rcv_skb+0x3a/0x50 net/core/sock.c:451
 llc_sap_state_process+0x3e3/0x4e0 net/llc/llc_sap.c:220
 llc_sap_rcv net/llc/llc_sap.c:294 [inline]
 llc_sap_handler+0x695/0x1320 net/llc/llc_sap.c:434
 llc_rcv+0x6da/0xed0 net/llc/llc_input.c:208
 __netif_receive_skb_core+0x1ae5/0x3400 net/core/dev.c:4190
 __netif_receive_skb+0x2a/0x170 net/core/dev.c:4228
 process_backlog+0xe5/0x6c0 net/core/dev.c:4839
 napi_poll net/core/dev.c:5202 [inline]
 net_rx_action+0xe70/0x1900 net/core/dev.c:5267
 __do_softirq+0x2fb/0xb7d kernel/softirq.c:284
 do_softirq_own_stack+0x1c/0x30 arch/x86/entry/entry_64.S:902
 
 do_softirq.part.17+0x1e8/0x230 kernel/softirq.c:328
 do_softirq kernel/softirq.c:176 [inline]
 __local_bh_enable_ip+0x1f2/0x200 kernel/softirq.c:181
 local_bh_enable include/linux/bottom_half.h:31 [inline]
 rcu_read_unlock_bh include/linux/rcupdate.h:971 [inline]
 __dev_queue_xmit+0xd87/0x2860 net/core/dev.c:3399
 dev_queue_xmit+0x17/0x20 net/core/dev.c:3405
 llc_build_and_send_ui_pkt+0x240/0x330 net/llc/llc_output.c:74
 llc_ui_sendmsg+0x98d/0x1430 net/llc/af_llc.c:928
 sock_sendmsg_nosec net/socket.c:635 [inline]
 sock_sendmsg+0xca/0x110 net/socket.c:645
 ___sys_sendmsg+0x9d2/0xae0 net/socket.c:1985
 __sys_sendmsg+0x138/0x320 net/socket.c:2019
 SYSC_sendmsg net/socket.c:2030 [inline]
 SyS_sendmsg+0x2d/0x50 net/socket.c:2026
 entry_SYSCALL_64_fastpath+0x1f/0xc2
RIP: 0033:0x4458b9
RSP: 002b:7fa8005abb58 EFLAGS: 0286 ORIG_RAX: 002e
RAX: ffda RBX: 0006 RCX: 004458b9
RDX: 00040880 RSI: 20003000 RDI: 0006
RBP: 006e1b00 R08:  R09: 
R10:  R11: 0286 R12: 00708000
R13: 0082 R14: 2000 R15: 
Code: 4b 50 fe e9 b1 f8 ff ff e8 3e 4a 50 fe e9 78 f8 ff ff e8 34 4a
50 fe e9 6d f9 ff ff e8 2a 4a 50 fe e9 93 f9 ff ff e8 20 0a 26 fe <0f>
0b e8 19 0a 26 fe be 3c 01 00 00 48 c7 c7 e0 e9 22 85 e8 b8
RIP: skb_set_owner_r include/linux/skbuff.h:2389 [inline] RSP: 88003ec06b58
RIP: __sock_queue_rcv_skb+0x8c0/0xda0 net/core/sock.c:425 RSP: 88003ec06b58
---[ end trace 58af2d02ad7f84f0 ]---
Kernel panic - not syncing: Fatal exception in interrupt
Dumping ftrace buffer:
   (ftrace buffer empty)
Kernel Offset: disabled
Rebooting in 86400 seconds..
// autogenerated by syzkaller (http://github.com/google/syzkaller)

#ifndef __NR_sendmsg
#define __NR_sendmsg 46
#endif
#ifndef __NR_mmap
#define __NR_mmap 9
#endif
#ifndef __NR_socket
#define __NR_socket 41
#endif
#ifndef __NR_connect
#define __NR_connect 42
#endif

#define _GNU_SOURCE

#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

#include 
#include 
#include 
#include 
#include 
#include 

#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

const int kFailStatus = 67;
const int kErrorStatus = 68;
const int kRetryStatus = 69;

__attribute__((noreturn)) void doexit(int status)
{
  volatile unsigned i;
  syscall(__NR_exit_group, status);
  for (i = 0;; i++) {
  }
}

__attribute__((noreturn)) void fail(const char* msg, ...)
{
  int e = errno;
  fflush(stdout);
  va_list args;
  va_start(args, msg);
  vfprintf(stderr, msg, args);
  va_end(args);
  fprintf(stderr, " (errno %d)\n", e);
  doexit(e == ENOMEM ? kRetryStatus : kFailStatus);
}

__attribute__((noreturn)) void exitf(const char* msg, ...)
{
  int e = errno;
  fflush(stdout);
  va_list args;
  va_start(args, msg);
  vfprintf(stderr, msg, args);
  va_end(args);
  fprintf(stderr, " (errno %d)\n", e);
  doexit(kRetryStatus);
}

static int flag_debug;

void debug(const char* 

[PATCH] spi-nor: use ERR_CAST in return

[Nicholas Mc Guire]

This fixes a sparse warning about 

Signed-off-by: Nicholas Mc Guire 
---

sparse complained about:
drivers/mtd/spi-nor/intel-spi.c:731:28: warning: incorrect type in return 
expression (different address spaces)
drivers/mtd/spi-nor/intel-spi.c:731:28:expected struct intel_spi *
drivers/mtd/spi-nor/intel-spi.c:731:28:got void [noderef] *base

Patch was compile tested with: multi_v7_defconfig (implies CONFIG_MTD_SPI_NOR=y)

Patch is against 4.10-rc6 (localversion-next is next-20170210)

 drivers/mtd/spi-nor/intel-spi.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/mtd/spi-nor/intel-spi.c b/drivers/mtd/spi-nor/intel-spi.c
index e43ce63..986a3d0 100644
--- a/drivers/mtd/spi-nor/intel-spi.c
+++ b/drivers/mtd/spi-nor/intel-spi.c
@@ -728,7 +728,7 @@ struct intel_spi *intel_spi_probe(struct device *dev,
 
ispi->base = devm_ioremap_resource(dev, mem);
if (IS_ERR(ispi->base))
-   return ispi->base;
+   return ERR_CAST(ispi->base);
 
ispi->dev = dev;
ispi->info = info;
-- 
2.1.4

[PATCH RFC] spi-nor: provide a range for poll_timout

[Nicholas Mc Guire]

The overall poll time here is INTEL_SPI_TIMEOUT * 1000 which is 
5000 * 1000 - so 5seconds and it is coded as a tight loop here delay_us
to readl_poll_timeout() is set to 0. As this is never called in an atomic
context sleeping should be no issue and there is no reasons for the
tight-loop here.

Signed-off-by: Nicholas Mc Guire 
---

Problem located by experimental coccinelle script:
./drivers/mtd/spi-nor/intel-spi.c:265:8-26: WARNING: usleep_range min=0 for 
delay INTEL_SPI_TIMEOUT * 1000
./drivers/mtd/spi-nor/intel-spi.c:274:8-26: WARNING: usleep_range min=0 for 
delay INTEL_SPI_TIMEOUT * 1000

The rational for setting the delay_us here to 40 is that readx_poll_timeout()
will take delay_us >> 2 + 1 as min value and that should be at least 10us (see
Documentation/timers/timers-howto.txt). Ideally the delay would be made
even larger to keep the load on the hrtimer subsystem low as these delays
here do not seem to be critical. Someone that knows the details of this device
would need to check if a larger delay would be ok here.

Patch was compile tested with: multi_v7_defconfig (implies CONFIG_MTD_SPI_NOR=y)
one coccicheck finding reported and one spars finding (in separate patches)

Patch is against 4.10-rc6 (localversion-next is next-20170210)

 drivers/mtd/spi-nor/intel-spi.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/mtd/spi-nor/intel-spi.c b/drivers/mtd/spi-nor/intel-spi.c
index a10f602..371bcf9 100644
--- a/drivers/mtd/spi-nor/intel-spi.c
+++ b/drivers/mtd/spi-nor/intel-spi.c
@@ -263,7 +263,7 @@ static int intel_spi_wait_hw_busy(struct intel_spi *ispi)
u32 val;
 
return readl_poll_timeout(ispi->base + HSFSTS_CTL, val,
- !(val & HSFSTS_CTL_SCIP), 0,
+ !(val & HSFSTS_CTL_SCIP), 40,
  INTEL_SPI_TIMEOUT * 1000);
 }
 
@@ -272,7 +272,7 @@ static int intel_spi_wait_sw_busy(struct intel_spi *ispi)
u32 val;
 
return readl_poll_timeout(ispi->sregs + SSFSTS_CTL, val,
- !(val & SSFSTS_CTL_SCIP), 0,
+ !(val & SSFSTS_CTL_SCIP), 40,
  INTEL_SPI_TIMEOUT * 1000);
 }
 
-- 
2.1.4

[PATCH] spi-nor: use ERR_CAST in return

[Nicholas Mc Guire]

This fixes a sparse warning about 

Signed-off-by: Nicholas Mc Guire 
---

sparse complained about:
drivers/mtd/spi-nor/intel-spi.c:731:28: warning: incorrect type in return 
expression (different address spaces)
drivers/mtd/spi-nor/intel-spi.c:731:28:expected struct intel_spi *
drivers/mtd/spi-nor/intel-spi.c:731:28:got void [noderef] *base

Patch was compile tested with: multi_v7_defconfig (implies CONFIG_MTD_SPI_NOR=y)

Patch is against 4.10-rc6 (localversion-next is next-20170210)

 drivers/mtd/spi-nor/intel-spi.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/mtd/spi-nor/intel-spi.c b/drivers/mtd/spi-nor/intel-spi.c
index e43ce63..986a3d0 100644
--- a/drivers/mtd/spi-nor/intel-spi.c
+++ b/drivers/mtd/spi-nor/intel-spi.c
@@ -728,7 +728,7 @@ struct intel_spi *intel_spi_probe(struct device *dev,
 
ispi->base = devm_ioremap_resource(dev, mem);
if (IS_ERR(ispi->base))
-   return ispi->base;
+   return ERR_CAST(ispi->base);
 
ispi->dev = dev;
ispi->info = info;
-- 
2.1.4

[PATCH RFC] spi-nor: provide a range for poll_timout

[Nicholas Mc Guire]

The overall poll time here is INTEL_SPI_TIMEOUT * 1000 which is 
5000 * 1000 - so 5seconds and it is coded as a tight loop here delay_us
to readl_poll_timeout() is set to 0. As this is never called in an atomic
context sleeping should be no issue and there is no reasons for the
tight-loop here.

Signed-off-by: Nicholas Mc Guire 
---

Problem located by experimental coccinelle script:
./drivers/mtd/spi-nor/intel-spi.c:265:8-26: WARNING: usleep_range min=0 for 
delay INTEL_SPI_TIMEOUT * 1000
./drivers/mtd/spi-nor/intel-spi.c:274:8-26: WARNING: usleep_range min=0 for 
delay INTEL_SPI_TIMEOUT * 1000

The rational for setting the delay_us here to 40 is that readx_poll_timeout()
will take delay_us >> 2 + 1 as min value and that should be at least 10us (see
Documentation/timers/timers-howto.txt). Ideally the delay would be made
even larger to keep the load on the hrtimer subsystem low as these delays
here do not seem to be critical. Someone that knows the details of this device
would need to check if a larger delay would be ok here.

Patch was compile tested with: multi_v7_defconfig (implies CONFIG_MTD_SPI_NOR=y)
one coccicheck finding reported and one spars finding (in separate patches)

Patch is against 4.10-rc6 (localversion-next is next-20170210)

 drivers/mtd/spi-nor/intel-spi.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/mtd/spi-nor/intel-spi.c b/drivers/mtd/spi-nor/intel-spi.c
index a10f602..371bcf9 100644
--- a/drivers/mtd/spi-nor/intel-spi.c
+++ b/drivers/mtd/spi-nor/intel-spi.c
@@ -263,7 +263,7 @@ static int intel_spi_wait_hw_busy(struct intel_spi *ispi)
u32 val;
 
return readl_poll_timeout(ispi->base + HSFSTS_CTL, val,
- !(val & HSFSTS_CTL_SCIP), 0,
+ !(val & HSFSTS_CTL_SCIP), 40,
  INTEL_SPI_TIMEOUT * 1000);
 }
 
@@ -272,7 +272,7 @@ static int intel_spi_wait_sw_busy(struct intel_spi *ispi)
u32 val;
 
return readl_poll_timeout(ispi->sregs + SSFSTS_CTL, val,
- !(val & SSFSTS_CTL_SCIP), 0,
+ !(val & SSFSTS_CTL_SCIP), 40,
  INTEL_SPI_TIMEOUT * 1000);
 }
 
-- 
2.1.4

[PATCH] spi-nor: use true/false for bool

[Nicholas Mc Guire]

writeable in struct intel_spi is a boolean and assignment should be to 
true/false not 1/0 as recommended by boolinit.cocci.

Signed-off-by: Nicholas Mc Guire 
---

make coccicheck complained with:
 ./drivers/mtd/spi-nor/intel-spi.c:707:3-18: WARNING: Assignment of bool to 0/1

Patch was compile tested with: multi_v7_defconfig (implies CONFIG_MTD_SPI_NOR=y)

Patch is against 4.10-rc6 (localversion-next is next-20170210)

 drivers/mtd/spi-nor/intel-spi.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/mtd/spi-nor/intel-spi.c b/drivers/mtd/spi-nor/intel-spi.c
index a10f602..e43ce63 100644
--- a/drivers/mtd/spi-nor/intel-spi.c
+++ b/drivers/mtd/spi-nor/intel-spi.c
@@ -704,7 +704,7 @@ static void intel_spi_fill_partition(struct intel_spi *ispi,
 * whole partition read-only to be on the safe side.
 */
if (intel_spi_is_protected(ispi, base, limit))
-   ispi->writeable = 0;
+   ispi->writeable = false;
 
end = (limit << 12) + 4096;
if (end > part->size)
-- 
2.1.4

[PATCH] spi-nor: use true/false for bool

[Nicholas Mc Guire]

writeable in struct intel_spi is a boolean and assignment should be to 
true/false not 1/0 as recommended by boolinit.cocci.

Signed-off-by: Nicholas Mc Guire 
---

make coccicheck complained with:
 ./drivers/mtd/spi-nor/intel-spi.c:707:3-18: WARNING: Assignment of bool to 0/1

Patch was compile tested with: multi_v7_defconfig (implies CONFIG_MTD_SPI_NOR=y)

Patch is against 4.10-rc6 (localversion-next is next-20170210)

 drivers/mtd/spi-nor/intel-spi.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/mtd/spi-nor/intel-spi.c b/drivers/mtd/spi-nor/intel-spi.c
index a10f602..e43ce63 100644
--- a/drivers/mtd/spi-nor/intel-spi.c
+++ b/drivers/mtd/spi-nor/intel-spi.c
@@ -704,7 +704,7 @@ static void intel_spi_fill_partition(struct intel_spi *ispi,
 * whole partition read-only to be on the safe side.
 */
if (intel_spi_is_protected(ispi, base, limit))
-   ispi->writeable = 0;
+   ispi->writeable = false;
 
end = (limit << 12) + 4096;
if (end > part->size)
-- 
2.1.4

[PATCH] net: neterion: vxge: use new api ethtool_{get|set}_link_ksettings

[Philippe Reynes]

The ethtool api {get|set}_settings is deprecated.
We move this driver to new api {get|set}_link_ksettings.

As I don't have the hardware, I'd be very pleased if
someone may test this patch.

Signed-off-by: Philippe Reynes 
---
 drivers/net/ethernet/neterion/vxge/vxge-ethtool.c |   47 -
 1 files changed, 27 insertions(+), 20 deletions(-)

diff --git a/drivers/net/ethernet/neterion/vxge/vxge-ethtool.c 
b/drivers/net/ethernet/neterion/vxge/vxge-ethtool.c
index 9a29670..db55e6d 100644
--- a/drivers/net/ethernet/neterion/vxge/vxge-ethtool.c
+++ b/drivers/net/ethernet/neterion/vxge/vxge-ethtool.c
@@ -38,9 +38,9 @@
 };
 
 /**
- * vxge_ethtool_sset - Sets different link parameters.
+ * vxge_ethtool_set_link_ksettings - Sets different link parameters.
  * @dev: device pointer.
- * @info: pointer to the structure with parameters given by ethtool to set
+ * @cmd: pointer to the structure with parameters given by ethtool to set
  * link information.
  *
  * The function sets different link parameters provided by the user onto
@@ -48,44 +48,51 @@
  * Return value:
  * 0 on success.
  */
-static int vxge_ethtool_sset(struct net_device *dev, struct ethtool_cmd *info)
+static int
+vxge_ethtool_set_link_ksettings(struct net_device *dev,
+   const struct ethtool_link_ksettings *cmd)
 {
/* We currently only support 10Gb/FULL */
-   if ((info->autoneg == AUTONEG_ENABLE) ||
-   (ethtool_cmd_speed(info) != SPEED_1) ||
-   (info->duplex != DUPLEX_FULL))
+   if ((cmd->base.autoneg == AUTONEG_ENABLE) ||
+   (cmd->base.speed != SPEED_1) ||
+   (cmd->base.duplex != DUPLEX_FULL))
return -EINVAL;
 
return 0;
 }
 
 /**
- * vxge_ethtool_gset - Return link specific information.
+ * vxge_ethtool_get_link_ksettings - Return link specific information.
  * @dev: device pointer.
- * @info: pointer to the structure with parameters given by ethtool
+ * @cmd: pointer to the structure with parameters given by ethtool
  * to return link information.
  *
  * Returns link specific information like speed, duplex etc.. to ethtool.
  * Return value :
  * return 0 on success.
  */
-static int vxge_ethtool_gset(struct net_device *dev, struct ethtool_cmd *info)
+static int vxge_ethtool_get_link_ksettings(struct net_device *dev,
+  struct ethtool_link_ksettings *cmd)
 {
-   info->supported = (SUPPORTED_1baseT_Full | SUPPORTED_FIBRE);
-   info->advertising = (ADVERTISED_1baseT_Full | ADVERTISED_FIBRE);
-   info->port = PORT_FIBRE;
+   ethtool_link_ksettings_zero_link_mode(cmd, supported);
+   ethtool_link_ksettings_add_link_mode(cmd, supported, 1baseT_Full);
+   ethtool_link_ksettings_add_link_mode(cmd, supported, FIBRE);
 
-   info->transceiver = XCVR_EXTERNAL;
+   ethtool_link_ksettings_zero_link_mode(cmd, advertising);
+   ethtool_link_ksettings_add_link_mode(cmd, advertising, 1baseT_Full);
+   ethtool_link_ksettings_add_link_mode(cmd, advertising, FIBRE);
+
+   cmd->base.port = PORT_FIBRE;
 
if (netif_carrier_ok(dev)) {
-   ethtool_cmd_speed_set(info, SPEED_1);
-   info->duplex = DUPLEX_FULL;
+   cmd->base.speed = SPEED_1;
+   cmd->base.duplex = DUPLEX_FULL;
} else {
-   ethtool_cmd_speed_set(info, SPEED_UNKNOWN);
-   info->duplex = DUPLEX_UNKNOWN;
+   cmd->base.speed = SPEED_UNKNOWN;
+   cmd->base.duplex = DUPLEX_UNKNOWN;
}
 
-   info->autoneg = AUTONEG_DISABLE;
+   cmd->base.autoneg = AUTONEG_DISABLE;
return 0;
 }
 
@@ -1126,8 +1133,6 @@ static int vxge_fw_flash(struct net_device *dev, struct 
ethtool_flash *parms)
 }
 
 static const struct ethtool_ops vxge_ethtool_ops = {
-   .get_settings   = vxge_ethtool_gset,
-   .set_settings   = vxge_ethtool_sset,
.get_drvinfo= vxge_ethtool_gdrvinfo,
.get_regs_len   = vxge_ethtool_get_regs_len,
.get_regs   = vxge_ethtool_gregs,
@@ -1139,6 +1144,8 @@ static int vxge_fw_flash(struct net_device *dev, struct 
ethtool_flash *parms)
.get_sset_count = vxge_ethtool_get_sset_count,
.get_ethtool_stats  = vxge_get_ethtool_stats,
.flash_device   = vxge_fw_flash,
+   .get_link_ksettings = vxge_ethtool_get_link_ksettings,
+   .set_link_ksettings = vxge_ethtool_set_link_ksettings,
 };
 
 void vxge_initialize_ethtool_ops(struct net_device *ndev)
-- 
1.7.4.4

[PATCH] net: neterion: vxge: use new api ethtool_{get|set}_link_ksettings

[Philippe Reynes]

The ethtool api {get|set}_settings is deprecated.
We move this driver to new api {get|set}_link_ksettings.

As I don't have the hardware, I'd be very pleased if
someone may test this patch.

Signed-off-by: Philippe Reynes 
---
 drivers/net/ethernet/neterion/vxge/vxge-ethtool.c |   47 -
 1 files changed, 27 insertions(+), 20 deletions(-)

diff --git a/drivers/net/ethernet/neterion/vxge/vxge-ethtool.c 
b/drivers/net/ethernet/neterion/vxge/vxge-ethtool.c
index 9a29670..db55e6d 100644
--- a/drivers/net/ethernet/neterion/vxge/vxge-ethtool.c
+++ b/drivers/net/ethernet/neterion/vxge/vxge-ethtool.c
@@ -38,9 +38,9 @@
 };
 
 /**
- * vxge_ethtool_sset - Sets different link parameters.
+ * vxge_ethtool_set_link_ksettings - Sets different link parameters.
  * @dev: device pointer.
- * @info: pointer to the structure with parameters given by ethtool to set
+ * @cmd: pointer to the structure with parameters given by ethtool to set
  * link information.
  *
  * The function sets different link parameters provided by the user onto
@@ -48,44 +48,51 @@
  * Return value:
  * 0 on success.
  */
-static int vxge_ethtool_sset(struct net_device *dev, struct ethtool_cmd *info)
+static int
+vxge_ethtool_set_link_ksettings(struct net_device *dev,
+   const struct ethtool_link_ksettings *cmd)
 {
/* We currently only support 10Gb/FULL */
-   if ((info->autoneg == AUTONEG_ENABLE) ||
-   (ethtool_cmd_speed(info) != SPEED_1) ||
-   (info->duplex != DUPLEX_FULL))
+   if ((cmd->base.autoneg == AUTONEG_ENABLE) ||
+   (cmd->base.speed != SPEED_1) ||
+   (cmd->base.duplex != DUPLEX_FULL))
return -EINVAL;
 
return 0;
 }
 
 /**
- * vxge_ethtool_gset - Return link specific information.
+ * vxge_ethtool_get_link_ksettings - Return link specific information.
  * @dev: device pointer.
- * @info: pointer to the structure with parameters given by ethtool
+ * @cmd: pointer to the structure with parameters given by ethtool
  * to return link information.
  *
  * Returns link specific information like speed, duplex etc.. to ethtool.
  * Return value :
  * return 0 on success.
  */
-static int vxge_ethtool_gset(struct net_device *dev, struct ethtool_cmd *info)
+static int vxge_ethtool_get_link_ksettings(struct net_device *dev,
+  struct ethtool_link_ksettings *cmd)
 {
-   info->supported = (SUPPORTED_1baseT_Full | SUPPORTED_FIBRE);
-   info->advertising = (ADVERTISED_1baseT_Full | ADVERTISED_FIBRE);
-   info->port = PORT_FIBRE;
+   ethtool_link_ksettings_zero_link_mode(cmd, supported);
+   ethtool_link_ksettings_add_link_mode(cmd, supported, 1baseT_Full);
+   ethtool_link_ksettings_add_link_mode(cmd, supported, FIBRE);
 
-   info->transceiver = XCVR_EXTERNAL;
+   ethtool_link_ksettings_zero_link_mode(cmd, advertising);
+   ethtool_link_ksettings_add_link_mode(cmd, advertising, 1baseT_Full);
+   ethtool_link_ksettings_add_link_mode(cmd, advertising, FIBRE);
+
+   cmd->base.port = PORT_FIBRE;
 
if (netif_carrier_ok(dev)) {
-   ethtool_cmd_speed_set(info, SPEED_1);
-   info->duplex = DUPLEX_FULL;
+   cmd->base.speed = SPEED_1;
+   cmd->base.duplex = DUPLEX_FULL;
} else {
-   ethtool_cmd_speed_set(info, SPEED_UNKNOWN);
-   info->duplex = DUPLEX_UNKNOWN;
+   cmd->base.speed = SPEED_UNKNOWN;
+   cmd->base.duplex = DUPLEX_UNKNOWN;
}
 
-   info->autoneg = AUTONEG_DISABLE;
+   cmd->base.autoneg = AUTONEG_DISABLE;
return 0;
 }
 
@@ -1126,8 +1133,6 @@ static int vxge_fw_flash(struct net_device *dev, struct 
ethtool_flash *parms)
 }
 
 static const struct ethtool_ops vxge_ethtool_ops = {
-   .get_settings   = vxge_ethtool_gset,
-   .set_settings   = vxge_ethtool_sset,
.get_drvinfo= vxge_ethtool_gdrvinfo,
.get_regs_len   = vxge_ethtool_get_regs_len,
.get_regs   = vxge_ethtool_gregs,
@@ -1139,6 +1144,8 @@ static int vxge_fw_flash(struct net_device *dev, struct 
ethtool_flash *parms)
.get_sset_count = vxge_ethtool_get_sset_count,
.get_ethtool_stats  = vxge_get_ethtool_stats,
.flash_device   = vxge_fw_flash,
+   .get_link_ksettings = vxge_ethtool_get_link_ksettings,
+   .set_link_ksettings = vxge_ethtool_set_link_ksettings,
 };
 
 void vxge_initialize_ethtool_ops(struct net_device *ndev)
-- 
1.7.4.4

Re: [PATCH v5 7/8] thunderbolt: Power down controller when idle

[Lukas Wunner]

On Sat, Jan 28, 2017 at 05:32:37PM -0600, Bjorn Helgaas wrote:
> On Sun, Jan 15, 2017 at 09:03:45PM +0100, Lukas Wunner wrote:
> > A Thunderbolt controller appears to the OS as a set of virtual devices:
> > One upstream bridge, multiple downstream bridges and one NHI (Native
> > Host Interface).  The upstream and downstream bridges represent a PCIe
> > switch (see definition of a switch in the PCIe spec).  The NHI device is
> > used to manage the switch fabric.  Hotplugged devices appear behind the
> > downstream bridges:
> > 
> >   (Root Port)  Upstream Bridge --+-- Downstream Bridge 0  NHI
> >  +-- Downstream Bridge 1 --
> >  +-- Downstream Bridge 2 --
> >  ...
> > 
> > Power is cut to the entire set of devices.  The Linux pm model is
> > hierarchical and assumes that a child cannot resume before its parent.
> > To conform to this model, power control must be governed by the
> > Thunderbolt controller's topmost device, which is the upstream bridge.
> > The NHI and downstream bridges go to D3hot independently and the
> > upstream bridge goes to D3cold once all its children have suspended.
> > This commit only adds runtime pm for the upstream bridge.  Runtime pm
> > for the NHI is added in a separate commit to signify its independence.
> > Runtime pm for the downstream bridges is handled by the pcieport driver.
> > 
> > Because Apple's ACPI methods are nonstandard, a struct dev_pm_domain is
> > used to override the PCI bus pm_ops.  The thunderbolt driver binds to
> 
> What are the default PCI bus pm_ops?  I looked briefly for it to see
> if there was some way to use hooks there instead of using
> dev_pm_domain_set() with its weird out-of-orderness.

The default PCI bus pm_ops are defined in drivers/pci/pci-driver.c as
struct dev_pm_ops pci_dev_pm_ops.

I did hook into those callbacks in an earlier version of this series
but it required more patches and more modifications to the PCI core
and PCIe port services driver to get Thunderbolt runpm to work:
https://www.spinics.net/lists/linux-pci/msg51158.html

Using dev_pm_domain_set() is the de facto standard to solve this,
vga_switcheroo does the same, that's why I settled on this approach.
(see drivers/gpu/vga/vga_switcheroo.c:vga_switcheroo_init_domain_pm_ops())


> I guess what you do in thunderbolt_power_init() is copy the upstream
> device's bus's ops, then override a few of them?  Seems like we then
> have the problem of keeping the Thunderbolt ones in sync with the
> generic ones, e.g., if something got added to the generic one,
> somebody should look at the Thunderbolt one to see if it's also need
> there?

Not a problem.  upstream_runtime_suspend() essentially does this:

// call pci_dev_pm_ops ->runtime_suspend hook:
ret = dev->bus->pm->runtime_suspend(dev);
// power down:
acpi_execute_simple_method(power->set, NULL, 0)
// enable wake interrupt:
acpi_enable_gpe(NULL, power->wake_gpe)

So any changes to the pci_dev_pm_ops are inherited.  Again,
vga_switcheroo does the same (see vga_switcheroo_runtime_suspend()).


> > +#define pr_fmt(fmt) KBUILD_MODNAME " %s: " fmt, dev_name(dev)
[...]
> > +   /* prevent interrupts during system sleep transition */
> > +   if (ACPI_FAILURE(acpi_disable_gpe(NULL, power->wake_gpe))) {
> > +   pr_err("cannot disable wake GPE, resuming\n");
> 
> Can you use dev_err() here and below?  This is related to a specific
> device, and it'd be nice to know which one.

See above, the device name is included in pr_fmt.  The reason to use
pr_err() instead of dev_err() is to get the error message prefixed
with "thunderbolt" instead of "pcieport".  Recall that this function
is executed in the context of the upstream bridge, whose driver name
is pcieport.  I would like to prevent people from grepping the portdrv
code for the error message.  You're the second person to raise this
question (Andy Shevchenko made the same comment on an earlier version
of this patch), so I've now added a comment to explain it.


> > +void thunderbolt_power_init(struct tb *tb)
> > +{
> > +   struct device *upstream_dev, *nhi_dev = >nhi->pdev->dev;
> > +   struct tb_power *power = NULL;
> 
> Unnecessary initialization.

Good point.

Thanks,

Lukas

Re: [PATCH v5 7/8] thunderbolt: Power down controller when idle

[Lukas Wunner]

On Sat, Jan 28, 2017 at 05:32:37PM -0600, Bjorn Helgaas wrote:
> On Sun, Jan 15, 2017 at 09:03:45PM +0100, Lukas Wunner wrote:
> > A Thunderbolt controller appears to the OS as a set of virtual devices:
> > One upstream bridge, multiple downstream bridges and one NHI (Native
> > Host Interface).  The upstream and downstream bridges represent a PCIe
> > switch (see definition of a switch in the PCIe spec).  The NHI device is
> > used to manage the switch fabric.  Hotplugged devices appear behind the
> > downstream bridges:
> > 
> >   (Root Port)  Upstream Bridge --+-- Downstream Bridge 0  NHI
> >  +-- Downstream Bridge 1 --
> >  +-- Downstream Bridge 2 --
> >  ...
> > 
> > Power is cut to the entire set of devices.  The Linux pm model is
> > hierarchical and assumes that a child cannot resume before its parent.
> > To conform to this model, power control must be governed by the
> > Thunderbolt controller's topmost device, which is the upstream bridge.
> > The NHI and downstream bridges go to D3hot independently and the
> > upstream bridge goes to D3cold once all its children have suspended.
> > This commit only adds runtime pm for the upstream bridge.  Runtime pm
> > for the NHI is added in a separate commit to signify its independence.
> > Runtime pm for the downstream bridges is handled by the pcieport driver.
> > 
> > Because Apple's ACPI methods are nonstandard, a struct dev_pm_domain is
> > used to override the PCI bus pm_ops.  The thunderbolt driver binds to
> 
> What are the default PCI bus pm_ops?  I looked briefly for it to see
> if there was some way to use hooks there instead of using
> dev_pm_domain_set() with its weird out-of-orderness.

The default PCI bus pm_ops are defined in drivers/pci/pci-driver.c as
struct dev_pm_ops pci_dev_pm_ops.

I did hook into those callbacks in an earlier version of this series
but it required more patches and more modifications to the PCI core
and PCIe port services driver to get Thunderbolt runpm to work:
https://www.spinics.net/lists/linux-pci/msg51158.html

Using dev_pm_domain_set() is the de facto standard to solve this,
vga_switcheroo does the same, that's why I settled on this approach.
(see drivers/gpu/vga/vga_switcheroo.c:vga_switcheroo_init_domain_pm_ops())


> I guess what you do in thunderbolt_power_init() is copy the upstream
> device's bus's ops, then override a few of them?  Seems like we then
> have the problem of keeping the Thunderbolt ones in sync with the
> generic ones, e.g., if something got added to the generic one,
> somebody should look at the Thunderbolt one to see if it's also need
> there?

Not a problem.  upstream_runtime_suspend() essentially does this:

// call pci_dev_pm_ops ->runtime_suspend hook:
ret = dev->bus->pm->runtime_suspend(dev);
// power down:
acpi_execute_simple_method(power->set, NULL, 0)
// enable wake interrupt:
acpi_enable_gpe(NULL, power->wake_gpe)

So any changes to the pci_dev_pm_ops are inherited.  Again,
vga_switcheroo does the same (see vga_switcheroo_runtime_suspend()).


> > +#define pr_fmt(fmt) KBUILD_MODNAME " %s: " fmt, dev_name(dev)
[...]
> > +   /* prevent interrupts during system sleep transition */
> > +   if (ACPI_FAILURE(acpi_disable_gpe(NULL, power->wake_gpe))) {
> > +   pr_err("cannot disable wake GPE, resuming\n");
> 
> Can you use dev_err() here and below?  This is related to a specific
> device, and it'd be nice to know which one.

See above, the device name is included in pr_fmt.  The reason to use
pr_err() instead of dev_err() is to get the error message prefixed
with "thunderbolt" instead of "pcieport".  Recall that this function
is executed in the context of the upstream bridge, whose driver name
is pcieport.  I would like to prevent people from grepping the portdrv
code for the error message.  You're the second person to raise this
question (Andy Shevchenko made the same comment on an earlier version
of this patch), so I've now added a comment to explain it.


> > +void thunderbolt_power_init(struct tb *tb)
> > +{
> > +   struct device *upstream_dev, *nhi_dev = >nhi->pdev->dev;
> > +   struct tb_power *power = NULL;
> 
> Unnecessary initialization.

Good point.

Thanks,

Lukas

Re: [PATCH v3] softirq: Prevent looping on disabled tasklets

[Chris Wilson]

On Sun, Feb 12, 2017 at 03:46:09PM +, Chris Wilson wrote:
> +void tasklet_enable(struct tasklet_struct *t)
> +{
> + if (!atomic_dec_and_test(>count))
> + return;
> +
> + if (test_bit(TASKLET_STATE_SCHED, >state))
> + raise_softirq(HI_SOFTIRQ | TASKLET_SOFTIRQ);

And of course this can't work as raise_softirq() is local to the cpu.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

Re: [PATCH v3] softirq: Prevent looping on disabled tasklets

[Chris Wilson]

On Sun, Feb 12, 2017 at 03:46:09PM +, Chris Wilson wrote:
> +void tasklet_enable(struct tasklet_struct *t)
> +{
> + if (!atomic_dec_and_test(>count))
> + return;
> +
> + if (test_bit(TASKLET_STATE_SCHED, >state))
> + raise_softirq(HI_SOFTIRQ | TASKLET_SOFTIRQ);

And of course this can't work as raise_softirq() is local to the cpu.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

[PATCH] staging:vt6656:channel.h: fix function definition argument without identifier name issue

[Arushi Singhal]

Function definitions arguments should also have an identifier name as
reported by checkpatch.pl.

Signed-off-by: Arushi Singhal 
---
 drivers/staging/vt6656/channel.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/vt6656/channel.h b/drivers/staging/vt6656/channel.h
index fcea6995fe26..62f18a959098 100644
--- a/drivers/staging/vt6656/channel.h
+++ b/drivers/staging/vt6656/channel.h
@@ -28,6 +28,6 @@
 
 #include "device.h"
 
-void vnt_init_bands(struct vnt_private *);
+void vnt_init_bands(struct vnt_private *priv);
 
 #endif  /* _CHANNEL_H_ */
-- 
2.11.0

[PATCH] staging:vt6656:channel.h: fix function definition argument without identifier name issue

[Arushi Singhal]

Function definitions arguments should also have an identifier name as
reported by checkpatch.pl.

Signed-off-by: Arushi Singhal 
---
 drivers/staging/vt6656/channel.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/vt6656/channel.h b/drivers/staging/vt6656/channel.h
index fcea6995fe26..62f18a959098 100644
--- a/drivers/staging/vt6656/channel.h
+++ b/drivers/staging/vt6656/channel.h
@@ -28,6 +28,6 @@
 
 #include "device.h"
 
-void vnt_init_bands(struct vnt_private *);
+void vnt_init_bands(struct vnt_private *priv);
 
 #endif  /* _CHANNEL_H_ */
-- 
2.11.0

Re: [REGRESSION] Two issues that prevent process accounting (taskstats) from working correctly

[Dmitry Romanov]

On Mon, Dec 19, 2016 at 01:06:00PM +0100, Martin Steigerwald wrote:
>
> 1) Sometimes process accounting does not work at all.
>
> The acct() system call (to activate process accounting) return value 0, 
> which means that process accounting is activated successfully.
> However, no process accounting records are written whatsoever. This 
> situation can be reproduced with the program 'acctdemo.c'
> that you can find as attachment. When this program gives the message 
> "found a process accounting record!", the situation is okay
> and process accounting works fine to the file '/tmp/mypacct'. When the 
> message 'No process accounting record yet' is repeatedly given,
> process accounting does not work and will not work at all. It might be 
> that you have to start this program several times before you get
> this situation (preferably start/finish lots of processes in the mean time).
> This problem is probably caused by a new mechanism introduced in the 
> kernel code (/linux/kernel/acct.c) that is called 'slow accounting'
> and has to be solved in the kernel code.
>
> I experience this problem on Debian8 with a 4.8 kernel and on CentOS7 
> with a 4.8 kernel.

I reported same problem on bugzilla as:

Bug 180841 - Process accounting sometimes do not append records for terminated 
processes 
https://bugzilla.kernel.org/show_bug.cgi?id=180841

I think I found cause of this problem and can suggest patch which correct this 
problem.

Problem arise in such situation:

Problem arise if between process accounting activation with call acct(...) and
first termination of process pass not less than one jiffy. (Note,  acct() return
successfully, with zero.) In such situation records for terminated processes 
do nod append to accounting file, until process accounting is restarted.

I wrote test program test.c for illustration described problem for kernel 
version 3.17-rc1 and later. This program create empty file for accounting, 
call system call acct() with this file, sleep for not less than one jiffy, 
create new process and exit this process. Then, program test size of accounting 
file. If size of file remain zero, it seems problem and program display message 
"Accounting file size = 0, process accounting did not add record to accounting 
file!".
On my system problem reproduce almost always by this test.c.

--
test.c
--
#include 
#include 
#include 
#include 
#include 
#include 

/* Accounting file name : */
#define ACCTFILENAME "/var/log/pacct"

int main() 
{
int fd;
int pid;
struct stat sb;

/* Turn off accounting */
if ( acct(NULL) < 0 ) {
perror("Process accounting off");
return -1;
}

/* Create empty accounting file */
fd = creat(ACCTFILENAME, S_IRUSR | S_IWUSR);
if ( fd == -1 ) {
perror("Accounting file creation");
return -1;
}
if ( close(fd) == -1) {
perror("Accounting file closing");
return -1;
}

/* Switch accounting on */
if ( acct(ACCTFILENAME) < 0 ) {
perror("Process accounting on");
return -1;
}

/* Delay must be at least 1 jiffy. 
For reproducing bug, some process exit must not happen during first 
jiffy.
If HZ >= 100, need delay minimum 10 ms. */
usleep(1);

/* Create and exit child process. The record for this process must be 
append 
by activated process accounting. */
pid = fork();
if (pid < 0) {
perror("Child process creating");
return -1;
}
/* Exit child process */
if (pid == 0) {
exit(0);
}
/* Wait for child process termination */
wait(NULL);

/* Get size of accounting file. */
if ( stat(ACCTFILENAME, ) == -1 ) {
perror("Getting accounting file status");
return -1;
}

if ( sb.st_size == 0 ) {
printf("Accounting file size = 0, process accounting did not 
add record to accounting file!\n");
}
else {
printf("Accounting file size > 0, expected behaviour.\n");
}

/* Turn off accounting and remove accounting file*/
if ( acct(NULL) < 0 ) {
perror("Process accounting off");
return -1;
}
if ( remove(ACCTFILENAME) == -1 ) {
perror("Removing accounting file");
return -1;
}

return 0;

}
--

I suppose that this problem may be solve in kernel versions 3.17-rc1 and 
later by following patch:

Signed-off-by: Dmitry Romanov 
---
 kernel/acct.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/acct.c b/kernel/acct.c
index 74963d1..37f1dc6 100644
--- a/kernel/acct.c
+++ b/kernel/acct.c
@@ -99,7 +99,7 @@ static 

Re: [REGRESSION] Two issues that prevent process accounting (taskstats) from working correctly

[Dmitry Romanov]

On Mon, Dec 19, 2016 at 01:06:00PM +0100, Martin Steigerwald wrote:
>
> 1) Sometimes process accounting does not work at all.
>
> The acct() system call (to activate process accounting) return value 0, 
> which means that process accounting is activated successfully.
> However, no process accounting records are written whatsoever. This 
> situation can be reproduced with the program 'acctdemo.c'
> that you can find as attachment. When this program gives the message 
> "found a process accounting record!", the situation is okay
> and process accounting works fine to the file '/tmp/mypacct'. When the 
> message 'No process accounting record yet' is repeatedly given,
> process accounting does not work and will not work at all. It might be 
> that you have to start this program several times before you get
> this situation (preferably start/finish lots of processes in the mean time).
> This problem is probably caused by a new mechanism introduced in the 
> kernel code (/linux/kernel/acct.c) that is called 'slow accounting'
> and has to be solved in the kernel code.
>
> I experience this problem on Debian8 with a 4.8 kernel and on CentOS7 
> with a 4.8 kernel.

I reported same problem on bugzilla as:

Bug 180841 - Process accounting sometimes do not append records for terminated 
processes 
https://bugzilla.kernel.org/show_bug.cgi?id=180841

I think I found cause of this problem and can suggest patch which correct this 
problem.

Problem arise in such situation:

Problem arise if between process accounting activation with call acct(...) and
first termination of process pass not less than one jiffy. (Note,  acct() return
successfully, with zero.) In such situation records for terminated processes 
do nod append to accounting file, until process accounting is restarted.

I wrote test program test.c for illustration described problem for kernel 
version 3.17-rc1 and later. This program create empty file for accounting, 
call system call acct() with this file, sleep for not less than one jiffy, 
create new process and exit this process. Then, program test size of accounting 
file. If size of file remain zero, it seems problem and program display message 
"Accounting file size = 0, process accounting did not add record to accounting 
file!".
On my system problem reproduce almost always by this test.c.

--
test.c
--
#include 
#include 
#include 
#include 
#include 
#include 

/* Accounting file name : */
#define ACCTFILENAME "/var/log/pacct"

int main() 
{
int fd;
int pid;
struct stat sb;

/* Turn off accounting */
if ( acct(NULL) < 0 ) {
perror("Process accounting off");
return -1;
}

/* Create empty accounting file */
fd = creat(ACCTFILENAME, S_IRUSR | S_IWUSR);
if ( fd == -1 ) {
perror("Accounting file creation");
return -1;
}
if ( close(fd) == -1) {
perror("Accounting file closing");
return -1;
}

/* Switch accounting on */
if ( acct(ACCTFILENAME) < 0 ) {
perror("Process accounting on");
return -1;
}

/* Delay must be at least 1 jiffy. 
For reproducing bug, some process exit must not happen during first 
jiffy.
If HZ >= 100, need delay minimum 10 ms. */
usleep(1);

/* Create and exit child process. The record for this process must be 
append 
by activated process accounting. */
pid = fork();
if (pid < 0) {
perror("Child process creating");
return -1;
}
/* Exit child process */
if (pid == 0) {
exit(0);
}
/* Wait for child process termination */
wait(NULL);

/* Get size of accounting file. */
if ( stat(ACCTFILENAME, ) == -1 ) {
perror("Getting accounting file status");
return -1;
}

if ( sb.st_size == 0 ) {
printf("Accounting file size = 0, process accounting did not 
add record to accounting file!\n");
}
else {
printf("Accounting file size > 0, expected behaviour.\n");
}

/* Turn off accounting and remove accounting file*/
if ( acct(NULL) < 0 ) {
perror("Process accounting off");
return -1;
}
if ( remove(ACCTFILENAME) == -1 ) {
perror("Removing accounting file");
return -1;
}

return 0;

}
--

I suppose that this problem may be solve in kernel versions 3.17-rc1 and 
later by following patch:

Signed-off-by: Dmitry Romanov 
---
 kernel/acct.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/acct.c b/kernel/acct.c
index 74963d1..37f1dc6 100644
--- a/kernel/acct.c
+++ b/kernel/acct.c
@@ -99,7 +99,7 @@ static int 

S2ram + btrfs with recent kernel => soft lockup warning and hard hang

[Bastien ROUCARIES]

Hi,

Since 3.8 s2ram on btrfs system lead to hang.

Could not save a trace will try to get a few picture but trace are similar to :
https://github.com/docker/docker/issues/15654
and
https://patchwork.kernel.org/patch/8352811/

It is 100% reproducible.

mount table
/dev/mapper/portable2015--bastien--vg-HOME on /var/cache/pbuilder type
btrfs 
(rw,relatime,lazytime,compress=zlib,space_cache,subvolid=934,subvol=/pbuilder)
/dev/mapper/portable2015--bastien--vg-HOME on /home type btrfs
(rw,nosuid,nodev,relatime,lazytime,compress=zlib,space_cache,subvolid=933,subvol=/home)

btrfs is over dm-crypt

Bastien

[PATCH v3] softirq: Prevent looping on disabled tasklets

[Chris Wilson]

Disabling a tasklet causes it not to run during tasklet_action, but is
put back onto the runnable tasklet list, and a new softirq raised. As
the softirq is raised from within __do_softirq() this causing
__do_softirq() to loop constantly until its timeslice expires and is
transferred to the ksoftirq thread. ksoftirq then permanently spins,
as on each action, the disabled tasklet keeps reraising the softirq.

Break this vicious cycle by moving the softirq from the action to the
final tasklet_enable().

This behaviour appears to be historic (since the first git import).
However, the looping until timeslice duration (to a max of 2ms) was
first introduced in commit c10d73671ad3 ("softirq: reduce latencies"),
with the restart limit restored in commit 34376a50fb1f ("Fix lockup
related to stop_machine being stuck in __do_softirq.")

v2: Export tasklet_enable() to work with modules.
v3: Restore the looping over a failed tasklet_trylock()

Reported-by: Tvrtko Ursulin 
Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
Cc: Thomas Gleixner 
Cc: Hannes Reinecke 
Cc: Jens Axboe 
Cc: Bjorn Helgaas 
Cc: Alexander Potapenko 
Cc: Chen Fan 
Cc: Ingo Molnar 
Cc: "Peter Zijlstra (Intel)" 
Cc: Sebastian Andrzej Siewior 
Cc: Johannes Thumshirn 
Cc: Emese Revfy 
Cc: Sagi Grimberg 
Cc: Eric Dumazet 
Cc: Tom Herbert 
Cc: Ben Hutchings 
---
 include/linux/interrupt.h |  7 +--
 kernel/softirq.c  | 20 ++--
 2 files changed, 19 insertions(+), 8 deletions(-)

diff --git a/include/linux/interrupt.h b/include/linux/interrupt.h
index 53144e78a369..a1fa88e7e509 100644
--- a/include/linux/interrupt.h
+++ b/include/linux/interrupt.h
@@ -611,12 +611,7 @@ static inline void tasklet_disable(struct tasklet_struct 
*t)
smp_mb();
 }
 
-static inline void tasklet_enable(struct tasklet_struct *t)
-{
-   smp_mb__before_atomic();
-   atomic_dec(>count);
-}
-
+extern void tasklet_enable(struct tasklet_struct *t);
 extern void tasklet_kill(struct tasklet_struct *t);
 extern void tasklet_kill_immediate(struct tasklet_struct *t, unsigned int cpu);
 extern void tasklet_init(struct tasklet_struct *t,
diff --git a/kernel/softirq.c b/kernel/softirq.c
index 080eb57789c4..47c8933d315e 100644
--- a/kernel/softirq.c
+++ b/kernel/softirq.c
@@ -516,6 +516,7 @@ static __latent_entropy void tasklet_action(struct 
softirq_action *a)
 
while (list) {
struct tasklet_struct *t = list;
+   bool raise_softirq = true;
 
list = list->next;
 
@@ -529,13 +530,15 @@ static __latent_entropy void tasklet_action(struct 
softirq_action *a)
continue;
}
tasklet_unlock(t);
+   raise_softirq = false;
}
 
local_irq_disable();
t->next = NULL;
*__this_cpu_read(tasklet_vec.tail) = t;
__this_cpu_write(tasklet_vec.tail, &(t->next));
-   __raise_softirq_irqoff(TASKLET_SOFTIRQ);
+   if (raise_softirq)
+   __raise_softirq_irqoff(TASKLET_SOFTIRQ);
local_irq_enable();
}
 }
@@ -552,6 +555,7 @@ static __latent_entropy void tasklet_hi_action(struct 
softirq_action *a)
 
while (list) {
struct tasklet_struct *t = list;
+   bool raise_softirq = true;
 
list = list->next;
 
@@ -565,13 +569,15 @@ static __latent_entropy void tasklet_hi_action(struct 
softirq_action *a)
continue;
}
tasklet_unlock(t);
+   raise_softirq = false;
}
 
local_irq_disable();
t->next = NULL;
*__this_cpu_read(tasklet_hi_vec.tail) = t;
__this_cpu_write(tasklet_hi_vec.tail, &(t->next));
-   __raise_softirq_irqoff(HI_SOFTIRQ);
+   if (raise_softirq)
+   __raise_softirq_irqoff(HI_SOFTIRQ);
local_irq_enable();
}
 }
@@ -587,6 +593,16 @@ void tasklet_init(struct tasklet_struct *t,
 }
 EXPORT_SYMBOL(tasklet_init);
 
+void tasklet_enable(struct tasklet_struct *t)
+{
+   if (!atomic_dec_and_test(>count))
+   return;
+
+   if (test_bit(TASKLET_STATE_SCHED, >state))
+   raise_softirq(HI_SOFTIRQ | TASKLET_SOFTIRQ);
+}
+EXPORT_SYMBOL(tasklet_enable);
+
 void tasklet_kill(struct tasklet_struct *t)
 {
if (in_interrupt())
-- 
2.11.0

S2ram + btrfs with recent kernel => soft lockup warning and hard hang

[Bastien ROUCARIES]

Hi,

Since 3.8 s2ram on btrfs system lead to hang.

Could not save a trace will try to get a few picture but trace are similar to :
https://github.com/docker/docker/issues/15654
and
https://patchwork.kernel.org/patch/8352811/

It is 100% reproducible.

mount table
/dev/mapper/portable2015--bastien--vg-HOME on /var/cache/pbuilder type
btrfs 
(rw,relatime,lazytime,compress=zlib,space_cache,subvolid=934,subvol=/pbuilder)
/dev/mapper/portable2015--bastien--vg-HOME on /home type btrfs
(rw,nosuid,nodev,relatime,lazytime,compress=zlib,space_cache,subvolid=933,subvol=/home)

btrfs is over dm-crypt

Bastien

[PATCH v3] softirq: Prevent looping on disabled tasklets

[Chris Wilson]

Disabling a tasklet causes it not to run during tasklet_action, but is
put back onto the runnable tasklet list, and a new softirq raised. As
the softirq is raised from within __do_softirq() this causing
__do_softirq() to loop constantly until its timeslice expires and is
transferred to the ksoftirq thread. ksoftirq then permanently spins,
as on each action, the disabled tasklet keeps reraising the softirq.

Break this vicious cycle by moving the softirq from the action to the
final tasklet_enable().

This behaviour appears to be historic (since the first git import).
However, the looping until timeslice duration (to a max of 2ms) was
first introduced in commit c10d73671ad3 ("softirq: reduce latencies"),
with the restart limit restored in commit 34376a50fb1f ("Fix lockup
related to stop_machine being stuck in __do_softirq.")

v2: Export tasklet_enable() to work with modules.
v3: Restore the looping over a failed tasklet_trylock()

Reported-by: Tvrtko Ursulin 
Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
Cc: Thomas Gleixner 
Cc: Hannes Reinecke 
Cc: Jens Axboe 
Cc: Bjorn Helgaas 
Cc: Alexander Potapenko 
Cc: Chen Fan 
Cc: Ingo Molnar 
Cc: "Peter Zijlstra (Intel)" 
Cc: Sebastian Andrzej Siewior 
Cc: Johannes Thumshirn 
Cc: Emese Revfy 
Cc: Sagi Grimberg 
Cc: Eric Dumazet 
Cc: Tom Herbert 
Cc: Ben Hutchings 
---
 include/linux/interrupt.h |  7 +--
 kernel/softirq.c  | 20 ++--
 2 files changed, 19 insertions(+), 8 deletions(-)

diff --git a/include/linux/interrupt.h b/include/linux/interrupt.h
index 53144e78a369..a1fa88e7e509 100644
--- a/include/linux/interrupt.h
+++ b/include/linux/interrupt.h
@@ -611,12 +611,7 @@ static inline void tasklet_disable(struct tasklet_struct 
*t)
smp_mb();
 }
 
-static inline void tasklet_enable(struct tasklet_struct *t)
-{
-   smp_mb__before_atomic();
-   atomic_dec(>count);
-}
-
+extern void tasklet_enable(struct tasklet_struct *t);
 extern void tasklet_kill(struct tasklet_struct *t);
 extern void tasklet_kill_immediate(struct tasklet_struct *t, unsigned int cpu);
 extern void tasklet_init(struct tasklet_struct *t,
diff --git a/kernel/softirq.c b/kernel/softirq.c
index 080eb57789c4..47c8933d315e 100644
--- a/kernel/softirq.c
+++ b/kernel/softirq.c
@@ -516,6 +516,7 @@ static __latent_entropy void tasklet_action(struct 
softirq_action *a)
 
while (list) {
struct tasklet_struct *t = list;
+   bool raise_softirq = true;
 
list = list->next;
 
@@ -529,13 +530,15 @@ static __latent_entropy void tasklet_action(struct 
softirq_action *a)
continue;
}
tasklet_unlock(t);
+   raise_softirq = false;
}
 
local_irq_disable();
t->next = NULL;
*__this_cpu_read(tasklet_vec.tail) = t;
__this_cpu_write(tasklet_vec.tail, &(t->next));
-   __raise_softirq_irqoff(TASKLET_SOFTIRQ);
+   if (raise_softirq)
+   __raise_softirq_irqoff(TASKLET_SOFTIRQ);
local_irq_enable();
}
 }
@@ -552,6 +555,7 @@ static __latent_entropy void tasklet_hi_action(struct 
softirq_action *a)
 
while (list) {
struct tasklet_struct *t = list;
+   bool raise_softirq = true;
 
list = list->next;
 
@@ -565,13 +569,15 @@ static __latent_entropy void tasklet_hi_action(struct 
softirq_action *a)
continue;
}
tasklet_unlock(t);
+   raise_softirq = false;
}
 
local_irq_disable();
t->next = NULL;
*__this_cpu_read(tasklet_hi_vec.tail) = t;
__this_cpu_write(tasklet_hi_vec.tail, &(t->next));
-   __raise_softirq_irqoff(HI_SOFTIRQ);
+   if (raise_softirq)
+   __raise_softirq_irqoff(HI_SOFTIRQ);
local_irq_enable();
}
 }
@@ -587,6 +593,16 @@ void tasklet_init(struct tasklet_struct *t,
 }
 EXPORT_SYMBOL(tasklet_init);
 
+void tasklet_enable(struct tasklet_struct *t)
+{
+   if (!atomic_dec_and_test(>count))
+   return;
+
+   if (test_bit(TASKLET_STATE_SCHED, >state))
+   raise_softirq(HI_SOFTIRQ | TASKLET_SOFTIRQ);
+}
+EXPORT_SYMBOL(tasklet_enable);
+
 void tasklet_kill(struct tasklet_struct *t)
 {
if (in_interrupt())
-- 
2.11.0

Re: 4.10-rc1: thinkpad x60: who ate my cpu?

[Woody Suwalski]

Woody Suwalski wrote:

Pavel Machek wrote:

On Sat 2017-01-14 12:30:54, Pavel Machek wrote:

Hi!

On Thu 2017-01-12 20:19:31, Woody Suwalski wrote:

Pavel Machek wrote:

Hi!

I used to have two cpus, and Thinkpad X60 should have two cores, 
but I

only see one on 4.10-rc1. This machine went through many
suspend/resume cycles. When backups finish, I'll try -rc2.

Whoever did it, he seems to have returned the cpu in -rc3. All seems
to be good now.
Actually since you have mentioned - I have checked my x60 - same 
problem -
only one CPU. However I was running 4.8.13 with uptime 33 days, 
multiple

sleep/wake-ups.
Installed a current EOL 4.8.17 and rebooted - I see 2 CPUs. So the 
issue is

older then 4.10 kernel, and I suspect it is the CPU hotplug / wakeup
related...

Hmm. So I seen two cores in -rc3 after boot. But it is quite well
possible that -rc1 was ok just after boot, too, and problem happened
sometime later (probably during suspend/resume cycles). Let me go back
to -rc1 to check.

Indeed in -rc1 I see both CPUs after boot. So we have hard to
reproduce case where 4.8 to 4.10 kernels lose one of the cpu cores...



Managed to duplicate - but it took again a long time - I have an 
uptime of 29 days.
It must have happened in the last day, as I kept checking as often as 
I remembered.


The kernel is 4.8.17 EOL, installed almost a month ago.
Platform ThinkPad x60,  Intel(R) Core(TM) Duo CPU  T2400  @ 1.83GHz

In dmesg I see that it used to be when 2 CPUs were OK:
[690409.476107] PM: noirq suspend of devices complete after 79.914 msecs
[690409.476547] ACPI: Preparing to enter system sleep state S3
[690409.780081] ACPI : EC: EC stopped
[690409.780083] PM: Saving platform NVS memory
[690409.780284] Disabling non-boot CPUs ...
[690409.805284] smpboot: CPU 1 is now offline
[690409.816464] ACPI: Low-level resume complete
[690409.816464] ACPI : EC: EC started
[690409.816464] PM: Restoring platform NVS memory
[690409.816464] Enabling non-boot CPUs ...
[690409.840574] x86: Booting SMP configuration:
[690409.840576] smpboot: Booting Node 0 Processor 1 APIC 0x1
[690409.805271] Initializing CPU#1
[690409.805271] Disabled fast string operations
[690409.888252]  cache: parent cpu1 should not be sleeping
[690409.920185] CPU1 is up
[690409.922288] ACPI: Waking up from system sleep state S3

Then the CPU1 failed to start:

[691329.776108] PM: noirq suspend of devices complete after 79.941 msecs
[691329.776550] ACPI: Preparing to enter system sleep state S3
[691330.080081] ACPI : EC: EC stopped
[691330.080083] PM: Saving platform NVS memory
[691330.080284] Disabling non-boot CPUs ...
[691330.105303] smpboot: CPU 1 is now offline
[691330.116477] ACPI: Low-level resume complete
[691330.116477] ACPI : EC: EC started
[691330.116477] PM: Restoring platform NVS memory
[691330.116477] Enabling non-boot CPUs ...
[691330.140570] x86: Booting SMP configuration:
[691330.140572] smpboot: Booting Node 0 Processor 1 APIC 0x1
[691340.140015] smpboot: do_boot_cpu failed(-1) to wakeup CPU#1
[691340.164445] Error taking CPU1 up: -5
[691340.166309] ACPI: Waking up from system sleep state S3

And now it is:
[692517.868523] ACPI: Preparing to enter system sleep state S3
[692518.172074] ACPI : EC: EC stopped
[692518.172076] PM: Saving platform NVS memory
[692518.172269] Disabling non-boot CPUs ...
[692518.172269] ACPI: Low-level resume complete
[692518.172269] ACPI : EC: EC started
[692518.172269] PM: Restoring platform NVS memory
[692518.172269] ACPI: Waking up from system sleep state S3

Is there any test I could do on the CPU wakeup while in that state?

Woody


Is there a way to kick the offline-CPU into operation from /sys level?

Re: 4.10-rc1: thinkpad x60: who ate my cpu?

[Woody Suwalski]

Woody Suwalski wrote:

Pavel Machek wrote:

On Sat 2017-01-14 12:30:54, Pavel Machek wrote:

Hi!

On Thu 2017-01-12 20:19:31, Woody Suwalski wrote:

Pavel Machek wrote:

Hi!

I used to have two cpus, and Thinkpad X60 should have two cores, 
but I

only see one on 4.10-rc1. This machine went through many
suspend/resume cycles. When backups finish, I'll try -rc2.

Whoever did it, he seems to have returned the cpu in -rc3. All seems
to be good now.
Actually since you have mentioned - I have checked my x60 - same 
problem -
only one CPU. However I was running 4.8.13 with uptime 33 days, 
multiple

sleep/wake-ups.
Installed a current EOL 4.8.17 and rebooted - I see 2 CPUs. So the 
issue is

older then 4.10 kernel, and I suspect it is the CPU hotplug / wakeup
related...

Hmm. So I seen two cores in -rc3 after boot. But it is quite well
possible that -rc1 was ok just after boot, too, and problem happened
sometime later (probably during suspend/resume cycles). Let me go back
to -rc1 to check.

Indeed in -rc1 I see both CPUs after boot. So we have hard to
reproduce case where 4.8 to 4.10 kernels lose one of the cpu cores...



Managed to duplicate - but it took again a long time - I have an 
uptime of 29 days.
It must have happened in the last day, as I kept checking as often as 
I remembered.


The kernel is 4.8.17 EOL, installed almost a month ago.
Platform ThinkPad x60,  Intel(R) Core(TM) Duo CPU  T2400  @ 1.83GHz

In dmesg I see that it used to be when 2 CPUs were OK:
[690409.476107] PM: noirq suspend of devices complete after 79.914 msecs
[690409.476547] ACPI: Preparing to enter system sleep state S3
[690409.780081] ACPI : EC: EC stopped
[690409.780083] PM: Saving platform NVS memory
[690409.780284] Disabling non-boot CPUs ...
[690409.805284] smpboot: CPU 1 is now offline
[690409.816464] ACPI: Low-level resume complete
[690409.816464] ACPI : EC: EC started
[690409.816464] PM: Restoring platform NVS memory
[690409.816464] Enabling non-boot CPUs ...
[690409.840574] x86: Booting SMP configuration:
[690409.840576] smpboot: Booting Node 0 Processor 1 APIC 0x1
[690409.805271] Initializing CPU#1
[690409.805271] Disabled fast string operations
[690409.888252]  cache: parent cpu1 should not be sleeping
[690409.920185] CPU1 is up
[690409.922288] ACPI: Waking up from system sleep state S3

Then the CPU1 failed to start:

[691329.776108] PM: noirq suspend of devices complete after 79.941 msecs
[691329.776550] ACPI: Preparing to enter system sleep state S3
[691330.080081] ACPI : EC: EC stopped
[691330.080083] PM: Saving platform NVS memory
[691330.080284] Disabling non-boot CPUs ...
[691330.105303] smpboot: CPU 1 is now offline
[691330.116477] ACPI: Low-level resume complete
[691330.116477] ACPI : EC: EC started
[691330.116477] PM: Restoring platform NVS memory
[691330.116477] Enabling non-boot CPUs ...
[691330.140570] x86: Booting SMP configuration:
[691330.140572] smpboot: Booting Node 0 Processor 1 APIC 0x1
[691340.140015] smpboot: do_boot_cpu failed(-1) to wakeup CPU#1
[691340.164445] Error taking CPU1 up: -5
[691340.166309] ACPI: Waking up from system sleep state S3

And now it is:
[692517.868523] ACPI: Preparing to enter system sleep state S3
[692518.172074] ACPI : EC: EC stopped
[692518.172076] PM: Saving platform NVS memory
[692518.172269] Disabling non-boot CPUs ...
[692518.172269] ACPI: Low-level resume complete
[692518.172269] ACPI : EC: EC started
[692518.172269] PM: Restoring platform NVS memory
[692518.172269] ACPI: Waking up from system sleep state S3

Is there any test I could do on the CPU wakeup while in that state?

Woody


Is there a way to kick the offline-CPU into operation from /sys level?

Re: [PATCH v4 2/7] drm/tinydrm: Add helper functions

[Noralf Trønnes]

Den 12.02.2017 12.50, skrev Andy Shevchenko:

On Sat, Feb 11, 2017 at 8:48 PM, Noralf Trønnes  wrote:

Add common functionality needed by many tinydrm drivers.
+int tinydrm_enable_backlight(struct backlight_device *backlight)
+{
+   unsigned int old_state;
+   int ret;
+
+   if (!backlight)
+   return 0;
+
+   old_state = backlight->props.state;
+   backlight->props.state &= ~BL_CORE_FBBLANK;
+   DRM_DEBUG_KMS("Backlight state: 0x%x -> 0x%x\n", old_state,
+ backlight->props.state);

"%#x" ?
(And elsewhere)


+#if IS_ENABLED(CONFIG_SPI)
+size_t tinydrm_spi_max_transfer_size(struct spi_device *spi, size_t max_len)
+{
+   size_t ret;
+
+   ret = min(spi_max_transfer_size(spi), spi->master->max_dma_len);

I don't get why DMA constrain somehow affects this framework?


The reason is that spi-bcm2835 reverts to PIO on larger buffers.
Looking at __spi_map_msg() and spi_map_buf() it becomes clear that the
core breaks up the buffer into manageable parts. So this must be a bug
in spi-bcm2835 (and spi-pxa2xx) since no other drivers have a upper
limit in the .can_dma() callback.
So you're rightly confused, with drivers fixed, this limit can be lifted.


What if max_dma_len is zero (imagine SPI master that works only by PIO
by some reason)?


It can't be zero:

int spi_register_master(struct spi_master *master)
{
...
if (!master->max_dma_len)
master->max_dma_len = INT_MAX;


+   if (max_len)
+   ret = min(ret, max_len);
+   if (spi_max)
+   ret = min_t(size_t, ret, spi_max);
+   ret &= ~0x3;

Why alignment is that? Why do we need it? Isn't a busyness of SPI
framework to cope with it?


This minimum capping doesn't look good. I should probably put >16
instead, that would cover the minimum for the 9-bit emulation code.

The reason I let the user change the transfer size, is that some usb
audio card on Raspberry Pi stuttered with 4k fbtft transfers.


+   if (ret < 4)

It's effectively check for 0.


+   ret = 4;
+
+   return ret;
+}
+EXPORT_SYMBOL(tinydrm_spi_max_transfer_size);
+static void
+tinydrm_dbg_spi_print(struct spi_device *spi, struct spi_transfer *tr,
+ const void *buf, int idx, bool tx)
+{
+   u32 speed_hz = tr->speed_hz ? tr->speed_hz : spi->max_speed_hz;
+   char linebuf[3 * 32];
+
+   hex_dump_to_buffer(buf, tr->len, 16,
+  DIV_ROUND_UP(tr->bits_per_word, 8),
+  linebuf, sizeof(linebuf), false);
+
+   printk(KERN_DEBUG
+  "tr(%i): speed=%u%s, bpw=%i, len=%u, %s_buf=[%s%s]\n", idx,
+  speed_hz > 100 ? speed_hz / 100 : speed_hz / 1000,
+  speed_hz > 100 ? "MHz" : "kHz", tr->bits_per_word, tr->len,
+  tx ? "tx" : "rx", linebuf, tr->len > 16 ? " ..." : "");

I hope at some point we will have some extension to print speeds,
sizes and so on based on algo in string_get_size().


+}
+int tinydrm_spi_transfer(struct spi_device *spi, u32 speed_hz,
+struct spi_transfer *header, u8 bpw, const void *buf,
+size_t len)
+{
+   struct spi_transfer tr = {
+   .bits_per_word = bpw,
+   .speed_hz = speed_hz,
+   };
+   struct spi_message m;
+   u16 *swap_buf = NULL;
+   size_t max_chunk;
+   size_t chunk;
+   int ret = 0;
+
+   if (WARN_ON_ONCE(bpw != 8 && bpw != 16))
+   return -EINVAL;
+
+   max_chunk = tinydrm_spi_max_transfer_size(spi, 0);
+
+   if (drm_debug & DRM_UT_DRIVER)
+   pr_debug("[drm:%s] bpw=%u, max_chunk=%zu, transfers:\n",
+__func__, bpw, max_chunk);

For all of your dev_dbg() / pr_debug() __func__ argument might be
redundant. Dynamic Debug may include this by request from user.


+/**
+ * tinydrm_machine_little_endian - Machine is little endian
+ *
+ * Returns:
+ * true if *defined(__LITTLE_ENDIAN)*, false otherwise
+ */
+static inline bool tinydrm_machine_little_endian(void)
+{
+#if defined(__LITTLE_ENDIAN)
+   return true;
+#else
+   return false;
+#endif
+}

Hmm... What is the typical code of a caller for this?


If the bus can't do 16-bit natively, it will have to swap the bytes on
little endian machines before transfer as 8-bit (Raspberry Pi can't do
16-bit SPI with it's DMA capable controller).
So this function is to avoid #ifdef's elsewhere.

Re: [PATCH v4 2/7] drm/tinydrm: Add helper functions

[Noralf Trønnes]

Den 12.02.2017 12.50, skrev Andy Shevchenko:

On Sat, Feb 11, 2017 at 8:48 PM, Noralf Trønnes  wrote:

Add common functionality needed by many tinydrm drivers.
+int tinydrm_enable_backlight(struct backlight_device *backlight)
+{
+   unsigned int old_state;
+   int ret;
+
+   if (!backlight)
+   return 0;
+
+   old_state = backlight->props.state;
+   backlight->props.state &= ~BL_CORE_FBBLANK;
+   DRM_DEBUG_KMS("Backlight state: 0x%x -> 0x%x\n", old_state,
+ backlight->props.state);

"%#x" ?
(And elsewhere)


+#if IS_ENABLED(CONFIG_SPI)
+size_t tinydrm_spi_max_transfer_size(struct spi_device *spi, size_t max_len)
+{
+   size_t ret;
+
+   ret = min(spi_max_transfer_size(spi), spi->master->max_dma_len);

I don't get why DMA constrain somehow affects this framework?


The reason is that spi-bcm2835 reverts to PIO on larger buffers.
Looking at __spi_map_msg() and spi_map_buf() it becomes clear that the
core breaks up the buffer into manageable parts. So this must be a bug
in spi-bcm2835 (and spi-pxa2xx) since no other drivers have a upper
limit in the .can_dma() callback.
So you're rightly confused, with drivers fixed, this limit can be lifted.


What if max_dma_len is zero (imagine SPI master that works only by PIO
by some reason)?


It can't be zero:

int spi_register_master(struct spi_master *master)
{
...
if (!master->max_dma_len)
master->max_dma_len = INT_MAX;


+   if (max_len)
+   ret = min(ret, max_len);
+   if (spi_max)
+   ret = min_t(size_t, ret, spi_max);
+   ret &= ~0x3;

Why alignment is that? Why do we need it? Isn't a busyness of SPI
framework to cope with it?


This minimum capping doesn't look good. I should probably put >16
instead, that would cover the minimum for the 9-bit emulation code.

The reason I let the user change the transfer size, is that some usb
audio card on Raspberry Pi stuttered with 4k fbtft transfers.


+   if (ret < 4)

It's effectively check for 0.


+   ret = 4;
+
+   return ret;
+}
+EXPORT_SYMBOL(tinydrm_spi_max_transfer_size);
+static void
+tinydrm_dbg_spi_print(struct spi_device *spi, struct spi_transfer *tr,
+ const void *buf, int idx, bool tx)
+{
+   u32 speed_hz = tr->speed_hz ? tr->speed_hz : spi->max_speed_hz;
+   char linebuf[3 * 32];
+
+   hex_dump_to_buffer(buf, tr->len, 16,
+  DIV_ROUND_UP(tr->bits_per_word, 8),
+  linebuf, sizeof(linebuf), false);
+
+   printk(KERN_DEBUG
+  "tr(%i): speed=%u%s, bpw=%i, len=%u, %s_buf=[%s%s]\n", idx,
+  speed_hz > 100 ? speed_hz / 100 : speed_hz / 1000,
+  speed_hz > 100 ? "MHz" : "kHz", tr->bits_per_word, tr->len,
+  tx ? "tx" : "rx", linebuf, tr->len > 16 ? " ..." : "");

I hope at some point we will have some extension to print speeds,
sizes and so on based on algo in string_get_size().


+}
+int tinydrm_spi_transfer(struct spi_device *spi, u32 speed_hz,
+struct spi_transfer *header, u8 bpw, const void *buf,
+size_t len)
+{
+   struct spi_transfer tr = {
+   .bits_per_word = bpw,
+   .speed_hz = speed_hz,
+   };
+   struct spi_message m;
+   u16 *swap_buf = NULL;
+   size_t max_chunk;
+   size_t chunk;
+   int ret = 0;
+
+   if (WARN_ON_ONCE(bpw != 8 && bpw != 16))
+   return -EINVAL;
+
+   max_chunk = tinydrm_spi_max_transfer_size(spi, 0);
+
+   if (drm_debug & DRM_UT_DRIVER)
+   pr_debug("[drm:%s] bpw=%u, max_chunk=%zu, transfers:\n",
+__func__, bpw, max_chunk);

For all of your dev_dbg() / pr_debug() __func__ argument might be
redundant. Dynamic Debug may include this by request from user.


+/**
+ * tinydrm_machine_little_endian - Machine is little endian
+ *
+ * Returns:
+ * true if *defined(__LITTLE_ENDIAN)*, false otherwise
+ */
+static inline bool tinydrm_machine_little_endian(void)
+{
+#if defined(__LITTLE_ENDIAN)
+   return true;
+#else
+   return false;
+#endif
+}

Hmm... What is the typical code of a caller for this?


If the bus can't do 16-bit natively, it will have to swap the bytes on
little endian machines before transfer as 8-bit (Raspberry Pi can't do
16-bit SPI with it's DMA capable controller).
So this function is to avoid #ifdef's elsewhere.

[PATCH] genirq: devres: use dev_name(dev) as default for devname

[Heiner Kallweit]

Allow the devname parameter to be NULL and use dev_name(dev) in this case.
This should be an appropriate default for most use cases.

Signed-off-by: Heiner Kallweit 
---
 kernel/irq/devres.c | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/kernel/irq/devres.c b/kernel/irq/devres.c
index 74d90a75..adb0baa6 100644
--- a/kernel/irq/devres.c
+++ b/kernel/irq/devres.c
@@ -33,7 +33,7 @@ static int devm_irq_match(struct device *dev, void *res, void 
*data)
  * @thread_fn: function to be called in a threaded interrupt context. NULL
  * for devices which handle everything in @handler
  * @irqflags: Interrupt type flags
- * @devname: An ascii name for the claiming device
+ * @devname: An ascii name for the claiming device, dev_name(dev) if NULL
  * @dev_id: A cookie passed back to the handler function
  *
  * Except for the extra @dev argument, this function takes the
@@ -57,6 +57,9 @@ int devm_request_threaded_irq(struct device *dev, unsigned 
int irq,
if (!dr)
return -ENOMEM;
 
+   if (!devname)
+   devname = dev_name(dev);
+
rc = request_threaded_irq(irq, handler, thread_fn, irqflags, devname,
  dev_id);
if (rc) {
@@ -80,7 +83,7 @@ EXPORT_SYMBOL(devm_request_threaded_irq);
  * @thread_fn: function to be called in a threaded interrupt context. NULL
  * for devices which handle everything in @handler
  * @irqflags: Interrupt type flags
- * @devname: An ascii name for the claiming device
+ * @devname: An ascii name for the claiming device, dev_name(dev) if NULL
  * @dev_id: A cookie passed back to the handler function
  *
  * Except for the extra @dev argument, this function takes the
@@ -103,6 +106,9 @@ int devm_request_any_context_irq(struct device *dev, 
unsigned int irq,
if (!dr)
return -ENOMEM;
 
+   if (!devname)
+   devname = dev_name(dev);
+
rc = request_any_context_irq(irq, handler, irqflags, devname, dev_id);
if (rc < 0) {
devres_free(dr);
-- 
2.11.1

[PATCH] genirq: devres: use dev_name(dev) as default for devname

[Heiner Kallweit]

Allow the devname parameter to be NULL and use dev_name(dev) in this case.
This should be an appropriate default for most use cases.

Signed-off-by: Heiner Kallweit 
---
 kernel/irq/devres.c | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/kernel/irq/devres.c b/kernel/irq/devres.c
index 74d90a75..adb0baa6 100644
--- a/kernel/irq/devres.c
+++ b/kernel/irq/devres.c
@@ -33,7 +33,7 @@ static int devm_irq_match(struct device *dev, void *res, void 
*data)
  * @thread_fn: function to be called in a threaded interrupt context. NULL
  * for devices which handle everything in @handler
  * @irqflags: Interrupt type flags
- * @devname: An ascii name for the claiming device
+ * @devname: An ascii name for the claiming device, dev_name(dev) if NULL
  * @dev_id: A cookie passed back to the handler function
  *
  * Except for the extra @dev argument, this function takes the
@@ -57,6 +57,9 @@ int devm_request_threaded_irq(struct device *dev, unsigned 
int irq,
if (!dr)
return -ENOMEM;
 
+   if (!devname)
+   devname = dev_name(dev);
+
rc = request_threaded_irq(irq, handler, thread_fn, irqflags, devname,
  dev_id);
if (rc) {
@@ -80,7 +83,7 @@ EXPORT_SYMBOL(devm_request_threaded_irq);
  * @thread_fn: function to be called in a threaded interrupt context. NULL
  * for devices which handle everything in @handler
  * @irqflags: Interrupt type flags
- * @devname: An ascii name for the claiming device
+ * @devname: An ascii name for the claiming device, dev_name(dev) if NULL
  * @dev_id: A cookie passed back to the handler function
  *
  * Except for the extra @dev argument, this function takes the
@@ -103,6 +106,9 @@ int devm_request_any_context_irq(struct device *dev, 
unsigned int irq,
if (!dr)
return -ENOMEM;
 
+   if (!devname)
+   devname = dev_name(dev);
+
rc = request_any_context_irq(irq, handler, irqflags, devname, dev_id);
if (rc < 0) {
devres_free(dr);
-- 
2.11.1

[PATCH 2/3] [media] si2168: add support for Si2168-D60

[Stefan Brüns]

Add handling for new revision, requiring new firmware.

Signed-off-by: Stefan Brüns 
---
 drivers/media/dvb-frontends/si2168.c  | 4 
 drivers/media/dvb-frontends/si2168_priv.h | 2 ++
 2 files changed, 6 insertions(+)

diff --git a/drivers/media/dvb-frontends/si2168.c 
b/drivers/media/dvb-frontends/si2168.c
index 20b4a659e2e4..28f3bbe0af25 100644
--- a/drivers/media/dvb-frontends/si2168.c
+++ b/drivers/media/dvb-frontends/si2168.c
@@ -674,6 +674,9 @@ static int si2168_probe(struct i2c_client *client,
case SI2168_CHIP_ID_B40:
dev->firmware_name = SI2168_B40_FIRMWARE;
break;
+   case SI2168_CHIP_ID_D60:
+   dev->firmware_name = SI2168_D60_FIRMWARE;
+   break;
default:
dev_dbg(>dev, "unknown chip version Si21%d-%c%c%c\n",
cmd.args[2], cmd.args[1], cmd.args[3], cmd.args[4]);
@@ -761,3 +764,4 @@ MODULE_LICENSE("GPL");
 MODULE_FIRMWARE(SI2168_A20_FIRMWARE);
 MODULE_FIRMWARE(SI2168_A30_FIRMWARE);
 MODULE_FIRMWARE(SI2168_B40_FIRMWARE);
+MODULE_FIRMWARE(SI2168_D60_FIRMWARE);
diff --git a/drivers/media/dvb-frontends/si2168_priv.h 
b/drivers/media/dvb-frontends/si2168_priv.h
index 7843ccb448a0..4baa95b7d648 100644
--- a/drivers/media/dvb-frontends/si2168_priv.h
+++ b/drivers/media/dvb-frontends/si2168_priv.h
@@ -25,6 +25,7 @@
 #define SI2168_A20_FIRMWARE "dvb-demod-si2168-a20-01.fw"
 #define SI2168_A30_FIRMWARE "dvb-demod-si2168-a30-01.fw"
 #define SI2168_B40_FIRMWARE "dvb-demod-si2168-b40-01.fw"
+#define SI2168_D60_FIRMWARE "dvb-demod-si2168-d60-01.fw"
 #define SI2168_B40_FIRMWARE_FALLBACK "dvb-demod-si2168-02.fw"
 
 /* state struct */
@@ -37,6 +38,7 @@ struct si2168_dev {
#define SI2168_CHIP_ID_A20 ('A' << 24 | 68 << 16 | '2' << 8 | '0' << 0)
#define SI2168_CHIP_ID_A30 ('A' << 24 | 68 << 16 | '3' << 8 | '0' << 0)
#define SI2168_CHIP_ID_B40 ('B' << 24 | 68 << 16 | '4' << 8 | '0' << 0)
+   #define SI2168_CHIP_ID_D60 ('D' << 24 | 68 << 16 | '6' << 8 | '0' << 0)
unsigned int chip_id;
unsigned int version;
const char *firmware_name;
-- 
2.11.0

[PATCH 2/3] [media] si2168: add support for Si2168-D60

[Stefan Brüns]

Add handling for new revision, requiring new firmware.

Signed-off-by: Stefan Brüns 
---
 drivers/media/dvb-frontends/si2168.c  | 4 
 drivers/media/dvb-frontends/si2168_priv.h | 2 ++
 2 files changed, 6 insertions(+)

diff --git a/drivers/media/dvb-frontends/si2168.c 
b/drivers/media/dvb-frontends/si2168.c
index 20b4a659e2e4..28f3bbe0af25 100644
--- a/drivers/media/dvb-frontends/si2168.c
+++ b/drivers/media/dvb-frontends/si2168.c
@@ -674,6 +674,9 @@ static int si2168_probe(struct i2c_client *client,
case SI2168_CHIP_ID_B40:
dev->firmware_name = SI2168_B40_FIRMWARE;
break;
+   case SI2168_CHIP_ID_D60:
+   dev->firmware_name = SI2168_D60_FIRMWARE;
+   break;
default:
dev_dbg(>dev, "unknown chip version Si21%d-%c%c%c\n",
cmd.args[2], cmd.args[1], cmd.args[3], cmd.args[4]);
@@ -761,3 +764,4 @@ MODULE_LICENSE("GPL");
 MODULE_FIRMWARE(SI2168_A20_FIRMWARE);
 MODULE_FIRMWARE(SI2168_A30_FIRMWARE);
 MODULE_FIRMWARE(SI2168_B40_FIRMWARE);
+MODULE_FIRMWARE(SI2168_D60_FIRMWARE);
diff --git a/drivers/media/dvb-frontends/si2168_priv.h 
b/drivers/media/dvb-frontends/si2168_priv.h
index 7843ccb448a0..4baa95b7d648 100644
--- a/drivers/media/dvb-frontends/si2168_priv.h
+++ b/drivers/media/dvb-frontends/si2168_priv.h
@@ -25,6 +25,7 @@
 #define SI2168_A20_FIRMWARE "dvb-demod-si2168-a20-01.fw"
 #define SI2168_A30_FIRMWARE "dvb-demod-si2168-a30-01.fw"
 #define SI2168_B40_FIRMWARE "dvb-demod-si2168-b40-01.fw"
+#define SI2168_D60_FIRMWARE "dvb-demod-si2168-d60-01.fw"
 #define SI2168_B40_FIRMWARE_FALLBACK "dvb-demod-si2168-02.fw"
 
 /* state struct */
@@ -37,6 +38,7 @@ struct si2168_dev {
#define SI2168_CHIP_ID_A20 ('A' << 24 | 68 << 16 | '2' << 8 | '0' << 0)
#define SI2168_CHIP_ID_A30 ('A' << 24 | 68 << 16 | '3' << 8 | '0' << 0)
#define SI2168_CHIP_ID_B40 ('B' << 24 | 68 << 16 | '4' << 8 | '0' << 0)
+   #define SI2168_CHIP_ID_D60 ('D' << 24 | 68 << 16 | '6' << 8 | '0' << 0)
unsigned int chip_id;
unsigned int version;
const char *firmware_name;
-- 
2.11.0

[PATCH 3/3] [media] cxusb: MyGica T230C support

[Stefan Brüns]

Mygica T230 DVB-T/T2/C USB stick support. It uses the same FX2/Si2168
bridge/demodulator combo as the T230, but uses the Si2141 tuner.
Factor out the common code and pass the tuner type and if port as
parameter, to avoid duplicating the initialization code.

Signed-off-by: Stefan Brüns 
---
 drivers/media/dvb-core/dvb-usb-ids.h |  1 +
 drivers/media/usb/dvb-usb/cxusb.c| 80 ++--
 2 files changed, 77 insertions(+), 4 deletions(-)

diff --git a/drivers/media/dvb-core/dvb-usb-ids.h 
b/drivers/media/dvb-core/dvb-usb-ids.h
index a7a4674ccc40..ce4a3d574dd7 100644
--- a/drivers/media/dvb-core/dvb-usb-ids.h
+++ b/drivers/media/dvb-core/dvb-usb-ids.h
@@ -380,6 +380,7 @@
 #define USB_PID_SONY_PLAYTV0x0003
 #define USB_PID_MYGICA_D6890xd811
 #define USB_PID_MYGICA_T2300xc688
+#define USB_PID_MYGICA_T230C   0xc689
 #define USB_PID_ELGATO_EYETV_DIVERSITY 0x0011
 #define USB_PID_ELGATO_EYETV_DTT   0x0021
 #define USB_PID_ELGATO_EYETV_DTT_2 0x003f
diff --git a/drivers/media/usb/dvb-usb/cxusb.c 
b/drivers/media/usb/dvb-usb/cxusb.c
index 9fd43a37154c..967f4f74309c 100644
--- a/drivers/media/usb/dvb-usb/cxusb.c
+++ b/drivers/media/usb/dvb-usb/cxusb.c
@@ -1305,7 +1305,9 @@ static int cxusb_mygica_d689_frontend_attach(struct 
dvb_usb_adapter *adap)
return 0;
 }
 
-static int cxusb_mygica_t230_frontend_attach(struct dvb_usb_adapter *adap)
+static int cxusb_mygica_t230_common_frontend_attach(struct dvb_usb_adapter 
*adap,
+   const char *tuner_name,
+   u8 tuner_if_port)
 {
struct dvb_usb_device *d = adap->dev;
struct cxusb_state *st = d->priv;
@@ -1352,12 +1354,12 @@ static int cxusb_mygica_t230_frontend_attach(struct 
dvb_usb_adapter *adap)
/* attach tuner */
memset(_config, 0, sizeof(si2157_config));
si2157_config.fe = adap->fe_adap[0].fe;
-   si2157_config.if_port = 1;
+   si2157_config.if_port = tuner_if_port;
memset(, 0, sizeof(struct i2c_board_info));
-   strlcpy(info.type, "si2157", I2C_NAME_SIZE);
+   strlcpy(info.type, tuner_name, I2C_NAME_SIZE);
info.addr = 0x60;
info.platform_data = _config;
-   request_module(info.type);
+   request_module("si2157");
client_tuner = i2c_new_device(adapter, );
if (client_tuner == NULL || client_tuner->dev.driver == NULL) {
module_put(client_demod->dev.driver->owner);
@@ -1376,6 +1378,16 @@ static int cxusb_mygica_t230_frontend_attach(struct 
dvb_usb_adapter *adap)
return 0;
 }
 
+static int cxusb_mygica_t230_frontend_attach(struct dvb_usb_adapter *adap)
+{
+   return cxusb_mygica_t230_common_frontend_attach(adap, "si2157", 1);
+}
+
+static int cxusb_mygica_t230c_frontend_attach(struct dvb_usb_adapter *adap)
+{
+   return cxusb_mygica_t230_common_frontend_attach(adap, "si2141", 0);
+}
+
 /*
  * DViCO has shipped two devices with the same USB ID, but only one of them
  * needs a firmware download.  Check the device class details to see if they
@@ -1458,6 +1470,7 @@ static struct dvb_usb_device_properties 
cxusb_aver_a868r_properties;
 static struct dvb_usb_device_properties cxusb_d680_dmb_properties;
 static struct dvb_usb_device_properties cxusb_mygica_d689_properties;
 static struct dvb_usb_device_properties cxusb_mygica_t230_properties;
+static struct dvb_usb_device_properties cxusb_mygica_t230c_properties;
 
 static int cxusb_probe(struct usb_interface *intf,
   const struct usb_device_id *id)
@@ -1490,6 +1503,8 @@ static int cxusb_probe(struct usb_interface *intf,
 THIS_MODULE, NULL, adapter_nr) ||
0 == dvb_usb_device_init(intf, _mygica_t230_properties,
 THIS_MODULE, NULL, adapter_nr) ||
+   0 == dvb_usb_device_init(intf, _mygica_t230c_properties,
+THIS_MODULE, NULL, adapter_nr) ||
0)
return 0;
 
@@ -1541,6 +1556,7 @@ enum cxusb_table_index {
CONEXANT_D680_DMB,
MYGICA_D689,
MYGICA_T230,
+   MYGICA_T230C,
NR__cxusb_table_index
 };
 
@@ -1608,6 +1624,9 @@ static struct usb_device_id 
cxusb_table[NR__cxusb_table_index + 1] = {
[MYGICA_T230] = {
USB_DEVICE(USB_VID_CONEXANT, USB_PID_MYGICA_T230)
},
+   [MYGICA_T230C] = {
+   USB_DEVICE(USB_VID_CONEXANT, USB_PID_MYGICA_T230C)
+   },
{}  /* Terminating entry */
 };
 MODULE_DEVICE_TABLE (usb, cxusb_table);
@@ -2307,6 +2326,59 @@ static struct dvb_usb_device_properties 
cxusb_mygica_t230_properties = {
}
 };
 
+static struct dvb_usb_device_properties cxusb_mygica_t230c_properties = {
+   

[PATCH 0/3] Add support for MyGica T230C DVB-T2 stick

[Stefan Brüns]

The required command sequence for the new tuner (Si2141) was traced from the
current Windows driver and verified with a small python script/libusb.
The changes to the Si2168 and cxusb driver are mostly addition of the
required IDs and some glue code.

Stefan Brüns (3):
  [media] si2157: Add support for Si2141-A10
  [media] si2168: add support for Si2168-D60
  [media] cxusb: MyGica T230C support

 drivers/media/dvb-core/dvb-usb-ids.h  |  1 +
 drivers/media/dvb-frontends/si2168.c  |  4 ++
 drivers/media/dvb-frontends/si2168_priv.h |  2 +
 drivers/media/tuners/si2157.c | 23 -
 drivers/media/tuners/si2157_priv.h|  2 +
 drivers/media/usb/dvb-usb/cxusb.c | 80 +--
 6 files changed, 106 insertions(+), 6 deletions(-)

-- 
2.11.0

[PATCH 3/3] [media] cxusb: MyGica T230C support

[Stefan Brüns]

Mygica T230 DVB-T/T2/C USB stick support. It uses the same FX2/Si2168
bridge/demodulator combo as the T230, but uses the Si2141 tuner.
Factor out the common code and pass the tuner type and if port as
parameter, to avoid duplicating the initialization code.

Signed-off-by: Stefan Brüns 
---
 drivers/media/dvb-core/dvb-usb-ids.h |  1 +
 drivers/media/usb/dvb-usb/cxusb.c| 80 ++--
 2 files changed, 77 insertions(+), 4 deletions(-)

diff --git a/drivers/media/dvb-core/dvb-usb-ids.h 
b/drivers/media/dvb-core/dvb-usb-ids.h
index a7a4674ccc40..ce4a3d574dd7 100644
--- a/drivers/media/dvb-core/dvb-usb-ids.h
+++ b/drivers/media/dvb-core/dvb-usb-ids.h
@@ -380,6 +380,7 @@
 #define USB_PID_SONY_PLAYTV0x0003
 #define USB_PID_MYGICA_D6890xd811
 #define USB_PID_MYGICA_T2300xc688
+#define USB_PID_MYGICA_T230C   0xc689
 #define USB_PID_ELGATO_EYETV_DIVERSITY 0x0011
 #define USB_PID_ELGATO_EYETV_DTT   0x0021
 #define USB_PID_ELGATO_EYETV_DTT_2 0x003f
diff --git a/drivers/media/usb/dvb-usb/cxusb.c 
b/drivers/media/usb/dvb-usb/cxusb.c
index 9fd43a37154c..967f4f74309c 100644
--- a/drivers/media/usb/dvb-usb/cxusb.c
+++ b/drivers/media/usb/dvb-usb/cxusb.c
@@ -1305,7 +1305,9 @@ static int cxusb_mygica_d689_frontend_attach(struct 
dvb_usb_adapter *adap)
return 0;
 }
 
-static int cxusb_mygica_t230_frontend_attach(struct dvb_usb_adapter *adap)
+static int cxusb_mygica_t230_common_frontend_attach(struct dvb_usb_adapter 
*adap,
+   const char *tuner_name,
+   u8 tuner_if_port)
 {
struct dvb_usb_device *d = adap->dev;
struct cxusb_state *st = d->priv;
@@ -1352,12 +1354,12 @@ static int cxusb_mygica_t230_frontend_attach(struct 
dvb_usb_adapter *adap)
/* attach tuner */
memset(_config, 0, sizeof(si2157_config));
si2157_config.fe = adap->fe_adap[0].fe;
-   si2157_config.if_port = 1;
+   si2157_config.if_port = tuner_if_port;
memset(, 0, sizeof(struct i2c_board_info));
-   strlcpy(info.type, "si2157", I2C_NAME_SIZE);
+   strlcpy(info.type, tuner_name, I2C_NAME_SIZE);
info.addr = 0x60;
info.platform_data = _config;
-   request_module(info.type);
+   request_module("si2157");
client_tuner = i2c_new_device(adapter, );
if (client_tuner == NULL || client_tuner->dev.driver == NULL) {
module_put(client_demod->dev.driver->owner);
@@ -1376,6 +1378,16 @@ static int cxusb_mygica_t230_frontend_attach(struct 
dvb_usb_adapter *adap)
return 0;
 }
 
+static int cxusb_mygica_t230_frontend_attach(struct dvb_usb_adapter *adap)
+{
+   return cxusb_mygica_t230_common_frontend_attach(adap, "si2157", 1);
+}
+
+static int cxusb_mygica_t230c_frontend_attach(struct dvb_usb_adapter *adap)
+{
+   return cxusb_mygica_t230_common_frontend_attach(adap, "si2141", 0);
+}
+
 /*
  * DViCO has shipped two devices with the same USB ID, but only one of them
  * needs a firmware download.  Check the device class details to see if they
@@ -1458,6 +1470,7 @@ static struct dvb_usb_device_properties 
cxusb_aver_a868r_properties;
 static struct dvb_usb_device_properties cxusb_d680_dmb_properties;
 static struct dvb_usb_device_properties cxusb_mygica_d689_properties;
 static struct dvb_usb_device_properties cxusb_mygica_t230_properties;
+static struct dvb_usb_device_properties cxusb_mygica_t230c_properties;
 
 static int cxusb_probe(struct usb_interface *intf,
   const struct usb_device_id *id)
@@ -1490,6 +1503,8 @@ static int cxusb_probe(struct usb_interface *intf,
 THIS_MODULE, NULL, adapter_nr) ||
0 == dvb_usb_device_init(intf, _mygica_t230_properties,
 THIS_MODULE, NULL, adapter_nr) ||
+   0 == dvb_usb_device_init(intf, _mygica_t230c_properties,
+THIS_MODULE, NULL, adapter_nr) ||
0)
return 0;
 
@@ -1541,6 +1556,7 @@ enum cxusb_table_index {
CONEXANT_D680_DMB,
MYGICA_D689,
MYGICA_T230,
+   MYGICA_T230C,
NR__cxusb_table_index
 };
 
@@ -1608,6 +1624,9 @@ static struct usb_device_id 
cxusb_table[NR__cxusb_table_index + 1] = {
[MYGICA_T230] = {
USB_DEVICE(USB_VID_CONEXANT, USB_PID_MYGICA_T230)
},
+   [MYGICA_T230C] = {
+   USB_DEVICE(USB_VID_CONEXANT, USB_PID_MYGICA_T230C)
+   },
{}  /* Terminating entry */
 };
 MODULE_DEVICE_TABLE (usb, cxusb_table);
@@ -2307,6 +2326,59 @@ static struct dvb_usb_device_properties 
cxusb_mygica_t230_properties = {
}
 };
 
+static struct dvb_usb_device_properties cxusb_mygica_t230c_properties = {
+   .caps = 

[PATCH 0/3] Add support for MyGica T230C DVB-T2 stick

[Stefan Brüns]

The required command sequence for the new tuner (Si2141) was traced from the
current Windows driver and verified with a small python script/libusb.
The changes to the Si2168 and cxusb driver are mostly addition of the
required IDs and some glue code.

Stefan Brüns (3):
  [media] si2157: Add support for Si2141-A10
  [media] si2168: add support for Si2168-D60
  [media] cxusb: MyGica T230C support

 drivers/media/dvb-core/dvb-usb-ids.h  |  1 +
 drivers/media/dvb-frontends/si2168.c  |  4 ++
 drivers/media/dvb-frontends/si2168_priv.h |  2 +
 drivers/media/tuners/si2157.c | 23 -
 drivers/media/tuners/si2157_priv.h|  2 +
 drivers/media/usb/dvb-usb/cxusb.c | 80 +--
 6 files changed, 106 insertions(+), 6 deletions(-)

-- 
2.11.0

[PATCH 1/3] [media] si2157: Add support for Si2141-A10

[Stefan Brüns]

The Si2141 needs two distinct commands for powerup/reset, otherwise it
will not respond to chip revision requests. It also needs a firmware
to run properly.

Signed-off-by: Stefan Brüns 
---
 drivers/media/tuners/si2157.c  | 23 +--
 drivers/media/tuners/si2157_priv.h |  2 ++
 2 files changed, 23 insertions(+), 2 deletions(-)

diff --git a/drivers/media/tuners/si2157.c b/drivers/media/tuners/si2157.c
index 57b250847cd3..e35b1faf0ddc 100644
--- a/drivers/media/tuners/si2157.c
+++ b/drivers/media/tuners/si2157.c
@@ -106,6 +106,9 @@ static int si2157_init(struct dvb_frontend *fe)
if (dev->chiptype == SI2157_CHIPTYPE_SI2146) {
memcpy(cmd.args, "\xc0\x05\x01\x00\x00\x0b\x00\x00\x01", 9);
cmd.wlen = 9;
+   } else if (dev->chiptype == SI2157_CHIPTYPE_SI2141) {
+   memcpy(cmd.args, "\xc0\x00\x0d\x0e\x00\x01\x01\x01\x01\x03", 
10);
+   cmd.wlen = 10;
} else {
memcpy(cmd.args, 
"\xc0\x00\x0c\x00\x00\x01\x01\x01\x01\x01\x01\x02\x00\x00\x01", 15);
cmd.wlen = 15;
@@ -115,6 +118,15 @@ static int si2157_init(struct dvb_frontend *fe)
if (ret)
goto err;
 
+   /* Si2141 needs a second command before it answers the revision query */
+   if (dev->chiptype == SI2157_CHIPTYPE_SI2141) {
+   memcpy(cmd.args, "\xc0\x08\x01\x02\x00\x00\x01", 7);
+   cmd.wlen = 7;
+   ret = si2157_cmd_execute(client, );
+   if (ret)
+   goto err;
+   }
+
/* query chip revision */
memcpy(cmd.args, "\x02", 1);
cmd.wlen = 1;
@@ -131,12 +143,16 @@ static int si2157_init(struct dvb_frontend *fe)
#define SI2157_A30 ('A' << 24 | 57 << 16 | '3' << 8 | '0' << 0)
#define SI2147_A30 ('A' << 24 | 47 << 16 | '3' << 8 | '0' << 0)
#define SI2146_A10 ('A' << 24 | 46 << 16 | '1' << 8 | '0' << 0)
+   #define SI2141_A10 ('A' << 24 | 41 << 16 | '1' << 8 | '0' << 0)
 
switch (chip_id) {
case SI2158_A20:
case SI2148_A20:
fw_name = SI2158_A20_FIRMWARE;
break;
+   case SI2141_A10:
+   fw_name = SI2141_A10_FIRMWARE;
+   break;
case SI2157_A30:
case SI2147_A30:
case SI2146_A10:
@@ -371,7 +387,7 @@ static int si2157_get_if_frequency(struct dvb_frontend *fe, 
u32 *frequency)
 
 static const struct dvb_tuner_ops si2157_ops = {
.info = {
-   .name   = "Silicon Labs Si2146/2147/2148/2157/2158",
+   .name   = "Silicon Labs 
Si2141/Si2146/2147/2148/2157/2158",
.frequency_min  = 4200,
.frequency_max  = 87000,
},
@@ -471,6 +487,7 @@ static int si2157_probe(struct i2c_client *client,
 #endif
 
dev_info(>dev, "Silicon Labs %s successfully attached\n",
+   dev->chiptype == SI2157_CHIPTYPE_SI2141 ?  "Si2141" :
dev->chiptype == SI2157_CHIPTYPE_SI2146 ?
"Si2146" : "Si2147/2148/2157/2158");
 
@@ -508,6 +525,7 @@ static int si2157_remove(struct i2c_client *client)
 static const struct i2c_device_id si2157_id_table[] = {
{"si2157", SI2157_CHIPTYPE_SI2157},
{"si2146", SI2157_CHIPTYPE_SI2146},
+   {"si2141", SI2157_CHIPTYPE_SI2141},
{}
 };
 MODULE_DEVICE_TABLE(i2c, si2157_id_table);
@@ -524,7 +542,8 @@ static struct i2c_driver si2157_driver = {
 
 module_i2c_driver(si2157_driver);
 
-MODULE_DESCRIPTION("Silicon Labs Si2146/2147/2148/2157/2158 silicon tuner 
driver");
+MODULE_DESCRIPTION("Silicon Labs Si2141/Si2146/2147/2148/2157/2158 silicon 
tuner driver");
 MODULE_AUTHOR("Antti Palosaari ");
 MODULE_LICENSE("GPL");
 MODULE_FIRMWARE(SI2158_A20_FIRMWARE);
+MODULE_FIRMWARE(SI2141_A10_FIRMWARE);
diff --git a/drivers/media/tuners/si2157_priv.h 
b/drivers/media/tuners/si2157_priv.h
index d6b2c7b44053..e6436f74abaa 100644
--- a/drivers/media/tuners/si2157_priv.h
+++ b/drivers/media/tuners/si2157_priv.h
@@ -42,6 +42,7 @@ struct si2157_dev {
 
 #define SI2157_CHIPTYPE_SI2157 0
 #define SI2157_CHIPTYPE_SI2146 1
+#define SI2157_CHIPTYPE_SI2141 2
 
 /* firmware command struct */
 #define SI2157_ARGLEN  30
@@ -52,5 +53,6 @@ struct si2157_cmd {
 };
 
 #define SI2158_A20_FIRMWARE "dvb-tuner-si2158-a20-01.fw"
+#define SI2141_A10_FIRMWARE "dvb-tuner-si2141-a10-01.fw"
 
 #endif
-- 
2.11.0

[PATCH 1/3] [media] si2157: Add support for Si2141-A10

[Stefan Brüns]

The Si2141 needs two distinct commands for powerup/reset, otherwise it
will not respond to chip revision requests. It also needs a firmware
to run properly.

Signed-off-by: Stefan Brüns 
---
 drivers/media/tuners/si2157.c  | 23 +--
 drivers/media/tuners/si2157_priv.h |  2 ++
 2 files changed, 23 insertions(+), 2 deletions(-)

diff --git a/drivers/media/tuners/si2157.c b/drivers/media/tuners/si2157.c
index 57b250847cd3..e35b1faf0ddc 100644
--- a/drivers/media/tuners/si2157.c
+++ b/drivers/media/tuners/si2157.c
@@ -106,6 +106,9 @@ static int si2157_init(struct dvb_frontend *fe)
if (dev->chiptype == SI2157_CHIPTYPE_SI2146) {
memcpy(cmd.args, "\xc0\x05\x01\x00\x00\x0b\x00\x00\x01", 9);
cmd.wlen = 9;
+   } else if (dev->chiptype == SI2157_CHIPTYPE_SI2141) {
+   memcpy(cmd.args, "\xc0\x00\x0d\x0e\x00\x01\x01\x01\x01\x03", 
10);
+   cmd.wlen = 10;
} else {
memcpy(cmd.args, 
"\xc0\x00\x0c\x00\x00\x01\x01\x01\x01\x01\x01\x02\x00\x00\x01", 15);
cmd.wlen = 15;
@@ -115,6 +118,15 @@ static int si2157_init(struct dvb_frontend *fe)
if (ret)
goto err;
 
+   /* Si2141 needs a second command before it answers the revision query */
+   if (dev->chiptype == SI2157_CHIPTYPE_SI2141) {
+   memcpy(cmd.args, "\xc0\x08\x01\x02\x00\x00\x01", 7);
+   cmd.wlen = 7;
+   ret = si2157_cmd_execute(client, );
+   if (ret)
+   goto err;
+   }
+
/* query chip revision */
memcpy(cmd.args, "\x02", 1);
cmd.wlen = 1;
@@ -131,12 +143,16 @@ static int si2157_init(struct dvb_frontend *fe)
#define SI2157_A30 ('A' << 24 | 57 << 16 | '3' << 8 | '0' << 0)
#define SI2147_A30 ('A' << 24 | 47 << 16 | '3' << 8 | '0' << 0)
#define SI2146_A10 ('A' << 24 | 46 << 16 | '1' << 8 | '0' << 0)
+   #define SI2141_A10 ('A' << 24 | 41 << 16 | '1' << 8 | '0' << 0)
 
switch (chip_id) {
case SI2158_A20:
case SI2148_A20:
fw_name = SI2158_A20_FIRMWARE;
break;
+   case SI2141_A10:
+   fw_name = SI2141_A10_FIRMWARE;
+   break;
case SI2157_A30:
case SI2147_A30:
case SI2146_A10:
@@ -371,7 +387,7 @@ static int si2157_get_if_frequency(struct dvb_frontend *fe, 
u32 *frequency)
 
 static const struct dvb_tuner_ops si2157_ops = {
.info = {
-   .name   = "Silicon Labs Si2146/2147/2148/2157/2158",
+   .name   = "Silicon Labs 
Si2141/Si2146/2147/2148/2157/2158",
.frequency_min  = 4200,
.frequency_max  = 87000,
},
@@ -471,6 +487,7 @@ static int si2157_probe(struct i2c_client *client,
 #endif
 
dev_info(>dev, "Silicon Labs %s successfully attached\n",
+   dev->chiptype == SI2157_CHIPTYPE_SI2141 ?  "Si2141" :
dev->chiptype == SI2157_CHIPTYPE_SI2146 ?
"Si2146" : "Si2147/2148/2157/2158");
 
@@ -508,6 +525,7 @@ static int si2157_remove(struct i2c_client *client)
 static const struct i2c_device_id si2157_id_table[] = {
{"si2157", SI2157_CHIPTYPE_SI2157},
{"si2146", SI2157_CHIPTYPE_SI2146},
+   {"si2141", SI2157_CHIPTYPE_SI2141},
{}
 };
 MODULE_DEVICE_TABLE(i2c, si2157_id_table);
@@ -524,7 +542,8 @@ static struct i2c_driver si2157_driver = {
 
 module_i2c_driver(si2157_driver);
 
-MODULE_DESCRIPTION("Silicon Labs Si2146/2147/2148/2157/2158 silicon tuner 
driver");
+MODULE_DESCRIPTION("Silicon Labs Si2141/Si2146/2147/2148/2157/2158 silicon 
tuner driver");
 MODULE_AUTHOR("Antti Palosaari ");
 MODULE_LICENSE("GPL");
 MODULE_FIRMWARE(SI2158_A20_FIRMWARE);
+MODULE_FIRMWARE(SI2141_A10_FIRMWARE);
diff --git a/drivers/media/tuners/si2157_priv.h 
b/drivers/media/tuners/si2157_priv.h
index d6b2c7b44053..e6436f74abaa 100644
--- a/drivers/media/tuners/si2157_priv.h
+++ b/drivers/media/tuners/si2157_priv.h
@@ -42,6 +42,7 @@ struct si2157_dev {
 
 #define SI2157_CHIPTYPE_SI2157 0
 #define SI2157_CHIPTYPE_SI2146 1
+#define SI2157_CHIPTYPE_SI2141 2
 
 /* firmware command struct */
 #define SI2157_ARGLEN  30
@@ -52,5 +53,6 @@ struct si2157_cmd {
 };
 
 #define SI2158_A20_FIRMWARE "dvb-tuner-si2158-a20-01.fw"
+#define SI2141_A10_FIRMWARE "dvb-tuner-si2141-a10-01.fw"
 
 #endif
-- 
2.11.0

Re: [PATCH v6] fork: free vmapped stacks in cache when cpus are offline

[Thomas Gleixner]

On Sun, 12 Feb 2017, Hoeun Ryu wrote:

>  Using virtually mapped stack, kernel stacks are allocated via vmalloc.
> In the current implementation, two stacks per cpu can be cached when
> tasks are freed and the cached stacks are used again in task duplications.
> but the cached stacks may remain unfreed even when cpu are offline.
>  By adding a cpu hotplug callback to free the cached stacks when a cpu
> goes offline, the pages of the cached stacks are not wasted.
> 
> Signed-off-by: Hoeun Ryu 
> Acked-by: Michal Hocko 

Reviewed-by: Thomas Gleixner 

Re: [PATCH v6] fork: free vmapped stacks in cache when cpus are offline

[Thomas Gleixner]

On Sun, 12 Feb 2017, Hoeun Ryu wrote:

>  Using virtually mapped stack, kernel stacks are allocated via vmalloc.
> In the current implementation, two stacks per cpu can be cached when
> tasks are freed and the cached stacks are used again in task duplications.
> but the cached stacks may remain unfreed even when cpu are offline.
>  By adding a cpu hotplug callback to free the cached stacks when a cpu
> goes offline, the pages of the cached stacks are not wasted.
> 
> Signed-off-by: Hoeun Ryu 
> Acked-by: Michal Hocko 

Reviewed-by: Thomas Gleixner 

Re: [PATCH] lz4: fix performance regressions

[Sven Schmidt]

On Sun, Feb 12, 2017 at 02:05:08PM +0100, Willy Tarreau wrote:
> Hi Sven,
> 
> On Sun, Feb 12, 2017 at 12:16:18PM +0100, Sven Schmidt wrote:
> > Fix performance regressions compared to current kernel LZ4
> 
> Your patch contains mostly style cleanups which certainly are welcome
> but make the whole patch hard to review. These cleanups would have been
> better into a separate, preliminary patch IMHO.
> 
> Regards,
> Willy

Hi Willy,

the problem was, I wanted to compare my version to the upstream LZ4 to find 
bugs (as with my last patch version: wrong indentation in LZ4HC 
in two for loops). But since the LZ4 code is a pain to read, I made additional 
style cleanups "on the way".
Hope you can manage to review the patch though, because it is difficult to 
separate the cleanups now.
Please feel free to ask if you stumble upon something.

Greetings,

Sven 

Re: [PATCH] lz4: fix performance regressions

[Sven Schmidt]

On Sun, Feb 12, 2017 at 02:05:08PM +0100, Willy Tarreau wrote:
> Hi Sven,
> 
> On Sun, Feb 12, 2017 at 12:16:18PM +0100, Sven Schmidt wrote:
> > Fix performance regressions compared to current kernel LZ4
> 
> Your patch contains mostly style cleanups which certainly are welcome
> but make the whole patch hard to review. These cleanups would have been
> better into a separate, preliminary patch IMHO.
> 
> Regards,
> Willy

Hi Willy,

the problem was, I wanted to compare my version to the upstream LZ4 to find 
bugs (as with my last patch version: wrong indentation in LZ4HC 
in two for loops). But since the LZ4 code is a pain to read, I made additional 
style cleanups "on the way".
Hope you can manage to review the patch though, because it is difficult to 
separate the cleanups now.
Please feel free to ask if you stumble upon something.

Greetings,

Sven 

Re: [PATCH v9 0/8] drivers: touchscreen: tsc2007 and ads7846/tsc2046 improvements (use common touchscreen bindings, pre-calibration, spi fix and provide iio raw values)

[H. Nikolaus Schaller]

Hi Dmitry,

> Am 28.01.2017 um 19:16 schrieb H. Nikolaus Schaller :
> 
> Hi Dmitry,
> there have been no further comments/complaints about this patch series in the 
> last month.
> And it appears as if only your action is needed.
> 
> What is missing for this patch series to be finally accepted?

Did you find time to look into my comment on patch 1/9 and make a decision on 
patch 6/8?

Is there anything open which prohibits inclusion to (and further testing 
within) linux/next?

BR and thanks,
Nikolaus

Re: [PATCH v9 0/8] drivers: touchscreen: tsc2007 and ads7846/tsc2046 improvements (use common touchscreen bindings, pre-calibration, spi fix and provide iio raw values)

[H. Nikolaus Schaller]

Hi Dmitry,

> Am 28.01.2017 um 19:16 schrieb H. Nikolaus Schaller :
> 
> Hi Dmitry,
> there have been no further comments/complaints about this patch series in the 
> last month.
> And it appears as if only your action is needed.
> 
> What is missing for this patch series to be finally accepted?

Did you find time to look into my comment on patch 1/9 and make a decision on 
patch 6/8?

Is there anything open which prohibits inclusion to (and further testing 
within) linux/next?

BR and thanks,
Nikolaus

Re: [Intel-gfx] [PATCH] softirq: Prevent looping on disabled tasklets

[kbuild test robot]

Hi Chris,

[auto build test ERROR on linus/master]
[also build test ERROR on v4.10-rc7 next-20170210]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Chris-Wilson/softirq-Prevent-looping-on-disabled-tasklets/20170212-220435
config: x86_64-rhel (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

>> ERROR: "raise_softirq" [sound/pci/asihpi/snd-asihpi.ko] undefined!
>> ERROR: "raise_softirq" [net/mac802154/mac802154.ko] undefined!
   ERROR: "raise_softirq" [net/mac80211/mac80211.ko] undefined!
>> ERROR: "raise_softirq" [drivers/usb/atm/usbatm.ko] undefined!
>> ERROR: "raise_softirq" [drivers/net/ethernet/jme.ko] undefined!
>> ERROR: "raise_softirq" [drivers/media/pci/mantis/mantis_core.ko] undefined!
>> ERROR: "raise_softirq" [drivers/hv/hv_vmbus.ko] undefined!
>> ERROR: "raise_softirq" [drivers/firewire/firewire-ohci.ko] undefined!

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip

Re: [Intel-gfx] [PATCH] softirq: Prevent looping on disabled tasklets

[kbuild test robot]

Hi Chris,

[auto build test ERROR on linus/master]
[also build test ERROR on v4.10-rc7 next-20170210]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Chris-Wilson/softirq-Prevent-looping-on-disabled-tasklets/20170212-220435
config: x86_64-rhel (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

>> ERROR: "raise_softirq" [sound/pci/asihpi/snd-asihpi.ko] undefined!
>> ERROR: "raise_softirq" [net/mac802154/mac802154.ko] undefined!
   ERROR: "raise_softirq" [net/mac80211/mac80211.ko] undefined!
>> ERROR: "raise_softirq" [drivers/usb/atm/usbatm.ko] undefined!
>> ERROR: "raise_softirq" [drivers/net/ethernet/jme.ko] undefined!
>> ERROR: "raise_softirq" [drivers/media/pci/mantis/mantis_core.ko] undefined!
>> ERROR: "raise_softirq" [drivers/hv/hv_vmbus.ko] undefined!
>> ERROR: "raise_softirq" [drivers/firewire/firewire-ohci.ko] undefined!

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip

[PATCH RFC] crypto: testmgr drop wrong init_completion

[Nicholas Mc Guire]

init_completion() is called here to reinitialize a completion object
that was already re-initialized in wait_async_op() by 
reinit_completion() if complete (via tcrypt_complete()) had been called
and wait_for_completion() returned, so no need to reinit it here.


Fixes: commit 946cc46372dc ("crypto: testmgr - add tests vectors for RSA")
Signed-off-by: Nicholas Mc Guire 
---

Found by experimental coccinelle script
./crypto/testmgr.c:2174:1-16: WARNING: possible duplicate init_completion

Only based on code review and no testing. In case I am overlooking something
and the re-initialization of the completion object is actually needed it
should be using reinit_completion() and not init_completion() anyway.
But as wait_async_op() will leave with the completion object re-initialized
it really should not be needed here (found no path in between that could
have called completion()).

Patch was only compile tested with: x86_64_defconfig (implies cryptomgr-y)

Patch is against linux-4.10-rc6 (localversion-next is next-20170210)

 crypto/testmgr.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/crypto/testmgr.c b/crypto/testmgr.c
index 98eb097..15fb453 100644
--- a/crypto/testmgr.c
+++ b/crypto/testmgr.c
@@ -2171,7 +2171,6 @@ static int test_akcipher_one(struct crypto_akcipher *tfm,
 
sg_init_one(, xbuf[0], vecs->c_size);
sg_init_one(, outbuf_dec, out_len_max);
-   init_completion();
akcipher_request_set_crypt(req, , , vecs->c_size, out_len_max);
 
/* Run RSA decrypt - m = c^d mod n;*/
-- 
2.1.4

[PATCH RFC] crypto: testmgr drop wrong init_completion

[Nicholas Mc Guire]

init_completion() is called here to reinitialize a completion object
that was already re-initialized in wait_async_op() by 
reinit_completion() if complete (via tcrypt_complete()) had been called
and wait_for_completion() returned, so no need to reinit it here.


Fixes: commit 946cc46372dc ("crypto: testmgr - add tests vectors for RSA")
Signed-off-by: Nicholas Mc Guire 
---

Found by experimental coccinelle script
./crypto/testmgr.c:2174:1-16: WARNING: possible duplicate init_completion

Only based on code review and no testing. In case I am overlooking something
and the re-initialization of the completion object is actually needed it
should be using reinit_completion() and not init_completion() anyway.
But as wait_async_op() will leave with the completion object re-initialized
it really should not be needed here (found no path in between that could
have called completion()).

Patch was only compile tested with: x86_64_defconfig (implies cryptomgr-y)

Patch is against linux-4.10-rc6 (localversion-next is next-20170210)

 crypto/testmgr.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/crypto/testmgr.c b/crypto/testmgr.c
index 98eb097..15fb453 100644
--- a/crypto/testmgr.c
+++ b/crypto/testmgr.c
@@ -2171,7 +2171,6 @@ static int test_akcipher_one(struct crypto_akcipher *tfm,
 
sg_init_one(, xbuf[0], vecs->c_size);
sg_init_one(, outbuf_dec, out_len_max);
-   init_completion();
akcipher_request_set_crypt(req, , , vecs->c_size, out_len_max);
 
/* Run RSA decrypt - m = c^d mod n;*/
-- 
2.1.4

Re: [Intel-gfx] [PATCH] softirq: Prevent looping on disabled tasklets

[kbuild test robot]

Hi Chris,

[auto build test ERROR on linus/master]
[also build test ERROR on v4.10-rc7 next-20170210]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Chris-Wilson/softirq-Prevent-looping-on-disabled-tasklets/20170212-220435
config: x86_64-lkp (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

>> ERROR: "raise_softirq" [net/mac80211/mac80211.ko] undefined!

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip

Re: [Intel-gfx] [PATCH] softirq: Prevent looping on disabled tasklets

[kbuild test robot]

Hi Chris,

[auto build test ERROR on linus/master]
[also build test ERROR on v4.10-rc7 next-20170210]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Chris-Wilson/softirq-Prevent-looping-on-disabled-tasklets/20170212-220435
config: x86_64-lkp (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

>> ERROR: "raise_softirq" [net/mac80211/mac80211.ko] undefined!

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip

[PATCH v2] [media] dvb-usb-firmware: don't do DMA on stack

[Stefan Brüns]

The buffer allocation for the firmware data was changed in
commit 43fab9793c1f ("dvb-usb: don't use stack for firmware load"),
but the same applies for the reset value.

Signed-off-by: Stefan Brüns 
---
This patch replaces the earlier submission conflicting with commit
43fab9793c1f, which was a subset of the submitted patch.

 drivers/media/usb/dvb-usb/dvb-usb-firmware.c | 21 -
 1 file changed, 12 insertions(+), 9 deletions(-)

diff --git a/drivers/media/usb/dvb-usb/dvb-usb-firmware.c 
b/drivers/media/usb/dvb-usb/dvb-usb-firmware.c
index 3271b3fee1f4..1f008f354282 100644
--- a/drivers/media/usb/dvb-usb/dvb-usb-firmware.c
+++ b/drivers/media/usb/dvb-usb/dvb-usb-firmware.c
@@ -36,16 +36,19 @@ static int usb_cypress_writemem(struct usb_device *udev,u16 
addr,u8 *data, u8 le
 int usb_cypress_load_firmware(struct usb_device *udev, const struct firmware 
*fw, int type)
 {
struct hexline *hx;
-   u8 reset;
+   u8 *buf;
+   u8 *reset;
int ret,pos=0;
+   u16 cpu_cs_register = cypress[type].cpu_cs_register;
 
-   hx = kmalloc(sizeof(*hx), GFP_KERNEL);
-   if (!hx)
+   buf = kmalloc(sizeof(*hx), GFP_KERNEL);
+   if (!buf)
return -ENOMEM;
+   hx = (struct hexline *)buf;
 
/* stop the CPU */
-   reset = 1;
-   if ((ret = 
usb_cypress_writemem(udev,cypress[type].cpu_cs_register,,1)) != 1)
+   buf[0] = 1;
+   if (usb_cypress_writemem(udev, cpu_cs_register, buf, 1) != 1)
err("could not stop the USB controller CPU.");
 
while ((ret = dvb_usb_get_hexline(fw, hx, )) > 0) {
@@ -61,21 +64,21 @@ int usb_cypress_load_firmware(struct usb_device *udev, 
const struct firmware *fw
}
if (ret < 0) {
err("firmware download failed at %d with %d",pos,ret);
-   kfree(hx);
+   kfree(buf);
return ret;
}
 
if (ret == 0) {
/* restart the CPU */
-   reset = 0;
-   if (ret || 
usb_cypress_writemem(udev,cypress[type].cpu_cs_register,,1) != 1) {
+   buf[0] = 0;
+   if (usb_cypress_writemem(udev, cpu_cs_register, buf, 1) != 1) {
err("could not restart the USB controller CPU.");
ret = -EINVAL;
}
} else
ret = -EIO;
 
-   kfree(hx);
+   kfree(buf);
 
return ret;
 }
-- 
2.11.0

[PATCH v2] [media] dvb-usb-firmware: don't do DMA on stack

[Stefan Brüns]

The buffer allocation for the firmware data was changed in
commit 43fab9793c1f ("dvb-usb: don't use stack for firmware load"),
but the same applies for the reset value.

Signed-off-by: Stefan Brüns 
---
This patch replaces the earlier submission conflicting with commit
43fab9793c1f, which was a subset of the submitted patch.

 drivers/media/usb/dvb-usb/dvb-usb-firmware.c | 21 -
 1 file changed, 12 insertions(+), 9 deletions(-)

diff --git a/drivers/media/usb/dvb-usb/dvb-usb-firmware.c 
b/drivers/media/usb/dvb-usb/dvb-usb-firmware.c
index 3271b3fee1f4..1f008f354282 100644
--- a/drivers/media/usb/dvb-usb/dvb-usb-firmware.c
+++ b/drivers/media/usb/dvb-usb/dvb-usb-firmware.c
@@ -36,16 +36,19 @@ static int usb_cypress_writemem(struct usb_device *udev,u16 
addr,u8 *data, u8 le
 int usb_cypress_load_firmware(struct usb_device *udev, const struct firmware 
*fw, int type)
 {
struct hexline *hx;
-   u8 reset;
+   u8 *buf;
+   u8 *reset;
int ret,pos=0;
+   u16 cpu_cs_register = cypress[type].cpu_cs_register;
 
-   hx = kmalloc(sizeof(*hx), GFP_KERNEL);
-   if (!hx)
+   buf = kmalloc(sizeof(*hx), GFP_KERNEL);
+   if (!buf)
return -ENOMEM;
+   hx = (struct hexline *)buf;
 
/* stop the CPU */
-   reset = 1;
-   if ((ret = 
usb_cypress_writemem(udev,cypress[type].cpu_cs_register,,1)) != 1)
+   buf[0] = 1;
+   if (usb_cypress_writemem(udev, cpu_cs_register, buf, 1) != 1)
err("could not stop the USB controller CPU.");
 
while ((ret = dvb_usb_get_hexline(fw, hx, )) > 0) {
@@ -61,21 +64,21 @@ int usb_cypress_load_firmware(struct usb_device *udev, 
const struct firmware *fw
}
if (ret < 0) {
err("firmware download failed at %d with %d",pos,ret);
-   kfree(hx);
+   kfree(buf);
return ret;
}
 
if (ret == 0) {
/* restart the CPU */
-   reset = 0;
-   if (ret || 
usb_cypress_writemem(udev,cypress[type].cpu_cs_register,,1) != 1) {
+   buf[0] = 0;
+   if (usb_cypress_writemem(udev, cpu_cs_register, buf, 1) != 1) {
err("could not restart the USB controller CPU.");
ret = -EINVAL;
}
} else
ret = -EIO;
 
-   kfree(hx);
+   kfree(buf);
 
return ret;
 }
-- 
2.11.0

[PATCH] video/viafbdev: Make PROC_FS dependency explicit

[Borislav Petkov]

From: Borislav Petkov 

Fix:

  drivers/video/fbdev/via/viafbdev.c: In function ‘viafb_remove_proc’:
  drivers/video/fbdev/via/viafbdev.c:1635:4: warning: unused variable 
‘iga2_entry’ [-Wunused-variable]
 *iga2_entry = shared->iga2_proc_entry;
  ^~
  drivers/video/fbdev/via/viafbdev.c:1634:4: warning: unused variable 
‘iga1_entry’ [-Wunused-variable]
 *iga1_entry = shared->iga1_proc_entry,

build warning from randconfig builds.

Signed-off-by: Borislav Petkov 
---
 drivers/video/fbdev/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
index 5d3b0db5ce0a..86ec39784c5a 100644
--- a/drivers/video/fbdev/Kconfig
+++ b/drivers/video/fbdev/Kconfig
@@ -1539,7 +1539,7 @@ config FB_SIS_315
 
 config FB_VIA
tristate "VIA UniChrome (Pro) and Chrome9 display support"
-   depends on FB && PCI && X86 && GPIOLIB && I2C
+   depends on FB && PCI && X86 && GPIOLIB && I2C && PROC_FS
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
select FB_CFB_IMAGEBLIT
-- 
2.11.0

[PATCH] video/viafbdev: Make PROC_FS dependency explicit

[Borislav Petkov]

From: Borislav Petkov 

Fix:

  drivers/video/fbdev/via/viafbdev.c: In function ‘viafb_remove_proc’:
  drivers/video/fbdev/via/viafbdev.c:1635:4: warning: unused variable 
‘iga2_entry’ [-Wunused-variable]
 *iga2_entry = shared->iga2_proc_entry;
  ^~
  drivers/video/fbdev/via/viafbdev.c:1634:4: warning: unused variable 
‘iga1_entry’ [-Wunused-variable]
 *iga1_entry = shared->iga1_proc_entry,

build warning from randconfig builds.

Signed-off-by: Borislav Petkov 
---
 drivers/video/fbdev/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
index 5d3b0db5ce0a..86ec39784c5a 100644
--- a/drivers/video/fbdev/Kconfig
+++ b/drivers/video/fbdev/Kconfig
@@ -1539,7 +1539,7 @@ config FB_SIS_315
 
 config FB_VIA
tristate "VIA UniChrome (Pro) and Chrome9 display support"
-   depends on FB && PCI && X86 && GPIOLIB && I2C
+   depends on FB && PCI && X86 && GPIOLIB && I2C && PROC_FS
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
select FB_CFB_IMAGEBLIT
-- 
2.11.0

Re: [PATCH v2] PCI: pciehp: Don't enable PME on runtime suspend

[Lukas Wunner]

On Thu, Feb 09, 2017 at 05:32:54AM +0100, Lukas Wunner wrote:
> On Wed, Feb 08, 2017 at 11:57:36AM -0600, Bjorn Helgaas wrote:
> > On Tue, Feb 07, 2017 at 07:21:01AM +0100, Lukas Wunner wrote:
> > > On Mon, Feb 06, 2017 at 04:15:02PM -0600, Bjorn Helgaas wrote:
> > > > On Mon, Feb 06, 2017 at 10:20:41PM +0100, Lukas Wunner wrote:
> > > > > On Mon, Feb 06, 2017 at 11:54:05AM -0600, Bjorn Helgaas wrote:
> > > > > > What is the hotplug event that causes generation of this wakeup 
> > > > > > event?
> > > > > 
> > > > > If you had read all e-mails in this thread or looked at the bugzilla
> > > > > entry I've created, you wouldn't have to ask this question.
> > > > 
> > > > I'm sorry, I don't necessarily have time to sort through all the
> > > > emails.  My idea is that the changelog should be a self-contained
> > > > justification for the patch.  The bugzilla is for supporting details
> > > > and future archaeologists.
> > > > 
> [...]
> > > > If you think a bugzilla is onerous
> > > 
> > > Hold on.  I didn't say a bugzilla is onerous, I said I'm disappointed
> > > that you're asking me to create one and then don't look at it.
> > 
> > I looked at it, and it had a few details, but no analysis of the
> > situation.  Ideally, I'm looking for a précis of the situation in
> > the changelog, with complete analysis and supporting details in the
> > bugzilla.
> 
> It's irrelevant whether the bugzilla contains an analysis or not.
> 
> You were asking what type of event caused the wakeup.  The information
> was in the bugzilla.  So you either didn't look at the bugzilla or
> didn't look hard enough.
> 
> Please tell me why in the future I should comply with your requests to
> create a bugzilla if you don't look at it and the bug reporter doesn't
> bother attaching any further information.  It would also have been
> possible for you to glean the information you were asking for from the
> reporter's e-mails but you didn't read those either.  And you're paid
> to do this, I'm not.  If you look at the timestamps of my e-mails you
> may notice that they're either early in the morning, late at night or
> on weekends.  Guess what, I'm doing this in my spare time, in addition
> to my day job.

My apologies Bjorn, it was clearly inappropriate for me to assume that
maintenance of the PCI subsystem is at all part of your job contract,
or talk about it on a public mailing list.

Kind regards,

Lukas

Re: [PATCH v2] PCI: pciehp: Don't enable PME on runtime suspend

[Lukas Wunner]

On Thu, Feb 09, 2017 at 05:32:54AM +0100, Lukas Wunner wrote:
> On Wed, Feb 08, 2017 at 11:57:36AM -0600, Bjorn Helgaas wrote:
> > On Tue, Feb 07, 2017 at 07:21:01AM +0100, Lukas Wunner wrote:
> > > On Mon, Feb 06, 2017 at 04:15:02PM -0600, Bjorn Helgaas wrote:
> > > > On Mon, Feb 06, 2017 at 10:20:41PM +0100, Lukas Wunner wrote:
> > > > > On Mon, Feb 06, 2017 at 11:54:05AM -0600, Bjorn Helgaas wrote:
> > > > > > What is the hotplug event that causes generation of this wakeup 
> > > > > > event?
> > > > > 
> > > > > If you had read all e-mails in this thread or looked at the bugzilla
> > > > > entry I've created, you wouldn't have to ask this question.
> > > > 
> > > > I'm sorry, I don't necessarily have time to sort through all the
> > > > emails.  My idea is that the changelog should be a self-contained
> > > > justification for the patch.  The bugzilla is for supporting details
> > > > and future archaeologists.
> > > > 
> [...]
> > > > If you think a bugzilla is onerous
> > > 
> > > Hold on.  I didn't say a bugzilla is onerous, I said I'm disappointed
> > > that you're asking me to create one and then don't look at it.
> > 
> > I looked at it, and it had a few details, but no analysis of the
> > situation.  Ideally, I'm looking for a précis of the situation in
> > the changelog, with complete analysis and supporting details in the
> > bugzilla.
> 
> It's irrelevant whether the bugzilla contains an analysis or not.
> 
> You were asking what type of event caused the wakeup.  The information
> was in the bugzilla.  So you either didn't look at the bugzilla or
> didn't look hard enough.
> 
> Please tell me why in the future I should comply with your requests to
> create a bugzilla if you don't look at it and the bug reporter doesn't
> bother attaching any further information.  It would also have been
> possible for you to glean the information you were asking for from the
> reporter's e-mails but you didn't read those either.  And you're paid
> to do this, I'm not.  If you look at the timestamps of my e-mails you
> may notice that they're either early in the morning, late at night or
> on weekends.  Guess what, I'm doing this in my spare time, in addition
> to my day job.

My apologies Bjorn, it was clearly inappropriate for me to assume that
maintenance of the PCI subsystem is at all part of your job contract,
or talk about it on a public mailing list.

Kind regards,

Lukas

Re: [PATCH] smiapp: add CCP2 support

[kbuild test robot]

Hi Pavel,

[auto build test ERROR on linuxtv-media/master]
[also build test ERROR on v4.10-rc7 next-20170210]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Pavel-Machek/smiapp-add-CCP2-support/20170208-214729
base:   git://linuxtv.org/media_tree.git master
config: x86_64-randconfig-it0-02122030 (attached as .config)
compiler: gcc-4.9 (Debian 4.9.4-2) 4.9.4
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

   drivers/media/i2c/smiapp/smiapp-core.c: In function 'smiapp_get_hwconfig':
   drivers/media/i2c/smiapp/smiapp-core.c:2812:7: error: 'V4L2_MBUS_CCP2' 
undeclared (first use in this function)
 case V4L2_MBUS_CCP2:
  ^
   drivers/media/i2c/smiapp/smiapp-core.c:2812:7: note: each undeclared 
identifier is reported only once for each function it appears in
>> drivers/media/i2c/smiapp/smiapp-core.c:2813:45: error: 'union ' 
>> has no member named 'mipi_csi1'
  hwcfg->csi_signalling_mode = (bus_cfg->bus.mipi_csi1.strobe) ?
^

vim +2813 drivers/media/i2c/smiapp/smiapp-core.c

  2806  
  2807  switch (bus_cfg->bus_type) {
  2808  case V4L2_MBUS_CSI2:
  2809  hwcfg->csi_signalling_mode = 
SMIAPP_CSI_SIGNALLING_MODE_CSI2;
  2810  hwcfg->lanes = bus_cfg->bus.mipi_csi2.num_data_lanes;
  2811  break;
> 2812  case V4L2_MBUS_CCP2:
> 2813  hwcfg->csi_signalling_mode = 
> (bus_cfg->bus.mipi_csi1.strobe) ?
  2814  SMIAPP_CSI_SIGNALLING_MODE_CCP2_DATA_STROBE :
  2815  SMIAPP_CSI_SIGNALLING_MODE_CCP2_DATA_CLOCK;
  2816  hwcfg->lanes = 1;

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip

Re: [PATCH] smiapp: add CCP2 support

[kbuild test robot]

Hi Pavel,

[auto build test ERROR on linuxtv-media/master]
[also build test ERROR on v4.10-rc7 next-20170210]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Pavel-Machek/smiapp-add-CCP2-support/20170208-214729
base:   git://linuxtv.org/media_tree.git master
config: x86_64-randconfig-it0-02122030 (attached as .config)
compiler: gcc-4.9 (Debian 4.9.4-2) 4.9.4
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

   drivers/media/i2c/smiapp/smiapp-core.c: In function 'smiapp_get_hwconfig':
   drivers/media/i2c/smiapp/smiapp-core.c:2812:7: error: 'V4L2_MBUS_CCP2' 
undeclared (first use in this function)
 case V4L2_MBUS_CCP2:
  ^
   drivers/media/i2c/smiapp/smiapp-core.c:2812:7: note: each undeclared 
identifier is reported only once for each function it appears in
>> drivers/media/i2c/smiapp/smiapp-core.c:2813:45: error: 'union ' 
>> has no member named 'mipi_csi1'
  hwcfg->csi_signalling_mode = (bus_cfg->bus.mipi_csi1.strobe) ?
^

vim +2813 drivers/media/i2c/smiapp/smiapp-core.c

  2806  
  2807  switch (bus_cfg->bus_type) {
  2808  case V4L2_MBUS_CSI2:
  2809  hwcfg->csi_signalling_mode = 
SMIAPP_CSI_SIGNALLING_MODE_CSI2;
  2810  hwcfg->lanes = bus_cfg->bus.mipi_csi2.num_data_lanes;
  2811  break;
> 2812  case V4L2_MBUS_CCP2:
> 2813  hwcfg->csi_signalling_mode = 
> (bus_cfg->bus.mipi_csi1.strobe) ?
  2814  SMIAPP_CSI_SIGNALLING_MODE_CCP2_DATA_STROBE :
  2815  SMIAPP_CSI_SIGNALLING_MODE_CCP2_DATA_CLOCK;
  2816  hwcfg->lanes = 1;

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip

[PATCH v2] softirq: Prevent looping on disabled tasklets

[Chris Wilson]

Disabling a tasklet causes it not to run during tasklet_action, but is
put back onto the runnable tasklet list, and a new softirq raised. As
the softirq is raised from within __do_softirq() this causing
__do_softirq() to loop constantly until its timeslice expires and is
transferred to the ksoftirq thread. ksoftirq then permanently spins,
as on each action, the disabled tasklet keeps reraising the softirq.

Break this vicious cycle by moving the softirq from the action to the
final tasklet_enable().

This behaviour appears to be historic (since the first git import).
However, the looping until timeslice duration (to a max of 2ms) was
first introduced in commit c10d73671ad3 ("softirq: reduce latencies"),
with the restart limit restored in commit 34376a50fb1f ("Fix lockup
related to stop_machine being stuck in __do_softirq.")

v2: Export tasklet_enable() to work with modules.

Reported-by: Tvrtko Ursulin 
Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
Cc: Thomas Gleixner 
Cc: Hannes Reinecke 
Cc: Jens Axboe 
Cc: Bjorn Helgaas 
Cc: Alexander Potapenko 
Cc: Chen Fan 
Cc: Ingo Molnar 
Cc: "Peter Zijlstra (Intel)" 
Cc: Sebastian Andrzej Siewior 
Cc: Johannes Thumshirn 
Cc: Emese Revfy 
Cc: Sagi Grimberg 
Cc: Eric Dumazet 
Cc: Tom Herbert 
Cc: Ben Hutchings 
---
 include/linux/interrupt.h |  7 +--
 kernel/softirq.c  | 12 ++--
 2 files changed, 11 insertions(+), 8 deletions(-)

diff --git a/include/linux/interrupt.h b/include/linux/interrupt.h
index 53144e78a369..a1fa88e7e509 100644
--- a/include/linux/interrupt.h
+++ b/include/linux/interrupt.h
@@ -611,12 +611,7 @@ static inline void tasklet_disable(struct tasklet_struct 
*t)
smp_mb();
 }
 
-static inline void tasklet_enable(struct tasklet_struct *t)
-{
-   smp_mb__before_atomic();
-   atomic_dec(>count);
-}
-
+extern void tasklet_enable(struct tasklet_struct *t);
 extern void tasklet_kill(struct tasklet_struct *t);
 extern void tasklet_kill_immediate(struct tasklet_struct *t, unsigned int cpu);
 extern void tasklet_init(struct tasklet_struct *t,
diff --git a/kernel/softirq.c b/kernel/softirq.c
index 080eb57789c4..ab8d9aeccb46 100644
--- a/kernel/softirq.c
+++ b/kernel/softirq.c
@@ -535,7 +535,6 @@ static __latent_entropy void tasklet_action(struct 
softirq_action *a)
t->next = NULL;
*__this_cpu_read(tasklet_vec.tail) = t;
__this_cpu_write(tasklet_vec.tail, &(t->next));
-   __raise_softirq_irqoff(TASKLET_SOFTIRQ);
local_irq_enable();
}
 }
@@ -571,7 +570,6 @@ static __latent_entropy void tasklet_hi_action(struct 
softirq_action *a)
t->next = NULL;
*__this_cpu_read(tasklet_hi_vec.tail) = t;
__this_cpu_write(tasklet_hi_vec.tail, &(t->next));
-   __raise_softirq_irqoff(HI_SOFTIRQ);
local_irq_enable();
}
 }
@@ -587,6 +585,16 @@ void tasklet_init(struct tasklet_struct *t,
 }
 EXPORT_SYMBOL(tasklet_init);
 
+void tasklet_enable(struct tasklet_struct *t)
+{
+   if (!atomic_dec_and_test(>count))
+   return;
+
+   if (test_bit(TASKLET_STATE_SCHED, >state))
+   raise_softirq(HI_SOFTIRQ | TASKLET_SOFTIRQ);
+}
+EXPORT_SYMBOL(tasklet_enable);
+
 void tasklet_kill(struct tasklet_struct *t)
 {
if (in_interrupt())
-- 
2.11.0

[PATCH v2] softirq: Prevent looping on disabled tasklets

[Chris Wilson]

Disabling a tasklet causes it not to run during tasklet_action, but is
put back onto the runnable tasklet list, and a new softirq raised. As
the softirq is raised from within __do_softirq() this causing
__do_softirq() to loop constantly until its timeslice expires and is
transferred to the ksoftirq thread. ksoftirq then permanently spins,
as on each action, the disabled tasklet keeps reraising the softirq.

Break this vicious cycle by moving the softirq from the action to the
final tasklet_enable().

This behaviour appears to be historic (since the first git import).
However, the looping until timeslice duration (to a max of 2ms) was
first introduced in commit c10d73671ad3 ("softirq: reduce latencies"),
with the restart limit restored in commit 34376a50fb1f ("Fix lockup
related to stop_machine being stuck in __do_softirq.")

v2: Export tasklet_enable() to work with modules.

Reported-by: Tvrtko Ursulin 
Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
Cc: Thomas Gleixner 
Cc: Hannes Reinecke 
Cc: Jens Axboe 
Cc: Bjorn Helgaas 
Cc: Alexander Potapenko 
Cc: Chen Fan 
Cc: Ingo Molnar 
Cc: "Peter Zijlstra (Intel)" 
Cc: Sebastian Andrzej Siewior 
Cc: Johannes Thumshirn 
Cc: Emese Revfy 
Cc: Sagi Grimberg 
Cc: Eric Dumazet 
Cc: Tom Herbert 
Cc: Ben Hutchings 
---
 include/linux/interrupt.h |  7 +--
 kernel/softirq.c  | 12 ++--
 2 files changed, 11 insertions(+), 8 deletions(-)

diff --git a/include/linux/interrupt.h b/include/linux/interrupt.h
index 53144e78a369..a1fa88e7e509 100644
--- a/include/linux/interrupt.h
+++ b/include/linux/interrupt.h
@@ -611,12 +611,7 @@ static inline void tasklet_disable(struct tasklet_struct 
*t)
smp_mb();
 }
 
-static inline void tasklet_enable(struct tasklet_struct *t)
-{
-   smp_mb__before_atomic();
-   atomic_dec(>count);
-}
-
+extern void tasklet_enable(struct tasklet_struct *t);
 extern void tasklet_kill(struct tasklet_struct *t);
 extern void tasklet_kill_immediate(struct tasklet_struct *t, unsigned int cpu);
 extern void tasklet_init(struct tasklet_struct *t,
diff --git a/kernel/softirq.c b/kernel/softirq.c
index 080eb57789c4..ab8d9aeccb46 100644
--- a/kernel/softirq.c
+++ b/kernel/softirq.c
@@ -535,7 +535,6 @@ static __latent_entropy void tasklet_action(struct 
softirq_action *a)
t->next = NULL;
*__this_cpu_read(tasklet_vec.tail) = t;
__this_cpu_write(tasklet_vec.tail, &(t->next));
-   __raise_softirq_irqoff(TASKLET_SOFTIRQ);
local_irq_enable();
}
 }
@@ -571,7 +570,6 @@ static __latent_entropy void tasklet_hi_action(struct 
softirq_action *a)
t->next = NULL;
*__this_cpu_read(tasklet_hi_vec.tail) = t;
__this_cpu_write(tasklet_hi_vec.tail, &(t->next));
-   __raise_softirq_irqoff(HI_SOFTIRQ);
local_irq_enable();
}
 }
@@ -587,6 +585,16 @@ void tasklet_init(struct tasklet_struct *t,
 }
 EXPORT_SYMBOL(tasklet_init);
 
+void tasklet_enable(struct tasklet_struct *t)
+{
+   if (!atomic_dec_and_test(>count))
+   return;
+
+   if (test_bit(TASKLET_STATE_SCHED, >state))
+   raise_softirq(HI_SOFTIRQ | TASKLET_SOFTIRQ);
+}
+EXPORT_SYMBOL(tasklet_enable);
+
 void tasklet_kill(struct tasklet_struct *t)
 {
if (in_interrupt())
-- 
2.11.0

Re: [PATCH] softirq: Prevent looping on disabled tasklets

[Chris Wilson]

On Sun, Feb 12, 2017 at 02:00:19PM +, Chris Wilson wrote:
> Disabling a tasklet causes it not to run during tasklet_action, but is
> put back onto the runnable tasklet list, and a new softirq raised. As
> the softirq is raised from within __do_softirq() this causing
> __do_softirq() to loop constantly until its timeslice expires and is
> transferred to the ksoftirq thread. ksoftirq then permanently spins,
> as on each action, the disabled tasklet keeps reraising the softirq.
> 
> Break this vicious cycle by moving the softirq from the action to the
> final tasklet_enable().
> 
> This behaviour appears to be historic (since the first git import).
> However, the looping until timeslice duration (to a max of 2ms) was
> first introduced in commit c10d73671ad3 ("softirq: reduce latencies"),
> with the restart limit restored in commit 34376a50fb1f ("Fix lockup
> related to stop_machine being stuck in __do_softirq.")
> 
> Reported-by: Tvrtko Ursulin 
> Signed-off-by: Chris Wilson 
> Cc: Tvrtko Ursulin 
> Cc: Thomas Gleixner 
> Cc: Hannes Reinecke 
> Cc: Jens Axboe 
> Cc: Bjorn Helgaas 
> Cc: Alexander Potapenko 
> Cc: Chen Fan 
> Cc: Ingo Molnar 
> Cc: "Peter Zijlstra (Intel)" 
> Cc: Sebastian Andrzej Siewior 
> Cc: Johannes Thumshirn 
> Cc: Emese Revfy 
> Cc: Sagi Grimberg 
> Cc: Eric Dumazet 
> Cc: Tom Herbert 
> Cc: Ben Hutchings 
> ---
>  include/linux/interrupt.h | 7 +--
>  kernel/softirq.c  | 2 --
>  2 files changed, 5 insertions(+), 4 deletions(-)
> 
> diff --git a/include/linux/interrupt.h b/include/linux/interrupt.h
> index 53144e78a369..12750f00d00d 100644
> --- a/include/linux/interrupt.h
> +++ b/include/linux/interrupt.h
> @@ -613,8 +613,11 @@ static inline void tasklet_disable(struct tasklet_struct 
> *t)
>  
>  static inline void tasklet_enable(struct tasklet_struct *t)
>  {
> - smp_mb__before_atomic();
> - atomic_dec(>count);
> + if (!atomic_dec_and_test(>count))
> + return;
> +
> + if (test_bit(TASKLET_STATE_SCHED, >state))
> + raise_softirq(HI_SOFTIRQ | TASKLET_SOFTIRQ);

raise_softirq is not exported, so let's move tasklet_enable()
out-of-line and export that.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

Trying to understand OOM killer

[Paul Menzel]

Dear Linux folks,


since some time, at Linux 4.8, 4.9, and 4.10-rc6, the OOM kicks in on a
8 GB machine.

```
Feb 12 08:21:50 asrocke350m1 kernel: updatedb.mlocat invoked oom-killer: 
gfp_mask=0x16040d0(GFP_TEMPORARY|__GFP_COMP|__GFP_NOTRACK), nodemask=
Feb 12 08:21:50 asrocke350m1 kernel: updatedb.mlocat cpuset=/ mems_allowed=0
Feb 12 08:21:50 asrocke350m1 kernel: CPU: 1 PID: 2314 Comm: updatedb.mlocat 
Tainted: G C  4.10.0-rc6-686-pae #1 Debian 4.10~rc6-1~
Feb 12 08:21:50 asrocke350m1 kernel: Hardware name: ASROCK E350M1/E350M1, BIOS 
4.5-964-gd96669e9db 02/11/2017
Feb 12 08:21:51 asrocke350m1 kernel: Call Trace:
Feb 12 08:21:51 asrocke350m1 kernel:  ? dump_stack+0x55/0x73
Feb 12 08:21:51 asrocke350m1 kernel:  ? dump_header+0x64/0x1ab
Feb 12 08:21:52 asrocke350m1 kernel:  ? ___ratelimit+0x9f/0x100
Feb 12 08:21:52 asrocke350m1 kernel:  ? oom_kill_process+0x221/0x3e0
Feb 12 08:21:52 asrocke350m1 kernel:  ? has_capability_noaudit+0x1a/0x30
Feb 12 08:21:52 asrocke350m1 kernel:  ? oom_badness.part.13+0xd7/0x150
Feb 12 08:21:52 asrocke350m1 kernel:  ? out_of_memory+0xe4/0x290
Feb 12 08:21:52 asrocke350m1 kernel:  ? __alloc_pages_nodemask+0xab8/0xbc0
Feb 12 08:21:52 asrocke350m1 kernel:  ? xfs_init_local_fork+0x8a/0xd0 [xfs]
Feb 12 08:21:52 asrocke350m1 kernel:  ? cache_grow_begin.isra.60+0x75/0x510
Feb 12 08:21:52 asrocke350m1 kernel:  ? xfs_buf_rele+0x43/0x2e0 [xfs]
Feb 12 08:21:52 asrocke350m1 kernel:  ? kmem_cache_alloc+0x1fa/0x530
Feb 12 08:21:52 asrocke350m1 kernel:  ? __d_alloc+0x23/0x180
Feb 12 08:21:52 asrocke350m1 kernel:  ? d_alloc+0x18/0x80
Feb 12 08:21:52 asrocke350m1 kernel:  ? d_alloc_parallel+0x47/0x450
Feb 12 08:21:52 asrocke350m1 kernel:  ? d_splice_alias+0x10d/0x3a0
Feb 12 08:21:53 asrocke350m1 kernel:  ? lockref_get_not_dead+0x8/0x40
Feb 12 08:21:53 asrocke350m1 kernel:  ? unlazy_walk+0xf9/0x1a0
Feb 12 08:21:53 asrocke350m1 kernel:  ? lookup_slow+0x5e/0x140
Feb 12 08:21:53 asrocke350m1 kernel:  ? walk_component+0x1b4/0x350
Feb 12 08:21:53 asrocke350m1 kernel:  ? path_lookupat+0x49/0xe0
Feb 12 08:21:53 asrocke350m1 kernel:  ? filename_lookup+0x99/0x190
Feb 12 08:21:53 asrocke350m1 kernel:  ? __check_object_size+0x9e/0x11c
Feb 12 08:21:53 asrocke350m1 kernel:  ? strncpy_from_user+0x39/0x140
Feb 12 08:21:53 asrocke350m1 kernel:  ? getname_flags+0x55/0x1a0
Feb 12 08:21:53 asrocke350m1 kernel:  ? vfs_fstatat+0x60/0xb0
Feb 12 08:21:53 asrocke350m1 kernel:  ? SyS_lstat64+0x2d/0x50
Feb 12 08:21:53 asrocke350m1 kernel:  ? sys_sync+0x9d/0xa0
Feb 12 08:21:53 asrocke350m1 kernel:  ? SyS_poll+0x6b/0x110
Feb 12 08:21:53 asrocke350m1 kernel:  ? do_fast_syscall_32+0x8a/0x150
Feb 12 08:21:53 asrocke350m1 kernel:  ? entry_SYSENTER_32+0x4e/0x7c
Feb 12 08:21:53 asrocke350m1 kernel: Mem-Info:
Feb 12 08:21:53 asrocke350m1 kernel: active_anon:119893 inactive_anon:17678 
isolated_anon:0
active_file:31461 inactive_file:219091 
isolated_file:0
unevictable:21 dirty:0 writeback:0 
unstable:0
slab_reclaimable:127609 
slab_unreclaimable:9519
mapped:63113 shmem:6177 pagetables:1601 
bounce:0
free:1381579 free_pcp:583 free_cma:0
Feb 12 08:21:53 asrocke350m1 kernel: Node 0 active_anon:479572kB 
inactive_anon:70712kB active_file:125844kB inactive_file:876364kB unevictable
Feb 12 08:21:53 asrocke350m1 kernel: DMA free:3840kB min:788kB low:984kB 
high:1180kB active_anon:0kB inactive_anon:0kB active_file:0kB inactiv
Feb 12 08:21:53 asrocke350m1 kernel: lowmem_reserve[]: 0 763 7663 7663
Feb 12 08:21:53 asrocke350m1 kernel: Normal free:38764kB min:38828kB 
low:48532kB high:58236kB active_anon:0kB inactive_anon:0kB active_file:16
Feb 12 08:21:53 asrocke350m1 kernel: lowmem_reserve[]: 0 0 55201 55201
Feb 12 08:21:53 asrocke350m1 kernel: HighMem free:5483712kB min:512kB 
low:88240kB high:175968kB active_anon:479572kB inactive_anon:70712kB act
Feb 12 08:21:54 asrocke350m1 kernel: lowmem_reserve[]: 0 0 0 0
Feb 12 08:21:54 asrocke350m1 kernel: DMA: 0*4kB 42*8kB (UE) 69*16kB (UE) 7*32kB 
(UE) 10*64kB (UE) 2*128kB (U) 1*256kB (U) 2*512kB (U) 0*1024kB
Feb 12 08:21:54 asrocke350m1 kernel: Normal: 17*4kB (UME) 583*8kB (UME) 
1983*16kB (UE) 72*32kB (ME) 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*
Feb 12 08:21:54 asrocke350m1 kernel: HighMem: 2156*4kB (UM) 1334*8kB (UM) 
2760*16kB (UM) 2087*32kB (UM) 1274*64kB (UM) 491*128kB (UM) 234*256k
Feb 12 08:21:54 asrocke350m1 kernel: Node 0 hugepages_total=0 hugepages_free=0 
hugepages_surp=0 hugepages_size=2048kB
Feb 12 08:21:54 asrocke350m1 kernel: 256720 total pagecache pages
Feb 12 08:21:54 asrocke350m1 kernel: 0 pages in swap cache
Feb 12 08:21:54 asrocke350m1 kernel: Swap cache stats: add 0, delete 0, find 0/0
Feb 12 08:21:54 asrocke350m1 kernel: Free swap  = 4194300kB
Feb 12 08:21:54 asrocke350m1 kernel: Total swap = 4194300kB
Feb 12 08:21:54 asrocke350m1 kernel: 1994197 pages RAM
Feb 12 08:21:54 

Re: [PATCH] softirq: Prevent looping on disabled tasklets

[Chris Wilson]

On Sun, Feb 12, 2017 at 02:00:19PM +, Chris Wilson wrote:
> Disabling a tasklet causes it not to run during tasklet_action, but is
> put back onto the runnable tasklet list, and a new softirq raised. As
> the softirq is raised from within __do_softirq() this causing
> __do_softirq() to loop constantly until its timeslice expires and is
> transferred to the ksoftirq thread. ksoftirq then permanently spins,
> as on each action, the disabled tasklet keeps reraising the softirq.
> 
> Break this vicious cycle by moving the softirq from the action to the
> final tasklet_enable().
> 
> This behaviour appears to be historic (since the first git import).
> However, the looping until timeslice duration (to a max of 2ms) was
> first introduced in commit c10d73671ad3 ("softirq: reduce latencies"),
> with the restart limit restored in commit 34376a50fb1f ("Fix lockup
> related to stop_machine being stuck in __do_softirq.")
> 
> Reported-by: Tvrtko Ursulin 
> Signed-off-by: Chris Wilson 
> Cc: Tvrtko Ursulin 
> Cc: Thomas Gleixner 
> Cc: Hannes Reinecke 
> Cc: Jens Axboe 
> Cc: Bjorn Helgaas 
> Cc: Alexander Potapenko 
> Cc: Chen Fan 
> Cc: Ingo Molnar 
> Cc: "Peter Zijlstra (Intel)" 
> Cc: Sebastian Andrzej Siewior 
> Cc: Johannes Thumshirn 
> Cc: Emese Revfy 
> Cc: Sagi Grimberg 
> Cc: Eric Dumazet 
> Cc: Tom Herbert 
> Cc: Ben Hutchings 
> ---
>  include/linux/interrupt.h | 7 +--
>  kernel/softirq.c  | 2 --
>  2 files changed, 5 insertions(+), 4 deletions(-)
> 
> diff --git a/include/linux/interrupt.h b/include/linux/interrupt.h
> index 53144e78a369..12750f00d00d 100644
> --- a/include/linux/interrupt.h
> +++ b/include/linux/interrupt.h
> @@ -613,8 +613,11 @@ static inline void tasklet_disable(struct tasklet_struct 
> *t)
>  
>  static inline void tasklet_enable(struct tasklet_struct *t)
>  {
> - smp_mb__before_atomic();
> - atomic_dec(>count);
> + if (!atomic_dec_and_test(>count))
> + return;
> +
> + if (test_bit(TASKLET_STATE_SCHED, >state))
> + raise_softirq(HI_SOFTIRQ | TASKLET_SOFTIRQ);

raise_softirq is not exported, so let's move tasklet_enable()
out-of-line and export that.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

Trying to understand OOM killer

[Paul Menzel]

Dear Linux folks,


since some time, at Linux 4.8, 4.9, and 4.10-rc6, the OOM kicks in on a
8 GB machine.

```
Feb 12 08:21:50 asrocke350m1 kernel: updatedb.mlocat invoked oom-killer: 
gfp_mask=0x16040d0(GFP_TEMPORARY|__GFP_COMP|__GFP_NOTRACK), nodemask=
Feb 12 08:21:50 asrocke350m1 kernel: updatedb.mlocat cpuset=/ mems_allowed=0
Feb 12 08:21:50 asrocke350m1 kernel: CPU: 1 PID: 2314 Comm: updatedb.mlocat 
Tainted: G C  4.10.0-rc6-686-pae #1 Debian 4.10~rc6-1~
Feb 12 08:21:50 asrocke350m1 kernel: Hardware name: ASROCK E350M1/E350M1, BIOS 
4.5-964-gd96669e9db 02/11/2017
Feb 12 08:21:51 asrocke350m1 kernel: Call Trace:
Feb 12 08:21:51 asrocke350m1 kernel:  ? dump_stack+0x55/0x73
Feb 12 08:21:51 asrocke350m1 kernel:  ? dump_header+0x64/0x1ab
Feb 12 08:21:52 asrocke350m1 kernel:  ? ___ratelimit+0x9f/0x100
Feb 12 08:21:52 asrocke350m1 kernel:  ? oom_kill_process+0x221/0x3e0
Feb 12 08:21:52 asrocke350m1 kernel:  ? has_capability_noaudit+0x1a/0x30
Feb 12 08:21:52 asrocke350m1 kernel:  ? oom_badness.part.13+0xd7/0x150
Feb 12 08:21:52 asrocke350m1 kernel:  ? out_of_memory+0xe4/0x290
Feb 12 08:21:52 asrocke350m1 kernel:  ? __alloc_pages_nodemask+0xab8/0xbc0
Feb 12 08:21:52 asrocke350m1 kernel:  ? xfs_init_local_fork+0x8a/0xd0 [xfs]
Feb 12 08:21:52 asrocke350m1 kernel:  ? cache_grow_begin.isra.60+0x75/0x510
Feb 12 08:21:52 asrocke350m1 kernel:  ? xfs_buf_rele+0x43/0x2e0 [xfs]
Feb 12 08:21:52 asrocke350m1 kernel:  ? kmem_cache_alloc+0x1fa/0x530
Feb 12 08:21:52 asrocke350m1 kernel:  ? __d_alloc+0x23/0x180
Feb 12 08:21:52 asrocke350m1 kernel:  ? d_alloc+0x18/0x80
Feb 12 08:21:52 asrocke350m1 kernel:  ? d_alloc_parallel+0x47/0x450
Feb 12 08:21:52 asrocke350m1 kernel:  ? d_splice_alias+0x10d/0x3a0
Feb 12 08:21:53 asrocke350m1 kernel:  ? lockref_get_not_dead+0x8/0x40
Feb 12 08:21:53 asrocke350m1 kernel:  ? unlazy_walk+0xf9/0x1a0
Feb 12 08:21:53 asrocke350m1 kernel:  ? lookup_slow+0x5e/0x140
Feb 12 08:21:53 asrocke350m1 kernel:  ? walk_component+0x1b4/0x350
Feb 12 08:21:53 asrocke350m1 kernel:  ? path_lookupat+0x49/0xe0
Feb 12 08:21:53 asrocke350m1 kernel:  ? filename_lookup+0x99/0x190
Feb 12 08:21:53 asrocke350m1 kernel:  ? __check_object_size+0x9e/0x11c
Feb 12 08:21:53 asrocke350m1 kernel:  ? strncpy_from_user+0x39/0x140
Feb 12 08:21:53 asrocke350m1 kernel:  ? getname_flags+0x55/0x1a0
Feb 12 08:21:53 asrocke350m1 kernel:  ? vfs_fstatat+0x60/0xb0
Feb 12 08:21:53 asrocke350m1 kernel:  ? SyS_lstat64+0x2d/0x50
Feb 12 08:21:53 asrocke350m1 kernel:  ? sys_sync+0x9d/0xa0
Feb 12 08:21:53 asrocke350m1 kernel:  ? SyS_poll+0x6b/0x110
Feb 12 08:21:53 asrocke350m1 kernel:  ? do_fast_syscall_32+0x8a/0x150
Feb 12 08:21:53 asrocke350m1 kernel:  ? entry_SYSENTER_32+0x4e/0x7c
Feb 12 08:21:53 asrocke350m1 kernel: Mem-Info:
Feb 12 08:21:53 asrocke350m1 kernel: active_anon:119893 inactive_anon:17678 
isolated_anon:0
active_file:31461 inactive_file:219091 
isolated_file:0
unevictable:21 dirty:0 writeback:0 
unstable:0
slab_reclaimable:127609 
slab_unreclaimable:9519
mapped:63113 shmem:6177 pagetables:1601 
bounce:0
free:1381579 free_pcp:583 free_cma:0
Feb 12 08:21:53 asrocke350m1 kernel: Node 0 active_anon:479572kB 
inactive_anon:70712kB active_file:125844kB inactive_file:876364kB unevictable
Feb 12 08:21:53 asrocke350m1 kernel: DMA free:3840kB min:788kB low:984kB 
high:1180kB active_anon:0kB inactive_anon:0kB active_file:0kB inactiv
Feb 12 08:21:53 asrocke350m1 kernel: lowmem_reserve[]: 0 763 7663 7663
Feb 12 08:21:53 asrocke350m1 kernel: Normal free:38764kB min:38828kB 
low:48532kB high:58236kB active_anon:0kB inactive_anon:0kB active_file:16
Feb 12 08:21:53 asrocke350m1 kernel: lowmem_reserve[]: 0 0 55201 55201
Feb 12 08:21:53 asrocke350m1 kernel: HighMem free:5483712kB min:512kB 
low:88240kB high:175968kB active_anon:479572kB inactive_anon:70712kB act
Feb 12 08:21:54 asrocke350m1 kernel: lowmem_reserve[]: 0 0 0 0
Feb 12 08:21:54 asrocke350m1 kernel: DMA: 0*4kB 42*8kB (UE) 69*16kB (UE) 7*32kB 
(UE) 10*64kB (UE) 2*128kB (U) 1*256kB (U) 2*512kB (U) 0*1024kB
Feb 12 08:21:54 asrocke350m1 kernel: Normal: 17*4kB (UME) 583*8kB (UME) 
1983*16kB (UE) 72*32kB (ME) 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*
Feb 12 08:21:54 asrocke350m1 kernel: HighMem: 2156*4kB (UM) 1334*8kB (UM) 
2760*16kB (UM) 2087*32kB (UM) 1274*64kB (UM) 491*128kB (UM) 234*256k
Feb 12 08:21:54 asrocke350m1 kernel: Node 0 hugepages_total=0 hugepages_free=0 
hugepages_surp=0 hugepages_size=2048kB
Feb 12 08:21:54 asrocke350m1 kernel: 256720 total pagecache pages
Feb 12 08:21:54 asrocke350m1 kernel: 0 pages in swap cache
Feb 12 08:21:54 asrocke350m1 kernel: Swap cache stats: add 0, delete 0, find 0/0
Feb 12 08:21:54 asrocke350m1 kernel: Free swap  = 4194300kB
Feb 12 08:21:54 asrocke350m1 kernel: Total swap = 4194300kB
Feb 12 08:21:54 asrocke350m1 kernel: 1994197 pages RAM
Feb 12 08:21:54 

Re: [PATCH] x86/vm86: fix compilation warning on a unused variable

[Borislav Petkov]

On Fri, Dec 16, 2016 at 11:19:16PM -0500, Jérémy Lefaure wrote:
> I don't know why gcc raises a warning on that even if it is not used.
> Anyway, I'm sure that the warning is reproducible. Both of your
> solutions fix the issue.

I still see the warning here. You wanna choose one solution, write a
proper patch and send it out?

-- 
Regards/Gruss,
Boris.

SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 
(AG Nürnberg)
-- 

Re: [PATCH] x86/vm86: fix compilation warning on a unused variable

[Borislav Petkov]

On Fri, Dec 16, 2016 at 11:19:16PM -0500, Jérémy Lefaure wrote:
> I don't know why gcc raises a warning on that even if it is not used.
> Anyway, I'm sure that the warning is reproducible. Both of your
> solutions fix the issue.

I still see the warning here. You wanna choose one solution, write a
proper patch and send it out?

-- 
Regards/Gruss,
Boris.

SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 
(AG Nürnberg)
-- 

[PATCH] softirq: Prevent looping on disabled tasklets

[Chris Wilson]

Disabling a tasklet causes it not to run during tasklet_action, but is
put back onto the runnable tasklet list, and a new softirq raised. As
the softirq is raised from within __do_softirq() this causing
__do_softirq() to loop constantly until its timeslice expires and is
transferred to the ksoftirq thread. ksoftirq then permanently spins,
as on each action, the disabled tasklet keeps reraising the softirq.

Break this vicious cycle by moving the softirq from the action to the
final tasklet_enable().

This behaviour appears to be historic (since the first git import).
However, the looping until timeslice duration (to a max of 2ms) was
first introduced in commit c10d73671ad3 ("softirq: reduce latencies"),
with the restart limit restored in commit 34376a50fb1f ("Fix lockup
related to stop_machine being stuck in __do_softirq.")

Reported-by: Tvrtko Ursulin 
Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
Cc: Thomas Gleixner 
Cc: Hannes Reinecke 
Cc: Jens Axboe 
Cc: Bjorn Helgaas 
Cc: Alexander Potapenko 
Cc: Chen Fan 
Cc: Ingo Molnar 
Cc: "Peter Zijlstra (Intel)" 
Cc: Sebastian Andrzej Siewior 
Cc: Johannes Thumshirn 
Cc: Emese Revfy 
Cc: Sagi Grimberg 
Cc: Eric Dumazet 
Cc: Tom Herbert 
Cc: Ben Hutchings 
---
 include/linux/interrupt.h | 7 +--
 kernel/softirq.c  | 2 --
 2 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/include/linux/interrupt.h b/include/linux/interrupt.h
index 53144e78a369..12750f00d00d 100644
--- a/include/linux/interrupt.h
+++ b/include/linux/interrupt.h
@@ -613,8 +613,11 @@ static inline void tasklet_disable(struct tasklet_struct 
*t)
 
 static inline void tasklet_enable(struct tasklet_struct *t)
 {
-   smp_mb__before_atomic();
-   atomic_dec(>count);
+   if (!atomic_dec_and_test(>count))
+   return;
+
+   if (test_bit(TASKLET_STATE_SCHED, >state))
+   raise_softirq(HI_SOFTIRQ | TASKLET_SOFTIRQ);
 }
 
 extern void tasklet_kill(struct tasklet_struct *t);
diff --git a/kernel/softirq.c b/kernel/softirq.c
index 744fa611cae0..5a359eb1a541 100644
--- a/kernel/softirq.c
+++ b/kernel/softirq.c
@@ -527,7 +527,6 @@ static __latent_entropy void tasklet_action(struct 
softirq_action *a)
t->next = NULL;
*__this_cpu_read(tasklet_vec.tail) = t;
__this_cpu_write(tasklet_vec.tail, &(t->next));
-   __raise_softirq_irqoff(TASKLET_SOFTIRQ);
local_irq_enable();
}
 }
@@ -563,7 +562,6 @@ static __latent_entropy void tasklet_hi_action(struct 
softirq_action *a)
t->next = NULL;
*__this_cpu_read(tasklet_hi_vec.tail) = t;
__this_cpu_write(tasklet_hi_vec.tail, &(t->next));
-   __raise_softirq_irqoff(HI_SOFTIRQ);
local_irq_enable();
}
 }
-- 
2.11.0

[PATCH] softirq: Prevent looping on disabled tasklets

[Chris Wilson]

Disabling a tasklet causes it not to run during tasklet_action, but is
put back onto the runnable tasklet list, and a new softirq raised. As
the softirq is raised from within __do_softirq() this causing
__do_softirq() to loop constantly until its timeslice expires and is
transferred to the ksoftirq thread. ksoftirq then permanently spins,
as on each action, the disabled tasklet keeps reraising the softirq.

Break this vicious cycle by moving the softirq from the action to the
final tasklet_enable().

This behaviour appears to be historic (since the first git import).
However, the looping until timeslice duration (to a max of 2ms) was
first introduced in commit c10d73671ad3 ("softirq: reduce latencies"),
with the restart limit restored in commit 34376a50fb1f ("Fix lockup
related to stop_machine being stuck in __do_softirq.")

Reported-by: Tvrtko Ursulin 
Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
Cc: Thomas Gleixner 
Cc: Hannes Reinecke 
Cc: Jens Axboe 
Cc: Bjorn Helgaas 
Cc: Alexander Potapenko 
Cc: Chen Fan 
Cc: Ingo Molnar 
Cc: "Peter Zijlstra (Intel)" 
Cc: Sebastian Andrzej Siewior 
Cc: Johannes Thumshirn 
Cc: Emese Revfy 
Cc: Sagi Grimberg 
Cc: Eric Dumazet 
Cc: Tom Herbert 
Cc: Ben Hutchings 
---
 include/linux/interrupt.h | 7 +--
 kernel/softirq.c  | 2 --
 2 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/include/linux/interrupt.h b/include/linux/interrupt.h
index 53144e78a369..12750f00d00d 100644
--- a/include/linux/interrupt.h
+++ b/include/linux/interrupt.h
@@ -613,8 +613,11 @@ static inline void tasklet_disable(struct tasklet_struct 
*t)
 
 static inline void tasklet_enable(struct tasklet_struct *t)
 {
-   smp_mb__before_atomic();
-   atomic_dec(>count);
+   if (!atomic_dec_and_test(>count))
+   return;
+
+   if (test_bit(TASKLET_STATE_SCHED, >state))
+   raise_softirq(HI_SOFTIRQ | TASKLET_SOFTIRQ);
 }
 
 extern void tasklet_kill(struct tasklet_struct *t);
diff --git a/kernel/softirq.c b/kernel/softirq.c
index 744fa611cae0..5a359eb1a541 100644
--- a/kernel/softirq.c
+++ b/kernel/softirq.c
@@ -527,7 +527,6 @@ static __latent_entropy void tasklet_action(struct 
softirq_action *a)
t->next = NULL;
*__this_cpu_read(tasklet_vec.tail) = t;
__this_cpu_write(tasklet_vec.tail, &(t->next));
-   __raise_softirq_irqoff(TASKLET_SOFTIRQ);
local_irq_enable();
}
 }
@@ -563,7 +562,6 @@ static __latent_entropy void tasklet_hi_action(struct 
softirq_action *a)
t->next = NULL;
*__this_cpu_read(tasklet_hi_vec.tail) = t;
__this_cpu_write(tasklet_hi_vec.tail, &(t->next));
-   __raise_softirq_irqoff(HI_SOFTIRQ);
local_irq_enable();
}
 }
-- 
2.11.0

Re: [PATCH v4 1/7] drm: Add DRM support for tiny LCD displays

[Noralf Trønnes]

Den 12.02.2017 12.05, skrev Andy Shevchenko:

On Sat, Feb 11, 2017 at 8:48 PM, Noralf Trønnes  wrote:

tinydrm provides helpers for very simple displays that can use
CMA backed framebuffers and need flushing on changes.
+/**
+ * tinydrm_gem_cma_free_object - Free resources associated with a CMA GEM
+ *   object

Keep on one line?


That means 81 columns and checkpatch complaint.
This in one of the annoying things about Linux
kernel coding. Always trying
to avoid
breaking up lines.
Because for me it hinders redability.


+const struct file_operations tinydrm_fops = {
+   .owner  = THIS_MODULE,

Do we still need this?


Looks like it, see drm_stub_open()


+static int tinydrm_init(struct device *parent, struct tinydrm_device *tdev,
+   const struct drm_framebuffer_funcs *fb_funcs,
+   struct drm_driver *driver)
+{
+   struct drm_device *drm;
+
+   mutex_init(>dirty_lock);
+   tdev->fb_funcs = fb_funcs;
+
+   /*
+* We don't embed drm_device, because that prevent us from using
+* devm_kzalloc() to allocate tinydrm_device in the driver since
+* drm_dev_unref() frees the structure. The devm_ functions provide

"devm_ functions" -> "devm_kzalloc()" ?

Otherwise what else do you refer to and why here?


yes, that last sentence can be dropped.


+* for easy error handling.
+*/
+static int tinydrm_register(struct tinydrm_device *tdev)
+{
+   struct drm_device *drm = tdev->drm;
+   int bpp = drm->mode_config.preferred_depth;
+   struct drm_fbdev_cma *fbdev;
+   int ret;
+
+   ret = drm_dev_register(tdev->drm, 0);
+   if (ret)
+   return ret;
+
+   fbdev = drm_fbdev_cma_init_with_funcs(drm, bpp ? bpp : 32,
+ drm->mode_config.num_connector,
+ tdev->fb_funcs);
+   if (IS_ERR(fbdev))
+   DRM_ERROR("Failed to initialize fbdev: %ld\n", PTR_ERR(fbdev));
+   else
+   tdev->fbdev_cma = fbdev;

Apparently I missed previous round of reviews, can you just put in
short words why error is not propagated here to the caller?


A comment might have helped here:
/* fbdev is of minor importance, don't let it stop us */


+
+   return 0;
+}
+/**
+ * tinydrm_display_pipe_init - Initialize display pipe
+ * @tdev: tinydrm device
+ * @funcs: Display pipe functions
+ * @connector_type: Connector type
+ * @formats: Array of supported formats (DRM_FORMAT\_\*)

DRM_FORMAT_* ?


sphinx wants it that way.


+ * @format_count: Number of elements in @formats
+ * @mode: Supported mode
+ * @rotation: Initial @mode rotation in degrees Counter Clock Wise
+ *
+ * This function sets up a _simple_display_pipe with a _connector that
+ * has one fixed _display_mode which is rotated according to @rotation.
+ *
+ * Returns:
+ * Zero on success, negative error code on failure.
+ */
+{
+   struct drm_device *drm = tdev->drm;
+   struct drm_display_mode *mode_copy;
+   struct drm_connector *connector;
+   int ret;
+   connector = tinydrm_connector_create(drm, mode_copy, connector_type);
+   if (IS_ERR(connector))
+   return PTR_ERR(connector);
+
+   ret = drm_simple_display_pipe_init(drm, >pipe, funcs, formats,
+  format_count, connector);
+   if (ret)
+   return ret;
+
+   return 0;

return drm_... ?


Yep.


tinydrm will be merged the way it is now, unless someone points to
something that is broken. But I collect your comments for a later
cleanup patchset. It takes a lot of effort for me as an amateur to
keeps this code up-to-date out-of-tree for months. It's not even
sure that I've hit the mark with this, so there will most likely be
changes when I start converting fbtft drivers, and I'll implement the
remaining bits and pieces as I make changes. The core of tinydrm won't
change because of unforseen fbtft quirks, but other parts might.


Noralf.


+}
+EXPORT_SYMBOL(tinydrm_display_pipe_init);

Re: [PATCH v4 1/7] drm: Add DRM support for tiny LCD displays

[Noralf Trønnes]

Den 12.02.2017 12.05, skrev Andy Shevchenko:

On Sat, Feb 11, 2017 at 8:48 PM, Noralf Trønnes  wrote:

tinydrm provides helpers for very simple displays that can use
CMA backed framebuffers and need flushing on changes.
+/**
+ * tinydrm_gem_cma_free_object - Free resources associated with a CMA GEM
+ *   object

Keep on one line?


That means 81 columns and checkpatch complaint.
This in one of the annoying things about Linux
kernel coding. Always trying
to avoid
breaking up lines.
Because for me it hinders redability.


+const struct file_operations tinydrm_fops = {
+   .owner  = THIS_MODULE,

Do we still need this?


Looks like it, see drm_stub_open()


+static int tinydrm_init(struct device *parent, struct tinydrm_device *tdev,
+   const struct drm_framebuffer_funcs *fb_funcs,
+   struct drm_driver *driver)
+{
+   struct drm_device *drm;
+
+   mutex_init(>dirty_lock);
+   tdev->fb_funcs = fb_funcs;
+
+   /*
+* We don't embed drm_device, because that prevent us from using
+* devm_kzalloc() to allocate tinydrm_device in the driver since
+* drm_dev_unref() frees the structure. The devm_ functions provide

"devm_ functions" -> "devm_kzalloc()" ?

Otherwise what else do you refer to and why here?


yes, that last sentence can be dropped.


+* for easy error handling.
+*/
+static int tinydrm_register(struct tinydrm_device *tdev)
+{
+   struct drm_device *drm = tdev->drm;
+   int bpp = drm->mode_config.preferred_depth;
+   struct drm_fbdev_cma *fbdev;
+   int ret;
+
+   ret = drm_dev_register(tdev->drm, 0);
+   if (ret)
+   return ret;
+
+   fbdev = drm_fbdev_cma_init_with_funcs(drm, bpp ? bpp : 32,
+ drm->mode_config.num_connector,
+ tdev->fb_funcs);
+   if (IS_ERR(fbdev))
+   DRM_ERROR("Failed to initialize fbdev: %ld\n", PTR_ERR(fbdev));
+   else
+   tdev->fbdev_cma = fbdev;

Apparently I missed previous round of reviews, can you just put in
short words why error is not propagated here to the caller?


A comment might have helped here:
/* fbdev is of minor importance, don't let it stop us */


+
+   return 0;
+}
+/**
+ * tinydrm_display_pipe_init - Initialize display pipe
+ * @tdev: tinydrm device
+ * @funcs: Display pipe functions
+ * @connector_type: Connector type
+ * @formats: Array of supported formats (DRM_FORMAT\_\*)

DRM_FORMAT_* ?


sphinx wants it that way.


+ * @format_count: Number of elements in @formats
+ * @mode: Supported mode
+ * @rotation: Initial @mode rotation in degrees Counter Clock Wise
+ *
+ * This function sets up a _simple_display_pipe with a _connector that
+ * has one fixed _display_mode which is rotated according to @rotation.
+ *
+ * Returns:
+ * Zero on success, negative error code on failure.
+ */
+{
+   struct drm_device *drm = tdev->drm;
+   struct drm_display_mode *mode_copy;
+   struct drm_connector *connector;
+   int ret;
+   connector = tinydrm_connector_create(drm, mode_copy, connector_type);
+   if (IS_ERR(connector))
+   return PTR_ERR(connector);
+
+   ret = drm_simple_display_pipe_init(drm, >pipe, funcs, formats,
+  format_count, connector);
+   if (ret)
+   return ret;
+
+   return 0;

return drm_... ?


Yep.


tinydrm will be merged the way it is now, unless someone points to
something that is broken. But I collect your comments for a later
cleanup patchset. It takes a lot of effort for me as an amateur to
keeps this code up-to-date out-of-tree for months. It's not even
sure that I've hit the mark with this, so there will most likely be
changes when I start converting fbtft drivers, and I'll implement the
remaining bits and pieces as I make changes. The core of tinydrm won't
change because of unforseen fbtft quirks, but other parts might.


Noralf.


+}
+EXPORT_SYMBOL(tinydrm_display_pipe_init);