Re: [PATCH 1/3] arm64: extend ioremap for cacheable non-shareable memory

[Roy Pledge]

These transactions are done in HW via an ACP port which if I remember correctly 
only supports non coherent transactions.  I will need to go back and check 
through email conversations I had with Catalin last year when debugging an 
issue using this mechanism (cacheable/nonshareable mapping) but it was deemed 
to be valid ARM setup architecturally for this type of device.

Just for some background the page the QBMan device presented to a core is only 
accessed by a single core (i.e. SW portals are core affine). In this model each 
page is always mapped as non shareable and another core will never access it. 
The important factor is that it is not DDR memory being mapped non sharable, 
but a non-coherent master on the bus in our SoC.  I agree regular RAM shouldn’t 
be mapped this way but we cannot map this device as cacheable/shareable 
(coherent) on CCN-504 devices without getting exceptions from the CCN-504. 
Treating it as non cacheable is functionally OK but performance suffers in that 
case.

Your help will be appreciated as we want to get support for these devices with 
good performance in upstream kernels.

Roy

On 2017-04-21, 5:11 AM, "Mark Rutland"  wrote:

Hi,

I notice you missed Catalin and Will from Cc. In future, please ensure
that you Cc them when altering arm64 arch code.

On Thu, Apr 20, 2017 at 03:34:16PM -0400, Haiying Wang wrote:
> NXP arm64 based SoC needs to allocate cacheable and
> non-shareable memory for the software portals of
> Queue manager, so we extend the arm64 ioremap support
> for this memory attribute.

NAK to this patch.

It is not possible to safely use Non-Shareable attributes in Linux page
tables, given that these page tables are shared by all PEs (i.e. CPUs).

My understanding is that if several PEs map a region as Non-Shareable,
the usual background behaviour of the PEs (e.g. speculation,
prefetching, natural eviction) mean that uniprocessor semantics are not
guaranteed (i.e. a read following a write may see stale data).

For example, in a system like:

+--+  +--+
| PE-a |  | PE-b |
+--+  +--+
| L1-a |  | L1-b |
+--+  +--+
   ||||
++
|  Shared cache  |
++
||
++
| Memory |
++

... you could have a sequence like:

1) PE-a allocates a line into L1-a for address X in preparation for a
   store.

2) PE-b allocates a line into L1-b for the same address X as a result of
   speculation.

3) PE-a makes a store to the line in L1-a. Since address X is mapped as
   Non-shareable, no snoops are performed to keep other copies of the
   line in sync.

4) As a result of explicit maintenance or as a natural eviction, L1-a
   evicts its line into shared cache. The shared cache subsequently
   evicts this to memory.

5) L1-b evicts its line to shared cache as a natural eviction.

6) L1-a fetches the line from shared cache in response to a load by
   PE-a, returning stale data (i.e. the store is lost).

No amount of cache maintenance can avoid this. In general, Non-Shareable
mappings are a bad idea.

Thanks,
Mark.

> Signed-off-by: Haiying Wang 
> ---
>  arch/arm64/include/asm/io.h   | 1 +
>  arch/arm64/include/asm/pgtable-prot.h | 1 +
>  2 files changed, 2 insertions(+)
> 
> diff --git a/arch/arm64/include/asm/io.h b/arch/arm64/include/asm/io.h
> index 0c00c87..b6f03e7 100644
> --- a/arch/arm64/include/asm/io.h
> +++ b/arch/arm64/include/asm/io.h
> @@ -170,6 +170,7 @@ extern void __iomem *ioremap_cache(phys_addr_t 
phys_addr, size_t size);
>  #define ioremap_nocache(addr, size)  __ioremap((addr), (size), 
__pgprot(PROT_DEVICE_nGnRE))
>  #define ioremap_wc(addr, size)   __ioremap((addr), (size), 
__pgprot(PROT_NORMAL_NC))
>  #define ioremap_wt(addr, size)   __ioremap((addr), (size), 
__pgprot(PROT_DEVICE_nGnRE))
> +#define ioremap_cache_ns(addr, size) __ioremap((addr), (size), 
__pgprot(PROT_NORMAL_NS))
>  #define iounmap  __iounmap
>  
>  /*
> diff --git a/arch/arm64/include/asm/pgtable-prot.h 
b/arch/arm64/include/asm/pgtable-prot.h
> index 2142c77..7fc7910 100644
> --- a/arch/arm64/include/asm/pgtable-prot.h
> +++ b/arch/arm64/include/asm/pgtable-prot.h
> @@ -42,6 +42,7 @@
>  #define PROT_NORMAL_NC   (PROT_DEFAULT | PTE_PXN | PTE_UXN | 
PTE_DIRTY | PTE_WRITE | PTE_ATTRINDX(MT_NORMAL_NC))
>  #define PROT_NORMAL_WT   (PROT_DEFAULT | PTE_PXN | PTE_UXN | 
PTE_DIRTY | PTE_WRITE | PTE_ATTRINDX(MT_NORMAL_WT))
>  #define PROT_NORMAL  (PROT_DEFAULT | 

Re: [PATCH 3/5] KEYS: encrypted: sanitize all key material

[David Howells]

Eric Biggers  wrote:

> - memzero_explicit(epayload->decrypted_data, epayload->decrypted_datalen);
> - kfree(key->payload.data[0]);
> + kzfree(key->payload.data[0]);

Should kzfree() be using memzero_explicit() rather than memset()?

David

[PATCH v1 2/8] ASoC: Intel: Skylake: Use recently introduced uuid_le_cmp_p{p}()

[Andy Shevchenko]

Recently introduced helpers take pointers to uuid_{be|le} instead of
reference.

Using them makes code less ugly.

Cc: Liam Girdwood 
Cc: Mark Brown 
Cc: Vinod Koul 
Signed-off-by: Andy Shevchenko 
---
 sound/soc/intel/skylake/skl-pcm.c   | 2 +-
 sound/soc/intel/skylake/skl-sst-utils.c | 4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/sound/soc/intel/skylake/skl-pcm.c 
b/sound/soc/intel/skylake/skl-pcm.c
index 600faad19bd4..4bf171985872 100644
--- a/sound/soc/intel/skylake/skl-pcm.c
+++ b/sound/soc/intel/skylake/skl-pcm.c
@@ -1207,7 +1207,7 @@ static int skl_get_module_info(struct skl *skl, struct 
skl_module_cfg *mconfig)
}
 
list_for_each_entry(module, >uuid_list, list) {
-   if (uuid_le_cmp(*uuid_mod, module->uuid) == 0) {
+   if (uuid_le_cmp_p(uuid_mod, module->uuid) == 0) {
mconfig->id.module_id = module->id;
mconfig->is_loadable = module->is_loadable;
return 0;
diff --git a/sound/soc/intel/skylake/skl-sst-utils.c 
b/sound/soc/intel/skylake/skl-sst-utils.c
index 6d5bff04bf65..67288580c743 100644
--- a/sound/soc/intel/skylake/skl-sst-utils.c
+++ b/sound/soc/intel/skylake/skl-sst-utils.c
@@ -189,7 +189,7 @@ int skl_get_pvt_id(struct skl_sst *ctx, uuid_le *uuid_mod, 
int instance_id)
int pvt_id;
 
list_for_each_entry(module, >uuid_list, list) {
-   if (uuid_le_cmp(*uuid_mod, module->uuid) == 0) {
+   if (uuid_le_cmp_p(uuid_mod, module->uuid) == 0) {
 
pvt_id = skl_pvtid_128(module);
if (pvt_id >= 0) {
@@ -218,7 +218,7 @@ int skl_put_pvt_id(struct skl_sst *ctx, uuid_le *uuid_mod, 
int *pvt_id)
struct uuid_module *module;
 
list_for_each_entry(module, >uuid_list, list) {
-   if (uuid_le_cmp(*uuid_mod, module->uuid) == 0) {
+   if (uuid_le_cmp_p(uuid_mod, module->uuid) == 0) {
 
if (*pvt_id != 0)
i = (*pvt_id) / 64;
-- 
2.11.0

Re: [PATCH 1/3] jump_label: Pull get_online_cpus() into generic code

[Jason Baron]

On 04/18/2017 06:32 AM, Peter Zijlstra wrote:

This change does two things; it moves the get_online_cpus() call into
generic code, with the aim of later providing some static_key ops that
avoid it.

And as a side effect it inverts the relation between cpu_hotplug_lock
and jump_label_mutex.

Signed-off-by: Peter Zijlstra (Intel) 
---


...


@@ -146,6 +154,7 @@ static void __static_key_slow_dec(struct
 * returns is unbalanced, because all other static_key_slow_inc()
 * instances block while the update is in progress.
 */
+   get_online_cpus();
if (!atomic_dec_and_mutex_lock(>enabled, _label_mutex)) {
WARN(atomic_read(>enabled) < 0,
 "jump label: negative count!\n");


So the get and put can be unbalanced here since the above:

'if (!atomic_dec_and_mutex_lock(>enabled, _label_mutex))'

is followed by 'return;'. However, I see that the next patch removes 
this and so things are balanced again...




@@ -159,6 +168,7 @@ static void __static_key_slow_dec(struct
jump_label_update(key);
}
jump_label_unlock();
+   put_online_cpus();
 }

 static void jump_label_update_timeout(struct work_struct *work)
@@ -592,6 +602,10 @@ jump_label_module_notify(struct notifier

switch (val) {
case MODULE_STATE_COMING:
+   /*
+* XXX do we need get_online_cpus() ?  the module isn't
+* executable yet, so nothing should be looking at our code.
+*/


Since we're just updating the table of places we potentially need to 
patch, but not actually doing any patching, we should not need 
get_online_cpus() here...so in attempt to reduce confusion I would 
remove this.


Thanks,

-Jason

Re: [PATCH 0/5] v2: block subsystem refcounter conversions

[Jens Axboe]

On 04/21/2017 09:22 AM, Peter Zijlstra wrote:
> On Fri, Apr 21, 2017 at 08:03:13AM -0600, Jens Axboe wrote:
>> You have it so easy - the code is completely standalone, building a
>> small test framework around it and measuring performance in _user space_
>> is trivial.
> 
> Something like this you mean:
> 
>   
> https://lkml.kernel.org/r/20170322165144.dtidvvbxey7w5...@hirez.programming.kicks-ass.net

Yes, exactly. But it'd be great to see better coverage of the API, and
various cases of X threads running operations on the same refcount,
so we get a full view of that side too. The above looks like just
counting cycles for a single op of foo_inc().

-- 
Jens Axboe

Re: [PATCH v13 03/10] mux: minimal mux subsystem and gpio-based mux controller

[Philipp Zabel]

On Fri, 2017-04-21 at 16:32 +0200, Peter Rosin wrote:
> On 2017-04-21 16:23, Philipp Zabel wrote:
> > On Thu, 2017-04-13 at 18:43 +0200, Peter Rosin wrote:
> > [...]
> >> +int mux_chip_register(struct mux_chip *mux_chip)
> >> +{
> >> +  int i;
> >> +  int ret;
> >> +
> >> +  for (i = 0; i < mux_chip->controllers; ++i) {
> >> +  struct mux_control *mux = _chip->mux[i];
> >> +
> >> +  if (mux->idle_state == mux->cached_state)
> >> +  continue;
> > 
> > I think this should be changed to
> >  
> > -   if (mux->idle_state == mux->cached_state)
> > +   if (mux->idle_state == mux->cached_state ||
> > +   mux->idle_state == MUX_IDLE_AS_IS)
> > continue;
> > 
> > or the following mux_control_set will be called with state ==
> > MUX_IDLE_AS_IS. Alternatively, mux_control_set should return when passed
> > this value.
> 
> That cannot happen because ->cached_state is initialized to -1
> in mux_chip_alloc, so should always be == MUX_IDLE_AS_IS when
> registering. And drivers are not supposed to touch ->cached_state.
> I.e., ->cached_state is "owned" by the core.

So this was caused by me filling cached_state from register reads in the
mmio driver. Makes me wonder why I am not allowed to do this, though, if
I am able to read back the initial state?

regards
Philipp

[PATCH v5 4/6] mtd: dataflash: Get rid of loop counter in jedec_probe()

[Andrey Smirnov]

"For" loop in jedec_probe can be simplified to not need counter
'i'. Convert the code and get rid of the variable.

Cc: cphe...@gmail.com
Cc: David Woodhouse 
Cc: Brian Norris 
Cc: Boris Brezillon 
Cc: Marek Vasut 
Cc: Richard Weinberger 
Cc: Cyrille Pitchen 
Cc: linux-kernel@vger.kernel.org
Reviewed-by: Marek Vasut 
Signed-off-by: Andrey Smirnov 
---

No changes since [v4]

Changes since [v3]

- Collected Reviewed-by from Marek

Not present in v2, v1

[v3] http://lkml.kernel.org/r/20170419152305.17226-4-andrew.smir...@gmail.com
[v4] http://lkml.kernel.org/r/20170420162952.5181-4-andrew.smir...@gmail.com

 drivers/mtd/devices/mtd_dataflash.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/mtd/devices/mtd_dataflash.c 
b/drivers/mtd/devices/mtd_dataflash.c
index ccd1e02..2d3e403 100644
--- a/drivers/mtd/devices/mtd_dataflash.c
+++ b/drivers/mtd/devices/mtd_dataflash.c
@@ -736,7 +736,7 @@ static struct flash_info dataflash_data[] = {
 
 static struct flash_info *jedec_probe(struct spi_device *spi)
 {
-   int ret, i;
+   int ret;
u8 code = OP_READ_ID;
u8 id[3];
u32 jedec;
@@ -767,9 +767,9 @@ static struct flash_info *jedec_probe(struct spi_device 
*spi)
jedec = jedec << 8;
jedec |= id[2];
 
-   for (i = 0, info = dataflash_data;
-   i < ARRAY_SIZE(dataflash_data);
-   i++, info++) {
+   for (info = dataflash_data;
+info < dataflash_data + ARRAY_SIZE(dataflash_data);
+info++) {
if (info->jedec_id == jedec) {
dev_dbg(>dev, "OTP, sector protect%s\n",
(info->flags & SUP_POW2PS) ?
-- 
2.9.3

Re: [PATCH v13 03/10] mux: minimal mux subsystem and gpio-based mux controller

[Philipp Zabel]

On Fri, 2017-04-21 at 16:55 +0200, Peter Rosin wrote:
> On 2017-04-21 16:41, Philipp Zabel wrote:
> > On Fri, 2017-04-21 at 16:32 +0200, Peter Rosin wrote:
> >> On 2017-04-21 16:23, Philipp Zabel wrote:
> >>> On Thu, 2017-04-13 at 18:43 +0200, Peter Rosin wrote:
> >>> [...]
>  +int mux_chip_register(struct mux_chip *mux_chip)
>  +{
>  +int i;
>  +int ret;
>  +
>  +for (i = 0; i < mux_chip->controllers; ++i) {
>  +struct mux_control *mux = _chip->mux[i];
>  +
>  +if (mux->idle_state == mux->cached_state)
>  +continue;
> >>>
> >>> I think this should be changed to
> >>>  
> >>> -   if (mux->idle_state == mux->cached_state)
> >>> +   if (mux->idle_state == mux->cached_state ||
> >>> +   mux->idle_state == MUX_IDLE_AS_IS)
> >>> continue;
> >>>
> >>> or the following mux_control_set will be called with state ==
> >>> MUX_IDLE_AS_IS. Alternatively, mux_control_set should return when passed
> >>> this value.
> >>
> >> That cannot happen because ->cached_state is initialized to -1
> >> in mux_chip_alloc, so should always be == MUX_IDLE_AS_IS when
> >> registering. And drivers are not supposed to touch ->cached_state.
> >> I.e., ->cached_state is "owned" by the core.
> > 
> > So this was caused by me filling cached_state from register reads in the
> > mmio driver. Makes me wonder why I am not allowed to do this, though, if
> > I am able to read back the initial state?
> 
> You gain fairly little by reading back the original state. If the mux
> should idle-as-is, you can avoid a maximum of one mux update if the first
> consumer happens to starts by requesting the previously active state.
> Similarly, if the mux should idle in a specific state, you can avoid a
> maximum of one mux update.
> 
> In both cases it costs one unconditional read of the mux state.
> 
> Sure, in some cases reads are cheaper than writes, but I didn't think
> support for seeding the cache was worth it. Is it worth it?

Probably not, I'll just drop the cached_state initialization. It should
be documented in the mux.h that this field is framework internal and not
to be touched by the drivers. At least I was surprised.

regards
Philipp

[GIT PULL 2/2] arm64 dts: exynos: Last round for v4.12

[Krzysztof Kozlowski]

Hi,

On top of previous pull request.

Best regards,
Krzysztof


The following changes since commit e3c07546747cdec07ff15c984bc6cebc9c9f788c:

  arm64: dts: exynos: Add the burst and esc clock frequency properties to DSI 
node (2017-03-08 08:55:39 +0200)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git 
tags/samsung-dt64-4.12-2

for you to fetch changes up to 5dccc9873c4af60f4478b3ef54267353f25cc301:

  arm64: dts: exynos: Use - instead of @ for DT OPP entries (2017-04-20 
18:10:05 +0200)


Second update of  Samsung DeviceTree ARM64 for v4.12:
 - Fix DTC warnings in Exynos ARM64 Device Tree sources.
 - Add panel node to TM2E board.


Hoegeun Kwon (1):
  arm64: dts: exynos: Add support for s6e3hf2 panel device on TM2e board

Viresh Kumar (1):
  arm64: dts: exynos: Use - instead of @ for DT OPP entries

 arch/arm64/boot/dts/exynos/exynos5433-bus.dtsi | 48 -
 arch/arm64/boot/dts/exynos/exynos5433-tm2e.dts | 11 ++
 arch/arm64/boot/dts/exynos/exynos5433.dtsi | 50 +-
 3 files changed, 60 insertions(+), 49 deletions(-)

Re: [GIT PULL] PCI fixes for v4.11

[Bjorn Helgaas]

[+cc linux-pci, linux-kernel, Mark, Dongdong]

On Fri, Apr 21, 2017 at 11:20:58AM -0500, Bjorn Helgaas wrote:
> Hi Linus,
> 
> Sorry this is so late.  It's been in -next for over a week, but I forgot to
> send it on until now.
> 
> 
> PCI fix:
> 
>   - fix HiSilicon DT binding
> 
> The following changes since commit 794a8604fe6e4a311373cde57a86ad4aab9d32b8:
> 
>   PCI: dwc: Fix dw_pcie_ops NULL pointer dereference (2017-04-04 08:24:25 
> -0500)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git 
> tags/pci-v4.11-fixes-5
> 
> for you to fetch changes up to b9c1153f7a9cb2d53b845615a0edd510f7fe8341:
> 
>   PCI: hisi: Fix DT binding (hisi-pcie-almost-ecam) (2017-04-12 10:46:47 
> -0500)
> 
> 
> pci-v4.11-fixes-5
> 
> 
> Dongdong Liu (1):
>   PCI: hisi: Fix DT binding (hisi-pcie-almost-ecam)
> 
>  Documentation/devicetree/bindings/pci/hisilicon-pcie.txt | 10 --
>  drivers/pci/dwc/pcie-hisi.c  |  6 +-
>  2 files changed, 13 insertions(+), 3 deletions(-)

[GIT PULL 1/2] ARM: dts: exynos: Last round for v4.12

[Krzysztof Kozlowski]

Hi,

I know it is late so just one fix for v4.12.
On top of previous pull request.

Best regards,
Krzysztof


The following changes since commit a1146328ec47141007a6ec076e1cbfc80f31887f:

  Merge tag 'samsung-dt-hdmi-cec-4.12' into next/dt (2017-03-31 00:27:18 +0300)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git 
tags/samsung-dt-4.12-2

for you to fetch changes up to 6a611d149a9a1eff7c89e81bab018e4121cce17e:

  ARM: dts: exynos: Use - instead of @ for DT OPP entries (2017-04-20 18:06:03 
+0200)


Fix DTC warnings in Exynos ARMv7 Device Tree sources.


Viresh Kumar (1):
  ARM: dts: exynos: Use - instead of @ for DT OPP entries

 .../devicetree/bindings/devfreq/exynos-bus.txt | 46 +++
 arch/arm/boot/dts/exynos3250.dtsi  | 46 +++
 arch/arm/boot/dts/exynos4210.dtsi  | 32 +--
 arch/arm/boot/dts/exynos4412-prime.dtsi|  4 +-
 arch/arm/boot/dts/exynos4412.dtsi  | 66 +++---
 arch/arm/boot/dts/exynos5420.dtsi  | 40 ++---
 arch/arm/boot/dts/exynos5800.dtsi  | 56 +-
 .../boot/dts/exynos/exynos5433-tm2-common.dtsi | 43 +-
 arch/arm64/boot/dts/exynos/exynos5433-tm2.dts  | 17 ++
 arch/arm64/boot/dts/exynos/exynos5433-tm2e.dts | 18 ++
 10 files changed, 221 insertions(+), 147 deletions(-)

Re: [PATCH v13 03/10] mux: minimal mux subsystem and gpio-based mux controller

[Peter Rosin]

On 2017-04-21 16:18, Philipp Zabel wrote:
> Hi Peter,
> 
> On Thu, 2017-04-13 at 18:43 +0200, Peter Rosin wrote:
> [...]
>> +int mux_control_select(struct mux_control *mux, int state)
> 
> state could be unsigned int for the consumer facing API.
> 
>> +{
>> +int ret;
> 
> And mux_control_select should check that (0 <= state < mux->states).

Yes, that makes sense. I worried that we might end up with
signed/unsigned comparisons since the internal state still needs
to be signed, but that didn't happen when I tried...

I'll include this change in v14.

Cheers,
peda

[PATCH] mm: gup: fix access_ok() argument type

[Arnd Bergmann]

MIPS just got changed to only accept a pointer argument for access_ok(),
causing one warning in drivers/scsi/pmcraid.c. I tried changing x86
the same way and found the same warning in __get_user_pages_fast()
and nowhere else in the kernel during randconfig testing:

mm/gup.c: In function '__get_user_pages_fast':
mm/gup.c:1578:6: error: passing argument 1 of '__chk_range_not_ok' makes 
pointer from integer without a cast [-Werror=int-conversion]

It would probably be a good idea to enforce type-safety in general,
so let's change this file to not cause a warning if we do that.

I don't know why the warning did not appear on MIPS.

Fixes: 2667f50e8b81 ("mm: introduce a general RCU get_user_pages_fast()")
Cc: Alexander Viro 
Signed-off-by: Arnd Bergmann 
---
 mm/gup.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/mm/gup.c b/mm/gup.c
index 2559a3987de7..7f5bc26d9229 100644
--- a/mm/gup.c
+++ b/mm/gup.c
@@ -1575,7 +1575,7 @@ int __get_user_pages_fast(unsigned long start, int 
nr_pages, int write,
end = start + len;
 
if (unlikely(!access_ok(write ? VERIFY_WRITE : VERIFY_READ,
-   start, len)))
+   (void __user *)start, len)))
return 0;
 
/*
-- 
2.9.0

Re: [PATCH 3.18 000/124] 3.18.50-stable review

[Guenter Roeck]

On Fri, Apr 21, 2017 at 06:35:28AM +0200, Greg Kroah-Hartman wrote:
> On Thu, Apr 20, 2017 at 08:38:16PM -0700, Guenter Roeck wrote:
> > On 04/20/2017 12:53 PM, Greg Kroah-Hartman wrote:
> > > On Thu, Apr 20, 2017 at 04:28:03PM +0200, Greg Kroah-Hartman wrote:
> > > > On Thu, Apr 20, 2017 at 06:46:11AM -0700, Guenter Roeck wrote:
> > > > > On 04/19/2017 11:34 PM, Greg Kroah-Hartman wrote:
> > > > > > This is the start of the stable review cycle for the 3.18.50 
> > > > > > release.
> > > > > > There are 124 patches in this series, all will be posted as a 
> > > > > > response
> > > > > > to this one.  If anyone has any issues with these being applied, 
> > > > > > please
> > > > > > let me know.
> > > > > > 
> > > > > > Responses should be made by Sat Apr 22 06:35:33 UTC 2017.
> > > > > > Anything received after that time might be too late.
> > > > > > 
> > > > > 
> > > > > Build results:
> > > > >   total: 139 pass: 133 fail: 6
> > > > > Failed builds:
> > > > >   arm:at91_dt_defconfig
> > > > >   arm:sama5_defconfig
> > > > >   avr32:defconfig
> > > > >   avr32:merisc_defconfig
> > > > >   avr32:atngw100mkii_evklcd101_defconfig
> > > > >   mips:cavium_octeon_defconfig
> > > > > 
> > > > > Qemu test results:
> > > > >   total: 111 pass: 111 fail: 0
> > > > > 
> > > > > Build errors:
> > > > > 
> > > > > drivers/tty/serial/atmel_serial.c: In function 'atmel_flush_buffer':
> > > > > drivers/tty/serial/atmel_serial.c:1874: error: 'struct 
> > > > > atmel_uart_port' has no member named 'tx_len'
> > > > > 
> > > > > Culprit: 2ac3772fd20e ("tty/serial: atmel: fix race condition 
> > > > > (TX+DMA)")
> > > > 
> > > > I've just fixed this one.
> > > > 
> > > > > arch/mips/mm/tlbex.c: In function 'build_huge_handler_tail':
> > > > > arch/mips/mm/tlbex.c:767:6: error: 'cpu_has_ftlb' undeclared
> > > > > 
> > > > > Culprit: 9c2c357eb4aa ("MIPS: Flush wrong invalid FTLB entry for huge 
> > > > > page")
> > > > 
> > > > Odd, let me dig into this one...
> > > 
> > > That looks to fix an issue that showed up in 4.3, so I've dropped it
> > > from the 3.18 stable queue now.
> > > 
> > > thanks for the report, all should be good now.
> > > 
> > 
> > Are you sure ?
> > 
> > groeck@server:~/src/linux-stable$ git grep cpu_has_ftlb
> > arch/mips/mm/tlbex.c:   if (cpu_has_ftlb && flush) {
> > groeck@server:~/src/linux-stable$ git describe
> > v3.18.49-125-g7379419992fb
> 
> {sigh} it would help if I actually pushed the commit to kernel.org :(
> 
> The patch has been deleted from the stable-queue now.
> 
Confirmed. No more errors.

Thanks,
Guenter

Re: [PATCH v17 2/3] usb: USB Type-C connector class

[Guenter Roeck]

On Fri, Apr 21, 2017 at 07:57:52PM +0530, Rajaram R wrote:
> On Fri, Apr 21, 2017 at 1:16 AM, Badhri Jagan Sridharan
>  wrote:
> > Thanks for the responses :)
> >
> > So seems like we have a plan.
> >
> > In Type-C connector class the checks for TYPEC_PWR_MODE_PD
> > and pd_revision for both the port and the partner will be removed in
> > power_role_store and the data_role_store and will be delegated
> > to the low level drivers.
> 
> It is important to remember what USB Type-C provide is mechanisms for
> "TRYing" to become a particular role and not guaranteeing.
> 
> With what device combination do you fore see we could get the desired
> role with this change ?
> 

If the partner is not PD capable, if a preferred role is specified, 
if the current cole does not match the preferred role, and if the request
is to set the role to match the preferred role, I think it is reasonable
to expect that re-establishing the connection would accomplish that if the
partner supports it.

Of course, that won't change anything if the partner does not support the
desired role, but it is better than doing nothing. This is also comparable
to requesting a role change from the partner if it does support PD.

Do you have a better idea ?

Thanks,
Guenter

> 
> >
> > TCPM code will issue hard reset in tcpm_dr_set and tcpm_pr_set if
> > current_role is not same as the preferred_role.
> >

... if the partner is not PD capable.

> > I am going to make changes in my local kernel code base to start
> > making the corresponding changes in userspace.
> > Should I post-back the local kernel changes or Heikki and Geunter
> > you are planning to upload them ?
> >
> > Thanks for the support !!
> > Badhri.
> >
> > On Thu, Apr 20, 2017 at 5:24 AM, Heikki Krogerus
> >  wrote:
> >> On Wed, Apr 19, 2017 at 10:22:47AM -0700, Badhri Jagan Sridharan wrote:
> >>> On Wed, Apr 19, 2017 at 8:14 AM, Guenter Roeck  wrote:
> >>> > On Wed, Apr 19, 2017 at 07:45:00AM -0700, Badhri Jagan Sridharan wrote:
> >>> >> On Wed, Apr 19, 2017 at 4:23 AM, Heikki Krogerus
> >>> >>  wrote:
> >>> >> > Hi,
> >>> >> >
> >>> >> > On Tue, Apr 18, 2017 at 11:52:33AM -0700, Badhri Jagan Sridharan 
> >>> >> > wrote:
> >>> >> >> Hi Heikki,
> >>> >> >>
> >>> >> >> I have a question regarding the preferred_role node.
> >>> >> >>
> >>> >> >> +What:  /sys/class/typec//preferred_role
> >>> >> >> +Date:  March 2017
> >>> >> >> +Contact:   Heikki Krogerus 
> >>> >> >> +Description:
> >>> >> >> +   The user space can notify the driver about the 
> >>> >> >> preferred role.
> >>> >> >> +   It should be handled as enabling of Try.SRC or 
> >>> >> >> Try.SNK, as
> >>> >> >> +   defined in USB Type-C specification, in the port 
> >>> >> >> drivers. By
> >>> >> >> +   default the preferred role should come from the 
> >>> >> >> platform.
> >>> >> >> +
> >>> >> >> +   Valid values: source, sink, none (to remove 
> >>> >> >> preference)
> >>> >> >>
> >>> >> >> What is the expected behavior when the userspace changes the
> >>> >> >> preferred_role node when the port is in connected state ?
> >>> >> >>
> >>> >> >> 1.  the state machine re-resolves the port roles right away based on
> >>> >> >> the new state machine in place ? (or)
> >>> >> >
> >>> >> > No! There are separate attributes for sending role swap requests.
> >>> >>
> >>> >> Right. But, that might not be helpful in cases when PD is not 
> >>> >> implemented.
> >>> >> and Implementing PD is not mandatory according the spec :/
> >>> >>
> >>> >> FYI quoting from the Type-C specification release(page 24),
> >>> >> role swaps are not limited to devices that only support PD.
> >>> >>
> >>> >> "Two independent set of mechanisms are defined to allow a USB Type-C
> >>> >> DRP to functionally swap power and data roles. When USB PD is
> >>> >> supported, power and data role swapping is performed as a subsequent
> >>> >> step following the initial connection process. For non-PD 
> >>> >> implementations,
> >>> >> power/data role swapping can optionally be dealt with as part of the 
> >>> >> initial
> >>> >> connection process."
> >>> >>
> >>> >> But, the current interface definition actually prevents current/data 
> >>> >> role
> >>> >> swaps for non-pd devices.
> >>> >>
> >>>
> >>> > This is correct for the attribute definition, but it is not implemented
> >>> > that way. Writing the attribute is only read-only for non-DRP ports.
> >>>
> >>> i.e. tcpm_dr_set/tcpm_pr_set at tcpm.c would return EINVAL when type
> >>> is not TYPEC_PORT_DRP, is that what you are referring to ?
> >>>
> >>> if (port->typec_caps.type != TYPEC_PORT_DRP) {
> >>> ret = -EINVAL;
> >>> goto port_unlock;
> >>> }
> >>>
> >>> I do agree that this is actually correct. I am referring to the case
> >>> where port is
> 

Re: Doubt on first access for PCIe device

[Lorenzo Pieralisi]

On Fri, Apr 21, 2017 at 03:33:45PM +0530, abhijit naik wrote:
>Hi Lorenzo,
>Thank you very much for reply.
>As you mentioned I noted that, "If a Function must generate a Completion
>prior to the initial device Configuration Write Request, 0's must be
>entered into the Bus Number and Device Number fields"
>By above statement this means that completion ID will be 0x. For the
>first device on any bus,  device number will be 0 and function number will
>be 0.
>Isn't completer (for configuration read) packet will be addressing itself
>instead of root complex with bus, device and function number 0?

I don't understand what you are asking. The completion (containing
the read data) is routed back to the initiator via ID (of the requester)
routing.

2.2.4.2
2.2.9

Lorenzo

>On Wed, Apr 19, 2017 at 3:56 PM, Lorenzo Pieralisi
> wrote:
> 
>  On Tue, Apr 11, 2017 at 07:45:40PM +0530, abhijit wrote:
>  >
>  > Hi All,
>  >
>  > I was referring Linux code for PCIe enumeration and I have one doubt
>  > w.r.t to very first operation that must be done on device.
>  >
>  > Currently while scanning for device, we directly read vendor ID from
>  > device. But PCIE base specification
>  > "CB-PCI_Express_Base_4.0r0.7_November-11-2016.pdf" section 2.2.6.2
>  > specifies that,
>  >
>  > "Functions must capture the Bus and Device Numbers supplied with all
>  > Type 0 Configuration Write Requests completed by the Function and
>  > supply these numbers in the Bus and Device Number fields of the
>  > Requester ID for all Requests initiated by the Device/Function."
> 
>  Please note:
>  "for all Requests initiated by the Device/Function".
>^
>  > Here I am assuming, the completer ID will be device number and
>  > function number that will eventually programmed in to  device. In
>  > that case, my question is, without first write, how read
>  > request(VENDOR ID read) is serviced/routed?
> 
>  That's not initiated by the endpoint device, it is routed by
>  requester ID, which is the requester ID of the configuration
>  request - ie master (ie root complex) requester ID.
> 
>  Read 2.2.9 - Completion rules
> 
>  HTH,
>  Lorenzo
> 
>--
>Best wishes,
>Abhijit Naik

Re: [PATCH v2 1/3] rtmutex: update rt-mutex-design

[Peter Zijlstra]

On Fri, Apr 21, 2017 at 10:12:53PM +0800, Alex Shi wrote:
> diff --git a/Documentation/locking/rt-mutex-design.txt 
> b/Documentation/locking/rt-mutex-design.txt
> index 8666070..11beb55 100644
> --- a/Documentation/locking/rt-mutex-design.txt
> +++ b/Documentation/locking/rt-mutex-design.txt
> @@ -97,9 +97,9 @@ waiter   - A waiter is a struct that is stored on the stack 
> of a blocked
> a process being blocked on the mutex, it is fine to allocate
> the waiter on the process's stack (local variable).  This
> structure holds a pointer to the task, as well as the mutex that
> -   the task is blocked on.  It also has the plist node structures to
> -   place the task in the waiter_list of a mutex as well as the
> -   pi_list of a mutex owner task (described below).
> +the task is blocked on.  It also has a rbtree node structures to
> +place the task in waiters rbtree of a mutex as well as the
> +pi_waiters rbtree of a mutex owner task (described below).

whitespace fail

>  
> waiter is sometimes used in reference to the task that is waiting
> on a mutex. This is the same as waiter->task.
> @@ -179,53 +179,35 @@ again.
>   |
> F->L5-+
>  
> +If the G process has highest priority in the chain, then all the tasks up
> +the chain (A and B in this example), must have their priorities increased
> +to that of G.

No, only the top task that's actually runnable needs to be modified. The
rest we don't care about because they're blocked.

> +Since the pi_waiters of a task holds an order by priority of all the top 
> waiters
> +of all the mutexes that the task owns, rt_mutex_getprio simply needs to 
> compare
> +the top pi waiter to its own normal priority, and return the higher priority
> +back.

rt_mutex_getprio() doesn't exist.

> +The main operation of this function is summarized by Thomas Gleixner in
> +rtmutex.c. See the 'Chain walk basics and protection scope' comment for 
> further
> +details.

Since all the useful bits are there anyway, why keep this document
around at all?

[GIT PULL rcu/next] RCU commits for 4.12

[Paul E. McKenney]

Hello, Ingo,

This pull request contains the following changes:

1.  Documentation updates.

http://lkml.kernel.org/r/20170412163956.ga15...@linux.vnet.ibm.com

2.  Miscellaneous fixes.

http://lkml.kernel.org/r/20170417232714.ga19...@linux.vnet.ibm.com

3.  Parallelize SRCU callback handling (plus overlapping patches).

http://lkml.kernel.org/r/20170419165805.gb10...@linux.vnet.ibm.com

http://lkml.kernel.org/r/87zifatu3a@concordia.ellerman.id.au

All of these changes have been subjected to 0day Test Robot and -next
testing, and are available in the git repository at:

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

for you to fetch changes up to f2094107ac82bf867184efd77cee30b6a98e2e20:

  Merge branches 'doc.2017.04.12a', 'fixes.2017.04.19a' and 'srcu.2017.04.21a' 
into HEAD (2017-04-21 06:00:13 -0700)


Dmitry Vyukov (1):
  rcu: Fix warning in rcu_seq_end()

Michael S. Tsirkin (1):
  hlist_add_tail_rcu disable sparse warning

Michalis Kokologiannakis (1):
  doc: Update the comparisons rule in rcu_dereference.txt

Nicholas Mc Guire (2):
  rcu: Use bool value directly
  rcu: Use true/false in assignment to bool

Paul E. McKenney (56):
  doc: Synchronous RCU grace periods are now legal throughout boot
  doc: Add mid-boot operation to expedited grace periods
  doc: Update stallwarn.txt to make causes more prominent
  doc: Update RCU data-structure documentation for rcu_segcblist
  doc: Update requirements based on recent changes
  doc: Update rcu_assign_pointer() definition in whatisRCU.txt
  doc: Emphasize that "toy" RCU requires recursive rwlock
  rcu: Maintain special bits at bottom of ->dynticks counter
  rcu: Make arch select smp_mb__after_unlock_lock() strength
  srcu: Consolidate batch checking into rcu_all_batches_empty()
  srcu: Check for tardy grace-period activity in cleanup_srcu_struct()
  rcu: Semicolon inside RCU_TRACE() for rcu.h
  rcu: Semicolon inside RCU_TRACE() for Tiny RCU
  rcu: Semicolon inside RCU_TRACE() for tree.c
  rcu: Pull rcu_sched_qs_mask into rcu_dynticks structure
  rcu: Pull rcu_qs_ctr into rcu_dynticks structure
  rcu: Eliminate flavor scan in rcu_momentary_dyntick_idle()
  rcu: Place guard on rcu_all_qs() and rcu_note_context_switch() actions
  rcu: Default RCU_FANOUT_LEAF to 16 unless explicitly changed
  srcu: Abstract multi-tail callback list handling
  srcu: Allow SRCU to access rcu_scheduler_active
  srcu: Allow early boot use of synchronize_srcu()
  rcu: Add single-element dequeue functions to rcu_segcblist
  srcu: Move rcu_seq_start() and friends to rcu.h
  rcu: Expedited wakeups need to be fully ordered
  srcu: Push srcu_advance_batches() fastpath into common case
  srcu: Move to state-based grace-period sequencing
  srcu: Add grace-period sequence numbers
  srcu: Use rcu_segcblist to track SRCU callbacks
  srcu: Move combining-tree definitions for SRCU's benefit
  srcu: Move rcu_init_levelspread() to rcu_tree_node.h
  rcu: Remove redundant levelcnt[] array from rcu_init_one()
  srcu: Move rcu_node traversal macros to rcu.h
  srcu: Make num_rcu_lvl[] array be external
  srcu: Fix bogus try_check_zero() comment
  srcu: Improve rcu_seq grace-period-counter abstraction
  srcu: Allow a second bit in rcu_seq for SRCU state
  srcu: Merge ->srcu_state into ->srcu_gp_seq
  srcu: Crude control of expedited grace periods
  mm: Use static initialization for "srcu"
  srcu: Create a tiny SRCU
  srcutorture: Print Tiny SRCU reader statistics
  srcu: Introduce CLASSIC_SRCU Kconfig option
  mm: Rename SLAB_DESTROY_BY_RCU to SLAB_TYPESAFE_BY_RCU
  lockdep: Use "WARNING" tag on lockdep splats
  types: Update obsolete callback_head comment
  rcu: Make RCU_FANOUT_LEAF help text more explicit about skew_tick
  rcu: Remove obsolete comment from rcu_future_gp_cleanup() header
  rcu: Improve comments for hotplug/suspend/hibernate functions
  torture: Use correct path for Kconfig fragment for duplicates
  rcu: Fix typo in PER_RCU_NODE_PERIOD header comment
  kvm: Move srcu_struct fields to end of struct kvm
  srcu: Parallelize callback handling
  srcu: Expedite srcu_schedule_cbs_snp() callback invocation
  rcu: Make non-preemptive schedule be Tasks RCU quiescent state
  Merge branches 'doc.2017.04.12a', 'fixes.2017.04.19a' and 
'srcu.2017.04.21a' into HEAD

pierre Kuo (1):
  doc: Update control-dependencies section of memory-barriers.txt

 Documentation/RCU/00-INDEX |   2 +-
 .../Design/Data-Structures/Data-Structures.html| 233 +++--
 .../RCU/Design/Data-Structures/nxtlist.svg |  34 +-
 .../Expedited-Grace-Periods.html   |  47 +-
 

Re: [PATCH 2/5] soc: fsl: add flextimer module alarm driver for Layerscape

[kbuild test robot]

Hi Wang,

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

url:
https://github.com/0day-ci/linux/commits/ying-zhang22455-nxp-com/soc-fsl-add-support-for-arm64-Layerscape-SOC-specific-drivers/20170421-174921
config: arm64-allmodconfig (attached as .config)
compiler: aarch64-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget 
https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm64 

All warnings (new ones prefixed by >>):

   drivers/soc/fsl/layerscape/ftm_alarm.c: In function 'ftm_clean_alarm':
>> drivers/soc/fsl/layerscape/ftm_alarm.c:139:13: warning: large integer 
>> implicitly truncated to unsigned type [-Woverflow]
 ftm_writel(~0UL, ftm1_base + FTM_MOD);
^

vim +139 drivers/soc/fsl/layerscape/ftm_alarm.c

   123  cycle = 0;
   124  }
   125  
   126  return cycle;
   127  }
   128  
   129  static u32 cycle_to_time(u32 cycle)
   130  {
   131  return cycle / alarm_freq + 1;
   132  }
   133  
   134  static void ftm_clean_alarm(void)
   135  {
   136  ftm_counter_disable(ftm1_base);
   137  
   138  ftm_writel(0x00, ftm1_base + FTM_CNTIN);
 > 139  ftm_writel(~0UL, ftm1_base + FTM_MOD);
   140  
   141  ftm_reset_counter(ftm1_base);
   142  }
   143  
   144  static int ftm_set_alarm(u64 cycle)
   145  {
   146  ftm_irq_disable(ftm1_base);
   147  

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


.config.gz
Description: application/gzip

[PATCH v5 5/6] mtd: dataflash: Make use of "extened device information"

[Andrey Smirnov]

In anticipation of supporting chips that need it, extend the size of
struct flash_info's 'jedec_id' field to make room 2 byte of extended
device information as well as add code to fetch this data during
jedec_probe().

Cc: cphe...@gmail.com
Cc: David Woodhouse 
Cc: Brian Norris 
Cc: Boris Brezillon 
Cc: Marek Vasut 
Cc: Richard Weinberger 
Cc: Cyrille Pitchen 
Cc: linux-kernel@vger.kernel.org
Acked-by: Marek Vasut 
Signed-off-by: Andrey Smirnov 
---

Changes since [v4]:

- Corrected value of SUP_EXTID from BIT(3) to 0x0004

- Collected Acked-by from Marek

Changes since [v3]:

- Convert patch to use SUP_EXTID flag and avoid patching
  dataflash_data table

Changes since [v2]:

- Make 'id' have same size as 'jedec'

- Get rid of eid_mask variable in favour of using GENMASK
  in-place

Changes since [v1]:

- Formatting

[v1] http://lkml.kernel.org/r/20170411161722.11164-1-andrew.smir...@gmail.com
[v2] http://lkml.kernel.org/r/20170418142127.23301-3-andrew.smir...@gmail.com
[v3] http://lkml.kernel.org/r/20170419152305.17226-5-andrew.smir...@gmail.com
[v4] http://lkml.kernel.org/r/20170420162952.5181-5-andrew.smir...@gmail.com

 drivers/mtd/devices/mtd_dataflash.c | 88 -
 1 file changed, 57 insertions(+), 31 deletions(-)

diff --git a/drivers/mtd/devices/mtd_dataflash.c 
b/drivers/mtd/devices/mtd_dataflash.c
index 2d3e403..3f1a0fb 100644
--- a/drivers/mtd/devices/mtd_dataflash.c
+++ b/drivers/mtd/devices/mtd_dataflash.c
@@ -84,6 +84,9 @@
 
 #define CFI_MFR_ATMEL  0x1F
 
+#define DATAFLASH_SHIFT_EXTID  24
+#define DATAFLASH_SHIFT_ID 40
+
 struct dataflash {
u8  command[4];
charname[24];
@@ -687,7 +690,7 @@ struct flash_info {
/* JEDEC id has a high byte of zero plus three data bytes:
 * the manufacturer id, then a two byte device id.
 */
-   u32 jedec_id;
+   u64 jedec_id;
 
/* The size listed here is what works with OP_ERASE_PAGE. */
unsignednr_pages;
@@ -695,6 +698,7 @@ struct flash_info {
u16 pageoffset;
 
u16 flags;
+#define SUP_EXTID  0x0004  /* supports extended ID data */
 #define SUP_POW2PS 0x0002  /* supports 2^N byte pages */
 #define IS_POW2PS  0x0001  /* uses 2^N byte pages */
 };
@@ -734,42 +738,18 @@ static struct flash_info dataflash_data[] = {
{ "at45db642d",  0x1f2800, 8192, 1024, 10, SUP_POW2PS | IS_POW2PS},
 };
 
-static struct flash_info *jedec_probe(struct spi_device *spi)
+static struct flash_info *jedec_lookup(struct spi_device *spi,
+  u64 jedec, bool use_extid)
 {
-   int ret;
-   u8 code = OP_READ_ID;
-   u8 id[3];
-   u32 jedec;
struct flash_info *info;
int status;
 
-   /*
-* JEDEC also defines an optional "extended device information"
-* string for after vendor-specific data, after the three bytes
-* we use here.  Supporting some chips might require using it.
-*
-* If the vendor ID isn't Atmel's (0x1f), assume this call failed.
-* That's not an error; only rev C and newer chips handle it, and
-* only Atmel sells these chips.
-*/
-   ret = spi_write_then_read(spi, , 1, id, 3);
-   if (ret < 0) {
-   dev_dbg(>dev, "error %d reading JEDEC ID\n", ret);
-   return ERR_PTR(ret);
-   }
-
-   if (id[0] != CFI_MFR_ATMEL)
-   return NULL;
-
-   jedec = id[0];
-   jedec = jedec << 8;
-   jedec |= id[1];
-   jedec = jedec << 8;
-   jedec |= id[2];
-
for (info = dataflash_data;
 info < dataflash_data + ARRAY_SIZE(dataflash_data);
 info++) {
+   if (use_extid && !(info->flags & SUP_EXTID))
+   continue;
+
if (info->jedec_id == jedec) {
dev_dbg(>dev, "OTP, sector protect%s\n",
(info->flags & SUP_POW2PS) ?
@@ -793,12 +773,58 @@ static struct flash_info *jedec_probe(struct spi_device 
*spi)
}
}
 
+   return ERR_PTR(-ENODEV);
+}
+
+static struct flash_info *jedec_probe(struct spi_device *spi)
+{
+   int ret;
+   u8 code = OP_READ_ID;
+   u64 jedec;
+   u8 id[sizeof(jedec)] = {0};
+   const unsigned int id_size = 5;
+   struct flash_info *info;
+
+   /*
+* JEDEC also defines an optional "extended device information"
+* string for after vendor-specific data, after the three bytes
+* we use here.  Supporting some chips might require using it.
+*
+* 

[PATCH v1 5/8] vmbus: Use recently introduced uuid_le_cmp_p{p}() helpers

[Andy Shevchenko]

Recently introduced helpers take pointers to uuid_{be|le} instead of
reference.

Using them makes code less ugly.

Cc: "K. Y. Srinivasan" 
Cc: Haiyang Zhang 
Cc: Stephen Hemminger 
Signed-off-by: Andy Shevchenko 
---
 drivers/hv/channel_mgmt.c | 10 +-
 drivers/hv/vmbus_drv.c|  2 +-
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/hv/channel_mgmt.c b/drivers/hv/channel_mgmt.c
index 735f9363f2e4..01570c50ed04 100644
--- a/drivers/hv/channel_mgmt.c
+++ b/drivers/hv/channel_mgmt.c
@@ -176,7 +176,7 @@ static bool is_unsupported_vmbus_devs(const uuid_le *guid)
int i;
 
for (i = 0; i < ARRAY_SIZE(vmbus_unsupported_devs); i++)
-   if (!uuid_le_cmp(*guid, vmbus_unsupported_devs[i].guid))
+   if (!uuid_le_cmp_p(guid, vmbus_unsupported_devs[i].guid))
return true;
return false;
 }
@@ -190,7 +190,7 @@ static u16 hv_get_dev_type(const struct vmbus_channel 
*channel)
return HV_UNKNOWN;
 
for (i = HV_IDE; i < HV_UNKNOWN; i++) {
-   if (!uuid_le_cmp(*guid, vmbus_devs[i].guid))
+   if (!uuid_le_cmp_p(guid, vmbus_devs[i].guid))
return i;
}
pr_info("Unknown GUID: %pUl\n", guid);
@@ -456,9 +456,9 @@ static void vmbus_process_offer(struct vmbus_channel 
*newchannel)
 
list_for_each_entry(channel, _connection.chn_list, listentry) {
if (!uuid_le_cmp(channel->offermsg.offer.if_type,
-   newchannel->offermsg.offer.if_type) &&
-   !uuid_le_cmp(channel->offermsg.offer.if_instance,
-   newchannel->offermsg.offer.if_instance)) {
+newchannel->offermsg.offer.if_type) &&
+   !uuid_le_cmp(channel->offermsg.offer.if_instance,
+newchannel->offermsg.offer.if_instance)) {
fnew = false;
break;
}
diff --git a/drivers/hv/vmbus_drv.c b/drivers/hv/vmbus_drv.c
index 0087b49095eb..b41a2be778f6 100644
--- a/drivers/hv/vmbus_drv.c
+++ b/drivers/hv/vmbus_drv.c
@@ -557,7 +557,7 @@ static const struct hv_vmbus_device_id 
*hv_vmbus_get_id(struct hv_driver *drv,
/* Look at the dynamic ids first, before the static ones */
spin_lock(>dynids.lock);
list_for_each_entry(dynid, >dynids.list, node) {
-   if (!uuid_le_cmp(dynid->id.guid, *guid)) {
+   if (!uuid_le_cmp_p(guid, dynid->id.guid)) {
id = >id;
break;
}
-- 
2.11.0

[PATCH v1 7/8] efi: Use recently introduced uuid_le_cmp_p{p}() helpers

[Andy Shevchenko]

Recently introduced helpers take pointers to uuid_{be|le} instead of
reference.

Using them makes code less ugly.

Cc: Matt Fleming 
Cc: Ard Biesheuvel 
Signed-off-by: Andy Shevchenko 
---
 drivers/firmware/efi/cper.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/firmware/efi/cper.c b/drivers/firmware/efi/cper.c
index d42537425438..7735b0f0ea90 100644
--- a/drivers/firmware/efi/cper.c
+++ b/drivers/firmware/efi/cper.c
@@ -402,14 +402,14 @@ static void cper_estatus_print_section(
printk("%s""fru_text: %.20s\n", pfx, gdata->fru_text);
 
snprintf(newpfx, sizeof(newpfx), "%s%s", pfx, INDENT_SP);
-   if (!uuid_le_cmp(*sec_type, CPER_SEC_PROC_GENERIC)) {
+   if (!uuid_le_cmp_p(sec_type, CPER_SEC_PROC_GENERIC)) {
struct cper_sec_proc_generic *proc_err = (void *)(gdata + 1);
printk("%s""section_type: general processor error\n", newpfx);
if (gdata->error_data_length >= sizeof(*proc_err))
cper_print_proc_generic(newpfx, proc_err);
else
goto err_section_too_small;
-   } else if (!uuid_le_cmp(*sec_type, CPER_SEC_PLATFORM_MEM)) {
+   } else if (!uuid_le_cmp_p(sec_type, CPER_SEC_PLATFORM_MEM)) {
struct cper_sec_mem_err *mem_err = (void *)(gdata + 1);
printk("%s""section_type: memory error\n", newpfx);
if (gdata->error_data_length >=
@@ -418,7 +418,7 @@ static void cper_estatus_print_section(
   gdata->error_data_length);
else
goto err_section_too_small;
-   } else if (!uuid_le_cmp(*sec_type, CPER_SEC_PCIE)) {
+   } else if (!uuid_le_cmp_p(sec_type, CPER_SEC_PCIE)) {
struct cper_sec_pcie *pcie = (void *)(gdata + 1);
printk("%s""section_type: PCIe error\n", newpfx);
if (gdata->error_data_length >= sizeof(*pcie))
-- 
2.11.0

[PATCH v1 1/8] lib/uuid: Introduce uuid_{be|le}_cmp_p{p}() helpers

[Andy Shevchenko]

New helpers take pointers to uuid_{be|le} as parameters.

When using them on a raw data we don't need to do an ugly dereference
and, in some cases, a type casting.

Cc: Andrew Morton 
Cc: Arnd Bergmann 
Cc: Liam Girdwood 
Cc: Mark Brown 
Cc: Vinod Koul 
Cc: Srinivas Pandruvada 
Cc: Benjamin Tissoires 
Cc: Kirti Wankhede 
Cc: Alex Williamson 
Cc: "K. Y. Srinivasan" 
Cc: Haiyang Zhang 
Cc: Stephen Hemminger 
Cc: Tomas Winkler 
Cc: Matt Fleming 
Cc: Ard Biesheuvel 
Cc: "Rafael J. Wysocki" 

Signed-off-by: Andy Shevchenko 
---
 include/linux/uuid.h | 20 
 1 file changed, 20 insertions(+)

diff --git a/include/linux/uuid.h b/include/linux/uuid.h
index 4dff73a89758..45312cb5ac65 100644
--- a/include/linux/uuid.h
+++ b/include/linux/uuid.h
@@ -58,6 +58,26 @@ static inline int uuid_be_cmp(const uuid_be u1, const 
uuid_be u2)
return memcmp(, , sizeof(uuid_be));
 }
 
+static inline int uuid_le_cmp_p(const uuid_le *pu1, const uuid_le u2)
+{
+   return memcmp(pu1, , sizeof(uuid_le));
+}
+
+static inline int uuid_be_cmp_p(const uuid_be *pu1, const uuid_be u2)
+{
+   return memcmp(pu1, , sizeof(uuid_be));
+}
+
+static inline int uuid_le_cmp_pp(const uuid_le *pu1, const uuid_le *pu2)
+{
+   return memcmp(pu1, pu2, sizeof(uuid_le));
+}
+
+static inline int uuid_be_cmp_pp(const uuid_be *pu1, const uuid_be *pu2)
+{
+   return memcmp(pu1, pu2, sizeof(uuid_be));
+}
+
 void generate_random_uuid(unsigned char uuid[16]);
 
 extern void uuid_le_gen(uuid_le *u);
-- 
2.11.0

Re: [PATCH 0/5] v2: block subsystem refcounter conversions

[Peter Zijlstra]

On Fri, Apr 21, 2017 at 08:03:13AM -0600, Jens Axboe wrote:
> You have it so easy - the code is completely standalone, building a
> small test framework around it and measuring performance in _user space_
> is trivial.

Something like this you mean:

  
https://lkml.kernel.org/r/20170322165144.dtidvvbxey7w5...@hirez.programming.kicks-ass.net

Re: [PATCH v5 09/11] mm: mempolicy: mbind and migrate_pages support thp migration

[Zi Yan]

Anshuman Khandual wrote:
> On 04/21/2017 02:17 AM, Zi Yan wrote:
>> From: Naoya Horiguchi 
>>
>> This patch enables thp migration for mbind(2) and migrate_pages(2).
>>
>> Signed-off-by: Naoya Horiguchi 
>> ---
>> ChangeLog v1 -> v2:
>> - support pte-mapped and doubly-mapped thp
>> ---
>>  mm/mempolicy.c | 108 
>> +
>>  1 file changed, 79 insertions(+), 29 deletions(-)
> 
> Snip
> 
>> @@ -981,7 +1012,17 @@ static struct page *new_node_page(struct page *page, 
>> unsigned long node, int **x
>>  if (PageHuge(page))
>>  return alloc_huge_page_node(page_hstate(compound_head(page)),
>>  node);
>> -else
>> +else if (thp_migration_supported() && PageTransHuge(page)) {
>> +struct page *thp;
>> +
>> +thp = alloc_pages_node(node,
>> +(GFP_TRANSHUGE | __GFP_THISNODE) & ~__GFP_RECLAIM,
>> +HPAGE_PMD_ORDER);
>> +if (!thp)
>> +return NULL;
>> +prep_transhuge_page(thp);
>> +return thp;
>> +} else
>>  return __alloc_pages_node(node, GFP_HIGHUSER_MOVABLE |
>>  __GFP_THISNODE, 0);
>>  }
>> @@ -1147,6 +1188,15 @@ static struct page *new_page(struct page *page, 
>> unsigned long start, int **x)
>>  if (PageHuge(page)) {
>>  BUG_ON(!vma);
>>  return alloc_huge_page_noerr(vma, address, 1);
>> +} else if (thp_migration_supported() && PageTransHuge(page)) {
>> +struct page *thp;
>> +
>> +thp = alloc_hugepage_vma(GFP_TRANSHUGE, vma, address,
>> + HPAGE_PMD_ORDER);
>> +if (!thp)
>> +return NULL;
>> +prep_transhuge_page(thp);
>> +return thp;
> 
> GFP flags in both these new page allocation functions should be the same.
> Does alloc_hugepage_vma() will eventually call page allocation with the
> following flags.
> 
> (GFP_TRANSHUGE | __GFP_THISNODE) & ~__GFP_RECLAIM

Sure. This is equivalent to (GFP_TRANSHUGE_LIGHT | __GFP_THISNODE),
which I am going to use.

-- 
Best Regards,
Yan Zi



signature.asc
Description: OpenPGP digital signature

[PATCH 1/9] x86/tsc: Provide tsc=unstable boot parameter

[Peter Zijlstra]

Since the clocksource watchdog will only detect broken TSC after the
fact, all TSC based clocks will likely have observed non-continuous
values before/when switching away from TSC.

Therefore only thing to fully avoid random clock movement when your
BIOS randomly mucks with TSC values from SMI handlers is reporting the
TSC as unstable at boot.

Signed-off-by: Peter Zijlstra (Intel) 
---
 arch/x86/kernel/tsc.c |2 ++
 1 file changed, 2 insertions(+)

--- a/arch/x86/kernel/tsc.c
+++ b/arch/x86/kernel/tsc.c
@@ -374,6 +374,8 @@ static int __init tsc_setup(char *str)
tsc_clocksource_reliable = 1;
if (!strncmp(str, "noirqtime", 9))
no_sched_irq_time = 1;
+   if (!strcmp(str, "unstable"))
+   mark_tsc_unstable("boot parameter");
return 1;
 }
 

Re: [PATCH net-next] net: dsa: Remove redundant NULL dst check

[David Miller]

From: Florian Fainelli 
Date: Thu, 20 Apr 2017 15:47:22 -0700

> tag_lan9303.c does check for a NULL dst but that's already checked by
> dsa_switch_rcv() one layer above.
> 
> Signed-off-by: Florian Fainelli 

Applied, thank you.

Re: [PATCH 1/3] jump_label: Pull get_online_cpus() into generic code

[Peter Zijlstra]

On Fri, Apr 21, 2017 at 12:08:26PM -0400, Jason Baron wrote:
> On 04/18/2017 06:32 AM, Peter Zijlstra wrote:
> > @@ -146,6 +154,7 @@ static void __static_key_slow_dec(struct
> >  * returns is unbalanced, because all other static_key_slow_inc()
> >  * instances block while the update is in progress.
> >  */
> > +   get_online_cpus();
> > if (!atomic_dec_and_mutex_lock(>enabled, _label_mutex)) {
> > WARN(atomic_read(>enabled) < 0,
> >  "jump label: negative count!\n");
> 
> So the get and put can be unbalanced here since the above:
> 
> 'if (!atomic_dec_and_mutex_lock(>enabled, _label_mutex))'
> 
> is followed by 'return;'. However, I see that the next patch removes this
> and so things are balanced again...

Duh.. right you are.

> > @@ -159,6 +168,7 @@ static void __static_key_slow_dec(struct
> > jump_label_update(key);
> > }
> > jump_label_unlock();
> > +   put_online_cpus();
> >  }
> > 
> >  static void jump_label_update_timeout(struct work_struct *work)
> > @@ -592,6 +602,10 @@ jump_label_module_notify(struct notifier
> > 
> > switch (val) {
> > case MODULE_STATE_COMING:
> > +   /*
> > +* XXX do we need get_online_cpus() ?  the module isn't
> > +* executable yet, so nothing should be looking at our code.
> > +*/
> 
> Since we're just updating the table of places we potentially need to patch,
> but not actually doing any patching, we should not need get_online_cpus()
> here...so in attempt to reduce confusion I would remove this.

Thanks for confirming it is indeed not required. Will make it go away.

[PATCH 8/9] sched/clock: Use late_initcall() instead of sched_init_smp()

[Peter Zijlstra]

Core2 marks its TSC unstable in ACPI Processor Idle, which is probed
after sched_init_smp(). Luckily it appears both acpi_processor and
intel_idle (which has a similar check) are mandatory built-in.

This means we can delay switching to stable until after these drivers
have ran (if they were modules, this would be impossible).

Delay the stable switch to late_initcall() to allow these drivers to
mark TSC unstable and avoid difficult stable->unstable transitions.

Cc: "Rafael J . Wysocki" 
Reported-by: "Lofstedt, Marta" 
Signed-off-by: Peter Zijlstra (Intel) 
---
 include/linux/sched/clock.h |5 -
 kernel/sched/clock.c|   10 +-
 kernel/sched/core.c |2 --
 3 files changed, 9 insertions(+), 8 deletions(-)

--- a/include/linux/sched/clock.h
+++ b/include/linux/sched/clock.h
@@ -23,10 +23,6 @@ extern u64 sched_clock_cpu(int cpu);
 extern void sched_clock_init(void);
 
 #ifndef CONFIG_HAVE_UNSTABLE_SCHED_CLOCK
-static inline void sched_clock_init_late(void)
-{
-}
-
 static inline void sched_clock_tick(void)
 {
 }
@@ -53,7 +49,6 @@ static inline u64 local_clock(void)
return sched_clock();
 }
 #else
-extern void sched_clock_init_late(void);
 extern int sched_clock_stable(void);
 extern void clear_sched_clock_stable(void);
 
--- a/kernel/sched/clock.c
+++ b/kernel/sched/clock.c
@@ -64,6 +64,7 @@
 #include 
 #include 
 #include 
+#include 
 
 /*
  * Scheduler clock - returns current time in nanosec units.
@@ -203,7 +204,11 @@ void clear_sched_clock_stable(void)
__clear_sched_clock_stable();
 }
 
-void sched_clock_init_late(void)
+/*
+ * We run this as late_initcall() such that it runs after all built-in drivers,
+ * notably: acpi_processor and intel_idle, which can mark the TSC as unstable.
+ */
+static int __init sched_clock_init_late(void)
 {
sched_clock_running = 2;
/*
@@ -217,7 +222,10 @@ void sched_clock_init_late(void)
 
if (__sched_clock_stable_early)
__set_sched_clock_stable();
+
+   return 0;
 }
+late_initcall(sched_clock_init_late);
 
 /*
  * min, max except they take wrapping into account
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -5962,7 +5962,6 @@ void __init sched_init_smp(void)
init_sched_dl_class();
 
sched_init_smt();
-   sched_clock_init_late();
 
sched_smp_initialized = true;
 }
@@ -5978,7 +5977,6 @@ early_initcall(migration_init);
 void __init sched_init_smp(void)
 {
sched_init_granularity();
-   sched_clock_init_late();
 }
 #endif /* CONFIG_SMP */
 

[PATCH 4/9] x86/tsc,sched/clock,clocksource: Use clocksource watchdog to provide stable sync points

[Peter Zijlstra]

Currently we keep sched_clock_tick() active for stable TSC in order to
keep the per-cpu state semi up-to-date. The (obvious) problem is that
by the time we detect TSC is borked, our per-cpu state is also borked.

So hook into the clocksource watchdog and call a method after we've
found it to still be stable.

There's the obvious race where the TSC goes wonky between finding it
stable and us running the callback, but closing that is too much work
and not really worth it, since we're already detecting TSC wobbles
after the fact, so we cannot, per definition, fully avoid funny clock
values.

And since the watchdog runs less often than the tick, this is also an
optimization.

Signed-off-by: Peter Zijlstra (Intel) 
---
 arch/x86/kernel/tsc.c   |   10 ++
 include/linux/clocksource.h |1 +
 include/linux/sched/clock.h |2 +-
 kernel/sched/clock.c|   36 +++-
 kernel/time/clocksource.c   |3 +++
 5 files changed, 42 insertions(+), 10 deletions(-)

--- a/arch/x86/kernel/tsc.c
+++ b/arch/x86/kernel/tsc.c
@@ -1129,6 +1129,15 @@ static void tsc_cs_mark_unstable(struct
pr_info("Marking TSC unstable due to clocksource watchdog\n");
 }
 
+static void tsc_cs_tick_stable(struct clocksource *cs)
+{
+   if (tsc_unstable)
+   return;
+
+   if (using_native_sched_clock())
+   sched_clock_tick_stable();
+}
+
 /*
  * .mask MUST be CLOCKSOURCE_MASK(64). See comment above read_tsc()
  */
@@ -1142,6 +1151,7 @@ static struct clocksource clocksource_ts
.archdata   = { .vclock_mode = VCLOCK_TSC },
.resume = tsc_resume,
.mark_unstable  = tsc_cs_mark_unstable,
+   .tick_stable= tsc_cs_tick_stable,
 };
 
 void mark_tsc_unstable(char *reason)
--- a/include/linux/clocksource.h
+++ b/include/linux/clocksource.h
@@ -96,6 +96,7 @@ struct clocksource {
void (*suspend)(struct clocksource *cs);
void (*resume)(struct clocksource *cs);
void (*mark_unstable)(struct clocksource *cs);
+   void (*tick_stable)(struct clocksource *cs);
 
/* private: */
 #ifdef CONFIG_CLOCKSOURCE_WATCHDOG
--- a/include/linux/sched/clock.h
+++ b/include/linux/sched/clock.h
@@ -63,8 +63,8 @@ extern void clear_sched_clock_stable(voi
  */
 extern u64 __sched_clock_offset;
 
-
 extern void sched_clock_tick(void);
+extern void sched_clock_tick_stable(void);
 extern void sched_clock_idle_sleep_event(void);
 extern void sched_clock_idle_wakeup_event(u64 delta_ns);
 
--- a/kernel/sched/clock.c
+++ b/kernel/sched/clock.c
@@ -367,20 +367,38 @@ void sched_clock_tick(void)
 {
struct sched_clock_data *scd;
 
+   if (sched_clock_stable())
+   return;
+
+   if (unlikely(!sched_clock_running))
+   return;
+
WARN_ON_ONCE(!irqs_disabled());
 
-   /*
-* Update these values even if sched_clock_stable(), because it can
-* become unstable at any point in time at which point we need some
-* values to fall back on.
-*
-* XXX arguably we can skip this if we expose tsc_clocksource_reliable
-*/
scd = this_scd();
__scd_stamp(scd);
+   sched_clock_local(scd);
+}
 
-   if (!sched_clock_stable() && likely(sched_clock_running))
-   sched_clock_local(scd);
+void sched_clock_tick_stable(void)
+{
+   u64 gtod, clock;
+
+   if (!sched_clock_stable())
+   return;
+
+   /*
+* Called under watchdog_lock.
+*
+* The watchdog just found this TSC to (still) be stable, so now is a
+* good moment to update our __gtod_offset. Because once we find the
+* TSC to be unstable, any computation will be computing crap.
+*/
+   local_irq_disable();
+   gtod = ktime_get_ns();
+   clock = sched_clock();
+   __gtod_offset = (clock + __sched_clock_offset) - gtod;
+   local_irq_enable();
 }
 
 /*
--- a/kernel/time/clocksource.c
+++ b/kernel/time/clocksource.c
@@ -233,6 +233,9 @@ static void clocksource_watchdog(unsigne
continue;
}
 
+   if (cs == curr_clocksource && cs->tick_stable)
+   cs->tick_stable(cs);
+
if (!(cs->flags & CLOCK_SOURCE_VALID_FOR_HRES) &&
(cs->flags & CLOCK_SOURCE_IS_CONTINUOUS) &&
(watchdog->flags & CLOCK_SOURCE_IS_CONTINUOUS)) {

[PATCH 3/9] sched/clock: Initialize all per-cpu state before switching (back) to unstable

[Peter Zijlstra]

In preparation for not keeping the sched_clock_tick() active for
stable TSC, we need to explicitly initialize all per-cpu state
before switching back to unstable.

Note: this patch looses the __gtod_offset calculation; it will be
restored in the next one.

Signed-off-by: Peter Zijlstra (Intel) 
---
 kernel/sched/clock.c |   60 +--
 1 file changed, 39 insertions(+), 21 deletions(-)

--- a/kernel/sched/clock.c
+++ b/kernel/sched/clock.c
@@ -124,6 +124,12 @@ int sched_clock_stable(void)
return static_branch_likely(&__sched_clock_stable);
 }
 
+static void __scd_stamp(struct sched_clock_data *scd)
+{
+   scd->tick_gtod = ktime_get_ns();
+   scd->tick_raw = sched_clock();
+}
+
 static void __set_sched_clock_stable(void)
 {
struct sched_clock_data *scd = this_scd();
@@ -141,8 +147,37 @@ static void __set_sched_clock_stable(voi
tick_dep_clear(TICK_DEP_BIT_CLOCK_UNSTABLE);
 }
 
+/*
+ * If we ever get here, we're screwed, because we found out -- typically after
+ * the fact -- that TSC wasn't good. This means all our clocksources (including
+ * ktime) could have reported wrong values.
+ *
+ * What we do here is an attempt to fix up and continue sort of where we left
+ * off in a coherent manner.
+ *
+ * The only way to fully avoid random clock jumps is to boot with:
+ * "tsc=unstable".
+ */
 static void __sched_clock_work(struct work_struct *work)
 {
+   struct sched_clock_data *scd;
+   int cpu;
+
+   /* take a current timestamp and set 'now' */
+   preempt_disable();
+   scd = this_scd();
+   __scd_stamp(scd);
+   scd->clock = scd->tick_gtod + __gtod_offset;
+   preempt_enable();
+
+   /* clone to all CPUs */
+   for_each_possible_cpu(cpu)
+   per_cpu(sched_clock_data, cpu) = *scd;
+
+   printk(KERN_INFO "sched_clock: Marking unstable (%lld, %lld)<-(%lld, 
%lld)\n",
+   scd->tick_gtod, __gtod_offset,
+   scd->tick_raw,  __sched_clock_offset);
+
static_branch_disable(&__sched_clock_stable);
 }
 
@@ -150,27 +185,11 @@ static DECLARE_WORK(sched_clock_work, __
 
 static void __clear_sched_clock_stable(void)
 {
-   struct sched_clock_data *scd = this_scd();
-
-   /*
-* Attempt to make the stable->unstable transition continuous.
-*
-* Trouble is, this is typically called from the TSC watchdog
-* timer, which is late per definition. This means the tick
-* values can already be screwy.
-*
-* Still do what we can.
-*/
-   __gtod_offset = (scd->tick_raw + __sched_clock_offset) - 
(scd->tick_gtod);
-
-   printk(KERN_INFO "sched_clock: Marking unstable (%lld, %lld)<-(%lld, 
%lld)\n",
-   scd->tick_gtod, __gtod_offset,
-   scd->tick_raw,  __sched_clock_offset);
+   if (!sched_clock_stable())
+   return;
 
tick_dep_set(TICK_DEP_BIT_CLOCK_UNSTABLE);
-
-   if (sched_clock_stable())
-   schedule_work(_clock_work);
+   schedule_work(_clock_work);
 }
 
 void clear_sched_clock_stable(void)
@@ -357,8 +376,7 @@ void sched_clock_tick(void)
 * XXX arguably we can skip this if we expose tsc_clocksource_reliable
 */
scd = this_scd();
-   scd->tick_raw  = sched_clock();
-   scd->tick_gtod = ktime_get_ns();
+   __scd_stamp(scd);
 
if (!sched_clock_stable() && likely(sched_clock_running))
sched_clock_local(scd);

[PATCH 5/9] sched/clock: Remove unused argument to sched_clock_idle_wakeup_event()

[Peter Zijlstra]

The argument to sched_clock_idle_wakeup_event() has not been used in a
long time. Remove it.

Signed-off-by: Peter Zijlstra (Intel) 
---
 arch/x86/kernel/tsc.c   |2 +-
 include/linux/sched/clock.h |4 ++--
 kernel/sched/clock.c|4 ++--
 kernel/time/tick-sched.c|2 +-
 4 files changed, 6 insertions(+), 6 deletions(-)

--- a/arch/x86/kernel/tsc.c
+++ b/arch/x86/kernel/tsc.c
@@ -284,7 +284,7 @@ static void set_cyc2ns_scale(unsigned lo
cyc2ns_write_end(cpu, data);
 
 done:
-   sched_clock_idle_wakeup_event(0);
+   sched_clock_idle_wakeup_event();
local_irq_restore(flags);
 }
 /*
--- a/include/linux/sched/clock.h
+++ b/include/linux/sched/clock.h
@@ -39,7 +39,7 @@ static inline void sched_clock_idle_slee
 {
 }
 
-static inline void sched_clock_idle_wakeup_event(u64 delta_ns)
+static inline void sched_clock_idle_wakeup_event(void)
 {
 }
 
@@ -66,7 +66,7 @@ extern u64 __sched_clock_offset;
 extern void sched_clock_tick(void);
 extern void sched_clock_tick_stable(void);
 extern void sched_clock_idle_sleep_event(void);
-extern void sched_clock_idle_wakeup_event(u64 delta_ns);
+extern void sched_clock_idle_wakeup_event(void);
 
 /*
  * As outlined in clock.c, provides a fast, high resolution, nanosecond
--- a/kernel/sched/clock.c
+++ b/kernel/sched/clock.c
@@ -410,9 +410,9 @@ void sched_clock_idle_sleep_event(void)
 EXPORT_SYMBOL_GPL(sched_clock_idle_sleep_event);
 
 /*
- * We just idled delta nanoseconds (called with irqs disabled):
+ * We just idled; resync with ktime. (called with irqs disabled):
  */
-void sched_clock_idle_wakeup_event(u64 delta_ns)
+void sched_clock_idle_wakeup_event(void)
 {
if (timekeeping_suspended)
return;
--- a/kernel/time/tick-sched.c
+++ b/kernel/time/tick-sched.c
@@ -573,7 +573,7 @@ static void tick_nohz_stop_idle(struct t
update_ts_time_stats(smp_processor_id(), ts, now, NULL);
ts->idle_active = 0;
 
-   sched_clock_idle_wakeup_event(0);
+   sched_clock_idle_wakeup_event();
 }
 
 static ktime_t tick_nohz_start_idle(struct tick_sched *ts)

[PATCH 0/9] sched_clock fixes

[Peter Zijlstra]

Hi,

These patches were inspired (and hopefully fix) two independent bug reports on
Core2 machines.

I never could quite reproduce one, but my Core2 machine no longer switches to
stable sched_clock and therefore no longer tickles the problematic stable ->
unstable transition either.

Before I dug up my Core2 machine, I tried emulating TSC wreckage by poking
random values into the TSC MSR from userspace. Behaviour in that case is
improved as well.

People have to realize that if we manage to boot with TSC 'stable' (both
sched_clock and clocksource) and we later find out we were mistaken (we observe
a TSC wobble) the clocks that are derived from it _will_ have had an observable
hickup. This is fundamentally unfixable.

If you own a machine where the BIOS tries to hide SMI latencies by rewinding
TSC (yes, this is a thing), the very best we can do is mark TSC unstable with a
boot parameter.

For example, this is me writing a stupid value into the TSC:

[   46.745082] random: crng init done
[18443029775.010069] clocksource: timekeeping watchdog on CPU0: Marking 
clocksource 'tsc' as unstable because the skew is too large:
[18443029775.023141] clocksource:   'hpet' wd_now: 3ebec538 
wd_last: 3e486ec9 mask: 
[18443029775.034214] clocksource:   'tsc' cs_now: 5025acce9 
cs_last: 24dc3bd21c88ee mask: 
[18443029775.046651] tsc: Marking TSC unstable due to clocksource watchdog
[18443029775.054211] TSC found unstable after boot, most likely due to broken 
BIOS. Use 'tsc=unstable'.
[18443029775.064434] sched_clock: Marking unstable (70569005835, 
-17833788)<-(-3714295689546517, -2965802361)
[   70.573700] clocksource: Switched to clocksource hpet

With some trace_printk()s (not included) I could tell that the wobble
occured at 69.965474. The clock now resumes where it 'should' have been.

But an unfortunate scheduling event could have resulted in one task
having seen a runtime of ~584 years with 'obvious' effects. Similar
jumps can also be observed from userspace GTOD usage.

[PATCH 9/9] sched/clock: Print a warning recommending tsc=unstable

[Peter Zijlstra]

With our switch to stable delayed until late_initcall(), the most
likely cause of hitting mark_tsc_unstable() is the watchdog. The
watchdog typically only triggers when creative BIOS'es fiddle with the
TSC to hide SMI latency.

Since the watchdog can only detect TSC fiddling after the fact all TSC
clocks (including userspace GTOD) can already have reported funny
values.

The only way to fully avoid this, is manually marking the TSC unstable
at boot. Suggest people do this on their broken systems.

Signed-off-by: Peter Zijlstra (Intel) 
---
 kernel/sched/clock.c |1 +
 1 file changed, 1 insertion(+)

--- a/kernel/sched/clock.c
+++ b/kernel/sched/clock.c
@@ -175,6 +175,7 @@ static void __sched_clock_work(struct wo
for_each_possible_cpu(cpu)
per_cpu(sched_clock_data, cpu) = *scd;
 
+   printk(KERN_WARNING "TSC found unstable after boot, most likely due to 
broken BIOS. Use 'tsc=unstable'.\n");
printk(KERN_INFO "sched_clock: Marking unstable (%lld, %lld)<-(%lld, 
%lld)\n",
scd->tick_gtod, __gtod_offset,
scd->tick_raw,  __sched_clock_offset);

Re: [PATCH] scsi: sas: move scsi_remove_host call into sas_remove_host

[Martin K. Petersen]

Johannes,

> Move scsi_remove_host call into sas_remove_host and remove it from SAS
> HBA drivers, so we don't mess up the ordering. This solves an issue
> with double deleting sysfs entries that was introduced by the change
> of sysfs behaviour from commit bcdde7e ("sysfs: make
> __sysfs_remove_dir() recursive").

Yeah, I prefer this approach.

Applied to 4.12/scsi-queue.

-- 
Martin K. Petersen  Oracle Linux Engineering

Re: [PATCH v2 2/2] dmaengine: Add DW AXI DMAC driver

[Andy Shevchenko]

On Fri, 2017-04-21 at 14:29 +, Eugeniy Paltsev wrote:
> On Tue, 2017-04-18 at 15:31 +0300, Andy Shevchenko wrote:
> > On Fri, 2017-04-07 at 17:04 +0300, Eugeniy Paltsev wrote:
> > > This patch adds support for the DW AXI DMAC controller.
> > > 

> > > +#include 
> > 
> > Are you sure you still need of.h along with depends OF ?
> 
> "of_match_ptr" used from of.h

It safe not to use it and always have a table. In this case the driver
even would be available for ACPI-enabled platforms (I suppose some ARM64
might find this useful).

> > > +#define AXI_DMA_BUSWIDTHS  \
> > > + (DMA_SLAVE_BUSWIDTH_1_BYTE  | \
> > > + DMA_SLAVE_BUSWIDTH_2_BYTES  | \
> > > + DMA_SLAVE_BUSWIDTH_4_BYTES  | \
> > > + DMA_SLAVE_BUSWIDTH_8_BYTES  | \
> > > + DMA_SLAVE_BUSWIDTH_16_BYTES | \
> > > + DMA_SLAVE_BUSWIDTH_32_BYTES | \
> > > + DMA_SLAVE_BUSWIDTH_64_BYTES)
> > > +/* TODO: check: do we need to use BIT() macro here? */
> > 
> > Still TODO? I remember I answered to this on the first round.
> 
> Yes, I remember it.
> I left this TODO as a reminder because src_addr_widths and
> dst_addr_widths are
> not used anywhere and they are set differently in different drivers
> (with or without BIT macro).

Strange. AFAIK they are representing bits (which is not the best idea)
in the resulting u64 field. So, anything bigger than 63 doesn't make
sense. In drivers where they are not bits quite likely a bug is hidden.

> 
> > > +
> > > +static inline void
> > > +axi_dma_iowrite32(struct axi_dma_chip *chip, u32 reg, u32 val)
> > > +{
> > > + iowrite32(val, chip->regs + reg);
> > 
> > Are you going to use IO ports for this IP? I don't think so.
> > Wouldn't be better to call readl()/writel() instead?
> 
> As I understand, it's better to use ioread/iowrite as more universal
> IO
> access way. Am I wrong?

As I said above the ioreadX/iowriteX makes only sense when your IP would
be accessed via IO region or MMIO. I'm pretty sure IO is not the case at
all for this IP.

> > > +static inline void axi_chan_irq_disable(struct axi_dma_chan
> > > *chan,
> > > u32 irq_mask)
> > > +{
> > > + u32 val;
> > > +
> > > + if (likely(irq_mask == DWAXIDMAC_IRQ_ALL)) {
> > > + axi_chan_iowrite32(chan, CH_INTSTATUS_ENA,
> > > DWAXIDMAC_IRQ_NONE);
> > > + } else {
> > 
> > I don't see the benefit. (Yes, I see one read-less path, I think it
> > makes perplexity for nothing here)
> 
> This function is called mostly with irq_mask = DWAXIDMAC_IRQ_ALL.
> Actually it is called only with irq_mask = DWAXIDMAC_IRQ_ALL until I
> add DMA_SLAVE support.
> But I can cut off this 'if' statment, if it is necessery.

It's not necessary, but from my point of view increases readability of
the code a lot for the price of an additional readl().

> 
> > > + val = axi_chan_ioread32(chan, CH_INTSTATUS_ENA);
> > > + val &= ~irq_mask;
> > > + axi_chan_iowrite32(chan, CH_INTSTATUS_ENA, val);
> > > + }

> > > +
> > > + return min_t(size_t, __ffs(sdl), max_width);
> > > +}
> > > +static void axi_desc_put(struct axi_dma_desc *desc)
> > > +{
> > > + struct axi_dma_chan *chan = desc->chan;
> > > + struct dw_axi_dma *dw = chan->chip->dw;
> > > + struct axi_dma_desc *child, *_next;
> > > + unsigned int descs_put = 0;
> > > + list_for_each_entry_safe(child, _next, >xfer_list,
> > > xfer_list) {
> > 
> > xfer_list looks redundant.
> > Can you elaborate why virtual channel management is not working for
> > you?
> 
> Each virtual descriptor encapsulates several hardware descriptors,
> which belong to same transfer.
> This list (xfer_list) is used only for allocating/freeing these
> descriptors and it doesn't affect on virtual dma work logic.
> I can see this approach in several drivers with VirtDMA (but they
> mostly use array instead of list)

You described how most of the DMA drivers are implemented, though they
are using just sg_list directly. I would recommend to do the same and
get rid of this list.

> > Btw, are you planning to use priority at all? For now on I didn't
> > see
> > a single driver (from the set I have checked, like 4-5 of them) that
> > uses priority anyhow. It makes driver more complex for nothing.
> 
> Only for dma slave operations.

So, in other words you *have* an actual two or more users that *need*
prioritization?

> > > + if (unlikely(dst_nents == 0 || src_nents == 0))
> > > + return NULL;
> > > +
> > > + if (unlikely(dst_sg == NULL || src_sg == NULL))
> > > + return NULL;
> > 
> > If we need those checks they should go to dmaengine.h/dmaengine.c.
> 
> I checked several drivers, which implements device_prep_dma_sg and
> they
> implements this checkers.
> Should I add something like "dma_sg_desc_invalid" function to
> dmaengine.h ?

I suppose it's better to implement them in the corresponding helpers in
dmaengine.h.

> > > +static void axi_chan_list_dump_lli(struct axi_dma_chan *chan,
> > > +    struct axi_dma_desc
> > > *desc_head)
> > > +{
> > > + struct 

Re: [PATCH 1/2 v4] video: fbdev: imxfb: support AUS mode

[Bartlomiej Zolnierkiewicz]

On Friday, April 21, 2017 12:29:08 PM Martin Kaiser wrote:
> Some displays require setting AUS mode in the LDCD AUS Mode Control
> Register to work with the imxfb driver. Like the value of the Panel
> Configuration Register, the AUS mode setting depends on the display
> mode.
> 
> Allow setting AUS mode from the device tree by adding a boolean
> property. Make this property optional to keep the DT ABI stable.
> AUS mode can be set only on imx21 and compatible chipsets.
> 
> Signed-off-by: Martin Kaiser 

Patch queued for 4.12, thanks.

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R Institute Poland
Samsung Electronics

[PATCH v1 4/8] vfio-mdev: Use recently introduced uuid_le_cmp_p{p}()

[Andy Shevchenko]

Recently introduced helpers take pointers to uuid_{be|le} instead of
reference.

Using them makes code less ugly.

Cc: Kirti Wankhede 
Cc: Alex Williamson 
Signed-off-by: Andy Shevchenko 
---
 drivers/vfio/mdev/mdev_core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/vfio/mdev/mdev_core.c b/drivers/vfio/mdev/mdev_core.c
index 126991046eb7..82de886855d8 100644
--- a/drivers/vfio/mdev/mdev_core.c
+++ b/drivers/vfio/mdev/mdev_core.c
@@ -75,7 +75,7 @@ static int _find_mdev_device(struct device *dev, void *data)
 
mdev = to_mdev_device(dev);
 
-   if (uuid_le_cmp(mdev->uuid, *(uuid_le *)data) == 0)
+   if (uuid_le_cmp_p(data, mdev->uuid) == 0)
return 1;
 
return 0;
-- 
2.11.0

Re: [patch V2 03/10] timers: Rework idle logic

[Frederic Weisbecker]

On Wed, Apr 19, 2017 at 08:50:39AM +0200, Peter Zijlstra wrote:
> On Tue, Apr 18, 2017 at 01:11:05PM +0200, Thomas Gleixner wrote:
> > Storing next event and determining whether the base is idle can be done in
> > __next_timer_interrupt(). 
> > 
> > Preparatory patch for new call sites which need this information as well.
> > 
> > Signed-off-by: Thomas Gleixner 
> > ---
> >  kernel/time/timer.c |   43 ---
> >  1 file changed, 24 insertions(+), 19 deletions(-)
> > 
> > --- a/kernel/time/timer.c
> > +++ b/kernel/time/timer.c
> > @@ -1358,8 +1358,11 @@ static int next_pending_bucket(struct ti
> >  /*
> >   * Search the first expiring timer in the various clock levels. Caller must
> >   * hold base->lock.
> > + *
> > + * Stores the next expiry time in base. The return value indicates whether
> > + * the base is empty or not.
> >   */
> > -static unsigned long __next_timer_interrupt(struct timer_base *base)
> > +static bool __next_timer_interrupt(struct timer_base *base)
> 
> Can't say I'm a fan of this.. I sort of see where this is going, but the
> fact remains that __next_timer_interrupt(), as a function, makes me
> expect a return value of time/timer quantity.

Maybe we can just do a rename like fetch_next_timer_interrupt() or
update_next_timer_interrupt()?

[PATCH v1 8/8] ACPI: Use recently introduced uuid_le_cmp_p{p}() helpers

[Andy Shevchenko]

Recently introduced helpers take pointers to uuid_{be|le} instead of
reference.

Using them makes code less ugly.

Cc: "Rafael J. Wysocki" 
Signed-off-by: Andy Shevchenko 
---
 drivers/acpi/acpi_extlog.c | 2 +-
 drivers/acpi/apei/ghes.c   | 8 
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/acpi/acpi_extlog.c b/drivers/acpi/acpi_extlog.c
index 502ea4dc2080..45e299aefda7 100644
--- a/drivers/acpi/acpi_extlog.c
+++ b/drivers/acpi/acpi_extlog.c
@@ -169,7 +169,7 @@ static int extlog_print(struct notifier_block *nb, unsigned 
long val,
if (gdata->validation_bits & CPER_SEC_VALID_FRU_TEXT)
fru_text = gdata->fru_text;
sec_type = (uuid_le *)gdata->section_type;
-   if (!uuid_le_cmp(*sec_type, CPER_SEC_PLATFORM_MEM)) {
+   if (!uuid_le_cmp_p(sec_type, CPER_SEC_PLATFORM_MEM)) {
struct cper_sec_mem_err *mem = (void *)(gdata + 1);
if (gdata->error_data_length >= sizeof(*mem))
trace_extlog_mem_event(mem, err_seq, fru_id, fru_text,
diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c
index d0855c09f32f..f2a7ee26d45f 100644
--- a/drivers/acpi/apei/ghes.c
+++ b/drivers/acpi/apei/ghes.c
@@ -431,12 +431,13 @@ static void ghes_do_proc(struct ghes *ghes,
 {
int sev, sec_sev;
struct acpi_hest_generic_data *gdata;
+   uuid_le *sec_type;
 
sev = ghes_severity(estatus->error_severity);
apei_estatus_for_each_section(estatus, gdata) {
+   sec_type = (uuid_le *)gdata->section_type;
sec_sev = ghes_severity(gdata->error_severity);
-   if (!uuid_le_cmp(*(uuid_le *)gdata->section_type,
-CPER_SEC_PLATFORM_MEM)) {
+   if (!uuid_le_cmp_p(sec_type, CPER_SEC_PLATFORM_MEM)) {
struct cper_sec_mem_err *mem_err;
mem_err = (struct cper_sec_mem_err *)(gdata+1);
ghes_edac_report_mem_error(ghes, sev, mem_err);
@@ -445,8 +446,7 @@ static void ghes_do_proc(struct ghes *ghes,
ghes_handle_memory_failure(gdata, sev);
}
 #ifdef CONFIG_ACPI_APEI_PCIEAER
-   else if (!uuid_le_cmp(*(uuid_le *)gdata->section_type,
- CPER_SEC_PCIE)) {
+   else if (!uuid_le_cmp_p(sec_type, CPER_SEC_PCIE)) {
struct cper_sec_pcie *pcie_err;
pcie_err = (struct cper_sec_pcie *)(gdata+1);
if (sev == GHES_SEV_RECOVERABLE &&
-- 
2.11.0

Re: [PATCH v5 06/11] mm: thp: check pmd migration entry in common path

[Zi Yan]

Anshuman Khandual wrote:
> On 04/21/2017 02:17 AM, Zi Yan wrote:
>> From: Zi Yan 
>>
>> If one of callers of page migration starts to handle thp,
>> memory management code start to see pmd migration entry, so we need
>> to prepare for it before enabling. This patch changes various code
>> point which checks the status of given pmds in order to prevent race
>> between thp migration and the pmd-related works.
>>
>> ChangeLog v1 -> v2:
>> - introduce pmd_related() (I know the naming is not good, but can't
>>   think up no better name. Any suggesntion is welcomed.)
>>
>> Signed-off-by: Naoya Horiguchi 
>>
>> ChangeLog v2 -> v3:
>> - add is_swap_pmd()
>> - a pmd entry should be pmd pointing to pte pages, is_swap_pmd(),
>>   pmd_trans_huge(), pmd_devmap(), or pmd_none()
>> - pmd_none_or_trans_huge_or_clear_bad() and pmd_trans_unstable() return
>>   true on pmd_migration_entry, so that migration entries are not
>>   treated as pmd page table entries.
>>
>> ChangeLog v4 -> v5:
>> - add explanation in pmd_none_or_trans_huge_or_clear_bad() to state
>>   the equivalence of !pmd_present() and is_pmd_migration_entry()
>> - fix migration entry wait deadlock code (from v1) in follow_page_mask()
>> - remove unnecessary code (from v1) in follow_trans_huge_pmd()
>> - use is_swap_pmd() instead of !pmd_present() for pmd migration entry,
>>   so it will not be confused with pmd_none()
>> - change author information
>>
>> Signed-off-by: Zi Yan 
>> ---
>>  arch/x86/mm/gup.c |  7 +++--
>>  fs/proc/task_mmu.c| 30 +
>>  include/asm-generic/pgtable.h | 17 +++-
>>  include/linux/huge_mm.h   | 14 --
>>  mm/gup.c  | 22 ++--
>>  mm/huge_memory.c  | 61 
>> ++-
>>  mm/memcontrol.c   |  5 
>>  mm/memory.c   | 12 +++--
>>  mm/mprotect.c |  4 +--
>>  mm/mremap.c   |  2 +-
>>  10 files changed, 145 insertions(+), 29 deletions(-)
>>
>> diff --git a/arch/x86/mm/gup.c b/arch/x86/mm/gup.c
>> index 456dfdfd2249..096bbcc801e6 100644
>> --- a/arch/x86/mm/gup.c
>> +++ b/arch/x86/mm/gup.c
>> @@ -9,6 +9,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>  #include 
>>  
>>  #include 
>> @@ -243,9 +244,11 @@ static int gup_pmd_range(pud_t pud, unsigned long addr, 
>> unsigned long end,
>>  pmd_t pmd = *pmdp;
>>  
>>  next = pmd_addr_end(addr, end);
>> -if (pmd_none(pmd))
>> +if (!pmd_present(pmd)) {
>> +VM_BUG_ON(is_swap_pmd(pmd) && 
>> IS_ENABLED(CONFIG_MIGRATION) &&
>> +  !is_pmd_migration_entry(pmd));
>>  return 0;
>> -if (unlikely(pmd_large(pmd) || !pmd_present(pmd))) {
>> +} else if (unlikely(pmd_large(pmd))) {
>>  /*
>>   * NUMA hinting faults need to be handled in the GUP
>>   * slowpath for accounting purposes and so that they
>> diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c
>> index 5c8359704601..57489dcd71c4 100644
>> --- a/fs/proc/task_mmu.c
>> +++ b/fs/proc/task_mmu.c
>> @@ -600,7 +600,8 @@ static int smaps_pte_range(pmd_t *pmd, unsigned long 
>> addr, unsigned long end,
>>  
>>  ptl = pmd_trans_huge_lock(pmd, vma);
>>  if (ptl) {
>> -smaps_pmd_entry(pmd, addr, walk);
>> +if (pmd_present(*pmd))
>> +smaps_pmd_entry(pmd, addr, walk);
>>  spin_unlock(ptl);
>>  return 0;
>>  }
>> @@ -942,6 +943,9 @@ static int clear_refs_pte_range(pmd_t *pmd, unsigned 
>> long addr,
>>  goto out;
>>  }
>>  
>> +if (!pmd_present(*pmd))
>> +goto out;
>> +
> 
> These pmd_present() checks should have been done irrespective of the
> presence of new PMD migration entries. Please separate them out in a
> different clean up patch.

Not really. The introduction of PMD migration entries makes
pmd_trans_huge_lock() return a lock when PMD is a swap entry (See
changes on pmd_trans_huge_lock() in this patch). This was not the case
before, where pmd_trans_huge_lock() returned NULL if PMD entry was
pmd_none() and both two chunks were not reachable.

Maybe I should use is_swap_pmd() to clarify the confusion.



>> diff --git a/mm/huge_memory.c b/mm/huge_memory.c
>> index 7406d88445bf..3479e9caf2fa 100644
>> --- a/mm/huge_memory.c
>> +++ b/mm/huge_memory.c
>> @@ -912,6 +912,22 @@ int copy_huge_pmd(struct mm_struct *dst_mm, struct 
>> mm_struct *src_mm,
>>  
>>  ret = -EAGAIN;
>>  pmd = *src_pmd;
>> +
>> +if (unlikely(is_swap_pmd(pmd))) {
>> +swp_entry_t entry = pmd_to_swp_entry(pmd);
>> +
>> +VM_BUG_ON(IS_ENABLED(CONFIG_MIGRATION) &&
>> +  

Re: [PATCH] drm: fourcc byteorder: brings header file comments in line with reality.

[Ilia Mirkin]

On Fri, Apr 21, 2017 at 3:58 AM, Gerd Hoffmann  wrote:
> While working on graphics support for virtual machines on ppc64 (which
> exists in both little and big endian variants) I've figured the comments
> for various drm fourcc formats in the header file don't match reality.
>
> Comments says the RGB formats are little endian, but in practice they
> are native endian.  Look at the drm_mode_legacy_fb_format() helper.  It
> maps -- for example -- bpp/depth 32/24 to DRM_FORMAT_XRGB, no matter
> whenever the machine is little endian or big endian.  The users of this
> function (fbdev emulation, DRM_IOCTL_MODE_ADDFB) expect the framebuffer
> is native endian, not little endian.  Most userspace also operates on
> native endian only.
>
> So, go update the comments for all 16+24+32 bpp RGB formats.
>
> Leaving the yuv formats as-is.  I have no idea if and how those are used
> on bigendian machines.

I think this is premature. The current situation is that I can't get
modetest to work *at all* on my NV34 / BE setup (I mean, it runs, just
the colors displayed are wrong). I believe that currently it packs
things in "cpu native endian". I've tried futzing with that without
much success, although I didn't spend too much time on it. I have a
NV34 plugged into my LE setup as well although I haven't tested to
double-check that it all works there. However I'm quite sure it used
to, as I used modetest to help develop the YUV overlay support for
those GPUs.

Does modetest work for you, under any interpretation of the formats?

There's an additional complication wrt looking at what fbcon does,
since it will feed the data in via special accel interfaces in fbdev,
which at least on nouveau, may end up byteswapping the data on upload
to VRAM (I'm not 100% clear on whether they do or not). However
modetest, which is creating its own fb, likely won't get such
treatment.

This is a shitty situation - we have hardware we don't know how it
works, tools we don't know whether they're broken, and comments we're
pretty sure are at least somewhat wrong. Furthermore the hardware is
relatively rare and developers with time to work on improving it are
even rarer.

I'd like to reiterate that the status quo does end up in a functioning
system. Let's try not to break that.

Cheers,

  -ilia

>
> Cc: Ville Syrjälä 
> Cc: Daniel Vetter 
> Cc: Pekka Paalanen 
> Cc: Ilia Mirkin 
> Cc: Michel Dänzer 
> Cc: Alex Deucher 
> Cc: amd-...@lists.freedesktop.org
> Signed-off-by: Gerd Hoffmann 
> ---
>  include/uapi/drm/drm_fourcc.h | 82 
> +--
>  1 file changed, 41 insertions(+), 41 deletions(-)
>
> diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
> index 995c8f9..1579765 100644
> --- a/include/uapi/drm/drm_fourcc.h
> +++ b/include/uapi/drm/drm_fourcc.h
> @@ -42,68 +42,68 @@ extern "C" {
>  #define DRM_FORMAT_R8  fourcc_code('R', '8', ' ', ' ') /* [7:0] R */
>
>  /* 16 bpp Red */
> -#define DRM_FORMAT_R16 fourcc_code('R', '1', '6', ' ') /* [15:0] R 
> little endian */
> +#define DRM_FORMAT_R16 fourcc_code('R', '1', '6', ' ') /* [15:0] R 
> native endian */
>
>  /* 16 bpp RG */
> -#define DRM_FORMAT_RG88fourcc_code('R', 'G', '8', '8') /* 
> [15:0] R:G 8:8 little endian */
> -#define DRM_FORMAT_GR88fourcc_code('G', 'R', '8', '8') /* 
> [15:0] G:R 8:8 little endian */
> +#define DRM_FORMAT_RG88fourcc_code('R', 'G', '8', '8') /* 
> [15:0] R:G 8:8 native endian */
> +#define DRM_FORMAT_GR88fourcc_code('G', 'R', '8', '8') /* 
> [15:0] G:R 8:8 native endian */
>
>  /* 32 bpp RG */
> -#define DRM_FORMAT_RG1616  fourcc_code('R', 'G', '3', '2') /* [31:0] R:G 
> 16:16 little endian */
> -#define DRM_FORMAT_GR1616  fourcc_code('G', 'R', '3', '2') /* [31:0] G:R 
> 16:16 little endian */
> +#define DRM_FORMAT_RG1616  fourcc_code('R', 'G', '3', '2') /* [31:0] R:G 
> 16:16 native endian */
> +#define DRM_FORMAT_GR1616  fourcc_code('G', 'R', '3', '2') /* [31:0] G:R 
> 16:16 native endian */
>
>  /* 8 bpp RGB */
>  #define DRM_FORMAT_RGB332  fourcc_code('R', 'G', 'B', '8') /* [7:0] 
> R:G:B 3:3:2 */
>  #define DRM_FORMAT_BGR233  fourcc_code('B', 'G', 'R', '8') /* [7:0] 
> B:G:R 2:3:3 */
>
>  /* 16 bpp RGB */
> -#define DRM_FORMAT_XRGBfourcc_code('X', 'R', '1', '2') /* [15:0] 
> x:R:G:B 4:4:4:4 little endian */
> -#define DRM_FORMAT_XBGRfourcc_code('X', 'B', '1', '2') /* [15:0] 
> x:B:G:R 4:4:4:4 little endian */
> -#define DRM_FORMAT_RGBXfourcc_code('R', 'X', '1', '2') /* [15:0] 
> R:G:B:x 4:4:4:4 little endian */
> -#define DRM_FORMAT_BGRXfourcc_code('B', 'X', '1', '2') /* [15:0] 
> B:G:R:x 4:4:4:4 little endian */
> +#define DRM_FORMAT_XRGBfourcc_code('X', 'R', '1', '2') /* 

Re: [PATCH] drm: fourcc byteorder: brings header file comments in line with reality.

[Harry Wentland]

Thanks, Christian for adding me.

On 2017-04-21 09:27 AM, Christian König wrote:

Adding Harry to this mail thread as well, cause is one of the people
really affected by this.

Christian.

Am 21.04.2017 um 15:21 schrieb Christian König:

Am 21.04.2017 um 15:12 schrieb Gerd Hoffmann:

   Hi,


"native" to me feels more like "native to the GPU" since these things
really are tied to the GPU not the CPU. That's also why I went with
the
explicit endianness originally so that the driver could properly
declare
what the GPU supports.

And to be honest I would really prefer to stick with that approach for
exactly that reason.



I strongly agree with Christian and Ville on this. I understand fourcc 
endianness as GPU endianness. Usermode needs to be clear on the 
framebuffer format, whether it's GPU or CPU rendered, so kernel should 
define this clearly.


In practice it probably doesn't currently make much difference for AMD 
GPUs. I've never heard of anyone using them on big-endian systems.


Harry



The proposed change would require that drivers have different code path
for different CPU byte order. Those code path tend to be not tested
very
well and are additional complexity we probably don't want inside the
driver.

We can add fixed-endian #defines without too much effort, at least for
the 8 bits per color formats.  In qemu we have the same problem, only
with pixman.  Those formats are native endian too, but often we have to
handle a fixed format, so we did this:

/*
  * pixman image formats are defined to be native endian,
  * that means host byte order on qemu.  So we go define
  * fixed formats here for cases where it is needed, like
  * feeding libjpeg / libpng and writing screenshots.
  */

#ifdef HOST_WORDS_BIGENDIAN
# define PIXMAN_BE_r8g8b8 PIXMAN_r8g8b8
# define PIXMAN_BE_x8r8g8b8   PIXMAN_x8r8g8b8
# define PIXMAN_BE_a8r8g8b8   PIXMAN_a8r8g8b8
# define PIXMAN_BE_b8g8r8x8   PIXMAN_b8g8r8x8
# define PIXMAN_BE_b8g8r8a8   PIXMAN_b8g8r8a8
# define PIXMAN_BE_r8g8b8x8   PIXMAN_r8g8b8x8
# define PIXMAN_BE_r8g8b8a8   PIXMAN_r8g8b8a8
# define PIXMAN_BE_x8b8g8r8   PIXMAN_x8b8g8r8
# define PIXMAN_BE_a8b8g8r8   PIXMAN_a8b8g8r8
# define PIXMAN_LE_x8r8g8b8   PIXMAN_b8g8r8x8
#else
# define PIXMAN_BE_r8g8b8 PIXMAN_b8g8r8
# define PIXMAN_BE_x8r8g8b8   PIXMAN_b8g8r8x8
# define PIXMAN_BE_a8r8g8b8   PIXMAN_b8g8r8a8
# define PIXMAN_BE_b8g8r8x8   PIXMAN_x8r8g8b8
# define PIXMAN_BE_b8g8r8a8   PIXMAN_a8r8g8b8
# define PIXMAN_BE_r8g8b8x8   PIXMAN_x8b8g8r8
# define PIXMAN_BE_r8g8b8a8   PIXMAN_a8b8g8r8
# define PIXMAN_BE_x8b8g8r8   PIXMAN_r8g8b8x8
# define PIXMAN_BE_a8b8g8r8   PIXMAN_r8g8b8a8
# define PIXMAN_LE_x8r8g8b8   PIXMAN_x8r8g8b8
#endif


Exactly what Mesa did as well.


My personal opinion is that formats in drm_fourcc.h should be
independent of the CPU byte order and the function
drm_mode_legacy_fb_format() and drivers depending on that incorrect
assumption be fixed instead.

The problem is this isn't a kernel-internal thing any more. With the
addition of the ADDFB2 ioctl the fourcc codes became part of the
kernel/userspace abi ...


I know and that's exactly the reason I'm going to object those changes.

The kernel/userspace abi is fixed and changing it like this could
potentially break drivers I'm the co-maintainer of. So that whole
approach is a clear NAK from my side.

If you find a driver or userspace which doesn't use the formats as
defined in the comments of drm_fourcc.h the fix the driver instead of
trying to adjust the common header to broken behavior. Cause the later
will clearly cause problems with drivers who correctly implemented the
interface.

Regards,
Christian.



cheers,
   Gerd

___
dri-devel mailing list
dri-de...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel



___
amd-gfx mailing list
amd-...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH] bus: fsl-mc: dpio: fix alter FQ state command

[Dan Carpenter]

On Fri, Apr 21, 2017 at 01:50:24PM +, Horia Geantă wrote:
> Let me know whether keeping code similar would be preferred or not.
> 

Keeping the code similar to the surrounding is never a valid argument
but especially not in staging/.  If only 1 line is nice in the whole
file, at least that's better than nothing.

regards,
dan carpenter

Re: [PATCH 01/11] blk: remove bio_set arg from blk_queue_split()

[Ming Lei]

On Thu, Apr 20, 2017 at 1:38 PM, NeilBrown  wrote:
> blk_queue_split() is always called with the last arg being q->bio_split,
> where 'q' is the first arg.
>
> Also blk_queue_split() sometimes uses the passed-in 'bs' and sometimes uses
> q->bio_split.
>
> This is inconsistent and unnecessary.  Remove the last arg and always use
> q->bio_split inside blk_queue_split()
>
> Signed-off-by: NeilBrown 

Reviewed-by: Ming Lei 

Thanks,

Re: [PATCH v2] dmaengine: sun4i: fix invalid argument

[Maxime Ripard]

On Fri, Apr 21, 2017 at 10:43:20AM +0200, Mason wrote:
> From: Marc Gonzalez 
> 
> The "pchans_used" field is an unsigned long array.
> 
> for_each_clear_bit_from() expects an unsigned long pointer,
> not an array address.
> 
> $ make C=2 drivers/dma/sun4i-dma.o
>   CHECK   drivers/dma/sun4i-dma.c
> drivers/dma/sun4i-dma.c:241:9: warning: incorrect type in argument 1 
> (different base types)
> drivers/dma/sun4i-dma.c:241:9:expected unsigned long const *p
> drivers/dma/sun4i-dma.c:241:9:got unsigned long ( * )[1]
> 
> Signed-off-by: Marc Gonzalez 

Acked-by: Maxime Ripard 

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


signature.asc
Description: PGP signature

Re: [PATCH 10/11] block: remove bio_clone() and all references.

[Ming Lei]

On Thu, Apr 20, 2017 at 1:38 PM, NeilBrown  wrote:
> bio_clone() is no longer used.
> Only bio_clone_bioset() or bio_clone_fast().
> This is for the best, as bio_clone() used fs_bio_set,
> and filesystems are unlikely to want to use bio_clone().
>
> So remove bio_clone() and all references.
> This includes a fix to some incorrect documentation.
>
> Signed-off-by: NeilBrown 

Reviewed-by: Ming Lei 

Thanks,
Ming Lei

Re: [PATCH v5 08/11] mm: hwpoison: soft offline supports thp migration

[Zi Yan]

Anshuman Khandual wrote:
> On 04/21/2017 02:17 AM, Zi Yan wrote:
>> From: Naoya Horiguchi 
>>
>> This patch enables thp migration for soft offline.
>>
>> Signed-off-by: Naoya Horiguchi 
>>
>> ChangeLog: v1 -> v5:
>> - fix page isolation counting error
>>
>> Signed-off-by: Zi Yan 
>> ---
>>  mm/memory-failure.c | 35 ++-
>>  1 file changed, 14 insertions(+), 21 deletions(-)
>>
>> diff --git a/mm/memory-failure.c b/mm/memory-failure.c
>> index 9b77476ef31f..23ff02eb3ed4 100644
>> --- a/mm/memory-failure.c
>> +++ b/mm/memory-failure.c
>> @@ -1481,7 +1481,17 @@ static struct page *new_page(struct page *p, unsigned 
>> long private, int **x)
>>  if (PageHuge(p))
>>  return alloc_huge_page_node(page_hstate(compound_head(p)),
>> nid);
>> -else
>> +else if (thp_migration_supported() && PageTransHuge(p)) {
>> +struct page *thp;
>> +
>> +thp = alloc_pages_node(nid,
>> +(GFP_TRANSHUGE | __GFP_THISNODE) & ~__GFP_RECLAIM,
> 
> Why not __GFP_RECLAIM ? Its soft offline path we wait a bit before
> declaring that THP page cannot be allocated and hence should invoke
> reclaim methods as well.

I am not sure how much effort the kernel wants to put here to soft
offline a THP. Naoya knows more here.


> 
>> +HPAGE_PMD_ORDER);
>> +if (!thp)
>> +return NULL;
>> +prep_transhuge_page(thp);
>> +return thp;
>> +} else
>>  return __alloc_pages_node(nid, GFP_HIGHUSER_MOVABLE, 0);
>>  }
>>  
>> @@ -1665,8 +1675,8 @@ static int __soft_offline_page(struct page *page, int 
>> flags)
>>   * cannot have PAGE_MAPPING_MOVABLE.
>>   */
>>  if (!__PageMovable(page))
>> -inc_node_page_state(page, NR_ISOLATED_ANON +
>> -page_is_file_cache(page));
>> +mod_node_page_state(page_pgdat(page), NR_ISOLATED_ANON +
>> +page_is_file_cache(page), 
>> hpage_nr_pages(page));
>>  list_add(>lru, );
>>  ret = migrate_pages(, new_page, NULL, MPOL_MF_MOVE_ALL,
>>  MIGRATE_SYNC, MR_MEMORY_FAILURE);
>> @@ -1689,28 +1699,11 @@ static int __soft_offline_page(struct page *page, 
>> int flags)
>>  static int soft_offline_in_use_page(struct page *page, int flags)
>>  {
>>  int ret;
>> -struct page *hpage = compound_head(page);
>> -
>> -if (!PageHuge(page) && PageTransHuge(hpage)) {
>> -lock_page(hpage);
>> -if (!PageAnon(hpage) || unlikely(split_huge_page(hpage))) {
>> -unlock_page(hpage);
>> -if (!PageAnon(hpage))
>> -pr_info("soft offline: %#lx: non anonymous 
>> thp\n", page_to_pfn(page));
>> -else
>> -pr_info("soft offline: %#lx: thp split 
>> failed\n", page_to_pfn(page));
>> -put_hwpoison_page(hpage);
>> -return -EBUSY;
>> -}
>> -unlock_page(hpage);
>> -get_hwpoison_page(page);
>> -put_hwpoison_page(hpage);
>> -}
>>  
>>  if (PageHuge(page))
>>  ret = soft_offline_huge_page(page, flags);
>>  else
>> -ret = __soft_offline_page(page, flags);
>> +ret = __soft_offline_page(compound_head(page), flags);
> 
> Hmm, what if the THP allocation fails in the new_page() path and
> we fallback for general page allocation. In that case we will
> always be still calling with the head page ? Because we dont
> split the huge page any more.

This could be a problem if the user wants to offline a TailPage but due
to THP allocation failure, the HeadPage is offlined.

It may be better to only soft offline THPs if page ==
compound_head(page). If page != compound_head(page), we still split THPs
like before.

Because in migrate_pages(), we cannot guarantee any TailPages in that
THP are migrated (1. THP allocation failure causes THP splitting, then
only HeadPage is going to be migrated; 2. even if we change existing
migrate_pages() implementation to add all TailPages to migration list
instead of LRU list, we still cannot guarantee the TailPage we want to
migrate is migrated.).

Naoya, what do you think?

-- 
Best Regards,
Yan Zi



signature.asc
Description: OpenPGP digital signature

RE: [PATCH v3 4/7] powerpc: kprobes: use safer string functions in kprobe_lookup_name()

[David Laight]

From: Naveen N. Rao
> Sent: 19 April 2017 13:51
...
>   dot_name[0] = '\0';
> - strncat(dot_name, name, sizeof(dot_name) - 1);
> + strlcat(dot_name, name, sizeof(dot_name));
...

Is that really zeroing the first byte just so it can append to it?

David

[PATCH v5 1/6] mtd: dataflash: Replace C99 types with their kernel counterparts

[Andrey Smirnov]

No functional change intended.

Cc: cphe...@gmail.com
Cc: David Woodhouse 
Cc: Brian Norris 
Cc: Boris Brezillon 
Cc: Marek Vasut 
Cc: Richard Weinberger 
Cc: Cyrille Pitchen 
Cc: linux-kernel@vger.kernel.org
Acked-by: Marek Vasut 
Signed-off-by: Andrey Smirnov 
---

No changes since [v3], [v4]

Changes since [v2]:

- Re-worded commit message

- Collected Acked-by from Marek

Not present in v1

[v2]: http://lkml.kernel.org/r/20170418142127.23301-1-andrew.smir...@gmail.com
[v3]: http://lkml.kernel.org/r/20170419152305.17226-1-andrew.smir...@gmail.com
[v4]: http://lkml.kernel.org/r/20170420162952.5181-1-andrew.smir...@gmail.com

 drivers/mtd/devices/mtd_dataflash.c | 40 ++---
 1 file changed, 20 insertions(+), 20 deletions(-)

diff --git a/drivers/mtd/devices/mtd_dataflash.c 
b/drivers/mtd/devices/mtd_dataflash.c
index f9e9bd1..a566231 100644
--- a/drivers/mtd/devices/mtd_dataflash.c
+++ b/drivers/mtd/devices/mtd_dataflash.c
@@ -84,7 +84,7 @@
 
 
 struct dataflash {
-   uint8_t command[4];
+   u8  command[4];
charname[24];
 
unsigned short  page_offset;/* offset in flash address */
@@ -153,8 +153,8 @@ static int dataflash_erase(struct mtd_info *mtd, struct 
erase_info *instr)
struct spi_transfer x = { };
struct spi_message  msg;
unsignedblocksize = priv->page_size << 3;
-   uint8_t *command;
-   uint32_trem;
+   u8  *command;
+   u32 rem;
 
pr_debug("%s: erase addr=0x%llx len 0x%llx\n",
  dev_name(>dev), (long long)instr->addr,
@@ -187,8 +187,8 @@ static int dataflash_erase(struct mtd_info *mtd, struct 
erase_info *instr)
pageaddr = pageaddr << priv->page_offset;
 
command[0] = do_block ? OP_ERASE_BLOCK : OP_ERASE_PAGE;
-   command[1] = (uint8_t)(pageaddr >> 16);
-   command[2] = (uint8_t)(pageaddr >> 8);
+   command[1] = (u8)(pageaddr >> 16);
+   command[2] = (u8)(pageaddr >> 8);
command[3] = 0;
 
pr_debug("ERASE %s: (%x) %x %x %x [%i]\n",
@@ -239,7 +239,7 @@ static int dataflash_read(struct mtd_info *mtd, loff_t 
from, size_t len,
struct spi_transfer x[2] = { };
struct spi_message  msg;
unsigned intaddr;
-   uint8_t *command;
+   u8  *command;
int status;
 
pr_debug("%s: read 0x%x..0x%x\n", dev_name(>spi->dev),
@@ -271,9 +271,9 @@ static int dataflash_read(struct mtd_info *mtd, loff_t 
from, size_t len,
 * fewer "don't care" bytes.  Both buffers stay unchanged.
 */
command[0] = OP_READ_CONTINUOUS;
-   command[1] = (uint8_t)(addr >> 16);
-   command[2] = (uint8_t)(addr >> 8);
-   command[3] = (uint8_t)(addr >> 0);
+   command[1] = (u8)(addr >> 16);
+   command[2] = (u8)(addr >> 8);
+   command[3] = (u8)(addr >> 0);
/* plus 4 "don't care" bytes */
 
status = spi_sync(priv->spi, );
@@ -308,7 +308,7 @@ static int dataflash_write(struct mtd_info *mtd, loff_t to, 
size_t len,
size_t  remaining = len;
u_char  *writebuf = (u_char *) buf;
int status = -EINVAL;
-   uint8_t *command;
+   u8  *command;
 
pr_debug("%s: write 0x%x..0x%x\n",
dev_name(>dev), (unsigned)to, (unsigned)(to + len));
@@ -455,11 +455,11 @@ static int dataflash_get_otp_info(struct mtd_info *mtd, 
size_t len,
 }
 
 static ssize_t otp_read(struct spi_device *spi, unsigned base,
-   uint8_t *buf, loff_t off, size_t len)
+   u8 *buf, loff_t off, size_t len)
 {
struct spi_message  m;
size_t  l;
-   uint8_t *scratch;
+   u8  *scratch;
struct spi_transfer t;
int status;
 
@@ -538,7 +538,7 @@ static int dataflash_write_user_otp(struct mtd_info *mtd,
 {
struct spi_message  m;
const size_tl = 4 + 64;
-   uint8_t *scratch;
+   u8  *scratch;
struct spi_transfer t;
struct dataflash*priv = mtd->priv;
int status;
@@ -689,14 +689,14 @@ struct flash_info {
/* JEDEC id has a high byte of zero plus three data bytes:
 * the manufacturer id, then a two byte device id.
 */
-   uint32_tjedec_id;
+   u32 jedec_id;
 

Re: [tip:irq/urgent] genirq/affinity: Fix calculating vectors to assign

[Andrei Vagin]

Looks like 4.11 will be release in a few days, it would be nice if this
commit reaches the upstream tree before this moment.

Thanks.

On Thu, Apr 20, 2017 at 07:06:49AM -0700, tip-bot for Keith Busch wrote:
> Commit-ID:  b72f8051f34b8164a62391e3676edc34523c5952
> Gitweb: http://git.kernel.org/tip/b72f8051f34b8164a62391e3676edc34523c5952
> Author: Keith Busch 
> AuthorDate: Wed, 19 Apr 2017 19:51:10 -0400
> Committer:  Thomas Gleixner 
> CommitDate: Thu, 20 Apr 2017 16:03:09 +0200
> 
> genirq/affinity: Fix calculating vectors to assign
> 
> The vectors_per_node is calculated from the remaining available vectors.
> The current vector starts after pre_vectors, so we need to subtract that
> from the current to properly account for the number of remaining vectors
> to assign.
> 
> Fixes: 3412386b531 ("irq/affinity: Fix extra vecs calculation")
> Reported-by: Andrei Vagin 
> Signed-off-by: Keith Busch 
> Link: 
> http://lkml.kernel.org/r/1492645870-13019-1-git-send-email-keith.bu...@intel.com
> Signed-off-by: Thomas Gleixner 
> 
> ---
>  kernel/irq/affinity.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/kernel/irq/affinity.c b/kernel/irq/affinity.c
> index d052947..e2d356d 100644
> --- a/kernel/irq/affinity.c
> +++ b/kernel/irq/affinity.c
> @@ -98,7 +98,7 @@ irq_create_affinity_masks(int nvecs, const struct 
> irq_affinity *affd)
>   int ncpus, v, vecs_to_assign, vecs_per_node;
>  
>   /* Spread the vectors per node */
> - vecs_per_node = (affv - curvec) / nodes;
> + vecs_per_node = (affv - (curvec - affd->pre_vectors)) / nodes;
>  
>   /* Get the cpus on this node which are in the mask */
>   cpumask_and(nmsk, cpu_online_mask, cpumask_of_node(n));

Re: [PATCH] drm: fourcc byteorder: brings header file comments in line with reality.

[Ilia Mirkin]

On Fri, Apr 21, 2017 at 12:59 PM, Ville Syrjälä
 wrote:
> On Fri, Apr 21, 2017 at 10:49:49AM -0400, Ilia Mirkin wrote:
>> On Fri, Apr 21, 2017 at 3:58 AM, Gerd Hoffmann  wrote:
>> > While working on graphics support for virtual machines on ppc64 (which
>> > exists in both little and big endian variants) I've figured the comments
>> > for various drm fourcc formats in the header file don't match reality.
>> >
>> > Comments says the RGB formats are little endian, but in practice they
>> > are native endian.  Look at the drm_mode_legacy_fb_format() helper.  It
>> > maps -- for example -- bpp/depth 32/24 to DRM_FORMAT_XRGB, no matter
>> > whenever the machine is little endian or big endian.  The users of this
>> > function (fbdev emulation, DRM_IOCTL_MODE_ADDFB) expect the framebuffer
>> > is native endian, not little endian.  Most userspace also operates on
>> > native endian only.
>> >
>> > So, go update the comments for all 16+24+32 bpp RGB formats.
>> >
>> > Leaving the yuv formats as-is.  I have no idea if and how those are used
>> > on bigendian machines.
>>
>> I think this is premature. The current situation is that I can't get
>> modetest to work *at all* on my NV34 / BE setup (I mean, it runs, just
>> the colors displayed are wrong). I believe that currently it packs
>> things in "cpu native endian". I've tried futzing with that without
>> much success, although I didn't spend too much time on it. I have a
>> NV34 plugged into my LE setup as well although I haven't tested to
>> double-check that it all works there. However I'm quite sure it used
>> to, as I used modetest to help develop the YUV overlay support for
>> those GPUs.
>
> I just took a quick stab at fixing modetest to respect the current
> wording in drm_fourcc.h:
>
> git://github.com/vsyrjala/libdrm.git modetest_endian

Looks like there was some careless testing on my part :( So ... it
looks like the current modetest without those changes does, in fact,
work on NV34/BE. With the changes, it breaks (and the handling of the
b* modes is a little broken in those patches -- they're not selectable
from the cmdline.) Which means that, as Michel & co predicted, it
appears to be taking BE input not LE input. This is very surprising to
me, but it is what it is. As I mentioned before, the details of how
the "BE" mode works on the GPUs is largely unknown to us beyond a few
basics. Note that only XR24 works, AR24 ends up with all black
displayed. This also happens on LE.

Furthermore, all of YUYV, UYVY, and NV12 plane overlays don't appear
to work properly. The first half of the overlay is OK (but I think
compressed), while the second half is gibberish. Testing this on my
board plugged into a LE CPU, I also get the same type of issue, so I'm
guessing that it's just bitrot of the feature. (Or modetest gained a
bug.)

Cheers,

  -ilia

Re: [PATCH v4 3/7] kprobes: validate the symbol name provided during probe registration

[Michael Ellerman]

"Naveen N. Rao"  writes:

> When a kprobe is being registered, we use the symbol_name field to
> lookup the address where the probe should be placed. Since this is a
> user-provided field, let's ensure that the length of the string is
> within expected limits.

What are we actually trying to protect against here?

If you ignore powerpc for a moment, kprobe_lookup_name() is just
kallsyms_lookup_name().

All kallsyms_lookup_name() does with name is strcmp() it against a
legitimate symbol name which is at most KSYM_NAME_LEN.

So I don't think any of this validation helps in that case?

In the powerpc version of kprobe_lookup_name() we do need to do some
string juggling, for which it helps to know the input is sane. But I
think we should just make that code more robust by checking the input
before we do anything with it.

cheers

[HMM 01/15] mm, memory_hotplug: introduce add_pages

[Jérôme Glisse]

From: Michal Hocko 

There are new users of memory hotplug emerging. Some of them require
different subset of arch_add_memory. There are some which only require
allocation of struct pages without mapping those pages to the kernel
address space. We currently have __add_pages for that purpose. But this
is rather lowlevel and not very suitable for the code outside of the
memory hotplug. E.g. x86_64 wants to update max_pfn which should be
done by the caller. Introduce add_pages() which should care about those
details if they are needed. Each architecture should define its
implementation and select CONFIG_ARCH_HAS_ADD_PAGES. All others use
the currently existing __add_pages.

Signed-off-by: Michal Hocko 
Signed-off-by: Jérôme Glisse 
---
 arch/x86/Kconfig   |  4 
 arch/x86/mm/init_64.c  | 22 +++---
 include/linux/memory_hotplug.h | 11 +++
 3 files changed, 30 insertions(+), 7 deletions(-)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index c43f476..e515dc2 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -2263,6 +2263,10 @@ source "kernel/livepatch/Kconfig"
 
 endmenu
 
+config ARCH_HAS_ADD_PAGES
+   def_bool y
+   depends on X86_64 && ARCH_ENABLE_MEMORY_HOTPLUG
+
 config ARCH_ENABLE_MEMORY_HOTPLUG
def_bool y
depends on X86_64 || (X86_32 && HIGHMEM)
diff --git a/arch/x86/mm/init_64.c b/arch/x86/mm/init_64.c
index ffeba90..a573ebc 100644
--- a/arch/x86/mm/init_64.c
+++ b/arch/x86/mm/init_64.c
@@ -671,7 +671,7 @@ void __init paging_init(void)
  * After memory hotplug the variables max_pfn, max_low_pfn and high_memory need
  * updating.
  */
-static void  update_end_of_memory_vars(u64 start, u64 size)
+static void update_end_of_memory_vars(u64 start, u64 size)
 {
unsigned long end_pfn = PFN_UP(start + size);
 
@@ -682,22 +682,30 @@ static void  update_end_of_memory_vars(u64 start, u64 
size)
}
 }
 
-int arch_add_memory(int nid, u64 start, u64 size, bool want_memblock)
+int add_pages(int nid, unsigned long start_pfn,
+ unsigned long nr_pages, bool want_memblock)
 {
-   unsigned long start_pfn = start >> PAGE_SHIFT;
-   unsigned long nr_pages = size >> PAGE_SHIFT;
int ret;
 
-   init_memory_mapping(start, start + size);
-
ret = __add_pages(nid, start_pfn, nr_pages, want_memblock);
WARN_ON_ONCE(ret);
 
/* update max_pfn, max_low_pfn and high_memory */
-   update_end_of_memory_vars(start, size);
+   update_end_of_memory_vars(start_pfn << PAGE_SHIFT,
+ nr_pages << PAGE_SHIFT);
 
return ret;
 }
+
+int arch_add_memory(int nid, u64 start, u64 size, bool want_memblock)
+{
+   unsigned long start_pfn = start >> PAGE_SHIFT;
+   unsigned long nr_pages = size >> PAGE_SHIFT;
+
+   init_memory_mapping(start, start + size);
+
+   return add_pages(nid, start_pfn, nr_pages, want_memblock);
+}
 EXPORT_SYMBOL_GPL(arch_add_memory);
 
 #define PAGE_INUSE 0xFD
diff --git a/include/linux/memory_hotplug.h b/include/linux/memory_hotplug.h
index aec8865..5ec6d64 100644
--- a/include/linux/memory_hotplug.h
+++ b/include/linux/memory_hotplug.h
@@ -126,6 +126,17 @@ extern int __remove_pages(struct zone *zone, unsigned long 
start_pfn,
 extern int __add_pages(int nid, unsigned long start_pfn,
unsigned long nr_pages, bool want_memblock);
 
+#ifndef CONFIG_ARCH_HAS_ADD_PAGES
+static inline int add_pages(int nid, unsigned long start_pfn,
+   unsigned long nr_pages, bool want_memblock)
+{
+   return __add_pages(nid, start_pfn, nr_pages, want_memblock);
+}
+#else /* ARCH_HAS_ADD_PAGES */
+int add_pages(int nid, unsigned long start_pfn,
+ unsigned long nr_pages, bool want_memblock);
+#endif /* ARCH_HAS_ADD_PAGES */
+
 #ifdef CONFIG_NUMA
 extern int memory_add_physaddr_to_nid(u64 start);
 #else
-- 
2.9.3

Re: [HMM 02/15] mm/put_page: move ZONE_DEVICE page reference decrement v2

[Dan Williams]

On Fri, Apr 21, 2017 at 8:30 PM, Jérôme Glisse  wrote:
> Move page reference decrement of ZONE_DEVICE from put_page()
> to put_zone_device_page() this does not affect non ZONE_DEVICE
> page.
>
> Doing this allow to catch when a ZONE_DEVICE page refcount reach
> 1 which means the device is no longer reference by any one (unlike
> page from other zone, ZONE_DEVICE page refcount never reach 0).
>
> This patch is just a preparatory patch for HMM.
>
> Changes since v1:
>   - commit message
>
> Signed-off-by: Jérôme Glisse 
> Cc: Dan Williams 
> Cc: Ross Zwisler 

Reviewed-by: Dan Williams 

[HMM 07/15] mm/hmm: heterogeneous memory management (HMM for short) v2

[Jérôme Glisse]

HMM provides 3 separate types of functionality:
- Mirroring: synchronize CPU page table and device page table
- Device memory: allocating struct page for device memory
- Migration: migrating regular memory to device memory

This patch introduces some common helpers and definitions to all of
those 3 functionality.

Changed since v1:
  - Kconfig logic (depend on x86-64 and use ARCH_HAS pattern)

Signed-off-by: Jérôme Glisse 
Signed-off-by: Evgeny Baskakov 
Signed-off-by: John Hubbard 
Signed-off-by: Mark Hairgrove 
Signed-off-by: Sherry Cheung 
Signed-off-by: Subhash Gutti 
---
 MAINTAINERS  |   7 +++
 include/linux/hmm.h  | 146 +++
 include/linux/mm_types.h |   5 ++
 kernel/fork.c|   2 +
 mm/Kconfig   |  13 +
 mm/Makefile  |   1 +
 mm/hmm.c |  71 +++
 7 files changed, 245 insertions(+)
 create mode 100644 include/linux/hmm.h
 create mode 100644 mm/hmm.c

diff --git a/MAINTAINERS b/MAINTAINERS
index 09341a9..6df21a9 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6052,6 +6052,13 @@ S:   Supported
 F: drivers/scsi/hisi_sas/
 F: Documentation/devicetree/bindings/scsi/hisilicon-sas.txt
 
+HMM - Heterogeneous Memory Management
+M: Jérôme Glisse 
+L: linux...@kvack.org
+S: Maintained
+F: mm/hmm*
+F: include/linux/hmm*
+
 HOST AP DRIVER
 M: Jouni Malinen 
 L: linux-wirel...@vger.kernel.org
diff --git a/include/linux/hmm.h b/include/linux/hmm.h
new file mode 100644
index 000..93b363d
--- /dev/null
+++ b/include/linux/hmm.h
@@ -0,0 +1,146 @@
+/*
+ * Copyright 2013 Red Hat Inc.
+ *
+ * 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.
+ *
+ * Authors: Jérôme Glisse 
+ */
+/*
+ * Heterogeneous Memory Management (HMM)
+ *
+ * See Documentation/vm/hmm.txt for reasons and overview of what HMM is and it
+ * is for. Here we focus on the HMM API description, with some explanation of
+ * the underlying implementation.
+ *
+ * Short description: HMM provides a set of helpers to share a virtual address
+ * space between CPU and a device, so that the device can access any valid
+ * address of the process (while still obeying memory protection). HMM also
+ * provides helpers to migrate process memory to device memory, and back. Each
+ * set of functionality (address space mirroring, and migration to and from
+ * device memory) can be used independently of the other.
+ *
+ *
+ * HMM address space mirroring API:
+ *
+ * Use HMM address space mirroring if you want to mirror range of the CPU page
+ * table of a process into a device page table. Here, "mirror" means "keep
+ * synchronized". Prerequisites: the device must provide the ability to write-
+ * protect its page tables (at PAGE_SIZE granularity), and must be able to
+ * recover from the resulting potential page faults.
+ *
+ * HMM guarantees that at any point in time, a given virtual address points to
+ * either the same memory in both CPU and device page tables (that is: CPU and
+ * device page tables each point to the same pages), or that one page table 
(CPU
+ * or device) points to no entry, while the other still points to the old page
+ * for the address. The latter case happens when the CPU page table update
+ * happens first, and then the update is mirrored over to the device page 
table.
+ * This does not cause any issue, because the CPU page table cannot start
+ * pointing to a new page until the device page table is invalidated.
+ *
+ * HMM uses mmu_notifiers to monitor the CPU page tables, and forwards any
+ * updates to each device driver that has registered a mirror. It also provides
+ * some API calls to help with taking a snapshot of the CPU page table, and to
+ * synchronize with any updates that might happen concurrently.
+ *
+ *
+ * HMM migration to and from device memory:
+ *
+ * HMM provides a set of helpers to hotplug device memory as ZONE_DEVICE, with
+ * a new MEMORY_DEVICE_UNADDRESSABLE type. This provides a struct page for
+ * each page of the device memory, and allows the device driver to manage its
+ * memory using those struct pages. Having struct pages for device memory makes
+ * migration easier. Because that memory is not addressable by the CPU it must
+ * never be pinned to the device; in other words, any CPU page fault can always
+ * 

[HMM 08/15] mm/hmm/mirror: mirror process address space on device with HMM helpers v2

[Jérôme Glisse]

This is a heterogeneous memory management (HMM) process address space
mirroring. In a nutshell this provide an API to mirror process address
space on a device. This boils down to keeping CPU and device page table
synchronize (we assume that both device and CPU are cache coherent like
PCIe device can be).

This patch provide a simple API for device driver to achieve address
space mirroring thus avoiding each device driver to grow its own CPU
page table walker and its own CPU page table synchronization mechanism.

This is useful for NVidia GPU >= Pascal, Mellanox IB >= mlx5 and more
hardware in the future.

Changed since v1:
  - Kconfig logic (depend on x86-64 and use ARCH_HAS pattern)

Signed-off-by: Jérôme Glisse 
Signed-off-by: Evgeny Baskakov 
Signed-off-by: John Hubbard 
Signed-off-by: Mark Hairgrove 
Signed-off-by: Sherry Cheung 
Signed-off-by: Subhash Gutti 
---
 include/linux/hmm.h | 110 ++
 mm/Kconfig  |  12 
 mm/hmm.c| 170 +++-
 3 files changed, 277 insertions(+), 15 deletions(-)

diff --git a/include/linux/hmm.h b/include/linux/hmm.h
index 93b363d..6668a1b 100644
--- a/include/linux/hmm.h
+++ b/include/linux/hmm.h
@@ -72,6 +72,7 @@
 
 #if IS_ENABLED(CONFIG_HMM)
 
+struct hmm;
 
 /*
  * hmm_pfn_t - HMM uses its own pfn type to keep several flags per page
@@ -134,6 +135,115 @@ static inline hmm_pfn_t hmm_pfn_t_from_pfn(unsigned long 
pfn)
 }
 
 
+#if IS_ENABLED(CONFIG_HMM_MIRROR)
+/*
+ * Mirroring: how to synchronize device page table with CPU page table.
+ *
+ * A device driver that is participating in HMM mirroring must always
+ * synchronize with CPU page table updates. For this, device drivers can either
+ * directly use mmu_notifier APIs or they can use the hmm_mirror API. Device
+ * drivers can decide to register one mirror per device per process, or just
+ * one mirror per process for a group of devices. The pattern is:
+ *
+ *  int device_bind_address_space(..., struct mm_struct *mm, ...)
+ *  {
+ *  struct device_address_space *das;
+ *
+ *  // Device driver specific initialization, and allocation of das
+ *  // which contains an hmm_mirror struct as one of its fields.
+ *  ...
+ *
+ *  ret = hmm_mirror_register(>mirror, mm, _mirror_ops);
+ *  if (ret) {
+ *  // Cleanup on error
+ *  return ret;
+ *  }
+ *
+ *  // Other device driver specific initialization
+ *  ...
+ *  }
+ *
+ * Once an hmm_mirror is registered for an address space, the device driver
+ * will get callbacks through sync_cpu_device_pagetables() operation (see
+ * hmm_mirror_ops struct).
+ *
+ * Device driver must not free the struct containing the hmm_mirror struct
+ * before calling hmm_mirror_unregister(). The expected usage is to do that 
when
+ * the device driver is unbinding from an address space.
+ *
+ *
+ *  void device_unbind_address_space(struct device_address_space *das)
+ *  {
+ *  // Device driver specific cleanup
+ *  ...
+ *
+ *  hmm_mirror_unregister(>mirror);
+ *
+ *  // Other device driver specific cleanup, and now das can be freed
+ *  ...
+ *  }
+ */
+
+struct hmm_mirror;
+
+/*
+ * enum hmm_update_type - type of update
+ * @HMM_UPDATE_INVALIDATE: invalidate range (no indication as to why)
+ */
+enum hmm_update_type {
+   HMM_UPDATE_INVALIDATE,
+};
+
+/*
+ * struct hmm_mirror_ops - HMM mirror device operations callback
+ *
+ * @update: callback to update range on a device
+ */
+struct hmm_mirror_ops {
+   /* sync_cpu_device_pagetables() - synchronize page tables
+*
+* @mirror: pointer to struct hmm_mirror
+* @update_type: type of update that occurred to the CPU page table
+* @start: virtual start address of the range to update
+* @end: virtual end address of the range to update
+*
+* This callback ultimately originates from mmu_notifiers when the CPU
+* page table is updated. The device driver must update its page table
+* in response to this callback. The update argument tells what action
+* to perform.
+*
+* The device driver must not return from this callback until the device
+* page tables are completely updated (TLBs flushed, etc); this is a
+* synchronous call.
+*/
+   void (*sync_cpu_device_pagetables)(struct hmm_mirror *mirror,
+  enum hmm_update_type update_type,
+  unsigned long start,
+  unsigned long end);
+};
+
+/*
+ * struct hmm_mirror - mirror struct for a device driver
+ *
+ * @hmm: pointer to struct hmm (which is unique per mm_struct)
+ * @ops: device driver 

Re: [PATCH 2/8] selftests: lib.mk: define CLEAN macro to allow Makefiles to override clean

[Michael Ellerman]

Shuah Khan  writes:

> Define CLEAN macro to allow Makefiles to override common clean target
> in lib.mk. This will help fix the following failures:
>
> warning: overriding recipe for target 'clean'
> ../lib.mk:55: warning: ignoring old recipe for target 'clean'
>
> Signed-off-by: Shuah Khan 

Should probably have:

Fixes: 88baa78d1f31 ("selftests: remove duplicated all and clean target")


In hindsight I'm not sure moving the clean target into lib.mk was
the best idea, but anyway it's a bit late to change our mind on that.

This patch is a good solution to fix the warnings.

Acked-by: Michael Ellerman 

cheers

Re: [PATCH 6/8] selftests: splice: override clean in lib.mk to fix warnings

[Michael Ellerman]

Shuah Khan  writes:

> Add override for lib.mk clean to fix the following warnings from clean
> target run.
>
> Makefile:8: warning: overriding recipe for target 'clean'
> ../lib.mk:55: warning: ignoring old recipe for target 'clean'
>
> Signed-off-by: Shuah Khan 
> ---
>  tools/testing/selftests/splice/Makefile | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/tools/testing/selftests/splice/Makefile 
> b/tools/testing/selftests/splice/Makefile
> index 559512c..3f967ba 100644
> --- a/tools/testing/selftests/splice/Makefile
> +++ b/tools/testing/selftests/splice/Makefile
> @@ -4,5 +4,6 @@ all: $(TEST_PROGS) $(EXTRA)
>  
>  include ../lib.mk
>  
> -clean:
> +override define CLEAN
>   rm -fr $(EXTRA)
> +endef

Could just be:

EXTRA_CLEAN := $(EXTRA)

cheers

Re: [PATCH 4/8] selftests: gpio: override clean in lib.mk to fix warnings

[Michael Ellerman]

Shuah Khan  writes:

> Add override for lib.mk clean to fix the following warnings from clean
> target run.
>
> Makefile:11: warning: overriding recipe for target 'clean'
> ../lib.mk:55: warning: ignoring old recipe for target 'clean'
>
> Signed-off-by: Shuah Khan 
> ---
>  tools/testing/selftests/gpio/Makefile | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/tools/testing/selftests/gpio/Makefile 
> b/tools/testing/selftests/gpio/Makefile
> index 205e4d1..4f6d9e0 100644
> --- a/tools/testing/selftests/gpio/Makefile
> +++ b/tools/testing/selftests/gpio/Makefile
> @@ -7,8 +7,9 @@ include ../lib.mk
>  
>  all: $(BINARIES)
>  
> -clean:
> +override define CLEAN
>   $(RM) $(BINARIES)
> +endef

This could be achieved more simply with:

EXTRA_CLEAN := $(BINARIES)

cheers

Re: [PATCH 7/8] selftests: sync: override clean in lib.mk to fix warnings

[Michael Ellerman]

Shuah Khan  writes:

> Add override for lib.mk clean to fix the following warnings from clean
> target run.
>
> Makefile:24: warning: overriding recipe for target 'clean'
> ../lib.mk:55: warning: ignoring old recipe for target 'clean'
>
> Signed-off-by: Shuah Khan 
> ---
>  tools/testing/selftests/sync/Makefile | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/tools/testing/selftests/sync/Makefile 
> b/tools/testing/selftests/sync/Makefile
> index 87ac400..f7d250d 100644
> --- a/tools/testing/selftests/sync/Makefile
> +++ b/tools/testing/selftests/sync/Makefile
> @@ -20,5 +20,6 @@ TESTS += sync_stress_merge.o
>  
>  sync_test: $(OBJS) $(TESTS)
>  
> -clean:
> +override define CLEAN
>   $(RM) sync_test $(OBJS) $(TESTS)
> +endef

EXTRA_CLEAN := sync_test $(OBJS) $(TESTS)

cheers

Linux 3.18.50

[Greg KH]

I'm announcing the release of the 3.18.50 kernel.

All users of the 3.18 kernel series must upgrade.

The updated 3.18.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git 
linux-3.18.y
and can be browsed at the normal kernel.org git web browser:

http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary

thanks,

greg k-h



 Makefile   |2 
 arch/arm/include/asm/psci.h|2 
 arch/arm/kvm/mmu.c |3 
 arch/c6x/kernel/ptrace.c   |   41 ---
 arch/metag/include/asm/uaccess.h   |   15 -
 arch/metag/kernel/ptrace.c |   19 +
 arch/metag/lib/usercopy.c  |  312 +
 arch/mips/kernel/ptrace.c  |3 
 arch/powerpc/boot/zImage.lds.S |1 
 arch/powerpc/kernel/align.c|   27 +-
 arch/powerpc/kernel/setup_64.c |9 
 arch/powerpc/kvm/emulate.c |1 
 arch/powerpc/mm/hash_native_64.c   |7 
 arch/s390/boot/compressed/misc.c   |   35 +-
 arch/s390/include/asm/uaccess.h|2 
 arch/sparc/kernel/ptrace_64.c  |2 
 arch/x86/include/asm/elf.h |2 
 arch/x86/kernel/cpu/perf_event_intel_lbr.c |2 
 arch/x86/kvm/vmx.c |   10 
 arch/x86/mm/init.c |   40 ++-
 arch/x86/vdso/vdso32-setup.c   |   11 
 block/scsi_ioctl.c |3 
 crypto/ahash.c |   79 --
 drivers/acpi/Makefile  |1 
 drivers/acpi/acpi_platform.c   |8 
 drivers/block/zram/zram_drv.c  |6 
 drivers/char/Kconfig   |6 
 drivers/char/mem.c |   82 --
 drivers/char/virtio_console.c  |   12 
 drivers/crypto/caam/ctrl.c |3 
 drivers/gpu/drm/ttm/ttm_object.c   |   10 
 drivers/gpu/drm/vmwgfx/vmwgfx_fence.c  |   79 --
 drivers/gpu/drm/vmwgfx/vmwgfx_ioctl.c  |4 
 drivers/gpu/drm/vmwgfx/vmwgfx_resource.c   |4 
 drivers/gpu/drm/vmwgfx/vmwgfx_surface.c|   31 +-
 drivers/hv/hv_balloon.c|4 
 drivers/iio/adc/ti_am335x_adc.c|   13 -
 drivers/input/joystick/iforce/iforce-usb.c |3 
 drivers/input/joystick/xpad.c  |2 
 drivers/input/misc/cm109.c |4 
 drivers/input/misc/ims-pcu.c   |4 
 drivers/input/misc/yealink.c   |4 
 drivers/input/serio/i8042-x86ia64io.h  |7 
 drivers/input/tablet/hanwang.c |3 
 drivers/input/tablet/kbtab.c   |3 
 drivers/input/touchscreen/sur40.c  |3 
 drivers/iommu/intel-iommu.c|2 
 drivers/isdn/gigaset/bas-gigaset.c |3 
 drivers/md/raid10.c|   18 +
 drivers/media/usb/dvb-usb-v2/dvb_usb_core.c|   10 
 drivers/media/usb/dvb-usb/dvb-usb-firmware.c   |   33 +-
 drivers/media/usb/uvc/uvc_driver.c |  118 -
 drivers/mmc/host/sdhci.c   |4 
 drivers/mmc/host/ushc.c|3 
 drivers/mtd/bcm47xxpart.c  |   10 
 drivers/net/ethernet/broadcom/genet/bcmgenet.c |6 
 drivers/net/ethernet/intel/igb/e1000_phy.c |4 
 drivers/net/ethernet/mellanox/mlx5/core/main.c |2 
 drivers/net/usb/catc.c |   56 ++--
 drivers/net/usb/pegasus.c  |   29 ++
 drivers/net/usb/rtl8150.c  |   34 ++
 drivers/pinctrl/qcom/pinctrl-msm.c |4 
 drivers/platform/x86/acer-wmi.c|   22 +
 drivers/rtc/rtc-s35390a.c  |  167 ++---
 drivers/rtc/rtc-tegra.c|   28 ++
 drivers/scsi/libiscsi.c|   26 ++
 drivers/scsi/libsas/sas_ata.c  |2 
 drivers/scsi/lpfc/lpfc_init.c  |1 
 drivers/scsi/sd.c  |   20 +
 drivers/scsi/sg.c  |2 
 drivers/scsi/sr.c  |6 
 drivers/target/iscsi/iscsi_target_parameters.c |   16 -
 drivers/target/iscsi/iscsi_target_util.c   |   12 
 drivers/target/target_core_pscsi.c |   47 ---
 drivers/target/target_core_sbc.c   |   10 
 drivers/tty/serial/8250/8250_pci.c |   23 +
 drivers/tty/serial/atmel_serial.c  |5 
 drivers/usb/class/usbtmc.c |7 
 drivers/usb/gadget/function/f_acm.c|4 
 drivers/uwb/hwa-rc.c   |

Re: [HMM 03/15] mm/unaddressable-memory: new type of ZONE_DEVICE for unaddressable memory

[Dan Williams]

On Fri, Apr 21, 2017 at 8:30 PM, Jérôme Glisse  wrote:
> HMM (heterogeneous memory management) need struct page to support migration
> from system main memory to device memory.  Reasons for HMM and migration to
> device memory is explained with HMM core patch.
>
> This patch deals with device memory that is un-addressable memory (ie CPU
> can not access it). Hence we do not want those struct page to be manage
> like regular memory. That is why we extend ZONE_DEVICE to support different
> types of memory.
>
> A persistent memory type is define for existing user of ZONE_DEVICE and a
> new device un-addressable type is added for the un-addressable memory type.
> There is a clear separation between what is expected from each memory type
> and existing user of ZONE_DEVICE are un-affected by new requirement and new
> use of the un-addressable type. All specific code path are protect with
> test against the memory type.
>
> Because memory is un-addressable we use a new special swap type for when
> a page is migrated to device memory (this reduces the number of maximum
> swap file).
>
> The main two additions beside memory type to ZONE_DEVICE is two callbacks.
> First one, page_free() is call whenever page refcount reach 1 (which means
> the page is free as ZONE_DEVICE page never reach a refcount of 0). This
> allow device driver to manage its memory and associated struct page.
>
> The second callback page_fault() happens when there is a CPU access to
> an address that is back by a device page (which are un-addressable by the
> CPU). This callback is responsible to migrate the page back to system
> main memory. Device driver can not block migration back to system memory,
> HMM make sure that such page can not be pin into device memory.
>
> If device is in some error condition and can not migrate memory back then
> a CPU page fault to device memory should end with SIGBUS.
>
> Signed-off-by: Jérôme Glisse 
> Cc: Dan Williams 
> Cc: Ross Zwisler 
> ---
>  fs/proc/task_mmu.c   |  7 +
>  include/linux/ioport.h   |  1 +
>  include/linux/memremap.h | 82 
> 
>  include/linux/swap.h | 24 --
>  include/linux/swapops.h  | 68 +++
>  kernel/memremap.c| 43 -
>  mm/Kconfig   | 13 
>  mm/memory.c  | 61 +++
>  mm/memory_hotplug.c  | 10 --
>  mm/mprotect.c| 14 +
>  10 files changed, 317 insertions(+), 6 deletions(-)
>
> diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c
> index f0c8b33..a12ba94 100644
> --- a/fs/proc/task_mmu.c
> +++ b/fs/proc/task_mmu.c
> @@ -542,6 +542,8 @@ static void smaps_pte_entry(pte_t *pte, unsigned long 
> addr,
> }
> } else if (is_migration_entry(swpent))
> page = migration_entry_to_page(swpent);
> +   else if (is_device_entry(swpent))
> +   page = device_entry_to_page(swpent);
> } else if (unlikely(IS_ENABLED(CONFIG_SHMEM) && mss->check_shmem_swap
> && pte_none(*pte))) {
> page = find_get_entry(vma->vm_file->f_mapping,
> @@ -704,6 +706,8 @@ static int smaps_hugetlb_range(pte_t *pte, unsigned long 
> hmask,
>
> if (is_migration_entry(swpent))
> page = migration_entry_to_page(swpent);
> +   else if (is_device_entry(swpent))
> +   page = device_entry_to_page(swpent);
> }
> if (page) {
> int mapcount = page_mapcount(page);
> @@ -1196,6 +1200,9 @@ static pagemap_entry_t pte_to_pagemap_entry(struct 
> pagemapread *pm,
> flags |= PM_SWAP;
> if (is_migration_entry(entry))
> page = migration_entry_to_page(entry);
> +
> +   if (is_device_entry(entry))
> +   page = device_entry_to_page(entry);
> }
>
> if (page && !PageAnon(page))
> diff --git a/include/linux/ioport.h b/include/linux/ioport.h
> index 6230064..ec619dc 100644
> --- a/include/linux/ioport.h
> +++ b/include/linux/ioport.h
> @@ -130,6 +130,7 @@ enum {
> IORES_DESC_ACPI_NV_STORAGE  = 3,
> IORES_DESC_PERSISTENT_MEMORY= 4,
> IORES_DESC_PERSISTENT_MEMORY_LEGACY = 5,
> +   IORES_DESC_DEVICE_MEMORY_UNADDRESSABLE  = 6,
>  };
>
>  /Fput* helpers to define resources */
> diff --git a/include/linux/memremap.h b/include/linux/memremap.h
> index 9341619..365fb4e 100644
> --- a/include/linux/memremap.h
> +++ b/include/linux/memremap.h
> @@ -35,24 +35,101 @@ static inline struct vmem_altmap 
> *to_vmem_altmap(unsigned long memmap_start)
>  }
>  #endif
>
> +/*
> + * Specialize ZONE_DEVICE memory into multiple 

Re: [PATCH 8/8] selftests: x86: override clean in lib.mk to fix warnings

[Michael Ellerman]

Shuah Khan  writes:

> Add override for lib.mk clean to fix the following warnings from clean
> target run.
>
> Makefile:44: warning: overriding recipe for target 'clean'
> ../lib.mk:55: warning: ignoring old recipe for target 'clean'
>
> Signed-off-by: Shuah Khan 
> ---
>  tools/testing/selftests/x86/Makefile | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/tools/testing/selftests/x86/Makefile 
> b/tools/testing/selftests/x86/Makefile
> index 38e0a9c..4d27550 100644
> --- a/tools/testing/selftests/x86/Makefile
> +++ b/tools/testing/selftests/x86/Makefile
> @@ -40,8 +40,9 @@ all_32: $(BINARIES_32)
>  
>  all_64: $(BINARIES_64)
>  
> -clean:
> +override define CLEAN
>   $(RM) $(BINARIES_32) $(BINARIES_64)
> +endef

Simpler as:

EXTRA_CLEAN := $(BINARIES_32) $(BINARIES_64)

cheers

Re: [PATCH v13 03/10] mux: minimal mux subsystem and gpio-based mux controller

[Peter Rosin]

On 2017-04-21 16:41, Philipp Zabel wrote:
> On Fri, 2017-04-21 at 16:32 +0200, Peter Rosin wrote:
>> On 2017-04-21 16:23, Philipp Zabel wrote:
>>> On Thu, 2017-04-13 at 18:43 +0200, Peter Rosin wrote:
>>> [...]
 +int mux_chip_register(struct mux_chip *mux_chip)
 +{
 +  int i;
 +  int ret;
 +
 +  for (i = 0; i < mux_chip->controllers; ++i) {
 +  struct mux_control *mux = _chip->mux[i];
 +
 +  if (mux->idle_state == mux->cached_state)
 +  continue;
>>>
>>> I think this should be changed to
>>>  
>>> -   if (mux->idle_state == mux->cached_state)
>>> +   if (mux->idle_state == mux->cached_state ||
>>> +   mux->idle_state == MUX_IDLE_AS_IS)
>>> continue;
>>>
>>> or the following mux_control_set will be called with state ==
>>> MUX_IDLE_AS_IS. Alternatively, mux_control_set should return when passed
>>> this value.
>>
>> That cannot happen because ->cached_state is initialized to -1
>> in mux_chip_alloc, so should always be == MUX_IDLE_AS_IS when
>> registering. And drivers are not supposed to touch ->cached_state.
>> I.e., ->cached_state is "owned" by the core.
> 
> So this was caused by me filling cached_state from register reads in the
> mmio driver. Makes me wonder why I am not allowed to do this, though, if
> I am able to read back the initial state?

You gain fairly little by reading back the original state. If the mux
should idle-as-is, you can avoid a maximum of one mux update if the first
consumer happens to starts by requesting the previously active state.
Similarly, if the mux should idle in a specific state, you can avoid a
maximum of one mux update.

In both cases it costs one unconditional read of the mux state.

Sure, in some cases reads are cheaper than writes, but I didn't think
support for seeding the cache was worth it. Is it worth it?

Cheers,
peda

Re: [PATCH net-next] liquidio: remove unnecessary variable assignment

[David Miller]

From: Arnd Bergmann 
Date: Wed, 19 Apr 2017 19:30:59 +0200

> gcc points out an useless assignment that was added during code refactoring:
> 
> drivers/net/ethernet/cavium/liquidio/lio_ethtool.c: In function 
> 'octnet_intrmod_callback':
> drivers/net/ethernet/cavium/liquidio/lio_ethtool.c:1315:59: error: parameter 
> 'oct_dev' set but not used [-Werror=unused-but-set-parameter]
> 
> This is harmless but can clearly be remove to avoid the warning.
> 
> Fixes: 50c0add534d2 ("liquidio: refactor interrupt moderation code")
> Signed-off-by: Arnd Bergmann 

Applied.

Re: [PATCH net-next 1/1] netvsc: Deal with rescinded channels correctly

[David Miller]

From: k...@exchange.microsoft.com
Date: Wed, 19 Apr 2017 13:53:49 -0700

> From: K. Y. Srinivasan 
> 
> We will not be able to send packets over a channel that has been
> rescinded. Make necessary adjustments so we can properly cleanup
> even when the channel is rescinded. This issue can be trigerred
> in the NIC hot-remove path.
> 
> Signed-off-by: K. Y. Srinivasan 

Applied, thanks.

Applied "spi: spi-ti-qspi: Use bounce buffer if read buffer is not DMA'ble" to the spi tree

[Mark Brown]

The patch

   spi: spi-ti-qspi: Use bounce buffer if read buffer is not DMA'ble

has been applied to the spi tree at

   git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git 

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.  

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark

>From c687c46e9e4527c4b4d82bc3cca58c1b08bcfb83 Mon Sep 17 00:00:00 2001
From: Vignesh R 
Date: Tue, 11 Apr 2017 17:22:25 +0530
Subject: [PATCH] spi: spi-ti-qspi: Use bounce buffer if read buffer is not
 DMA'ble

Flash filesystems like JFFS2, UBIFS and MTD block layer can provide
vmalloc'd or kmap'd buffers that cannot be mapped using dma_map_sg() and
can potentially be in memory region above 32bit addressable region(ie
buffers belonging to memory region backed by LPAE) of DMA, implement
spi_flash_can_dma() interface to inform SPI core not to map such
buffers.
When buffers are not mapped for DMA, then use a pre allocated bounce
buffer(64K = typical flash erase sector size) to read from flash and
then do a copy to actual destination buffer. This is approach is much
faster than using memcpy using CPU and also reduces CPU load.

With this patch, UBIFS read speed is ~18MB/s and CPU utilization <20% on
DRA74 Rev H EVM. Performance degradation is negligible when compared
with non bounce buffer case while using UBIFS.

Signed-off-by: Vignesh R 
Signed-off-by: Mark Brown 
---
 drivers/spi/spi-ti-qspi.c | 66 ++-
 1 file changed, 59 insertions(+), 7 deletions(-)

diff --git a/drivers/spi/spi-ti-qspi.c b/drivers/spi/spi-ti-qspi.c
index 804914ebfd9d..23a06148b8ae 100644
--- a/drivers/spi/spi-ti-qspi.c
+++ b/drivers/spi/spi-ti-qspi.c
@@ -33,6 +33,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -57,6 +58,8 @@ struct ti_qspi {
struct ti_qspi_regs ctx_reg;
 
dma_addr_t  mmap_phys_base;
+   dma_addr_t  rx_bb_dma_addr;
+   void*rx_bb_addr;
struct dma_chan *rx_chan;
 
u32 spi_max_frequency;
@@ -126,6 +129,8 @@ struct ti_qspi {
 #define QSPI_SETUP_ADDR_SHIFT  8
 #define QSPI_SETUP_DUMMY_SHIFT 10
 
+#define QSPI_DMA_BUFFER_SIZESZ_64K
+
 static inline unsigned long ti_qspi_read(struct ti_qspi *qspi,
unsigned long reg)
 {
@@ -429,6 +434,35 @@ static int ti_qspi_dma_xfer(struct ti_qspi *qspi, 
dma_addr_t dma_dst,
return 0;
 }
 
+static int ti_qspi_dma_bounce_buffer(struct ti_qspi *qspi,
+struct spi_flash_read_message *msg)
+{
+   size_t readsize = msg->len;
+   void *to = msg->buf;
+   dma_addr_t dma_src = qspi->mmap_phys_base + msg->from;
+   int ret = 0;
+
+   /*
+* Use bounce buffer as FS like jffs2, ubifs may pass
+* buffers that does not belong to kernel lowmem region.
+*/
+   while (readsize != 0) {
+   size_t xfer_len = min_t(size_t, QSPI_DMA_BUFFER_SIZE,
+   readsize);
+
+   ret = ti_qspi_dma_xfer(qspi, qspi->rx_bb_dma_addr,
+  dma_src, xfer_len);
+   if (ret != 0)
+   return ret;
+   memcpy(to, qspi->rx_bb_addr, xfer_len);
+   readsize -= xfer_len;
+   dma_src += xfer_len;
+   to += xfer_len;
+   }
+
+   return ret;
+}
+
 static int ti_qspi_dma_xfer_sg(struct ti_qspi *qspi, struct sg_table rx_sg,
   loff_t from)
 {
@@ -496,6 +530,12 @@ static void ti_qspi_setup_mmap_read(struct spi_device *spi,
  QSPI_SPI_SETUP_REG(spi->chip_select));
 }
 
+static bool ti_qspi_spi_flash_can_dma(struct spi_device *spi,
+ struct spi_flash_read_message *msg)
+{
+   return virt_addr_valid(msg->buf);
+}
+
 static int ti_qspi_spi_flash_read(struct spi_device *spi,
  struct spi_flash_read_message *msg)
 {
@@ -509,15 +549,12 @@ static int ti_qspi_spi_flash_read(struct spi_device *spi,
ti_qspi_setup_mmap_read(spi, msg);
 
if (qspi->rx_chan) {
-   if (msg->cur_msg_mapped) {
+   if (msg->cur_msg_mapped)
ret = 

Re: [PATCH v3] Staging: most: use __func__ instead of the function name

[Greg KH]

On Fri, Apr 21, 2017 at 11:06:54AM -0700, Chandra Annamaneni wrote:
> 
> Sorry about the top posting.
> 
> I did ask about it on the 9th of April and the reply was that the email
> was 'acked'. Since I did not get a further email, I assumed it was lost.
> Perhaps I misunderstood.

I really do not know, sorry.  If you didn't get an automated email from
my system that it was applied, rebased it against the latest
staging-next branch and resend it.

thanks,

greg k-h

Re: [PATCH V15 04/11] efi: parse ARM processor error

[Borislav Petkov]

On Tue, Apr 18, 2017 at 05:05:16PM -0600, Tyler Baicar wrote:
> Add support for ARM Common Platform Error Record (CPER).
> UEFI 2.6 specification adds support for ARM specific
> processor error information to be reported as part of the
> CPER records. This provides more detail on for processor error logs.
> 
> Signed-off-by: Tyler Baicar 
> CC: Jonathan (Zhixiong) Zhang 
> Reviewed-by: James Morse 
> Reviewed-by: Ard Biesheuvel 
> ---
>  drivers/firmware/efi/cper.c | 135 
> 
>  include/linux/cper.h|  54 ++
>  2 files changed, 189 insertions(+)
> 
> diff --git a/drivers/firmware/efi/cper.c b/drivers/firmware/efi/cper.c
> index 46585f9..f959185 100644
> --- a/drivers/firmware/efi/cper.c
> +++ b/drivers/firmware/efi/cper.c
> @@ -110,12 +110,15 @@ void cper_print_bits(const char *pfx, unsigned int bits,
>  static const char * const proc_type_strs[] = {
>   "IA32/X64",
>   "IA64",
> + "ARM",
>  };
>  
>  static const char * const proc_isa_strs[] = {
>   "IA32",
>   "IA64",
>   "X64",
> + "ARM A32/T32",
> + "ARM A64",
>  };
>  
>  static const char * const proc_error_type_strs[] = {
> @@ -184,6 +187,128 @@ static void cper_print_proc_generic(const char *pfx,
>   printk("%s""IP: 0x%016llx\n", pfx, proc->ip);
>  }
>  
> +#if defined(CONFIG_ARM64) || defined(CONFIG_ARM)
> +static const char * const arm_reg_ctx_strs[] = {
> + "AArch32 general purpose registers",
> + "AArch32 EL1 context registers",
> + "AArch32 EL2 context registers",
> + "AArch32 secure context registers",
> + "AArch64 general purpose registers",
> + "AArch64 EL1 context registers",
> + "AArch64 EL2 context registers",
> + "AArch64 EL3 context registers",
> + "Misc. system register structure",
> +};
> +
> +static void cper_print_proc_arm(const char *pfx,
> + const struct cper_sec_proc_arm *proc)
> +{
> + int i, len, max_ctx_type;
> + struct cper_arm_err_info *err_info;
> + struct cper_arm_ctx_info *ctx_info;
> + char newpfx[64];
> +
> + printk("%ssection length: %d\n", pfx, proc->section_length);

We need to dump section length because?

> + printk("%sMIDR: 0x%016llx\n", pfx, proc->midr);
> +
> + len = proc->section_length - (sizeof(*proc) +
> + proc->err_info_num * (sizeof(*err_info)));
> + if (len < 0) {
> + printk("%ssection length is too small\n", pfx);

Now here we *can* dump it.

> + printk("%sfirmware-generated error record is incorrect\n", pfx);
> + printk("%sERR_INFO_NUM is %d\n", pfx, proc->err_info_num);
> + return;
> + }
> +
> + if (proc->validation_bits & CPER_ARM_VALID_MPIDR)
> + printk("%sMPIDR: 0x%016llx\n", pfx, proc->mpidr);


< newline here.

Also, what is MPIDR and can it be written in a more user-friendly manner
and not be an abbreviation?

> + if (proc->validation_bits & CPER_ARM_VALID_AFFINITY_LEVEL)
> + printk("%serror affinity level: %d\n", pfx,
> + proc->affinity_level);
> + if (proc->validation_bits & CPER_ARM_VALID_RUNNING_STATE) {
> + printk("%srunning state: 0x%x\n", pfx, proc->running_state);
> + printk("%sPSCI state: %d\n", pfx, proc->psci_state);

One more abbreviation. Please consider whether having the abbreviations
or actually writing them out is more user-friendly.

> + }
> +
> + snprintf(newpfx, sizeof(newpfx), "%s%s", pfx, INDENT_SP);

That INDENT_SP thing is just silly, someone should kill it.

> +
> + err_info = (struct cper_arm_err_info *)(proc + 1);
> + for (i = 0; i < proc->err_info_num; i++) {
> + printk("%sError info structure %d:\n", pfx, i);
> + printk("%sversion:%d\n", newpfx, err_info->version);
> + printk("%slength:%d\n", newpfx, err_info->length);

< newline here.

Why do we even dump version and info for *every* err_info structure?

> + if (err_info->validation_bits &
> + CPER_ARM_INFO_VALID_MULTI_ERR) {
> + if (err_info->multiple_error == 0)
> + printk("%ssingle error\n", newpfx);
> + else if (err_info->multiple_error == 1)
> + printk("%smultiple errors\n", newpfx);
> + else
> + printk("%smultiple errors count:%u\n",
> + newpfx, err_info->multiple_error);

So this can be simply: "num errors: %d", err_info->multiple_error+1...

Without checking CPER_ARM_INFO_VALID_MULTI_ERR.

> + }

< newline here.

> + if (err_info->validation_bits & CPER_ARM_INFO_VALID_FLAGS) {
> + if (err_info->flags & CPER_ARM_INFO_FLAGS_FIRST)
> + 

[PATCH net-next] net: dsa: LAN9303: add I2C dependency

[Arnd Bergmann]

With CONFIG_I2C=m and NET_DSA_SMSC_LAN9303=y, we run into a link error:

drivers/base/regmap/regmap-i2c.o: In function `regmap_smbus_byte_reg_read':
regmap-i2c.c:(.text.regmap_smbus_byte_reg_read+0x18): undefined reference to 
`i2c_smbus_read_byte_data'
drivers/base/regmap/regmap-i2c.o: In function `regmap_smbus_byte_reg_write':
regmap-i2c.c:(.text.regmap_smbus_byte_reg_write+0x18): undefined reference to 
`i2c_smbus_write_byte_data'
drivers/base/regmap/regmap-i2c.o: In function `regmap_smbus_word_reg_read':
regmap-i2c.c:(.text.regmap_smbus_word_reg_read+0x18): undefined reference to 
`i2c_smbus_read_word_data'
drivers/base/regmap/regmap-i2c.o: In function `regmap_smbus_word_read_swapped':
regmap-i2c.c:(.text.regmap_smbus_word_read_swapped+0x18): undefined reference 
to `i2c_smbus_read_word_data'
drivers/base/regmap/regmap-i2c.o: In function `regmap_smbus_word_write_swapped':

This adds a Kconfig dependency to avoid the broken configuration.

Fixes: be4e119f9914 ("net: dsa: LAN9303: add I2C managed mode support")
Signed-off-by: Arnd Bergmann 
---
 drivers/net/dsa/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/dsa/Kconfig b/drivers/net/dsa/Kconfig
index 131a5b1cbfc8..862ee22303c2 100644
--- a/drivers/net/dsa/Kconfig
+++ b/drivers/net/dsa/Kconfig
@@ -59,7 +59,7 @@ config NET_DSA_SMSC_LAN9303
 
 config NET_DSA_SMSC_LAN9303_I2C
tristate "SMSC/Microchip LAN9303 3-ports 10/100 ethernet switch in I2C 
managed mode"
-   depends on NET_DSA
+   depends on NET_DSA && I2C
select NET_DSA_SMSC_LAN9303
select REGMAP_I2C
---help---
-- 
2.9.0

Re: [PATCH V15 03/11] cper: add timestamp print to CPER status printing

[Borislav Petkov]

On Fri, Apr 21, 2017 at 12:08:43PM -0600, Baicar, Tyler wrote:
> The timestamp may still be useful when it is imprecise. In the polling case,
> you may only poll every minute or so, so the time may be useful.

Well, what is in the timestamp when !precise? Some random time or some
timestamp from a couple of seconds ago? How do you differentiate what
timestamp is bollocks and what is from a while ago?

Is the imprecise tstamp really close to the time the error happened or
pointing at 1970 - the beginning of unix time? :-)

I'm sure you've picked up by now that we don't trust the firmware one
bit.

> Also, I imagine there could be interrupt based errors happening much faster 
> than the
> FW/OS handshake can happen. Maybe we can just use what I had before but also
> specify imprecise so that it is clear:
> 
> printk("%s%ststamp: %02d%02d-%02d-%02d %02d:%02d:%02d\n", pfx,
> (timestamp[3] & 0x1 ? "precise " : "imprecise "),
>  century, year, mon, day, hour, min, sec);

I guess.

-- 
Regards/Gruss,
Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.

Applied "ASoC: fsl_asrc_dma: use correct direction enum type" to the asoc tree

[Mark Brown]

The patch

   ASoC: fsl_asrc_dma: use correct direction enum type

has been applied to the asoc tree at

   git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git 

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.  

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark

>From 24dbd9edb668e2376ce871199f5ee4fd59c62276 Mon Sep 17 00:00:00 2001
From: Stefan Agner 
Date: Wed, 19 Apr 2017 23:36:07 -0700
Subject: [PATCH] ASoC: fsl_asrc_dma: use correct direction enum type

The direction argument is of type enum dma_transfer_direction, and
not enum dma_data_direction. The enumeration values are the same
so this did not had an effect in practise.

Signed-off-by: Stefan Agner 
Acked-by: Nicolin Chen 
Signed-off-by: Mark Brown 
---
 sound/soc/fsl/fsl_asrc_dma.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/sound/soc/fsl/fsl_asrc_dma.c b/sound/soc/fsl/fsl_asrc_dma.c
index dc30d780f874..282d841840b1 100644
--- a/sound/soc/fsl/fsl_asrc_dma.c
+++ b/sound/soc/fsl/fsl_asrc_dma.c
@@ -76,7 +76,7 @@ static int fsl_asrc_dma_prepare_and_submit(struct 
snd_pcm_substream *substream)
pair->dma_chan[!dir], runtime->dma_addr,
snd_pcm_lib_buffer_bytes(substream),
snd_pcm_lib_period_bytes(substream),
-   dir == OUT ? DMA_TO_DEVICE : DMA_FROM_DEVICE, flags);
+   dir == OUT ? DMA_MEM_TO_DEV : DMA_DEV_TO_MEM, flags);
if (!pair->desc[!dir]) {
dev_err(dev, "failed to prepare slave DMA for Front-End\n");
return -ENOMEM;
-- 
2.11.0

Re: bug fix for registers debugfs file implementation [RFC]

[Mark Brown]

On Sat, Apr 01, 2017 at 02:13:41AM -0700, noman pouigt wrote:
> Current registers debugfs file implementation doesn't
> handle if the size exceeds 4k. It just dumps 4k of registers.
> Fix this by using the seq_file which already handles
> the file offset logic instead of reinventing the wheel.
> 
> I am wondering if there is any issue is doing below which
> I am not aware of?

If I remember correctly this is done the way it is because seq_file has
to iterate through the entire file to get to the point being read by the
application.  This is a *very* big overhead for some applications (like
monitoring some registers to see what they're doing) on bigger devices,
especially if there's lots of uncached stuff and the reads have to go to
the hardware.  With the current code you can open the file, seek to the
registers you're interested in and read only them.  You'll notice that
the other debug files have been converted over to seq_file as they're
pure software and there's less reason to repeatedly read them.

I'm also very surprised that this is failing for you as I know this code
has been fairly heavily exercised with devices with very large register
maps much larger than 4k and my own testing is mainly doing cats which
seemed to work last time I tried and should be iterating over the 4k
boundary...  what's the actual failure mode?  I'm guessing it's
something if we end a register exactly on a page boundary or something?

Also your patch is completely tab/space mangled so it's not appliable.

> +static void regmap_debugfs_stop(struct seq_file *s, void *v)
> +{
> +}

The need for empty functions is worrying...


signature.asc
Description: PGP signature

Applied "ASoC: rsnd: fix semicolon.cocci warnings" to the asoc tree

[Mark Brown]

The patch

   ASoC: rsnd: fix semicolon.cocci warnings

has been applied to the asoc tree at

   git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git 

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.  

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark

>From 75f9e4adb56fbb8ffaab7d316f0c02df00e4b755 Mon Sep 17 00:00:00 2001
From: kbuild test robot 
Date: Fri, 21 Apr 2017 13:02:57 +0800
Subject: [PATCH] ASoC: rsnd: fix semicolon.cocci warnings

sound/soc/sh/rcar/adg.c:462:54-55: Unneeded semicolon

 Remove unneeded semicolon.

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

Signed-off-by: Fengguang Wu 
Acked-by: Kuninori Morimoto 
Signed-off-by: Mark Brown 
---
 sound/soc/sh/rcar/adg.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/sound/soc/sh/rcar/adg.c b/sound/soc/sh/rcar/adg.c
index 96fef91b480c..faa1a4f09766 100644
--- a/sound/soc/sh/rcar/adg.c
+++ b/sound/soc/sh/rcar/adg.c
@@ -459,7 +459,7 @@ static void rsnd_adg_get_clkout(struct rsnd_priv *priv,
 * ADG supports BRRA/BRRB output only
 * this means all clkout0/1/2/3 will be same rate
 */
-   prop = of_find_property(np, "clock-frequency", NULL);;
+   prop = of_find_property(np, "clock-frequency", NULL);
req_size = prop->length / sizeof(u32);
 
of_property_read_u32_array(np, "clock-frequency", req_rate, req_size);
-- 
2.11.0

Re: [PATCH 2/2] n2rng: Combine substrings for two messages in n2rng_probe()

[David Miller]

From: Herbert Xu 
Date: Fri, 21 Apr 2017 19:36:41 +0800

> On Wed, Apr 19, 2017 at 11:11:35AM +0200, SF Markus Elfring wrote:
>> From: Markus Elfring 
>> Date: Wed, 19 Apr 2017 10:50:04 +0200
>> 
>> The script "checkpatch.pl" pointed information out like the following.
>> 
>> WARNING: quoted string split across lines
>> 
>> Thus fix the affected source code places.
>> 
>> Signed-off-by: Markus Elfring 
> 
> This patch doesn't seem to add any value so I'm not taking it.
> 
> Please don't send patches based purely on a checkpatch complaint.

Thank you Herbert.

Re: [PATCH 2/2] n2rng: Combine substrings for two messages in n2rng_probe()

[Joe Perches]

On Fri, 2017-04-21 at 19:36 +0800, Herbert Xu wrote:
> On Wed, Apr 19, 2017 at 11:11:35AM +0200, SF Markus Elfring wrote:
> > From: Markus Elfring 
> > Date: Wed, 19 Apr 2017 10:50:04 +0200
> > 
> > The script "checkpatch.pl" pointed information out like the following.
> > 
> > WARNING: quoted string split across lines
> > 
> > Thus fix the affected source code places.
> > 
> > Signed-off-by: Markus Elfring 
> 
> This patch doesn't seem to add any value so I'm not taking it.

Your choice.

The general reason to merge strings is in CodingStyle

2) Breaking long lines and strings
[]
never break user-visible strings such as
printk messages, because that breaks the ability to grep for them.

Re: [PATCH 04/11] block: Improvements to bounce-buffer handling

[Ming Lei]

On Thu, Apr 20, 2017 at 1:38 PM, NeilBrown  wrote:
> Since commit 23688bf4f830 ("block: ensure to split after potentially
> bouncing a bio") blk_queue_bounce() is called *before*
> blk_queue_split().
> This means that:
>  1/ the comments blk_queue_split() about bounce buffers are
> irrelevant, and
>  2/ a very large bio (more than BIO_MAX_PAGES) will no longer be
> split before it arrives at blk_queue_bounce(), leading to the
> possibility that bio_clone_bioset() will fail and a NULL
> will be dereferenced.
>
> Separately, blk_queue_bounce() shouldn't use fs_bio_set as the bio
> being copied could be from the same set, and this could lead to a
> deadlock.
>
> So:
>  - allocate 2 private biosets for blk_queue_bounce, one for
>splitting enormous bios and one for cloning bios.
>  - add code to split a bio that exceeds BIO_MAX_PAGES.
>  - Fix up the comments in blk_queue_split()
>
> Signed-off-by: NeilBrown 
> ---
>  block/blk-merge.c |   14 --
>  block/bounce.c|   27 ++-
>  2 files changed, 30 insertions(+), 11 deletions(-)
>
> diff --git a/block/blk-merge.c b/block/blk-merge.c
> index d59074556703..51c84540d3bb 100644
> --- a/block/blk-merge.c
> +++ b/block/blk-merge.c
> @@ -117,17 +117,11 @@ static struct bio *blk_bio_segment_split(struct 
> request_queue *q,
>  * each holds at most BIO_MAX_PAGES bvecs because
>  * bio_clone() can fail to allocate big bvecs.
>  *
> -* It should have been better to apply the limit per
> -* request queue in which bio_clone() is involved,
> -* instead of globally. The biggest blocker is the
> -* bio_clone() in bio bounce.
> +* Those drivers which will need to use bio_clone()
> +* should tell us in some way.  For now, impose the
> +* BIO_MAX_PAGES limit on all queues.
>  *
> -* If bio is splitted by this reason, we should have
> -* allowed to continue bios merging, but don't do
> -* that now for making the change simple.
> -*
> -* TODO: deal with bio bounce's bio_clone() gracefully
> -* and convert the global limit into per-queue limit.
> +* TODO: handle users of bio_clone() differently.
>  */
> if (bvecs++ >= BIO_MAX_PAGES)
> goto split;
> diff --git a/block/bounce.c b/block/bounce.c
> index 1cb5dd3a5da1..51fb538b504d 100644
> --- a/block/bounce.c
> +++ b/block/bounce.c
> @@ -26,6 +26,7 @@
>  #define POOL_SIZE  64
>  #define ISA_POOL_SIZE  16
>
> +struct bio_set *bounce_bio_set, *bounce_bio_split;
>  static mempool_t *page_pool, *isa_page_pool;
>
>  #if defined(CONFIG_HIGHMEM) || defined(CONFIG_NEED_BOUNCE_POOL)
> @@ -40,6 +41,14 @@ static __init int init_emergency_pool(void)
> BUG_ON(!page_pool);
> pr_info("pool size: %d pages\n", POOL_SIZE);
>
> +   bounce_bio_set = bioset_create(BIO_POOL_SIZE, 0);
> +   BUG_ON(!bounce_bio_set);
> +   if (bioset_integrity_create(bounce_bio_set, BIO_POOL_SIZE))
> +   BUG_ON(1);
> +
> +   bounce_bio_split = bioset_create_nobvec(BIO_POOL_SIZE, 0);
> +   BUG_ON(!bounce_bio_split);
> +
> return 0;
>  }
>
> @@ -194,7 +203,23 @@ static void __blk_queue_bounce(struct request_queue *q, 
> struct bio **bio_orig,
>
> return;
>  bounce:
> -   bio = bio_clone_bioset(*bio_orig, GFP_NOIO, fs_bio_set);
> +   if (bio_segments(*bio_orig) > BIO_MAX_PAGES) {
> +   int cnt = 0;
> +   int sectors = 0;
> +   struct bio_vec bv;
> +   struct bvec_iter iter;
> +   bio_for_each_segment(bv, *bio_orig, iter) {

The two bio_for_each_segment()(one is in bio_segments()) can be merged to
one.

> +   if (cnt++ < BIO_MAX_PAGES)
> +   sectors += bv.bv_len >> 9;
> +   else
> +   break;
> +   }
> +   bio = bio_split(*bio_orig, sectors, GFP_NOIO, 
> bounce_bio_split);
> +   bio_chain(bio, *bio_orig);
> +   generic_make_request(*bio_orig);
> +   *bio_orig = bio;
> +   }
> +   bio = bio_clone_bioset(*bio_orig, GFP_NOIO, bounce_bio_set);
>
> bio_for_each_segment_all(to, bio, i) {
> struct page *page = to->bv_page;
>
>



Thanks,
Ming Lei

Re: [musl] Re: [PATCH v2 0/3] uapi glibc compat: fix musl libc compatibility

[Rich Felker]

On Fri, Apr 21, 2017 at 03:14:21PM +0200, Hauke Mehrtens wrote:
> 
> 
> On 04/20/2017 10:36 PM, David Miller wrote:
> > From: David Woodhouse 
> > Date: Thu, 20 Apr 2017 21:14:37 +0100
> > 
> >> I agree, except I don't think you're going far enough. Those "standard
> >> names" you mention... some of this stuff actually depends on __GLIBC__,
> >> and *that* isn't right either.
> > 
> > Yep, that's something that needs correcting.
> > 
> Should all libc implementations define __GLIBC__

Absolutely not.

Rich

[PATCH v2 11/17] IB/mlx4: Delete an unnecessary variable initialisation in mlx4_ib_add()

[SF Markus Elfring]

From: Markus Elfring 
Date: Fri, 21 Apr 2017 18:44:15 +0200

The local variable "new_counter_index" will be set to an appropriate pointer
a bit later. Thus omit the explicit initialisation at the beginning.

Signed-off-by: Markus Elfring 
---
 drivers/infiniband/hw/mlx4/main.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/infiniband/hw/mlx4/main.c 
b/drivers/infiniband/hw/mlx4/main.c
index a54e2f04929b..d08b9b154c97 100644
--- a/drivers/infiniband/hw/mlx4/main.c
+++ b/drivers/infiniband/hw/mlx4/main.c
@@ -2615,7 +2615,7 @@ static void *mlx4_ib_add(struct mlx4_dev *dev)
int num_req_counters;
int allocated;
u32 counter_index;
-   struct counter_index *new_counter_index = NULL;
+   struct counter_index *new_counter_index;
 
pr_info_once("%s", mlx4_ib_version);
 
-- 
2.12.2

[PATCH v2 12/17] IB/mlx4: Delete an unnecessary variable assignment in mlx4_ib_add()

[SF Markus Elfring]

From: Markus Elfring 
Date: Fri, 21 Apr 2017 18:52:03 +0200

Delete an assignment for the local variable "num_ports" at the beginning
because it was initialised with the same value.

Signed-off-by: Markus Elfring 
Reviewed-by: Majd Dibbiny 
---
 drivers/infiniband/hw/mlx4/main.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/infiniband/hw/mlx4/main.c 
b/drivers/infiniband/hw/mlx4/main.c
index d08b9b154c97..4eb2466530dc 100644
--- a/drivers/infiniband/hw/mlx4/main.c
+++ b/drivers/infiniband/hw/mlx4/main.c
@@ -2618,8 +2618,6 @@ static void *mlx4_ib_add(struct mlx4_dev *dev)
struct counter_index *new_counter_index;
 
pr_info_once("%s", mlx4_ib_version);
-
-   num_ports = 0;
mlx4_foreach_ib_transport_port(i, dev)
num_ports++;
 
-- 
2.12.2

Re: [PATCH 2/2] ASoC: codec: wm8960: Relax bit clock computation when using PLL

[Arnd Bergmann]

On Fri, Apr 21, 2017 at 3:07 PM, Daniel Baluta  wrote:
> Bitclk is derived from sysclk using bclk_divs.
> Sysclk can be derived in two ways:
> (1) directly from MLCK
> (2) MCLK via PLL
>
> Commit 3c01b9ee2ab9d0d ("ASoC: codec: wm8960: Relax bit clock
> computation")
> relaxed bitclk computation when sysclk is directly derived from MCLK.
>
> Lets do the same thing when sysclk is derived via PLL.
>
> Signed-off-by: Daniel Baluta 
> ---
> Here, I forced the following harmless initialization:
>
> *sysclk_idx = *dac_idx = *bclk_idx = -1;
>
> otherwise I would trigger a gcc false positive warning:
>
> sound/soc/codecs/wm8960.c: In function 'wm8960_configure_clocking':
> sound/soc/codecs/wm8960.c:810:46: warning: 'j' may be used uninitialized
> in this function [-Wmaybe-uninitialized]
>   snd_soc_update_bits(codec, WM8960_CLOCK1, 0x7 << 6, j << 6);
> ~~^~~~
> sound/soc/codecs/wm8960.c:806:44: warning: 'i' may be used uninitialized
> in this function [-Wmaybe-uninitialized]
> snd_soc_update_bits(codec, WM8960_CLOCK1, 3 << 1, i << 1);
>   ~~^~~~

I saw the same warning earlier, but it was gone after the rework
I posted the other day. Please try if that works for you as well, I think
that would be better than a bogus initialization.

   Arnd

Re: [PATCH v1] net: phy: fix auto-negotiation stall due to unavailable interrupt

[Alexander Kochetkov]

> 21 апр. 2017 г., в 17:18, Roger Quadros  написал(а):
> 
> I think the following commit broke functionality with interrupt driven PHYs
> 3c293f4e08b5 ("net: phy: Trigger state machine on state change and not 
> polling.")

Probably this one[1] broke, according to Alexandre’s commit[2].
And it was since Nov 16 2015. But it was hidden by some other commits.

For Roger problem became visible after 3c293f4e08b5 ("net: phy:
Trigger state machine on state change and not polling.»),

For my problem became visible after 529ed1275263 ("net: phy: phy drivers
should not set SUPPORTED_[Asym_]Pause»). As commit 529ed1275263 
removed SUPPORTED_Pause flag from PHY advertising property and
genphy_config_aneg() began to skip PHY auto-negotiation.

Alexander.

[1] Fixes: 321beec5047a (net: phy: Use interrupts when available in NOLINK 
state)
 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=321beec5047af83db90c88114b7e664b156f49fe
[2] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=99f81afc139c6edd14d77a91ee91685a414a1c66

Re: time: hang due to timer_create/timer_settime

[Thomas Gleixner]

On Fri, 21 Apr 2017, Thomas Gleixner wrote:
> On Fri, 21 Apr 2017, Andrey Konovalov wrote:
> > Hi,
> > 
> > I've got the following error report while fuzzing the kernel with syzkaller.
> > 
> > On commit 4f7d029b9bf009fbee76bb10c0c4351a1870d2f3 (4.11-rc7).
> > 
> > A reproducer and .config are attached.
> > 
> > The program hangs the kernel.
> >  lock_acquire+0x22d/0x560 kernel/locking/lockdep.c:3762
> >  __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]
> >  _raw_spin_lock_irqsave+0xc4/0x110 kernel/locking/spinlock.c:159
> >  alarmtimer_fired+0x169/0x7a0 kernel/time/alarmtimer.c:189
> >  __run_hrtimer kernel/time/hrtimer.c:1212 [inline]
> >  __hrtimer_run_queues+0x350/0xe50 kernel/time/hrtimer.c:1276
> >  hrtimer_interrupt+0x1ab/0x5c0 kernel/time/hrtimer.c:1310
> >  local_apic_timer_interrupt+0x6f/0xe0 arch/x86/kernel/apic/apic.c:937
> >  smp_apic_timer_interrupt+0x71/0xa0 arch/x86/kernel/apic/apic.c:961
> >  apic_timer_interrupt+0x93/0xa0 arch/x86/entry/entry_64.S:487
> 
> Right. That lacks the protection which we have in the other posix
> timers. I'll have a look.

But what's even more alarming is:

  (*(uint64_t*)0x20aedfe0 = (uint64_t)0x0);
  (*(uint64_t*)0x20aedfe8 = (uint64_t)0x989680);
  (*(uint64_t*)0x20aedff0 = (uint64_t)0x80077359400);
  (*(uint64_t*)0x20aedff8 = (uint64_t)0x0);
  r[11] = execute_syscall(__NR_timer_settime, r[6], 0x0ul, 0x20aedfe0ul,
  0x20715fe0ul, 0, 0, 0, 0, 0);

0x20aedfe0 is the itimerspec handed to timer_create(). So

  its->it_interval.tv_sec = 0;
  its->it_interval.tv_nsec = 0x989680;

  its->it_value.tv_sec = 0x80077359400;
  its->it_value.tv_nsec = 0;

it_value.tv_sec is 1.82795e+10 YEARS into the future.

How does that timer fire in the first place? 

Thanks,

tglx

Re: time: hang due to timer_create/timer_settime

[Thomas Gleixner]

On Fri, 21 Apr 2017, Andrey Konovalov wrote:
> Hi,
> 
> I've got the following error report while fuzzing the kernel with syzkaller.
> 
> On commit 4f7d029b9bf009fbee76bb10c0c4351a1870d2f3 (4.11-rc7).
> 
> A reproducer and .config are attached.
> 
> The program hangs the kernel.
>  lock_acquire+0x22d/0x560 kernel/locking/lockdep.c:3762
>  __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]
>  _raw_spin_lock_irqsave+0xc4/0x110 kernel/locking/spinlock.c:159
>  alarmtimer_fired+0x169/0x7a0 kernel/time/alarmtimer.c:189
>  __run_hrtimer kernel/time/hrtimer.c:1212 [inline]
>  __hrtimer_run_queues+0x350/0xe50 kernel/time/hrtimer.c:1276
>  hrtimer_interrupt+0x1ab/0x5c0 kernel/time/hrtimer.c:1310
>  local_apic_timer_interrupt+0x6f/0xe0 arch/x86/kernel/apic/apic.c:937
>  smp_apic_timer_interrupt+0x71/0xa0 arch/x86/kernel/apic/apic.c:961
>  apic_timer_interrupt+0x93/0xa0 arch/x86/entry/entry_64.S:487

Right. That lacks the protection which we have in the other posix
timers. I'll have a look.

Thanks,

tglx

Re: [PATCH] PCI: don't allow unbinding host controllers that aren't prepared

[Bjorn Helgaas]

On Thu, Mar 30, 2017 at 06:12:03PM -0700, Brian Norris wrote:
> Many PCI host controller drivers aren't prepared to have their devices
> unbound from them forcefully (e.g., through /sys/...//unbind),
> as they don't provide any driver .remove callback, where they'd detach
> the root bus, release resources, etc. Keeping the driver built in (i.e.,
> not a loadable module) is not enough; and providing no .remove callback
> just means we don't do any teardown.
> 
> To rule out the possibility of unbinding a device via sysfs, we need to
> set the ".suppress_bind_attrs" field.
> 
> I found the suspect drivers via the following search:
> 
>   git grep -l platform_driver $(git grep -L -e '\.remove' -e 
> suppress_bind_attrs drivers/pci/)
> 
> Then I inspected them to ensure that
> (a) they set up a PCI bus in their probe() and
> (b) they don't have a remove() callback for undoing the setup
> 
> I excluded drivers/pci/host/pcie-rockchip.c, because I've implemented
> remove() support elsewhere [1].
> 
> [1] https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1349576.html
> [PATCH v2 3/5] PCI: rockchip: add remove() support
> 
> Suggested-by: Bjorn Helgaas 
> Signed-off-by: Brian Norris 

Applied to pci/remove for v4.12, thanks, Brian!

> ---
> Not tested, other than to compile a few of these.
> 
>  drivers/pci/dwc/pci-imx6.c | 1 +
>  drivers/pci/dwc/pci-layerscape.c   | 1 +
>  drivers/pci/dwc/pcie-armada8k.c| 1 +
>  drivers/pci/dwc/pcie-artpec6.c | 1 +
>  drivers/pci/dwc/pcie-designware-plat.c | 1 +
>  drivers/pci/dwc/pcie-hisi.c| 2 ++
>  drivers/pci/dwc/pcie-spear13xx.c   | 1 +
>  drivers/pci/host/pci-ftpci100.c| 1 +
>  drivers/pci/host/pci-host-generic.c| 1 +
>  drivers/pci/host/pci-thunder-ecam.c| 1 +
>  drivers/pci/host/pci-thunder-pem.c | 1 +
>  drivers/pci/host/pci-versatile.c   | 1 +
>  drivers/pci/host/pci-xgene.c   | 1 +
>  13 files changed, 14 insertions(+)
> 
> diff --git a/drivers/pci/dwc/pci-imx6.c b/drivers/pci/dwc/pci-imx6.c
> index 801e46cd266d..f85a063e9964 100644
> --- a/drivers/pci/dwc/pci-imx6.c
> +++ b/drivers/pci/dwc/pci-imx6.c
> @@ -725,6 +725,7 @@ static struct platform_driver imx6_pcie_driver = {
>   .driver = {
>   .name   = "imx6q-pcie",
>   .of_match_table = imx6_pcie_of_match,
> + .suppress_bind_attrs = true,
>   },
>   .shutdown = imx6_pcie_shutdown,
>  };
> diff --git a/drivers/pci/dwc/pci-layerscape.c 
> b/drivers/pci/dwc/pci-layerscape.c
> index c32e392a0ae6..880f345bff43 100644
> --- a/drivers/pci/dwc/pci-layerscape.c
> +++ b/drivers/pci/dwc/pci-layerscape.c
> @@ -305,6 +305,7 @@ static struct platform_driver ls_pcie_driver = {
>   .driver = {
>   .name = "layerscape-pcie",
>   .of_match_table = ls_pcie_of_match,
> + .suppress_bind_attrs = true,
>   },
>  };
>  builtin_platform_driver_probe(ls_pcie_driver, ls_pcie_probe);
> diff --git a/drivers/pci/dwc/pcie-armada8k.c b/drivers/pci/dwc/pcie-armada8k.c
> index f110e3b24a26..9d8f7e4db5df 100644
> --- a/drivers/pci/dwc/pcie-armada8k.c
> +++ b/drivers/pci/dwc/pcie-armada8k.c
> @@ -262,6 +262,7 @@ static struct platform_driver armada8k_pcie_driver = {
>   .driver = {
>   .name   = "armada8k-pcie",
>   .of_match_table = of_match_ptr(armada8k_pcie_of_match),
> + .suppress_bind_attrs = true,
>   },
>  };
>  builtin_platform_driver(armada8k_pcie_driver);
> diff --git a/drivers/pci/dwc/pcie-artpec6.c b/drivers/pci/dwc/pcie-artpec6.c
> index fcd3ef845883..7a86d4b4dcc1 100644
> --- a/drivers/pci/dwc/pcie-artpec6.c
> +++ b/drivers/pci/dwc/pcie-artpec6.c
> @@ -290,6 +290,7 @@ static struct platform_driver artpec6_pcie_driver = {
>   .driver = {
>   .name   = "artpec6-pcie",
>   .of_match_table = artpec6_pcie_of_match,
> + .suppress_bind_attrs = true,
>   },
>  };
>  builtin_platform_driver(artpec6_pcie_driver);
> diff --git a/drivers/pci/dwc/pcie-designware-plat.c 
> b/drivers/pci/dwc/pcie-designware-plat.c
> index b6c832ba39dd..bdb75a5758ae 100644
> --- a/drivers/pci/dwc/pcie-designware-plat.c
> +++ b/drivers/pci/dwc/pcie-designware-plat.c
> @@ -129,6 +129,7 @@ static struct platform_driver dw_plat_pcie_driver = {
>   .driver = {
>   .name   = "dw-pcie",
>   .of_match_table = dw_plat_pcie_of_match,
> + .suppress_bind_attrs = true,
>   },
>   .probe = dw_plat_pcie_probe,
>  };
> diff --git a/drivers/pci/dwc/pcie-hisi.c b/drivers/pci/dwc/pcie-hisi.c
> index fd66a3199db7..088ed5e4e46b 100644
> --- a/drivers/pci/dwc/pcie-hisi.c
> +++ b/drivers/pci/dwc/pcie-hisi.c
> @@ -334,6 +334,7 @@ static struct platform_driver hisi_pcie_driver = {
>   .driver = {
>  .name = "hisi-pcie",
>  .of_match_table = hisi_pcie_of_match,
> +.suppress_bind_attrs 

Re: [PATCH 0/5] v2: block subsystem refcounter conversions

[Kees Cook]

On Fri, Apr 21, 2017 at 3:55 AM, Reshetova, Elena
 wrote:
> On Thu, Apr 20, 2017 at 11:33 AM, Eric Biggers  wrote:
>> Of course, having extra checks behind a debug option is fine.  But they 
>> should
>> not be part of the base feature; the base feature should just be mitigation 
>> of
>> reference count *overflows*.  It would be nice to do more, of course; but 
>> when
>> the extra stuff prevents people from using refcount_t for performance 
>> reasons,
>> it defeats the point of the feature in the first place.
>
> Sure, but as I said above, I think the smaller tricks and fixes won't be 
> convincing enough,
> so their value is questionable.
>
>> I strongly encourage anyone who has been involved in refcount_t to experiment
>> with removing a reference count decrement somewhere in their kernel, then 
>> trying
>> to exploit it to gain code execution.  If you don't know what you're trying 
>> to
>> protect against, you will not know which defences work and which don't.
>
> Well, we had successful CVEs and even exploits on this in the past.
> @Kees, do you store a list of them in the project?

Here are two from last year:
http://perception-point.io/2016/01/14/analysis-and-exploitation-of-a-linux-kernel-vulnerability-cve-2016-0728/
http://cyseclabs.com/page?n=02012016

I don't disagree with Eric on the threat model: the primary concern
for reference count protection is the overflow condition. Detecting a
prior use-after-free is certainly nice to have, but the more important
case is the initial overflow.

How about we introduce something like CONFIG_HAVE_ARCH_FAST_REFCOUNT_T
for per-arch implementations and CONFIG_FAST_REFCOUNT_T that trades
coverage for speed, and checks only the overflow condition. This gets
us the critical coverage without the changes in performance. This is
basically what PaX/grsecurity already did: there is a tiny change to
the atomic inc functions to detect the wrap.

-Kees

-- 
Kees Cook
Pixel Security

Re: [PATCHv4 00/12] Ion cleanup in preparation for moving out of staging

[Sumit Semwal]

Hi Laura,

Thanks much for this series!

On 18 April 2017 at 23:57, Laura Abbott  wrote:
> Hi,
>
> This is v4 of the series to cleanup to Ion. Greg took some of the patches
> that weren't CMA related already. There was a minor bisectability problem
> with the CMA APIs so this is a new version to address that. I also
> addressed some minor comments on the patch to collapse header files.

For the series, please feel free to apply my
Acked-by: Sumit Semwal 

>
> Thanks,
> Laura
>
> Laura Abbott (12):
>   cma: Store a name in the cma structure
>   cma: Introduce cma_for_each_area
>   staging: android: ion: Use CMA APIs directly
>   staging: android: ion: Stop butchering the DMA address
>   staging: android: ion: Break the ABI in the name of forward progress
>   staging: android: ion: Get rid of ion_phys_addr_t
>   staging: android: ion: Collapse internal header files
>   staging: android: ion: Rework heap registration/enumeration
>   staging: android: ion: Drop ion_map_kernel interface
>   staging: android: ion: Remove ion_handle and ion_client
>   staging: android: ion: Set query return value
>   staging/android: Update Ion TODO list
>
>  arch/powerpc/kvm/book3s_hv_builtin.c|   3 +-
>  drivers/base/dma-contiguous.c   |   5 +-
>  drivers/staging/android/TODO|  21 +-
>  drivers/staging/android/ion/Kconfig |  32 +
>  drivers/staging/android/ion/Makefile|  11 +-
>  drivers/staging/android/ion/compat_ion.c| 152 -
>  drivers/staging/android/ion/compat_ion.h|  29 -
>  drivers/staging/android/ion/ion-ioctl.c |  55 +-
>  drivers/staging/android/ion/ion.c   | 812 
> ++--
>  drivers/staging/android/ion/ion.h   | 386 ---
>  drivers/staging/android/ion/ion_carveout_heap.c |  21 +-
>  drivers/staging/android/ion/ion_chunk_heap.c|  16 +-
>  drivers/staging/android/ion/ion_cma_heap.c  | 120 ++--
>  drivers/staging/android/ion/ion_heap.c  |  68 --
>  drivers/staging/android/ion/ion_page_pool.c |   3 +-
>  drivers/staging/android/ion/ion_priv.h  | 453 -
>  drivers/staging/android/ion/ion_system_heap.c   |  39 +-
>  drivers/staging/android/uapi/ion.h  |  36 +-
>  include/linux/cma.h |   6 +-
>  mm/cma.c|  31 +-
>  mm/cma.h|   1 +
>  mm/cma_debug.c  |   2 +-
>  22 files changed, 524 insertions(+), 1778 deletions(-)
>  delete mode 100644 drivers/staging/android/ion/compat_ion.c
>  delete mode 100644 drivers/staging/android/ion/compat_ion.h
>  delete mode 100644 drivers/staging/android/ion/ion_priv.h
>
> --
> 2.7.4
>



-- 
Thanks and regards,

Sumit Semwal
Linaro Mobile Group - Kernel Team Lead
Linaro.org │ Open source software for ARM SoCs

Re: [PATCH net-next] net: dsa: LAN9303: add I2C dependency

[David Miller]

From: Arnd Bergmann 
Date: Fri, 21 Apr 2017 18:22:40 +0200

> With CONFIG_I2C=m and NET_DSA_SMSC_LAN9303=y, we run into a link error:
> 
> drivers/base/regmap/regmap-i2c.o: In function `regmap_smbus_byte_reg_read':
> regmap-i2c.c:(.text.regmap_smbus_byte_reg_read+0x18): undefined reference to 
> `i2c_smbus_read_byte_data'
> drivers/base/regmap/regmap-i2c.o: In function `regmap_smbus_byte_reg_write':
> regmap-i2c.c:(.text.regmap_smbus_byte_reg_write+0x18): undefined reference to 
> `i2c_smbus_write_byte_data'
> drivers/base/regmap/regmap-i2c.o: In function `regmap_smbus_word_reg_read':
> regmap-i2c.c:(.text.regmap_smbus_word_reg_read+0x18): undefined reference to 
> `i2c_smbus_read_word_data'
> drivers/base/regmap/regmap-i2c.o: In function 
> `regmap_smbus_word_read_swapped':
> regmap-i2c.c:(.text.regmap_smbus_word_read_swapped+0x18): undefined reference 
> to `i2c_smbus_read_word_data'
> drivers/base/regmap/regmap-i2c.o: In function 
> `regmap_smbus_word_write_swapped':
> 
> This adds a Kconfig dependency to avoid the broken configuration.
> 
> Fixes: be4e119f9914 ("net: dsa: LAN9303: add I2C managed mode support")
> Signed-off-by: Arnd Bergmann 

Applied, thanks.

Re: hwmon: (adt7475) set start bit in probe

[Guenter Roeck]

On Sat, Apr 22, 2017 at 07:08:09AM +1200, Chris Packham wrote:
> The ADT7475 and ADT7476 have the STRT bit cleared by default[1]. Before any
> monitoring activities the STRT bit needs to be set. Logically this needs
> to happen before any of the sensors are read so the probe() function
> seems the best place for it.
> 
> [1] - https://www.onsemi.com/pub/Collateral/ADT7475-D.PDF
> 
> Signed-off-by: Chris Packham 

Applied.

Thanks,
Guenter

> ---
>  drivers/hwmon/adt7475.c | 13 +
>  1 file changed, 13 insertions(+)
> 
> diff --git a/drivers/hwmon/adt7475.c b/drivers/hwmon/adt7475.c
> index fcfa48222145..c803e3c5fcd4 100644
> --- a/drivers/hwmon/adt7475.c
> +++ b/drivers/hwmon/adt7475.c
> @@ -59,6 +59,8 @@
>  #define REG_VENDID   0x3E
>  #define REG_DEVID2   0x3F
>  
> +#define REG_CONFIG1  0x40
> +
>  #define REG_STATUS1  0x41
>  #define REG_STATUS2  0x42
>  
> @@ -1371,6 +1373,17 @@ static int adt7475_probe(struct i2c_client *client,
>   for (i = 0; i < ADT7475_PWM_COUNT; i++)
>   adt7475_read_pwm(client, i);
>  
> + /* Start monitoring */
> + switch (chip) {
> + case adt7475:
> + case adt7476:
> + i2c_smbus_write_byte_data(client, REG_CONFIG1,
> +   adt7475_read(REG_CONFIG1) | 0x01);
> + break;
> + default:
> + break;
> + }
> +
>   ret = sysfs_create_group(>dev.kobj, _attr_group);
>   if (ret)
>   return ret;

Re: [RFC PATCH 0/2] kbuild: use relative path from $(srctree) instead of __FILE__

[Geert Uytterhoeven]

Hi Yamada-san,

On Fri, Apr 21, 2017 at 9:03 PM, Masahiro Yamada
 wrote:
> Kbuild works in objtree, not in srctree.  So, __FILE__ is prefixed
> with $(srctree)/ for out-of-tree build.
>
> It would be nice to see the same log regardless
> in-tree, or out-of-tree build.
>
> 1/2 adds a new macro KBUILD_FILE.  This points the relative path
> of the file we are building.  This is intended to replace __FILE__.
>
> 2/2 replaces __FILE__ in bug.h as an example.  This will improve
> the output of WARN_ON() etc.

I haven't tried your series, but I love the idea behind it!
I never liked exposing full file paths in kernel images.

Thanks!

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: [PATCH net] ip6mr: fix notification device destruction

[Nikolay Aleksandrov]

On 21/04/17 22:36, David Miller wrote:
> From: Nikolay Aleksandrov 
> Date: Fri, 21 Apr 2017 21:30:42 +0300
> 
>> On 21/04/17 20:42, Nikolay Aleksandrov wrote:
>>> Andrey Konovalov reported a BUG caused by the ip6mr code which is caused
>>> because we call unregister_netdevice_many for a device that is already
>>> being destroyed. In IPv4's ipmr that has been resolved by two commits
>>> long time ago by introducing the "notify" parameter to the delete
>>> function and avoiding the unregister when called from a notifier, so
>>> let's do the same for ip6mr.
>  ...
>> +CC LKML and Linus
> 
> Applied, thanks Nikolay and thanks Andrey for the report and testing.
> 
> Nikolay, how far does this bug go back?
> 

Good question, AFAICS since ip6mr exists because it was copied from ipmr:
commit 7bc570c8b4f7
Author: YOSHIFUJI Hideaki 
Date:   Thu Apr 3 09:22:53 2008 +0900

[IPV6] MROUTE: Support multicast forwarding.

[GIT PULL] 4.11 nfsd bugfix

[J. Bruce Fields]

Please pull

  git://linux-nfs.org/~bfields/linux.git tags/nfsd-4.11-2

Fix a 4.11 regression that triggers a BUG() on an attempt to use an
unsupported NFSv4 compound op.

(Apologies for what's probably a last-minute fix.  I was hoping to have
a few more ready to roll up with it, but they'll probably have to wait
till next week.)

--b.

Olga Kornievskaia (1):
  nfsd: fix oops on unsupported operation

 fs/nfsd/nfs4proc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Re: [PATCH 0/5] v2: block subsystem refcounter conversions

[James Bottomley]

On Fri, 2017-04-21 at 13:22 -0700, Kees Cook wrote:
> On Fri, Apr 21, 2017 at 12:55 PM, Eric Biggers  
> wrote:
> > > > Of course, having extra checks behind a debug option is fine. 
> > > >  But they should not be part of the base feature; the base 
> > > > feature should just be mitigation of reference count
> > > > *overflows*.  It would be nice to do more, of
> > > > course; but when the extra stuff prevents people from using 
> > > > refcount_t for performance reasons, it defeats the point of the
> > > > feature in the first place.
> > > 
> > > Sure, but as I said above, I think the smaller tricks and fixes 
> > > won't be convincing enough, so their value is questionable.
> > 
> > This makes no sense, as the main point of the feature is supposed 
> > to be the security improvement.  As-is, the extra debugging stuff 
> > is actually preventing the security improvement from being adopted,
> > which is unfortunate.
> 
> We've been trying to handle the conflicting desires of those wanting
> very precise refcounting implementation and gaining the security
> protections. Ultimately, the best way forward seemed to be to first
> land the precise refcounting implementation, and start conversion
> until we ran into concerns over performance. Now, since we're here, 
> we can move forward with getting a fast implementation that provides 
> the desired security protections without too greatly messing with the
> refcount API.

But that's not what it really looks like.  What it looks like is
someone came up with a new API and is now intent on forcing it through
the kernel in about 500 patches using security as the hammer.

If we were really concerned about security first, we'd have fixed the
atomic overflow problem in the atomics and then built the precise
refcounting on that and tried to persuade people of the merits.

Why can't we still do this?  It looks like the overflow protection will
add only a couple of cycles to the atomics.  We can move the current
version to an unchecked variant which can be used either in truly
performance critical regions with no security implications or if
someone really needs the atomic to overflow.  From my point of view it
would give us the 90% case (security) and stop this endless argument
over the fast paths.  Subsystems which have already moved to refcount
would stay there and the rest get to evaluate a migration on the merits
of the operational utility.

James

[for-next][PATCH 21/33] ftrace: Add helper function ftrace_hash_move_and_update_ops()

[Steven Rostedt]

From: "Steven Rostedt (VMware)" 

The processes of updating a ops filter_hash is a bit complex, and requires
setting up an old hash to perform the update. This is done exactly the same
in two locations for the same reasons. Create a helper function that does it
in one place.

Signed-off-by: Steven Rostedt (VMware) 
---
 kernel/trace/ftrace.c | 105 +-
 1 file changed, 53 insertions(+), 52 deletions(-)

diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c
index f7fcab8f3aa1..5c8d8eea9e7c 100644
--- a/kernel/trace/ftrace.c
+++ b/kernel/trace/ftrace.c
@@ -3674,6 +3674,56 @@ ftrace_match_records(struct ftrace_hash *hash, char 
*buff, int len)
return match_records(hash, buff, len, NULL);
 }
 
+static void ftrace_ops_update_code(struct ftrace_ops *ops,
+  struct ftrace_ops_hash *old_hash)
+{
+   struct ftrace_ops *op;
+
+   if (!ftrace_enabled)
+   return;
+
+   if (ops->flags & FTRACE_OPS_FL_ENABLED) {
+   ftrace_run_modify_code(ops, FTRACE_UPDATE_CALLS, old_hash);
+   return;
+   }
+
+   /*
+* If this is the shared global_ops filter, then we need to
+* check if there is another ops that shares it, is enabled.
+* If so, we still need to run the modify code.
+*/
+   if (ops->func_hash != _ops.local_hash)
+   return;
+
+   do_for_each_ftrace_op(op, ftrace_ops_list) {
+   if (op->func_hash == _ops.local_hash &&
+   op->flags & FTRACE_OPS_FL_ENABLED) {
+   ftrace_run_modify_code(op, FTRACE_UPDATE_CALLS, 
old_hash);
+   /* Only need to do this once */
+   return;
+   }
+   } while_for_each_ftrace_op(op);
+}
+
+static int ftrace_hash_move_and_update_ops(struct ftrace_ops *ops,
+  struct ftrace_hash **orig_hash,
+  struct ftrace_hash *hash,
+  int enable)
+{
+   struct ftrace_ops_hash old_hash_ops;
+   struct ftrace_hash *old_hash;
+   int ret;
+
+   old_hash = *orig_hash;
+   old_hash_ops.filter_hash = ops->func_hash->filter_hash;
+   old_hash_ops.notrace_hash = ops->func_hash->notrace_hash;
+   ret = ftrace_hash_move(ops, enable, orig_hash, hash);
+   if (!ret) {
+   ftrace_ops_update_code(ops, _hash_ops);
+   free_ftrace_hash_rcu(old_hash);
+   }
+   return ret;
+}
 
 /*
  * We register the module command as a template to show others how
@@ -4306,44 +4356,11 @@ ftrace_match_addr(struct ftrace_hash *hash, unsigned 
long ip, int remove)
return add_hash_entry(hash, ip);
 }
 
-static void ftrace_ops_update_code(struct ftrace_ops *ops,
-  struct ftrace_ops_hash *old_hash)
-{
-   struct ftrace_ops *op;
-
-   if (!ftrace_enabled)
-   return;
-
-   if (ops->flags & FTRACE_OPS_FL_ENABLED) {
-   ftrace_run_modify_code(ops, FTRACE_UPDATE_CALLS, old_hash);
-   return;
-   }
-
-   /*
-* If this is the shared global_ops filter, then we need to
-* check if there is another ops that shares it, is enabled.
-* If so, we still need to run the modify code.
-*/
-   if (ops->func_hash != _ops.local_hash)
-   return;
-
-   do_for_each_ftrace_op(op, ftrace_ops_list) {
-   if (op->func_hash == _ops.local_hash &&
-   op->flags & FTRACE_OPS_FL_ENABLED) {
-   ftrace_run_modify_code(op, FTRACE_UPDATE_CALLS, 
old_hash);
-   /* Only need to do this once */
-   return;
-   }
-   } while_for_each_ftrace_op(op);
-}
-
 static int
 ftrace_set_hash(struct ftrace_ops *ops, unsigned char *buf, int len,
unsigned long ip, int remove, int reset, int enable)
 {
struct ftrace_hash **orig_hash;
-   struct ftrace_ops_hash old_hash_ops;
-   struct ftrace_hash *old_hash;
struct ftrace_hash *hash;
int ret;
 
@@ -4378,14 +4395,7 @@ ftrace_set_hash(struct ftrace_ops *ops, unsigned char 
*buf, int len,
}
 
mutex_lock(_lock);
-   old_hash = *orig_hash;
-   old_hash_ops.filter_hash = ops->func_hash->filter_hash;
-   old_hash_ops.notrace_hash = ops->func_hash->notrace_hash;
-   ret = ftrace_hash_move(ops, enable, orig_hash, hash);
-   if (!ret) {
-   ftrace_ops_update_code(ops, _hash_ops);
-   free_ftrace_hash_rcu(old_hash);
-   }
+   ret = ftrace_hash_move_and_update_ops(ops, orig_hash, hash, enable);
mutex_unlock(_lock);
 
  out_regex_unlock:
@@ -4624,10 +4634,8 @@ static void __init set_ftrace_early_filters(void)
 int ftrace_regex_release(struct inode *inode, struct file 

[for-next][PATCH 20/33] ftrace: Remove data field from ftrace_func_probe structure

[Steven Rostedt]

From: "Steven Rostedt (VMware)" 

No users of the function probes uses the data field anymore. Remove it, and
change the init function to take a void *data parameter instead of a
void **data, because the init will just get the data that the registering
function was received, and there's no state after it is called.

The other functions for ftrace_probe_ops still take the data parameter, but
it will currently only be passed NULL. It will stay as a parameter for
future data to be passed to these functions.

Signed-off-by: Steven Rostedt (VMware) 
---
 kernel/trace/ftrace.c  | 11 ---
 kernel/trace/trace.c   |  4 ++--
 kernel/trace/trace.h   |  2 +-
 kernel/trace/trace_events.c|  5 ++---
 kernel/trace/trace_functions.c |  4 ++--
 5 files changed, 11 insertions(+), 15 deletions(-)

diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c
index 15f910a03822..f7fcab8f3aa1 100644
--- a/kernel/trace/ftrace.c
+++ b/kernel/trace/ftrace.c
@@ -1102,7 +1102,6 @@ struct ftrace_func_probe {
struct hlist_node   node;
struct ftrace_probe_ops *ops;
unsigned long   ip;
-   void*data;
struct list_headfree_list;
 };
 
@@ -3152,7 +3151,7 @@ t_hash_show(struct seq_file *m, struct ftrace_iterator 
*iter)
return -EIO;
 
if (rec->ops->print)
-   return rec->ops->print(m, rec->ip, rec->ops, rec->data);
+   return rec->ops->print(m, rec->ip, rec->ops, NULL);
 
seq_printf(m, "%ps:%ps\n", (void *)rec->ip, (void *)rec->ops->func);
 
@@ -3735,7 +3734,7 @@ static void function_trace_probe_call(unsigned long ip, 
unsigned long parent_ip,
preempt_disable_notrace();
hlist_for_each_entry_rcu_notrace(entry, hhd, node) {
if (entry->ip == ip)
-   entry->ops->func(ip, parent_ip, entry->ops, 
>data);
+   entry->ops->func(ip, parent_ip, entry->ops, NULL);
}
preempt_enable_notrace();
 }
@@ -3800,7 +3799,7 @@ static bool __disable_ftrace_function_probe(void)
 static void ftrace_free_entry(struct ftrace_func_probe *entry)
 {
if (entry->ops->free)
-   entry->ops->free(entry->ops, entry->ip, >data);
+   entry->ops->free(entry->ops, entry->ip, NULL);
kfree(entry);
 }
 
@@ -4007,15 +4006,13 @@ register_ftrace_function_probe(char *glob, struct 
ftrace_probe_ops *ops,
 
count++;
 
-   entry->data = data;
-
/*
 * The caller might want to do something special
 * for each function we find. We call the callback
 * to give the caller an opportunity to do so.
 */
if (ops->init) {
-   if (ops->init(ops, rec->ip, >data) < 0) {
+   if (ops->init(ops, rec->ip, data) < 0) {
/* caller does not like this func */
kfree(entry);
continue;
diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
index 7febeb823c62..7a4d578d8887 100644
--- a/kernel/trace/trace.c
+++ b/kernel/trace/trace.c
@@ -6786,11 +6786,11 @@ ftrace_snapshot_print(struct seq_file *m, unsigned long 
ip,
 
 static int
 ftrace_snapshot_init(struct ftrace_probe_ops *ops, unsigned long ip,
-void **data)
+void *data)
 {
struct ftrace_func_mapper *mapper = ops->private_data;
 
-   return ftrace_func_mapper_add_ip(mapper, ip, *data);
+   return ftrace_func_mapper_add_ip(mapper, ip, data);
 }
 
 static void
diff --git a/kernel/trace/trace.h b/kernel/trace/trace.h
index 376d5a798489..86aa5aba 100644
--- a/kernel/trace/trace.h
+++ b/kernel/trace/trace.h
@@ -937,7 +937,7 @@ struct ftrace_probe_ops {
struct ftrace_probe_ops *ops,
void **data);
int (*init)(struct ftrace_probe_ops *ops,
-   unsigned long ip, void **data);
+   unsigned long ip, void *data);
void(*free)(struct ftrace_probe_ops *ops,
unsigned long ip, void **data);
int (*print)(struct seq_file *m,
diff --git a/kernel/trace/trace_events.c b/kernel/trace/trace_events.c
index ee308312fe87..37902107c44f 100644
--- a/kernel/trace/trace_events.c
+++ b/kernel/trace/trace_events.c
@@ -2543,11 +2543,10 @@ event_enable_print(struct seq_file *m, unsigned long ip,
 
 static int
 event_enable_init(struct ftrace_probe_ops *ops, unsigned long ip,
- void **_data)
+ void *_data)
 {
struct ftrace_func_mapper *mapper = ops->private_data;
-   struct event_probe_data **pdata = (struct event_probe_data **)_data;
-

Re: [PATCH] drm: fourcc byteorder: brings header file comments in line with reality.

[Gerd Hoffmann]

  Hi,

> > My personal opinion is that formats in drm_fourcc.h should be 
> > independent of the CPU byte order and the function 
> > drm_mode_legacy_fb_format() and drivers depending on that incorrect 
> > assumption be fixed instead.
> 
> The problem is this isn't a kernel-internal thing any more.  With the
> addition of the ADDFB2 ioctl the fourcc codes became part of the
> kernel/userspace abi ...

Ok, added some printk's to the ADDFB and ADDFB2 code paths and tested a
bit.  Apparently pretty much all userspace still uses the ADDFB ioctl.
xorg (modesetting driver) does.  gnome-shell in wayland mode does.
Seems the big transition to ADDFB2 didn't happen yet.

I guess that makes changing drm_mode_legacy_fb_format + drivers a
reasonable option ...

cheers,
  Gerd

[for-next][PATCH 19/33] ftrace: Remove printing of data in showing of a function probe

[Steven Rostedt]

From: "Steven Rostedt (VMware)" 

None of the probe users uses the data field anymore of the entry. They all
have their own print() function. Remove showing the data field in the
generic function as the data field will be going away.

Signed-off-by: Steven Rostedt (VMware) 
---
 kernel/trace/ftrace.c | 6 +-
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c
index 1c31c74d0819..15f910a03822 100644
--- a/kernel/trace/ftrace.c
+++ b/kernel/trace/ftrace.c
@@ -3154,11 +3154,7 @@ t_hash_show(struct seq_file *m, struct ftrace_iterator 
*iter)
if (rec->ops->print)
return rec->ops->print(m, rec->ip, rec->ops, rec->data);
 
-   seq_printf(m, "%ps:%ps", (void *)rec->ip, (void *)rec->ops->func);
-
-   if (rec->data)
-   seq_printf(m, ":%p", rec->data);
-   seq_putc(m, '\n');
+   seq_printf(m, "%ps:%ps\n", (void *)rec->ip, (void *)rec->ops->func);
 
return 0;
 }
-- 
2.10.2

[HMM 14/15] mm/hmm/devmem: dummy HMM device for ZONE_DEVICE memory v3

[Jérôme Glisse]

This introduce a dummy HMM device class so device driver can use it to
create hmm_device for the sole purpose of registering device memory.
It is useful to device driver that want to manage multiple physical
device memory under same struct device umbrella.

Changed since v2:
  - use device_initcall() and drop everything that is module specific
Changed since v1:
  - Improve commit message
  - Add drvdata parameter to set on struct device

Signed-off-by: Jérôme Glisse 
Signed-off-by: Evgeny Baskakov 
Signed-off-by: John Hubbard 
Signed-off-by: Mark Hairgrove 
Signed-off-by: Sherry Cheung 
Signed-off-by: Subhash Gutti 
---
 include/linux/hmm.h | 22 +-
 mm/hmm.c| 88 +
 2 files changed, 109 insertions(+), 1 deletion(-)

diff --git a/include/linux/hmm.h b/include/linux/hmm.h
index 50a1115..374e5fd 100644
--- a/include/linux/hmm.h
+++ b/include/linux/hmm.h
@@ -72,11 +72,11 @@
 
 #if IS_ENABLED(CONFIG_HMM)
 
+#include 
 #include 
 #include 
 #include 
 
-
 struct hmm;
 
 /*
@@ -433,6 +433,26 @@ static inline unsigned long 
hmm_devmem_page_get_drvdata(struct page *page)
 
return drvdata[1];
 }
+
+
+/*
+ * struct hmm_device - fake device to hang device memory onto
+ *
+ * @device: device struct
+ * @minor: device minor number
+ */
+struct hmm_device {
+   struct device   device;
+   unsigned intminor;
+};
+
+/*
+ * A device driver that wants to handle multiple devices memory through a
+ * single fake device can use hmm_device to do so. This is purely a helper and
+ * it is not strictly needed, in order to make use of any HMM functionality.
+ */
+struct hmm_device *hmm_device_new(void *drvdata);
+void hmm_device_put(struct hmm_device *hmm_device);
 #endif /* IS_ENABLED(CONFIG_HMM_DEVMEM) */
 
 
diff --git a/mm/hmm.c b/mm/hmm.c
index 5d882e6..8b6b4c6 100644
--- a/mm/hmm.c
+++ b/mm/hmm.c
@@ -19,6 +19,7 @@
  */
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -1112,4 +1113,91 @@ int hmm_devmem_fault_range(struct hmm_devmem *devmem,
return 0;
 }
 EXPORT_SYMBOL(hmm_devmem_fault_range);
+
+/*
+ * A device driver that wants to handle multiple devices memory through a
+ * single fake device can use hmm_device to do so. This is purely a helper
+ * and it is not needed to make use of any HMM functionality.
+ */
+#define HMM_DEVICE_MAX 256
+
+static DECLARE_BITMAP(hmm_device_mask, HMM_DEVICE_MAX);
+static DEFINE_SPINLOCK(hmm_device_lock);
+static struct class *hmm_device_class;
+static dev_t hmm_device_devt;
+
+static void hmm_device_release(struct device *device)
+{
+   struct hmm_device *hmm_device;
+
+   hmm_device = container_of(device, struct hmm_device, device);
+   spin_lock(_device_lock);
+   clear_bit(hmm_device->minor, hmm_device_mask);
+   spin_unlock(_device_lock);
+
+   kfree(hmm_device);
+}
+
+struct hmm_device *hmm_device_new(void *drvdata)
+{
+   struct hmm_device *hmm_device;
+   int ret;
+
+   hmm_device = kzalloc(sizeof(*hmm_device), GFP_KERNEL);
+   if (!hmm_device)
+   return ERR_PTR(-ENOMEM);
+
+   ret = alloc_chrdev_region(_device->device.devt, 0, 1, "hmm_device");
+   if (ret < 0) {
+   kfree(hmm_device);
+   return NULL;
+   }
+
+   spin_lock(_device_lock);
+   hmm_device->minor = find_first_zero_bit(hmm_device_mask, 
HMM_DEVICE_MAX);
+   if (hmm_device->minor >= HMM_DEVICE_MAX) {
+   spin_unlock(_device_lock);
+   kfree(hmm_device);
+   return NULL;
+   }
+   set_bit(hmm_device->minor, hmm_device_mask);
+   spin_unlock(_device_lock);
+
+   dev_set_name(_device->device, "hmm_device%d", hmm_device->minor);
+   hmm_device->device.devt = MKDEV(MAJOR(hmm_device_devt),
+   hmm_device->minor);
+   hmm_device->device.release = hmm_device_release;
+   dev_set_drvdata(_device->device, drvdata);
+   hmm_device->device.class = hmm_device_class;
+   device_initialize(_device->device);
+
+   return hmm_device;
+}
+EXPORT_SYMBOL(hmm_device_new);
+
+void hmm_device_put(struct hmm_device *hmm_device)
+{
+   put_device(_device->device);
+}
+EXPORT_SYMBOL(hmm_device_put);
+
+static int __init hmm_init(void)
+{
+   int ret;
+
+   ret = alloc_chrdev_region(_device_devt, 0,
+ HMM_DEVICE_MAX,
+ "hmm_device");
+   if (ret)
+   return ret;
+
+   hmm_device_class = class_create(THIS_MODULE, "hmm_device");
+   if (IS_ERR(hmm_device_class)) {
+   unregister_chrdev_region(hmm_device_devt, HMM_DEVICE_MAX);
+   return PTR_ERR(hmm_device_class);
+   }
+   return 0;
+}
+
+device_initcall(hmm_init);
 #endif /* 

Re: Linux 3.18.50

[Greg KH]

diff --git a/Makefile b/Makefile
index 252070fdf91c..8665178e2a36 100644
--- a/Makefile
+++ b/Makefile
@@ -1,6 +1,6 @@
 VERSION = 3
 PATCHLEVEL = 18
-SUBLEVEL = 49
+SUBLEVEL = 50
 EXTRAVERSION =
 NAME = Diseased Newt
 
diff --git a/arch/arm/include/asm/psci.h b/arch/arm/include/asm/psci.h
index e3789fb02c9c..c25ef3ec6d1f 100644
--- a/arch/arm/include/asm/psci.h
+++ b/arch/arm/include/asm/psci.h
@@ -37,7 +37,7 @@ struct psci_operations {
 extern struct psci_operations psci_ops;
 extern struct smp_operations psci_smp_ops;
 
-#if defined(CONFIG_SMP) && defined(CONFIG_ARM_PSCI)
+#ifdef CONFIG_ARM_PSCI
 int psci_init(void);
 bool psci_smp_available(void);
 #else
diff --git a/arch/arm/kvm/mmu.c b/arch/arm/kvm/mmu.c
index feda3ff185e9..9fb14a37263b 100644
--- a/arch/arm/kvm/mmu.c
+++ b/arch/arm/kvm/mmu.c
@@ -1407,6 +1407,7 @@ int kvm_arch_prepare_memory_region(struct kvm *kvm,
(KVM_PHYS_SIZE >> PAGE_SHIFT))
return -EFAULT;
 
+   down_read(>mm->mmap_sem);
/*
 * A memory region could potentially cover multiple VMAs, and any holes
 * between them, so iterate over all of them to find out if we can map
@@ -1464,6 +1465,8 @@ int kvm_arch_prepare_memory_region(struct kvm *kvm,
else
stage2_flush_memslot(kvm, memslot);
spin_unlock(>mmu_lock);
+
+   up_read(>mm->mmap_sem);
return ret;
 }
 
diff --git a/arch/c6x/kernel/ptrace.c b/arch/c6x/kernel/ptrace.c
index 3c494e8d..a511ac16a8e3 100644
--- a/arch/c6x/kernel/ptrace.c
+++ b/arch/c6x/kernel/ptrace.c
@@ -69,46 +69,6 @@ static int gpr_get(struct task_struct *target,
   0, sizeof(*regs));
 }
 
-static int gpr_set(struct task_struct *target,
-  const struct user_regset *regset,
-  unsigned int pos, unsigned int count,
-  const void *kbuf, const void __user *ubuf)
-{
-   int ret;
-   struct pt_regs *regs = task_pt_regs(target);
-
-   /* Don't copyin TSR or CSR */
-   ret = user_regset_copyin(, , , ,
-,
-0, PT_TSR * sizeof(long));
-   if (ret)
-   return ret;
-
-   ret = user_regset_copyin_ignore(, , , ,
-   PT_TSR * sizeof(long),
-   (PT_TSR + 1) * sizeof(long));
-   if (ret)
-   return ret;
-
-   ret = user_regset_copyin(, , , ,
-,
-(PT_TSR + 1) * sizeof(long),
-PT_CSR * sizeof(long));
-   if (ret)
-   return ret;
-
-   ret = user_regset_copyin_ignore(, , , ,
-   PT_CSR * sizeof(long),
-   (PT_CSR + 1) * sizeof(long));
-   if (ret)
-   return ret;
-
-   ret = user_regset_copyin(, , , ,
-,
-(PT_CSR + 1) * sizeof(long), -1);
-   return ret;
-}
-
 enum c6x_regset {
REGSET_GPR,
 };
@@ -120,7 +80,6 @@ static const struct user_regset c6x_regsets[] = {
.size = sizeof(u32),
.align = sizeof(u32),
.get = gpr_get,
-   .set = gpr_set
},
 };
 
diff --git a/arch/metag/include/asm/uaccess.h b/arch/metag/include/asm/uaccess.h
index 7841f2290385..9d523375f68a 100644
--- a/arch/metag/include/asm/uaccess.h
+++ b/arch/metag/include/asm/uaccess.h
@@ -192,20 +192,21 @@ extern long __must_check strnlen_user(const char __user 
*src, long count);
 
 #define strlen_user(str) strnlen_user(str, 32767)
 
-extern unsigned long __must_check __copy_user_zeroing(void *to,
- const void __user *from,
- unsigned long n);
+extern unsigned long raw_copy_from_user(void *to, const void __user *from,
+   unsigned long n);
 
 static inline unsigned long
 copy_from_user(void *to, const void __user *from, unsigned long n)
 {
+   unsigned long res = n;
if (likely(access_ok(VERIFY_READ, from, n)))
-   return __copy_user_zeroing(to, from, n);
-   memset(to, 0, n);
-   return n;
+   res = raw_copy_from_user(to, from, n);
+   if (unlikely(res))
+   memset(to + (n - res), 0, res);
+   return res;
 }
 
-#define __copy_from_user(to, from, n) __copy_user_zeroing(to, from, n)
+#define __copy_from_user(to, from, n) raw_copy_from_user(to, from, n)
 #define __copy_from_user_inatomic __copy_from_user
 
 extern unsigned long __must_check __copy_user(void __user *to,
diff --git a/arch/metag/kernel/ptrace.c b/arch/metag/kernel/ptrace.c
index 7563628822bd..5e2dc7defd2c 100644
--- a/arch/metag/kernel/ptrace.c
+++ b/arch/metag/kernel/ptrace.c
@@ -24,6 +24,16 @@
  * user_regset definitions.
  */
 
+static unsigned long