[PATCH v2 10/11] x86/mm: Be more consistent wrt PAGE_SHIFT vs PAGE_SIZE in tlb flush code

[Andy Lutomirski]

Nadav pointed out that some code used PAGE_SIZE and other code used
PAGE_SHIFT.  Use PAGE_SHIFT instead of multiplying or dividing by
PAGE_SIZE.

Requested-by: Nadav Amit 
Cc: Rik van Riel 
Cc: Dave Hansen 
Cc: Nadav Amit 
Cc: Michal Hocko 
Cc: Arjan van de Ven 
Cc: Andrew Morton 
Signed-off-by: Andy Lutomirski 
---
 arch/x86/mm/tlb.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/arch/x86/mm/tlb.c b/arch/x86/mm/tlb.c
index 4bfadb869a1e..20659edd9347 100644
--- a/arch/x86/mm/tlb.c
+++ b/arch/x86/mm/tlb.c
@@ -220,8 +220,7 @@ static void flush_tlb_func_common(const struct 
flush_tlb_info *f,
trace_tlb_flush(reason, TLB_FLUSH_ALL);
} else {
unsigned long addr;
-   unsigned long nr_pages =
-   (f->end - f->start) / PAGE_SIZE;
+   unsigned long nr_pages = (f->end - f->start) >> PAGE_SHIFT;
addr = f->start;
while (addr < f->end) {
__flush_tlb_single(addr);
@@ -351,7 +350,7 @@ void flush_tlb_kernel_range(unsigned long start, unsigned 
long end)
 
/* Balance as user space task's flush, a bit conservative */
if (end == TLB_FLUSH_ALL ||
-   (end - start) > tlb_single_page_flush_ceiling * PAGE_SIZE) {
+   (end - start) > tlb_single_page_flush_ceiling >> PAGE_SHIFT) {
on_each_cpu(do_flush_tlb_all, NULL, 1);
} else {
struct flush_tlb_info info;
-- 
2.9.3

Re: [PATCH] CodingStyle: delete "kmalloc(sizeof(*var))" as preferred allocation form

[Joe Perches]

On Mon, 2017-05-22 at 15:22 -0700, Andrew Morton wrote:
> On Mon, 22 May 2017 14:43:18 -0700 Joe Perches  wrote:
> > On Tue, 2017-05-23 at 00:38 +0300, Alexey Dobriyan wrote:
> > > * ratio of allocation styles is ~6400:12000 which is about 1:2
> > >   so the amount of churn to maintain this rule is pretty high in theory.

I got:

$ git grep -E "alloc.*\bsizeof\s*\(\s*[^\*]" | wc -l
8114
$ git grep -E "alloc.*\bsizeof\s*\(\s*[\*]" | wc -l
12198

> > > -The preferred form for passing a size of a struct is the following:
> > > -
> > > -.. code-block:: c
> > > -
> > > - p = kmalloc(sizeof(*p), ...);
> > > -
> > > -The alternative form where struct name is spelled out hurts readability 
> > > and
> > > -introduces an opportunity for a bug when the pointer variable type is 
> > > changed
> > > -but the corresponding sizeof that is passed to a memory allocator is not.
> > > -
> > 
> > Thanks.  I agree with this deletion.
> 
> I don't.  Every damn time I see a p = kmalloc(sizeof struct foo) I have
> to hunt around to check the type of p.  And I review a lot of code!

Yeah, I read a lot of patches with you.
But there are real reasons to use sizeof(type) too.
And changing existing uses is pretty pointless.

[PATCH] usb: typec: Add a sysfs node to manage port type

[Badhri Jagan Sridharan]

User space applications in some cases have the need to enforce a
specific port type(DFP/UFP/DRP). This change allows userspace to
attempt setting the desired port type. Low level drivers can
however reject the request if the specific port type is not supported.

Signed-off-by: Badhri Jagan Sridharan 
---
 Documentation/ABI/testing/sysfs-class-typec | 13 ++
 drivers/usb/typec/typec.c   | 40 +
 include/linux/usb/typec.h   |  4 +++
 3 files changed, 57 insertions(+)

diff --git a/Documentation/ABI/testing/sysfs-class-typec 
b/Documentation/ABI/testing/sysfs-class-typec
index d4a3d23eb09c..853b2ef73641 100644
--- a/Documentation/ABI/testing/sysfs-class-typec
+++ b/Documentation/ABI/testing/sysfs-class-typec
@@ -73,6 +73,19 @@ Description:
 
Valid values: source, sink, none (to remove preference)
 
+What:   /sys/class/typec//port_type
+Date:   May 2017
+Description:
+   Indicates the type of the port. This attribute can be used for
+   requesting a change in the port type. Port type change is
+   supported as a synchronous operation, so write(2) to the
+   attribute will not return until the operation has finished.
+
+   Valid values:
+   - DRP
+   - DFP
+   - UFP
+
 What:  /sys/class/typec//supported_accessory_modes
 Date:  April 2017
 Contact:   Heikki Krogerus 
diff --git a/drivers/usb/typec/typec.c b/drivers/usb/typec/typec.c
index 89e540bb7ff3..684a13bb744d 100644
--- a/drivers/usb/typec/typec.c
+++ b/drivers/usb/typec/typec.c
@@ -789,6 +789,12 @@ static const char * const typec_data_roles[] = {
[TYPEC_HOST]= "host",
 };
 
+static const char * const typec_port_types[] = {
+   [TYPEC_PORT_DFP] = "dfp",
+   [TYPEC_PORT_UFP] = "ufp",
+   [TYPEC_PORT_DRP] = "drp",
+};
+
 static ssize_t
 preferred_role_store(struct device *dev, struct device_attribute *attr,
 const char *buf, size_t size)
@@ -926,6 +932,39 @@ static ssize_t power_role_show(struct device *dev,
 }
 static DEVICE_ATTR_RW(power_role);
 
+static ssize_t
+port_type_store(struct device *dev, struct device_attribute *attr,
+   const char *buf, size_t size)
+{
+   struct typec_port *port = to_typec_port(dev);
+   int ret;
+
+   if (!port->cap->port_type_set) {
+   dev_dbg(dev, "changing port type not supported\n");
+   return -EOPNOTSUPP;
+   }
+
+   ret = sysfs_match_string(typec_port_types, buf);
+   if (ret < 0)
+   return ret;
+
+   ret = port->cap->port_type_set(port->cap, ret);
+   if (ret)
+   return ret;
+
+   return size;
+}
+
+static ssize_t
+port_type_show(struct device *dev, struct device_attribute *attr,
+   char *buf)
+{
+   struct typec_port *port = to_typec_port(dev);
+
+   return sprintf(buf, "%s\n", typec_port_types[port->cap->type]);
+}
+static DEVICE_ATTR_RW(port_type);
+
 static const char * const typec_pwr_opmodes[] = {
[TYPEC_PWR_MODE_USB]= "default",
[TYPEC_PWR_MODE_1_5A]   = "1.5A",
@@ -1035,6 +1074,7 @@ static struct attribute *typec_attrs[] = {
_attr_usb_power_delivery_revision.attr,
_attr_usb_typec_revision.attr,
_attr_vconn_source.attr,
+   _attr_port_type.attr,
NULL,
 };
 ATTRIBUTE_GROUPS(typec);
diff --git a/include/linux/usb/typec.h b/include/linux/usb/typec.h
index ec78204964ab..5badf6f66479 100644
--- a/include/linux/usb/typec.h
+++ b/include/linux/usb/typec.h
@@ -190,6 +190,7 @@ struct typec_partner_desc {
  * @pr_set: Set Power Role
  * @vconn_set: Set VCONN Role
  * @activate_mode: Enter/exit given Alternate Mode
+ * @port_type_set: Set port type
  *
  * Static capabilities of a single USB Type-C port.
  */
@@ -214,6 +215,9 @@ struct typec_capability {
 
int (*activate_mode)(const struct typec_capability *,
 int mode, int activate);
+
+   int (*port_type_set)(const struct typec_capability *,
+   enum typec_port_type);
 };
 
 /* Specific to try_role(). Indicates the user want's to clear the preference. 
*/
-- 
2.13.0.303.g4ebf302169-goog

Re: [PATCH] nvme: pci: Fix NULL dereference when resetting NVMe SSD

[Rakesh Pandit]

On Mon, May 22, 2017 at 06:04:20PM +0200, Christoph Hellwig wrote:
> On Mon, May 22, 2017 at 06:02:17PM +0200, Christoph Hellwig wrote:
> > On Mon, May 22, 2017 at 06:38:29PM +0300, Rakesh Pandit wrote:
> > > Just got to use the using the test box again and you are right that
> > > nvme_remove_dead_ctrl_work is getting called just before the NULL
> > > pointer dereference.
> > > 
> > > Here call trace to nvme_timeout which results in eventually call to
> > > nvme_reset when it wants to reset the controller (which races with
> > > ->reset_notify from PCI layer):
> > 
> > Does the patch below fix the issue for you?
> 
> Actually, it probably should be this one, but for you the effects
> are probably the same:
> 
> diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
> index b01bd5bba8e6..b61ad77dc322 100644
> --- a/drivers/pci/pci.c
> +++ b/drivers/pci/pci.c
> @@ -4275,11 +4275,13 @@ int pci_reset_function(struct pci_dev *dev)
>   if (rc)
>   return rc;
>  
> + pci_dev_lock(dev);
>   pci_dev_save_and_disable(dev);
>  
> - rc = pci_dev_reset(dev, 0);
> + rc = __pci_dev_reset(dev, 0);
>  
>   pci_dev_restore(dev);
> + pci_dev_unlock(dev);
>  
>   return rc;
>  }

Thanks, this patch fixes the reported issue for me.

Re: [HMM 08/15] mm/ZONE_DEVICE: special case put_page() for device private pages

[Hugh Dickins]

On Mon, 22 May 2017, Jerome Glisse wrote:
> On Mon, May 22, 2017 at 12:29:53PM -0700, Dan Williams wrote:
> > On Mon, May 22, 2017 at 9:51 AM, Jerome Glisse  wrote:
> > > A ZONE_DEVICE page that reach a refcount of 1 is free ie no longer
> > > have any user. For device private pages this is important to catch
> > > and thus we need to special case put_page() for this.
> > >
> > > Signed-off-by: Jerome Glisse 
> > > Cc: Kirill A. Shutemov 
> > > Cc: Dan Williams 
> > > Cc: Ross Zwisler 
> > > ---
> > >  include/linux/mm.h | 30 ++
> > >  kernel/memremap.c  |  1 -
> > >  2 files changed, 30 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/include/linux/mm.h b/include/linux/mm.h
> > > index a825dab..11f7bac 100644
> > > --- a/include/linux/mm.h
> > > +++ b/include/linux/mm.h
> > > @@ -23,6 +23,7 @@
> > >  #include 
> > >  #include 
> > >  #include 
> > > +#include 
> > >
> > >  struct mempolicy;
> > >  struct anon_vma;
> > > @@ -795,6 +796,20 @@ static inline bool is_device_private_page(const 
> > > struct page *page)
> > > return ((page_zonenum(page) == ZONE_DEVICE) &&
> > > (page->pgmap->type == MEMORY_DEVICE_PRIVATE));
> > >  }
> > > +
> > > +static inline void put_zone_device_private_page(struct page *page)
> > > +{
> > > +   int count = page_ref_dec_return(page);
> > > +
> > > +   /*
> > > +* If refcount is 1 then page is freed and refcount is stable as 
> > > nobody
> > > +* holds a reference on the page.
> > > +*/
> > > +   if (count == 1)
> > > +   page->pgmap->page_free(page, page->pgmap->data);
> > > +   else if (!count)
> > > +   __put_page(page);
> > > +}

Is there something else in this patchset that guarantees
that get_page_unless_zero() is never used on thse pages?
We have plenty of code that knows that refcount 0 is special:
having to know that refcount 1 may be special is worrying.

Hugh

> > >  #else
> > >  static inline bool is_zone_device_page(const struct page *page)
> > >  {
> > > @@ -805,6 +820,10 @@ static inline bool is_device_private_page(const 
> > > struct page *page)
> > >  {
> > > return false;
> > >  }
> > > +
> > > +static inline void put_zone_device_private_page(struct page *page)
> > > +{
> > > +}
> > >  #endif
> > >
> > >  static inline void get_page(struct page *page)
> > > @@ -822,6 +841,17 @@ static inline void put_page(struct page *page)
> > >  {
> > > page = compound_head(page);
> > >
> > > +   /*
> > > +* For private device pages we need to catch refcount transition 
> > > from
> > > +* 2 to 1, when refcount reach one it means the private device 
> > > page is
> > > +* free and we need to inform the device driver through callback. 
> > > See
> > > +* include/linux/memremap.h and HMM for details.
> > > +*/
> > > +   if (unlikely(is_device_private_page(page))) {
> > 
> > Since I presume HMM is a niche use case can we make this a
> > "static_branch_unlikely(_key) && is_device_private_page(page))"?
> > That way non-hmm platforms see minimal overhead.
> 
> Like i said in the cover letter i am bit anxious about doing for
> an inline function. I don't see any existing case for inline
> function and static key. Is that suppose to work ?
> 
> How widespread HMM use will be is hard to guess. Usual chicken
> and egg plus adoption thing. If GPGPU compte keeps growing and
> it seems it does then HMM likely gonna be enable and actively
> use for large chunk of those computer that have GPGPU workload.
> 
> I will test a static key of that branch and see if it explodes
> because put_page() is an inline function.
> 
> Cheers,
> Jerome

Re: [PATCH 3/3] mfd: twl: move header file out of I2C realm

[Jonathan Cameron]

On Mon, 22 May 2017 00:02:10 +0200
Wolfram Sang  wrote:

> include/linux/i2c is not for client devices. Move the header file to a
> more appropriate location.
> 
> Signed-off-by: Wolfram Sang 
> ---
>  arch/arm/mach-omap2/common.h| 2 +-
>  arch/arm/mach-omap2/omap_twl.c  | 2 +-
>  drivers/gpio/gpio-twl4030.c | 2 +-

>  drivers/iio/adc/twl4030-madc.c  | 2 +-
>  drivers/iio/adc/twl6030-gpadc.c | 2 +-
Acked-by: Jonathan Cameron 

Thanks,
>  drivers/input/keyboard/twl4030_keypad.c | 2 +-
>  drivers/input/misc/twl4030-pwrbutton.c  | 2 +-
>  drivers/input/misc/twl4030-vibra.c  | 2 +-
>  drivers/mfd/twl-core.c  | 6 +++---
>  drivers/mfd/twl4030-audio.c | 2 +-
>  drivers/mfd/twl4030-irq.c   | 2 +-
>  drivers/mfd/twl4030-power.c | 2 +-
>  drivers/mfd/twl6030-irq.c   | 2 +-
>  drivers/phy/phy-twl4030-usb.c   | 2 +-
>  drivers/power/supply/twl4030_charger.c  | 2 +-
>  drivers/pwm/pwm-twl-led.c   | 2 +-
>  drivers/pwm/pwm-twl.c   | 2 +-
>  drivers/regulator/twl-regulator.c   | 2 +-
>  drivers/regulator/twl6030-regulator.c   | 2 +-
>  drivers/rtc/rtc-twl.c   | 2 +-
>  drivers/usb/phy/phy-twl6030-usb.c   | 2 +-
>  drivers/video/backlight/pandora_bl.c| 2 +-
>  drivers/watchdog/twl4030_wdt.c  | 2 +-
>  include/linux/{i2c => mfd}/twl.h| 0
>  sound/soc/codecs/twl4030.c  | 2 +-
>  25 files changed, 26 insertions(+), 26 deletions(-)
>  rename include/linux/{i2c => mfd}/twl.h (100%)
> 
> diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h
> index 8cc6338fcb1288..b5ad7fcb80ed24 100644
> --- a/arch/arm/mach-omap2/common.h
> +++ b/arch/arm/mach-omap2/common.h
> @@ -29,7 +29,7 @@
>  #include 
>  #include 
>  #include 
> -#include 
> +#include 
>  #include 
>  #include 
>  #include 
> diff --git a/arch/arm/mach-omap2/omap_twl.c b/arch/arm/mach-omap2/omap_twl.c
> index 1346b3ab34a5e3..295124b248ae3f 100644
> --- a/arch/arm/mach-omap2/omap_twl.c
> +++ b/arch/arm/mach-omap2/omap_twl.c
> @@ -16,7 +16,7 @@
>  #include 
>  #include 
>  #include 
> -#include 
> +#include 
>  
>  #include "soc.h"
>  #include "voltage.h"
> diff --git a/drivers/gpio/gpio-twl4030.c b/drivers/gpio/gpio-twl4030.c
> index 24f388ed46d4c4..9b511df5450eb6 100644
> --- a/drivers/gpio/gpio-twl4030.c
> +++ b/drivers/gpio/gpio-twl4030.c
> @@ -35,7 +35,7 @@
>  #include 
>  #include 
>  
> -#include 
> +#include 
>  
>  /*
>   * The GPIO "subchip" supports 18 GPIOs which can be configured as
> diff --git a/drivers/iio/adc/twl4030-madc.c b/drivers/iio/adc/twl4030-madc.c
> index 0c74869a540ad3..5a64eda1652061 100644
> --- a/drivers/iio/adc/twl4030-madc.c
> +++ b/drivers/iio/adc/twl4030-madc.c
> @@ -35,7 +35,7 @@
>  #include 
>  #include 
>  #include 
> -#include 
> +#include 
>  #include 
>  #include 
>  #include 
> diff --git a/drivers/iio/adc/twl6030-gpadc.c b/drivers/iio/adc/twl6030-gpadc.c
> index becbb0aef232b9..bc0e60b9da452e 100644
> --- a/drivers/iio/adc/twl6030-gpadc.c
> +++ b/drivers/iio/adc/twl6030-gpadc.c
> @@ -33,7 +33,7 @@
>  #include 
>  #include 
>  #include 
> -#include 
> +#include 
>  #include 
>  #include 
>  
> diff --git a/drivers/input/keyboard/twl4030_keypad.c 
> b/drivers/input/keyboard/twl4030_keypad.c
> index 39e72b3219d8a4..f9f98ef1d98e3f 100644
> --- a/drivers/input/keyboard/twl4030_keypad.c
> +++ b/drivers/input/keyboard/twl4030_keypad.c
> @@ -30,7 +30,7 @@
>  #include 
>  #include 
>  #include 
> -#include 
> +#include 
>  #include 
>  #include 
>  
> diff --git a/drivers/input/misc/twl4030-pwrbutton.c 
> b/drivers/input/misc/twl4030-pwrbutton.c
> index 1c13005b228fa7..b307cca1702226 100644
> --- a/drivers/input/misc/twl4030-pwrbutton.c
> +++ b/drivers/input/misc/twl4030-pwrbutton.c
> @@ -27,7 +27,7 @@
>  #include 
>  #include 
>  #include 
> -#include 
> +#include 
>  
>  #define PWR_PWRON_IRQ (1 << 0)
>  
> diff --git a/drivers/input/misc/twl4030-vibra.c 
> b/drivers/input/misc/twl4030-vibra.c
> index caa5a62c42fbe0..6c51d404874bbd 100644
> --- a/drivers/input/misc/twl4030-vibra.c
> +++ b/drivers/input/misc/twl4030-vibra.c
> @@ -28,7 +28,7 @@
>  #include 
>  #include 
>  #include 
> -#include 
> +#include 
>  #include 
>  #include 
>  #include 
> diff --git a/drivers/mfd/twl-core.c b/drivers/mfd/twl-core.c
> index c64615dca2bd33..2a09dde4ca6efc 100644
> --- a/drivers/mfd/twl-core.c
> +++ b/drivers/mfd/twl-core.c
> @@ -44,7 +44,7 @@
>  #include 
>  
>  #include 
> -#include 
> +#include 
>  
>  /* Register descriptions for audio */
>  #include 
> @@ -173,7 +173,7 @@ static struct twl_private *twl_priv;
>  static struct twl_mapping twl4030_map[] = {
>   /*
>* NOTE:  don't change this table without updating the
> -  *  defines for TWL4030_MODULE_*
> +  *  defines for TWL4030_MODULE_*
>* so they continue to match the order in this 

Re: [PULL REQUEST] i2c for 4.12

[Linus Torvalds]

On Mon, May 22, 2017 at 1:28 PM, Linus Torvalds
 wrote:
>
> Have not tested that commit, but did verify that yes it was the i2c
> pull, and am about to reboot into a kernel that just zeroes those
> variables beforehand (which seems to be the same thing that commit
> does, although it also moves lines around for some unfathomable
> reason).

Confirmed. Initializing those fields to zero fixes it.

   Linus

Re: [PATCH 0/1] x86/cqm: Cqm3 Design Documentation

[Shivappa Vikas]

On Mon, 22 May 2017, Thomas Gleixner wrote:


On Mon, 17 Apr 2017, Shivappa Vikas wrote:



Hello Thomas,

Wanted to know if you had any feedback on the new interface for cqm design
which is based on monitoring the resctrl groups. It tries to address all the
requirements discussed in :

https://marc.info/?l=linux-kernel=148891934720489

-basically to monitor resctrl groups / per thread including kernel threads.
-monitor thread from creation (also a child thread forked belongs to same
group like its parent)
-monitor subset of tasks in a resctrl group.
-monitor subset of cpus in a resctrl group.
-monitor different events (however the first version only shows llc_occupancy)
-monitor all domains and show per domain data.

I have a patch series but was thinking to send after the design document is
reviewed so that its easy to review and I can make changes that are discussed
here.


Send it along. This looks sane. I've wanted to reply long ago, but forgot
about it again. Sorry for the delay.


Ok - will do , Expecting to send by next week or so..

Thanks,
Vikas



Thanks,

tglx

[PATCH] arch: blackfin: kernel: bfin_gpio: Use strlcpy to Copy a C-string into a sized buffer

[Karim Eshapa]

Use strlcpy with sized buffer instead of strncpy to
avoid non NUL-terminated source strings problems.

Signed-off-by: Karim Eshapa 
---
 arch/blackfin/kernel/bfin_gpio.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/blackfin/kernel/bfin_gpio.c b/arch/blackfin/kernel/bfin_gpio.c
index c5d3128..49fca59 100644
--- a/arch/blackfin/kernel/bfin_gpio.c
+++ b/arch/blackfin/kernel/bfin_gpio.c
@@ -119,7 +119,7 @@ static void gpio_error(unsigned gpio)
 static void set_label(unsigned short ident, const char *label)
 {
if (label) {
-   strncpy(str_ident[ident].name, label,
+   strlcpy(str_ident[ident].name, label,
 RESOURCE_LABEL_SIZE);
str_ident[ident].name[RESOURCE_LABEL_SIZE - 1] = 0;
}
-- 
2.7.4

Re: [PATCH 2/4] dt-bindings: Document the Raspberry Pi Touchscreen nodes.

[Eric Anholt]

Laurent Pinchart  writes:

> Hi Eric,
>
> On Tuesday 16 May 2017 11:46:36 Eric Anholt wrote:
>
> [snip]
>
>> In terms of physical connections:
>> 
>>[15-pin "DSI" connector on 2835]
>> 
>> | I2C   | DSI
>>/ \SPI   |
>> [TS]  [Atmel]--[TC358762]
>>\|
>> \PWM|
>>  \  | DPI
>> [some backlight]--[some unknown panel]
>> 
>> The binding I'm trying to create is to expose what's necessary for a
>> driver that talks I2C to the Atmel, which then controls the PWM and does
>> the command sequence over SPI to the Toshiba that sets up its end of the
>> DSI link.
>
> According to the documentation I've been able to find, the TC358762 has an 
> SPI 
> master port through which it can output the commands DCS received from the 
> DSI 
> port, and an I2C slave port through which it can be configured by an external 
> device. If the connection between the microcontroller and the TC358762 is 
> indeed SPI and not I2C, I assume it's used by the microcontroller to receive 
> the DCS commands and perform control of the backlight (and possibly other 
> components) accordingly. By the way, is there any place where I can find a 
> leaked version of the non-public panel schematics ? ;-)

Not that I know of.

I don't know that you can control the backlight over DCS, given that I
have no docs.  We only send commands from Atmel to TC, not the other way
around.

> As far as I can tell from your patch series, you don't need to send any 
> command to the TC358762 over DSI. In that case I would model the panel in DT 
> as an I2C device, as all control goes through the I2C bus. The DSI video data 
> connection should then be modelled using the OF graph DT bindings. The result 
> will be a black box panel with a custom black box panel driver, using a 
> single 
> DT node. There's no need for a separate bridge instance. That's the cleanest 
> option I can come up with so far, and I agree that splitting TC358762 support 
> into a standalone bridge driver makes no sense in this case.

I agree, it's just that when I submitted to drm-panel I was told that it
didn't make sense as a single driver, so I went to all of this work
instead.


signature.asc
Description: PGP signature

Re: [PATCH 1/1] futex: remove duplicated code

[Thomas Gleixner]

On Mon, 15 May 2017, Will Deacon wrote:
> Hi Jiri,
> 
> On Mon, May 15, 2017 at 03:07:42PM +0200, Jiri Slaby wrote:
> > There is code duplicated over all architecture's headers for
> > futex_atomic_op_inuser. Namely op decoding, access_ok check for uaddr,
> > and comparison of the result.
> > 
> > Remove this duplication and leave up to the arches only the needed
> > assembly which is now in arch_futex_atomic_op_inuser.
> > 
> > Note that s390 removed access_ok check in d12a29703 ("s390/uaccess:
> > remove pointless access_ok() checks") as access_ok there returns true.
> > We introduce it back to the helper for the sake of simplicity (it gets
> > optimized away anyway).
> 
> Whilst I think this is a good idea, the code in question actually results
> in undefined behaviour per the C spec and is reported by UBSAN. See my
> patch fixing arm64 here (which I'd forgotten about):
> 
> https://www.spinics.net/lists/linux-arch/msg38564.html
> 
> But, as stated in the thread above, I think we should go a step further
> and remove FUTEX_OP_{OR,ANDN,XOR,OPARG_SHIFT} altogether. They don't
> appear to be used by userspace, and this whole thing is a total mess.

You wish. The constants are not used, but FUTEX_WAKE_OP _IS_ used by
glibc. They only have one argument it seems:

   #define FUTEX_OP_CLEAR_WAKE_IF_GT_ONE  ((4 << 24) | 1)

but I'm pretty sure that there is enough (probably horrible) code (think
java) out there using FUTEX_WAKE_OP for whatever (non)sensical reasons in
any available combination.

Thanks,

tglx

Re: linux-next: manual merge of the selinux tree with Linus' tree

[Daniel Jurgens]

On 5/22/2017 4:08 PM, Paul Moore wrote:
> On Sun, May 21, 2017 at 10:38 PM, Stephen Rothwell  
> wrote:
>> Hi Paul,
>>
>> Today's linux-next merge of the selinux tree got a conflict in:
>>
>>   include/rdma/ib_verbs.h
>>
>> between commit:
>>
>>   2fc775726491 ("IB/opa-vnic: RDMA NETDEV interface")
>>
>> from Linus' tree and commit:
>>
>>   89b54b4d09bd ("IB/core: Enforce PKey security on QPs")
>>
>> from the selinux tree.
>>
>> I fixed it up (see below) and can carry the fix as necessary. This
>> is now fixed as far as linux-next is concerned, but any non trivial
>> conflicts should be mentioned to your upstream maintainer when your tree
>> is submitted for merging.  You may also want to consider cooperating
>> with the maintainer of the conflicting tree to minimise any particularly
>> complex conflicts.
> Thanks Stephen.
>
> Daniel and Doug, does Stephen's patch look right to you?

Looks good to me.

>
>> diff --cc include/rdma/ib_verbs.h
>> index ba8314ec5768,c9e903fc824b..
>> --- a/include/rdma/ib_verbs.h
>> +++ b/include/rdma/ib_verbs.h
>> @@@ -1890,7 -1878,10 +1930,8 @@@ enum ib_mad_result
>> IB_MAD_RESULT_CONSUMED = 1 << 2  /* Packet consumed: stop processing 
>> */
>>   };
>>
>>  -#define IB_DEVICE_NAME_MAX 64
>>  -
>>   struct ib_port_cache {
>> +   u64   subnet_prefix;
>> struct ib_pkey_cache  *pkey;
>> struct ib_gid_table   *gid;
>> u8 lmc;
>> @@@ -1912,34 -1903,12 +1953,40 @@@ struct ib_port_immutable
>> u32   max_mad_size;
>>   };
>>
>>  +/* rdma netdev type - specifies protocol type */
>>  +enum rdma_netdev_t {
>>  +  RDMA_NETDEV_OPA_VNIC,
>>  +  RDMA_NETDEV_IPOIB,
>>  +};
>>  +
>>  +/**
>>  + * struct rdma_netdev - rdma netdev
>>  + * For cases where netstack interfacing is required.
>>  + */
>>  +struct rdma_netdev {
>>  +  void  *clnt_priv;
>>  +  struct ib_device  *hca;
>>  +  u8 port_num;
>>  +
>>  +  /* control functions */
>>  +  void (*set_id)(struct net_device *netdev, int id);
>>  +  /* send packet */
>>  +  int (*send)(struct net_device *dev, struct sk_buff *skb,
>>  +  struct ib_ah *address, u32 dqpn);
>>  +  /* multicast */
>>  +  int (*attach_mcast)(struct net_device *dev, struct ib_device *hca,
>>  +  union ib_gid *gid, u16 mlid,
>>  +  int set_qkey, u32 qkey);
>>  +  int (*detach_mcast)(struct net_device *dev, struct ib_device *hca,
>>  +  union ib_gid *gid, u16 mlid);
>>  +};
>>  +
>> + struct ib_port_pkey_list {
>> +   /* Lock to hold while modifying the list. */
>> +   spinlock_tlist_lock;
>> +   struct list_head  pkey_list;
>> + };
>> +
>>   struct ib_device {
>> /* Do not access @dma_device directly from ULP nor from HW drivers. 
>> */
>> struct device*dma_device;
>
>

Re: linux-next: build failure after merge of the selinux tree

[Paul Moore]

On Sun, May 21, 2017 at 10:48 PM, Stephen Rothwell  
wrote:
> Hi Paul,
>
> After merging the selinux tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
>
> drivers/infiniband/core/uverbs_cmd.c: In function 'create_qp':
> drivers/infiniband/core/uverbs_cmd.c:1513:4: error: label 'err_destroy' used 
> but not defined
> goto err_destroy;
> ^
>
> Caused by commit
>
>   89b54b4d09bd ("IB/core: Enforce PKey security on QPs")
>
> interacting with commit
>
>   fd3c7904db6e ("IB/core: Change idr objects to use the new schema")
>
> from Linus' tree.
>
> I have applied the following merge fix patch for today:
>
> From: Stephen Rothwell 
> Date: Mon, 22 May 2017 12:45:57 +1000
> Subject: [PATCH] IB/core: fix up for create_qp label changes
>
> Signed-off-by: Stephen Rothwell 
> ---
>  drivers/infiniband/core/uverbs_cmd.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Thanks Stephen, this looks right to me.

Daniel and Doug, does this look right to you?

> diff --git a/drivers/infiniband/core/uverbs_cmd.c 
> b/drivers/infiniband/core/uverbs_cmd.c
> index 558fd5204b32..0ad3b05405d8 100644
> --- a/drivers/infiniband/core/uverbs_cmd.c
> +++ b/drivers/infiniband/core/uverbs_cmd.c
> @@ -1510,7 +1510,7 @@ static int create_qp(struct ib_uverbs_file *file,
> if (cmd->qp_type != IB_QPT_XRC_TGT) {
> ret = ib_create_qp_security(qp, device);
> if (ret)
> -   goto err_destroy;
> +   goto err_cb;
>
> qp->real_qp   = qp;
> qp->device= device;
> --
> 2.11.0
>
> --
> Cheers,
> Stephen Rothwell



-- 
paul moore
www.paul-moore.com

[PATCH] mmc: block: fix semicolon.cocci warnings

[kbuild test robot]

drivers/mmc/core/block.c:1929:3-4: Unneeded semicolon


 Remove unneeded semicolon.

Generated by: scripts/coccinelle/misc/semicolon.cocci

CC: Linus Walleij 
Signed-off-by: Fengguang Wu 
---

 block.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/mmc/core/block.c
+++ b/drivers/mmc/core/block.c
@@ -1926,7 +1926,7 @@ void mmc_blk_issue_rq(struct mmc_queue *
mmc_blk_issue_rw_rq(mq, req);
card->host->context_info.is_waiting_last_req = false;
break;
-   };
+   }
} else {
/* No request, flushing the pipeline with NULL */
mmc_blk_issue_rw_rq(mq, NULL);

[PATCH v2 2/2] hw_random: timeriomem_rng: Allow setting RNG quality from platform data

[Rick Altherr]

When a hw_random device's quality is non-zero, it will automatically be
used to fill the kernel's entropy pool.  Since timeriomem_rng is used by
many different devices, the quality needs to be provided by platform
data or device tree.

Signed-off-by: Rick Altherr 
---

Changes in v2:
- Adjust header comment for platform data quality property to match code
and DT bindings

 drivers/char/hw_random/timeriomem-rng.c | 7 +++
 include/linux/timeriomem-rng.h  | 3 +++
 2 files changed, 10 insertions(+)

diff --git a/drivers/char/hw_random/timeriomem-rng.c 
b/drivers/char/hw_random/timeriomem-rng.c
index a0faa5f05deb..03ff5483d865 100644
--- a/drivers/char/hw_random/timeriomem-rng.c
+++ b/drivers/char/hw_random/timeriomem-rng.c
@@ -151,8 +151,15 @@ static int timeriomem_rng_probe(struct platform_device 
*pdev)
dev_err(>dev, "missing period\n");
return -EINVAL;
}
+
+   if (!of_property_read_u32(pdev->dev.of_node,
+   "quality", ))
+   priv->rng_ops.quality = i;
+   else
+   priv->rng_ops.quality = 0;
} else {
period = pdata->period;
+   priv->rng_ops.quality = pdata->quality;
}
 
priv->period = ns_to_ktime(period * NSEC_PER_USEC);
diff --git a/include/linux/timeriomem-rng.h b/include/linux/timeriomem-rng.h
index 46eb27ddbfab..3e00122bcf88 100644
--- a/include/linux/timeriomem-rng.h
+++ b/include/linux/timeriomem-rng.h
@@ -13,4 +13,7 @@ struct timeriomem_rng_data {
 
/* measures in usecs */
unsigned intperiod;
+
+   /* bits of entropy per 1024 bits read */
+   unsigned intquality;
 };
-- 
2.13.0.303.g4ebf302169-goog

Re: [PATCH] ocfs2: fix a static checker warning

[Andrew Morton]

On Mon, 22 May 2017 12:54:37 +0800 Gang He  wrote:

> This patch will fix a static checker warning, this warning was
> caused by commit d56a8f32e4c662509ce50a37e78fa66c777977d3. after
> apply this patch, the error return value will not be NULL(zero).

When identifying another commit, please use the form

d56a8f32e4c6 ("ocfs2: check/fix inode block for online file check")


And when fixing warnings such as this, please quote the warning in full
and identify which checker tool generated that warning.

Re: [PATCH v2 1/5] HID: intel_ish-hid: fix potential uninitialized data usage

[Arnd Bergmann]

On Mon, May 22, 2017 at 9:17 PM, Srinivas Pandruvada
 wrote:
> Hi Arnd,
> On Thu, 2017-05-18 at 22:21 +0200, Arnd Bergmann wrote:
>> gcc points out an uninialized pointer dereference that could happen
>> if we ever get to recv_ishtp_cl_msg_dma() or recv_ishtp_cl_msg()
>> with an empty >read_list:
>>
>> drivers/hid/intel-ish-hid/ishtp/client.c: In function
>> 'recv_ishtp_cl_msg_dma':
>> drivers/hid/intel-ish-hid/ishtp/client.c:1049:3: error: 'cl' may be
>> used uninitialized in this function [-Werror=maybe-uninitialized]
>>
>> The warning only appeared in very few randconfig builds, as the
>> spinlocks tend to prevent gcc from tracing the variables. I only
>> saw it in configurations that had neither SMP nor LOCKDEP enabled.
>>
>> As we can see, we only enter the case if 'complete_rb' is non-NULL,
>> and then 'cl' is known to point to complete_rb->cl. Adding another
>> initialization to the same pointer is harmless here and makes it
>> clear to the compiler that the behavior is well-defined.
>>
> Did you get chance to test these changes on a platform with ISH?

No, I only build-tested it and though about the fix carefully.

Arnd

Re: [PATCH 1/3] mm/slub: Only define kmalloc_large_node_hook() for NUMA systems

[Andrew Morton]

On Mon, 22 May 2017 13:56:21 -0700 Matthias Kaehlcke  wrote:

> El Mon, May 22, 2017 at 01:39:26PM -0700 David Rientjes ha dit:
> 
> > On Fri, 19 May 2017, Matthias Kaehlcke wrote:
> > 
> > > The function is only used when CONFIG_NUMA=y. Placing it in an #ifdef
> > > block fixes the following warning when building with clang:
> > > 
> > > mm/slub.c:1246:20: error: unused function 'kmalloc_large_node_hook'
> > > [-Werror,-Wunused-function]
> > > 
> > 
> > Is clang not inlining kmalloc_large_node_hook() for some reason?  I don't 
> > think this should ever warn on gcc.
> 
> clang warns about unused static inline functions outside of header
> files, in difference to gcc.

I wish it wouldn't.  These patches just add clutter.

RE: [PATCH 1/2] perf/x86/intel: enable CPU ref_cycles for GP counter

[Liang, Kan]

> 
> On Mon, May 22, 2017 at 12:23 PM, Peter Zijlstra 
> wrote:
> > On Mon, May 22, 2017 at 04:55:47PM +, Liang, Kan wrote:
> >>
> >>
> >> > On Fri, May 19, 2017 at 10:06:21AM -0700, kan.li...@intel.com wrote:
> >> > > diff --git a/arch/x86/events/core.c b/arch/x86/events/core.c
> >> > > index
> >> > > 580b60f..e8b2326 100644
> >> > > --- a/arch/x86/events/core.c
> >> > > +++ b/arch/x86/events/core.c
> >> > > @@ -101,6 +101,10 @@ u64 x86_perf_event_update(struct
> perf_event
> >> > *event)
> >> > >   delta = (new_raw_count << shift) - (prev_raw_count << shift);
> >> > >   delta >>= shift;
> >> > >
> >> > > + /* Correct the count number if applying ref_cycles replacement
> >> > > + */ if (!is_sampling_event(event) &&
> >> > > + (hwc->flags & PERF_X86_EVENT_REF_CYCLES_REP))
> >> > > + delta *= x86_pmu.ref_cycles_factor;
> >> >
> >> > That condition seems wrong, why only correct for !sampling events?
> >> >
> >>
> >> For sampling, it's either fixed freq mode or fixed period mode.
> >>  - In the fixed freq mode, we should do nothing, because the adaptive
> >>frequency algorithm will handle it.
> >>  - In the fixed period mode, we have already adjusted the period in
> >> ref_cycles_rep().
> >> Therefore, we should only handle !sampling events here.
> >
> > How so? For sampling events the actual event count should also be
> > accurate.
> 
> Yes, it must be. Because you can reconstruct the total number of occurrences
> of the event by adding all the periods recorded in each sample. So the period
> in each sample must reflect user event and not kernel event.

Peter and Stephane, you are right.
After adjusting the period, I can only make sure the number of samples for
the bus_cycles event is the same as that for ref cycles event.
I still need to adjust the number of occurrences of the event accordingly,
to make it accurate.
I will change it in next version.

Thanks,
Kan

Re: [PATCH v4 next 2/3] modules:capabilities: automatic module loading restriction

[Kees Cook]

On Mon, May 22, 2017 at 4:57 AM, Djalal Harouni  wrote:
> [...]
> diff --git a/kernel/module.c b/kernel/module.c
> index 4a3665f..ce7a146 100644
> --- a/kernel/module.c
> +++ b/kernel/module.c
> @@ -282,6 +282,8 @@ module_param(sig_enforce, bool_enable_only, 0644);
>
>  /* Block module loading/unloading? */
>  int modules_disabled = 0;
> +int modules_autoload_mode = MODULES_AUTOLOAD_ALLOWED;
> +const int modules_autoload_max = MODULES_AUTOLOAD_DISABLED;
>  core_param(nomodule, modules_disabled, bint, 0);
>
>  /* Waiting for a module to finish initializing? */
> @@ -4296,6 +4298,46 @@ struct module *__module_text_address(unsigned long 
> addr)
>  }
>  EXPORT_SYMBOL_GPL(__module_text_address);
>
> +/**
> + * may_autoload_module - Determine whether a module auto-load operation
> + * is permitted
> + * @kmod_name: The module name
> + * @allow_cap: if positive, may allow to auto-load the module if this 
> capability
> + * is set
> + *
> + * Determine whether a module auto-load operation is allowed or not. The 
> check
> + * uses the sysctl "modules_autoload_mode" value.
> + *
> + * This allows to have more control on automatic module loading, and align it
> + * with explicit load/unload module operations. The kernel contains several
> + * modules, some of them are not updated often and may contain bugs and
> + * vulnerabilities.
> + *
> + * The "allow_cap" is passed by callers to explicitly note that the module 
> has
> + * the appropriate alias and that the "allow_cap" capability is set. This is
> + * for backward compatibility, the aim is to have a clear picture where:
> + *
> + * 1) Implicit module loading is allowed
> + * 2) Implicit module loading as with the explicit one requires 
> CAP_SYS_MODULE.
> + * 3) Implicit module loading as with the explicit one can be disabled.
> + *
> + * Returns 0 if the module request is allowed or -EPERM if not.
> + */
> +int may_autoload_module(char *kmod_name, int allow_cap)
> +{
> +   if (modules_autoload_mode == MODULES_AUTOLOAD_ALLOWED)
> +   return 0;
> +   else if (modules_autoload_mode == MODULES_AUTOLOAD_PRIVILEGED) {
> +   /* Check CAP_SYS_MODULE then allow_cap if valid */
> +   if (capable(CAP_SYS_MODULE) ||
> +   (allow_cap > 0 && capable(allow_cap)))

With the allow_cap check already happening in my suggestion for
__request_module(), it's not needed here. (In fact, it's not even
really needed to plumb this into the hook, I don't think?

Regardless, I remain a fan. :)

-Kees

-- 
Kees Cook
Pixel Security

Re: [PATCH 1/2] misc: apds990x: move header file out of I2C realm

[Linus Walleij]

On Mon, May 22, 2017 at 11:49 PM, Arnd Bergmann  wrote:
> On Mon, May 22, 2017 at 5:56 PM, Wolfram Sang  wrote:
>>
>>> Should we also remove the drivers or move them into staging?
>>
>> I'd prefer to keep them. If they are needed again, DT conversion is
>> likely and easier than restarting from scratch. Guenter Roeck also
>> prefers to not unnecessarily annoy people who might have out-of-tree
>> board code. So, as long as they are not painful, let's keep them?
>
> The one reason I can think of for removing them is that we don't
> want ambient light sensor drivers in drivers/misc any more and
> instead of adding DT probing code would also expect new users to
> migrate to drivers/iio/light/, which already has drivers for
> apds9300 and apds9960 but not apds990x, as well as bh1750 and
> bh1780 but not bh1770.

This (apds990x) and bh1770 were added by Samu Onkalo
for Nokia's upstreaming efforts.

Samu, what are the hardware targets using this? Something that
has a userspace etc that we can test?

Like Nokia 900 or so?

Yours,
Linus Walleij

Re: work queue of scsi fc transports should be serialized

[Martin Wilck]

On Sat, 2017-05-20 at 08:25 +, Dashi DS1 Cao wrote:
> On Fri, 2017-05-19 at 09:36 +, Dashi DS1 Cao wrote:
> > It seems there is a race of multiple "fc_starget_delete" of the
> > same 
> > rport, thus of the same SCSI host. The race leads to the race of 
> > scsi_remove_target and it cannot be prevented by the code snippet 
> > alone, even of the most recent
> > version:
> > spin_lock_irqsave(shost->host_lock, flags);
> > list_for_each_entry(starget, >__targets, siblings) {
> > if (starget->state == STARGET_DEL ||
> > starget->state == STARGET_REMOVE)
> > continue;
> > If there is a possibility that the starget is under deletion(state
> > == 
> > STARGET_DEL), it should be possible that list_next_entry(starget, 
> > siblings) could cause a read access violation.
> > Hello Dashi,
> > Something else must be going on. From scsi_remove_target():
> > restart:
> > spin_lock_irqsave(shost->host_lock, flags);
> > list_for_each_entry(starget, >__targets, siblings) {
> > if (starget->state == STARGET_DEL ||
> > starget->state == STARGET_REMOVE)
> > continue;
> > if (starget->dev.parent == dev || >dev == dev)
> > {
> > kref_get(>reap_ref);
> > starget->state = STARGET_REMOVE;
> > spin_unlock_irqrestore(shost->host_lock,
> > flags);
> > __scsi_remove_target(starget);
> > scsi_target_reap(starget);
> > goto restart;
> > }
> > }
> > spin_unlock_irqrestore(shost->host_lock, flags);
> > In other words, before scsi_remove_target() decides to call
> > __scsi_remove_target(), it changes the target state into
> > STARGET_REMOVE while holding the host lock. 
> > This means that scsi_remove_target() won't
> > call __scsi_remove_target() twice and also that it won't invoke
> > list_next_entry(starget, siblings) after starget has been 
> > freed.
> > Bart.
> 
> In the crashes of Suse 12 sp1, the root cause is the deletion of a
> list node without holding the lock:
> spin_lock_irqsave(shost->host_lock, flags);
> list_for_each_entry_safe(starget, tmp, >__targets,
> siblings) {
> if (starget->state == STARGET_DEL)
> continue;
> if (starget->dev.parent == dev || >dev ==
> dev) {
> /* assuming new targets arrive at the end */
> kref_get(>reap_ref);
> spin_unlock_irqrestore(shost->host_lock,
> flags);
> 
> __scsi_remove_target(starget);
> list_move_tail(>siblings,
> _list);  --this deletion from shost->__targets list is done
> without the lock.
> spin_lock_irqsave(shost->host_lock, flags);
>  }
>   }
>   spin_unlock_irqrestore(shost->host_lock, flags);

I believe this is fixed in SLES12-SP1 kernel 3.12.53-60.30.1, with the
following patch:

* Mon Jan 18 2016 jthumsh...@suse.de
- scsi: restart list search after unlock in scsi_remove_target
  (bsc#944749, bsc#959257).
- Delete
  patches.fixes/0001-SCSI-Fix-hard-lockup-in-scsi_remove_target.patch.
- commit 2490876

Regards,
Martin

-- 
Dr. Martin Wilck , Tel. +49 (0)911 74053 2107
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)

Re: [PATCH BUGFIX] block, bfq: access and cache blkg data only when safe

[Paolo Valente]

> Il giorno 19 mag 2017, alle ore 16:37, Jens Axboe  ha 
> scritto:
> 
> On 05/19/2017 02:39 AM, Paolo Valente wrote:
>> @@ -692,8 +725,7 @@ void bfq_pd_offline(struct blkg_policy_data *pd)
>>  /*
>>   * The idle tree may still contain bfq_queues belonging
>>   * to exited task because they never migrated to a different
>> - * cgroup from the one being destroyed now.  No one else
>> - * can access them so it's safe to act without any lock.
>> ++* cgroup from the one being destroyed now.
>>   */
>>  bfq_flush_idle_tree(st);
>> 
> 
> Looks like an extra '+' snuck into that hunk.
> 

Yes, sorry.  Before possibly submitting a fixed version, I'll wait for
a reply on my previous email in this thread, as the issue now seems
more serious to me, and affecting CFQ too.

Thanks,
Paolo

> -- 
> Jens Axboe
> 

RE: [PATCH] x86/ACPI/cstate: Allow ACPI C1 FFH MWAIT use on AMD systems

[Ghannam, Yazen]

> -Original Message-
> From: Borislav Petkov [mailto:b...@alien8.de]
> Sent: Monday, May 22, 2017 12:22 PM
>

...
 
> What about x86_idle?
> 
> That whole select_idle_routine() jumping through hoops. That's still doing
> default_idle() on Zen, AFAICT.
> 
> Or am I missing something?
> 
> Because that still asks prefer_mwait_c1_over_halt() and that needs a family
> check or whatever...
> 

I think we leave HALT as the default idle mechanism and allow BIOS to select
other mechanisms through ACPI. 

On AMD, HALT allows the hardware to automatically manage its Cstates. This
is useful if the OS doesn't define multiple states like when we use
default_idle_call().

On the other hand, MWAIT on AMD limits the hardware to using only certain,
shallower Cstates. This is okay if we define individual states and use MWAIT
for some of them. But it would consume more power if used always.

Thanks,
Yazen

[PATCH] xprtrdma: Delete an error message for a failed memory allocation in xprt_rdma_bc_setup()

[SF Markus Elfring]

From: Markus Elfring 
Date: Mon, 22 May 2017 22:18:28 +0200

Omit an extra message for a memory allocation failure in this function.

This issue was detected by using the Coccinelle software.

Link: 
http://events.linuxfoundation.org/sites/events/files/slides/LCJ16-Refactor_Strings-WSang_0.pdf
Signed-off-by: Markus Elfring 
---
 net/sunrpc/xprtrdma/backchannel.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/net/sunrpc/xprtrdma/backchannel.c 
b/net/sunrpc/xprtrdma/backchannel.c
index 24fedd4b117e..03f6b5840764 100644
--- a/net/sunrpc/xprtrdma/backchannel.c
+++ b/net/sunrpc/xprtrdma/backchannel.c
@@ -119,11 +119,9 @@ int xprt_rdma_bc_setup(struct rpc_xprt *xprt, unsigned int 
reqs)
 
for (i = 0; i < (reqs << 1); i++) {
rqst = kzalloc(sizeof(*rqst), GFP_KERNEL);
-   if (!rqst) {
-   pr_err("RPC:   %s: Failed to create bc rpc_rqst\n",
-  __func__);
+   if (!rqst)
goto out_free;
-   }
+
dprintk("RPC:   %s: new rqst %p\n", __func__, rqst);
 
rqst->rq_xprt = _xprt->rx_xprt;
-- 
2.13.0

Re: [PATCH] xprtrdma: Delete an error message for a failed memory allocation in xprt_rdma_bc_setup()

[Chuck Lever]

> On May 22, 2017, at 4:24 PM, SF Markus Elfring 
>  wrote:
> 
> From: Markus Elfring 
> Date: Mon, 22 May 2017 22:18:28 +0200
> 
> Omit an extra message for a memory allocation failure in this function.
> 
> This issue was detected by using the Coccinelle software.
> 
> Link: 
> http://events.linuxfoundation.org/sites/events/files/slides/LCJ16-Refactor_Strings-WSang_0.pdf
> Signed-off-by: Markus Elfring 

Reviewed-by: Chuck Lever 


> ---
> net/sunrpc/xprtrdma/backchannel.c | 6 ++
> 1 file changed, 2 insertions(+), 4 deletions(-)
> 
> diff --git a/net/sunrpc/xprtrdma/backchannel.c 
> b/net/sunrpc/xprtrdma/backchannel.c
> index 24fedd4b117e..03f6b5840764 100644
> --- a/net/sunrpc/xprtrdma/backchannel.c
> +++ b/net/sunrpc/xprtrdma/backchannel.c
> @@ -119,11 +119,9 @@ int xprt_rdma_bc_setup(struct rpc_xprt *xprt, unsigned 
> int reqs)
> 
>   for (i = 0; i < (reqs << 1); i++) {
>   rqst = kzalloc(sizeof(*rqst), GFP_KERNEL);
> - if (!rqst) {
> - pr_err("RPC:   %s: Failed to create bc rpc_rqst\n",
> -__func__);
> + if (!rqst)
>   goto out_free;
> - }
> +
>   dprintk("RPC:   %s: new rqst %p\n", __func__, rqst);
> 
>   rqst->rq_xprt = _xprt->rx_xprt;
> -- 
> 2.13.0

--
Chuck Lever

Re: [PATCH] MAINTAINERS: EP93XX: Update maintainership

[Ryan Mallon]

On 22/05/17 23:30, Alexander Sverdlin wrote:
> As agreed with Ryan, change the maintainership.

Thanks for taking this over Alexander.

Acked-by: Ryan Mallon 

> Signed-off-by: Alexander Sverdlin 
> ---
>  MAINTAINERS | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 9e984645c4b0..5a248d0f 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -1172,7 +1172,7 @@ N:  clps711x
>  
>  ARM/CIRRUS LOGIC EP93XX ARM ARCHITECTURE
>  M:   Hartley Sweeten 
> -M:   Ryan Mallon 
> +M:   Alexander Sverdlin 
>  L:   linux-arm-ker...@lists.infradead.org (moderated for non-subscribers)
>  S:   Maintained
>  F:   arch/arm/mach-ep93xx/
> 

Re: [uml-devel] [PATCH] um: Add mark_rodata_ro support.

[Thomas Meyer]

> Am 22.05.2017 um 21:37 schrieb Richard Weinberger :
> 
> Thomas,
> 
>> Am 22.05.2017 um 21:18 schrieb Thomas Meyer:
>> 
>>> Am 22.05.2017 um 20:34 schrieb Richard Weinberger :
>>> 
>>> Thomas,
>>> 
 Am 22.05.2017 um 20:14 schrieb Thomas Meyer:
 It's purely cosmetic; to get rid of the boot message: "This architecture 
 does not have kernel memory protection." in init/main.c
 
 Which isn't true for UML as all read only stuff should end up in a read 
 only ELF section. Shouldn't it?
>>> 
>>> Hmm, reading /proc//maps tells a different story on my host.
>>> Did you check?
>> 
>> No... I may should have done so...
>> 
>> Okay, but it should be possible to mprotect those regions ?
> 
> Yes, it should.
> Can you give it a try?

Will do so!

> 
> Thanks,
> //richard
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> User-mode-linux-devel mailing list
> user-mode-linux-de...@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel


smime.p7s
Description: S/MIME cryptographic signature

Re: [PATCH 1/3] mm/slub: Only define kmalloc_large_node_hook() for NUMA systems

[David Rientjes]

On Fri, 19 May 2017, Matthias Kaehlcke wrote:

> The function is only used when CONFIG_NUMA=y. Placing it in an #ifdef
> block fixes the following warning when building with clang:
> 
> mm/slub.c:1246:20: error: unused function 'kmalloc_large_node_hook'
> [-Werror,-Wunused-function]
> 

Is clang not inlining kmalloc_large_node_hook() for some reason?  I don't 
think this should ever warn on gcc.

> Signed-off-by: Matthias Kaehlcke 

Acked-by: David Rientjes 

> ---
>  mm/slub.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/mm/slub.c b/mm/slub.c
> index 57e5156f02be..66e1046435b7 100644
> --- a/mm/slub.c
> +++ b/mm/slub.c
> @@ -1313,11 +1313,14 @@ static inline void dec_slabs_node(struct kmem_cache 
> *s, int node,
>   * Hooks for other subsystems that check memory allocations. In a typical
>   * production configuration these hooks all should produce no code at all.
>   */
> +
> +#ifdef CONFIG_NUMA
>  static inline void kmalloc_large_node_hook(void *ptr, size_t size, gfp_t 
> flags)
>  {
>   kmemleak_alloc(ptr, size, 1, flags);
>   kasan_kmalloc_large(ptr, size, flags);
>  }
> +#endif
>  
>  static inline void kfree_hook(const void *x)
>  {

Re: [PATCH 2/5] sctp: Delete an error message for a failed memory allocation in sctp_init()

[Vlad Yasevich]

On 05/22/2017 12:38 PM, SF Markus Elfring wrote:
> From: Markus Elfring 
> Date: Mon, 22 May 2017 17:28:14 +0200
> 
> Omit an extra message for a memory allocation failure in this function.
> 
> This issue was detected by using the Coccinelle software.
> 
> Link: 
> http://events.linuxfoundation.org/sites/events/files/slides/LCJ16-Refactor_Strings-WSang_0.pdf
> Signed-off-by: Markus Elfring 
> ---
>  net/sctp/protocol.c | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/net/sctp/protocol.c b/net/sctp/protocol.c
> index 2b1a6215bd2f..5e7c8a344770 100644
> --- a/net/sctp/protocol.c
> +++ b/net/sctp/protocol.c
> @@ -1447,5 +1447,4 @@ static __init int sctp_init(void)
>   if (!sctp_ep_hashtable) {
> - pr_err("Failed endpoint_hash alloc\n");
>   status = -ENOMEM;
>   goto err_ehash_alloc;
>   }
> 

Acked-by: Vlad Yasevich 

At the time this was written, it was patterned after TCP.  Since then TCP 
changed
significantly.  We can surely clean-up the pr_err() here and possibly update the
code as well later.

-vlad

Re: [PATCH 3/5] sctp: Fix a typo in a comment line in sctp_init()

[Vlad Yasevich]

On 05/22/2017 12:39 PM, SF Markus Elfring wrote:
> From: Markus Elfring 
> Date: Mon, 22 May 2017 17:43:44 +0200
> 
> Add a missing character in this description.
> 
> Signed-off-by: Markus Elfring 
> ---
>  net/sctp/protocol.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/net/sctp/protocol.c b/net/sctp/protocol.c
> index 5e7c8a344770..64756c42cec9 100644
> --- a/net/sctp/protocol.c
> +++ b/net/sctp/protocol.c
> @@ -1454,7 +1454,7 @@ static __init int sctp_init(void)
>   }
>  
>   /* Allocate and initialize the SCTP port hash table.
> -  * Note that order is initalized to start at the max sized
> +  * Note that order is initialized to start at the max sized
>* table we want to support.  If we can't get that many pages
>* reduce the order and try again
>*/
> 

Acked-by: Vlad Yasevich 

Re: [PATCH 4/5] sctp: Improve a size determination in sctp_inetaddr_event()

[Vlad Yasevich]

On 05/22/2017 12:40 PM, SF Markus Elfring wrote:
> From: Markus Elfring 
> Date: Mon, 22 May 2017 18:08:24 +0200
> 
> Replace the specification of a data structure by a pointer dereference
> as the parameter for the operator "sizeof" to make the corresponding size
> determination a bit safer according to the Linux coding style convention.
> 
> Signed-off-by: Markus Elfring 
> ---
>  net/sctp/protocol.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/net/sctp/protocol.c b/net/sctp/protocol.c
> index 64756c42cec9..057479b7bd72 100644
> --- a/net/sctp/protocol.c
> +++ b/net/sctp/protocol.c
> @@ -784,7 +784,7 @@ static int sctp_inetaddr_event(struct notifier_block 
> *this, unsigned long ev,
>  
>   switch (ev) {
>   case NETDEV_UP:
> - addr = kmalloc(sizeof(struct sctp_sockaddr_entry), GFP_ATOMIC);
> + addr = kmalloc(sizeof(*addr), GFP_ATOMIC);
>   if (addr) {
>   addr->a.v4.sin_family = AF_INET;
>   addr->a.v4.sin_port = 0;
> 

Acked-by: Vlad Yasevich 

-vlad

Re: linux-next: manual merge of the selinux tree with Linus' tree

[Paul Moore]

On Sun, May 21, 2017 at 10:38 PM, Stephen Rothwell  
wrote:
> Hi Paul,
>
> Today's linux-next merge of the selinux tree got a conflict in:
>
>   include/rdma/ib_verbs.h
>
> between commit:
>
>   2fc775726491 ("IB/opa-vnic: RDMA NETDEV interface")
>
> from Linus' tree and commit:
>
>   89b54b4d09bd ("IB/core: Enforce PKey security on QPs")
>
> from the selinux tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.

Thanks Stephen.

Daniel and Doug, does Stephen's patch look right to you?

> diff --cc include/rdma/ib_verbs.h
> index ba8314ec5768,c9e903fc824b..
> --- a/include/rdma/ib_verbs.h
> +++ b/include/rdma/ib_verbs.h
> @@@ -1890,7 -1878,10 +1930,8 @@@ enum ib_mad_result
> IB_MAD_RESULT_CONSUMED = 1 << 2  /* Packet consumed: stop processing 
> */
>   };
>
>  -#define IB_DEVICE_NAME_MAX 64
>  -
>   struct ib_port_cache {
> +   u64   subnet_prefix;
> struct ib_pkey_cache  *pkey;
> struct ib_gid_table   *gid;
> u8 lmc;
> @@@ -1912,34 -1903,12 +1953,40 @@@ struct ib_port_immutable
> u32   max_mad_size;
>   };
>
>  +/* rdma netdev type - specifies protocol type */
>  +enum rdma_netdev_t {
>  +  RDMA_NETDEV_OPA_VNIC,
>  +  RDMA_NETDEV_IPOIB,
>  +};
>  +
>  +/**
>  + * struct rdma_netdev - rdma netdev
>  + * For cases where netstack interfacing is required.
>  + */
>  +struct rdma_netdev {
>  +  void  *clnt_priv;
>  +  struct ib_device  *hca;
>  +  u8 port_num;
>  +
>  +  /* control functions */
>  +  void (*set_id)(struct net_device *netdev, int id);
>  +  /* send packet */
>  +  int (*send)(struct net_device *dev, struct sk_buff *skb,
>  +  struct ib_ah *address, u32 dqpn);
>  +  /* multicast */
>  +  int (*attach_mcast)(struct net_device *dev, struct ib_device *hca,
>  +  union ib_gid *gid, u16 mlid,
>  +  int set_qkey, u32 qkey);
>  +  int (*detach_mcast)(struct net_device *dev, struct ib_device *hca,
>  +  union ib_gid *gid, u16 mlid);
>  +};
>  +
> + struct ib_port_pkey_list {
> +   /* Lock to hold while modifying the list. */
> +   spinlock_tlist_lock;
> +   struct list_head  pkey_list;
> + };
> +
>   struct ib_device {
> /* Do not access @dma_device directly from ULP nor from HW drivers. */
> struct device*dma_device;



-- 
paul moore
www.paul-moore.com

Re: [PATCH 7/7] DWARF: add the config option

[H. Peter Anvin]

On 05/20/17 13:01, H.J. Lu wrote:
> On Sat, May 20, 2017 at 9:20 AM, Josh Poimboeuf  wrote:
> 
>>>
>>> (H.J., could we get a binutils feature that allows is to do:
>>>
>>> pushq %whatever
>>> .cfi_adjust_sp -8
>>> ...
>>> popq %whatever
>>> .cfi_adjust_sp 8
>>>
> 
> Np.  Compiler needs to generate this.
> 

For actual assembly we have such a feature, it is called macros.

push/pop is the easy stuff; macros take care of that, but the real pain
is dealing with the flow of control.

-hpa

[PATCH] zlib: Put get_unaligned16() inside #ifdef block

[Matthias Kaehlcke]

The function is not used when CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS=y.
Adding the #ifdef fixes the following warning when building with clang:

lib/zlib_inflate/inffast.c:31:1: error: unused function 'get_unaligned16'
[-Werror,-Wunused-function]

Signed-off-by: Matthias Kaehlcke 
---
Note: Usually we would use the __maybe_unused attribute to silence the
warning. Since this code is used in the kernel decompression stub rather
than in the kernel itself we can't include  with the
definition of __maybe_unused (it would be possible for some platforms,
however for powerpc the build fails with a compiler error). We could
redefine __maybe_unused or use the raw __attribute__((unused)), but
using the #ifdef is a simpler solution.

 lib/zlib_inflate/inffast.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/lib/zlib_inflate/inffast.c b/lib/zlib_inflate/inffast.c
index 2c13ecc5bb2c..af2fd95e35e9 100644
--- a/lib/zlib_inflate/inffast.c
+++ b/lib/zlib_inflate/inffast.c
@@ -26,6 +26,7 @@ union uu {
unsigned char b[2];
 };
 
+#ifndef CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS
 /* Endian independed version */
 static inline unsigned short
 get_unaligned16(const unsigned short *p)
@@ -37,6 +38,7 @@ get_unaligned16(const unsigned short *p)
mm.b[1] = b[1];
return mm.us;
 }
+#endif
 
 #ifdef POSTINC
 #  define OFF 0
-- 
2.13.0.303.g4ebf302169-goog

Re: [patch 2/2] MM: allow per-cpu vmstat_threshold and vmstat_worker configuration

[Marcelo Tosatti]

On Mon, May 22, 2017 at 11:38:02AM -0500, Christoph Lameter wrote:
> On Sat, 20 May 2017, Marcelo Tosatti wrote:
> 
> > > And you can configure the interval of vmstat updates freely Set
> > > the vmstat_interval to 60 seconds instead of 2 for a try? Is that rare
> > > enough?
> >
> > Not rare enough. Never is rare enough.
> 
> Ok what about the other stuff that must be going on if you allow OS
> activity like f.e. the tick, scheduler etc etc.

Yes these are also problems... but we're either getting rid of them or
reducing their impact as much as possible.

vmstat_update is one member of the problematic set.

I'll get you the detailed IPI measures, hold on...

Re: [PATCH] zlib: Put get_unaligned16() inside #ifdef block

[Andrew Morton]

On Mon, 22 May 2017 14:13:26 -0700 Matthias Kaehlcke  wrote:

> The function is not used when CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS=y.
> Adding the #ifdef fixes the following warning when building with clang:
> 
> lib/zlib_inflate/inffast.c:31:1: error: unused function 'get_unaligned16'
> [-Werror,-Wunused-function]
> 
> ...
>
> --- a/lib/zlib_inflate/inffast.c
> +++ b/lib/zlib_inflate/inffast.c
> @@ -26,6 +26,7 @@ union uu {
>   unsigned char b[2];
>  };
>  
> +#ifndef CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS
>  /* Endian independed version */
>  static inline unsigned short
>  get_unaligned16(const unsigned short *p)
> @@ -37,6 +38,7 @@ get_unaligned16(const unsigned short *p)
>   mm.b[1] = b[1];
>   return mm.us;
>  }
> +#endif
>  
>  #ifdef POSTINC
>  #  define OFF 0

Do we really want to mucky up the source code to keep clang happy?  gcc
won't warn about an unused static inline.  Can we configure clang to do
the same?

Re: [PATCH 7/7] DWARF: add the config option

[H. Peter Anvin]

On 05/22/17 14:07, H. Peter Anvin wrote:
> On 05/20/17 13:01, H.J. Lu wrote:
>> On Sat, May 20, 2017 at 9:20 AM, Josh Poimboeuf  wrote:
>>

 (H.J., could we get a binutils feature that allows is to do:

 pushq %whatever
 .cfi_adjust_sp -8
 ...
 popq %whatever
 .cfi_adjust_sp 8

>>
>> Np.  Compiler needs to generate this.
>>
> 
> For actual assembly we have such a feature, it is called macros.
> 
> push/pop is the easy stuff; macros take care of that, but the real pain
> is dealing with the flow of control.
> 

My biggest beef with the CFI directives that gas uses is that there is
that .cfi_remember_state/.cfi_restore_state doesn't have a way to
specify more than one state.  That makes it really hard to get sanity
around control flow changes, especially with code that is intentionally
out of line.

That, and some of the CFI directives seem to be a bit ill-defined in
their definition (are they even applicable to anything other than
DWARF?)  They almost seem to be referencing some external specification,
but the only thing I'm finding is the DWARF documentation which is
written in very different terms.

The best description of what a personality routine is I found in an
article by Ian Lance Taylor.  It doesn't seem to be applicable to C as
far as I can tell.

-hpa

Re: [PATCH] drm/pl111: add ARM_AMBA dependency

[Arnd Bergmann]

On Mon, May 22, 2017 at 6:23 PM, Eric Anholt  wrote:
> Arnd Bergmann  writes:
>
>> The driver is written in a way to enable compile-testing without 
>> CONFIG_ARM_AMBA,
>> but it just causes needless warnings:
>>
>> drivers/gpu/drm/pl111/pl111_drv.c:149:26: error: 'pl111_drm_driver' defined 
>> but not used [-Werror=unused-variable]
>> drivers/gpu/drm/pl111/pl111_drv.c:81:12: error: 'pl111_modeset_init' defined 
>> but not used [-Werror=unused-function]
>>
>> This removes the #ifdef instead, and adds a dependency on ARM_AMBA to
>> only let us build the driver when the base support is enabled.
>>
>> Unfortunately, this requires removing one redundant 'select ARM_AMBA'
>> line from mach-s3c64xx to avoid a circular dependency.
>>
>> It might be good to allow manually enabling ARM_AMBA when COMPILE_TEST
>> is turned on, but that should be a separate patch and may cause other
>> build regressions.
>
> If I understand the Kconfig, you're effectively disabling the build on
> COMPILE_TEST && !ARM.  I'd rather that we just fix up the warnings, so
> that people can keep build-testing DRM drivers:
>
> https://patchwork.kernel.org/patch/9737857/

That works too. When I tried the same, I thought it was a little too silly to
have a file that effectively compiles into nothing.

My initial approach did two things differently though:

- use __maybe_unused instead of __used, since

- annotate pl111_amba_driver instead of
  pl111_drm_driver/pl111_modeset_init, and keep only
  module_amba_driver() in the #ifdef.

   Arnd

Re: linux-next: manual merge of the tip tree with Linus' tree

[Stephen Rothwell]

Hi Mark,

On Mon, 22 May 2017 09:32:15 +0100 Mark Rutland  wrote:
>
> Just to check, is your copy of tip up-to-date?

Yes, it was fetched just before being merged.  I use the auto-latest
branch of the tip tree which may not be as up to date as the master
branch.

> That latter commit was in the tip smp/hotplug branch, but that branch
> was reset to v4.12-rc1 a few days ago (before the first commit was sent
> to Linus), specifically to avoid this conflict.
> 
> ... did we miss another branch that was merged into, perhaps?

Presumably, but that's ok - I assume it will come good eventually.

> The good news is that the commit in Linus' tree is the correct fix. :)

Well, except that I only fixed up that one spot, the rest of the commit
from the tip tree was still there.

> The other commit was a slightly broken prior attempt, and shouldn't be
> in the tip tree any more.

OK.

-- 
Cheers,
Stephen Rothwell

Re: [PATCH] CodingStyle: delete "kmalloc(sizeof(*var))" as preferred allocation form

[Joe Perches]

On Tue, 2017-05-23 at 00:38 +0300, Alexey Dobriyan wrote:
> There are valid reasons for
> 
>   malloc(sizeof(struct S))
> 
> form:
> 
> * struct S acts as an anchor for ctags quickly reminding which type is
>   in focus
> 
> * argument re changing name prevents bugs is semi bogus:
>   such changes are rare,
>   "void *" cast gives both forms equal opportunity to be screwed up
> 
> * proper way to fix those rare misallocation bugs (which indeed happened)
>   is type safe allocation macros (see tmalloc from Samba).
> 
>   However amount of disruption will be so high so it may never be done.
> 
> * ratio of allocation styles is ~6400:12000 which is about 1:2
>   so the amount of churn to maintain this rule is pretty high in theory.
> 
> The winning move is to not play and not encourage people send trivial stuff.
> 
> Signed-off-by: Alexey Dobriyan 
> ---
> 
>  Documentation/process/coding-style.rst |   10 --
>  1 file changed, 10 deletions(-)
> 
> --- a/Documentation/process/coding-style.rst
> +++ b/Documentation/process/coding-style.rst
> @@ -808,16 +808,6 @@ kmalloc(), kzalloc(), kmalloc_array(), kcalloc(), 
> vmalloc(), and
>  vzalloc().  Please refer to the API documentation for further information
>  about them.
>  
> -The preferred form for passing a size of a struct is the following:
> -
> -.. code-block:: c
> -
> - p = kmalloc(sizeof(*p), ...);
> -
> -The alternative form where struct name is spelled out hurts readability and
> -introduces an opportunity for a bug when the pointer variable type is changed
> -but the corresponding sizeof that is passed to a memory allocator is not.
> -
>  Casting the return value which is a void pointer is redundant. The conversion
>  from void pointer to any other pointer type is guaranteed by the C 
> programming
>  language.

Thanks.  I agree with this deletion.

Re: [PATCH] ipc: Fail build if IPC structures change layout

[Andrew Morton]

On Fri, 19 May 2017 16:44:00 -0700 Kees Cook  wrote:

> Since struct layout can be seen at build-time, turn runtime report
> into a build failure so it can be fixed more quickly.

I've just dropped the patch which this fixes, due to runtime issues. 
Manfred, please include this in the resend?

Re: [PATCH 0/2] Fixes for Switchtec Driver

[Bjorn Helgaas]

On Mon, May 15, 2017 at 10:44:51AM -0600, Logan Gunthorpe wrote:
> Hi Bjorn,
> 
> Can you please apply the following two patches? The first is
> a cleanup to use a new helper function I added (it had to wait
> until both patchsets were in). The second is a minor bug fix to
> the driver we found last week.
> 
> Thanks!
> 
> Logan
> 
> 
> Logan Gunthorpe (2):
>   switchtec: utilize new device_add_cdev helper function
>   switchtec: fix minor bug with partition id register
> 
>  drivers/pci/switch/switchtec.c | 16 ++--
>  1 file changed, 6 insertions(+), 10 deletions(-)

Since we merged the Switchtec driver during the v4.12 merge window, I
applied these to for-linus for v4.12, with the following changelogs to
correct a few typos:

commit 9871e9bb5cf6
Author: Logan Gunthorpe 
Date:   Mon May 22 16:52:30 2017 -0500

switchtec: Fix minor bug with partition ID register

When a switch endpoint is configured without NTB, the mmio_ntb registers
will read all zeros.  However, in corner case configurations where the
partition ID is not zero and NTB is not enabled, the code will have the
wrong partition ID and this causes the driver to use the wrong set of
drivers.  To fix this we simply take the partition ID from the system info
region.

Reported-by: Dingbao Chen 
Signed-off-by: Logan Gunthorpe 
Signed-off-by: Bjorn Helgaas 

commit e40cf640b8f6 (refs/patches/for-linus/switchtec-use-new)
Author: Logan Gunthorpe 
Date:   Mon May 22 16:52:24 2017 -0500

switchtec: Use new cdev_device_add() helper function

Convert from "cdev_add() + device_add()" to cdev_device_add(), and from
"device_del() + cdev_del()" to cdev_device_del().

[bhelgaas: changelog]
Signed-off-by: Logan Gunthorpe 
Signed-off-by: Bjorn Helgaas 

Re: [PULL REQUEST] i2c for 4.12

[Tobias Klausmann]

If you find the time, please push it out to master for testing purpose! 
(my touchpad is broken as well: 9d6408433019bfae15e2d0d5f4498c4ff70b86c0 
- i2c: designware: don't infer timings described by ACPI from clock rate)



Thanks,

Tobias Klausmann


On 5/22/17 11:04 PM, Wolfram Sang wrote:

Confirmed. Initializing those fields to zero fixes it.

Thanks!

[PATCH v2 1/2] mm: avoid spurious 'bad pmd' warning messages

[Ross Zwisler]

When the pmd_devmap() checks were added by:

commit 5c7fb56e5e3f ("mm, dax: dax-pmd vs thp-pmd vs hugetlbfs-pmd")

to add better support for DAX huge pages, they were all added to the end of
if() statements after existing pmd_trans_huge() checks.  So, things like:

-   if (pmd_trans_huge(*pmd))
+   if (pmd_trans_huge(*pmd) || pmd_devmap(*pmd))

When further checks were added after pmd_trans_unstable() checks by:

commit 7267ec008b5c ("mm: postpone page table allocation until we have page
to map")

they were also added at the end of the conditional:

+   if (pmd_trans_unstable(fe->pmd) || pmd_devmap(*fe->pmd))

This ordering is fine for pmd_trans_huge(), but doesn't work for
pmd_trans_unstable().  This is because DAX huge pages trip the bad_pmd()
check inside of pmd_none_or_trans_huge_or_clear_bad() (called by
pmd_trans_unstable()), which prints out a warning and returns 1.  So, we do
end up doing the right thing, but only after spamming dmesg with suspicious
looking messages:

mm/pgtable-generic.c:39: bad pmd 8808daa49b88(8401006000a5)

Reorder these checks in a helper so that pmd_devmap() is checked first,
avoiding the error messages, and add a comment explaining why the ordering
is important.

Signed-off-by: Ross Zwisler 
Reviewed-by: Jan Kara 
Fixes: commit 7267ec008b5c ("mm: postpone page table allocation until we have 
page to map")
Cc: sta...@vger.kernel.org
---

Changes from v1:
 - Break the checks out into the new pmd_devmap_trans_unstable() helper and
   add a comment about the ordering (Dave).  I ended up keeping this helper
   in mm/memory.c because I didn't see an obvious header where it would
   live happily.  pmd_devmap() is either defined in
   arch/x86/include/asm/pgtable.h or in include/linux/mm.h depending on
   __HAVE_ARCH_PTE_DEVMAP and CONFIG_TRANSPARENT_HUGEPAGE, and
   pmd_trans_unstable() is defined in include/asm-generic/pgtable.h.

 - Add a comment explaining why pte_alloc_one_map() doesn't suffer from races.
   This was the result of a conversation with Dave Hansen.
---
 mm/memory.c | 40 ++--
 1 file changed, 30 insertions(+), 10 deletions(-)

diff --git a/mm/memory.c b/mm/memory.c
index 6ff5d72..2e65df1 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -3029,6 +3029,17 @@ static int __do_fault(struct vm_fault *vmf)
return ret;
 }
 
+/*
+ * The ordering of these checks is important for pmds with _PAGE_DEVMAP set.
+ * If we check pmd_trans_unstable() first we will trip the bad_pmd() check
+ * inside of pmd_none_or_trans_huge_or_clear_bad(). This will end up correctly
+ * returning 1 but not before it spams dmesg with the pmd_clear_bad() output.
+ */
+static int pmd_devmap_trans_unstable(pmd_t *pmd)
+{
+   return pmd_devmap(*pmd) || pmd_trans_unstable(pmd);
+}
+
 static int pte_alloc_one_map(struct vm_fault *vmf)
 {
struct vm_area_struct *vma = vmf->vma;
@@ -3052,18 +3063,27 @@ static int pte_alloc_one_map(struct vm_fault *vmf)
 map_pte:
/*
 * If a huge pmd materialized under us just retry later.  Use
-* pmd_trans_unstable() instead of pmd_trans_huge() to ensure the pmd
-* didn't become pmd_trans_huge under us and then back to pmd_none, as
-* a result of MADV_DONTNEED running immediately after a huge pmd fault
-* in a different thread of this mm, in turn leading to a misleading
-* pmd_trans_huge() retval.  All we have to ensure is that it is a
-* regular pmd that we can walk with pte_offset_map() and we can do that
-* through an atomic read in C, which is what pmd_trans_unstable()
-* provides.
+* pmd_trans_unstable() via pmd_devmap_trans_unstable() instead of
+* pmd_trans_huge() to ensure the pmd didn't become pmd_trans_huge
+* under us and then back to pmd_none, as a result of MADV_DONTNEED
+* running immediately after a huge pmd fault in a different thread of
+* this mm, in turn leading to a misleading pmd_trans_huge() retval.
+* All we have to ensure is that it is a regular pmd that we can walk
+* with pte_offset_map() and we can do that through an atomic read in
+* C, which is what pmd_trans_unstable() provides.
 */
-   if (pmd_trans_unstable(vmf->pmd) || pmd_devmap(*vmf->pmd))
+   if (pmd_devmap_trans_unstable(vmf->pmd))
return VM_FAULT_NOPAGE;
 
+   /*
+* At this point we know that our vmf->pmd points to a page of ptes
+* and it cannot become pmd_none(), pmd_devmap() or pmd_trans_huge()
+* for the duration of the fault.  If a racing MADV_DONTNEED runs and
+* we zap the ptes pointed to by our vmf->pmd, the vmf->ptl will still
+* be valid and we will re-check to make sure the vmf->pte isn't
+* pte_none() under vmf->ptl protection when we return to
+* alloc_set_pte().
+*/
vmf->pte = pte_offset_map_lock(vma->vm_mm, 

Re: linux-next: error while fetching the c6x tree

[Stephen Rothwell]

Hi Mark,

On Mon, 22 May 2017 10:14:50 -0400 Mark Salter  wrote:
>
> It's back up, now.

Thanks.

-- 
Cheers,
Stephen Rothwell

Re: [PATCH -next] drm/pl111: Fix return value check in pl111_amba_probe()

[Eric Anholt]

Wei Yongjun  writes:

> From: Wei Yongjun 
>
> In case of error, the function devm_ioremap_resource() returns ERR_PTR()
> and never returns NULL. The NULL test in the return value check should
> be replaced with IS_ERR().
>
> Fixes: bed41005e617 ("drm/pl111: Initial drm/kms driver for pl111")
> Signed-off-by: Wei Yongjun 

Reviewed and applied.  Thanks!


signature.asc
Description: PGP signature

Re: [PATCH 7/7] DWARF: add the config option

[Josh Poimboeuf]

On Mon, May 22, 2017 at 02:37:50PM -0700, H. Peter Anvin wrote:
> On 05/22/17 14:07, H. Peter Anvin wrote:
> > On 05/20/17 13:01, H.J. Lu wrote:
> >> On Sat, May 20, 2017 at 9:20 AM, Josh Poimboeuf  
> >> wrote:
> >>
> 
>  (H.J., could we get a binutils feature that allows is to do:
> 
>  pushq %whatever
>  .cfi_adjust_sp -8
>  ...
>  popq %whatever
>  .cfi_adjust_sp 8
> 
> >>
> >> Np.  Compiler needs to generate this.
> >>
> > 
> > For actual assembly we have such a feature, it is called macros.
> > 
> > push/pop is the easy stuff; macros take care of that, but the real pain
> > is dealing with the flow of control.
> > 
> 
> My biggest beef with the CFI directives that gas uses is that there is
> that .cfi_remember_state/.cfi_restore_state doesn't have a way to
> specify more than one state.  That makes it really hard to get sanity
> around control flow changes, especially with code that is intentionally
> out of line.
> 
> That, and some of the CFI directives seem to be a bit ill-defined in
> their definition (are they even applicable to anything other than
> DWARF?)  They almost seem to be referencing some external specification,
> but the only thing I'm finding is the DWARF documentation which is
> written in very different terms.
> 
> The best description of what a personality routine is I found in an
> article by Ian Lance Taylor.  It doesn't seem to be applicable to C as
> far as I can tell.

So my understanding is that there's stock DWARF (.debug_frame) and then
there's souped-up DWARF (.eh_frame), which is basically DWARF with a few
extensions.

The remember/restore state thing is stock DWARF (DW_CFA_remember_state
and DW_CFA_restore_state).  The personality routine thing is in the
.eh_frame extension which is documented here:

  
http://refspecs.linuxfoundation.org/LSB_5.0.0/LSB-Core-generic/LSB-Core-generic/ehframechpt.html

-- 
Josh

[VFS] b3bd180696: BUG:stack_guard_page_was_hit_at#(stack_is#..#)

[kernel test robot]

FYI, we noticed the following commit:

commit: b3bd18069659cd4f4cdb0ea1638f4ce54ef0b499 ("VFS: Implement a superblock 
configuration context")
https://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git mount-context

in testcase: trinity
with following parameters:

runtime: 300s

test-description: Trinity is a linux system call fuzz tester.
test-url: http://codemonkey.org.uk/projects/trinity/


on test machine: qemu-system-x86_64 -enable-kvm -smp 2 -m 512M

caused below changes (please refer to attached dmesg/kmsg for entire 
log/backtrace):


++++
|| 50f1960a2b | b3bd180696 |
++++
| boot_successes | 7  | 0  |
| boot_failures  | 0  | 6  |
| BUG:stack_guard_page_was_hit_at#(stack_is#..#) | 0  | 6  |
| Kernel_panic-not_syncing:Fatal_exception   | 0  | 6  |
++++



[1.018960] BUG: stack guard page was hit at a662400d4000 (stack is 
a662400d..a662400d3fff)
[1.021514] kernel stack overflow (page fault):  [#1] SMP
[1.022918] Modules linked in:
[1.024023] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 
4.12.0-rc1-9-gb3bd180 #4
[1.026254] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
1.9.3-20161025_171302-gandalf 04/01/2014
[1.028802] task: 969a91900040 task.stack: a662400d
[1.030144] RIP: 0010:legacy_monolithic_mount_data+0x66/0xa0
[1.031546] RSP: :a662400d3db8 EFLAGS: 00010246
[1.032955] RAX: 969a9172a2a8 RBX: 969a90915d08 RCX: 038e
[1.034620] RDX: 1000 RSI: a662400d3ffe RDI: 969a9172a470
[1.036311] RBP: a662400d3dd0 R08: a444cb27 R09: 0001
[1.037925] R10: a662400d3d38 R11: a662400d3e3f R12: 
[1.039578] R13: a662400d3e36 R14: 9472cfe0 R15: 0800
[1.041235] FS:  () GS:969a92c0() 
knlGS:
[1.043402] CS:  0010 DS:  ES:  CR0: 80050033
[1.044963] CR2: a662400d4000 CR3: 09423000 CR4: 06f0
[1.046509] Call Trace:
[1.047440]  parse_monolithic_mount_data+0x20/0x22
[1.048753]  vfs_kern_mount+0x4c/0xb4
[1.049786]  kern_mount_data+0x19/0x2e
[1.050876]  init_hugetlbfs_fs+0xe3/0x15a
[1.051980]  ? proc_create_data+0x86/0x9f
[1.053209]  ? init_ramfs_fs+0x25/0x25
[1.054354]  ? set_debug_rodata+0x17/0x17
[1.055483]  do_one_initcall+0x90/0x13c
[1.069483]  ? set_debug_rodata+0x17/0x17
[1.070703]  kernel_init_freeable+0x1de/0x261
[1.071965]  ? rest_init+0x13b/0x13b
[1.073007]  kernel_init+0xe/0xf5
[1.074112]  ret_from_fork+0x31/0x40
[1.075120] Code: e8 e3 5a 37 00 eb 54 45 31 e4 48 85 f6 49 89 f5 74 49 48 
83 7f 50 00 48 89 fb 74 1a b9 00 04 00 00 48 8b 7b 50 4c 89 ee 45 31 e4  a5 
c7 43 60 00 10 00 00 eb 25 48 8b 3d 1b bf 4b 02 ba 00 10 
[1.079546] RIP: legacy_monolithic_mount_data+0x66/0xa0 RSP: a662400d3db8
[1.081175] ---[ end trace 89195d162e5195f6 ]---


To reproduce:

git clone https://github.com/01org/lkp-tests.git
cd lkp-tests
bin/lkp qemu -k  job-script  # job-script is attached in this 
email



Thanks,
Kernel Test Robot
#
# Automatically generated file; DO NOT EDIT.
# Linux/x86_64 4.12.0-rc1 Kernel Configuration
#
CONFIG_64BIT=y
CONFIG_X86_64=y
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
CONFIG_OUTPUT_FORMAT="elf64-x86-64"
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/x86_64_defconfig"
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_MMU=y
CONFIG_ARCH_MMAP_RND_BITS_MIN=28
CONFIG_ARCH_MMAP_RND_BITS_MAX=32
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MIN=8
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MAX=16
CONFIG_NEED_DMA_MAP_STATE=y
CONFIG_NEED_SG_DMA_LENGTH=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_BUG_RELATIVE_POINTERS=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_ARCH_HAS_CPU_RELAX=y
CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
CONFIG_HAVE_SETUP_PER_CPU_AREA=y
CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y
CONFIG_ARCH_WANT_GENERAL_HUGETLB=y
CONFIG_ZONE_DMA32=y
CONFIG_AUDIT_ARCH=y
CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
CONFIG_X86_64_SMP=y
CONFIG_ARCH_SUPPORTS_UPROBES=y
CONFIG_FIX_EARLYCON_MEM=y
CONFIG_PGTABLE_LEVELS=4
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_EXTABLE_SORT=y
CONFIG_THREAD_INFO_IN_TASK=y

#
# General 

RE: [PATCH 00/24] Thunderbolt security levels and NVM firmware upgrade

[Bernat, Yehezkel]

> -Original Message-
> From: mario.limoncie...@dell.com [mailto:mario.limoncie...@dell.com]
> Sent: Monday, May 22, 2017 23:08
> To: mika.westerb...@linux.intel.com
> Cc: gre...@linuxfoundation.org; andreas.noe...@gmail.com; Jamet,
> Michael ; Bernat, Yehezkel
> ; lu...@wunner.de; Levy, Amir (Jer)
> ; l...@kernel.org; jared.doming...@dell.com;
> andriy.shevche...@linux.intel.com; linux-kernel@vger.kernel.org
> Subject: RE: [PATCH 00/24] Thunderbolt security levels and NVM firmware
> upgrade
> 
> > -Original Message-
> > From: Mika Westerberg [mailto:mika.westerb...@linux.intel.com]
> > Sent: Monday, May 22, 2017 6:37 AM
> > To: Limonciello, Mario 
> > Cc: gre...@linuxfoundation.org; andreas.noe...@gmail.com;
> > michael.ja...@intel.com; yehezkel.ber...@intel.com; lu...@wunner.de;
> > amir.jer.l...@intel.com; l...@kernel.org; Dominguez, Jared
> > ; andriy.shevche...@linux.intel.com;
> linux-
> > ker...@vger.kernel.org
> > Subject: Re: [PATCH 00/24] Thunderbolt security levels and NVM firmware
> upgrade
> >
> > On Sat, May 20, 2017 at 11:24:12AM +0300, Mika Westerberg wrote:
> > > On Fri, May 19, 2017 at 05:54:37PM +, mario.limoncie...@dell.com
> wrote:
> > > > >
> > > > > It happens occasionally when you reboot the machine when a device
> is
> > > > > connected but seems to be dependent on the BIOS version. Since it is
> the
> > > > > BIOS who is supposed to enumerated these devices, I suspect that it
> is
> > > > > either problem in BIOS or our PCI enumeration code does something
> wrong.
> > > > >
> > > >
> > > > I'm fairly certain it's an issue somewhere with Linux PCI enumeration.  
> > > > I
> took
> > > > the exact same HW and switched it out the SSD to one w/ Win10 1607.
> > > > I set the dock and cable to "always allow" in TBT settings applet.
> > > >
> > > > I don't reproduce any problems with enumeration with the dock
> plugged in
> > > > on cold boot.  All the devices hanging off the bridge show up properly.
> > >
> > > You mean in Windows you don't reproduce the problem, right? Even
> when
> > > you reboot the machine with devices connected.
> > >
> > > I tried on Intel Skull Canyon NUC so that I disabled the thunderbolt
> > > driver and after reboot (warm) I can see the PCI scan error about bus
> > > being partially hidden behind a bridge.
> > >
> > > When this happens PCIe ports of the thunderbolt device/host seem to
> be
> > > unconfigured and Linux then decides to reconfigure them which leads to
> > > the problem. When it works we get ACPI hotplug event to the PCIe root
> > > port and the PCIe upstream/downstream ports are properly configured
> by
> > > the BIOS.
> > >
> > > I guess Windows does something differently here than what we do when
> PCI
> > > devices are enumerated.
> >
> > We discussed this with our BIOS/firmware people and there was a
> firmware
> > bug that caused many issues around hotplug and reboot flows. Is is
> > possible for you to try with the latest BIOS and see if the issue
> > reproduces (or are you already running the latest)?
> 
> I was 1 version behind, but I double checked with the latest version (1.1.15)
> and the same behavior exists on Linux (still works properly on Win10).
> 
> If you have some more details about what the FW guys changed, I can check
> with my Dell FW team if they've picked up the same fix.  I'm guessing it's not
> the same problem though considering it works properly on Win10?

What about the TBT NVM version?
NVM 16 sounds a bit old to me.

Re: [PULL REQUEST] i2c for 4.12

[Linus Torvalds]

On Fri, May 19, 2017 at 1:40 PM, Wolfram Sang  wrote:
>
> here is a regression fix for I2C that would be great to have in rc2
> already. Based on your tree from today. Please pull.

Gaah. I hadn't tested this on my laptop, and instead of beign a
regression fix, this looks like a new regression. My touchpad on the
xps 13 9350 no longer works after this.

Now, I'm not 100% certain it is this particular change, but I'm about
half-way through the bisection, and this is the only thing that looks
even remotely likely.

And yes, the xps13 does use i2c_designware for the touchpad.

I'll finish the bisection just top be sure, but the rest in there
really looks like kvm stuff etc that shouldn't possibly affect the
touchpad.

So this commit will almost certainly be reverted unless somebody can
figure out why it breaks.

   Linus

[PATCH] clk: sunxi-ng: select SUNXI_CCU_MULT for sun8i-a83t

[Arnd Bergmann]

We get a link error when CCU_MULT is not set with the
newly added driver:

drivers/clk/sunxi-ng/ccu-sun8i-a83t.o:(.data.__compound_literal.1+0x4): 
undefined reference to `ccu_mult_ops'
drivers/clk/sunxi-ng/ccu-sun8i-a83t.o:(.data.__compound_literal.3+0x4): 
undefined reference to `ccu_mult_ops'

Fixes: 46b49211 ("clk: sunxi-ng: Add driver for A83T CCU")
Signed-off-by: Arnd Bergmann 
---
 drivers/clk/sunxi-ng/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/clk/sunxi-ng/Kconfig b/drivers/clk/sunxi-ng/Kconfig
index a384c695b388..67acef3d2494 100644
--- a/drivers/clk/sunxi-ng/Kconfig
+++ b/drivers/clk/sunxi-ng/Kconfig
@@ -121,6 +121,7 @@ config SUN8I_A83T_CCU
select SUNXI_CCU_DIV
select SUNXI_CCU_GATE
select SUNXI_CCU_MP
+   select SUNXI_CCU_MULT
select SUNXI_CCU_MUX
select SUNXI_CCU_NKMP
select SUNXI_CCU_NM
-- 
2.9.0

[PATCH] gpu: drm: gma500: remove two more dead variable

[Arnd Bergmann]

The dead code removal left two unused variables:

drivers/gpu/drm/gma500/mdfld_tpo_vid.c: In function 'tpo_vid_get_config_mode':
drivers/gpu/drm/gma500/mdfld_tpo_vid.c:34:31: error: unused variable 'ti' 
[-Werror=unused-variable]

This removes them as well.

Fixes: 94d7fb4982d2 ("gpu: drm: gma500: remove dead code")
Signed-off-by: Arnd Bergmann 
---
 drivers/gpu/drm/gma500/mdfld_tpo_vid.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/gpu/drm/gma500/mdfld_tpo_vid.c 
b/drivers/gpu/drm/gma500/mdfld_tpo_vid.c
index d40628e6810d..a9420bf9a419 100644
--- a/drivers/gpu/drm/gma500/mdfld_tpo_vid.c
+++ b/drivers/gpu/drm/gma500/mdfld_tpo_vid.c
@@ -30,8 +30,6 @@
 static struct drm_display_mode *tpo_vid_get_config_mode(struct drm_device *dev)
 {
struct drm_display_mode *mode;
-   struct drm_psb_private *dev_priv = dev->dev_private;
-   struct oaktrail_timing_info *ti = _priv->gct_data.DTD;
 
mode = kzalloc(sizeof(*mode), GFP_KERNEL);
if (!mode)
-- 
2.9.0

Documenting sigaltstack SS_AUTODISRM

[Michael Kerrisk (man-pages)]

Stas,

I have attempted to document the SS_AUTODISARM feature that you added
in Linux 4.7.

Could you please take a look at the SS_AUTODISARM pieces in the
sigaltstack() man page below? There is also one FIXME that I would
like help with.

It seems to me that the API has become rather odd now. It is no longer
possible to simply check whether code is executing on an alternative
stack by using

sigaltstack(NULL, _ss);
if (old_ss.ss_flags & SS_ONSTACK)


Thanks,

Michael


NAME
   sigaltstack - set and/or get signal stack context

SYNOPSIS
   #include 

   int sigaltstack(const stack_t *ss, stack_t *old_ss);

   FeatureTestMacro   Requirements   for   glibc   (see   fea‐
   ture_test_macros(7)):

   sigaltstack():
   _XOPEN_SOURCE >= 500
   || /* Since glibc 2.12: */ _POSIX_C_SOURCE >= 200809L
   || /* Glibc versions <= 2.19: */ _BSD_SOURCE

DESCRIPTION
   sigaltstack() allows a process to define a new alternate signal
   stack and/or retrieve the state of an existing alternate signal
   stack.  An alternate signal stack is used during the  execution
   of  a  signal handler if the establishment of that handler (see
   sigaction(2)) requested it.

   The normal sequence of events for  using  an  alternate  signal
   stack is the following:

   1. Allocate an area of memory to be used for the alternate sig‐
  nal stack.

   2. Use sigaltstack() to inform the system of the existence  and
  location of the alternate signal stack.

   3. When  establishing  a  signal  handler  using  sigaction(2),
  inform the system that the signal handler should be executed
  on  the  alternate signal stack by specifying the SA_ONSTACK
  flag.

   The ss argument is used  to  specify  a  new  alternate  signal
   stack,  while  the old_ss argument is used to retrieve informa‐
   tion about the currently established signal stack.  If  we  are
   interested  in  performing  just  one  of these tasks, then the
   other argument can be specified as NULL.

   The stack_t type used to type the arguments of this function is
   defined as follows:

   typedef struct {
   void  *ss_sp; /* Base address of stack */
   intss_flags;  /* Flags */
   size_t ss_size;   /* Number of bytes in stack */
   } stack_t;

   To  establish  a new alternate signal stack, the fields of this
   structure are set as follows:

   ss.ss_flags
  This field contains either 0, or the following flag:

  SS_AUTODISARM (since Linux 4.7)
 Clear the  alternate  signal  stack  settings  on
 entry  to  the  signal  handler.  When the signal
 handler returns, the  previous  alternate  signal
 stack settings are restored.

 This  flag  was  added  in  order make it safe to
 switch away from the signal handler with swapcon‐
 text(3).   Without this flag, a subsequently han‐
 dled  signal  will  corrupt  the  state  of   the
 switched-away  signal  handler.  On kernels where
 this flag is not supported,  sigaltstack()  fails
 with the error EINVAL when this flag is supplied.

   ss.ss_sp
  This  field specifies the starting address of the stack.
  When a signal handler is invoked on the alternate stack,
  the  kernel  automatically  aligns  the address given in
  ss.ss_sp to a suitable address boundary for the underly‐
  ing hardware architecture.

   ss.ss_size
  This  field  specifies  the size of the stack.  The con‐
  stant SIGSTKSZ is defined to be large  enough  to  cover
  the  usual  size  requirements  for  an alternate signal
  stack, and the constant MINSIGSTKSZ defines the  minimum
  size required to execute a signal handler.

   To  disable  an  existing stack, specify ss.ss_flags as SS_DIS‐
   ABLE.  In this case, the kernel  ignores  any  other  flags  in
   ss.ss_flags and the remaining fields in ss.

   If  old_ss  is  not NULL, then it is used to return information
   about the alternate signal stack which was in effect  prior  to
   the call to sigaltstack().  The old_ss.ss_sp and old_ss.ss_size
   fields return the starting address and size of that stack.  The
   old_ss.ss_flags may return either of the following values:

   SS_ONSTACK
  The process is currently executing on the alternate sig‐
  nal stack.  (Note that it is not possible to change  the
  alternate  signal stack if the process is currently exe‐
  cuting on it.)

   SS_DISABLE
 

Re: [PATCH 02/24] thunderbolt: Do not try to read UID if DROM offset is read as 0

[Mika Westerberg]

On Mon, May 22, 2017 at 08:41:22PM +0200, Andreas Noever wrote:
> Yes there is a check for the root switch, but also one that checks the
> return code of tb_drom_read_uid_only :)
> 
> err = tb_drom_read_uid_only(sw, );
> if (err) {
> tb_sw_warn(sw, "uid read failed\n");
> return err;
> }
> if (sw != sw->tb->root_switch && sw->uid != uid) {
> 
> 
> The reason it works on the Mac is because drom_offset is not 0, so the
> new branch in tb_drom_read_uid_only is not taken. Probably this is the
> case for all Cactus Ridge models and Alpine Ridge doesn't go there
> since it uses the ICM? 

Yes in case of ICM we don't call the function at all.

> Still it wouldn't hurt to only read the uid if
> sw != root_switch, the value is not used if sw == root_switch.

I agree. I'll update the code so that it will only read and check UID
when we are not dealing with the root switch.

Re: [4.11 regression] su / sudo doesn't work when enlightenment is running as the window manager

[Takashi Iwai]

On Mon, 22 May 2017 22:24:17 +0200,
Eric W. Biederman wrote:
> 
> Takashi Iwai  writes:
> 
> > Hi Eric,
> >
> > we've got a bug report showing the weird behavior supposedly triggered
> > by your commit 20523132ec5d ("exec: Test the ptracer's saved cred to
> > see if the tracee can gain caps").  In short, user can't run su or
> > sudo any longer when a terminal is started from Enlighentment window
> > manager.
> >
> > Some details are found in openSUSE Bugzilla:
> >   https://bugzilla.suse.com/show_bug.cgi?id=1040041
> >
> > and more in gentoo forum and Enlightenment bug tracker:
> >   
> > https://forums.gentoo.org/viewtopic-t-1063022-postdays-0-postorder-asc-start-0.html
> >   https://phab.enlightenment.org/T5470
> >
> > As the bug seems solely in Enlightenment, it might that be some its
> > specific patch is broken.  But a regression is a regression, after
> > all...
> >
> > Could you take a look at the issue?
> 
> I will.
> 
> I am wondering if the bisect did not quite go back far enough as that
> change really should have been had no effect and it was the introduction
> of the ptracer_capable test that is causing problems.
> 
> To be able to think this through clearly I really need to understand
> what enlightenment-start is doing.
> 
> At first glance the reported behavior does seem corect.  If you are not
> root and you are ptracing a setuid-root application it should not have
> be run setuid.
> 
> So either I made a stilly mistake somewhere or enlightenment is doing
> something problematic.  The ugly possibility is that I might have closed
> a security hole they were depending upon by accident.
> 
> I took a quick look at what I think is the code to enlightment_start.
> AKA src/bin/e_start_main.c
> 
> And all it does is:
>   pid = fork();
> if (pid == 0) {
>   /* child */
> ptrace(PT_TRACE_ME, 0, NULL);
> } else {
>   ptrace(PT_ATTACH, pid, NULL, NULL);
> ...;
> }
> 
> So the tracer_cred should be the same on either path.
> 
> So if someone who understands what enlightenment is doing could boil
> this down or otherwise help me understand exactly what kind of ptrace
> interaction is causing this problem that would really help.
> 
> Hmm. You know I think I know what is going on and it is a bit
> embarrasing:
> 
> Can someone please test this change?  I am guessing I just forgot to zero
> ptracer_cred on fork...  Why ptrace_init_task lives in a header
> instead of in kernel/fork.c I do not know.

Thanks for a prompt reaction!

I'll prepare a test kernel and ask reporters giving it a try.


Takashi

> 
> diff --git a/include/linux/ptrace.h b/include/linux/ptrace.h
> index 422bc2e4cb6a..a31442c4b272 100644
> --- a/include/linux/ptrace.h
> +++ b/include/linux/ptrace.h
> @@ -202,6 +202,7 @@ static inline void ptrace_init_task(struct task_struct 
> *child, bool ptrace)
> INIT_LIST_HEAD(>ptraced);
> child->jobctl = 0;
> child->ptrace = 0;
> +   child->ptracer_cred = NULL;
> child->parent = child->real_parent;
>  
> if (unlikely(ptrace) && current->ptrace) {
> 
> Eric
> 

Re: [PATCH 1/3] mm/slub: Only define kmalloc_large_node_hook() for NUMA systems

[Matthias Kaehlcke]

El Mon, May 22, 2017 at 01:39:26PM -0700 David Rientjes ha dit:

> On Fri, 19 May 2017, Matthias Kaehlcke wrote:
> 
> > The function is only used when CONFIG_NUMA=y. Placing it in an #ifdef
> > block fixes the following warning when building with clang:
> > 
> > mm/slub.c:1246:20: error: unused function 'kmalloc_large_node_hook'
> > [-Werror,-Wunused-function]
> > 
> 
> Is clang not inlining kmalloc_large_node_hook() for some reason?  I don't 
> think this should ever warn on gcc.

clang warns about unused static inline functions outside of header
files, in difference to gcc.

> > Signed-off-by: Matthias Kaehlcke 
> 
> Acked-by: David Rientjes 
> 
> > ---
> >  mm/slub.c | 3 +++
> >  1 file changed, 3 insertions(+)
> > 
> > diff --git a/mm/slub.c b/mm/slub.c
> > index 57e5156f02be..66e1046435b7 100644
> > --- a/mm/slub.c
> > +++ b/mm/slub.c
> > @@ -1313,11 +1313,14 @@ static inline void dec_slabs_node(struct kmem_cache 
> > *s, int node,
> >   * Hooks for other subsystems that check memory allocations. In a typical
> >   * production configuration these hooks all should produce no code at all.
> >   */
> > +
> > +#ifdef CONFIG_NUMA
> >  static inline void kmalloc_large_node_hook(void *ptr, size_t size, gfp_t 
> > flags)
> >  {
> > kmemleak_alloc(ptr, size, 1, flags);
> > kasan_kmalloc_large(ptr, size, flags);
> >  }
> > +#endif
> >  
> >  static inline void kfree_hook(const void *x)
> >  {

Re: [PULL REQUEST] i2c for 4.12

[Wolfram Sang]

> Confirmed. Initializing those fields to zero fixes it.

Thanks!



signature.asc
Description: PGP signature

Re: Build regressions/improvements in v4.12-rc2

[Arnd Bergmann]

On Mon, May 22, 2017 at 8:46 PM, John David Anglin  wrote:
> On 2017-05-22, at 5:49 AM, Geert Uytterhoeven wrote:
>
>>> [Deleted 1166 lines about "warning: -ffunction-sections disabled; it makes 
>>> profiling impossible [enabled by default]" on parisc-allmodconfig]
>
> Although this issue may be fixed in gcc, do we really want to enable 
> profiling by default?

This is ftrace, which uses the same compiler flag as gprof, and the option
is only enabled in allmodconfig, which seems reasonable.

   Arnd

Re: [HMM 08/15] mm/ZONE_DEVICE: special case put_page() for device private pages

[Jerome Glisse]

On Mon, May 22, 2017 at 01:19:29PM -0700, Dan Williams wrote:
> On Mon, May 22, 2017 at 1:14 PM, Jerome Glisse  wrote:
> > On Mon, May 22, 2017 at 12:29:53PM -0700, Dan Williams wrote:
> >> On Mon, May 22, 2017 at 9:51 AM, Jérôme Glisse  wrote:
> >> > A ZONE_DEVICE page that reach a refcount of 1 is free ie no longer
> >> > have any user. For device private pages this is important to catch
> >> > and thus we need to special case put_page() for this.
> >> >
> >> > Signed-off-by: Jérôme Glisse 
> >> > Cc: Kirill A. Shutemov 
> >> > Cc: Dan Williams 
> >> > Cc: Ross Zwisler 
> >> > ---
> >> >  include/linux/mm.h | 30 ++
> >> >  kernel/memremap.c  |  1 -
> >> >  2 files changed, 30 insertions(+), 1 deletion(-)
> >> >
> >> > diff --git a/include/linux/mm.h b/include/linux/mm.h
> >> > index a825dab..11f7bac 100644
> >> > --- a/include/linux/mm.h
> >> > +++ b/include/linux/mm.h
> >> > @@ -23,6 +23,7 @@
> >> >  #include 
> >> >  #include 
> >> >  #include 
> >> > +#include 
> >> >
> >> >  struct mempolicy;
> >> >  struct anon_vma;
> >> > @@ -795,6 +796,20 @@ static inline bool is_device_private_page(const 
> >> > struct page *page)
> >> > return ((page_zonenum(page) == ZONE_DEVICE) &&
> >> > (page->pgmap->type == MEMORY_DEVICE_PRIVATE));
> >> >  }
> >> > +
> >> > +static inline void put_zone_device_private_page(struct page *page)
> >> > +{
> >> > +   int count = page_ref_dec_return(page);
> >> > +
> >> > +   /*
> >> > +* If refcount is 1 then page is freed and refcount is stable as 
> >> > nobody
> >> > +* holds a reference on the page.
> >> > +*/
> >> > +   if (count == 1)
> >> > +   page->pgmap->page_free(page, page->pgmap->data);
> >> > +   else if (!count)
> >> > +   __put_page(page);
> >> > +}
> >> >  #else
> >> >  static inline bool is_zone_device_page(const struct page *page)
> >> >  {
> >> > @@ -805,6 +820,10 @@ static inline bool is_device_private_page(const 
> >> > struct page *page)
> >> >  {
> >> > return false;
> >> >  }
> >> > +
> >> > +static inline void put_zone_device_private_page(struct page *page)
> >> > +{
> >> > +}
> >> >  #endif
> >> >
> >> >  static inline void get_page(struct page *page)
> >> > @@ -822,6 +841,17 @@ static inline void put_page(struct page *page)
> >> >  {
> >> > page = compound_head(page);
> >> >
> >> > +   /*
> >> > +* For private device pages we need to catch refcount transition 
> >> > from
> >> > +* 2 to 1, when refcount reach one it means the private device 
> >> > page is
> >> > +* free and we need to inform the device driver through 
> >> > callback. See
> >> > +* include/linux/memremap.h and HMM for details.
> >> > +*/
> >> > +   if (unlikely(is_device_private_page(page))) {
> >>
> >> Since I presume HMM is a niche use case can we make this a
> >> "static_branch_unlikely(_key) && is_device_private_page(page))"?
> >> That way non-hmm platforms see minimal overhead.
> >
> > Like i said in the cover letter i am bit anxious about doing for
> 
> I don't think you copied me on the cover letter.
> 
> > an inline function. I don't see any existing case for inline
> > function and static key. Is that suppose to work ?
> >
> > How widespread HMM use will be is hard to guess. Usual chicken
> > and egg plus adoption thing. If GPGPU compte keeps growing and
> > it seems it does then HMM likely gonna be enable and actively
> > use for large chunk of those computer that have GPGPU workload.
> >
> > I will test a static key of that branch and see if it explodes
> > because put_page() is an inline function.
> 
> memcpy_mcsafe() is an existing example of a static inline with a
> static branch. Hasn't seemed to have caused any problems to date.

Ok i will post a new version of 08 with static keys, i shouldn't
need to repost any other patches for that. Andrew that's fine
with you or do you prefer me to repost a full updated patchset ?

Cheers,
Jérôme

Re: [PATCH 7/7] DWARF: add the config option

[H. Peter Anvin]

On 05/22/17 04:12, Ingo Molnar wrote:
\>>
>> This construct might be useful for other arches, which is why I called
>> it "FP" instead of "BP".  But then I ruined that with the last 3 :-)
> 
> Please call it BP - 'FP' can easily be read as floating-point, making it all 
> super-confusing. We should use canonical x86 register names and ordering - 
> even
> if not all registers are used straight away.
> 

Seriously, I suspect that at the end of the day we will have reinvented
DWARF.

-hpa

Re: [PATCH] zlib: Put get_unaligned16() inside #ifdef block

[Matthias Kaehlcke]

Hi Andrew,

El Mon, May 22, 2017 at 02:39:25PM -0700 Andrew Morton ha dit:

> On Mon, 22 May 2017 14:13:26 -0700 Matthias Kaehlcke  
> wrote:
> 
> > The function is not used when CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS=y.
> > Adding the #ifdef fixes the following warning when building with clang:
> > 
> > lib/zlib_inflate/inffast.c:31:1: error: unused function 'get_unaligned16'
> > [-Werror,-Wunused-function]
> > 
> > ...
> >
> > --- a/lib/zlib_inflate/inffast.c
> > +++ b/lib/zlib_inflate/inffast.c
> > @@ -26,6 +26,7 @@ union uu {
> > unsigned char b[2];
> >  };
> >  
> > +#ifndef CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS
> >  /* Endian independed version */
> >  static inline unsigned short
> >  get_unaligned16(const unsigned short *p)
> > @@ -37,6 +38,7 @@ get_unaligned16(const unsigned short *p)
> > mm.b[1] = b[1];
> > return mm.us;
> >  }
> > +#endif
> >  
> >  #ifdef POSTINC
> >  #  define OFF 0
> 
> Do we really want to mucky up the source code to keep clang happy?  gcc
> won't warn about an unused static inline.  Can we configure clang to do
> the same?

To my knowledge there is no option to tell clang to behave like gcc in
this aspect.

On the positive side the number of instances is relatively limited, at
least for defconfig and my custom configs. In most cases it is enough
with adding __maybe_unused, which is already widely used in the kernel.

Personally I think it is useful to be warned about unused functions in
.c files, regardless of whether the function is inline or not.

Re: [PATCH v4 next 1/3] modules:capabilities: allow __request_module() to take a capability argument

[Kees Cook]

On Mon, May 22, 2017 at 4:57 AM, Djalal Harouni  wrote:
> This is a preparation patch for the module auto-load restriction feature.
>
> In order to restrict module auto-load operations we need to check if the
> caller has CAP_SYS_MODULE capability. This allows to align security
> checks of automatic module loading with the checks of the explicit operations.
>
> However for "netdev-%s" modules, they are allowed to be loaded if
> CAP_NET_ADMIN is set. Therefore, in order to not break this assumption,
> and allow userspace to only load "netdev-%s" modules with CAP_NET_ADMIN
> capability which is considered a privileged operation, we have two
> choices: 1) parse "netdev-%s" alias and check the capability or 2) hand
> the capability form request_module() to security_kernel_module_request()
> hook and let the capability subsystem decide.
>
> After a discussion with Rusty Russell [1], the suggestion was to pass
> the capability from request_module() to security_kernel_module_request()
> for 'netdev-%s' modules that need CAP_NET_ADMIN.
>
> The patch does not update request_module(), it updates the internal
> __request_module() that will take an extra "allow_cap" argument. If
> positive, then automatic module load operation can be allowed.

I find this refactor slightly confusing. I would expect to collapse
the existing caps checks in net/core/dev_ioctl.c and
net/ipv4/tcp_cong.c, and make this a "required cap" argument, and to
add a new non-__ function instead of requiring callers use
__request_module.

request_module_capable(int cap_required, fmt, args);

adjust __request_module() for the new arg, and when cap_required !=
-1, perform a cap check.

Then make request_module pass -1 to __request_module(), and change
dev_ioctl.c (and tcp_cong.c) from:

if (no_module && capable(CAP_NET_ADMIN))
no_module = request_module("netdev-%s", name);
if (no_module && capable(CAP_SYS_MODULE))
request_module("%s", name);

to:

if (no_module)
no_module = request_module_capable(CAP_NET_ADMIN,
"netdev-%s", name);
if (no_module)
no_module = request_module_capable(CAP_SYS_MODULE, "%s", name);

that'll make the code cleaner, too.

> __request_module() will be only called by networking code which is the
> exception to this, so we do not break userspace and CAP_NET_ADMIN can
> continue to load 'netdev-%s' modules. Other kernel code should continue
> to use request_module() which calls security_kernel_module_request() and
> will check for CAP_SYS_MODULE capability in next patch. Allowing more
> control on who can trigger automatic module loading.
>
> This patch updates security_kernel_module_request() to take the
> 'allow_cap' argument and SELinux which is currently the only user of
> security_kernel_module_request() hook.
>
> Based on patch by Rusty Russell:
> https://lkml.org/lkml/2017/4/26/735
>
> Cc: Serge Hallyn 
> Cc: Andy Lutomirski 
> Suggested-by: Rusty Russell 
> Suggested-by: Kees Cook 
> Signed-off-by: Djalal Harouni 
>
> [1] https://lkml.org/lkml/2017/4/24/7
> ---
>  include/linux/kmod.h  | 15 ---
>  include/linux/lsm_hooks.h |  4 +++-
>  include/linux/security.h  |  4 ++--
>  kernel/kmod.c | 15 +--
>  net/core/dev_ioctl.c  | 10 +-
>  security/security.c   |  4 ++--
>  security/selinux/hooks.c  |  2 +-
>  7 files changed, 38 insertions(+), 16 deletions(-)
>
> diff --git a/include/linux/kmod.h b/include/linux/kmod.h
> index c4e441e..a314432 100644
> --- a/include/linux/kmod.h
> +++ b/include/linux/kmod.h
> @@ -32,18 +32,19 @@
>  extern char modprobe_path[]; /* for sysctl */
>  /* modprobe exit status on success, -ve on error.  Return value
>   * usually useless though. */
> -extern __printf(2, 3)
> -int __request_module(bool wait, const char *name, ...);
> -#define request_module(mod...) __request_module(true, mod)
> -#define request_module_nowait(mod...) __request_module(false, mod)
> +extern __printf(3, 4)
> +int __request_module(bool wait, int allow_cap, const char *name, ...);
>  #define try_then_request_module(x, mod...) \
> -   ((x) ?: (__request_module(true, mod), (x)))
> +   ((x) ?: (__request_module(true, -1, mod), (x)))
>  #else
> -static inline int request_module(const char *name, ...) { return -ENOSYS; }
> -static inline int request_module_nowait(const char *name, ...) { return 
> -ENOSYS; }
> +static inline __printf(3, 4)
> +int __request_module(bool wait, int allow_cap, const char *name, ...)
> +{ return -ENOSYS; }
>  #define try_then_request_module(x, mod...) (x)
>  #endif
>
> +#define request_module(mod...) __request_module(true, -1, mod)
> +#define request_module_nowait(mod...) __request_module(false, -1, mod)
>
>  struct cred;
>  struct file;
> diff --git a/include/linux/lsm_hooks.h b/include/linux/lsm_hooks.h
> index f7914d9..7688f79 

Re: [PATCH v3 1/5] sysctl: fix lax sysctl_check_table() sanity check

[Andrew Morton]

On Thu, 18 May 2017 20:35:50 -0700 "Luis R. Rodriguez"  
wrote:

> Commit 7c60c48f58a7 ("sysctl: Improve the sysctl sanity checks")
> improved sanity checks considerbly, however the enhancements on
> sysctl_check_table() meant adding a functional change so that
> only the last table entry's sanity error is propagated. It also
> changed the way errors were propagated so that each new check
> reset the err value, this means only last sanity check computed
> is used for an error. This has been in the kernel since v3.4 days.
> 
> Fix this by carrying on errors from previous checks and iterations
> as we traverse the table and ensuring we keep any error from previous
> checks. We keep iterating on the table even if an error is found so
> we can complain for all errors found in one shot. This works as
> -EINVAL is always returned on error anyway, and the check for error
> is any non-zero value.
> 
> ...
>
> --- a/fs/proc/proc_sysctl.c
> +++ b/fs/proc/proc_sysctl.c
> @@ -1066,7 +1066,7 @@ static int sysctl_check_table(const char *path, struct 
> ctl_table *table)
>   int err = 0;
>   for (; table->procname; table++) {
>   if (table->child)
> - err = sysctl_err(path, table, "Not a file");
> + err |= sysctl_err(path, table, "Not a file");
>  
>   if ((table->proc_handler == proc_dostring) ||
>   (table->proc_handler == proc_dointvec) ||
> @@ -1078,15 +1078,15 @@ static int sysctl_check_table(const char *path, 
> struct ctl_table *table)
>   (table->proc_handler == proc_doulongvec_minmax) ||
>   (table->proc_handler == proc_doulongvec_ms_jiffies_minmax)) 
> {
>   if (!table->data)
> - err = sysctl_err(path, table, "No data");
> + err |= sysctl_err(path, table, "No data");
>   if (!table->maxlen)
> - err = sysctl_err(path, table, "No maxlen");
> + err |= sysctl_err(path, table, "No maxlen");
>   }
>   if (!table->proc_handler)
> - err = sysctl_err(path, table, "No proc_handler");
> + err |= sysctl_err(path, table, "No proc_handler");
>  
>   if ((table->mode & (S_IRUGO|S_IWUGO)) != table->mode)
> - err = sysctl_err(path, table, "bogus .mode 0%o",
> + err |= sysctl_err(path, table, "bogus .mode 0%o",
>   table->mode);
>   }
>   return err;

glumpf.  I'm not a fan of this err|=foo() trick - if foo() returns
different errnos we can a mangled result.  This patch assumes that
syscal_err() will only ever return a single errno.

I guess we're safe enough in this case but still... ugh.

[PATCH] crypto: rng: Remove unused function __crypto_rng_cast()

[Matthias Kaehlcke]

This fixes the following warning when building with clang:

crypto/rng.c:35:34: error: unused function '__crypto_rng_cast'
[-Werror,-Wunused-function]

Signed-off-by: Matthias Kaehlcke 
---
 crypto/rng.c | 5 -
 1 file changed, 5 deletions(-)

diff --git a/crypto/rng.c b/crypto/rng.c
index f46dac5288b9..5e8469244960 100644
--- a/crypto/rng.c
+++ b/crypto/rng.c
@@ -33,11 +33,6 @@ struct crypto_rng *crypto_default_rng;
 EXPORT_SYMBOL_GPL(crypto_default_rng);
 static int crypto_default_rng_refcnt;
 
-static inline struct crypto_rng *__crypto_rng_cast(struct crypto_tfm *tfm)
-{
-   return container_of(tfm, struct crypto_rng, base);
-}
-
 int crypto_rng_reset(struct crypto_rng *tfm, const u8 *seed, unsigned int slen)
 {
u8 *buf = NULL;
-- 
2.13.0.303.g4ebf302169-goog

Re: [PATCH v2 1/7] kernel/locking: Fix compile error with qrwlock.c

[David Miller]

From: Babu Moger 
Date: Mon, 22 May 2017 16:57:39 -0500

> I will update the patch set with the above information. Does that
> work?

Yes it does, I didn't realize there were multiple problems.

Thanks.

Re: [kernel-hardening] [PATCH v4 next 0/3] modules: automatic module loading restrictions

[Kees Cook]

On Mon, May 22, 2017 at 12:55 PM, Djalal Harouni  wrote:
> On Mon, May 22, 2017 at 6:43 PM, Solar Designer  wrote:
>> On Mon, May 22, 2017 at 03:49:15PM +0200, Djalal Harouni wrote:
>>> On Mon, May 22, 2017 at 2:08 PM, Solar Designer  wrote:
>>> > On Mon, May 22, 2017 at 01:57:03PM +0200, Djalal Harouni wrote:
>>> >> *) When modules_autoload_mode is set to (2), automatic module loading is
>>> >> disabled for all. Once set, this value can not be changed.
>>> >
>>> > What purpose does this securelevel-like property ("Once set, this value
>>> > can not be changed.") serve here?  I think this mode 2 is needed, but
>>> > without this extra property, which is bypassable by e.g. explicitly
>>> > loaded kernel modules anyway (and that's OK).
>>>
>>> My reasoning about "Once set, this value can not be changed" is mainly for:
>>>
>>> If you have some systems where modules are not updated for any given
>>> reason, then the only one who will be able to load a module is an
>>> administrator, basically this is a shortcut for:
>>>
>>> * Apps/services can run with CAP_NET_ADMIN but they are not allowed to
>>> auto-load 'netdev' modules.
>>>
>>> * Explicitly loading modules can be guarded by seccomp filters *per*
>>> app, so even if these apps have
>>>   CAP_SYS_MODULE they won't be able to explicitly load modules, one
>>> has to remount some sysctl /proc/ entries read-only here and remove
>>> CAP_SYS_ADMIN for all apps anyway.
>>>
>>> This mainly serves the purpose of these systems that do not receive
>>> updates, if I don't want to expose those kernel interfaces what should
>>> I do ? then if I want to unload old versions and replace them with new
>>> ones what operation should be allowed ? and only real root of the
>>> system can do it. Hence, the "Once set, this value can not be changed"
>>> is more of a shortcut, also the idea was put in my mind based on how
>>> "modules_disabled" is disabled forever, and some other interfaces. I
>>> would say: it is easy to handle a transition from 1) "hey this system
>>> is still up to date, some features should be exposed" to 2) "this
>>> system is not up to date anymore, only root should expose some
>>> features..."
>>>
>>> Hmm, I am not sure if this answers your question ? :-)
>>
>> This answers my question, but in a way that I summarize as "there's no
>> good reason to include this securelevel-like property".
>>
>
> Hmm, sorry I did forget to add in my previous comment that with such
> systems, CAP_SYS_MODULE can be used to reset the
> "modules_autoload_mode" sysctl back from mode 2 to mode 1, even if we
> disable it privileged tasks can be triggered to overwrite the sysctl
> flag and get it back unless /proc is read-only... that's one of the
> points, it should not be so easy to relax it.

I'm on the fence. For modules_disabled and Yama, it was tied to
CAP_SYS_ADMIN, basically designed to be a at-boot setting that could
not later be undone by an attacker gaining that privilege, keeping
them out of either kernel memory or existing user process memory.
Here, it's CAP_SYS_MODULE... it's hard to imagine the situation where
a CAP_SYS_MODULE-capable process could write to this sysctl but NOT
issue direct modprobe requests, but it's _possible_ via crazy symlink
games to trick capable processes into writing to sysctls. We've seen
this multiple times before, and it's a way for attackers to turn a
single privileged write into a privileged exec.

I might turn the question around, though: why would we want to have it
changeable at this setting?

I'm fine leaving that piece off, either way.

-Kees

-- 
Kees Cook
Pixel Security

[PATCH 1/2] staging: vt6655: replace NULL comparison with '!' operator

[Marko Stankovic]

Fix comparison to NULL issues reported by checkpatch.pl

Signed-off-by: Marko Stankovic 
---
 drivers/staging/vt6655/device_main.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/vt6655/device_main.c 
b/drivers/staging/vt6655/device_main.c
index da0f71191009..1c652f0ff3ba 100644
--- a/drivers/staging/vt6655/device_main.c
+++ b/drivers/staging/vt6655/device_main.c
@@ -157,7 +157,7 @@ static void vt6655_remove(struct pci_dev *pcid)
 {
struct vnt_private *priv = pci_get_drvdata(pcid);
 
-   if (priv == NULL)
+   if (!priv)
return;
device_free_info(priv);
 }
@@ -453,7 +453,7 @@ static bool device_init_rings(struct vnt_private *priv)
   priv->opts.tx_descs[0] * sizeof(struct 
vnt_tx_desc) +
   priv->opts.tx_descs[1] * sizeof(struct 
vnt_tx_desc),
   >pool_dma, GFP_ATOMIC);
-   if (vir_pool == NULL) {
+   if (!vir_pool) {
dev_err(>pcid->dev, "allocate desc dma memory failed\n");
return false;
}
-- 
2.11.0

[PATCH 2/2] staging: vt6655: remove unnecessary blank lines

[Marko Stankovic]

Fix unnecessary blank lines issues reported by checkpatch.pl

Signed-off-by: Marko Stankovic 
---
 drivers/staging/vt6655/device_main.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/staging/vt6655/device_main.c 
b/drivers/staging/vt6655/device_main.c
index 1c652f0ff3ba..78804eaec608 100644
--- a/drivers/staging/vt6655/device_main.c
+++ b/drivers/staging/vt6655/device_main.c
@@ -1018,7 +1018,6 @@ static void vnt_interrupt_process(struct vnt_private 
*priv)
}
 
/* TODO: adhoc PS mode */
-
}
 
if (isr & ISR_BNTX) {
@@ -1702,7 +1701,6 @@ static int vt6655_suspend(struct pci_dev *pcid, 
pm_message_t state)
 
 static int vt6655_resume(struct pci_dev *pcid)
 {
-
pci_set_power_state(pcid, PCI_D0);
pci_enable_wake(pcid, PCI_D0, 0);
pci_restore_state(pcid);
-- 
2.11.0

Re: [PATCH v3] add the option of fortified string.h functions

[Kees Cook]

On Mon, May 22, 2017 at 4:10 PM, Daniel Micay  wrote:
> This adds support for compiling with a rough equivalent to the glibc
> _FORTIFY_SOURCE=1 feature, providing compile-time and runtime buffer
> overflow checks for string.h functions when the compiler determines the
> size of the source or destination buffer at compile-time. Unlike glibc,
> it covers buffer reads in addition to writes.
>
> GNU C __builtin_*_chk intrinsics are avoided because they would force a
> much more complex implementation. They aren't designed to detect read
> overflows and offer no real benefit when using an implementation based
> on inline checks. Inline checks don't add up to much code size and allow
> full use of the regular string intrinsics while avoiding the need for a
> bunch of _chk functions and per-arch assembly to avoid wrapper overhead.
>
> This detects various overflows at compile-time in various drivers and
> some non-x86 core kernel code. There will likely be issues caught in
> regular use at runtime too.
>
> Future improvements left out of initial implementation for simplicity,
> as it's all quite optional and can be done incrementally:
>
> * Some of the fortified string functions (strncpy, strcat), don't yet
>   place a limit on reads from the source based on __builtin_object_size of
>   the source buffer.
>
> * Extending coverage to more string functions like strlcat.
>
> * It should be possible to optionally use __builtin_object_size(x, 1) for
>   some functions (C strings) to detect intra-object overflows (like
>   glibc's _FORTIFY_SOURCE=2), but for now this takes the conservative
>   approach to avoid likely compatibility issues.
>
> * The compile-time checks should be made available via a separate config
>   option which can be enabled by default (or always enabled) once enough
>   time has passed to get the issues it catches fixed.
>
> Signed-off-by: Daniel Micay 

Acked-by: Kees Cook 

This is great to have. While it was out-of-tree code, it would have
blocked at least CVE-2016-3858 from being exploitable (improper size
argument to strlcpy()). I've sent a number of fixes for
out-of-bounds-reads that this detected upstream already. If I can
collect Acks on this, I could carry it in the kspp tree for -next
along with any other fixes. Otherwise, perhaps it can go via -mm?

Thanks!

-Kees

> ---
> Changes since v2:
> - add fortified strlcpy
> - split the compile-time errors for reads and writes, and specify the 
> parameter
> - avoid redefinition of __NO_FORTIFY in KASan-uninstrumented code already 
> defining __NO_FORTIFY
>
>  arch/arm64/include/asm/string.h  |   5 +
>  arch/x86/boot/compressed/misc.c  |   5 +
>  arch/x86/include/asm/string_64.h |   5 +
>  include/linux/string.h   | 200 
> +++
>  lib/string.c |   6 ++
>  security/Kconfig |   6 ++
>  6 files changed, 227 insertions(+)
>
> diff --git a/arch/arm64/include/asm/string.h b/arch/arm64/include/asm/string.h
> index 2eb714c4639f..d0aa42907569 100644
> --- a/arch/arm64/include/asm/string.h
> +++ b/arch/arm64/include/asm/string.h
> @@ -63,6 +63,11 @@ extern int memcmp(const void *, const void *, size_t);
>  #define memcpy(dst, src, len) __memcpy(dst, src, len)
>  #define memmove(dst, src, len) __memmove(dst, src, len)
>  #define memset(s, c, n) __memset(s, c, n)
> +
> +#ifndef __NO_FORTIFY
> +#define __NO_FORTIFY /* FORTIFY_SOURCE uses __builtin_memcpy, etc. */
> +#endif
> +
>  #endif
>
>  #endif
> diff --git a/arch/x86/boot/compressed/misc.c b/arch/x86/boot/compressed/misc.c
> index b3c5a5f030ce..43691238a21d 100644
> --- a/arch/x86/boot/compressed/misc.c
> +++ b/arch/x86/boot/compressed/misc.c
> @@ -409,3 +409,8 @@ asmlinkage __visible void *extract_kernel(void *rmode, 
> memptr heap,
> debug_putstr("done.\nBooting the kernel.\n");
> return output;
>  }
> +
> +void fortify_panic(const char *name)
> +{
> +   error("detected buffer overflow");
> +}
> diff --git a/arch/x86/include/asm/string_64.h 
> b/arch/x86/include/asm/string_64.h
> index 733bae07fb29..3c5b26e07b85 100644
> --- a/arch/x86/include/asm/string_64.h
> +++ b/arch/x86/include/asm/string_64.h
> @@ -77,6 +77,11 @@ int strcmp(const char *cs, const char *ct);
>  #define memcpy(dst, src, len) __memcpy(dst, src, len)
>  #define memmove(dst, src, len) __memmove(dst, src, len)
>  #define memset(s, c, n) __memset(s, c, n)
> +
> +#ifndef __NO_FORTIFY
> +#define __NO_FORTIFY /* FORTIFY_SOURCE uses __builtin_memcpy, etc. */
> +#endif
> +
>  #endif
>
>  #define __HAVE_ARCH_MEMCPY_MCSAFE 1
> diff --git a/include/linux/string.h b/include/linux/string.h
> index 537918f8a98e..66dc841e4c5e 100644
> --- a/include/linux/string.h
> +++ b/include/linux/string.h
> @@ -187,4 +187,204 @@ static inline const char *kbasename(const char *path)
> return tail ? tail + 1 : path;
>  }
>
> +#define __FORTIFY_INLINE extern __always_inline 

Re: [PATCH v2 10/11] x86/mm: Be more consistent wrt PAGE_SHIFT vs PAGE_SIZE in tlb flush code

[Nadav Amit]

> 
>   /* Balance as user space task's flush, a bit conservative */
>   if (end == TLB_FLUSH_ALL ||
> - (end - start) > tlb_single_page_flush_ceiling * PAGE_SIZE) {
> + (end - start) > tlb_single_page_flush_ceiling >> PAGE_SHIFT) {

Shouldn’t it be << ?

Nadav

Re: [PATCH v3 4/5] drivers/perf: Add support for ARMv8.2 Statistical Profiling Extension

[Kim Phillips]

On Mon, 22 May 2017 17:22:12 +0100
Mark Rutland  wrote:

> On Mon, May 22, 2017 at 10:45:21AM -0500, Kim Phillips wrote:
> > On Mon, 22 May 2017 13:44:46 +0100
> > Mark Rutland  wrote:
> > > On Mon, May 22, 2017 at 07:32:49AM -0500, Kim Phillips wrote:
> > > > On Thu, 18 May 2017 18:24:32 +0100
> > > > Will Deacon  wrote:
> > > > > +/* Perf callbacks */
> > > > > +static int arm_spe_pmu_event_init(struct perf_event *event)
> > > > > +{
> > > > > + u64 reg;
> > > > > + struct perf_event_attr *attr = >attr;
> > > > > + struct arm_spe_pmu *spe_pmu = to_spe_pmu(event->pmu);
> > > > > +
> > > > > + /* This is, of course, deeply driver-specific */
> > > > > + if (attr->type != event->pmu->type)
> > > > > + return -ENOENT;
> > > > > +
> > > 
> > > [trimming other return sites]
> > 
> > Thanks but other conditions, such as the user specified sample period
> > check would be more appropriate to be left in for this discussion.
> 
> Sure, I was just trimming to a single example for brevity.  I appreciate
> there are cases where it may not be as simple to determine the cause
> from userspace today.

That helps, thanks.

> > > > I've consistently brought up lack of proper user error messaging in all
> > > > previous submissions of this driver:
> > > > 
> > > ... and we've consistently explained why logging such things to dmesg by
> > > default will not fly. As before, while we call these return codes error
> > > values, they are *not* errors in the same sense as pr_err().
> > 
> > I've expressed my disagreement to that matter here:
> >  
> > https://lkml.org/lkml/2017/4/7/223
> >  
> > yet it got no response.
> 
> That's not strictly true.
> 
> I replied to the mail you cited, attempting to clarify as best I could.
> You replied again, and it's true I didn't respond there, but there was
> no new substantiative argument. To summarize that thread, to the best of
> my understanding:
> 
> * We disagree on the semantic of "an error" in this context. Clearly we
>   aren't going to agree.

That's bad.  We ought to agree on what an error is, in this and any
other context.  I'm willing to listen if you have a convincing
argument, but none was given after my last reply:

"The driver is trying to report an error:  in the above example, it's
reporting that it cannot support an operation by returning
-*E*OPNOTSUPP: an ERROR because it was unable to complete the request:
the request failed.  Unlike e.g., a warning where something may not
have been quite right, but went along with executing the operation
anyway."

To put it another way, perf_event_open returning errno EINVAL is no
different than open() returning the same with the meaning 'Invalid
value in flags.'  In fact, the perf_event_open manpage says errors in
setting the sample frequency make the syscall return the error code -1
and EINVAL in errno.

Prior to that I see what might possibly be the underlying cause for the
discrepancy:  you said:

> > > The above cases are not (system) errors, and using dev_err (even
> > > ratelimited) is certainly not appropriate. These are pr_debug() at best.

So is it that you are resisting technically calling it an error because
that would imply we use pr_err() instead of pr_debug() perhaps?  In
which case, is that because of fuzzing?:

quoting you again:

"There are some cases where they're actively harmful (e.g. when fuzzing)."

to which my response remains:

"I'd expect fuzzer users to be more amenable to manually modifying the
driver rather than regular users of the driver."

to which your then-response was seemingly irrelevant, and against the
benefit of normal user of the driver:

"When fuzzing, I take a mainline, defconfig kernel, and run it through
its paces. I don't touch each and every driver."

If this is the case, can we find another solution to make both regular
fuzzer runners and regular users happy?

> * We agree that error reporting and handling is painful in this area.
> 
> * We disagree w.r.t. using printk() and friends. My position has not
>   been swayed. 
> 
> [...]

I beg you to please reconsider, given we agree that this particular
syscall is bad, and the alternative (no messaging) will truly be worse
for our users.

> > > > AFAICT, my comments hold, yet the driver still gets resubmitted without
> > > > them being addressed.  How do we get out of this loop?
> > > 
> > > We've repeatedly explained why the approach you suggest is not feasible.
> > > Perhaps you could try to explain why our approach doesn't seem feasible
> > > to you.
> > 
> > I don't want SPE users to have to manually instrument the driver
> > in order to find out what it didn't like about the parameters they
> > specified.  This problem has already been reported by other early
> > adopters.  perf itself says "dmesg may provide additional information",
> > so let's please use it.
> 
> Sorry, but regardless of any argument there is to be had on how best to
> 

Re: Documenting sigaltstack SS_AUTODISRM

[Stas Sergeev]

22.05.2017 23:38, Michael Kerrisk (man-pages) пишет:

Stas,

I have attempted to document the SS_AUTODISARM feature that you added
in Linux 4.7.

Could you please take a look at the SS_AUTODISARM pieces in the
sigaltstack() man page below? There is also one FIXME that I would
like help with.

It seems to me that the API has become rather odd now. It is no longer
possible to simply check whether code is executing on an alternative
stack by using

 sigaltstack(NULL, _ss);
 if (old_ss.ss_flags & SS_ONSTACK)

You mean, if SS_AUTODISARM was previously used, right?
Because I don't think we broke the existing code, or did we?
I can vaguely recall that I was submitting the patches
that were returning SS_ONSTACK even when SS_AUTODISARM
was used, but they were considered too complex.
This is possible to implement, but the agreement was
that it is not a big deal.


ss.ss_flags
   This field contains either 0, or the following flag:

Is this correct?
AFAIK it can be SS_DISABLE too, and posix seems to allow any
other value for enable, which can be (on linux) SS_ONSTACK,
not only 0.
And SS_AUTODISARM can be ORed with the value.


   ┌─┐
   │FIXME│
   ├─┤
   │Was it intended that one  can  set  up  a  different │
   │alternative signal stack in this scenario? (In pass‐ │
   │ing,  if  one  does  this,   the   sigaltstack(NULL, │
   │_ss)  now returns old_ss.ss_flags==SS_AUTODISARM │
   │rather  than  old_ss.ss_flags==SS_DISABLE.  The  API │
   │design here seems confusing...   │
   └─┘

My memory may be wrong here, but I think setting
up another alt stack was not supposed because the
previous settings would be restored upon sighandler
return. AFAIK I was trying to make up a proposal to
get such attempts explicitly blocked rather than
silently ignored, but again the simplicity was chosen.


SS_AUTODISARM
   The  alternate  signal  stack  has  been  marked  to  be
   autodisarmed as described above.

Initially this flag was supposed to be ORed with
the old values. Your descrition is correct, but if
more bit flags are added, this may became a
problem, as you are always treating it as a separate
value, not a bit flag.

Re: [PATCH 1/3] mfd: dm355evm_msp: move header file out of I2C realm

[Dmitry Torokhov]

On Mon, May 22, 2017 at 12:02:08AM +0200, Wolfram Sang wrote:
> include/linux/i2c is not for client devices. Move the header file to a
> more appropriate location.
> 
> Signed-off-by: Wolfram Sang 
> ---
>  drivers/input/misc/dm355evm_keys.c| 2 +-

Acked-by: Dmitry Torokhov 

>  drivers/mfd/dm355evm_msp.c| 2 +-
>  drivers/rtc/rtc-dm355evm.c| 2 +-
>  include/linux/{i2c => mfd}/dm355evm_msp.h | 0
>  4 files changed, 3 insertions(+), 3 deletions(-)
>  rename include/linux/{i2c => mfd}/dm355evm_msp.h (100%)
> 
> diff --git a/drivers/input/misc/dm355evm_keys.c 
> b/drivers/input/misc/dm355evm_keys.c
> index bab256ef32b9b3..c803db64a3760d 100644
> --- a/drivers/input/misc/dm355evm_keys.c
> +++ b/drivers/input/misc/dm355evm_keys.c
> @@ -15,7 +15,7 @@
>  #include 
>  #include 
>  
> -#include 
> +#include 
>  #include 
>  
>  
> diff --git a/drivers/mfd/dm355evm_msp.c b/drivers/mfd/dm355evm_msp.c
> index 86eca614507bd8..2a2756709f22f0 100644
> --- a/drivers/mfd/dm355evm_msp.c
> +++ b/drivers/mfd/dm355evm_msp.c
> @@ -18,7 +18,7 @@
>  #include 
>  #include 
>  #include 
> -#include 
> +#include 
>  
>  
>  /*
> diff --git a/drivers/rtc/rtc-dm355evm.c b/drivers/rtc/rtc-dm355evm.c
> index f225cd873ff6c2..97d8259b94940f 100644
> --- a/drivers/rtc/rtc-dm355evm.c
> +++ b/drivers/rtc/rtc-dm355evm.c
> @@ -13,7 +13,7 @@
>  #include 
>  #include 
>  
> -#include 
> +#include 
>  #include 
>  
>  
> diff --git a/include/linux/i2c/dm355evm_msp.h 
> b/include/linux/mfd/dm355evm_msp.h
> similarity index 100%
> rename from include/linux/i2c/dm355evm_msp.h
> rename to include/linux/mfd/dm355evm_msp.h
> -- 
> 2.11.0
> 

-- 
Dmitry

Re: dm ioctl: Restore __GFP_HIGH in copy_params()

[Mike Snitzer]

On Mon, May 22 2017 at  4:35pm -0400,
David Rientjes  wrote:

> On Mon, 22 May 2017, Mike Snitzer wrote:
> 
> > > > The lvm2 was designed this way - it is broken, but there is not much 
> > > > that 
> > > > can be done about it - fixing this would mean major rewrite. The only 
> > > > thing we can do about it is to lower the deadlock probability with 
> > > > __GFP_HIGH (or PF_MEMALLOC that was used some times ago).
> > 
> > Yes, lvm2 was originally designed to to have access to memory reserves
> > to ensure forward progress.  But if the mm subsystem has improved to
> > allow for the required progress without lvm2 trying to stake a claim on
> > those reserves then we'll gladly avoid (ab)using them.
> > 
> 
> There is no such improvement to the page allocator when allocating at 
> runtime.  A persistent amount of memory in a mempool could be set aside as 
> a preallocation and unavailable from the rest of the system forever as an 
> alternative to dynamically allocating with memory reserves, but that has 
> obvious downsides.  This patch is the exact right thing to do.
> 
> > > But let me repeat. GFP_KERNEL allocation for order-0 page will not fail.
> > 
> > OK, but will it be serviced immediately?  Not failing isn't useful if it
> > never completes.
> > 
> 
> No, and you can use __GFP_HIGH, which this patch does, to have a 
> reasonable expectation of forward progress in the very near term.
> 
> > While adding the __GFP_NOFAIL flag would serve to document expectations
> > I'm left unconvinced that the memory allocator will _not fail_ for an
> > order-0 page -- as Mikulas said most ioctls don't need more than 4K.
> 
> __GFP_NOFAIL would make no sense in kvmalloc() calls, ever, it would never 
> fallback to vmalloc :)
> 
> I'm hoping this can get merged during the 4.12 window to fix the broken 
> commit d224e9381897.

I've added your Acked-by and staged it for 4.12, please see:
https://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm.git/commit/?h=for-4.12/dm=8c1e2162f27b319da913683143c0c6c09b083ebb

Not sure when I'll send it to Linus but certainly no later than for rc4
inclusion.

Thanks,
Mike

Re: [PATCH net-next 2/2] samples/bpf: add samples for HW_CACHE / RAW events

[Alexei Starovoitov]

On 5/22/17 4:26 PM, David Miller wrote:

From: Alexei Starovoitov 
Date: Mon, 22 May 2017 15:48:40 -0700


@@ -31,7 +31,7 @@ static unsigned long long (*bpf_get_current_uid_gid)(void) =
(void *) BPF_FUNC_get_current_uid_gid;
 static int (*bpf_get_current_comm)(void *buf, int buf_size) =
(void *) BPF_FUNC_get_current_comm;
-static int (*bpf_perf_event_read)(void *map, int index) =
+static u64 (*bpf_perf_event_read)(void *map, u64 flags) =
(void *) BPF_FUNC_perf_event_read;


If the second argument really is "u64 flags", then please update
the comments in tools/include/uapi/linux/bpf.h as well.


of course.
As independent patch, I assume.
For both tools/include/uapi/...bpf.h and include/uapi/...bpf.h

It has some info:
/* BPF_FUNC_perf_event_output and BPF_FUNC_perf_event_read flags. */
#define BPF_F_INDEX_MASK0xULL
#define BPF_F_CURRENT_CPU   BPF_F_INDEX_MASK

yet perf_event_read() is least documented. hmm.
 * u64 bpf_perf_event_read(, index)
 * Return: Number events read or error code

that needs to be fixed.

Re: [PATCH] ib/core: not to set page dirty bit if it's already set.

[Qing Huang]

On 5/19/2017 6:05 AM, Christoph Hellwig wrote:

On Thu, May 18, 2017 at 04:33:53PM -0700, Qing Huang wrote:

This change will optimize kernel memory deregistration operations.
__ib_umem_release() used to call set_page_dirty_lock() against every
writable page in its memory region. Its purpose is to keep data
synced between CPU and DMA device when swapping happens after mem
deregistration ops. Now we choose not to set page dirty bit if it's
already set by kernel prior to calling __ib_umem_release(). This
reduces memory deregistration time by half or even more when we ran
application simulation test program.

As far as I can tell this code doesn't even need set_page_dirty_lock
and could just use set_page_dirty


It seems that set_page_dirty_lock has been used here for more than 10 
years. Don't know the original purpose. Maybe it was used to prevent 
races between setting dirty bits and swapping out pages?


Perhaps we can call set_page_dirty before calling ib_dma_unmap_sg?


Signed-off-by: Qing Huang
---
  drivers/infiniband/core/umem.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/infiniband/core/umem.c b/drivers/infiniband/core/umem.c
index 3dbf811..21e60b1 100644
--- a/drivers/infiniband/core/umem.c
+++ b/drivers/infiniband/core/umem.c
@@ -58,7 +58,7 @@ static void __ib_umem_release(struct ib_device *dev, struct 
ib_umem *umem, int d
for_each_sg(umem->sg_head.sgl, sg, umem->npages, i) {
  
  		page = sg_page(sg);

-   if (umem->writable && dirty)
+   if (!PageDirty(page) && umem->writable && dirty)
set_page_dirty_lock(page);
put_page(page);
}
--
2.9.3

Re: [PATCH v2 4/5] HID: intel_ish-hid: fix format string for size_t

[Srinivas Pandruvada]

On Thu, 2017-05-18 at 22:21 +0200, Arnd Bergmann wrote:
> When building for 32-bit architectures, we get a harmless warning:
> 
> intel-ish-hid/ishtp-hid-client.c: In function 'process_recv':
> intel-ish-hid/ishtp-hid-client.c:139:7: error: format '%lu' expects
> argument of type 'long unsigned int', but argument 3 has type
> 'unsigned int' [-Werror=format=]
> 
> This changes the format string to print size_t variables using %zu
> instead.
Is the ordering of patch correct?
ISH config depends on X86_64, so it would not be enabled for 32 bit
build.
So your patch 5/5 will adding "|| COMPILE_TEST", hence it is building.

Thanks,
Srinivas

> 
> Signed-off-by: Arnd Bergmann 
> ---
>  drivers/hid/intel-ish-hid/ishtp-hid-client.c | 5 ++---
>  1 file changed, 2 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/hid/intel-ish-hid/ishtp-hid-client.c
> b/drivers/hid/intel-ish-hid/ishtp-hid-client.c
> index 5c643d7a07b2..157b44aacdff 100644
> --- a/drivers/hid/intel-ish-hid/ishtp-hid-client.c
> +++ b/drivers/hid/intel-ish-hid/ishtp-hid-client.c
> @@ -136,10 +136,9 @@ static void process_recv(struct ishtp_cl
> *hid_ishtp_cl, void *recv_buf,
>   if (1 + sizeof(struct device_info) *
> i >=
>   payload_len) {
>   dev_err(_data-
> >cl_device->dev,
> - "[hid-ish]:
> [ENUM_DEVICES]: content size %lu is bigger than payload_len %u\n",
> + "[hid-ish]:
> [ENUM_DEVICES]: content size %zu is bigger than payload_len %zu\n",
>   1 + sizeof(struct
> device_info)
> - * i,
> - (unsigned
> int)payload_len);
> + * i, payload_len);
>   }
>  
>   if (1 + sizeof(struct device_info) *
> i >=

Re: [PATCH] gpu: drm: gma500: remove two more dead variable

[Patrik Jakobsson]

On Mon, May 22, 2017 at 10:30 PM, Arnd Bergmann  wrote:
> The dead code removal left two unused variables:
>
> drivers/gpu/drm/gma500/mdfld_tpo_vid.c: In function 'tpo_vid_get_config_mode':
> drivers/gpu/drm/gma500/mdfld_tpo_vid.c:34:31: error: unused variable 'ti' 
> [-Werror=unused-variable]
>
> This removes them as well.
>
> Fixes: 94d7fb4982d2 ("gpu: drm: gma500: remove dead code")
> Signed-off-by: Arnd Bergmann 

Thanks, I'll take this through drm-misc

Signed-off-by: Patrik Jakobsson 

> ---
>  drivers/gpu/drm/gma500/mdfld_tpo_vid.c | 2 --
>  1 file changed, 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/gma500/mdfld_tpo_vid.c 
> b/drivers/gpu/drm/gma500/mdfld_tpo_vid.c
> index d40628e6810d..a9420bf9a419 100644
> --- a/drivers/gpu/drm/gma500/mdfld_tpo_vid.c
> +++ b/drivers/gpu/drm/gma500/mdfld_tpo_vid.c
> @@ -30,8 +30,6 @@
>  static struct drm_display_mode *tpo_vid_get_config_mode(struct drm_device 
> *dev)
>  {
> struct drm_display_mode *mode;
> -   struct drm_psb_private *dev_priv = dev->dev_private;
> -   struct oaktrail_timing_info *ti = _priv->gct_data.DTD;
>
> mode = kzalloc(sizeof(*mode), GFP_KERNEL);
> if (!mode)
> --
> 2.9.0
>

Re: [PATCH] irqchip: aspeed: Add AST2500 compatible string

[Rob Herring]

On Tue, May 16, 2017 at 03:57:47PM +0800, Andrew Jeffery wrote:
> In addition to introducing the new compatible string the bindings
> description is reworked to be more generic.
> 
> Signed-off-by: Andrew Jeffery 
> ---
>  .../bindings/interrupt-controller/aspeed,ast2400-vic.txt | 9 
> +
>  drivers/irqchip/irq-aspeed-vic.c | 3 ++-
>  2 files changed, 7 insertions(+), 5 deletions(-)

Acked-by: Rob Herring 

Re: [PATCH] crypto: stm32 - Add CRC32 support for STM32F4XX

[Rob Herring]

On Wed, May 17, 2017 at 12:18:50AM +0300, Cosar Dindar wrote:
> This patch series add hardware CRC32 ("Ethernet") calculation support
> for STMicroelectronics STM32F4XX series devices.
> 
> As an hardware limitation polynomial and key setting are not supported
> as they are fixed as 0x4C11DB7 (poly) and 0x (key).
> 
> CRC32C Castagnoli algorithm is not supported also.
> Module is tested on STM32F429-disco board with crypto testmgr using
> cases within the key 0x.
> 
> Signed-off-by: Cosar Dindar 
> ---
>  .../devicetree/bindings/crypto/st,stm32-crc.txt|  4 +-
>  arch/arm/boot/dts/stm32429i-eval.dts   |  4 ++
>  arch/arm/boot/dts/stm32f429-disco.dts  |  4 ++
>  arch/arm/boot/dts/stm32f429.dtsi   |  7 +++
>  arch/arm/boot/dts/stm32f469-disco.dts  |  4 ++
>  drivers/crypto/stm32/stm32_crc32.c | 68 
> ++
>  6 files changed, 79 insertions(+), 12 deletions(-)

Acked-by: Rob Herring 

Re: [PATCH v3 19/21] drm/sun4i: Add compatible for the A10s pipeline

[Rob Herring]

On Wed, May 17, 2017 at 09:40:48AM +0200, Maxime Ripard wrote:
> The A10s has a slightly different display pipeline than the A13, with an
> HDMI controller.
> 
> Add a compatible for it.
> 
> Signed-off-by: Maxime Ripard 
> ---
>  Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt | 1 +
>  drivers/gpu/drm/sun4i/sun4i_drv.c | 1 +
>  2 files changed, 2 insertions(+)

Acked-by: Rob Herring 

[PATCH 3/7] RISC-V: Device Tree Documentation

[Palmer Dabbelt]

---
 .../interrupt-controller/riscv,cpu-intc.txt| 46 ++
 .../bindings/interrupt-controller/riscv,plic0.txt  | 44 +
 2 files changed, 90 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/interrupt-controller/riscv,cpu-intc.txt
 create mode 100644 
Documentation/devicetree/bindings/interrupt-controller/riscv,plic0.txt

diff --git 
a/Documentation/devicetree/bindings/interrupt-controller/riscv,cpu-intc.txt 
b/Documentation/devicetree/bindings/interrupt-controller/riscv,cpu-intc.txt
new file mode 100644
index ..62f02e834ff9
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupt-controller/riscv,cpu-intc.txt
@@ -0,0 +1,46 @@
+RISC-V Hart-Level Interrupt Controller (HLIC)
+-
+
+RISC-V cores include Control Status Registers (CSRs) which are local to each
+hart and can be read or written by software. Some of these CSRs are used to
+control local interrupts connected to the core.
+
+Typical examples of local interrupts on a RISC-V core include: software IPI
+interrupts, timer interrupts, and a link to the PLIC interrupt controller.
+
+Required properties:
+- compatible : "riscv,cpu-intc"
+- #interrupt-cells : should be <1>
+- interrupt-controller : Identifies the node as an interrupt controller
+
+Furthermore, this interrupt-controller MUST be embedded inside the cpu
+definition of the hart whose CSRs control these local interrupts.
+
+Example:
+
+   cpu1: cpu@1 {
+   clock-frequency = <16>;
+   compatible = "riscv";
+   d-cache-block-size = <64>;
+   d-cache-sets = <64>;
+   d-cache-size = <16384>;
+   d-tlb-sets = <1>;
+   d-tlb-size = <32>;
+   device_type = "cpu";
+   i-cache-block-size = <64>;
+   i-cache-sets = <64>;
+   i-cache-size = <16384>;
+   i-tlb-sets = <1>;
+   i-tlb-size = <32>;
+   mmu-type = "riscv,sv39";
+   next-level-cache = <>;
+   reg = <1>;
+   riscv,isa = "rv64imac";
+   status = "okay";
+   tlb-split;
+   cpu1-intc: interrupt-controller {
+   #interrupt-cells = <1>;
+   compatible = "riscv,cpu-intc";
+   interrupt-controller;
+   };
+   };
diff --git 
a/Documentation/devicetree/bindings/interrupt-controller/riscv,plic0.txt 
b/Documentation/devicetree/bindings/interrupt-controller/riscv,plic0.txt
new file mode 100644
index ..c05b5806f7d2
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupt-controller/riscv,plic0.txt
@@ -0,0 +1,44 @@
+RISC-V Platform-Level Interrupt Controller (PLIC)
+-
+
+RISC-V cores typically include a PLIC, which route interrupts from multiple
+devices to multiple hart contexts.  The PLIC is connected to the interrupt
+controller embedded in a RISC-V core via the interrupt-related CSRs.
+
+A hart context is a priviledge mode in a hardware execution thread.  For
+example, in an 4 core system with 2-way SMT, you have 8 harts and probably
+at least two priviledge modes per hart; machine mode and supervisor mode.
+
+Each interrupt can be enabled on per-context basis. Any context can claim
+a pending enabled interrupt and then release it once it has been handled.
+
+Each interrupt has a configurable priority. Higher priority interrupts are
+serviced firs. Each context can specify a priority threshold. Interrupts
+with priority below this threshold will not cause the PLIC to raise its
+interrupt line leading to the context.
+
+Required properties:
+- compatible : "riscv,plic0"
+- #address-cells : should be <0>
+- #interrupt-cells : should be <1>
+- interrupt-controller : Identifies the node as an interrupt controller
+- reg : Should contain 1 register range (address and length)
+- riscv,ndev : Specifies the number of interrupts attached to the PLIC
+- interrupts-extended : Specifies which contexts are connected to the PLIC
+
+Example:
+
+   plic: interrupt-controller@c00 {
+   #address-cells = <0>;
+   #interrupt-cells = <1>;
+   compatible = "riscv,plic0";
+   interrupt-controller;
+   interrupts-extended = <
+11
+11  9
+11  9
+11  9
+11  9>;
+   reg = <0xc00 0x400>;
+   riscv,ndev = <10>;
+   };
-- 
2.13.0

[PATCH v3 5/5] mtd: mchp23k256: Add support for mchp23lcv1024

[Chris Packham]

The mchp23lcv1024 is software compatible with the mchp23k256, the
only difference (from a software point of view) is the size. There
is no way to detect the size so we must be told via a Device Tree.

Signed-off-by: Chris Packham 
---
Changes in v2:
- fix formatting in switch statement
- add support for 24-bit addressing
Changes in v3:
- None

 .../bindings/mtd/microchip,mchp23k256.txt  |  2 +-
 drivers/mtd/devices/mchp23k256.c   | 53 ++
 2 files changed, 44 insertions(+), 11 deletions(-)

diff --git a/Documentation/devicetree/bindings/mtd/microchip,mchp23k256.txt 
b/Documentation/devicetree/bindings/mtd/microchip,mchp23k256.txt
index 25e5ad38b0f0..7328eb92a03c 100644
--- a/Documentation/devicetree/bindings/mtd/microchip,mchp23k256.txt
+++ b/Documentation/devicetree/bindings/mtd/microchip,mchp23k256.txt
@@ -3,7 +3,7 @@
 Required properties:
 - #address-cells, #size-cells : Must be present if the device has sub-nodes
   representing partitions.
-- compatible : Must be "microchip,mchp23k256"
+- compatible : Must be one of "microchip,mchp23k256" or 
"microchip,mchp23lcv1024"
 - reg : Chip-Select number
 - spi-max-frequency : Maximum frequency of the SPI bus the chip can operate at
 
diff --git a/drivers/mtd/devices/mchp23k256.c b/drivers/mtd/devices/mchp23k256.c
index 3e5feb454644..72ecf374a06a 100644
--- a/drivers/mtd/devices/mchp23k256.c
+++ b/drivers/mtd/devices/mchp23k256.c
@@ -21,10 +21,14 @@
 #include 
 #include 
 
+#define MAX_CMD_SIZE   4
+enum chips { mchp23k256, mchp23lcv1024 };
+
 struct mchp23k256_flash {
struct spi_device   *spi;
struct mutexlock;
struct mtd_info mtd;
+   u8  addr_width;
 };
 
 #define MCHP23K256_CMD_WRITE_STATUS0x01
@@ -34,22 +38,35 @@ struct mchp23k256_flash {
 
 #define to_mchp23k256_flash(x) container_of(x, struct mchp23k256_flash, mtd)
 
+static void mchp23k256_addr2cmd(struct mchp23k256_flash *flash,
+   unsigned int addr, u8 *cmd)
+{
+   /* cmd[0] has opcode */
+   cmd[1] = addr >> (flash->addr_width * 8 -  8);
+   cmd[2] = addr >> (flash->addr_width * 8 - 16);
+   cmd[3] = addr >> (flash->addr_width * 8 - 24);
+}
+
+static int mchp23k256_cmdsz(struct mchp23k256_flash *flash)
+{
+   return 1 + flash->addr_width;
+}
+
 static int mchp23k256_write(struct mtd_info *mtd, loff_t to, size_t len,
size_t *retlen, const unsigned char *buf)
 {
struct mchp23k256_flash *flash = to_mchp23k256_flash(mtd);
struct spi_transfer transfer[2] = {};
struct spi_message message;
-   unsigned char command[3];
+   unsigned char command[MAX_CMD_SIZE];
 
spi_message_init();
 
command[0] = MCHP23K256_CMD_WRITE;
-   command[1] = to >> 8;
-   command[2] = to;
+   mchp23k256_addr2cmd(flash, to, command);
 
transfer[0].tx_buf = command;
-   transfer[0].len = sizeof(command);
+   transfer[0].len = mchp23k256_cmdsz(flash);
spi_message_add_tail([0], );
 
transfer[1].tx_buf = buf;
@@ -73,17 +90,16 @@ static int mchp23k256_read(struct mtd_info *mtd, loff_t 
from, size_t len,
struct mchp23k256_flash *flash = to_mchp23k256_flash(mtd);
struct spi_transfer transfer[2] = {};
struct spi_message message;
-   unsigned char command[3];
+   unsigned char command[MAX_CMD_SIZE];
 
spi_message_init();
 
memset(, 0, sizeof(transfer));
command[0] = MCHP23K256_CMD_READ;
-   command[1] = from >> 8;
-   command[2] = from;
+   mchp23k256_addr2cmd(flash, from, command);
 
transfer[0].tx_buf = command;
-   transfer[0].len = sizeof(command);
+   transfer[0].len = mchp23k256_cmdsz(flash);
spi_message_add_tail([0], );
 
transfer[1].rx_buf = buf;
@@ -128,6 +144,7 @@ static int mchp23k256_probe(struct spi_device *spi)
struct mchp23k256_flash *flash;
struct flash_platform_data *data;
int err;
+   enum chips chip;
 
flash = devm_kzalloc(>dev, sizeof(*flash), GFP_KERNEL);
if (!flash)
@@ -143,15 +160,30 @@ static int mchp23k256_probe(struct spi_device *spi)
 
data = dev_get_platdata(>dev);
 
+   if (spi->dev.of_node)
+   chip = (enum chips)of_device_get_match_data(>dev);
+   else
+   chip = mchp23k256;
+
mtd_set_of_node(>mtd, spi->dev.of_node);
flash->mtd.dev.parent   = >dev;
flash->mtd.type = MTD_RAM;
flash->mtd.flags= MTD_CAP_RAM;
flash->mtd.writesize= 1;
-   flash->mtd.size = SZ_32K;
flash->mtd._read= mchp23k256_read;
flash->mtd._write   = mchp23k256_write;
 
+   switch (chip) {
+   case mchp23lcv1024:
+   flash->mtd.size = SZ_128K;
+   flash->addr_width   = 3;
+   break;
+

[PATCH 6/7] RISC-V: arch/riscv/kernel

[Palmer Dabbelt]

---
 arch/riscv/kernel/Makefile |  19 ++
 arch/riscv/kernel/asm-offsets.c| 113 ++
 arch/riscv/kernel/cacheinfo.c  |  82 
 arch/riscv/kernel/cpu.c|  81 
 arch/riscv/kernel/entry.S  | 414 +
 arch/riscv/kernel/head.S   | 139 +
 arch/riscv/kernel/irq.c| 205 ++
 arch/riscv/kernel/module.c | 185 +
 arch/riscv/kernel/pci.c|  36 
 arch/riscv/kernel/plic.c   | 208 +++
 arch/riscv/kernel/process.c| 130 
 arch/riscv/kernel/ptrace.c | 148 +
 arch/riscv/kernel/reset.c  |  33 +++
 arch/riscv/kernel/riscv_ksyms.c|  16 ++
 arch/riscv/kernel/sbi-con.c| 214 +++
 arch/riscv/kernel/setup.c  | 234 +
 arch/riscv/kernel/signal.c | 258 +++
 arch/riscv/kernel/smp.c| 107 ++
 arch/riscv/kernel/smpboot.c| 105 ++
 arch/riscv/kernel/stacktrace.c | 183 
 arch/riscv/kernel/sys_riscv.c  |  85 
 arch/riscv/kernel/syscall_table.c  |  26 +++
 arch/riscv/kernel/time.c   | 116 +++
 arch/riscv/kernel/traps.c  | 167 +++
 arch/riscv/kernel/vdso.c   | 125 +++
 arch/riscv/kernel/vdso/.gitignore  |   1 +
 arch/riscv/kernel/vdso/Makefile|  61 ++
 arch/riscv/kernel/vdso/sigreturn.S |  25 +++
 arch/riscv/kernel/vdso/vdso.S  |  28 +++
 arch/riscv/kernel/vdso/vdso.lds.S  |  77 +++
 arch/riscv/kernel/vmlinux.lds.S|  93 +
 31 files changed, 3714 insertions(+)
 create mode 100644 arch/riscv/kernel/Makefile
 create mode 100644 arch/riscv/kernel/asm-offsets.c
 create mode 100644 arch/riscv/kernel/cacheinfo.c
 create mode 100644 arch/riscv/kernel/cpu.c
 create mode 100644 arch/riscv/kernel/entry.S
 create mode 100644 arch/riscv/kernel/head.S
 create mode 100644 arch/riscv/kernel/irq.c
 create mode 100644 arch/riscv/kernel/module.c
 create mode 100644 arch/riscv/kernel/pci.c
 create mode 100644 arch/riscv/kernel/plic.c
 create mode 100644 arch/riscv/kernel/process.c
 create mode 100644 arch/riscv/kernel/ptrace.c
 create mode 100644 arch/riscv/kernel/reset.c
 create mode 100644 arch/riscv/kernel/riscv_ksyms.c
 create mode 100644 arch/riscv/kernel/sbi-con.c
 create mode 100644 arch/riscv/kernel/setup.c
 create mode 100644 arch/riscv/kernel/signal.c
 create mode 100644 arch/riscv/kernel/smp.c
 create mode 100644 arch/riscv/kernel/smpboot.c
 create mode 100644 arch/riscv/kernel/stacktrace.c
 create mode 100644 arch/riscv/kernel/sys_riscv.c
 create mode 100644 arch/riscv/kernel/syscall_table.c
 create mode 100644 arch/riscv/kernel/time.c
 create mode 100644 arch/riscv/kernel/traps.c
 create mode 100644 arch/riscv/kernel/vdso.c
 create mode 100644 arch/riscv/kernel/vdso/.gitignore
 create mode 100644 arch/riscv/kernel/vdso/Makefile
 create mode 100644 arch/riscv/kernel/vdso/sigreturn.S
 create mode 100644 arch/riscv/kernel/vdso/vdso.S
 create mode 100644 arch/riscv/kernel/vdso/vdso.lds.S
 create mode 100644 arch/riscv/kernel/vmlinux.lds.S

diff --git a/arch/riscv/kernel/Makefile b/arch/riscv/kernel/Makefile
new file mode 100644
index ..94ac2931c56a
--- /dev/null
+++ b/arch/riscv/kernel/Makefile
@@ -0,0 +1,19 @@
+#
+# Makefile for the RISC-V Linux kernel
+#
+
+extra-y := head.o vmlinux.lds
+
+obj-y  := cpu.o entry.o irq.o process.o ptrace.o reset.o setup.o \
+  signal.o syscall_table.o sys_riscv.o time.o traps.o \
+  riscv_ksyms.o stacktrace.o vdso.o cacheinfo.o vdso/
+
+CFLAGS_setup.o := -mcmodel=medany
+
+obj-$(CONFIG_SMP)  += smpboot.o smp.o
+obj-$(CONFIG_SBI_CONSOLE)  += sbi-con.o
+obj-$(CONFIG_PCI)  += pci.o
+obj-$(CONFIG_MODULES)  += module.o
+obj-$(CONFIG_PLIC) += plic.o
+
+clean:
diff --git a/arch/riscv/kernel/asm-offsets.c b/arch/riscv/kernel/asm-offsets.c
new file mode 100644
index ..ac2e0cfaf8a3
--- /dev/null
+++ b/arch/riscv/kernel/asm-offsets.c
@@ -0,0 +1,113 @@
+/*
+ * Copyright (C) 2012 Regents of the University of California
+ *
+ *   This program is free software; you can redistribute it and/or
+ *   modify it under the terms of the GNU General Public License
+ *   as published by the Free Software Foundation, version 2.
+ *
+ *   This program is distributed in the hope that it will be useful, but
+ *   WITHOUT ANY WARRANTY; without even the implied warranty of
+ *   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE, GOOD TITLE or
+ *   NON INFRINGEMENT.  See the GNU General Public License for
+ *   more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+void asm_offsets(void)
+{
+   OFFSET(TASK_THREAD_INFO, task_struct, stack);
+   OFFSET(THREAD_RA, task_struct, thread.ra);
+   OFFSET(THREAD_SP, task_struct, thread.sp);
+   OFFSET(THREAD_S0, task_struct, 

[PATCH 7/7] RISC-V: arch/riscv/mm

[Palmer Dabbelt]

---
 arch/riscv/mm/Makefile  |   1 +
 arch/riscv/mm/extable.c |  38 +++
 arch/riscv/mm/fault.c   | 279 
 arch/riscv/mm/init.c|  72 +
 arch/riscv/mm/ioremap.c |  96 +
 5 files changed, 486 insertions(+)
 create mode 100644 arch/riscv/mm/Makefile
 create mode 100644 arch/riscv/mm/extable.c
 create mode 100644 arch/riscv/mm/fault.c
 create mode 100644 arch/riscv/mm/init.c
 create mode 100644 arch/riscv/mm/ioremap.c

diff --git a/arch/riscv/mm/Makefile b/arch/riscv/mm/Makefile
new file mode 100644
index ..36ebe6feb5d6
--- /dev/null
+++ b/arch/riscv/mm/Makefile
@@ -0,0 +1 @@
+obj-y := init.o fault.o extable.o ioremap.o
diff --git a/arch/riscv/mm/extable.c b/arch/riscv/mm/extable.c
new file mode 100644
index ..811b298c2475
--- /dev/null
+++ b/arch/riscv/mm/extable.c
@@ -0,0 +1,38 @@
+/*
+ * Copyright (C) 2009 Sunplus Core Technology Co., Ltd.
+ *  Lennox Wu 
+ *  Chen Liqin 
+ * Copyright (C) 2013 Regents of the University of California
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, see the file COPYING, or write
+ * to the Free Software Foundation, Inc.,
+ * 51 Franklin St, Fifth Floor, Boston, MA  02110-1301  USA
+ */
+
+
+#include 
+#include 
+#include 
+
+int fixup_exception(struct pt_regs *regs)
+{
+   const struct exception_table_entry *fixup;
+
+   fixup = search_exception_tables(regs->sepc);
+   if (fixup) {
+   regs->sepc = fixup->fixup;
+   return 1;
+   }
+   return 0;
+}
diff --git a/arch/riscv/mm/fault.c b/arch/riscv/mm/fault.c
new file mode 100644
index ..f02e286dd1c1
--- /dev/null
+++ b/arch/riscv/mm/fault.c
@@ -0,0 +1,279 @@
+/*
+ * Copyright (C) 2009 Sunplus Core Technology Co., Ltd.
+ *  Lennox Wu 
+ *  Chen Liqin 
+ * Copyright (C) 2012 Regents of the University of California
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, see the file COPYING, or write
+ * to the Free Software Foundation, Inc.,
+ * 51 Franklin St, Fifth Floor, Boston, MA  02110-1301  USA
+ */
+
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+
+/*
+ * This routine handles page faults.  It determines the address and the
+ * problem, and then passes it off to one of the appropriate routines.
+ */
+asmlinkage void do_page_fault(struct pt_regs *regs)
+{
+   struct task_struct *tsk;
+   struct vm_area_struct *vma;
+   struct mm_struct *mm;
+   unsigned long addr, cause;
+   unsigned int flags = FAULT_FLAG_ALLOW_RETRY | FAULT_FLAG_KILLABLE;
+   int fault, code = SEGV_MAPERR;
+
+   cause = regs->scause;
+   addr = regs->sbadaddr;
+
+   tsk = current;
+   mm = tsk->mm;
+
+   /*
+* Fault-in kernel-space virtual memory on-demand.
+* The 'reference' page table is init_mm.pgd.
+*
+* NOTE! We MUST NOT take any locks for this case. We may
+* be in an interrupt or a critical region, and should
+* only copy the information from the master page table,
+* nothing more.
+*/
+   if (unlikely((addr >= VMALLOC_START) && (addr <= VMALLOC_END)))
+   goto vmalloc_fault;
+
+   /* Enable interrupts if they were enabled in the parent context. */
+   if (likely(regs->sstatus & SR_PIE))
+   local_irq_enable();
+
+   /*
+* If we're in an interrupt, have no user context, or are running
+* in an atomic region, then we must not take the fault.
+*/
+   if (unlikely(faulthandler_disabled() || !mm))
+   goto no_context;
+
+   if (user_mode(regs))
+   flags |= FAULT_FLAG_USER;
+
+   

Re: [PATCH 07/12] arm64: dts: hi3660: Add uarts nodes

[Rob Herring]

On Wed, May 17, 2017 at 04:37:40PM +0800, Guodong Xu wrote:
> From: Chen Feng 
> 
> Add nodes uart0 to uart4 and uart6 for hi3660 SoC.
> Enable uart3 and uart6, disable uart5, in hikey960 board dts.
> 
> On HiKey960:
>  - UART6 is used as default console, and is wired out through low speed
>  expansion connector.
>  - UART3 has RTS/CTS hardware handshake, and is wired out through low
>  speed expansion connector.
>  - UART5 is not used in commercial launched boards. So disable it.
>  - UART4 is connected to Bluetooth, WL1837.
> 
> Signed-off-by: Chen Feng 
> Signed-off-by: Wang Xiaoyin 
> Signed-off-by: Guodong Xu 
> Reviewed-by: Zhangfei Gao 
> ---
>  arch/arm64/boot/dts/hisilicon/hi3660-hikey960.dts | 18 +--
>  arch/arm64/boot/dts/hisilicon/hi3660.dtsi | 60 
> +++
>  2 files changed, 73 insertions(+), 5 deletions(-)
> 
> diff --git a/arch/arm64/boot/dts/hisilicon/hi3660-hikey960.dts 
> b/arch/arm64/boot/dts/hisilicon/hi3660-hikey960.dts
> index f685b1e..513c496 100644
> --- a/arch/arm64/boot/dts/hisilicon/hi3660-hikey960.dts
> +++ b/arch/arm64/boot/dts/hisilicon/hi3660-hikey960.dts
> @@ -15,12 +15,16 @@
>   compatible = "hisilicon,hi3660-hikey960", "hisilicon,hi3660";
>  
>   aliases {
> - serial5 =/* console UART */
> + serial0 = 
> + serial1 = 
> + serial2 = 
> + serial3 = 
> + serial4 = 
> + serial5 = 
> + serial6 = 
>   };
>  
> - chosen {
> - stdout-path = "serial5:115200n8";

Why is this removed?

> - };
> + chosen {};
>  
>   memory@0 {
>   device_type = "memory";
> @@ -47,6 +51,10 @@
>   status = "okay";
>  };
>  
> - {
> + {
> + status = "okay";
> +};
> +
> + {
>   status = "okay";

labels for LS connector?

>  };
> diff --git a/arch/arm64/boot/dts/hisilicon/hi3660.dtsi 
> b/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
> index 3bea0d2..0951a29 100644
> --- a/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
> +++ b/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
> @@ -242,6 +242,56 @@
>   status = "disabled";
>   };
>  
> + uart0: serial@fdf02000 {
> + compatible = "arm,pl011", "arm,primecell";
> + reg = <0x0 0xfdf02000 0x0 0x1000>;
> + interrupts = ;
> + clocks = <_ctrl HI3660_CLK_MUX_UART0>,
> +  <_ctrl HI3660_PCLK>;
> + clock-names = "uartclk", "apb_pclk";
> + status = "disabled";
> + };
> +
> + uart1: serial@fdf0 {
> + compatible = "arm,pl011", "arm,primecell";
> + reg = <0x0 0xfdf0 0x0 0x1000>;
> + interrupts = ;
> + clocks = <_ctrl HI3660_CLK_GATE_UART1>,
> +  <_ctrl HI3660_CLK_GATE_UART1>;
> + clock-names = "uartclk", "apb_pclk";
> + status = "disabled";
> + };
> +
> + uart2: serial@fdf03000 {
> + compatible = "arm,pl011", "arm,primecell";
> + reg = <0x0 0xfdf03000 0x0 0x1000>;
> + interrupts = ;
> + clocks = <_ctrl HI3660_CLK_GATE_UART2>,
> +  <_ctrl HI3660_PCLK>;
> + clock-names = "uartclk", "apb_pclk";
> + status = "disabled";
> + };
> +
> + uart3: serial@ffd74000 {
> + compatible = "arm,pl011", "arm,primecell";
> + reg = <0x0 0xffd74000 0x0 0x1000>;
> + interrupts = ;
> + clocks = <_ctrl HI3660_FACTOR_UART3>,
> +  <_ctrl HI3660_PCLK>;
> + clock-names = "uartclk", "apb_pclk";
> + status = "disabled";
> + };
> +
> + uart4: serial@fdf01000 {
> + compatible = "arm,pl011", "arm,primecell";
> + reg = <0x0 0xfdf01000 0x0 0x1000>;
> + interrupts = ;
> + clocks = <_ctrl HI3660_CLK_GATE_UART4>,
> +  <_ctrl HI3660_CLK_GATE_UART4>;
> + clock-names = "uartclk", "apb_pclk";
> + status = "disabled";
> + };
> +
>   uart5: serial@fdf05000 {
>   compatible = "arm,pl011", "arm,primecell";
>   reg = <0x0 0xfdf05000 0x0 0x1000>;
> @@ -252,6 +302,16 @@
>   status = "disabled";
>   };
>  
> + uart6: serial@fff32000 {
> + compatible = "arm,pl011", "arm,primecell";
> + 

[PATCH v3 4/5] mtd: mchp23k256: add partitioning support

[Chris Packham]

Setting the of_node for the mtd device allows the generic mtd code to
setup the partitions. Additionally we must specify a non-zero erasesize
for the partitions to be writeable.

Signed-off-by: Chris Packham 
Reviewed-by: Andrew Lunn 
Tested-by: Andrew Lunn 
---
Changes in v2
- collect revew/test from Andrew
Changes in v3:
- remove setting of erasesize

 drivers/mtd/devices/mchp23k256.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/mtd/devices/mchp23k256.c b/drivers/mtd/devices/mchp23k256.c
index 2542f5b8b63f..3e5feb454644 100644
--- a/drivers/mtd/devices/mchp23k256.c
+++ b/drivers/mtd/devices/mchp23k256.c
@@ -143,6 +143,7 @@ static int mchp23k256_probe(struct spi_device *spi)
 
data = dev_get_platdata(>dev);
 
+   mtd_set_of_node(>mtd, spi->dev.of_node);
flash->mtd.dev.parent   = >dev;
flash->mtd.type = MTD_RAM;
flash->mtd.flags= MTD_CAP_RAM;
-- 
2.11.0.24.ge6920cf

Re: [PATCH v3 5/5] mtd: mchp23k256: Add support for mchp23lcv1024

[Andrew Lunn]

On Tue, May 23, 2017 at 12:43:17PM +1200, Chris Packham wrote:
> The mchp23lcv1024 is software compatible with the mchp23k256, the
> only difference (from a software point of view) is the size.

This is not really true. The size of the address is also different,
and the point of the v2 change.

> There
> is no way to detect the size so we must be told via a Device Tree.

or defaults to 256K when device tree is not used.

> 
> Signed-off-by: Chris Packham 

Reviewed-by: Andrew Lunn 

Andrew

Re: [RFC PATCH v3 00/12] Unify interrupt mode and setup it as soon as possible

[Dou Liyang]

Dear Thomas,

At 05/23/2017 04:23 AM, Thomas Gleixner wrote:

Dou,

On Wed, 10 May 2017, Dou Liyang wrote:


According to Ingo's and Eric's advice[1,2], Try my best to optimize the
init of interrupt delivery mode for x86.


sorry for replying late. The patchset is not forgotten, it's on my todo
list and I'll tend to it latest next week.



I am very glad to hear that. :)

I will check it again and wait for your advice.

Thanks,
  Liyang.


Thanks,

tglx

Re: [PATCH 2/7] RISC-V: arch/riscv Makefile and Kconfigs

[Randy Dunlap]

On 05/22/17 18:27, Olof Johansson wrote:
> Hi,
> 
> 
> On Mon, May 22, 2017 at 5:41 PM, Palmer Dabbelt  wrote:
>> ---
>>  arch/riscv/.gitignore|  35 
>>  arch/riscv/Kconfig   | 300 
>> +++
>>  arch/riscv/Makefile  |  64 
>>  arch/riscv/configs/riscv32_spike |  47 ++
>>  arch/riscv/configs/riscv64_freedom-u |  52 ++
>>  arch/riscv/configs/riscv64_qemu  |  64 
>>  arch/riscv/configs/riscv64_spike |  45 ++
>>  7 files changed, 607 insertions(+)
>>  create mode 100644 arch/riscv/.gitignore
>>  create mode 100644 arch/riscv/Kconfig
>>  create mode 100644 arch/riscv/Makefile
>>  create mode 100644 arch/riscv/configs/riscv32_spike
>>  create mode 100644 arch/riscv/configs/riscv64_freedom-u
>>  create mode 100644 arch/riscv/configs/riscv64_qemu
>>  create mode 100644 arch/riscv/configs/riscv64_spike
> 
> Nearly all other platforms have _defconfig in the config names. It
> might get a bit excessive to prepend riscv{32,64} to all of them
> though. Most other platforms have shortened it to, for example,
> spike_defconfig, spike64_defconfig, qemu_defconfig,
> freedom-u_defconfig.
> 
> Not going to argue too much about the color of the shed here, but
> using the _defconfig naming is recommended.

well, the top-level Makefile looks for "make *config" to indicate that
there is a config-command in progress (or in process), so they usually
have to end in the string "config".

Have these been tested?


-- 
~Randy

Re: [PATCH 1/3] mm/slub: Only define kmalloc_large_node_hook() for NUMA systems

[David Rientjes]

On Mon, 22 May 2017, Andrew Morton wrote:

> > > Is clang not inlining kmalloc_large_node_hook() for some reason?  I don't 
> > > think this should ever warn on gcc.
> > 
> > clang warns about unused static inline functions outside of header
> > files, in difference to gcc.
> 
> I wish it wouldn't.  These patches just add clutter.
> 

Matthias, what breaks if you do this?

diff --git a/include/linux/compiler-clang.h b/include/linux/compiler-clang.h
index de179993e039..e1895ce6fa1b 100644
--- a/include/linux/compiler-clang.h
+++ b/include/linux/compiler-clang.h
@@ -15,3 +15,8 @@
  * with any version that can compile the kernel
  */
 #define __UNIQUE_ID(prefix) __PASTE(__PASTE(__UNIQUE_ID_, prefix), __COUNTER__)
+
+#ifdef inline
+#undef inline
+#define inline __attribute__((unused))
+#endif

Re: [PATCH 1/3] mfd: lp87565: Add lp87565 PMIC support

[Keerthy]

On Monday 22 May 2017 11:18 PM, Lee Jones wrote:
> On Fri, 19 May 2017, Keerthy wrote:
> 
>> The LP87565 chip is a power management IC for Portable Navigation Systems
>> and Tablet Computing devices. It contains the following components:
>>
>> - Configurable Bucks(Single and multi-phase).
>> - Configurable General Purpose Output Signals (GPO).
>>
>> The LP87565-Q1 variant device uses two 2-phase outputs configuration,
>> Buck0 is master for Buck0/1 output and Buck2 is master for Buck2/3
>> output.
>>
>> Signed-off-by: Keerthy 
>> ---
>>  Documentation/devicetree/bindings/mfd/lp87565.txt |  44 
>>  drivers/mfd/Kconfig   |  14 ++
>>  drivers/mfd/Makefile  |   1 +
>>  drivers/mfd/lp87565.c | 103 
>>  include/linux/mfd/lp87565.h   | 275 
>> ++
>>  5 files changed, 437 insertions(+)
>>  create mode 100644 Documentation/devicetree/bindings/mfd/lp87565.txt
>>  create mode 100644 drivers/mfd/lp87565.c
>>  create mode 100644 include/linux/mfd/lp87565.h
>>
>> diff --git a/Documentation/devicetree/bindings/mfd/lp87565.txt 
>> b/Documentation/devicetree/bindings/mfd/lp87565.txt
>> new file mode 100644
>> index 000..38a00a1
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/mfd/lp87565.txt
>> @@ -0,0 +1,44 @@
>> +TI LP873565 PMIC MFD driver
>> +
>> +Required properties:
>> +  - compatible: "ti,lp87565", "ti,lp87565-q1"
>> +  - reg:I2C slave address.
>> +  - gpio-controller:Marks the device node as a GPIO Controller.
>> +  - #gpio-cells:Should be two.  The first cell is the pin number and
>> +the second cell is used to specify flags.
>> +See ../gpio/gpio.txt for more information.
>> +  - xxx-in-supply:  Phandle to parent supply node of each regulator
>> +populated under regulators node. xxx should match
>> +the supply_name populated in driver.
>> +  - regulators: List of child nodes that specify the regulator
>> +initialization data.
>> +Example:
>> +
>> +lp87565: lp87565@60 {
>> +compatible = "ti,lp87565-q1";
>> +reg = <0x60>;
>> +gpio-controller;
>> +#gpio-cells = <2>;
>> +
>> +buck10-in-supply =<_3v3>;
>> +buck23-in-supply =<_3v3>;
> 
> White space errors.
> 
> '\n' here.

I will fix this.

> 
>> +regulators: regulators {
>> +buck10_reg: buck10 {
>> +/*VDD_MPU*/
> 
> Whitespace errors.

I will fix this.

> 
>> +regulator-name = "buck10";
>> +regulator-min-microvolt = <85>;
>> +regulator-max-microvolt = <125>;
>> +regulator-always-on;
>> +regulator-boot-on;
>> +};
>> +
>> +buck23_reg: buck23 {
>> +/* VDD_GPU*/
> 
> Whitespace errors.

I will fix this.

> 
>> +regulator-name = "buck23";
>> +regulator-min-microvolt = <85>;
>> +regulator-max-microvolt = <125>;
>> +regulator-boot-on;
>> +regulator-always-on;
>> +};
>> +};
>> +};
>> diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
>> index 3eb5c93..5e884f3 100644
>> --- a/drivers/mfd/Kconfig
>> +++ b/drivers/mfd/Kconfig
>> @@ -1325,6 +1325,20 @@ config MFD_TI_LP873X
>>This driver can also be built as a module. If so, the module
>>will be called lp873x.
>>  
>> +config MFD_TI_LP87565
>> +tristate "TI LP87565 Power Management IC"
>> +depends on I2C
>> +select MFD_CORE
>> +select REGMAP_I2C
>> +help
>> +  If you say yes here then you get support for the LP87565 series of
>> +  Power Management Integrated Circuits (PMIC).
>> +  These include voltage regulators, thermal protection, configurable
>> +  General Purpose Outputs (GPO) that are used in portable devices.
>> +
>> +  This driver can also be built as a module. If so, the module
>> +  will be called lp87565.
>> +
>>  config MFD_TPS65218
>>  tristate "TI TPS65218 Power Management chips"
>>  depends on I2C
>> diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
>> index c16bf1e..7edbe1b 100644
>> --- a/drivers/mfd/Makefile
>> +++ b/drivers/mfd/Makefile
>> @@ -25,6 +25,7 @@ obj-$(CONFIG_HTC_PASIC3)   += htc-pasic3.o
>>  obj-$(CONFIG_HTC_I2CPLD)+= htc-i2cpld.o
>>  
>>  obj-$(CONFIG_MFD_TI_LP873X) += lp873x.o
>> +obj-$(CONFIG_MFD_TI_LP87565)+= lp87565.o
>>  
>>  obj-$(CONFIG_MFD_DAVINCI_VOICECODEC)+= davinci_voicecodec.o
>>  obj-$(CONFIG_MFD_DM355EVM_MSP)  += dm355evm_msp.o
>> diff --git a/drivers/mfd/lp87565.c b/drivers/mfd/lp87565.c
>> new file mode 100644
>> index 000..dff882f
>> --- /dev/null
>> +++ b/drivers/mfd/lp87565.c
>> @@ -0,0 +1,103 @@
>> +/*
>> + * Copyright (C) 2017 

Re: [PATCH] arm64: dts: rockchip: update cpu opp table for rk3399 op1

[Eddie Cai]

Hi Heiko

2017-05-22 23:02 GMT+08:00 Heiko Stuebner :
> Hi Eddie, Caesar,
>
> Am Montag, 24. April 2017, 18:29:26 CEST schrieb Eddie Cai:
>> Hi Heiko
>>
>> 2017-04-24 17:15 GMT+08:00 Heiko Stübner :
>> > Am Montag, 24. April 2017, 16:49:08 CEST schrieb Caesar Wang:
>> >> 在 2017年04月24日 16:26, Heiko Stübner 写道:
>> >> > Hi Caesar,
>> >> >
>> >> > Am Montag, 24. April 2017, 14:18:50 CEST schrieb Caesar Wang:
>> >> >> Update the cpu opp table for rk3399 op1.
>> >> >
>> >> > Ideally this should contain something about the "why".
>> >> > Are these new voltage settings safer to operate under?
>> >>
>> >> The before opp table is for earlier batch of rk3399 SoCs,  that's no
>> >> enough for the current and
>> >> newer batch of rk3399 op1. In order to suit for the rk3399 op1, we need
>> >> to little voltages changed.
>> >
>> > just to make sure, this is also safe for all the non-chromebook rk3399 socs
>> > (like the firefly and tv-boxes, etc), right?
>> This is only for op1. other 3399s should have a different opp table
>
> digging this up, as I'm right now working on a rk3399-firefly, could you
> provide the correct opp tables for the available rk3399 variants please?
>
> I.e. generally safe opps for boards like the firefly and the special ones
> for op1-based devices?
here is for 3399:
https://github.com/rockchip-linux/kernel/blob/release-4.4/arch/arm64/boot/dts/rockchip/rk3399-opp.dtsi
here is for op1:
https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-4.4/arch/arm64/boot/dts/rockchip/rk3399-opp.dtsi
>
>
> Thanks
> Heiko

Re: mm, something wring in page_lock_anon_vma_read()?

[Hugh Dickins]

On Tue, 23 May 2017, Xishi Qiu wrote:
> On 2017/5/23 3:26, Hugh Dickins wrote:
> > I mean, there are various places in mm/memory.c which decide what they
> > intend to do based on orig_pte, then take pte lock, then check that
> > pte_same(pte, orig_pte) before taking it any further.  If a pte_same()
> > check were missing (I do not know of any such case), then two racing
> > tasks might install the same pte, one on top of the other - page
> > mapcount being incremented twice, but decremented only once when
> > that pte is finally unmapped later.
> > 
> 
> Hi Hugh,
> 
> Do you mean that the ptes from two racing point to the same page?
> or the two racing point to two pages, but one covers the other later?
> and the first page maybe alone in the lru list, and it will never be freed
> when the process exit.
> 
> We got this info before crash.
> [26068.316592] BUG: Bad rss-counter state mm:8800a7de2d80 idx:1 val:1

I might mean either: you are taking my suggestion too seriously,
it is merely a suggestion of one way in which this could happen.

Another way is ordinary memory corruption (whether by software error
or by flipped DRAM bits) of a page table: that could end up here too.

Hugh

[PATCH] ext4: fix quota charging for shared xattr blocks

[Tahsin Erdogan]

ext4_xattr_block_set() calls dquot_alloc_block() to charge for an xattr
block when new references are made. However if dquot_initialize() hasn't
been called on an inode, request for charging is effectively ignored
because ext4_inode_info->i_dquot is not initialized yet.

Add dquot_initialize() call to ext4_xattr_set_handle().

Signed-off-by: Tahsin Erdogan 
---
 fs/ext4/xattr.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/fs/ext4/xattr.c b/fs/ext4/xattr.c
index 8fb7ce14e6eb..e94575448550 100644
--- a/fs/ext4/xattr.c
+++ b/fs/ext4/xattr.c
@@ -1166,6 +1166,11 @@ ext4_xattr_set_handle(handle_t *handle, struct inode 
*inode, int name_index,
return -EINVAL;
if (strlen(name) > 255)
return -ERANGE;
+
+   error = dquot_initialize(inode);
+   if (error)
+   return error;
+
ext4_write_lock_xattr(inode, _expand);
 
error = ext4_reserve_inode_write(handle, inode, );
-- 
2.13.0.219.gdb65acc882-goog

Multiple longjmp definitions with STATIC_LINKING=y

[Florian Fainelli]

Hi Richard,

I have been playing with UML again and trying to get it to statically
link on a CentOS 6.9 host that has:

glibc-2.12-static
gcc-4.4

installed results in the following:

/usr/lib/gcc/x86_64-redhat-linux/4.4.7/../../../../lib64/libpthread.a(libpthread.o):
In function `siglongjmp':
(.text+0x8490): multiple definition of `longjmp'
arch/x86/um/built-in.o:/local/users/fainelli/openwrt/trunk/build_dir/target-x86_64_musl/linux-uml/linux-4.4.69/arch/x86/um/setjmp_64.S:44:
first defined here
/usr/lib/gcc/x86_64-redhat-linux/4.4.7/../../../../lib64/libpthread.a(libpthread.o):
In function `sem_open':
(.text+0x77cd): warning: the use of `mktemp' is dangerous, better use
`mkstemp'
collect2: ld returned 1 exit status
make[4]: *** [vmlinux] Error 1

Should we have some linker script magic not to export this symbol and
prevent a clash with libpthread.a pulling its own version?

Thanks!
-- 
Florian

Re: [PATCH 0/6] refine and rename slub sysfs

[Wei Yang]

On Thu, May 18, 2017 at 11:06:37AM +0200, Michal Hocko wrote:
>On Wed 17-05-17 22:11:40, Wei Yang wrote:
>> This patch serial could be divided into two parts.
>> 
>> First three patches refine and adds slab sysfs.
>> Second three patches rename slab sysfs.
>> 
>> 1. Refine slab sysfs
>> 
>> There are four level slabs:
>> 
>> CPU
>> CPU_PARTIAL
>> PARTIAL
>> FULL
>> 
>> And in sysfs, it use show_slab_objects() and cpu_partial_slabs_show() to
>> reflect the statistics.
>> 
>> In patch 2, it splits some function in show_slab_objects() which makes sure
>> only cpu_partial_slabs_show() covers statistics for CPU_PARTIAL slabs.
>> 
>> After doing so, it would be more clear that show_slab_objects() has totally 9
>> statistic combinations for three level of slabs. Each slab has three cases
>> statistic.
>> 
>> slabs
>> objects
>> total_objects
>> 
>> And when we look at current implementation, some of them are missing. So 
>> patch
>> 2 & 3 add them up.
>> 
>> 2. Rename sysfs
>> 
>> The slab statistics in sysfs are
>> 
>> slabs
>> objects
>> total_objects
>> cpu_slabs
>> partial
>> partial_objects
>> cpu_partial_slabs
>> 
>> which is a little bit hard for users to understand. The second three patches
>> rename sysfs file in this pattern.
>> 
>> xxx_slabs[[_total]_objects]
>> 
>> Finally it looks Like
>> 
>> slabs
>> slabs_objects
>> slabs_total_objects
>> cpu_slabs
>> cpu_slabs_objects
>> cpu_slabs_total_objects
>> partial_slabs
>> partial_slabs_objects
>> partial_slabs_total_objects
>> cpu_partial_slabs
>
>_Why_ do we need all this?

To have a clear statistics for each slab level.

>-- 
>Michal Hocko
>SUSE Labs

-- 
Wei Yang
Help you, Help me


signature.asc
Description: PGP signature

Re: [PATCH v3 0/3] Fix mdp device tree

[Minghsiu Tsai]

On Mon, 2017-05-22 at 16:16 +0200, Hans Verkuil wrote:
> On 05/22/2017 04:14 PM, Matthias Brugger wrote:
> > 
> > 
> > On 22/05/17 11:09, Hans Verkuil wrote:
> >> On 05/12/2017 05:22 AM, Minghsiu Tsai wrote:
> >>
> >> Who should take care of the dtsi changes? I'm not sure who maintains the 
> >> mdp dts.
> > 
> > I will take care of the dtsi patches.
> > 
> >>
> >> The driver change and the dtsi change need to be in sync, so it is 
> >> probably easiest
> >> to merge this via one tree.
> >>
> >> Here is my Acked-by for these three patches:
> >>
> >> Acked-by: Hans Verkuil 
> >>
> >> I can take all three, provided I have the Ack of the mdp dts maintainer. 
> >> Or it can
> >> go through him with my Ack.
> >>
> > 
> > I think we should provide backwards compability instead, as proposed here:
> > http://lists.infradead.org/pipermail/linux-mediatek/2017-May/008811.html
> > 
> > If this change is ok for you, please let Minghsiu know so that he can 
> > provide a v4.
> 
> That's a lot better. In that case I can take the media patches and you the 
> dts.
> 
> I'll wait for the v4.
> 

Hi Hans, Matthias,

I have uploaded v4, thanks.


> Regards,
> 
>   Hans
> 
> > 
> > Regards,
> > Matthias
> > 
> >> Regards,
> >>
> >>Hans
> >>
> >>> Changes in v3:
> >>> - Upload patches again because forget to add v2 in title
> >>>
> >>> Changes in v2:
> >>> - Update commit message
> >>>
> >>> If the mdp_* nodes are under an mdp sub-node, their corresponding
> >>> platform device does not automatically get its iommu assigned properly.
> >>>
> >>> Fix this by moving the mdp component nodes up a level such that they are
> >>> siblings of mdp and all other SoC subsystems.  This also simplifies the
> >>> device tree.
> >>>
> >>> Although it fixes iommu assignment issue, it also break compatibility
> >>> with old device tree. So, the patch in driver is needed to iterate over
> >>> sibling mdp device nodes, not child ones, to keep driver work properly.
> >>>
> >>> Daniel Kurtz (2):
> >>>arm64: dts: mt8173: Fix mdp device tree
> >>>media: mtk-mdp: Fix mdp device tree
> >>>
> >>> Minghsiu Tsai (1):
> >>>dt-bindings: mt8173: Fix mdp device tree
> >>>
> >>>   .../devicetree/bindings/media/mediatek-mdp.txt |  12 +-
> >>>   arch/arm64/boot/dts/mediatek/mt8173.dtsi   | 126 
> >>> ++---
> >>>   drivers/media/platform/mtk-mdp/mtk_mdp_core.c  |   2 +-
> >>>   3 files changed, 64 insertions(+), 76 deletions(-)
> >>>
> >>
> 

Re: RISC-V Linux Port v1

[Palmer Dabbelt]

On Mon, 22 May 2017 18:25:41 PDT (-0700), rdun...@infradead.org wrote:
> On 05/22/17 18:16, Olof Johansson wrote:
>> Hi Palmer,
>>
>> On Mon, May 22, 2017 at 5:41 PM, Palmer Dabbelt  wrote:
>>
>>> In addition to the threaded messages, our port can be found on Git Hib
>>>
>>>   https://github.com/riscv/riscv-linux/tree/riscv-for-submission-v1
>>>
>>> [PATCH 1/7] RISC-V: Top-Level Makefile for riscv{32,64}
>>> [PATCH 2/7] RISC-V: arch/riscv Makefile and Kconfigs
>>> [PATCH 3/7] RISC-V: Device Tree Documentation
>>> [PATCH 4/7] RISC-V: arch/riscv/include
>>> [PATCH 5/7] RISC-V: arch/riscv/lib
>>> [PATCH 6/7] RISC-V: arch/riscv/kernel
>>> [PATCH 7/7] RISC-V: arch/riscv/mm
>>
>> So, one overall comment on this patchset is that it's not bisectable
>> (i.e. early patches add Makefile contents that refers to directories
>> not yet introduced).
>>
>> While it's not overly important to really split up a new architecture
>> introduction into small incremental patches, we generally strive to
>> have the tree fully buildable at any given commit. Some minor
>> rearranging would alleviate these problems.
>
> Neither the email patches nor the git tree have any Signed-off-by:
> entries AFAICT.

Makes sense.  I went through and checked everything for copyright, so I'll sign
off on the next patch set.

Thanks!