Re: [PATCH 2/2] fs, elf: drop MAP_FIXED usage from elf_map

[Khalid Aziz]

On 11/29/2017 07:42 AM, Michal Hocko wrote:

From: Michal Hocko 

Both load_elf_interp and load_elf_binary rely on elf_map to map segments
on a controlled address and they use MAP_FIXED to enforce that. This is
however dangerous thing prone to silent data corruption which can be
even exploitable. Let's take CVE-2017-1000253 as an example. At the time
(before eab09532d400 ("binfmt_elf: use ELF_ET_DYN_BASE only for PIE"))
ELF_ET_DYN_BASE was at TASK_SIZE / 3 * 2 which is not that far away from
the stack top on 32b (legacy) memory layout (only 1GB away). Therefore
we could end up mapping over the existing stack with some luck.

The issue has been fixed since then (a87938b2e246 ("fs/binfmt_elf.c:
fix bug in loading of PIE binaries")), ELF_ET_DYN_BASE moved moved much
further from the stack (eab09532d400 and later by c715b72c1ba4 ("mm:
revert x86_64 and arm64 ELF_ET_DYN_BASE base changes")) and excessive
stack consumption early during execve fully stopped by da029c11e6b1
("exec: Limit arg stack to at most 75% of _STK_LIM"). So we should be
safe and any attack should be impractical. On the other hand this is
just too subtle assumption so it can break quite easily and hard to
spot.

I believe that the MAP_FIXED usage in load_elf_binary (et. al) is still
fundamentally dangerous. Moreover it shouldn't be even needed. We are
at the early process stage and so there shouldn't be unrelated mappings
(except for stack and loader) existing so mmap for a given address
should succeed even without MAP_FIXED. Something is terribly wrong if
this is not the case and we should rather fail than silently corrupt the
underlying mapping.

Address this issue by changing MAP_FIXED to the newly added
MAP_FIXED_SAFE. This will mean that mmap will fail if there is an
existing mapping clashing with the requested one without clobbering it.

Cc: Abdul Haleem 
Cc: Joel Stanley 
Acked-by: Kees Cook 
Signed-off-by: Michal Hocko 
---


Reviewed-by: Khalid Aziz 

[PATCH AUTOSEL for 4.9 44/52] crypto: s5p-sss - Fix completing crypto request in IRQ handler

[alexander . levin]

From: Krzysztof Kozlowski 

[ Upstream commit 07de4bc88ce6a4d898cad9aa4c99c1df7e87702d ]

In a regular interrupt handler driver was finishing the crypt/decrypt
request by calling complete on crypto request.  This is disallowed since
converting to skcipher in commit b286d8b1a690 ("crypto: skcipher - Add
skcipher walk interface") and causes a warning:
WARNING: CPU: 0 PID: 0 at crypto/skcipher.c:430 
skcipher_walk_first+0x13c/0x14c

The interrupt is marked shared but in fact there are no other users
sharing it.  Thus the simplest solution seems to be to just use a
threaded interrupt handler, after converting it to oneshot.

Signed-off-by: Krzysztof Kozlowski 
Signed-off-by: Herbert Xu 
Signed-off-by: Sasha Levin 
---
 drivers/crypto/s5p-sss.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/crypto/s5p-sss.c b/drivers/crypto/s5p-sss.c
index dce1af0ce85c..a668286d62cb 100644
--- a/drivers/crypto/s5p-sss.c
+++ b/drivers/crypto/s5p-sss.c
@@ -805,8 +805,9 @@ static int s5p_aes_probe(struct platform_device *pdev)
dev_warn(dev, "feed control interrupt is not available.\n");
goto err_irq;
}
-   err = devm_request_irq(dev, pdata->irq_fc, s5p_aes_interrupt,
-  IRQF_SHARED, pdev->name, pdev);
+   err = devm_request_threaded_irq(dev, pdata->irq_fc, NULL,
+   s5p_aes_interrupt, IRQF_ONESHOT,
+   pdev->name, pdev);
if (err < 0) {
dev_warn(dev, "feed control interrupt is not available.\n");
goto err_irq;
-- 
2.11.0

[PATCH AUTOSEL for 4.9 10/52] powerpc: Fix compiling a BE kernel with a powerpc64le toolchain

[alexander . levin]

From: Nicholas Piggin 

[ Upstream commit 4dc831aa88132f835cefe876aa0206977c4d7710 ]

GCC can compile with either endian, but the default ABI version is set
based on the default endianness of the toolchain. Alan Modra says:

  you need both -mbig and -mabi=elfv1 to make a powerpc64le gcc
  generate powerpc64 code

The opposite is true for powerpc64 when generating -mlittle it
requires -mabi=elfv2 to generate v2 ABI, which we were already doing.

This change adds ABI annotations together with endianness for all cases,
LE and BE. This fixes the case of building a BE kernel with a toolchain
that is LE by default.

Signed-off-by: Nicholas Piggin 
Tested-by: Naveen N. Rao 
Signed-off-by: Michael Ellerman 
Signed-off-by: Sasha Levin 
---
 arch/powerpc/Makefile | 11 ++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile
index 617dece67924..a60c9c6e5cc1 100644
--- a/arch/powerpc/Makefile
+++ b/arch/powerpc/Makefile
@@ -72,8 +72,15 @@ GNUTARGET:= powerpc
 MULTIPLEWORD   := -mmultiple
 endif
 
-cflags-$(CONFIG_CPU_BIG_ENDIAN)+= $(call 
cc-option,-mbig-endian)
+ifdef CONFIG_PPC64
+cflags-$(CONFIG_CPU_BIG_ENDIAN)+= $(call cc-option,-mabi=elfv1)
+cflags-$(CONFIG_CPU_BIG_ENDIAN)+= $(call 
cc-option,-mcall-aixdesc)
+aflags-$(CONFIG_CPU_BIG_ENDIAN)+= $(call cc-option,-mabi=elfv1)
+aflags-$(CONFIG_CPU_LITTLE_ENDIAN) += -mabi=elfv2
+endif
+
 cflags-$(CONFIG_CPU_LITTLE_ENDIAN) += -mlittle-endian
+cflags-$(CONFIG_CPU_BIG_ENDIAN)+= $(call 
cc-option,-mbig-endian)
 ifneq ($(cc-name),clang)
   cflags-$(CONFIG_CPU_LITTLE_ENDIAN)   += -mno-strict-align
 endif
@@ -113,7 +120,9 @@ ifeq ($(CONFIG_CPU_LITTLE_ENDIAN),y)
 CFLAGS-$(CONFIG_PPC64) += $(call cc-option,-mabi=elfv2,$(call 
cc-option,-mcall-aixdesc))
 AFLAGS-$(CONFIG_PPC64) += $(call cc-option,-mabi=elfv2)
 else
+CFLAGS-$(CONFIG_PPC64) += $(call cc-option,-mabi=elfv1)
 CFLAGS-$(CONFIG_PPC64) += $(call cc-option,-mcall-aixdesc)
+AFLAGS-$(CONFIG_PPC64) += $(call cc-option,-mabi=elfv1)
 endif
 CFLAGS-$(CONFIG_PPC64) += $(call cc-option,-mcmodel=medium,$(call 
cc-option,-mminimal-toc))
 CFLAGS-$(CONFIG_PPC64) += $(call cc-option,-mno-pointers-to-nested-functions)
-- 
2.11.0

[PATCH AUTOSEL for 4.9 46/52] blk-mq: initialize mq kobjects in blk_mq_init_allocated_queue()

[alexander . levin]

From: Ming Lei 

[ Upstream commit 737f98cfe7de8df7433a4d846850aa8efa44bd48 ]

Both q->mq_kobj and sw queues' kobjects should have been initialized
once, instead of doing that each add_disk context.

Also this patch removes clearing of ctx in blk_mq_init_cpu_queues()
because percpu allocator fills zero to allocated variable.

This patch fixes one issue[1] reported from Omar.

[1] kernel wearning when doing unbind/bind on one scsi-mq device

[   19.347924] kobject (8800791ea0b8): tried to init an initialized object, 
something is seriously wrong.
[   19.349781] CPU: 1 PID: 84 Comm: kworker/u8:1 Not tainted 
4.10.0-rc7-00210-g53f39eeaa263 #34
[   19.350686] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
1.10.1-20161122_114906-anatol 04/01/2014
[   19.350920] Workqueue: events_unbound async_run_entry_fn
[   19.350920] Call Trace:
[   19.350920]  dump_stack+0x63/0x83
[   19.350920]  kobject_init+0x77/0x90
[   19.350920]  blk_mq_register_dev+0x40/0x130
[   19.350920]  blk_register_queue+0xb6/0x190
[   19.350920]  device_add_disk+0x1ec/0x4b0
[   19.350920]  sd_probe_async+0x10d/0x1c0 [sd_mod]
[   19.350920]  async_run_entry_fn+0x48/0x150
[   19.350920]  process_one_work+0x1d0/0x480
[   19.350920]  worker_thread+0x48/0x4e0
[   19.350920]  kthread+0x101/0x140
[   19.350920]  ? process_one_work+0x480/0x480
[   19.350920]  ? kthread_create_on_node+0x60/0x60
[   19.350920]  ret_from_fork+0x2c/0x40

Cc: Omar Sandoval 
Signed-off-by: Ming Lei 
Tested-by: Peter Zijlstra (Intel) 
Signed-off-by: Jens Axboe 
Signed-off-by: Sasha Levin 
---
 block/blk-mq-sysfs.c | 4 +---
 block/blk-mq.c   | 4 +++-
 block/blk-mq.h   | 1 +
 3 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/block/blk-mq-sysfs.c b/block/blk-mq-sysfs.c
index 01fb455d3377..8c0894e0713b 100644
--- a/block/blk-mq-sysfs.c
+++ b/block/blk-mq-sysfs.c
@@ -429,7 +429,7 @@ void blk_mq_hctx_kobj_init(struct blk_mq_hw_ctx *hctx)
kobject_init(&hctx->kobj, &blk_mq_hw_ktype);
 }
 
-static void blk_mq_sysfs_init(struct request_queue *q)
+void blk_mq_sysfs_init(struct request_queue *q)
 {
struct blk_mq_ctx *ctx;
int cpu;
@@ -449,8 +449,6 @@ int blk_mq_register_dev(struct device *dev, struct 
request_queue *q)
 
blk_mq_disable_hotplug();
 
-   blk_mq_sysfs_init(q);
-
ret = kobject_add(&q->mq_kobj, kobject_get(&dev->kobj), "%s", "mq");
if (ret < 0)
goto out;
diff --git a/block/blk-mq.c b/block/blk-mq.c
index 7b597ec4e9c5..10f8f94b7f20 100644
--- a/block/blk-mq.c
+++ b/block/blk-mq.c
@@ -1707,7 +1707,6 @@ static void blk_mq_init_cpu_queues(struct request_queue 
*q,
struct blk_mq_ctx *__ctx = per_cpu_ptr(q->queue_ctx, i);
struct blk_mq_hw_ctx *hctx;
 
-   memset(__ctx, 0, sizeof(*__ctx));
__ctx->cpu = i;
spin_lock_init(&__ctx->lock);
INIT_LIST_HEAD(&__ctx->rq_list);
@@ -1970,6 +1969,9 @@ struct request_queue *blk_mq_init_allocated_queue(struct 
blk_mq_tag_set *set,
if (!q->queue_ctx)
goto err_exit;
 
+   /* init q->mq_kobj and sw queues' kobjects */
+   blk_mq_sysfs_init(q);
+
q->queue_hw_ctx = kzalloc_node(nr_cpu_ids * sizeof(*(q->queue_hw_ctx)),
GFP_KERNEL, set->numa_node);
if (!q->queue_hw_ctx)
diff --git a/block/blk-mq.h b/block/blk-mq.h
index e5d25249028c..c55bcf67b956 100644
--- a/block/blk-mq.h
+++ b/block/blk-mq.h
@@ -50,6 +50,7 @@ static inline struct blk_mq_hw_ctx *blk_mq_map_queue(struct 
request_queue *q,
 /*
  * sysfs helpers
  */
+extern void blk_mq_sysfs_init(struct request_queue *q);
 extern int blk_mq_sysfs_register(struct request_queue *q);
 extern void blk_mq_sysfs_unregister(struct request_queue *q);
 extern void blk_mq_hctx_kobj_init(struct blk_mq_hw_ctx *hctx);
-- 
2.11.0

[PATCH AUTOSEL for 4.9 51/52] powerpc/powernv/ioda2: Gracefully fail if too many TCE levels requested

[alexander . levin]

From: Alexey Kardashevskiy 

[ Upstream commit 7aafac11e308d37ed3c509829bb43d80c1811ac3 ]

The IODA2 specification says that a 64 DMA address cannot use top 4 bits
(3 are reserved and one is a "TVE select"); bottom page_shift bits
cannot be used for multilevel table addressing either.

The existing IODA2 table allocation code aligns the minimum TCE table
size to PAGE_SIZE so in the case of 64K system pages and 4K IOMMU pages,
we have 64-4-12=48 bits. Since 64K page stores 8192 TCEs, i.e. needs
13 bits, the maximum number of levels is 48/13 = 3 so we physically
cannot address more and EEH happens on DMA accesses.

This adds a check that too many levels were requested.

It is still possible to have 5 levels in the case of 4K system page size.

Signed-off-by: Alexey Kardashevskiy 
Acked-by: Gavin Shan 
Signed-off-by: Michael Ellerman 
Signed-off-by: Sasha Levin 
---
 arch/powerpc/platforms/powernv/pci-ioda.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c 
b/arch/powerpc/platforms/powernv/pci-ioda.c
index dcdfee0cd4f2..f602307a4386 100644
--- a/arch/powerpc/platforms/powernv/pci-ioda.c
+++ b/arch/powerpc/platforms/powernv/pci-ioda.c
@@ -2623,6 +2623,9 @@ static long pnv_pci_ioda2_table_alloc_pages(int nid, 
__u64 bus_offset,
level_shift = entries_shift + 3;
level_shift = max_t(unsigned, level_shift, PAGE_SHIFT);
 
+   if ((level_shift - 3) * levels + page_shift >= 60)
+   return -EINVAL;
+
/* Allocate TCE table */
addr = pnv_pci_ioda2_table_do_alloc_pages(nid, level_shift,
levels, tce_table_size, &offset, &total_allocated);
-- 
2.11.0

[PATCH AUTOSEL for 4.9 50/52] drm/amd/amdgpu: fix console deadlock if late init failed

[alexander . levin]

From: Jim Qu 

[ Upstream commit c085bd5119d5d0bdf3ef591a5563566be7dedced ]

Signed-off-by: Jim Qu 
Reviewed-by: Alex Deucher 
Signed-off-by: Alex Deucher 
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index e41d4baebf86..ce9797b6f9c7 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -2020,8 +2020,11 @@ int amdgpu_device_resume(struct drm_device *dev, bool 
resume, bool fbcon)
}
 
r = amdgpu_late_init(adev);
-   if (r)
+   if (r) {
+   if (fbcon)
+   console_unlock();
return r;
+   }
 
/* pin cursors */
list_for_each_entry(crtc, &dev->mode_config.crtc_list, head) {
-- 
2.11.0

Re: [PATCH v2 1/2] pinctrl: Allow a device to indicate when to force a state

[Tony Lindgren]

* Florian Fainelli  [171129 17:37]:
> On 11/29/2017 09:01 AM, Tony Lindgren wrote:
> > * Florian Fainelli  [171102 23:18]:
> >> It may happen that a device needs to force applying a state, e.g:
> >> because it only defines one state of pin states (default) but loses
> >> power/register contents when entering low power modes. Add a
> >> pinctrl_dev::flags bitmask to help describe future quirks and define
> >> PINCTRL_FLG_FORCE_STATE as such a settable flag.
> > 
> > It makes sense to tag the existing state with the context loss
> > information as otherwise we'll be duplicating the state in the
> > pinctrl driver potentially for hundreds of pins.
> > 
> > Maybe this patch description should clarify that it's the
> > pinctrl device restoring the pin state, not the pinctrl
> > consumer devices?
> > 
> > So maybe just "a pinctrl device needs to force apply a state"
> > instead of just device above?
> 
> It's a bit more involved than that, the pinctrl consumer device might
> want to restore a particular state by calling pinctrl_select_state(),
> however, because of the (p->state == state)check, the pinctrl provider
> driver has no chance of making that call do the actual HW programming.

Hmm but isn't it the pinctrl provider device losing context here?
I think the restore of the pin state should somehow happen automatically
by the pinctrl provider driver without a need for the pinctrl consumer
drivers to do anything.

Or what's the use case for pinctrl consumer driver wanting to store
a pin?

Regards,

Tony

Re: [PATCH 4.14 000/193] 4.14.3-stable review

[Greg Kroah-Hartman]

On Wed, Nov 29, 2017 at 05:04:34PM +0100, Zdenek Kaspar wrote:
> On 11/28/2017 11:24 AM, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.14.3 release.
> > There are 193 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 Thu Nov 30 10:05:26 UTC 2017.
> > Anything received after that time might be too late.
> > 
> > The whole patch series can be found in one patch at:
> > kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.14.3-rc1.gz
> > or in the git tree and branch at:
> >   git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> > linux-4.14.y
> > and the diffstat can be found below.
> > 
> > thanks,
> > 
> > greg k-h
> 
> ... snip ...
> 
> > Paolo Bonzini 
> > kvm: vmx: Reinstate support for CPUs without virtual NMI
> 
> KVM works again on old Core2 CPU ... thanks, Z.

Nice, thanks for testing!

greg k-h

[PATCH AUTOSEL for 4.4 02/32] ARM: OMAP2+: gpmc-onenand: propagate error on initialization failure

[alexander . levin]

From: Ladislav Michl 

[ Upstream commit 7807e086a2d1f69cc1a57958cac04fea79fc2112 ]

gpmc_probe_onenand_child returns success even on gpmc_onenand_init
failure. Fix that.

Signed-off-by: Ladislav Michl 
Acked-by: Roger Quadros 
Signed-off-by: Tony Lindgren 
Signed-off-by: Sasha Levin 
---
 arch/arm/mach-omap2/gpmc-onenand.c | 10 ++
 drivers/memory/omap-gpmc.c |  4 +---
 include/linux/omap-gpmc.h  |  5 +++--
 3 files changed, 10 insertions(+), 9 deletions(-)

diff --git a/arch/arm/mach-omap2/gpmc-onenand.c 
b/arch/arm/mach-omap2/gpmc-onenand.c
index 8633c703546a..2944af820558 100644
--- a/arch/arm/mach-omap2/gpmc-onenand.c
+++ b/arch/arm/mach-omap2/gpmc-onenand.c
@@ -367,7 +367,7 @@ static int gpmc_onenand_setup(void __iomem *onenand_base, 
int *freq_ptr)
return ret;
 }
 
-void gpmc_onenand_init(struct omap_onenand_platform_data *_onenand_data)
+int gpmc_onenand_init(struct omap_onenand_platform_data *_onenand_data)
 {
int err;
struct device *dev = &gpmc_onenand_device.dev;
@@ -393,15 +393,17 @@ void gpmc_onenand_init(struct omap_onenand_platform_data 
*_onenand_data)
if (err < 0) {
dev_err(dev, "Cannot request GPMC CS %d, error %d\n",
gpmc_onenand_data->cs, err);
-   return;
+   return err;
}
 
gpmc_onenand_resource.end = gpmc_onenand_resource.start +
ONENAND_IO_SIZE - 1;
 
-   if (platform_device_register(&gpmc_onenand_device) < 0) {
+   err = platform_device_register(&gpmc_onenand_device);
+   if (err) {
dev_err(dev, "Unable to register OneNAND device\n");
gpmc_cs_free(gpmc_onenand_data->cs);
-   return;
}
+
+   return err;
 }
diff --git a/drivers/memory/omap-gpmc.c b/drivers/memory/omap-gpmc.c
index 55cba89dbdb8..49691a8c74ee 100644
--- a/drivers/memory/omap-gpmc.c
+++ b/drivers/memory/omap-gpmc.c
@@ -1890,9 +1890,7 @@ static int gpmc_probe_onenand_child(struct 
platform_device *pdev,
if (!of_property_read_u32(child, "dma-channel", &val))
gpmc_onenand_data->dma_channel = val;
 
-   gpmc_onenand_init(gpmc_onenand_data);
-
-   return 0;
+   return gpmc_onenand_init(gpmc_onenand_data);
 }
 #else
 static int gpmc_probe_onenand_child(struct platform_device *pdev,
diff --git a/include/linux/omap-gpmc.h b/include/linux/omap-gpmc.h
index 7dee00143afd..c201e31e9d7e 100644
--- a/include/linux/omap-gpmc.h
+++ b/include/linux/omap-gpmc.h
@@ -191,10 +191,11 @@ static inline int gpmc_nand_init(struct 
omap_nand_platform_data *d,
 #endif
 
 #if IS_ENABLED(CONFIG_MTD_ONENAND_OMAP2)
-extern void gpmc_onenand_init(struct omap_onenand_platform_data *d);
+extern int gpmc_onenand_init(struct omap_onenand_platform_data *d);
 #else
 #define board_onenand_data NULL
-static inline void gpmc_onenand_init(struct omap_onenand_platform_data *d)
+static inline int gpmc_onenand_init(struct omap_onenand_platform_data *d)
 {
+   return 0;
 }
 #endif
-- 
2.11.0

[PATCH AUTOSEL for 4.4 01/32] vti6: Don't report path MTU below IPV6_MIN_MTU.

[alexander . levin]

From: Steffen Klassert 

[ Upstream commit e3dc847a5f85b43ee2bfc8eae407a7e383483228 ]

In vti6_xmit(), the check for IPV6_MIN_MTU before we
send a ICMPV6_PKT_TOOBIG message is missing. So we might
report a PMTU below 1280. Fix this by adding the required
check.

Fixes: ccd740cbc6e ("vti6: Add pmtu handling to vti6_xmit.")
Signed-off-by: Steffen Klassert 
Signed-off-by: Sasha Levin 
---
 net/ipv6/ip6_vti.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/net/ipv6/ip6_vti.c b/net/ipv6/ip6_vti.c
index 7ebb14def2cb..24140e85067c 100644
--- a/net/ipv6/ip6_vti.c
+++ b/net/ipv6/ip6_vti.c
@@ -474,11 +474,15 @@ vti6_xmit(struct sk_buff *skb, struct net_device *dev, 
struct flowi *fl)
if (!skb->ignore_df && skb->len > mtu) {
skb_dst(skb)->ops->update_pmtu(dst, NULL, skb, mtu);
 
-   if (skb->protocol == htons(ETH_P_IPV6))
+   if (skb->protocol == htons(ETH_P_IPV6)) {
+   if (mtu < IPV6_MIN_MTU)
+   mtu = IPV6_MIN_MTU;
+
icmpv6_send(skb, ICMPV6_PKT_TOOBIG, 0, mtu);
-   else
+   } else {
icmp_send(skb, ICMP_DEST_UNREACH, ICMP_FRAG_NEEDED,
  htonl(mtu));
+   }
 
return -EMSGSIZE;
}
-- 
2.11.0

[PATCH AUTOSEL for 4.9 47/52] zram: set physical queue limits to avoid array out of bounds accesses

[alexander . levin]

From: Johannes Thumshirn 

[ Upstream commit 0bc315381fe9ed9fb91db8b0e82171b645ac008f ]

zram can handle at most SECTORS_PER_PAGE sectors in a bio's bvec. When using
the NVMe over Fabrics loopback target which potentially sends a huge bulk of
pages attached to the bio's bvec this results in a kernel panic because of
array out of bounds accesses in zram_decompress_page().

Signed-off-by: Johannes Thumshirn 
Reviewed-by: Hannes Reinecke 
Reviewed-by: Sergey Senozhatsky 
Signed-off-by: Jens Axboe 
Signed-off-by: Sasha Levin 
---
 drivers/block/zram/zram_drv.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
index c9914d653968..b7c0b69a02f5 100644
--- a/drivers/block/zram/zram_drv.c
+++ b/drivers/block/zram/zram_drv.c
@@ -1286,6 +1286,8 @@ static int zram_add(void)
blk_queue_io_min(zram->disk->queue, PAGE_SIZE);
blk_queue_io_opt(zram->disk->queue, PAGE_SIZE);
zram->disk->queue->limits.discard_granularity = PAGE_SIZE;
+   zram->disk->queue->limits.max_sectors = SECTORS_PER_PAGE;
+   zram->disk->queue->limits.chunk_sectors = 0;
blk_queue_max_discard_sectors(zram->disk->queue, UINT_MAX);
/*
 * zram_bio_discard() will clear all logical blocks if logical block
-- 
2.11.0

[PATCH AUTOSEL for 4.9 52/52] EDAC, i5000, i5400: Fix use of MTR_DRAM_WIDTH macro

[alexander . levin]

From: Jérémy Lefaure 

[ Upstream commit e61555c29c28a4a3b6ba6207f4a0883ee236004d ]

The MTR_DRAM_WIDTH macro returns the data width. It is sometimes used
as if it returned a boolean true if the width if 8. Fix the tests where
MTR_DRAM_WIDTH is misused.

Signed-off-by: Jérémy Lefaure 
Cc: linux-edac 
Link: http://lkml.kernel.org/r/20170309011809.8340-1-jeremy.lefa...@lse.epita.fr
Signed-off-by: Borislav Petkov 
Signed-off-by: Sasha Levin 
---
 drivers/edac/i5000_edac.c | 2 +-
 drivers/edac/i5400_edac.c | 5 +++--
 2 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/edac/i5000_edac.c b/drivers/edac/i5000_edac.c
index 72e07e3cf718..2a09be5f4f86 100644
--- a/drivers/edac/i5000_edac.c
+++ b/drivers/edac/i5000_edac.c
@@ -1293,7 +1293,7 @@ static int i5000_init_csrows(struct mem_ctl_info *mci)
dimm->mtype = MEM_FB_DDR2;
 
/* ask what device type on this row */
-   if (MTR_DRAM_WIDTH(mtr))
+   if (MTR_DRAM_WIDTH(mtr) == 8)
dimm->dtype = DEV_X8;
else
dimm->dtype = DEV_X4;
diff --git a/drivers/edac/i5400_edac.c b/drivers/edac/i5400_edac.c
index 6ef6ad1ba16e..029dfe07b734 100644
--- a/drivers/edac/i5400_edac.c
+++ b/drivers/edac/i5400_edac.c
@@ -1207,13 +1207,14 @@ static int i5400_init_dimms(struct mem_ctl_info *mci)
 
dimm->nr_pages = size_mb << 8;
dimm->grain = 8;
-   dimm->dtype = MTR_DRAM_WIDTH(mtr) ? DEV_X8 : DEV_X4;
+   dimm->dtype = MTR_DRAM_WIDTH(mtr) == 8 ?
+ DEV_X8 : DEV_X4;
dimm->mtype = MEM_FB_DDR2;
/*
 * The eccc mechanism is SDDC (aka SECC), with
 * is similar to Chipkill.
 */
-   dimm->edac_mode = MTR_DRAM_WIDTH(mtr) ?
+   dimm->edac_mode = MTR_DRAM_WIDTH(mtr) == 8 ?
  EDAC_S8ECD8ED : EDAC_S4ECD4ED;
ndimms++;
}
-- 
2.11.0

[PATCH AUTOSEL for 4.9 49/52] axonram: Fix gendisk handling

[alexander . levin]

From: Jan Kara 

[ Upstream commit 672a2c87c83649fb0167202342ce85af9a3b4f1c ]

It is invalid to call del_gendisk() when disk->queue is NULL. Fix error
handling in axon_ram_probe() to avoid doing that.

Also del_gendisk() does not drop a reference to gendisk allocated by
alloc_disk(). That has to be done by put_disk(). Add that call where
needed.

Reported-by: Dan Carpenter 
Signed-off-by: Jan Kara 
Signed-off-by: Jens Axboe 
Signed-off-by: Sasha Levin 
---
 arch/powerpc/sysdev/axonram.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/arch/powerpc/sysdev/axonram.c b/arch/powerpc/sysdev/axonram.c
index ada29eaed6e2..f523ac883150 100644
--- a/arch/powerpc/sysdev/axonram.c
+++ b/arch/powerpc/sysdev/axonram.c
@@ -274,7 +274,9 @@ failed:
if (bank->disk->major > 0)
unregister_blkdev(bank->disk->major,
bank->disk->disk_name);
-   del_gendisk(bank->disk);
+   if (bank->disk->flags & GENHD_FL_UP)
+   del_gendisk(bank->disk);
+   put_disk(bank->disk);
}
device->dev.platform_data = NULL;
if (bank->io_addr != 0)
@@ -299,6 +301,7 @@ axon_ram_remove(struct platform_device *device)
device_remove_file(&device->dev, &dev_attr_ecc);
free_irq(bank->irq_id, device);
del_gendisk(bank->disk);
+   put_disk(bank->disk);
iounmap((void __iomem *) bank->io_addr);
kfree(bank);
 
-- 
2.11.0

[PATCH AUTOSEL for 4.9 48/52] netfilter: don't track fragmented packets

[alexander . levin]

From: Florian Westphal 

[ Upstream commit 7b4fdf77a450ec0fdcb2f677b080ddbf2c186544 ]

Andrey reports syzkaller splat caused by

NF_CT_ASSERT(!ip_is_fragment(ip_hdr(skb)));

in ipv4 nat.  But this assertion (and the comment) are wrong, this function
does see fragments when IP_NODEFRAG setsockopt is used.

As conntrack doesn't track packets without complete l4 header, only the
first fragment is tracked.

Because applying nat to first packet but not the rest makes no sense this
also turns off tracking of all fragments.

Reported-by: Andrey Konovalov 
Signed-off-by: Florian Westphal 
Signed-off-by: Pablo Neira Ayuso 
Signed-off-by: Sasha Levin 
---
 net/ipv4/netfilter/nf_conntrack_l3proto_ipv4.c | 4 
 net/ipv4/netfilter/nf_nat_l3proto_ipv4.c   | 5 -
 2 files changed, 4 insertions(+), 5 deletions(-)

diff --git a/net/ipv4/netfilter/nf_conntrack_l3proto_ipv4.c 
b/net/ipv4/netfilter/nf_conntrack_l3proto_ipv4.c
index 713c09a74b90..0c9ded247ebb 100644
--- a/net/ipv4/netfilter/nf_conntrack_l3proto_ipv4.c
+++ b/net/ipv4/netfilter/nf_conntrack_l3proto_ipv4.c
@@ -158,6 +158,10 @@ static unsigned int ipv4_conntrack_local(void *priv,
if (skb->len < sizeof(struct iphdr) ||
ip_hdrlen(skb) < sizeof(struct iphdr))
return NF_ACCEPT;
+
+   if (ip_is_fragment(ip_hdr(skb))) /* IP_NODEFRAG setsockopt set */
+   return NF_ACCEPT;
+
return nf_conntrack_in(state->net, PF_INET, state->hook, skb);
 }
 
diff --git a/net/ipv4/netfilter/nf_nat_l3proto_ipv4.c 
b/net/ipv4/netfilter/nf_nat_l3proto_ipv4.c
index f8aad03d674b..6f5e8d01b876 100644
--- a/net/ipv4/netfilter/nf_nat_l3proto_ipv4.c
+++ b/net/ipv4/netfilter/nf_nat_l3proto_ipv4.c
@@ -255,11 +255,6 @@ nf_nat_ipv4_fn(void *priv, struct sk_buff *skb,
/* maniptype == SRC for postrouting. */
enum nf_nat_manip_type maniptype = HOOK2MANIP(state->hook);
 
-   /* We never see fragments: conntrack defrags on pre-routing
-* and local-out, and nf_nat_out protects post-routing.
-*/
-   NF_CT_ASSERT(!ip_is_fragment(ip_hdr(skb)));
-
ct = nf_ct_get(skb, &ctinfo);
/* Can't track?  It's not due to stress, or conntrack would
 * have dropped it.  Hence it's the user's responsibilty to
-- 
2.11.0

[PATCH AUTOSEL for 4.9 41/52] ibmvnic: Fix overflowing firmware/hardware TX queue

[alexander . levin]

From: Thomas Falcon 

[ Upstream commit 142c0ac445792c492579cb01f1cfd4e32e6dfcce ]

Use a counter to track the number of outstanding transmissions sent
that have not received completions. If the counter reaches the maximum
number of queue entries, stop transmissions on that queue. As we receive
more completions from firmware, wake the queue once the counter reaches
an acceptable level.

This patch prevents hardware/firmware TX queue from filling up and
and generating errors.  Since incorporating this fix, internal testing
has reported that these firmware errors have stopped.

Signed-off-by: Thomas Falcon 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin 
---
 drivers/net/ethernet/ibm/ibmvnic.c | 27 ++-
 drivers/net/ethernet/ibm/ibmvnic.h |  1 +
 2 files changed, 27 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/ibm/ibmvnic.c 
b/drivers/net/ethernet/ibm/ibmvnic.c
index b8778e7b1f79..2eec76e88ead 100644
--- a/drivers/net/ethernet/ibm/ibmvnic.c
+++ b/drivers/net/ethernet/ibm/ibmvnic.c
@@ -705,6 +705,7 @@ static int ibmvnic_xmit(struct sk_buff *skb, struct 
net_device *netdev)
u8 *hdrs = (u8 *)&adapter->tx_rx_desc_req;
struct device *dev = &adapter->vdev->dev;
struct ibmvnic_tx_buff *tx_buff = NULL;
+   struct ibmvnic_sub_crq_queue *tx_scrq;
struct ibmvnic_tx_pool *tx_pool;
unsigned int tx_send_failed = 0;
unsigned int tx_map_failed = 0;
@@ -724,6 +725,7 @@ static int ibmvnic_xmit(struct sk_buff *skb, struct 
net_device *netdev)
int ret = 0;
 
tx_pool = &adapter->tx_pool[queue_num];
+   tx_scrq = adapter->tx_scrq[queue_num];
txq = netdev_get_tx_queue(netdev, skb_get_queue_mapping(skb));
handle_array = (u64 *)((u8 *)(adapter->login_rsp_buf) +
   be32_to_cpu(adapter->login_rsp_buf->
@@ -826,6 +828,14 @@ static int ibmvnic_xmit(struct sk_buff *skb, struct 
net_device *netdev)
ret = NETDEV_TX_BUSY;
goto out;
}
+
+   atomic_inc(&tx_scrq->used);
+
+   if (atomic_read(&tx_scrq->used) >= adapter->req_tx_entries_per_subcrq) {
+   netdev_info(netdev, "Stopping queue %d\n", queue_num);
+   netif_stop_subqueue(netdev, queue_num);
+   }
+
tx_packets++;
tx_bytes += skb->len;
txq->trans_start = jiffies;
@@ -1220,6 +1230,7 @@ static struct ibmvnic_sub_crq_queue 
*init_sub_crq_queue(struct ibmvnic_adapter
scrq->adapter = adapter;
scrq->size = 4 * PAGE_SIZE / sizeof(*scrq->msgs);
scrq->cur = 0;
+   atomic_set(&scrq->used, 0);
scrq->rx_skb_top = NULL;
spin_lock_init(&scrq->lock);
 
@@ -1368,8 +1379,22 @@ restart_loop:
 DMA_TO_DEVICE);
}
 
-   if (txbuff->last_frag)
+   if (txbuff->last_frag) {
+   atomic_dec(&scrq->used);
+
+   if (atomic_read(&scrq->used) <=
+   (adapter->req_tx_entries_per_subcrq / 2) &&
+   netif_subqueue_stopped(adapter->netdev,
+  txbuff->skb)) {
+   netif_wake_subqueue(adapter->netdev,
+   scrq->pool_index);
+   netdev_dbg(adapter->netdev,
+  "Started queue %d\n",
+  scrq->pool_index);
+   }
+
dev_kfree_skb_any(txbuff->skb);
+   }
 
adapter->tx_pool[pool].free_map[adapter->tx_pool[pool].
 producer_index] = index;
diff --git a/drivers/net/ethernet/ibm/ibmvnic.h 
b/drivers/net/ethernet/ibm/ibmvnic.h
index dd775d951b73..892eda346e54 100644
--- a/drivers/net/ethernet/ibm/ibmvnic.h
+++ b/drivers/net/ethernet/ibm/ibmvnic.h
@@ -863,6 +863,7 @@ struct ibmvnic_sub_crq_queue {
spinlock_t lock;
struct sk_buff *rx_skb_top;
struct ibmvnic_adapter *adapter;
+   atomic_t used;
 };
 
 struct ibmvnic_long_term_buff {
-- 
2.11.0

Re: [PATCH AUTOSEL for 4.9 04/52] x86/selftests: Add clobbers for int80 on x86_64

[Dmitry Safonov]

Hi Sasha,

I would object including this to stable tree:
1. It's selftest fixup
2. I have never saw selftests failing because of it (but it's possible)
I saw this in CRIU (Checkpoint Restore In Userspace) project
triggering, so I've fixed the selftests, mostly for documentation
reasons - as people in userspace can reuse this code and think
it's good and will just work after copy-paste (which is not the case).

So, this patch doesn't look urgent to include it in -stable kernel.

Thanks,
Dmitry

2017-11-29 17:21 GMT+00:00  :
> From: Dmitry Safonov 
>
> [ Upstream commit 2a4d0c627f5374f365a873dea4e10ae0bb437680 ]
>
> Kernel erases R8..R11 registers prior returning to userspace
> from int80:
>
>   https://lkml.org/lkml/2009/10/1/164
>
> GCC can reuse these registers and doesn't expect them to change
> during syscall invocation. I met this kind of bug in CRIU once
> GCC 6.1 and CLANG stored local variables in those registers
> and the kernel zerofied them during syscall:
>
>   
> https://github.com/xemul/criu/commit/990d33f1a1cdd17bca6c2eb059ab3be2564f7fa2
>
> By that reason I suggest to add those registers to clobbers
> in selftests.  Also, as noted by Andy - removed unneeded clobber
> for flags in INT $0x80 inline asm.
>
> Signed-off-by: Dmitry Safonov 
> Acked-by: Andy Lutomirski 
> Cc: 0x7f454...@gmail.com
> Cc: Borislav Petkov 
> Cc: Borislav Petkov 
> Cc: Brian Gerst 
> Cc: Denys Vlasenko 
> Cc: H. Peter Anvin 
> Cc: Josh Poimboeuf 
> Cc: Linus Torvalds 
> Cc: Peter Zijlstra 
> Cc: Shuah Khan 
> Cc: Thomas Gleixner 
> Cc: linux-kselft...@vger.kernel.org
> Link: http://lkml.kernel.org/r/20170213101336.20486-1-dsafo...@virtuozzo.com
> Signed-off-by: Ingo Molnar 
> Signed-off-by: Sasha Levin 
> ---
>  tools/testing/selftests/x86/fsgsbase.c|  2 +-
>  tools/testing/selftests/x86/ldt_gdt.c | 16 +++-
>  tools/testing/selftests/x86/ptrace_syscall.c  |  3 ++-
>  tools/testing/selftests/x86/single_step_syscall.c |  5 -
>  4 files changed, 18 insertions(+), 8 deletions(-)
>
> diff --git a/tools/testing/selftests/x86/fsgsbase.c 
> b/tools/testing/selftests/x86/fsgsbase.c
> index 9b4610c6d3fb..f249e042b3b5 100644
> --- a/tools/testing/selftests/x86/fsgsbase.c
> +++ b/tools/testing/selftests/x86/fsgsbase.c
> @@ -245,7 +245,7 @@ void do_unexpected_base(void)
> long ret;
> asm volatile ("int $0x80"
>   : "=a" (ret) : "a" (243), "b" (low_desc)
> - : "flags");
> + : "r8", "r9", "r10", "r11");
> memcpy(&desc, low_desc, sizeof(desc));
> munmap(low_desc, sizeof(desc));
>
> diff --git a/tools/testing/selftests/x86/ldt_gdt.c 
> b/tools/testing/selftests/x86/ldt_gdt.c
> index e717fed80219..b9a22f18566a 100644
> --- a/tools/testing/selftests/x86/ldt_gdt.c
> +++ b/tools/testing/selftests/x86/ldt_gdt.c
> @@ -45,6 +45,12 @@
>  #define AR_DB  (1 << 22)
>  #define AR_G   (1 << 23)
>
> +#ifdef __x86_64__
> +# define INT80_CLOBBERS "r8", "r9", "r10", "r11"
> +#else
> +# define INT80_CLOBBERS
> +#endif
> +
>  static int nerrs;
>
>  /* Points to an array of 1024 ints, each holding its own index. */
> @@ -634,7 +640,7 @@ static int invoke_set_thread_area(void)
> asm volatile ("int $0x80"
>   : "=a" (ret), "+m" (low_user_desc) :
> "a" (243), "b" (low_user_desc)
> - : "flags");
> + : INT80_CLOBBERS);
> return ret;
>  }
>
> @@ -703,7 +709,7 @@ static void test_gdt_invalidation(void)
> "+a" (eax)
>   : "m" (low_user_desc_clear),
> [arg1] "r" ((unsigned int)(unsigned 
> long)low_user_desc_clear)
> - : "flags");
> + : INT80_CLOBBERS);
>
> if (sel != 0) {
> result = "FAIL";
> @@ -734,7 +740,7 @@ static void test_gdt_invalidation(void)
> "+a" (eax)
>   : "m" (low_user_desc_clear),
> [arg1] "r" ((unsigned int)(unsigned 
> long)low_user_desc_clear)
> - : "flags");
> + : INT80_CLOBBERS);
>
> if (sel != 0) {
> result = "FAIL";
> @@ -767,7 +773,7 @@ static void test_gdt_invalidation(void)
> "+a" (eax)
>   : "m" (low_user_desc_clear),
> [arg1] "r" ((unsigned int)(unsigned 
> long)low_user_desc_clear)
> - : "flags");
> + : INT80_CLOBBERS);
>
>  #ifdef __x86_64__
> syscall(SYS_arch_prctl, ARCH_GET_FS, &new_base);
> @@ -820,7 +826,7 @@ static void test_gdt_invalidation(void)
> "+a" (eax)
>   : "m" (low_user_desc_clear),
> [arg1] "r" ((unsigned int)(unsigned 
> long)low_user_desc_clea

[PATCH AUTOSEL for 4.9 30/52] KVM: nVMX: reset nested_run_pending if the vCPU is going to be reset

[alexander . levin]

From: Wanpeng Li 

[ Upstream commit 2f707d97982286b307ef2a9b034e19aabc1abb56 ]

Reported by syzkaller:

WARNING: CPU: 1 PID: 27742 at arch/x86/kvm/vmx.c:11029
nested_vmx_vmexit+0x5c35/0x74d0 arch/x86/kvm/vmx.c:11029
CPU: 1 PID: 27742 Comm: a.out Not tainted 4.10.0+ #229
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
Call Trace:
 __dump_stack lib/dump_stack.c:15 [inline]
 dump_stack+0x2ee/0x3ef lib/dump_stack.c:51
 panic+0x1fb/0x412 kernel/panic.c:179
 __warn+0x1c4/0x1e0 kernel/panic.c:540
 warn_slowpath_null+0x2c/0x40 kernel/panic.c:583
 nested_vmx_vmexit+0x5c35/0x74d0 arch/x86/kvm/vmx.c:11029
 vmx_leave_nested arch/x86/kvm/vmx.c:11136 [inline]
 vmx_set_msr+0x1565/0x1910 arch/x86/kvm/vmx.c:3324
 kvm_set_msr+0xd4/0x170 arch/x86/kvm/x86.c:1099
 do_set_msr+0x11e/0x190 arch/x86/kvm/x86.c:1128
 __msr_io arch/x86/kvm/x86.c:2577 [inline]
 msr_io+0x24b/0x450 arch/x86/kvm/x86.c:2614
 kvm_arch_vcpu_ioctl+0x35b/0x46a0 arch/x86/kvm/x86.c:3497
 kvm_vcpu_ioctl+0x232/0x1120 arch/x86/kvm/../../../virt/kvm/kvm_main.c:2721
 vfs_ioctl fs/ioctl.c:43 [inline]
 do_vfs_ioctl+0x1bf/0x1790 fs/ioctl.c:683
 SYSC_ioctl fs/ioctl.c:698 [inline]
 SyS_ioctl+0x8f/0xc0 fs/ioctl.c:689
 entry_SYSCALL_64_fastpath+0x1f/0xc2

The syzkaller folks reported a nested_run_pending warning during userspace
clear VMX capability which is exposed to L1 before.

The warning gets thrown while doing

(*(uint32_t*)0x20aecfe8 = (uint32_t)0x1);
(*(uint32_t*)0x20aecfec = (uint32_t)0x0);
(*(uint32_t*)0x20aecff0 = (uint32_t)0x3a);
(*(uint32_t*)0x20aecff4 = (uint32_t)0x0);
(*(uint64_t*)0x20aecff8 = (uint64_t)0x0);
r[29] = syscall(__NR_ioctl, r[4], 0x4008ae89ul,
0x20aecfe8ul, 0, 0, 0, 0, 0, 0);

i.e. KVM_SET_MSR ioctl with

struct kvm_msrs {
.nmsrs = 1,
.pad = 0,
.entries = {
{.index = MSR_IA32_FEATURE_CONTROL,
 .reserved = 0,
 .data = 0}
}
}

The VMLANCH/VMRESUME emulation should be stopped since the CPU is going to
reset here. This patch resets the nested_run_pending since the CPU is going
to be reset hence there should be nothing pending.

Reported-by: Dmitry Vyukov 
Suggested-by: Radim Krčmář 
Cc: Paolo Bonzini 
Cc: Radim Krčmář 
Cc: Dmitry Vyukov 
Cc: David Hildenbrand 
Signed-off-by: Wanpeng Li 
Reviewed-by: David Hildenbrand 
Reviewed-by: Jim Mattson 
Signed-off-by: Radim Krčmář 
Signed-off-by: Sasha Levin 
---
 arch/x86/kvm/vmx.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 22476d2ce002..5c58bd60b45b 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -10885,8 +10885,10 @@ static void nested_vmx_vmexit(struct kvm_vcpu *vcpu, 
u32 exit_reason,
  */
 static void vmx_leave_nested(struct kvm_vcpu *vcpu)
 {
-   if (is_guest_mode(vcpu))
+   if (is_guest_mode(vcpu)) {
+   to_vmx(vcpu)->nested.nested_run_pending = 0;
nested_vmx_vmexit(vcpu, -1, 0, 0);
+   }
free_nested(to_vmx(vcpu));
 }
 
-- 
2.11.0

[PATCH AUTOSEL for 4.9 35/52] spi_ks8995: regs_size incorrect for some devices

[alexander . levin]

From: "Blomme, Maarten" 

[ Upstream commit 239870f2a0ebf75cc8f6d987dc528c5243f93d69 ]

Signed-off-by: Maarten Blomme 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin 
---
 drivers/net/phy/spi_ks8995.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/phy/spi_ks8995.c b/drivers/net/phy/spi_ks8995.c
index aa7209d794f3..1e2d4f1179da 100644
--- a/drivers/net/phy/spi_ks8995.c
+++ b/drivers/net/phy/spi_ks8995.c
@@ -491,8 +491,8 @@ static int ks8995_probe(struct spi_device *spi)
if (err)
return err;
 
-   ks->regs_attr.size = ks->chip->regs_size;
memcpy(&ks->regs_attr, &ks8995_registers_attr, sizeof(ks->regs_attr));
+   ks->regs_attr.size = ks->chip->regs_size;
 
err = ks8995_reset(ks);
if (err)
-- 
2.11.0

[PATCH AUTOSEL for 4.9 31/52] arm: KVM: Survive unknown traps from guests

[alexander . levin]

From: Mark Rutland 

[ Upstream commit f050fe7a9164945dd1c28be05bf00e8cfb082ccf ]

Currently we BUG() if we see a HSR.EC value we don't recognise. As
configurable disables/enables are added to the architecture (controlled
by RES1/RES0 bits respectively), with associated synchronous exceptions,
it may be possible for a guest to trigger exceptions with classes that
we don't recognise.

While we can't service these exceptions in a manner useful to the guest,
we can avoid bringing down the host. Per ARM DDI 0406C.c, all currently
unallocated HSR EC encodings are reserved, and per ARM DDI
0487A.k_iss10775, page G6-4395, EC values within the range 0x00 - 0x2c
are reserved for future use with synchronous exceptions, and EC values
within the range 0x2d - 0x3f may be used for either synchronous or
asynchronous exceptions.

The patch makes KVM handle any unknown EC by injecting an UNDEFINED
exception into the guest, with a corresponding (ratelimited) warning in
the host dmesg. We could later improve on this with with a new (opt-in)
exit to the host userspace.

Cc: Dave Martin 
Cc: Suzuki K Poulose 
Reviewed-by: Christoffer Dall 
Signed-off-by: Mark Rutland 
Signed-off-by: Marc Zyngier 
Signed-off-by: Sasha Levin 
---
 arch/arm/include/asm/kvm_arm.h |  1 +
 arch/arm/kvm/handle_exit.c | 19 ---
 2 files changed, 13 insertions(+), 7 deletions(-)

diff --git a/arch/arm/include/asm/kvm_arm.h b/arch/arm/include/asm/kvm_arm.h
index e22089fb44dc..a3f0b3d50089 100644
--- a/arch/arm/include/asm/kvm_arm.h
+++ b/arch/arm/include/asm/kvm_arm.h
@@ -209,6 +209,7 @@
 #define HSR_EC_IABT_HYP(0x21)
 #define HSR_EC_DABT(0x24)
 #define HSR_EC_DABT_HYP(0x25)
+#define HSR_EC_MAX (0x3f)
 
 #define HSR_WFI_IS_WFE (_AC(1, UL) << 0)
 
diff --git a/arch/arm/kvm/handle_exit.c b/arch/arm/kvm/handle_exit.c
index 066b6d4508ce..42f5daf715d0 100644
--- a/arch/arm/kvm/handle_exit.c
+++ b/arch/arm/kvm/handle_exit.c
@@ -79,7 +79,19 @@ static int kvm_handle_wfx(struct kvm_vcpu *vcpu, struct 
kvm_run *run)
return 1;
 }
 
+static int kvm_handle_unknown_ec(struct kvm_vcpu *vcpu, struct kvm_run *run)
+{
+   u32 hsr = kvm_vcpu_get_hsr(vcpu);
+
+   kvm_pr_unimpl("Unknown exception class: hsr: %#08x\n",
+ hsr);
+
+   kvm_inject_undefined(vcpu);
+   return 1;
+}
+
 static exit_handle_fn arm_exit_handlers[] = {
+   [0 ... HSR_EC_MAX]  = kvm_handle_unknown_ec,
[HSR_EC_WFI]= kvm_handle_wfx,
[HSR_EC_CP15_32]= kvm_handle_cp15_32,
[HSR_EC_CP15_64]= kvm_handle_cp15_64,
@@ -98,13 +110,6 @@ static exit_handle_fn kvm_get_exit_handler(struct kvm_vcpu 
*vcpu)
 {
u8 hsr_ec = kvm_vcpu_trap_get_class(vcpu);
 
-   if (hsr_ec >= ARRAY_SIZE(arm_exit_handlers) ||
-   !arm_exit_handlers[hsr_ec]) {
-   kvm_err("Unknown exception class: hsr: %#08x\n",
-   (unsigned int)kvm_vcpu_get_hsr(vcpu));
-   BUG();
-   }
-
return arm_exit_handlers[hsr_ec];
 }
 
-- 
2.11.0

[PATCH AUTOSEL for 4.4 04/32] selftest/powerpc: Fix false failures for skipped tests

[alexander . levin]

From: Sachin Sant 

[ Upstream commit a6d8a21596df041f36f4c2ccc260c459e3e851f1 ]

Tests under alignment subdirectory are skipped when executed on previous
generation hardware, but harness still marks them as failed.

  test: test_copy_unaligned
  tags: git_version:unknown
  [SKIP] Test skipped on line 26
  skip: test_copy_unaligned
  selftests: copy_unaligned [FAIL]

The MAGIC_SKIP_RETURN_VALUE value assigned to rc variable is retained till
the program exit which causes the test to be marked as failed.

This patch resets the value before returning to the main() routine.
With this patch the test o/p is as follows:

  test: test_copy_unaligned
  tags: git_version:unknown
  [SKIP] Test skipped on line 26
  skip: test_copy_unaligned
  selftests: copy_unaligned [PASS]

Signed-off-by: Sachin Sant 
Signed-off-by: Michael Ellerman 
Signed-off-by: Sasha Levin 
---
 tools/testing/selftests/powerpc/harness.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/tools/testing/selftests/powerpc/harness.c 
b/tools/testing/selftests/powerpc/harness.c
index f7997affd143..f45cee80c58b 100644
--- a/tools/testing/selftests/powerpc/harness.c
+++ b/tools/testing/selftests/powerpc/harness.c
@@ -109,9 +109,11 @@ int test_harness(int (test_function)(void), char *name)
 
rc = run_test(test_function, name);
 
-   if (rc == MAGIC_SKIP_RETURN_VALUE)
+   if (rc == MAGIC_SKIP_RETURN_VALUE) {
test_skip(name);
-   else
+   /* so that skipped test is not marked as failed */
+   rc = 0;
+   } else
test_finish(name, rc);
 
return rc;
-- 
2.11.0

[PATCH AUTOSEL for 4.4 07/32] ARM: OMAP2+: Release device node after it is no longer needed.

[alexander . levin]

From: Guenter Roeck 

[ Upstream commit b92675d998a9fa37fe9e0e35053a95b4a23c158b ]

The device node returned by of_find_node_by_name() needs to be released
after it is no longer needed to avoid a device node leak.

Signed-off-by: Guenter Roeck 
Signed-off-by: Tony Lindgren 
Signed-off-by: Sasha Levin 
---
 arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c 
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index 9ef0bd1676cd..13e22a4a5a20 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -3967,15 +3967,20 @@ int __init omap3xxx_hwmod_init(void)
 
if (h_sham && omap3xxx_hwmod_is_hs_ip_block_usable(bus, "sham")) {
r = omap_hwmod_register_links(h_sham);
-   if (r < 0)
+   if (r < 0) {
+   of_node_put(bus);
return r;
+   }
}
 
if (h_aes && omap3xxx_hwmod_is_hs_ip_block_usable(bus, "aes")) {
r = omap_hwmod_register_links(h_aes);
-   if (r < 0)
+   if (r < 0) {
+   of_node_put(bus);
return r;
+   }
}
+   of_node_put(bus);
 
/*
 * Register hwmod links specific to certain ES levels of a
-- 
2.11.0

[PATCH AUTOSEL for 4.4 03/32] x86/hpet: Prevent might sleep splat on resume

[alexander . levin]

From: Thomas Gleixner 

[ Upstream commit bb1a2c26165640ba2cbcfe06c81e9f9d6db4e643 ]

Sergey reported a might sleep warning triggered from the hpet resume
path. It's caused by the call to disable_irq() from interrupt disabled
context.

The problem with the low level resume code is that it is not accounted as a
special system_state like we do during the boot process. Calling the same
code during system boot would not trigger the warning. That's inconsistent
at best.

In this particular case it's trivial to replace the disable_irq() with
disable_hardirq() because this particular code path is solely used from
system resume and the involved hpet interrupts can never be force threaded.

Reported-and-tested-by: Sergey Senozhatsky 
Signed-off-by: Thomas Gleixner 
Cc: Peter Zijlstra 
Cc: "Rafael J. Wysocki" 
Cc: Sergey Senozhatsky 
Cc: Borislav Petkov 
Link: http://lkml.kernel.org/r/alpine.DEB.2.20.1703012108460.3684@nanos
Signed-off-by: Thomas Gleixner 
Signed-off-by: Sasha Levin 
---
 arch/x86/kernel/hpet.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/kernel/hpet.c b/arch/x86/kernel/hpet.c
index acc9b8f19ca8..f48eb8eeefe2 100644
--- a/arch/x86/kernel/hpet.c
+++ b/arch/x86/kernel/hpet.c
@@ -353,7 +353,7 @@ static int hpet_resume(struct clock_event_device *evt, int 
timer)
 
irq_domain_deactivate_irq(irq_get_irq_data(hdev->irq));
irq_domain_activate_irq(irq_get_irq_data(hdev->irq));
-   disable_irq(hdev->irq);
+   disable_hardirq(hdev->irq);
irq_set_affinity(hdev->irq, cpumask_of(hdev->cpu));
enable_irq(hdev->irq);
}
-- 
2.11.0

[PATCH AUTOSEL for 4.4 08/32] gpio: altera: Use handle_level_irq when configured as a level_high

[alexander . levin]

From: Phil Reid 

[ Upstream commit f759921cfbf4847319d197a6ed7c9534d593f8bc ]

When a threaded irq handler is chained attached to one of the gpio
pins when configure for level irq the altera_gpio_irq_leveL_high_handler
does not mask the interrupt while being handled by the chained irq.
This resulting in the threaded irq not getting enough cycles to complete
quickly enough before the irq was disabled as faulty. handle_level_irq
should be used in this situation instead of handle_simple_irq.

In gpiochip_irqchip_add set default handler to handle_bad_irq as
per Documentation/gpio/driver.txt. Then set the correct handler in
the set_type callback.

Signed-off-by: Phil Reid 
Signed-off-by: Linus Walleij 
Signed-off-by: Sasha Levin 
---
 drivers/gpio/gpio-altera.c | 26 +++---
 1 file changed, 11 insertions(+), 15 deletions(-)

diff --git a/drivers/gpio/gpio-altera.c b/drivers/gpio/gpio-altera.c
index 3e6661bab54a..ddf9cd3ad974 100644
--- a/drivers/gpio/gpio-altera.c
+++ b/drivers/gpio/gpio-altera.c
@@ -94,21 +94,18 @@ static int altera_gpio_irq_set_type(struct irq_data *d,
 
altera_gc = to_altera(irq_data_get_irq_chip_data(d));
 
-   if (type == IRQ_TYPE_NONE)
+   if (type == IRQ_TYPE_NONE) {
+   irq_set_handler_locked(d, handle_bad_irq);
return 0;
-   if (type == IRQ_TYPE_LEVEL_HIGH &&
-   altera_gc->interrupt_trigger == IRQ_TYPE_LEVEL_HIGH)
-   return 0;
-   if (type == IRQ_TYPE_EDGE_RISING &&
-   altera_gc->interrupt_trigger == IRQ_TYPE_EDGE_RISING)
-   return 0;
-   if (type == IRQ_TYPE_EDGE_FALLING &&
-   altera_gc->interrupt_trigger == IRQ_TYPE_EDGE_FALLING)
-   return 0;
-   if (type == IRQ_TYPE_EDGE_BOTH &&
-   altera_gc->interrupt_trigger == IRQ_TYPE_EDGE_BOTH)
+   }
+   if (type == altera_gc->interrupt_trigger) {
+   if (type == IRQ_TYPE_LEVEL_HIGH)
+   irq_set_handler_locked(d, handle_level_irq);
+   else
+   irq_set_handler_locked(d, handle_simple_irq);
return 0;
-
+   }
+   irq_set_handler_locked(d, handle_bad_irq);
return -EINVAL;
 }
 
@@ -234,7 +231,6 @@ static void altera_gpio_irq_edge_handler(struct irq_desc 
*desc)
chained_irq_exit(chip, desc);
 }
 
-
 static void altera_gpio_irq_leveL_high_handler(struct irq_desc *desc)
 {
struct altera_gpio_chip *altera_gc;
@@ -314,7 +310,7 @@ static int altera_gpio_probe(struct platform_device *pdev)
altera_gc->interrupt_trigger = reg;
 
ret = gpiochip_irqchip_add(&altera_gc->mmchip.gc, &altera_irq_chip, 0,
-   handle_simple_irq, IRQ_TYPE_NONE);
+   handle_bad_irq, IRQ_TYPE_NONE);
 
if (ret) {
dev_info(&pdev->dev, "could not add irqchip\n");
-- 
2.11.0

[PATCH AUTOSEL for 4.4 13/32] libata: drop WARN from protocol error in ata_sff_qc_issue()

[alexander . levin]

From: Tejun Heo 

[ Upstream commit 0580b762a4d6b70817476b90042813f8573283fa ]

ata_sff_qc_issue() expects upper layers to never issue commands on a
command protocol that it doesn't implement.  While the assumption
holds fine with the usual IO path, nothing filters based on the
command protocol in the passthrough path (which was added later),
allowing the warning to be tripped with a passthrough command with the
right (well, wrong) protocol.

Failing with AC_ERR_SYSTEM is the right thing to do anyway.  Remove
the unnecessary WARN.

Reported-by: Dmitry Vyukov 
Link: 
http://lkml.kernel.org/r/cact4y+bxkvevnzu8up6x0qvqsj6wnoua_1exftsozc+smut...@mail.gmail.com
Signed-off-by: Tejun Heo 
Signed-off-by: Sasha Levin 
---
 drivers/ata/libata-sff.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/ata/libata-sff.c b/drivers/ata/libata-sff.c
index 7dbba387d12a..18de4c457068 100644
--- a/drivers/ata/libata-sff.c
+++ b/drivers/ata/libata-sff.c
@@ -1480,7 +1480,6 @@ unsigned int ata_sff_qc_issue(struct ata_queued_cmd *qc)
break;
 
default:
-   WARN_ON_ONCE(1);
return AC_ERR_SYSTEM;
}
 
-- 
2.11.0

[PATCH AUTOSEL for 4.4 06/32] ARM: OMAP2+: Fix device node reference counts

[alexander . levin]

From: Guenter Roeck 

[ Upstream commit 10e5778f54765c96fe0c8f104b7a030e5b35bc72 ]

After commit 0549bde0fcb1 ("of: fix of_node leak caused in
of_find_node_opts_by_path"), the following error may be
reported when running omap images.

OF: ERROR: Bad of_node_put() on /ocp@6800
CPU: 0 PID: 0 Comm: swapper Not tainted 4.10.0-rc7-next-20170210 #1
Hardware name: Generic OMAP3-GP (Flattened Device Tree)
[] (unwind_backtrace) from [] (show_stack+0x10/0x14)
[] (show_stack) from [] (dump_stack+0x98/0xac)
[] (dump_stack) from [] (kobject_release+0x48/0x7c)
[] (kobject_release)
from [] (of_find_node_by_name+0x74/0x94)
[] (of_find_node_by_name)
from [] (omap3xxx_hwmod_is_hs_ip_block_usable+0x24/0x2c)
[] (omap3xxx_hwmod_is_hs_ip_block_usable) from
[] (omap3xxx_hwmod_init+0x180/0x274)
[] (omap3xxx_hwmod_init)
from [] (omap3_init_early+0xa0/0x11c)
[] (omap3_init_early)
from [] (omap3430_init_early+0x8/0x30)
[] (omap3430_init_early)
from [] (setup_arch+0xc04/0xc34)
[] (setup_arch) from [] (start_kernel+0x68/0x38c)
[] (start_kernel) from [<8020807c>] (0x8020807c)

of_find_node_by_name() drops the reference to the passed device node.
The commit referenced above exposes this problem.

To fix the problem, use of_get_child_by_name() instead of
of_find_node_by_name(); of_get_child_by_name() does not drop
the reference count of passed device nodes. While semantically
different, we only look for immediate children of the passed
device node, so of_get_child_by_name() is a more appropriate
function to use anyway.

Release the reference to the device node obtained with
of_get_child_by_name() after it is no longer needed to avoid
another device node leak.

While at it, clean up the code and change the return type of
omap3xxx_hwmod_is_hs_ip_block_usable() to bool to match its use
and the return type of of_device_is_available().

Cc: Qi Hou 
Cc: Peter Rosin 
Cc: Rob Herring 
Signed-off-by: Guenter Roeck 
Signed-off-by: Tony Lindgren 
Signed-off-by: Sasha Levin 
---
 arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 16 ++--
 1 file changed, 10 insertions(+), 6 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c 
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index 131f8967589b..9ef0bd1676cd 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -3885,16 +3885,20 @@ static struct omap_hwmod_ocp_if 
*omap3xxx_dss_hwmod_ocp_ifs[] __initdata = {
  * Return: 0 if device named @dev_name is not likely to be accessible,
  * or 1 if it is likely to be accessible.
  */
-static int __init omap3xxx_hwmod_is_hs_ip_block_usable(struct device_node *bus,
-  const char *dev_name)
+static bool __init omap3xxx_hwmod_is_hs_ip_block_usable(struct device_node 
*bus,
+   const char *dev_name)
 {
+   struct device_node *node;
+   bool available;
+
if (!bus)
-   return (omap_type() == OMAP2_DEVICE_TYPE_GP) ? 1 : 0;
+   return omap_type() == OMAP2_DEVICE_TYPE_GP;
 
-   if (of_device_is_available(of_find_node_by_name(bus, dev_name)))
-   return 1;
+   node = of_get_child_by_name(bus, dev_name);
+   available = of_device_is_available(node);
+   of_node_put(node);
 
-   return 0;
+   return available;
 }
 
 int __init omap3xxx_hwmod_init(void)
-- 
2.11.0

Re: [Xen-devel] [PATCH V2] Xen/pciback: Implement PCI slot or bus reset with 'do_flr' SysFS attribute

[Govinda Tatti]

In the case of bus or slot reset, our goal is to reset connected PCIe
fabric/card/endpoint.
The connected card/endpoint can be multi-function device. So, same
walk-through and checking
is needed irrespective of type of reset being used.

I don't follow: The scope of other devices/functions possibly
affected by a reset depends on the type of reset, doesn't it?

For PCIe platforms, both slot and bus reset endup resetting all connected
device/functions on thesecondary bus (behind the root-port or 
downstream-port).


Cheers
GOVINDA

Re: [PATCH] jsm_tty: Fix a possible null pointer dereference in two functions

[Joe Perches]

On Wed, 2017-11-29 at 17:40 +0100, SF Markus Elfring wrote:
> From: Markus Elfring 
> Date: Wed, 29 Nov 2017 17:30:36 +0100
> 
> Move two debug messages so that a null pointer access can not happen
> for the variable "ch" in these functions.

An actual defect fix!

Here you could probably cc stable too.

> 
> This issue was detected by using the Coccinelle software.
> 
> Fixes: 669fef464468d3f02d60a5cf725fc097e03c5cb8 ("serial: jsm: Convert 
> jsm_printk to jsm_dbg")
> 
> Signed-off-by: Markus Elfring 
> ---
>  drivers/tty/serial/jsm/jsm_tty.c | 5 ++---
>  1 file changed, 2 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/tty/serial/jsm/jsm_tty.c 
> b/drivers/tty/serial/jsm/jsm_tty.c
> index 469927d37b41..a34eed7344e5 100644
> --- a/drivers/tty/serial/jsm/jsm_tty.c
> +++ b/drivers/tty/serial/jsm/jsm_tty.c
> @@ -521,11 +521,10 @@ void jsm_input(struct jsm_channel *ch)
>   int s = 0;
>   int i = 0;
>  
> - jsm_dbg(READ, &ch->ch_bd->pci_dev, "start\n");
> -
>   if (!ch)
>   return;
>  
> + jsm_dbg(READ, &ch->ch_bd->pci_dev, "start\n");
>   port = &ch->uart_port.state->port;
>   tp = port->tty;
>  
> @@ -647,10 +646,10 @@ static void jsm_carrier(struct jsm_channel *ch)
>   int virt_carrier = 0;
>   int phys_carrier = 0;
>  
> - jsm_dbg(CARR, &ch->ch_bd->pci_dev, "start\n");
>   if (!ch)
>   return;
>  
> + jsm_dbg(CARR, &ch->ch_bd->pci_dev, "start\n");
>   bd = ch->ch_bd;
>  
>   if (!bd)

Re: [PATCH 1/3] kbuild: add clang-version.sh

[Nick Desaulniers]

+# clang-version [-p] clang-command
+#
+# Prints the compiler version of `command' in a canonical 4-digit form

small nit: `command` should be `clang-command`, but its just a comment
(maybe the maintainer can make that change when/if applying).

The conditional at the end to see if $with_patchlevel using "x" is
odd, but this is what scripts/gcc-version.sh does and this patch does
work as expected.

Tested-by: Nick Desaulniers 

Re: [v2,01/12] hwrng: bcm2835 - Obtain base register via resource

[Florian Fainelli]

On 11/28/2017 10:30 PM, Herbert Xu wrote:
> On Tue, Nov 07, 2017 at 04:44:38PM -0800, Florian Fainelli wrote:
>> In preparation for consolidating bcm63xx-rng into bcm2835-rng, make sure
>> that we obtain the base register via platform_get_resource() since we
>> need to support the non-DT enabled MIPS-based BCM63xx DSL SoCs.
>>
>> Signed-off-by: Florian Fainelli 
> 
> All applied.  Thanks.

Hu, okay, I actually had a v3 prepared that I was going to post
addressing some of the comments. Should I send an incremental set of
changes now?
-- 
Florian

Re: [PATCH V2 6/7] PCI: add device wait after slot and bus reset

[Christoph Hellwig]

On Mon, Nov 27, 2017 at 01:20:27AM -0500, Sinan Kaya wrote:
> Rev 3.1 Sec 2.3.1 Request Handling Rules indicates that a device can issue
> CRS following secondary bus reset. Handle device presence gracefully.
> 
> Signed-off-by: Sinan Kaya 

Looks good,

Reviewed-by: Christoph Hellwig 

Re: [PATCH V2 5/7] PCI: add a return type for pci_reset_bridge_secondary_bus()

[Christoph Hellwig]

On Mon, Nov 27, 2017 at 01:20:26AM -0500, Sinan Kaya wrote:
> Getting ready to return an error from pci_reset_bridge_secondary_bus() when
> device is unreachable.
> 
> Signed-off-by: Sinan Kaya 

Looks ok, but I would just merge it into the next patch.

Reviewed-by: Christoph Hellwig 

Re: [PATCH v2 2/2] pinctrl: Allow indicating loss of pin states during low-power

[Florian Fainelli]

On 11/29/2017 09:02 AM, Tony Lindgren wrote:
> * Linus Walleij  [171129 13:03]:
>> On Fri, Nov 3, 2017 at 12:15 AM, Florian Fainelli  
>> wrote:
>>
>>> Some platforms (e.g: Broadcom STB: BMIPS_GENERIC/ARCH_BRCMSTB) will lose
>>> their register contents when entering their lower power state. In such a
>>> case, the pinctrl-single driver that is used will not be able to restore
>>> the power states without telling the core about it and having
>>> pinctrl_select_state() check for that.
>>>
>>> This patch adds a new optional boolean property that Device Tree can
>>> define in order to obtain exactly that and having the core pinctrl code
>>> take that into account.
>>>
>>> Signed-off-by: Florian Fainelli 
>>
>> Florian, I'm really sorry for losing track of this patch set, it's
>> important stuff and I see why systems are dependent on something
>> like this.
>>
>> Tony: can you look at this from a pinctrl-single point of view?
>> This is the intended consumer: pinctrl-single users that lose the
>> hardware state over suspend/resume.
>>
>> How do you see this working with other pinctrl-single users?
> 
> Hmm well typically a device driver that loses it's context just does
> save and restore of the registers in runtime PM suspend/resume
> as needed. In this case it would mean duplicating the state for
> potentially for hundreds of registers.. So using the existing
> state in the pinctrl subsystem totally makes sense for the pins.
> 
> Florian do you have other reasons why this should be done in the
> pinctrl framework instead of the driver? Might be worth describing
> the reasoning in the patch descriptions :)

The pinctrl provider driver that I am using is pinctrl-single, which has
proper suspend/resume callbacks but those are not causing any HW
programming to happen because of the (p->state == state) check, hence
this patch series.

> 
> So as long as the pinctrl framework state is used to restore the
> state by the pinctrl driver instead of the pinctrl consumer drivers,
> I don't have issues with this patchset. So probably just improving
> the patch messages a bit should do it.
> 
> FYI, on omaps, the PRCM hardware saves and restores the pinctrl
> state so this has not been so far an issue.
> 
> Regards,
> 
> Tony
> 
> 


-- 
Florian

Re: [PATCH V2 3/7] PCI: make pci_flr_wait() generic and rename to pci_dev_wait()

[Christoph Hellwig]

On Mon, Nov 27, 2017 at 01:20:24AM -0500, Sinan Kaya wrote:
> Rev 3.1 Sec 2.3.1 Request Handling Rules:
> Valid reset conditions after which a device is permitted to return CRS
> are:
> * Cold, Warm, and Hot Resets,
> * FLR
> * A reset initiated in response to a D3hot to D0 uninitialized
> 
> Try to reuse FLR implementation towards other reset types.

Should we keep a helper for the FLR wait?  If not I guess the reference
for AF_FLR should be the PCI spec, not the PCIE spec.

Re: [PATCH V2 4/7] PCI: wait device ready after pci_pm_reset()

[Christoph Hellwig]

Looks good,

Reviewed-by: Christoph Hellwig 

[PATCH AUTOSEL for 4.4 19/32] arm64: KVM: Survive unknown traps from guests

[alexander . levin]

From: Mark Rutland 

[ Upstream commit ba4dd156eabdca93501d92a980ba27fa5f4bbd27 ]

Currently we BUG() if we see an ESR_EL2.EC value we don't recognise. As
configurable disables/enables are added to the architecture (controlled
by RES1/RES0 bits respectively), with associated synchronous exceptions,
it may be possible for a guest to trigger exceptions with classes that
we don't recognise.

While we can't service these exceptions in a manner useful to the guest,
we can avoid bringing down the host. Per ARM DDI 0487A.k_iss10775, page
D7-1937, EC values within the range 0x00 - 0x2c are reserved for future
use with synchronous exceptions, and EC values within the range 0x2d -
0x3f may be used for either synchronous or asynchronous exceptions.

The patch makes KVM handle any unknown EC by injecting an UNDEFINED
exception into the guest, with a corresponding (ratelimited) warning in
the host dmesg. We could later improve on this with with a new (opt-in)
exit to the host userspace.

Cc: Dave Martin 
Cc: Suzuki K Poulose 
Reviewed-by: Christoffer Dall 
Signed-off-by: Mark Rutland 
Signed-off-by: Marc Zyngier 
Signed-off-by: Sasha Levin 
---
 arch/arm64/kvm/handle_exit.c | 19 ---
 1 file changed, 12 insertions(+), 7 deletions(-)

diff --git a/arch/arm64/kvm/handle_exit.c b/arch/arm64/kvm/handle_exit.c
index 15f0477b0d2a..ba93a09eb536 100644
--- a/arch/arm64/kvm/handle_exit.c
+++ b/arch/arm64/kvm/handle_exit.c
@@ -121,7 +121,19 @@ static int kvm_handle_guest_debug(struct kvm_vcpu *vcpu, 
struct kvm_run *run)
return ret;
 }
 
+static int kvm_handle_unknown_ec(struct kvm_vcpu *vcpu, struct kvm_run *run)
+{
+   u32 hsr = kvm_vcpu_get_hsr(vcpu);
+
+   kvm_pr_unimpl("Unknown exception class: hsr: %#08x -- %s\n",
+ hsr, esr_get_class_string(hsr));
+
+   kvm_inject_undefined(vcpu);
+   return 1;
+}
+
 static exit_handle_fn arm_exit_handlers[] = {
+   [0 ... ESR_ELx_EC_MAX]  = kvm_handle_unknown_ec,
[ESR_ELx_EC_WFx]= kvm_handle_wfx,
[ESR_ELx_EC_CP15_32]= kvm_handle_cp15_32,
[ESR_ELx_EC_CP15_64]= kvm_handle_cp15_64,
@@ -147,13 +159,6 @@ static exit_handle_fn kvm_get_exit_handler(struct kvm_vcpu 
*vcpu)
u32 hsr = kvm_vcpu_get_hsr(vcpu);
u8 hsr_ec = hsr >> ESR_ELx_EC_SHIFT;
 
-   if (hsr_ec >= ARRAY_SIZE(arm_exit_handlers) ||
-   !arm_exit_handlers[hsr_ec]) {
-   kvm_err("Unknown exception class: hsr: %#08x -- %s\n",
-   hsr, esr_get_class_string(hsr));
-   BUG();
-   }
-
return arm_exit_handlers[hsr_ec];
 }
 
-- 
2.11.0

[PATCH AUTOSEL for 4.4 21/32] bnx2x: prevent crash when accessing PTP with interface down

[alexander . levin]

From: Michal Schmidt 

[ Upstream commit 466e8bf10ac104d96e1ea813e8126e11cb72ea20 ]

It is possible to crash the kernel by accessing a PTP device while its
associated bnx2x interface is down. Before the interface is brought up,
the timecounter is not initialized, so accessing it results in NULL
dereference.

Fix it by checking if the interface is up.

Use -ENETDOWN as the error code when the interface is down.
 -EFAULT in bnx2x_ptp_adjfreq() did not seem right.

Tested using phc_ctl get/set/adj/freq commands.

Signed-off-by: Michal Schmidt 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin 
---
 drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c | 20 +++-
 1 file changed, 19 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c 
b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
index 1c8123816745..abb3ff6498dc 100644
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
@@ -13646,7 +13646,7 @@ static int bnx2x_ptp_adjfreq(struct ptp_clock_info 
*ptp, s32 ppb)
if (!netif_running(bp->dev)) {
DP(BNX2X_MSG_PTP,
   "PTP adjfreq called while the interface is down\n");
-   return -EFAULT;
+   return -ENETDOWN;
}
 
if (ppb < 0) {
@@ -13705,6 +13705,12 @@ static int bnx2x_ptp_adjtime(struct ptp_clock_info 
*ptp, s64 delta)
 {
struct bnx2x *bp = container_of(ptp, struct bnx2x, ptp_clock_info);
 
+   if (!netif_running(bp->dev)) {
+   DP(BNX2X_MSG_PTP,
+  "PTP adjtime called while the interface is down\n");
+   return -ENETDOWN;
+   }
+
DP(BNX2X_MSG_PTP, "PTP adjtime called, delta = %llx\n", delta);
 
timecounter_adjtime(&bp->timecounter, delta);
@@ -13717,6 +13723,12 @@ static int bnx2x_ptp_gettime(struct ptp_clock_info 
*ptp, struct timespec64 *ts)
struct bnx2x *bp = container_of(ptp, struct bnx2x, ptp_clock_info);
u64 ns;
 
+   if (!netif_running(bp->dev)) {
+   DP(BNX2X_MSG_PTP,
+  "PTP gettime called while the interface is down\n");
+   return -ENETDOWN;
+   }
+
ns = timecounter_read(&bp->timecounter);
 
DP(BNX2X_MSG_PTP, "PTP gettime called, ns = %llu\n", ns);
@@ -13732,6 +13744,12 @@ static int bnx2x_ptp_settime(struct ptp_clock_info 
*ptp,
struct bnx2x *bp = container_of(ptp, struct bnx2x, ptp_clock_info);
u64 ns;
 
+   if (!netif_running(bp->dev)) {
+   DP(BNX2X_MSG_PTP,
+  "PTP settime called while the interface is down\n");
+   return -ENETDOWN;
+   }
+
ns = timespec64_to_ns(ts);
 
DP(BNX2X_MSG_PTP, "PTP settime called, ns = %llu\n", ns);
-- 
2.11.0

[PATCH AUTOSEL for 4.4 22/32] bnx2x: fix possible overrun of VFPF multicast addresses array

[alexander . levin]

From: Michal Schmidt 

[ Upstream commit 22118d861cec5da6ed525aaf12a3de9bfeffc58f ]

It is too late to check for the limit of the number of VF multicast
addresses after they have already been copied to the req->multicast[]
array, possibly overflowing it.

Do the check before copying.

Also fix the error path to not skip unlocking vf2pf_mutex.

Signed-off-by: Michal Schmidt 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin 
---
 drivers/net/ethernet/broadcom/bnx2x/bnx2x_vfpf.c | 23 +++
 1 file changed, 11 insertions(+), 12 deletions(-)

diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_vfpf.c 
b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_vfpf.c
index 1374e5394a79..a12a4236b143 100644
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_vfpf.c
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_vfpf.c
@@ -868,7 +868,7 @@ int bnx2x_vfpf_set_mcast(struct net_device *dev)
struct bnx2x *bp = netdev_priv(dev);
struct vfpf_set_q_filters_tlv *req = &bp->vf2pf_mbox->req.set_q_filters;
struct pfvf_general_resp_tlv *resp = &bp->vf2pf_mbox->resp.general_resp;
-   int rc, i = 0;
+   int rc = 0, i = 0;
struct netdev_hw_addr *ha;
 
if (bp->state != BNX2X_STATE_OPEN) {
@@ -883,6 +883,15 @@ int bnx2x_vfpf_set_mcast(struct net_device *dev)
/* Get Rx mode requested */
DP(NETIF_MSG_IFUP, "dev->flags = %x\n", dev->flags);
 
+   /* We support PFVF_MAX_MULTICAST_PER_VF mcast addresses tops */
+   if (netdev_mc_count(dev) > PFVF_MAX_MULTICAST_PER_VF) {
+   DP(NETIF_MSG_IFUP,
+  "VF supports not more than %d multicast MAC addresses\n",
+  PFVF_MAX_MULTICAST_PER_VF);
+   rc = -EINVAL;
+   goto out;
+   }
+
netdev_for_each_mc_addr(ha, dev) {
DP(NETIF_MSG_IFUP, "Adding mcast MAC: %pM\n",
   bnx2x_mc_addr(ha));
@@ -890,16 +899,6 @@ int bnx2x_vfpf_set_mcast(struct net_device *dev)
i++;
}
 
-   /* We support four PFVF_MAX_MULTICAST_PER_VF mcast
- * addresses tops
- */
-   if (i >= PFVF_MAX_MULTICAST_PER_VF) {
-   DP(NETIF_MSG_IFUP,
-  "VF supports not more than %d multicast MAC addresses\n",
-  PFVF_MAX_MULTICAST_PER_VF);
-   return -EINVAL;
-   }
-
req->n_multicast = i;
req->flags |= VFPF_SET_Q_FILTERS_MULTICAST_CHANGED;
req->vf_qid = 0;
@@ -924,7 +923,7 @@ int bnx2x_vfpf_set_mcast(struct net_device *dev)
 out:
bnx2x_vfpf_finalize(bp, &req->first_tlv);
 
-   return 0;
+   return rc;
 }
 
 /* request pf to add a vlan for the vf */
-- 
2.11.0

Re: [PATCH V2 2/7] PCI: handle FLR failure and allow other reset types

[Christoph Hellwig]

On Mon, Nov 27, 2017 at 01:20:23AM -0500, Sinan Kaya wrote:
> pci_flr_wait() and pci_af_flr() functions assume graceful return even
> though the device is inaccessible under error conditions.
> 
> Return -ENOTTY in error cases so that __pci_reset_function_locked() can
> try other reset types if AF_FLR/FLR reset fails.

Looks good,

Reviewed-by: Christoph Hellwig 

[PATCH AUTOSEL for 4.4 23/32] bnx2x: do not rollback VF MAC/VLAN filters we did not configure

[alexander . levin]

From: Michal Schmidt 

[ Upstream commit 78d5505432436516456c12abbe705ec8dee7ee2b ]

On failure to configure a VF MAC/VLAN filter we should not attempt to
rollback filters that we failed to configure with -EEXIST.

Signed-off-by: Michal Schmidt 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin 
---
 drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.c | 8 +++-
 drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.h | 1 +
 2 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.c 
b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.c
index 9d027348cd09..5780830f78ad 100644
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.c
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.c
@@ -434,7 +434,9 @@ static int bnx2x_vf_mac_vlan_config(struct bnx2x *bp,
 
/* Add/Remove the filter */
rc = bnx2x_config_vlan_mac(bp, &ramrod);
-   if (rc && rc != -EEXIST) {
+   if (rc == -EEXIST)
+   return 0;
+   if (rc) {
BNX2X_ERR("Failed to %s %s\n",
  filter->add ? "add" : "delete",
  (filter->type == BNX2X_VF_FILTER_VLAN_MAC) ?
@@ -444,6 +446,8 @@ static int bnx2x_vf_mac_vlan_config(struct bnx2x *bp,
return rc;
}
 
+   filter->applied = true;
+
return 0;
 }
 
@@ -471,6 +475,8 @@ int bnx2x_vf_mac_vlan_config_list(struct bnx2x *bp, struct 
bnx2x_virtf *vf,
BNX2X_ERR("Managed only %d/%d filters - rolling back\n",
  i, filters->count + 1);
while (--i >= 0) {
+   if (!filters->filters[i].applied)
+   continue;
filters->filters[i].add = !filters->filters[i].add;
bnx2x_vf_mac_vlan_config(bp, vf, qid,
 &filters->filters[i],
diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.h 
b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.h
index 670a581ffabc..6f6f13dc2be3 100644
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.h
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.h
@@ -114,6 +114,7 @@ struct bnx2x_vf_mac_vlan_filter {
(BNX2X_VF_FILTER_MAC | BNX2X_VF_FILTER_VLAN) /*shortcut*/
 
bool add;
+   bool applied;
u8 *mac;
u16 vid;
 };
-- 
2.11.0

Re: [PATCH V2 1/7] PCI: protect restore with device lock to be consistent

[Christoph Hellwig]

On Mon, Nov 27, 2017 at 01:20:22AM -0500, Sinan Kaya wrote:
> Commit b014e96d1abb ("PCI: Protect pci_error_handlers->reset_notify() usage
> with device_lock()") added protection around pci_dev_restore() function so
> that device specific remove callback does not cause a race condition
> against hotplug.
> 
> pci_dev_lock() usage has been forgotten in two different places in the
> code. Adding locks for pci_slot_restore() and moving pci_dev_restore()
> inside the locks for pci_try_reset_function().
> 
> Signed-off-by: Sinan Kaya 

Looks good,

Reviewed-by: Christoph Hellwig 

[PATCH AUTOSEL for 4.4 14/32] workqueue: trigger WARN if queue_delayed_work() is called with NULL @wq

[alexander . levin]

From: Tejun Heo 

[ Upstream commit 637fdbae60d6cb9f6e963c1079d7e0445c86ff7d ]

If queue_delayed_work() gets called with NULL @wq, the kernel will
oops asynchronuosly on timer expiration which isn't too helpful in
tracking down the offender.  This actually happened with smc.

__queue_delayed_work() already does several input sanity checks
synchronously.  Add NULL @wq check.

Reported-by: Dave Jones 
Link: http://lkml.kernel.org/r/20170227171439.jshx3qplflyrg...@codemonkey.org.uk
Signed-off-by: Tejun Heo 
Signed-off-by: Sasha Levin 
---
 kernel/workqueue.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/kernel/workqueue.c b/kernel/workqueue.c
index 95cc76785a12..8eb4d3cb 100644
--- a/kernel/workqueue.c
+++ b/kernel/workqueue.c
@@ -1479,6 +1479,7 @@ static void __queue_delayed_work(int cpu, struct 
workqueue_struct *wq,
struct timer_list *timer = &dwork->timer;
struct work_struct *work = &dwork->work;
 
+   WARN_ON_ONCE(!wq);
WARN_ON_ONCE(timer->function != delayed_work_timer_fn ||
 timer->data != (unsigned long)dwork);
WARN_ON_ONCE(timer_pending(timer));
-- 
2.11.0

Re: [PATCH v2 1/2] pinctrl: Allow a device to indicate when to force a state

[Florian Fainelli]

On 11/29/2017 09:01 AM, Tony Lindgren wrote:
> * Florian Fainelli  [171102 23:18]:
>> It may happen that a device needs to force applying a state, e.g:
>> because it only defines one state of pin states (default) but loses
>> power/register contents when entering low power modes. Add a
>> pinctrl_dev::flags bitmask to help describe future quirks and define
>> PINCTRL_FLG_FORCE_STATE as such a settable flag.
> 
> It makes sense to tag the existing state with the context loss
> information as otherwise we'll be duplicating the state in the
> pinctrl driver potentially for hundreds of pins.
> 
> Maybe this patch description should clarify that it's the
> pinctrl device restoring the pin state, not the pinctrl
> consumer devices?
> 
> So maybe just "a pinctrl device needs to force apply a state"
> instead of just device above?

It's a bit more involved than that, the pinctrl consumer device might
want to restore a particular state by calling pinctrl_select_state(),
however, because of the (p->state == state)check, the pinctrl provider
driver has no chance of making that call do the actual HW programming.
-- 
Florian

[PATCH AUTOSEL for 4.4 25/32] crypto: s5p-sss - Fix completing crypto request in IRQ handler

[alexander . levin]

From: Krzysztof Kozlowski 

[ Upstream commit 07de4bc88ce6a4d898cad9aa4c99c1df7e87702d ]

In a regular interrupt handler driver was finishing the crypt/decrypt
request by calling complete on crypto request.  This is disallowed since
converting to skcipher in commit b286d8b1a690 ("crypto: skcipher - Add
skcipher walk interface") and causes a warning:
WARNING: CPU: 0 PID: 0 at crypto/skcipher.c:430 
skcipher_walk_first+0x13c/0x14c

The interrupt is marked shared but in fact there are no other users
sharing it.  Thus the simplest solution seems to be to just use a
threaded interrupt handler, after converting it to oneshot.

Signed-off-by: Krzysztof Kozlowski 
Signed-off-by: Herbert Xu 
Signed-off-by: Sasha Levin 
---
 drivers/crypto/s5p-sss.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/crypto/s5p-sss.c b/drivers/crypto/s5p-sss.c
index f214a8755827..fd39893079d5 100644
--- a/drivers/crypto/s5p-sss.c
+++ b/drivers/crypto/s5p-sss.c
@@ -664,8 +664,9 @@ static int s5p_aes_probe(struct platform_device *pdev)
dev_warn(dev, "feed control interrupt is not available.\n");
goto err_irq;
}
-   err = devm_request_irq(dev, pdata->irq_fc, s5p_aes_interrupt,
-  IRQF_SHARED, pdev->name, pdev);
+   err = devm_request_threaded_irq(dev, pdata->irq_fc, NULL,
+   s5p_aes_interrupt, IRQF_ONESHOT,
+   pdev->name, pdev);
if (err < 0) {
dev_warn(dev, "feed control interrupt is not available.\n");
goto err_irq;
-- 
2.11.0

Re: [PATCH] jsm_tty: Fix a possible null pointer dereference in two functions

[Greg Kroah-Hartman]

On Wed, Nov 29, 2017 at 09:23:07AM -0800, Joe Perches wrote:
> On Wed, 2017-11-29 at 17:40 +0100, SF Markus Elfring wrote:
> > From: Markus Elfring 
> > Date: Wed, 29 Nov 2017 17:30:36 +0100
> > 
> > Move two debug messages so that a null pointer access can not happen
> > for the variable "ch" in these functions.
> 
> An actual defect fix!

Nope, not at all, this does not "fix" anything.

> Here you could probably cc stable too.

Nope, not worth it.

greg k-h

[PATCH AUTOSEL for 4.4 24/32] ipv6: reorder icmpv6_init() and ip6_mr_init()

[alexander . levin]

From: WANG Cong 

[ Upstream commit 15e668070a64bb97f102ad9cf3bccbca0545cda8 ]

Andrey reported the following kernel crash:

kasan: GPF could be caused by NULL-ptr deref or user memory access
general protection fault:  [#1] SMP KASAN
Dumping ftrace buffer:
   (ftrace buffer empty)
Modules linked in:
CPU: 0 PID: 14446 Comm: syz-executor6 Not tainted 4.10.0+ #82
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
task: 88001f311700 task.stack: 88001f6e8000
RIP: 0010:ip6mr_sk_done+0x15a/0x3d0 net/ipv6/ip6mr.c:1618
RSP: 0018:88001f6ef418 EFLAGS: 00010202
RAX: dc00 RBX: 110003edde8c RCX: c900043ee000
RDX: 0004 RSI: 83e3b3f8 RDI: 0020
RBP: 88001f6ef508 R08: fbfff0dcc5d8 R09: 
R10: 86e62ec0 R11:  R12: 
R13:  R14: 88001f6ef4e0 R15: 8800380a0040
FS:  7f7a52cec700() GS:88003ec0() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 0061c500 CR3: 1f1ae000 CR4: 06f0
DR0: 2000 DR1: 2000 DR2: 
DR3:  DR6: 0ff0 DR7: 0600
Call Trace:
 rawv6_close+0x4c/0x80 net/ipv6/raw.c:1217
 inet_release+0xed/0x1c0 net/ipv4/af_inet.c:425
 inet6_release+0x50/0x70 net/ipv6/af_inet6.c:432
 sock_release+0x8d/0x1e0 net/socket.c:597
 __sock_create+0x39d/0x880 net/socket.c:1226
 sock_create_kern+0x3f/0x50 net/socket.c:1243
 inet_ctl_sock_create+0xbb/0x280 net/ipv4/af_inet.c:1526
 icmpv6_sk_init+0x163/0x500 net/ipv6/icmp.c:954
 ops_init+0x10a/0x550 net/core/net_namespace.c:115
 setup_net+0x261/0x660 net/core/net_namespace.c:291
 copy_net_ns+0x27e/0x540 net/core/net_namespace.c:396
9pnet_virtio: no channels available for device ./file1
 create_new_namespaces+0x437/0x9b0 kernel/nsproxy.c:106
 unshare_nsproxy_namespaces+0xae/0x1e0 kernel/nsproxy.c:205
 SYSC_unshare kernel/fork.c:2281 [inline]
 SyS_unshare+0x64e/0x1000 kernel/fork.c:2231
 entry_SYSCALL_64_fastpath+0x1f/0xc2

This is because net->ipv6.mr6_tables is not initialized at that point,
ip6mr_rules_init() is not called yet, therefore on the error path when
we iterator the list, we trigger this oops. Fix this by reordering
ip6mr_rules_init() before icmpv6_sk_init().

Reported-by: Andrey Konovalov 
Signed-off-by: Cong Wang 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin 
---
 net/ipv6/af_inet6.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/net/ipv6/af_inet6.c b/net/ipv6/af_inet6.c
index 9f5137cd604e..83ec6639b04d 100644
--- a/net/ipv6/af_inet6.c
+++ b/net/ipv6/af_inet6.c
@@ -893,12 +893,12 @@ static int __init inet6_init(void)
err = register_pernet_subsys(&inet6_net_ops);
if (err)
goto register_pernet_fail;
-   err = icmpv6_init();
-   if (err)
-   goto icmp_fail;
err = ip6_mr_init();
if (err)
goto ipmr_fail;
+   err = icmpv6_init();
+   if (err)
+   goto icmp_fail;
err = ndisc_init();
if (err)
goto ndisc_fail;
@@ -1016,10 +1016,10 @@ igmp_fail:
ndisc_cleanup();
 ndisc_fail:
ip6_mr_cleanup();
-ipmr_fail:
-   icmpv6_cleanup();
 icmp_fail:
unregister_pernet_subsys(&inet6_net_ops);
+ipmr_fail:
+   icmpv6_cleanup();
 register_pernet_fail:
sock_unregister(PF_INET6);
rtnl_unregister_all(PF_INET6);
-- 
2.11.0

Re: [PATCH 3/5] PCI: cadence: Add host driver for Cadence PCIe controller

[Lorenzo Pieralisi]

On Thu, Nov 23, 2017 at 04:01:48PM +0100, Cyrille Pitchen wrote:
> This patch adds support to the Cadence PCIe controller in host mode.

Bjorn already commented on this, it would be good to add some
of the cover letter details in this log.

> Signed-off-by: Cyrille Pitchen 
> ---
>  drivers/Makefile|   1 +
>  drivers/pci/Kconfig |   1 +
>  drivers/pci/cadence/Kconfig |  24 ++
>  drivers/pci/cadence/Makefile|   2 +
>  drivers/pci/cadence/pcie-cadence-host.c | 425 
> 

You should also update the MAINTAINERS file.

>  drivers/pci/cadence/pcie-cadence.c  | 110 +
>  drivers/pci/cadence/pcie-cadence.h  | 325 
>  7 files changed, 888 insertions(+)
>  create mode 100644 drivers/pci/cadence/Kconfig
>  create mode 100644 drivers/pci/cadence/Makefile
>  create mode 100644 drivers/pci/cadence/pcie-cadence-host.c
>  create mode 100644 drivers/pci/cadence/pcie-cadence.c
>  create mode 100644 drivers/pci/cadence/pcie-cadence.h
>
> diff --git a/drivers/Makefile b/drivers/Makefile
> index 1d034b680431..27bdd98784d9 100644
> --- a/drivers/Makefile
> +++ b/drivers/Makefile
> @@ -18,6 +18,7 @@ obj-y   += pwm/
>
>  obj-$(CONFIG_PCI)+= pci/
>  obj-$(CONFIG_PCI_ENDPOINT)   += pci/endpoint/
> +obj-$(CONFIG_PCI_CADENCE)+= pci/cadence/

Already commented on the cover letter.

>  # PCI dwc controller drivers
>  obj-y+= pci/dwc/
>
> diff --git a/drivers/pci/Kconfig b/drivers/pci/Kconfig
> index 90944667ccea..2471b2e36b8b 100644
> --- a/drivers/pci/Kconfig
> +++ b/drivers/pci/Kconfig
> @@ -144,6 +144,7 @@ config PCI_HYPERV
>PCI devices from a PCI backend to support PCI driver domains.
>
>  source "drivers/pci/hotplug/Kconfig"
> +source "drivers/pci/cadence/Kconfig"
>  source "drivers/pci/dwc/Kconfig"
>  source "drivers/pci/host/Kconfig"
>  source "drivers/pci/endpoint/Kconfig"
> diff --git a/drivers/pci/cadence/Kconfig b/drivers/pci/cadence/Kconfig
> new file mode 100644
> index ..120306cae2aa
> --- /dev/null
> +++ b/drivers/pci/cadence/Kconfig
> @@ -0,0 +1,24 @@
> +menuconfig PCI_CADENCE
> + bool "Cadence PCI controllers support"
> + depends on PCI && HAS_IOMEM
> + help
> +   Say Y here if you want to support some Cadence PCI controller.
> +
> +   When in doubt, say N.
> +
> +if PCI_CADENCE
> +
> +config PCIE_CADENCE
> + bool
> +
> +config PCIE_CADENCE_HOST
> + bool "Cadence PCIe host controller"
> + depends on OF
> + depends on PCI_MSI_IRQ_DOMAIN

I do not see the reason for this dependency in the code.

> + select PCIE_CADENCE
> + help
> +   Say Y here if you want to support the Cadence PCIe controller in host
> +   mode. This PCIe controller may be embedded into many different vendors
> +   SoCs.
> +
> +endif # PCI_CADENCE
> diff --git a/drivers/pci/cadence/Makefile b/drivers/pci/cadence/Makefile
> new file mode 100644
> index ..d57d192d2595
> --- /dev/null
> +++ b/drivers/pci/cadence/Makefile
> @@ -0,0 +1,2 @@
> +obj-$(CONFIG_PCIE_CADENCE) += pcie-cadence.o
> +obj-$(CONFIG_PCIE_CADENCE_HOST) += pcie-cadence-host.o
> diff --git a/drivers/pci/cadence/pcie-cadence-host.c 
> b/drivers/pci/cadence/pcie-cadence-host.c
> new file mode 100644
> index ..252471e72a93
> --- /dev/null
> +++ b/drivers/pci/cadence/pcie-cadence-host.c
> @@ -0,0 +1,425 @@
> +/*
> + * Cadence PCIe host controller driver.
> + *
> + * Copyright (c) 2017 Cadence
> + *
> + * Author: Cyrille Pitchen 
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License along 
> with
> + * this program.  If not, see .
> + */
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include "pcie-cadence.h"
> +
> +/**
> + * struct cdns_pcie_rc_data - hardware specific data
> + * @max_regions: maximum number of regions supported by the hardware
> + * @vendor_id: PCI vendor ID
> + * @device_id: PCI device ID
> + * @no_bar_nbits: Number of bits to keep for inbound (PCIe -> CPU) address
> + *translation (nbits sets into the "no BAR match" register).
> + */
> +struct cdns_pcie_rc_data {
> + size_t  max_regions;

Reason for it to be size_t ?

> + u16 vendor_id;
> + u16 device_id;
> + u8  no_bar_nbits;
> +};

I think that this data should come from

[PATCH AUTOSEL for 4.4 27/32] zram: set physical queue limits to avoid array out of bounds accesses

[alexander . levin]

From: Johannes Thumshirn 

[ Upstream commit 0bc315381fe9ed9fb91db8b0e82171b645ac008f ]

zram can handle at most SECTORS_PER_PAGE sectors in a bio's bvec. When using
the NVMe over Fabrics loopback target which potentially sends a huge bulk of
pages attached to the bio's bvec this results in a kernel panic because of
array out of bounds accesses in zram_decompress_page().

Signed-off-by: Johannes Thumshirn 
Reviewed-by: Hannes Reinecke 
Reviewed-by: Sergey Senozhatsky 
Signed-off-by: Jens Axboe 
Signed-off-by: Sasha Levin 
---
 drivers/block/zram/zram_drv.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
index 62a93b685c54..502406c9e6e1 100644
--- a/drivers/block/zram/zram_drv.c
+++ b/drivers/block/zram/zram_drv.c
@@ -1247,6 +1247,8 @@ static int zram_add(void)
blk_queue_io_min(zram->disk->queue, PAGE_SIZE);
blk_queue_io_opt(zram->disk->queue, PAGE_SIZE);
zram->disk->queue->limits.discard_granularity = PAGE_SIZE;
+   zram->disk->queue->limits.max_sectors = SECTORS_PER_PAGE;
+   zram->disk->queue->limits.chunk_sectors = 0;
blk_queue_max_discard_sectors(zram->disk->queue, UINT_MAX);
/*
 * zram_bio_discard() will clear all logical blocks if logical block
-- 
2.11.0

[PATCH AUTOSEL for 4.4 26/32] i2c: riic: fix restart condition

[alexander . levin]

From: Chris Brandt 

[ Upstream commit 2501c1bb054290679baad0ff7f4f07c714251f4c ]

While modifying the driver to use the STOP interrupt, the completion of the
intermediate transfers need to wake the driver back up in order to initiate
the next transfer (restart condition). Otherwise you get never ending
interrupts and only the first transfer sent.

Fixes: 71ccea095ea1 ("i2c: riic: correctly finish transfers")
Reported-by: Simon Horman 
Signed-off-by: Chris Brandt 
Tested-by: Simon Horman 
Signed-off-by: Wolfram Sang 
Signed-off-by: Sasha Levin 
---
 drivers/i2c/busses/i2c-riic.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/i2c/busses/i2c-riic.c b/drivers/i2c/busses/i2c-riic.c
index d8803c3bbfdc..16833365475f 100644
--- a/drivers/i2c/busses/i2c-riic.c
+++ b/drivers/i2c/busses/i2c-riic.c
@@ -218,8 +218,12 @@ static irqreturn_t riic_tend_isr(int irq, void *data)
}
 
if (riic->is_last || riic->err) {
-   riic_clear_set_bit(riic, 0, ICIER_SPIE, RIIC_ICIER);
+   riic_clear_set_bit(riic, ICIER_TEIE, ICIER_SPIE, RIIC_ICIER);
writeb(ICCR2_SP, riic->base + RIIC_ICCR2);
+   } else {
+   /* Transfer is complete, but do not send STOP */
+   riic_clear_set_bit(riic, ICIER_TEIE, 0, RIIC_ICIER);
+   complete(&riic->msg_done);
}
 
return IRQ_HANDLED;
-- 
2.11.0

[PATCH AUTOSEL for 4.4 29/32] axonram: Fix gendisk handling

[alexander . levin]

From: Jan Kara 

[ Upstream commit 672a2c87c83649fb0167202342ce85af9a3b4f1c ]

It is invalid to call del_gendisk() when disk->queue is NULL. Fix error
handling in axon_ram_probe() to avoid doing that.

Also del_gendisk() does not drop a reference to gendisk allocated by
alloc_disk(). That has to be done by put_disk(). Add that call where
needed.

Reported-by: Dan Carpenter 
Signed-off-by: Jan Kara 
Signed-off-by: Jens Axboe 
Signed-off-by: Sasha Levin 
---
 arch/powerpc/sysdev/axonram.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/arch/powerpc/sysdev/axonram.c b/arch/powerpc/sysdev/axonram.c
index 7a399b4d60a0..566e8fc341f3 100644
--- a/arch/powerpc/sysdev/axonram.c
+++ b/arch/powerpc/sysdev/axonram.c
@@ -276,7 +276,9 @@ failed:
if (bank->disk->major > 0)
unregister_blkdev(bank->disk->major,
bank->disk->disk_name);
-   del_gendisk(bank->disk);
+   if (bank->disk->flags & GENHD_FL_UP)
+   del_gendisk(bank->disk);
+   put_disk(bank->disk);
}
device->dev.platform_data = NULL;
if (bank->io_addr != 0)
@@ -301,6 +303,7 @@ axon_ram_remove(struct platform_device *device)
device_remove_file(&device->dev, &dev_attr_ecc);
free_irq(bank->irq_id, device);
del_gendisk(bank->disk);
+   put_disk(bank->disk);
iounmap((void __iomem *) bank->io_addr);
kfree(bank);
 
-- 
2.11.0

[PATCH AUTOSEL for 3.18 05/16] workqueue: trigger WARN if queue_delayed_work() is called with NULL @wq

[alexander . levin]

From: Tejun Heo 

[ Upstream commit 637fdbae60d6cb9f6e963c1079d7e0445c86ff7d ]

If queue_delayed_work() gets called with NULL @wq, the kernel will
oops asynchronuosly on timer expiration which isn't too helpful in
tracking down the offender.  This actually happened with smc.

__queue_delayed_work() already does several input sanity checks
synchronously.  Add NULL @wq check.

Reported-by: Dave Jones 
Link: http://lkml.kernel.org/r/20170227171439.jshx3qplflyrg...@codemonkey.org.uk
Signed-off-by: Tejun Heo 
Signed-off-by: Sasha Levin 
---
 kernel/workqueue.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/kernel/workqueue.c b/kernel/workqueue.c
index a636e38c0813..39998408e705 100644
--- a/kernel/workqueue.c
+++ b/kernel/workqueue.c
@@ -1452,6 +1452,7 @@ static void __queue_delayed_work(int cpu, struct 
workqueue_struct *wq,
struct timer_list *timer = &dwork->timer;
struct work_struct *work = &dwork->work;
 
+   WARN_ON_ONCE(!wq);
WARN_ON_ONCE(timer->function != delayed_work_timer_fn ||
 timer->data != (unsigned long)dwork);
WARN_ON_ONCE(timer_pending(timer));
-- 
2.11.0

[PATCH AUTOSEL for 4.4 30/32] drm/amd/amdgpu: fix console deadlock if late init failed

[alexander . levin]

From: Jim Qu 

[ Upstream commit c085bd5119d5d0bdf3ef591a5563566be7dedced ]

Signed-off-by: Jim Qu 
Reviewed-by: Alex Deucher 
Signed-off-by: Alex Deucher 
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index 16302f7d59f6..fc9f14747f70 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -1760,8 +1760,11 @@ int amdgpu_resume_kms(struct drm_device *dev, bool 
resume, bool fbcon)
}
 
r = amdgpu_late_init(adev);
-   if (r)
+   if (r) {
+   if (fbcon)
+   console_unlock();
return r;
+   }
 
/* pin cursors */
list_for_each_entry(crtc, &dev->mode_config.crtc_list, head) {
-- 
2.11.0

[PATCH AUTOSEL for 3.18 02/16] usb: gadget: configs: plug memory leak

[alexander . levin]

From: John Keeping 

[ Upstream commit 38355b2a44776c25b0f2ad466e8c51bb805b3032 ]

When binding a gadget to a device, "name" is stored in gi->udc_name, but
this does not happen when unregistering and the string is leaked.

Signed-off-by: John Keeping 
Signed-off-by: Felipe Balbi 
Signed-off-by: Sasha Levin 
---
 drivers/usb/gadget/configfs.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/usb/gadget/configfs.c b/drivers/usb/gadget/configfs.c
index a7e1a96e69a5..156c252c5aab 100644
--- a/drivers/usb/gadget/configfs.c
+++ b/drivers/usb/gadget/configfs.c
@@ -266,6 +266,7 @@ static ssize_t gadget_dev_desc_UDC_store(struct gadget_info 
*gi,
ret = unregister_gadget(gi);
if (ret)
goto err;
+   kfree(name);
} else {
if (gi->udc_name) {
ret = -EBUSY;
-- 
2.11.0

[PATCH AUTOSEL for 4.4 17/32] KVM: nVMX: reset nested_run_pending if the vCPU is going to be reset

[alexander . levin]

From: Wanpeng Li 

[ Upstream commit 2f707d97982286b307ef2a9b034e19aabc1abb56 ]

Reported by syzkaller:

WARNING: CPU: 1 PID: 27742 at arch/x86/kvm/vmx.c:11029
nested_vmx_vmexit+0x5c35/0x74d0 arch/x86/kvm/vmx.c:11029
CPU: 1 PID: 27742 Comm: a.out Not tainted 4.10.0+ #229
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
Call Trace:
 __dump_stack lib/dump_stack.c:15 [inline]
 dump_stack+0x2ee/0x3ef lib/dump_stack.c:51
 panic+0x1fb/0x412 kernel/panic.c:179
 __warn+0x1c4/0x1e0 kernel/panic.c:540
 warn_slowpath_null+0x2c/0x40 kernel/panic.c:583
 nested_vmx_vmexit+0x5c35/0x74d0 arch/x86/kvm/vmx.c:11029
 vmx_leave_nested arch/x86/kvm/vmx.c:11136 [inline]
 vmx_set_msr+0x1565/0x1910 arch/x86/kvm/vmx.c:3324
 kvm_set_msr+0xd4/0x170 arch/x86/kvm/x86.c:1099
 do_set_msr+0x11e/0x190 arch/x86/kvm/x86.c:1128
 __msr_io arch/x86/kvm/x86.c:2577 [inline]
 msr_io+0x24b/0x450 arch/x86/kvm/x86.c:2614
 kvm_arch_vcpu_ioctl+0x35b/0x46a0 arch/x86/kvm/x86.c:3497
 kvm_vcpu_ioctl+0x232/0x1120 arch/x86/kvm/../../../virt/kvm/kvm_main.c:2721
 vfs_ioctl fs/ioctl.c:43 [inline]
 do_vfs_ioctl+0x1bf/0x1790 fs/ioctl.c:683
 SYSC_ioctl fs/ioctl.c:698 [inline]
 SyS_ioctl+0x8f/0xc0 fs/ioctl.c:689
 entry_SYSCALL_64_fastpath+0x1f/0xc2

The syzkaller folks reported a nested_run_pending warning during userspace
clear VMX capability which is exposed to L1 before.

The warning gets thrown while doing

(*(uint32_t*)0x20aecfe8 = (uint32_t)0x1);
(*(uint32_t*)0x20aecfec = (uint32_t)0x0);
(*(uint32_t*)0x20aecff0 = (uint32_t)0x3a);
(*(uint32_t*)0x20aecff4 = (uint32_t)0x0);
(*(uint64_t*)0x20aecff8 = (uint64_t)0x0);
r[29] = syscall(__NR_ioctl, r[4], 0x4008ae89ul,
0x20aecfe8ul, 0, 0, 0, 0, 0, 0);

i.e. KVM_SET_MSR ioctl with

struct kvm_msrs {
.nmsrs = 1,
.pad = 0,
.entries = {
{.index = MSR_IA32_FEATURE_CONTROL,
 .reserved = 0,
 .data = 0}
}
}

The VMLANCH/VMRESUME emulation should be stopped since the CPU is going to
reset here. This patch resets the nested_run_pending since the CPU is going
to be reset hence there should be nothing pending.

Reported-by: Dmitry Vyukov 
Suggested-by: Radim Krčmář 
Cc: Paolo Bonzini 
Cc: Radim Krčmář 
Cc: Dmitry Vyukov 
Cc: David Hildenbrand 
Signed-off-by: Wanpeng Li 
Reviewed-by: David Hildenbrand 
Reviewed-by: Jim Mattson 
Signed-off-by: Radim Krčmář 
Signed-off-by: Sasha Levin 
---
 arch/x86/kvm/vmx.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index aa8776848183..88b92d948b41 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -10556,8 +10556,10 @@ static void nested_vmx_vmexit(struct kvm_vcpu *vcpu, 
u32 exit_reason,
  */
 static void vmx_leave_nested(struct kvm_vcpu *vcpu)
 {
-   if (is_guest_mode(vcpu))
+   if (is_guest_mode(vcpu)) {
+   to_vmx(vcpu)->nested.nested_run_pending = 0;
nested_vmx_vmexit(vcpu, -1, 0, 0);
+   }
free_nested(to_vmx(vcpu));
 }
 
-- 
2.11.0

[PATCH AUTOSEL for 3.18 06/16] scsi: lpfc: Fix crash during Hardware error recovery on SLI3 adapters

[alexander . levin]

From: James Smart 

[ Upstream commit 5d181531bc6169e19a02a27d202cf0e982db9d0e ]

if REG_VPI fails, the driver was incorrectly issuing INIT_VFI
(a SLI4 command) on a SLI3 adapter.

Signed-off-by: Dick Kennedy 
Signed-off-by: James Smart 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Sasha Levin 
---
 drivers/scsi/lpfc/lpfc_els.c | 14 ++
 1 file changed, 10 insertions(+), 4 deletions(-)

diff --git a/drivers/scsi/lpfc/lpfc_els.c b/drivers/scsi/lpfc/lpfc_els.c
index 4c25485aa934..c76279926ad6 100644
--- a/drivers/scsi/lpfc/lpfc_els.c
+++ b/drivers/scsi/lpfc/lpfc_els.c
@@ -7265,11 +7265,17 @@ lpfc_cmpl_reg_new_vport(struct lpfc_hba *phba, 
LPFC_MBOXQ_t *pmb)
spin_lock_irq(shost->host_lock);
vport->fc_flag |= FC_VPORT_NEEDS_REG_VPI;
spin_unlock_irq(shost->host_lock);
-   if (vport->port_type == LPFC_PHYSICAL_PORT
-   && !(vport->fc_flag & FC_LOGO_RCVD_DID_CHNG))
-   lpfc_issue_init_vfi(vport);
-   else
+   if (mb->mbxStatus == MBX_NOT_FINISHED)
+   break;
+   if ((vport->port_type == LPFC_PHYSICAL_PORT) &&
+   !(vport->fc_flag & FC_LOGO_RCVD_DID_CHNG)) {
+   if (phba->sli_rev == LPFC_SLI_REV4)
+   lpfc_issue_init_vfi(vport);
+   else
+   lpfc_initial_flogi(vport);
+   } else {
lpfc_initial_fdisc(vport);
+   }
break;
}
} else {
-- 
2.11.0

[PATCH AUTOSEL for 4.4 16/32] irqchip/crossbar: Fix incorrect type of register size

[alexander . levin]

From: Franck Demathieu 

[ Upstream commit 4b9de5da7e120c7f02395da729f0ec77ce7a6044 ]

The 'size' variable is unsigned according to the dt-bindings.
As this variable is used as integer in other places, create a new variable
that allows to fix the following sparse issue (-Wtypesign):

  drivers/irqchip/irq-crossbar.c:279:52: warning: incorrect type in argument 3 
(different signedness)
  drivers/irqchip/irq-crossbar.c:279:52:expected unsigned int [usertype] 
*out_value
  drivers/irqchip/irq-crossbar.c:279:52:got int *

Signed-off-by: Franck Demathieu 
Signed-off-by: Marc Zyngier 
Signed-off-by: Sasha Levin 
---
 drivers/irqchip/irq-crossbar.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/irqchip/irq-crossbar.c b/drivers/irqchip/irq-crossbar.c
index 63faee04a008..636187a4c1a3 100644
--- a/drivers/irqchip/irq-crossbar.c
+++ b/drivers/irqchip/irq-crossbar.c
@@ -199,7 +199,7 @@ static const struct irq_domain_ops crossbar_domain_ops = {
 static int __init crossbar_of_init(struct device_node *node)
 {
int i, size, reserved = 0;
-   u32 max = 0, entry;
+   u32 max = 0, entry, reg_size;
const __be32 *irqsr;
int ret = -ENOMEM;
 
@@ -276,9 +276,9 @@ static int __init crossbar_of_init(struct device_node *node)
if (!cb->register_offsets)
goto err_irq_map;
 
-   of_property_read_u32(node, "ti,reg-size", &size);
+   of_property_read_u32(node, "ti,reg-size", ®_size);
 
-   switch (size) {
+   switch (reg_size) {
case 1:
cb->write = crossbar_writeb;
break;
@@ -304,7 +304,7 @@ static int __init crossbar_of_init(struct device_node *node)
continue;
 
cb->register_offsets[i] = reserved;
-   reserved += size;
+   reserved += reg_size;
}
 
of_property_read_u32(node, "ti,irqs-safe-map", &cb->safe_map);
-- 
2.11.0

[PATCH AUTOSEL for 4.4 18/32] arm: KVM: Survive unknown traps from guests

[alexander . levin]

From: Mark Rutland 

[ Upstream commit f050fe7a9164945dd1c28be05bf00e8cfb082ccf ]

Currently we BUG() if we see a HSR.EC value we don't recognise. As
configurable disables/enables are added to the architecture (controlled
by RES1/RES0 bits respectively), with associated synchronous exceptions,
it may be possible for a guest to trigger exceptions with classes that
we don't recognise.

While we can't service these exceptions in a manner useful to the guest,
we can avoid bringing down the host. Per ARM DDI 0406C.c, all currently
unallocated HSR EC encodings are reserved, and per ARM DDI
0487A.k_iss10775, page G6-4395, EC values within the range 0x00 - 0x2c
are reserved for future use with synchronous exceptions, and EC values
within the range 0x2d - 0x3f may be used for either synchronous or
asynchronous exceptions.

The patch makes KVM handle any unknown EC by injecting an UNDEFINED
exception into the guest, with a corresponding (ratelimited) warning in
the host dmesg. We could later improve on this with with a new (opt-in)
exit to the host userspace.

Cc: Dave Martin 
Cc: Suzuki K Poulose 
Reviewed-by: Christoffer Dall 
Signed-off-by: Mark Rutland 
Signed-off-by: Marc Zyngier 
Signed-off-by: Sasha Levin 
---
 arch/arm/include/asm/kvm_arm.h |  1 +
 arch/arm/kvm/handle_exit.c | 19 ---
 2 files changed, 13 insertions(+), 7 deletions(-)

diff --git a/arch/arm/include/asm/kvm_arm.h b/arch/arm/include/asm/kvm_arm.h
index dc641ddf0784..dd1715268543 100644
--- a/arch/arm/include/asm/kvm_arm.h
+++ b/arch/arm/include/asm/kvm_arm.h
@@ -209,6 +209,7 @@
 #define HSR_EC_IABT_HYP(0x21)
 #define HSR_EC_DABT(0x24)
 #define HSR_EC_DABT_HYP(0x25)
+#define HSR_EC_MAX (0x3f)
 
 #define HSR_WFI_IS_WFE (1U << 0)
 
diff --git a/arch/arm/kvm/handle_exit.c b/arch/arm/kvm/handle_exit.c
index 95f12b2ccdcb..f36b5b1acd1f 100644
--- a/arch/arm/kvm/handle_exit.c
+++ b/arch/arm/kvm/handle_exit.c
@@ -100,7 +100,19 @@ static int kvm_handle_wfx(struct kvm_vcpu *vcpu, struct 
kvm_run *run)
return 1;
 }
 
+static int kvm_handle_unknown_ec(struct kvm_vcpu *vcpu, struct kvm_run *run)
+{
+   u32 hsr = kvm_vcpu_get_hsr(vcpu);
+
+   kvm_pr_unimpl("Unknown exception class: hsr: %#08x\n",
+ hsr);
+
+   kvm_inject_undefined(vcpu);
+   return 1;
+}
+
 static exit_handle_fn arm_exit_handlers[] = {
+   [0 ... HSR_EC_MAX]  = kvm_handle_unknown_ec,
[HSR_EC_WFI]= kvm_handle_wfx,
[HSR_EC_CP15_32]= kvm_handle_cp15_32,
[HSR_EC_CP15_64]= kvm_handle_cp15_64,
@@ -122,13 +134,6 @@ static exit_handle_fn kvm_get_exit_handler(struct kvm_vcpu 
*vcpu)
 {
u8 hsr_ec = kvm_vcpu_trap_get_class(vcpu);
 
-   if (hsr_ec >= ARRAY_SIZE(arm_exit_handlers) ||
-   !arm_exit_handlers[hsr_ec]) {
-   kvm_err("Unknown exception class: hsr: %#08x\n",
-   (unsigned int)kvm_vcpu_get_hsr(vcpu));
-   BUG();
-   }
-
return arm_exit_handlers[hsr_ec];
 }
 
-- 
2.11.0

Re: [PATCH v2] KVM: VMX: Cache IA32_DEBUGCTL in memory

[David Hildenbrand]

On 29.11.2017 10:31, Wanpeng Li wrote:
> From: Wanpeng Li 
> 
> MSR_IA32_DEBUGCTLMSR is zeroed on VMEXIT, so it is saved/restored 
> each time during world switch. Jim from Google pointed out that 
> when running schbench in L2, vmx_vcpu_run will occupy 4% cpu time, 
> and the 25% of vmx_vcpu_run cpu time is occupied by get_debugctlmsr(). 
> This patch caches the host IA32_DEBUGCTL MSR and saves/restores 
> the host IA32_DEBUGCTL msr when guest/host switches to avoid to 
> save/restore each time during world switch.
> 
> Suggested-by: Jim Mattson 
> Cc: Paolo Bonzini 
> Cc: Radim Krčmář 
> Cc: Jim Mattson 
> Signed-off-by: Wanpeng Li 
> ---
> v1 ->  v2:
>  * rename to host_debugctlmsr and place it in struct vcpu_struct
>  * update_debugctlmsr stay in vmx_vcpu_run
> 
>  arch/x86/kvm/vmx.c | 10 ++
>  1 file changed, 6 insertions(+), 4 deletions(-)
> 
> diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
> index 8c7e816..d293c29 100644
> --- a/arch/x86/kvm/vmx.c
> +++ b/arch/x86/kvm/vmx.c
> @@ -658,6 +658,8 @@ struct vcpu_vmx {
>  
>   u32 host_pkru;
>  
> + unsigned long host_debugctlmsr;
> +
>   /*
>* Only bits masked by msr_ia32_feature_control_valid_bits can be set in
>* msr_ia32_feature_control. FEATURE_CONTROL_LOCKED is always included
> @@ -2326,6 +2328,7 @@ static void vmx_vcpu_load(struct kvm_vcpu *vcpu, int 
> cpu)
>  
>   vmx_vcpu_pi_load(vcpu, cpu);
>   vmx->host_pkru = read_pkru();
> + vmx->host_debugctlmsr = get_debugctlmsr();
>  }
>  
>  static void vmx_vcpu_pi_put(struct kvm_vcpu *vcpu)
> @@ -9346,7 +9349,7 @@ static void vmx_arm_hv_timer(struct kvm_vcpu *vcpu)
>  static void __noclone vmx_vcpu_run(struct kvm_vcpu *vcpu)
>  {
>   struct vcpu_vmx *vmx = to_vmx(vcpu);
> - unsigned long debugctlmsr, cr3, cr4;
> + unsigned long cr3, cr4;
>  
>   /* Record the guest's net vcpu time for enforced NMI injections. */
>   if (unlikely(!enable_vnmi &&
> @@ -9399,7 +9402,6 @@ static void __noclone vmx_vcpu_run(struct kvm_vcpu 
> *vcpu)
>   __write_pkru(vcpu->arch.pkru);
>  
>   atomic_switch_perf_msrs(vmx);
> - debugctlmsr = get_debugctlmsr();
>  
>   vmx_arm_hv_timer(vcpu);
>  
> @@ -9510,8 +9512,8 @@ static void __noclone vmx_vcpu_run(struct kvm_vcpu 
> *vcpu)
> );
>  
>   /* MSR_IA32_DEBUGCTLMSR is zeroed on vmexit. Restore it if needed */
> - if (debugctlmsr)
> - update_debugctlmsr(debugctlmsr);
> + if (vmx->host_debugctlmsr)
> + update_debugctlmsr(vmx->host_debugctlmsr);
>  
>  #ifndef CONFIG_X86_64
>   /*
> 

Reviewed-by: David Hildenbrand 

-- 

Thanks,

David / dhildenb

[PATCH AUTOSEL for 4.4 15/32] scsi: lpfc: Fix crash during Hardware error recovery on SLI3 adapters

[alexander . levin]

From: James Smart 

[ Upstream commit 5d181531bc6169e19a02a27d202cf0e982db9d0e ]

if REG_VPI fails, the driver was incorrectly issuing INIT_VFI
(a SLI4 command) on a SLI3 adapter.

Signed-off-by: Dick Kennedy 
Signed-off-by: James Smart 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Sasha Levin 
---
 drivers/scsi/lpfc/lpfc_els.c | 14 ++
 1 file changed, 10 insertions(+), 4 deletions(-)

diff --git a/drivers/scsi/lpfc/lpfc_els.c b/drivers/scsi/lpfc/lpfc_els.c
index d278362448ca..fc8f9b446556 100644
--- a/drivers/scsi/lpfc/lpfc_els.c
+++ b/drivers/scsi/lpfc/lpfc_els.c
@@ -7887,11 +7887,17 @@ lpfc_cmpl_reg_new_vport(struct lpfc_hba *phba, 
LPFC_MBOXQ_t *pmb)
spin_lock_irq(shost->host_lock);
vport->fc_flag |= FC_VPORT_NEEDS_REG_VPI;
spin_unlock_irq(shost->host_lock);
-   if (vport->port_type == LPFC_PHYSICAL_PORT
-   && !(vport->fc_flag & FC_LOGO_RCVD_DID_CHNG))
-   lpfc_issue_init_vfi(vport);
-   else
+   if (mb->mbxStatus == MBX_NOT_FINISHED)
+   break;
+   if ((vport->port_type == LPFC_PHYSICAL_PORT) &&
+   !(vport->fc_flag & FC_LOGO_RCVD_DID_CHNG)) {
+   if (phba->sli_rev == LPFC_SLI_REV4)
+   lpfc_issue_init_vfi(vport);
+   else
+   lpfc_initial_flogi(vport);
+   } else {
lpfc_initial_fdisc(vport);
+   }
break;
}
} else {
-- 
2.11.0

[PATCH AUTOSEL for 3.18 15/16] axonram: Fix gendisk handling

[alexander . levin]

From: Jan Kara 

[ Upstream commit 672a2c87c83649fb0167202342ce85af9a3b4f1c ]

It is invalid to call del_gendisk() when disk->queue is NULL. Fix error
handling in axon_ram_probe() to avoid doing that.

Also del_gendisk() does not drop a reference to gendisk allocated by
alloc_disk(). That has to be done by put_disk(). Add that call where
needed.

Reported-by: Dan Carpenter 
Signed-off-by: Jan Kara 
Signed-off-by: Jens Axboe 
Signed-off-by: Sasha Levin 
---
 arch/powerpc/sysdev/axonram.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/arch/powerpc/sysdev/axonram.c b/arch/powerpc/sysdev/axonram.c
index e8bb33b2d3cc..2f99da0f3d9d 100644
--- a/arch/powerpc/sysdev/axonram.c
+++ b/arch/powerpc/sysdev/axonram.c
@@ -283,7 +283,9 @@ failed:
if (bank->disk->major > 0)
unregister_blkdev(bank->disk->major,
bank->disk->disk_name);
-   del_gendisk(bank->disk);
+   if (bank->disk->flags & GENHD_FL_UP)
+   del_gendisk(bank->disk);
+   put_disk(bank->disk);
}
device->dev.platform_data = NULL;
if (bank->io_addr != 0)
@@ -308,6 +310,7 @@ axon_ram_remove(struct platform_device *device)
device_remove_file(&device->dev, &dev_attr_ecc);
free_irq(bank->irq_id, device);
del_gendisk(bank->disk);
+   put_disk(bank->disk);
iounmap((void __iomem *) bank->io_addr);
kfree(bank);
 
-- 
2.11.0

[PATCH AUTOSEL for 3.18 09/16] arm: KVM: Survive unknown traps from guests

[alexander . levin]

From: Mark Rutland 

[ Upstream commit f050fe7a9164945dd1c28be05bf00e8cfb082ccf ]

Currently we BUG() if we see a HSR.EC value we don't recognise. As
configurable disables/enables are added to the architecture (controlled
by RES1/RES0 bits respectively), with associated synchronous exceptions,
it may be possible for a guest to trigger exceptions with classes that
we don't recognise.

While we can't service these exceptions in a manner useful to the guest,
we can avoid bringing down the host. Per ARM DDI 0406C.c, all currently
unallocated HSR EC encodings are reserved, and per ARM DDI
0487A.k_iss10775, page G6-4395, EC values within the range 0x00 - 0x2c
are reserved for future use with synchronous exceptions, and EC values
within the range 0x2d - 0x3f may be used for either synchronous or
asynchronous exceptions.

The patch makes KVM handle any unknown EC by injecting an UNDEFINED
exception into the guest, with a corresponding (ratelimited) warning in
the host dmesg. We could later improve on this with with a new (opt-in)
exit to the host userspace.

Cc: Dave Martin 
Cc: Suzuki K Poulose 
Reviewed-by: Christoffer Dall 
Signed-off-by: Mark Rutland 
Signed-off-by: Marc Zyngier 
Signed-off-by: Sasha Levin 
---
 arch/arm/include/asm/kvm_arm.h |  1 +
 arch/arm/kvm/handle_exit.c | 19 ---
 2 files changed, 13 insertions(+), 7 deletions(-)

diff --git a/arch/arm/include/asm/kvm_arm.h b/arch/arm/include/asm/kvm_arm.h
index 816db0bf2dd8..151464c6bfdb 100644
--- a/arch/arm/include/asm/kvm_arm.h
+++ b/arch/arm/include/asm/kvm_arm.h
@@ -208,6 +208,7 @@
 #define HSR_EC_IABT_HYP(0x21)
 #define HSR_EC_DABT(0x24)
 #define HSR_EC_DABT_HYP(0x25)
+#define HSR_EC_MAX (0x3f)
 
 #define HSR_WFI_IS_WFE (1U << 0)
 
diff --git a/arch/arm/kvm/handle_exit.c b/arch/arm/kvm/handle_exit.c
index a96a8043277c..b6ac50b85d72 100644
--- a/arch/arm/kvm/handle_exit.c
+++ b/arch/arm/kvm/handle_exit.c
@@ -98,7 +98,19 @@ static int kvm_handle_wfx(struct kvm_vcpu *vcpu, struct 
kvm_run *run)
return 1;
 }
 
+static int kvm_handle_unknown_ec(struct kvm_vcpu *vcpu, struct kvm_run *run)
+{
+   u32 hsr = kvm_vcpu_get_hsr(vcpu);
+
+   kvm_pr_unimpl("Unknown exception class: hsr: %#08x\n",
+ hsr);
+
+   kvm_inject_undefined(vcpu);
+   return 1;
+}
+
 static exit_handle_fn arm_exit_handlers[] = {
+   [0 ... HSR_EC_MAX]  = kvm_handle_unknown_ec,
[HSR_EC_WFI]= kvm_handle_wfx,
[HSR_EC_CP15_32]= kvm_handle_cp15_32,
[HSR_EC_CP15_64]= kvm_handle_cp15_64,
@@ -120,13 +132,6 @@ static exit_handle_fn kvm_get_exit_handler(struct kvm_vcpu 
*vcpu)
 {
u8 hsr_ec = kvm_vcpu_trap_get_class(vcpu);
 
-   if (hsr_ec >= ARRAY_SIZE(arm_exit_handlers) ||
-   !arm_exit_handlers[hsr_ec]) {
-   kvm_err("Unknown exception class: hsr: %#08x\n",
-   (unsigned int)kvm_vcpu_get_hsr(vcpu));
-   BUG();
-   }
-
return arm_exit_handlers[hsr_ec];
 }
 
-- 
2.11.0

[PATCH AUTOSEL for 4.4 10/32] usb: gadget: configs: plug memory leak

[alexander . levin]

From: John Keeping 

[ Upstream commit 38355b2a44776c25b0f2ad466e8c51bb805b3032 ]

When binding a gadget to a device, "name" is stored in gi->udc_name, but
this does not happen when unregistering and the string is leaked.

Signed-off-by: John Keeping 
Signed-off-by: Felipe Balbi 
Signed-off-by: Sasha Levin 
---
 drivers/usb/gadget/configfs.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/usb/gadget/configfs.c b/drivers/usb/gadget/configfs.c
index 163d305e1200..6abb6a10ee82 100644
--- a/drivers/usb/gadget/configfs.c
+++ b/drivers/usb/gadget/configfs.c
@@ -270,6 +270,7 @@ static ssize_t gadget_dev_desc_UDC_store(struct config_item 
*item,
ret = unregister_gadget(gi);
if (ret)
goto err;
+   kfree(name);
} else {
if (gi->udc_name) {
ret = -EBUSY;
-- 
2.11.0

[PATCH AUTOSEL for 3.18 10/16] spi_ks8995: fix "BUG: key accdaa28 not in .data!"

[alexander . levin]

From: "Blomme, Maarten" 

[ Upstream commit 4342696df764ec65dcdfbd0c10d90ea52505f8ba ]

Signed-off-by: Maarten Blomme 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin 
---
 drivers/net/phy/spi_ks8995.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/phy/spi_ks8995.c b/drivers/net/phy/spi_ks8995.c
index eab57fc5b967..49dfb8abc43d 100644
--- a/drivers/net/phy/spi_ks8995.c
+++ b/drivers/net/phy/spi_ks8995.c
@@ -332,6 +332,7 @@ static int ks8995_probe(struct spi_device *spi)
if (err)
return err;
 
+   sysfs_attr_init(&ks->regs_attr.attr);
err = sysfs_create_bin_file(&spi->dev.kobj, &ks->regs_attr);
if (err) {
dev_err(&spi->dev, "unable to create sysfs file, err=%d\n",
-- 
2.11.0

[PATCH AUTOSEL for 3.18 13/16] crypto: s5p-sss - Fix completing crypto request in IRQ handler

[alexander . levin]

From: Krzysztof Kozlowski 

[ Upstream commit 07de4bc88ce6a4d898cad9aa4c99c1df7e87702d ]

In a regular interrupt handler driver was finishing the crypt/decrypt
request by calling complete on crypto request.  This is disallowed since
converting to skcipher in commit b286d8b1a690 ("crypto: skcipher - Add
skcipher walk interface") and causes a warning:
WARNING: CPU: 0 PID: 0 at crypto/skcipher.c:430 
skcipher_walk_first+0x13c/0x14c

The interrupt is marked shared but in fact there are no other users
sharing it.  Thus the simplest solution seems to be to just use a
threaded interrupt handler, after converting it to oneshot.

Signed-off-by: Krzysztof Kozlowski 
Signed-off-by: Herbert Xu 
Signed-off-by: Sasha Levin 
---
 drivers/crypto/s5p-sss.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/crypto/s5p-sss.c b/drivers/crypto/s5p-sss.c
index 658fa533ced1..5f0e3bb9006d 100644
--- a/drivers/crypto/s5p-sss.c
+++ b/drivers/crypto/s5p-sss.c
@@ -682,8 +682,9 @@ static int s5p_aes_probe(struct platform_device *pdev)
dev_warn(dev, "feed control interrupt is not available.\n");
goto err_irq;
}
-   err = devm_request_irq(dev, pdata->irq_fc, s5p_aes_interrupt,
-  IRQF_SHARED, pdev->name, pdev);
+   err = devm_request_threaded_irq(dev, pdata->irq_fc, NULL,
+   s5p_aes_interrupt, IRQF_ONESHOT,
+   pdev->name, pdev);
if (err < 0) {
dev_warn(dev, "feed control interrupt is not available.\n");
goto err_irq;
-- 
2.11.0

[PATCH AUTOSEL for 3.18 11/16] bnx2x: fix possible overrun of VFPF multicast addresses array

[alexander . levin]

From: Michal Schmidt 

[ Upstream commit 22118d861cec5da6ed525aaf12a3de9bfeffc58f ]

It is too late to check for the limit of the number of VF multicast
addresses after they have already been copied to the req->multicast[]
array, possibly overflowing it.

Do the check before copying.

Also fix the error path to not skip unlocking vf2pf_mutex.

Signed-off-by: Michal Schmidt 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin 
---
 drivers/net/ethernet/broadcom/bnx2x/bnx2x_vfpf.c | 23 +++
 1 file changed, 11 insertions(+), 12 deletions(-)

diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_vfpf.c 
b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_vfpf.c
index b1d9c44aa56c..07eba80f6fb1 100644
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_vfpf.c
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_vfpf.c
@@ -826,7 +826,7 @@ int bnx2x_vfpf_set_mcast(struct net_device *dev)
struct bnx2x *bp = netdev_priv(dev);
struct vfpf_set_q_filters_tlv *req = &bp->vf2pf_mbox->req.set_q_filters;
struct pfvf_general_resp_tlv *resp = &bp->vf2pf_mbox->resp.general_resp;
-   int rc, i = 0;
+   int rc = 0, i = 0;
struct netdev_hw_addr *ha;
 
if (bp->state != BNX2X_STATE_OPEN) {
@@ -841,6 +841,15 @@ int bnx2x_vfpf_set_mcast(struct net_device *dev)
/* Get Rx mode requested */
DP(NETIF_MSG_IFUP, "dev->flags = %x\n", dev->flags);
 
+   /* We support PFVF_MAX_MULTICAST_PER_VF mcast addresses tops */
+   if (netdev_mc_count(dev) > PFVF_MAX_MULTICAST_PER_VF) {
+   DP(NETIF_MSG_IFUP,
+  "VF supports not more than %d multicast MAC addresses\n",
+  PFVF_MAX_MULTICAST_PER_VF);
+   rc = -EINVAL;
+   goto out;
+   }
+
netdev_for_each_mc_addr(ha, dev) {
DP(NETIF_MSG_IFUP, "Adding mcast MAC: %pM\n",
   bnx2x_mc_addr(ha));
@@ -848,16 +857,6 @@ int bnx2x_vfpf_set_mcast(struct net_device *dev)
i++;
}
 
-   /* We support four PFVF_MAX_MULTICAST_PER_VF mcast
- * addresses tops
- */
-   if (i >= PFVF_MAX_MULTICAST_PER_VF) {
-   DP(NETIF_MSG_IFUP,
-  "VF supports not more than %d multicast MAC addresses\n",
-  PFVF_MAX_MULTICAST_PER_VF);
-   return -EINVAL;
-   }
-
req->n_multicast = i;
req->flags |= VFPF_SET_Q_FILTERS_MULTICAST_CHANGED;
req->vf_qid = 0;
@@ -882,7 +881,7 @@ int bnx2x_vfpf_set_mcast(struct net_device *dev)
 out:
bnx2x_vfpf_finalize(bp, &req->first_tlv);
 
-   return 0;
+   return rc;
 }
 
 int bnx2x_vfpf_storm_rx_mode(struct bnx2x *bp)
-- 
2.11.0

[PATCH 0/2] Switchtec Updates

[Logan Gunthorpe]

Hi Bjorn,

Blease accept the following two patches. The first adds a couple more
device IDs for the Switchtec driver. The second adds a new event type
for it to report.

Thanks,

Logan

Kelvin Cao (1):
  switchtec: Add device IDs for PSX 24xG3 and PSX 48xG3

Logan Gunthorpe (1):
  switchtec: Added Global Fabric Manager Server (GFMS) event

 drivers/pci/switch/switchtec.c   | 3 +++
 include/linux/switchtec.h| 3 +++
 include/uapi/linux/switchtec_ioctl.h | 3 ++-
 3 files changed, 8 insertions(+), 1 deletion(-)

--
2.11.0

[PATCH 2/2] switchtec: Add device IDs for PSX 24xG3 and PSX 48xG3

[Logan Gunthorpe]

From: Kelvin Cao 

These are valid devices that were missing from the existing device
ID table for the Switchtec driver.

Signed-off-by: Kelvin Cao 
Signed-off-by: Logan Gunthorpe 

# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
#
# Author:Kelvin Cao 
# Date:  Sat Oct 14 01:31:58 2017 +0800
#
# interactive rebase in progress; onto 4fbd8d194f06
# Last commands done (2 commands done):
#r b63e909353b8 switchtec: Added Global Fabric Manager Server (GFMS) event.
#r a9d2d2460138 switchtec: Add device IDs for PSX 24xG3 and PSX 48xG3
# No commands remaining.
# You are currently editing a commit while rebasing branch 'switchtec-pci-next' 
on '4fbd8d194f06'.
#
# Changes to be committed:
#   modified:   drivers/pci/switch/switchtec.c
#

# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
#
# Author:Kelvin Cao 
# Date:  Sat Oct 14 01:31:58 2017 +0800
#
# On branch switchtec-pci-next
# Changes to be committed:
#   modified:   drivers/pci/switch/switchtec.c
#
---
 drivers/pci/switch/switchtec.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/pci/switch/switchtec.c b/drivers/pci/switch/switchtec.c
index 7668d270725d..a0f8373f3b5f 100644
--- a/drivers/pci/switch/switchtec.c
+++ b/drivers/pci/switch/switchtec.c
@@ -1353,6 +1353,8 @@ static const struct pci_device_id switchtec_pci_tbl[] = {
SWITCHTEC_PCI_DEVICE(0x8534),  //PFX 64xG3
SWITCHTEC_PCI_DEVICE(0x8535),  //PFX 80xG3
SWITCHTEC_PCI_DEVICE(0x8536),  //PFX 96xG3
+   SWITCHTEC_PCI_DEVICE(0x8541),  //PSX 24xG3
+   SWITCHTEC_PCI_DEVICE(0x8542),  //PSX 32xG3
SWITCHTEC_PCI_DEVICE(0x8543),  //PSX 48xG3
SWITCHTEC_PCI_DEVICE(0x8544),  //PSX 64xG3
SWITCHTEC_PCI_DEVICE(0x8545),  //PSX 80xG3
-- 
2.11.0

[PATCH 1/2] switchtec: Added Global Fabric Manager Server (GFMS) event

[Logan Gunthorpe]

Add a new event type that is newly exposed by recent firmware. The event will
never occur if the firmware is too old. If user space tries to use this
event in an older kernel, it will just get an EINVAL which is perfectly
acceptable in the existing user space code.

Signed-off-by: Logan Gunthorpe 
---
 drivers/pci/switch/switchtec.c   | 1 +
 include/linux/switchtec.h| 3 +++
 include/uapi/linux/switchtec_ioctl.h | 3 ++-
 3 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/pci/switch/switchtec.c b/drivers/pci/switch/switchtec.c
index 730cc897b94d..7668d270725d 100644
--- a/drivers/pci/switch/switchtec.c
+++ b/drivers/pci/switch/switchtec.c
@@ -707,6 +707,7 @@ static const struct event_reg {
EV_GLB(SWITCHTEC_IOCTL_EVENT_CLI_MRPC_COMP_ASYNC,
   cli_mrpc_comp_async_hdr),
EV_GLB(SWITCHTEC_IOCTL_EVENT_GPIO_INT, gpio_interrupt_hdr),
+   EV_GLB(SWITCHTEC_IOCTL_EVENT_GFMS, gfms_event_hdr),
EV_PAR(SWITCHTEC_IOCTL_EVENT_PART_RESET, part_reset_hdr),
EV_PAR(SWITCHTEC_IOCTL_EVENT_MRPC_COMP, mrpc_comp_hdr),
EV_PAR(SWITCHTEC_IOCTL_EVENT_MRPC_COMP_ASYNC, mrpc_comp_async_hdr),
diff --git a/include/linux/switchtec.h b/include/linux/switchtec.h
index 09d73d0d1aa8..42d121174fe2 100644
--- a/include/linux/switchtec.h
+++ b/include/linux/switchtec.h
@@ -100,6 +100,9 @@ struct sw_event_regs {
u32 gpio_interrupt_hdr;
u32 gpio_interrupt_data;
u32 reserved16[4];
+   u32 gfms_event_hdr;
+   u32 gfms_event_data;
+   u32 reserved17[4];
 } __packed;
 
 enum {
diff --git a/include/uapi/linux/switchtec_ioctl.h 
b/include/uapi/linux/switchtec_ioctl.h
index 75df44373034..4f4daf8db954 100644
--- a/include/uapi/linux/switchtec_ioctl.h
+++ b/include/uapi/linux/switchtec_ioctl.h
@@ -88,7 +88,8 @@ struct switchtec_ioctl_event_summary {
 #define SWITCHTEC_IOCTL_EVENT_FORCE_SPEED  26
 #define SWITCHTEC_IOCTL_EVENT_CREDIT_TIMEOUT   27
 #define SWITCHTEC_IOCTL_EVENT_LINK_STATE   28
-#define SWITCHTEC_IOCTL_MAX_EVENTS 29
+#define SWITCHTEC_IOCTL_EVENT_GFMS 29
+#define SWITCHTEC_IOCTL_MAX_EVENTS 30
 
 #define SWITCHTEC_IOCTL_EVENT_LOCAL_PART_IDX -1
 #define SWITCHTEC_IOCTL_EVENT_IDX_ALL -2
-- 
2.11.0

[PATCH AUTOSEL for 4.4 11/32] USB: gadgetfs: Fix a potential memory leak in 'dev_config()'

[alexander . levin]

From: Christophe JAILLET 

[ Upstream commit b6e7aeeaf235901c42ec35de4633c7c69501d303 ]

'kbuf' is allocated just a few lines above using 'memdup_user()'.
If the 'if (dev->buf)' test fails, this memory is never released.

Signed-off-by: Christophe JAILLET 
Signed-off-by: Felipe Balbi 
Signed-off-by: Sasha Levin 
---
 drivers/usb/gadget/legacy/inode.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/gadget/legacy/inode.c 
b/drivers/usb/gadget/legacy/inode.c
index b6df47aa25af..81f3c9cb333c 100644
--- a/drivers/usb/gadget/legacy/inode.c
+++ b/drivers/usb/gadget/legacy/inode.c
@@ -1837,8 +1837,10 @@ dev_config (struct file *fd, const char __user *buf, 
size_t len, loff_t *ptr)
 
spin_lock_irq (&dev->lock);
value = -EINVAL;
-   if (dev->buf)
+   if (dev->buf) {
+   kfree(kbuf);
goto fail;
+   }
dev->buf = kbuf;
 
/* full or low speed config */
-- 
2.11.0

Re: [PATCH v5 next 1/5] modules:capabilities: add request_module_cap()

[Serge E. Hallyn]

Quoting Theodore Ts'o (ty...@mit.edu):
> Half the problem here is that with containers, people are changing the
> security model, because they want to let untrusted users have "root",
> without really having "root".  Part of the fundamental problem is that
> there are some well-meaning, but fundamentally misguided people, who
> have been asserting: "Containers are just as secure as VM's".
> 
> Well, they are not.  And the sooner people get past this, the better
> off they'll be

Just to be clear, module loading requires - and must always continue to
require - CAP_SYS_MODULE against the initial user namespace.  Containers
in user namespaces do not have that.

I don't believe anyone has ever claimed that containers which are not in
a user namespace are in any way secure.

(And as for the other claim, I'd prefer to stick to "VMs are in most
cases as insecure as properly configured containers" :)

-serge

[PATCH AUTOSEL for 4.4 12/32] kvm: nVMX: VMCLEAR should not cause the vCPU to shut down

[alexander . levin]

From: Jim Mattson 

[ Upstream commit 587d7e72aedca91cee80c0a56811649c3efab765 ]

VMCLEAR should silently ignore a failure to clear the launch state of
the VMCS referenced by the operand.

Signed-off-by: Jim Mattson 
[Changed "kvm_write_guest(vcpu->kvm" to "kvm_vcpu_write_guest(vcpu".]
Signed-off-by: Radim Krčmář 

Signed-off-by: Sasha Levin 
---
 arch/x86/kvm/vmx.c | 22 --
 1 file changed, 4 insertions(+), 18 deletions(-)

diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 9114588e3e61..aa8776848183 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -6927,9 +6927,8 @@ static int handle_vmoff(struct kvm_vcpu *vcpu)
 static int handle_vmclear(struct kvm_vcpu *vcpu)
 {
struct vcpu_vmx *vmx = to_vmx(vcpu);
+   u32 zero = 0;
gpa_t vmptr;
-   struct vmcs12 *vmcs12;
-   struct page *page;
 
if (!nested_vmx_check_permission(vcpu))
return 1;
@@ -6940,22 +6939,9 @@ static int handle_vmclear(struct kvm_vcpu *vcpu)
if (vmptr == vmx->nested.current_vmptr)
nested_release_vmcs12(vmx);
 
-   page = nested_get_page(vcpu, vmptr);
-   if (page == NULL) {
-   /*
-* For accurate processor emulation, VMCLEAR beyond available
-* physical memory should do nothing at all. However, it is
-* possible that a nested vmx bug, not a guest hypervisor bug,
-* resulted in this case, so let's shut down before doing any
-* more damage:
-*/
-   kvm_make_request(KVM_REQ_TRIPLE_FAULT, vcpu);
-   return 1;
-   }
-   vmcs12 = kmap(page);
-   vmcs12->launch_state = 0;
-   kunmap(page);
-   nested_release_page(page);
+   kvm_vcpu_write_guest(vcpu,
+   vmptr + offsetof(struct vmcs12, launch_state),
+   &zero, sizeof(zero));
 
nested_free_vmcs02(vmx, vmptr);
 
-- 
2.11.0

[PATCH AUTOSEL for 3.18 07/16] irqchip/crossbar: Fix incorrect type of register size

[alexander . levin]

From: Franck Demathieu 

[ Upstream commit 4b9de5da7e120c7f02395da729f0ec77ce7a6044 ]

The 'size' variable is unsigned according to the dt-bindings.
As this variable is used as integer in other places, create a new variable
that allows to fix the following sparse issue (-Wtypesign):

  drivers/irqchip/irq-crossbar.c:279:52: warning: incorrect type in argument 3 
(different signedness)
  drivers/irqchip/irq-crossbar.c:279:52:expected unsigned int [usertype] 
*out_value
  drivers/irqchip/irq-crossbar.c:279:52:got int *

Signed-off-by: Franck Demathieu 
Signed-off-by: Marc Zyngier 
Signed-off-by: Sasha Levin 
---
 drivers/irqchip/irq-crossbar.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/irqchip/irq-crossbar.c b/drivers/irqchip/irq-crossbar.c
index c03773bf02c7..8d332a36e560 100644
--- a/drivers/irqchip/irq-crossbar.c
+++ b/drivers/irqchip/irq-crossbar.c
@@ -176,7 +176,7 @@ static const struct irq_domain_ops routable_irq_domain_ops 
= {
 static int __init crossbar_of_init(struct device_node *node)
 {
int i, size, reserved = 0;
-   u32 max = 0, entry;
+   u32 max = 0, entry, reg_size;
const __be32 *irqsr;
int ret = -ENOMEM;
 
@@ -253,9 +253,9 @@ static int __init crossbar_of_init(struct device_node *node)
if (!cb->register_offsets)
goto err_irq_map;
 
-   of_property_read_u32(node, "ti,reg-size", &size);
+   of_property_read_u32(node, "ti,reg-size", ®_size);
 
-   switch (size) {
+   switch (reg_size) {
case 1:
cb->write = crossbar_writeb;
break;
@@ -281,7 +281,7 @@ static int __init crossbar_of_init(struct device_node *node)
continue;
 
cb->register_offsets[i] = reserved;
-   reserved += size;
+   reserved += reg_size;
}
 
of_property_read_u32(node, "ti,irqs-safe-map", &cb->safe_map);
-- 
2.11.0

[PATCH AUTOSEL for 4.4 31/32] powerpc/powernv/ioda2: Gracefully fail if too many TCE levels requested

[alexander . levin]

From: Alexey Kardashevskiy 

[ Upstream commit 7aafac11e308d37ed3c509829bb43d80c1811ac3 ]

The IODA2 specification says that a 64 DMA address cannot use top 4 bits
(3 are reserved and one is a "TVE select"); bottom page_shift bits
cannot be used for multilevel table addressing either.

The existing IODA2 table allocation code aligns the minimum TCE table
size to PAGE_SIZE so in the case of 64K system pages and 4K IOMMU pages,
we have 64-4-12=48 bits. Since 64K page stores 8192 TCEs, i.e. needs
13 bits, the maximum number of levels is 48/13 = 3 so we physically
cannot address more and EEH happens on DMA accesses.

This adds a check that too many levels were requested.

It is still possible to have 5 levels in the case of 4K system page size.

Signed-off-by: Alexey Kardashevskiy 
Acked-by: Gavin Shan 
Signed-off-by: Michael Ellerman 
Signed-off-by: Sasha Levin 
---
 arch/powerpc/platforms/powernv/pci-ioda.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c 
b/arch/powerpc/platforms/powernv/pci-ioda.c
index e40d0714679e..ecb7f3220355 100644
--- a/arch/powerpc/platforms/powernv/pci-ioda.c
+++ b/arch/powerpc/platforms/powernv/pci-ioda.c
@@ -2270,6 +2270,9 @@ static long pnv_pci_ioda2_table_alloc_pages(int nid, 
__u64 bus_offset,
level_shift = entries_shift + 3;
level_shift = max_t(unsigned, level_shift, PAGE_SHIFT);
 
+   if ((level_shift - 3) * levels + page_shift >= 60)
+   return -EINVAL;
+
/* Allocate TCE table */
addr = pnv_pci_ioda2_table_do_alloc_pages(nid, level_shift,
levels, tce_table_size, &offset, &total_allocated);
-- 
2.11.0

[PATCH AUTOSEL for 4.4 20/32] spi_ks8995: fix "BUG: key accdaa28 not in .data!"

[alexander . levin]

From: "Blomme, Maarten" 

[ Upstream commit 4342696df764ec65dcdfbd0c10d90ea52505f8ba ]

Signed-off-by: Maarten Blomme 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin 
---
 drivers/net/phy/spi_ks8995.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/phy/spi_ks8995.c b/drivers/net/phy/spi_ks8995.c
index c72c42206850..21d22f86134e 100644
--- a/drivers/net/phy/spi_ks8995.c
+++ b/drivers/net/phy/spi_ks8995.c
@@ -310,6 +310,7 @@ static int ks8995_probe(struct spi_device *spi)
if (err)
return err;
 
+   sysfs_attr_init(&ks->regs_attr.attr);
err = sysfs_create_bin_file(&spi->dev.kobj, &ks->regs_attr);
if (err) {
dev_err(&spi->dev, "unable to create sysfs file, err=%d\n",
-- 
2.11.0

[PATCH AUTOSEL for 3.18 04/16] libata: drop WARN from protocol error in ata_sff_qc_issue()

[alexander . levin]

From: Tejun Heo 

[ Upstream commit 0580b762a4d6b70817476b90042813f8573283fa ]

ata_sff_qc_issue() expects upper layers to never issue commands on a
command protocol that it doesn't implement.  While the assumption
holds fine with the usual IO path, nothing filters based on the
command protocol in the passthrough path (which was added later),
allowing the warning to be tripped with a passthrough command with the
right (well, wrong) protocol.

Failing with AC_ERR_SYSTEM is the right thing to do anyway.  Remove
the unnecessary WARN.

Reported-by: Dmitry Vyukov 
Link: 
http://lkml.kernel.org/r/cact4y+bxkvevnzu8up6x0qvqsj6wnoua_1exftsozc+smut...@mail.gmail.com
Signed-off-by: Tejun Heo 
Signed-off-by: Sasha Levin 
---
 drivers/ata/libata-sff.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/ata/libata-sff.c b/drivers/ata/libata-sff.c
index 12d337754e4a..58b0a58a7f1d 100644
--- a/drivers/ata/libata-sff.c
+++ b/drivers/ata/libata-sff.c
@@ -1480,7 +1480,6 @@ unsigned int ata_sff_qc_issue(struct ata_queued_cmd *qc)
break;
 
default:
-   WARN_ON_ONCE(1);
return AC_ERR_SYSTEM;
}
 
-- 
2.11.0

[PATCH AUTOSEL for 3.18 01/16] selftest/powerpc: Fix false failures for skipped tests

[alexander . levin]

From: Sachin Sant 

[ Upstream commit a6d8a21596df041f36f4c2ccc260c459e3e851f1 ]

Tests under alignment subdirectory are skipped when executed on previous
generation hardware, but harness still marks them as failed.

  test: test_copy_unaligned
  tags: git_version:unknown
  [SKIP] Test skipped on line 26
  skip: test_copy_unaligned
  selftests: copy_unaligned [FAIL]

The MAGIC_SKIP_RETURN_VALUE value assigned to rc variable is retained till
the program exit which causes the test to be marked as failed.

This patch resets the value before returning to the main() routine.
With this patch the test o/p is as follows:

  test: test_copy_unaligned
  tags: git_version:unknown
  [SKIP] Test skipped on line 26
  skip: test_copy_unaligned
  selftests: copy_unaligned [PASS]

Signed-off-by: Sachin Sant 
Signed-off-by: Michael Ellerman 
Signed-off-by: Sasha Levin 
---
 tools/testing/selftests/powerpc/harness.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/tools/testing/selftests/powerpc/harness.c 
b/tools/testing/selftests/powerpc/harness.c
index 8ebc58a09311..d1ed7bab65a5 100644
--- a/tools/testing/selftests/powerpc/harness.c
+++ b/tools/testing/selftests/powerpc/harness.c
@@ -105,9 +105,11 @@ int test_harness(int (test_function)(void), char *name)
 
rc = run_test(test_function, name);
 
-   if (rc == MAGIC_SKIP_RETURN_VALUE)
+   if (rc == MAGIC_SKIP_RETURN_VALUE) {
test_skip(name);
-   else
+   /* so that skipped test is not marked as failed */
+   rc = 0;
+   } else
test_finish(name, rc);
 
return rc;
-- 
2.11.0

[PATCH AUTOSEL for 3.18 03/16] USB: gadgetfs: Fix a potential memory leak in 'dev_config()'

[alexander . levin]

From: Christophe JAILLET 

[ Upstream commit b6e7aeeaf235901c42ec35de4633c7c69501d303 ]

'kbuf' is allocated just a few lines above using 'memdup_user()'.
If the 'if (dev->buf)' test fails, this memory is never released.

Signed-off-by: Christophe JAILLET 
Signed-off-by: Felipe Balbi 
Signed-off-by: Sasha Levin 
---
 drivers/usb/gadget/legacy/inode.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/gadget/legacy/inode.c 
b/drivers/usb/gadget/legacy/inode.c
index 368d07937848..e2d57e3d67c7 100644
--- a/drivers/usb/gadget/legacy/inode.c
+++ b/drivers/usb/gadget/legacy/inode.c
@@ -1921,8 +1921,10 @@ dev_config (struct file *fd, const char __user *buf, 
size_t len, loff_t *ptr)
 
spin_lock_irq (&dev->lock);
value = -EINVAL;
-   if (dev->buf)
+   if (dev->buf) {
+   kfree(kbuf);
goto fail;
+   }
dev->buf = kbuf;
 
/* full or low speed config */
-- 
2.11.0

Re: [PATCH 3/3] arm64: use -mno-implicit-float instead of -mgeneral-regs-only

[Nick Desaulniers]

On Wed, Nov 29, 2017 at 8:22 AM, Sami Tolvanen  wrote:
> On Wed, Nov 29, 2017 at 12:15:14PM +, Ard Biesheuvel wrote:
>> Do we still need these patches now that the AES code has been fixed?
>
> With your AES patch that Herbert just applied, this patch is no longer
> needed. Version macros in the first two patches will still be useful in
> future though.

Matthias, maybe for your recommended Clang patch sets, you can replace
this patch with
https://www.spinics.net/lists/arm-kernel/msg617947.html?

[PATCH AUTOSEL for 3.18 08/16] KVM: nVMX: reset nested_run_pending if the vCPU is going to be reset

[alexander . levin]

From: Wanpeng Li 

[ Upstream commit 2f707d97982286b307ef2a9b034e19aabc1abb56 ]

Reported by syzkaller:

WARNING: CPU: 1 PID: 27742 at arch/x86/kvm/vmx.c:11029
nested_vmx_vmexit+0x5c35/0x74d0 arch/x86/kvm/vmx.c:11029
CPU: 1 PID: 27742 Comm: a.out Not tainted 4.10.0+ #229
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
Call Trace:
 __dump_stack lib/dump_stack.c:15 [inline]
 dump_stack+0x2ee/0x3ef lib/dump_stack.c:51
 panic+0x1fb/0x412 kernel/panic.c:179
 __warn+0x1c4/0x1e0 kernel/panic.c:540
 warn_slowpath_null+0x2c/0x40 kernel/panic.c:583
 nested_vmx_vmexit+0x5c35/0x74d0 arch/x86/kvm/vmx.c:11029
 vmx_leave_nested arch/x86/kvm/vmx.c:11136 [inline]
 vmx_set_msr+0x1565/0x1910 arch/x86/kvm/vmx.c:3324
 kvm_set_msr+0xd4/0x170 arch/x86/kvm/x86.c:1099
 do_set_msr+0x11e/0x190 arch/x86/kvm/x86.c:1128
 __msr_io arch/x86/kvm/x86.c:2577 [inline]
 msr_io+0x24b/0x450 arch/x86/kvm/x86.c:2614
 kvm_arch_vcpu_ioctl+0x35b/0x46a0 arch/x86/kvm/x86.c:3497
 kvm_vcpu_ioctl+0x232/0x1120 arch/x86/kvm/../../../virt/kvm/kvm_main.c:2721
 vfs_ioctl fs/ioctl.c:43 [inline]
 do_vfs_ioctl+0x1bf/0x1790 fs/ioctl.c:683
 SYSC_ioctl fs/ioctl.c:698 [inline]
 SyS_ioctl+0x8f/0xc0 fs/ioctl.c:689
 entry_SYSCALL_64_fastpath+0x1f/0xc2

The syzkaller folks reported a nested_run_pending warning during userspace
clear VMX capability which is exposed to L1 before.

The warning gets thrown while doing

(*(uint32_t*)0x20aecfe8 = (uint32_t)0x1);
(*(uint32_t*)0x20aecfec = (uint32_t)0x0);
(*(uint32_t*)0x20aecff0 = (uint32_t)0x3a);
(*(uint32_t*)0x20aecff4 = (uint32_t)0x0);
(*(uint64_t*)0x20aecff8 = (uint64_t)0x0);
r[29] = syscall(__NR_ioctl, r[4], 0x4008ae89ul,
0x20aecfe8ul, 0, 0, 0, 0, 0, 0);

i.e. KVM_SET_MSR ioctl with

struct kvm_msrs {
.nmsrs = 1,
.pad = 0,
.entries = {
{.index = MSR_IA32_FEATURE_CONTROL,
 .reserved = 0,
 .data = 0}
}
}

The VMLANCH/VMRESUME emulation should be stopped since the CPU is going to
reset here. This patch resets the nested_run_pending since the CPU is going
to be reset hence there should be nothing pending.

Reported-by: Dmitry Vyukov 
Suggested-by: Radim Krčmář 
Cc: Paolo Bonzini 
Cc: Radim Krčmář 
Cc: Dmitry Vyukov 
Cc: David Hildenbrand 
Signed-off-by: Wanpeng Li 
Reviewed-by: David Hildenbrand 
Reviewed-by: Jim Mattson 
Signed-off-by: Radim Krčmář 
Signed-off-by: Sasha Levin 
---
 arch/x86/kvm/vmx.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index a9ca10baf936..1990f4c97a62 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -9082,8 +9082,10 @@ static void nested_vmx_vmexit(struct kvm_vcpu *vcpu, u32 
exit_reason,
  */
 static void vmx_leave_nested(struct kvm_vcpu *vcpu)
 {
-   if (is_guest_mode(vcpu))
+   if (is_guest_mode(vcpu)) {
+   to_vmx(vcpu)->nested.nested_run_pending = 0;
nested_vmx_vmexit(vcpu, -1, 0, 0);
+   }
free_nested(to_vmx(vcpu));
 }
 
-- 
2.11.0

[PATCH AUTOSEL for 4.4 32/32] EDAC, i5000, i5400: Fix use of MTR_DRAM_WIDTH macro

[alexander . levin]

From: Jérémy Lefaure 

[ Upstream commit e61555c29c28a4a3b6ba6207f4a0883ee236004d ]

The MTR_DRAM_WIDTH macro returns the data width. It is sometimes used
as if it returned a boolean true if the width if 8. Fix the tests where
MTR_DRAM_WIDTH is misused.

Signed-off-by: Jérémy Lefaure 
Cc: linux-edac 
Link: http://lkml.kernel.org/r/20170309011809.8340-1-jeremy.lefa...@lse.epita.fr
Signed-off-by: Borislav Petkov 
Signed-off-by: Sasha Levin 
---
 drivers/edac/i5000_edac.c | 2 +-
 drivers/edac/i5400_edac.c | 5 +++--
 2 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/edac/i5000_edac.c b/drivers/edac/i5000_edac.c
index 72e07e3cf718..2a09be5f4f86 100644
--- a/drivers/edac/i5000_edac.c
+++ b/drivers/edac/i5000_edac.c
@@ -1293,7 +1293,7 @@ static int i5000_init_csrows(struct mem_ctl_info *mci)
dimm->mtype = MEM_FB_DDR2;
 
/* ask what device type on this row */
-   if (MTR_DRAM_WIDTH(mtr))
+   if (MTR_DRAM_WIDTH(mtr) == 8)
dimm->dtype = DEV_X8;
else
dimm->dtype = DEV_X4;
diff --git a/drivers/edac/i5400_edac.c b/drivers/edac/i5400_edac.c
index 6ef6ad1ba16e..029dfe07b734 100644
--- a/drivers/edac/i5400_edac.c
+++ b/drivers/edac/i5400_edac.c
@@ -1207,13 +1207,14 @@ static int i5400_init_dimms(struct mem_ctl_info *mci)
 
dimm->nr_pages = size_mb << 8;
dimm->grain = 8;
-   dimm->dtype = MTR_DRAM_WIDTH(mtr) ? DEV_X8 : DEV_X4;
+   dimm->dtype = MTR_DRAM_WIDTH(mtr) == 8 ?
+ DEV_X8 : DEV_X4;
dimm->mtype = MEM_FB_DDR2;
/*
 * The eccc mechanism is SDDC (aka SECC), with
 * is similar to Chipkill.
 */
-   dimm->edac_mode = MTR_DRAM_WIDTH(mtr) ?
+   dimm->edac_mode = MTR_DRAM_WIDTH(mtr) == 8 ?
  EDAC_S8ECD8ED : EDAC_S4ECD4ED;
ndimms++;
}
-- 
2.11.0

[PATCH AUTOSEL for 3.18 16/16] EDAC, i5000, i5400: Fix use of MTR_DRAM_WIDTH macro

[alexander . levin]

From: Jérémy Lefaure 

[ Upstream commit e61555c29c28a4a3b6ba6207f4a0883ee236004d ]

The MTR_DRAM_WIDTH macro returns the data width. It is sometimes used
as if it returned a boolean true if the width if 8. Fix the tests where
MTR_DRAM_WIDTH is misused.

Signed-off-by: Jérémy Lefaure 
Cc: linux-edac 
Link: http://lkml.kernel.org/r/20170309011809.8340-1-jeremy.lefa...@lse.epita.fr
Signed-off-by: Borislav Petkov 
Signed-off-by: Sasha Levin 
---
 drivers/edac/i5000_edac.c | 2 +-
 drivers/edac/i5400_edac.c | 5 +++--
 2 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/edac/i5000_edac.c b/drivers/edac/i5000_edac.c
index 72e07e3cf718..2a09be5f4f86 100644
--- a/drivers/edac/i5000_edac.c
+++ b/drivers/edac/i5000_edac.c
@@ -1293,7 +1293,7 @@ static int i5000_init_csrows(struct mem_ctl_info *mci)
dimm->mtype = MEM_FB_DDR2;
 
/* ask what device type on this row */
-   if (MTR_DRAM_WIDTH(mtr))
+   if (MTR_DRAM_WIDTH(mtr) == 8)
dimm->dtype = DEV_X8;
else
dimm->dtype = DEV_X4;
diff --git a/drivers/edac/i5400_edac.c b/drivers/edac/i5400_edac.c
index 6ef6ad1ba16e..029dfe07b734 100644
--- a/drivers/edac/i5400_edac.c
+++ b/drivers/edac/i5400_edac.c
@@ -1207,13 +1207,14 @@ static int i5400_init_dimms(struct mem_ctl_info *mci)
 
dimm->nr_pages = size_mb << 8;
dimm->grain = 8;
-   dimm->dtype = MTR_DRAM_WIDTH(mtr) ? DEV_X8 : DEV_X4;
+   dimm->dtype = MTR_DRAM_WIDTH(mtr) == 8 ?
+ DEV_X8 : DEV_X4;
dimm->mtype = MEM_FB_DDR2;
/*
 * The eccc mechanism is SDDC (aka SECC), with
 * is similar to Chipkill.
 */
-   dimm->edac_mode = MTR_DRAM_WIDTH(mtr) ?
+   dimm->edac_mode = MTR_DRAM_WIDTH(mtr) == 8 ?
  EDAC_S8ECD8ED : EDAC_S4ECD4ED;
ndimms++;
}
-- 
2.11.0

Re: [PATCH net-next 0/3] rxrpc: Fixes

[David Howells]

David Miller  wrote:

> This email says "net-next", yet your patches say "net".

Sorry about that - it should be 'net'.  I copied an old cover note.  All the
patches have a macro substitution, but the cover note does not.  Do you want
me to repost?

David

[PATCH AUTOSEL for 3.18 12/16] ipv6: reorder icmpv6_init() and ip6_mr_init()

[alexander . levin]

From: WANG Cong 

[ Upstream commit 15e668070a64bb97f102ad9cf3bccbca0545cda8 ]

Andrey reported the following kernel crash:

kasan: GPF could be caused by NULL-ptr deref or user memory access
general protection fault:  [#1] SMP KASAN
Dumping ftrace buffer:
   (ftrace buffer empty)
Modules linked in:
CPU: 0 PID: 14446 Comm: syz-executor6 Not tainted 4.10.0+ #82
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
task: 88001f311700 task.stack: 88001f6e8000
RIP: 0010:ip6mr_sk_done+0x15a/0x3d0 net/ipv6/ip6mr.c:1618
RSP: 0018:88001f6ef418 EFLAGS: 00010202
RAX: dc00 RBX: 110003edde8c RCX: c900043ee000
RDX: 0004 RSI: 83e3b3f8 RDI: 0020
RBP: 88001f6ef508 R08: fbfff0dcc5d8 R09: 
R10: 86e62ec0 R11:  R12: 
R13:  R14: 88001f6ef4e0 R15: 8800380a0040
FS:  7f7a52cec700() GS:88003ec0() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 0061c500 CR3: 1f1ae000 CR4: 06f0
DR0: 2000 DR1: 2000 DR2: 
DR3:  DR6: 0ff0 DR7: 0600
Call Trace:
 rawv6_close+0x4c/0x80 net/ipv6/raw.c:1217
 inet_release+0xed/0x1c0 net/ipv4/af_inet.c:425
 inet6_release+0x50/0x70 net/ipv6/af_inet6.c:432
 sock_release+0x8d/0x1e0 net/socket.c:597
 __sock_create+0x39d/0x880 net/socket.c:1226
 sock_create_kern+0x3f/0x50 net/socket.c:1243
 inet_ctl_sock_create+0xbb/0x280 net/ipv4/af_inet.c:1526
 icmpv6_sk_init+0x163/0x500 net/ipv6/icmp.c:954
 ops_init+0x10a/0x550 net/core/net_namespace.c:115
 setup_net+0x261/0x660 net/core/net_namespace.c:291
 copy_net_ns+0x27e/0x540 net/core/net_namespace.c:396
9pnet_virtio: no channels available for device ./file1
 create_new_namespaces+0x437/0x9b0 kernel/nsproxy.c:106
 unshare_nsproxy_namespaces+0xae/0x1e0 kernel/nsproxy.c:205
 SYSC_unshare kernel/fork.c:2281 [inline]
 SyS_unshare+0x64e/0x1000 kernel/fork.c:2231
 entry_SYSCALL_64_fastpath+0x1f/0xc2

This is because net->ipv6.mr6_tables is not initialized at that point,
ip6mr_rules_init() is not called yet, therefore on the error path when
we iterator the list, we trigger this oops. Fix this by reordering
ip6mr_rules_init() before icmpv6_sk_init().

Reported-by: Andrey Konovalov 
Signed-off-by: Cong Wang 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin 
---
 net/ipv6/af_inet6.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/net/ipv6/af_inet6.c b/net/ipv6/af_inet6.c
index ad95905e7a70..552fba77327d 100644
--- a/net/ipv6/af_inet6.c
+++ b/net/ipv6/af_inet6.c
@@ -887,12 +887,12 @@ static int __init inet6_init(void)
err = register_pernet_subsys(&inet6_net_ops);
if (err)
goto register_pernet_fail;
-   err = icmpv6_init();
-   if (err)
-   goto icmp_fail;
err = ip6_mr_init();
if (err)
goto ipmr_fail;
+   err = icmpv6_init();
+   if (err)
+   goto icmp_fail;
err = ndisc_init();
if (err)
goto ndisc_fail;
@@ -1010,10 +1010,10 @@ igmp_fail:
ndisc_cleanup();
 ndisc_fail:
ip6_mr_cleanup();
-ipmr_fail:
-   icmpv6_cleanup();
 icmp_fail:
unregister_pernet_subsys(&inet6_net_ops);
+ipmr_fail:
+   icmpv6_cleanup();
 register_pernet_fail:
sock_unregister(PF_INET6);
rtnl_unregister_all(PF_INET6);
-- 
2.11.0

[PATCH ipsec] xfrm: fix XFRMA_OUTPUT_MARK policy entry

[Michal Kubecek]

This seems to be an obvious typo, NLA_U32 is type of the attribute, not its
(minimal) length.

Fixes: 077fbac405bf ("net: xfrm: support setting an output mark.")
Signed-off-by: Michal Kubecek 
---
 net/xfrm/xfrm_user.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/xfrm/xfrm_user.c b/net/xfrm/xfrm_user.c
index c2cfcc6fdb34..ff58c37469d6 100644
--- a/net/xfrm/xfrm_user.c
+++ b/net/xfrm/xfrm_user.c
@@ -2485,7 +2485,7 @@ static const struct nla_policy xfrma_policy[XFRMA_MAX+1] 
= {
[XFRMA_PROTO]   = { .type = NLA_U8 },
[XFRMA_ADDRESS_FILTER]  = { .len = sizeof(struct xfrm_address_filter) },
[XFRMA_OFFLOAD_DEV] = { .len = sizeof(struct xfrm_user_offload) },
-   [XFRMA_OUTPUT_MARK] = { .len = NLA_U32 },
+   [XFRMA_OUTPUT_MARK] = { .type = NLA_U32 },
 };
 
 static const struct nla_policy xfrma_spd_policy[XFRMA_SPD_MAX+1] = {
-- 
2.15.0

Re: [Xen-devel] [PATCH] Xen/pciback: Implement PCI slot or bus reset with 'do_flr' SysFS attribute

[Govinda Tatti]

Furthermore, contrary to what you claim in
your reply to Pasi, I can't see where you try an actual FLR first -
you go straight to pci_probe_reset_{slot,bus}(). If you actually
tried FLR first, only falling back to the other methods as "emulation",
I could certainly agree with the file name chosen.

Currently, multiple resets are being invoked (independently) in the context
of "xl attach/detach/shutdown/reboot".

- pci_reset_function_locked (invoked by pcistub_put_pci_dev())
This function tries various PCI reset methods including FLR.
- pcistub_reset_dev (called by toolsstack based on "do_flr" attribute)

While related in a certain way, I can't really see how this addresses
the comment.
pcistub_reset_dev() just tries slot or bus reset but not FLR since it is 
being
checked and executed by pci_reset_function_locked() if supported. May be 
we can
add FLR reset code to pcistub_reset_dev() and try FLR first before 
fall-back to

slot/bus reset.

Cheers
GOVINDA

Re: [RFC PATCH] KVM: x86: Allow Qemu/KVM to use PVH entry point

[Maran Wilson]

On 11/29/2017 12:21 AM, Juergen Gross wrote:

On 28/11/17 20:34, Maran Wilson wrote:

For certain applications it is desirable to rapidly boot a KVM virtual
machine. In cases where legacy hardware and software support within the
guest is not needed, Qemu should be able to boot directly into the
uncompressed Linux kernel binary without the need to run firmware.

There already exists an ABI to allow this for Xen PVH guests and the ABI is
supported by Linux and FreeBSD:

https://xenbits.xen.org/docs/unstable/misc/hvmlite.html

This PoC patch enables Qemu to use that same entry point for booting KVM
guests.

Even though the code is still PoC quality, I'm sending this as an RFC now
since there are a number of different ways the specific implementation
details can be handled. I chose a shared code path for Xen and KVM guests
but could just as easily create a separate code path that is advertised by
a different ELF note for KVM. There also seems to be some flexibility in
how the e820 table data is passed and how (or if) it should be identified
as e820 data. As a starting point, I've chosen the options that seem to
result in the smallest patch with minimal to no changes required of the
x86/HVM direct boot ABI.

I like the idea.

I'd rather split up the different hypervisor types early and use a
common set of service functions instead of special casing xen_guest
everywhere. This would make it much easier to support the KVM PVH
boot without the need to configure the kernel with CONFIG_XEN.


Thanks for the feedback. I'll try doing something like that as this 
patch moves from proof of concept to a real proposal.



Another option would be to use the same boot path as with grub: set
the boot params in zeropage and start at startup_32.


I think others have already responded about that. The main thing I was 
trying to avoid, was adding any Linux OS specific initialization (like 
zeropage) to QEMU. Especially since this PVH entry point already exists 
in Linux.


Thanks,
-Maran



Juergen


---
  arch/x86/xen/enlighten_pvh.c | 74 
  1 file changed, 55 insertions(+), 19 deletions(-)

diff --git a/arch/x86/xen/enlighten_pvh.c b/arch/x86/xen/enlighten_pvh.c
index 98ab176..d93f711 100644
--- a/arch/x86/xen/enlighten_pvh.c
+++ b/arch/x86/xen/enlighten_pvh.c
@@ -31,21 +31,46 @@ static void xen_pvh_arch_setup(void)
acpi_irq_model = ACPI_IRQ_MODEL_PLATFORM;
  }
  
-static void __init init_pvh_bootparams(void)

+static void __init init_pvh_bootparams(bool xen_guest)
  {
struct xen_memory_map memmap;
int rc;
  
  	memset(&pvh_bootparams, 0, sizeof(pvh_bootparams));
  
-	memmap.nr_entries = ARRAY_SIZE(pvh_bootparams.e820_table);

-   set_xen_guest_handle(memmap.buffer, pvh_bootparams.e820_table);
-   rc = HYPERVISOR_memory_op(XENMEM_memory_map, &memmap);
-   if (rc) {
-   xen_raw_printk("XENMEM_memory_map failed (%d)\n", rc);
-   BUG();
+   if (xen_guest) {
+   memmap.nr_entries = ARRAY_SIZE(pvh_bootparams.e820_table);
+   set_xen_guest_handle(memmap.buffer, pvh_bootparams.e820_table);
+   rc = HYPERVISOR_memory_op(XENMEM_memory_map, &memmap);
+   if (rc) {
+   xen_raw_printk("XENMEM_memory_map failed (%d)\n", rc);
+   BUG();
+   }
+   pvh_bootparams.e820_entries = memmap.nr_entries;
+   } else if (pvh_start_info.nr_modules > 1) {
+   /* The second module should be the e820 data for KVM guests */
+   struct hvm_modlist_entry *modaddr;
+   char e820_sig[] = "e820 data";
+   struct boot_e820_entry *ep;
+   struct e820_table *tp;
+   char *cmdline_str;
+   int idx;
+
+   modaddr = __va(pvh_start_info.modlist_paddr +
+  sizeof(struct hvm_modlist_entry));
+   cmdline_str = __va(modaddr->cmdline_paddr);
+
+   if ((modaddr->cmdline_paddr) &&
+   (!strncmp(e820_sig, cmdline_str, sizeof(e820_sig {
+   tp = __va(modaddr->paddr);
+   ep = (struct boot_e820_entry *)tp->entries;
+
+   pvh_bootparams.e820_entries = tp->nr_entries;
+
+   for (idx = 0; idx < tp->nr_entries ; idx++, ep++)
+   pvh_bootparams.e820_table[idx] = *ep;
+   }
}
-   pvh_bootparams.e820_entries = memmap.nr_entries;
  
  	if (pvh_bootparams.e820_entries < E820_MAX_ENTRIES_ZEROPAGE - 1) {

pvh_bootparams.e820_table[pvh_bootparams.e820_entries].addr =
@@ -55,8 +80,9 @@ static void __init init_pvh_bootparams(void)
pvh_bootparams.e820_table[pvh_bootparams.e820_entries].type =
E820_TYPE_RESERVED;
pvh_bootparams.e820_entries++;
-   } else
+   } else if (xen_guest) {
   

[PATCH AUTOSEL for 3.18 14/16] i2c: riic: fix restart condition

[alexander . levin]

From: Chris Brandt 

[ Upstream commit 2501c1bb054290679baad0ff7f4f07c714251f4c ]

While modifying the driver to use the STOP interrupt, the completion of the
intermediate transfers need to wake the driver back up in order to initiate
the next transfer (restart condition). Otherwise you get never ending
interrupts and only the first transfer sent.

Fixes: 71ccea095ea1 ("i2c: riic: correctly finish transfers")
Reported-by: Simon Horman 
Signed-off-by: Chris Brandt 
Tested-by: Simon Horman 
Signed-off-by: Wolfram Sang 
Signed-off-by: Sasha Levin 
---
 drivers/i2c/busses/i2c-riic.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/i2c/busses/i2c-riic.c b/drivers/i2c/busses/i2c-riic.c
index 7a7b71e97ba4..43e88e3c1d27 100644
--- a/drivers/i2c/busses/i2c-riic.c
+++ b/drivers/i2c/busses/i2c-riic.c
@@ -218,8 +218,12 @@ static irqreturn_t riic_tend_isr(int irq, void *data)
}
 
if (riic->is_last || riic->err) {
-   riic_clear_set_bit(riic, 0, ICIER_SPIE, RIIC_ICIER);
+   riic_clear_set_bit(riic, ICIER_TEIE, ICIER_SPIE, RIIC_ICIER);
writeb(ICCR2_SP, riic->base + RIIC_ICCR2);
+   } else {
+   /* Transfer is complete, but do not send STOP */
+   riic_clear_set_bit(riic, ICIER_TEIE, 0, RIIC_ICIER);
+   complete(&riic->msg_done);
}
 
return IRQ_HANDLED;
-- 
2.11.0

[PATCH AUTOSEL for 4.4 09/32] HID: chicony: Add support for another ASUS Zen AiO keyboard

[alexander . levin]

From: Daniel Drake 

[ Upstream commit f2f10b7e722a75c6d75a7f7cd06b0eee3ae20f7c ]

Add support for media keys on the keyboard that comes with the
Asus V221ID and ZN241IC All In One computers.

The keys to support here are WLAN, BRIGHTNESSDOWN and BRIGHTNESSUP.

This device is not visibly branded as Chicony, and the USB Vendor ID
suggests that it is a JESS device. However this seems like the right place
to put it: the usage codes are identical to the currently supported
devices, and this driver already supports the ASUS AIO keyboard AK1D.

Signed-off-by: Daniel Drake 
Signed-off-by: Jiri Kosina 
Signed-off-by: Sasha Levin 
---
 drivers/hid/Kconfig   | 4 ++--
 drivers/hid/hid-chicony.c | 1 +
 drivers/hid/hid-core.c| 1 +
 drivers/hid/hid-ids.h | 1 +
 4 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/hid/Kconfig b/drivers/hid/Kconfig
index 513a16cc6e18..2729ab3557bb 100644
--- a/drivers/hid/Kconfig
+++ b/drivers/hid/Kconfig
@@ -165,11 +165,11 @@ config HID_CHERRY
Support for Cherry Cymotion keyboard.
 
 config HID_CHICONY
-   tristate "Chicony Tactical pad"
+   tristate "Chicony devices"
depends on HID
default !EXPERT
---help---
-   Support for Chicony Tactical pad.
+   Support for Chicony Tactical pad and special keys on Chicony keyboards.
 
 config HID_CORSAIR
tristate "Corsair devices"
diff --git a/drivers/hid/hid-chicony.c b/drivers/hid/hid-chicony.c
index bc3cec199fee..f04ed9aabc3f 100644
--- a/drivers/hid/hid-chicony.c
+++ b/drivers/hid/hid-chicony.c
@@ -86,6 +86,7 @@ static const struct hid_device_id ch_devices[] = {
{ HID_USB_DEVICE(USB_VENDOR_ID_CHICONY, 
USB_DEVICE_ID_CHICONY_WIRELESS2) },
{ HID_USB_DEVICE(USB_VENDOR_ID_CHICONY, USB_DEVICE_ID_CHICONY_AK1D) },
{ HID_USB_DEVICE(USB_VENDOR_ID_CHICONY, 
USB_DEVICE_ID_CHICONY_ACER_SWITCH12) },
+   { HID_USB_DEVICE(USB_VENDOR_ID_JESS, USB_DEVICE_ID_JESS_ZEN_AIO_KBD) },
{ }
 };
 MODULE_DEVICE_TABLE(hid, ch_devices);
diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
index 11a051bd8a8b..1a1fc8351289 100644
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -1867,6 +1867,7 @@ static const struct hid_device_id 
hid_have_special_driver[] = {
{ HID_USB_DEVICE(USB_VENDOR_ID_HOLTEK_ALT, 
USB_DEVICE_ID_HOLTEK_ALT_MOUSE_A081) },
{ HID_USB_DEVICE(USB_VENDOR_ID_HOLTEK_ALT, 
USB_DEVICE_ID_HOLTEK_ALT_MOUSE_A0C2) },
{ HID_USB_DEVICE(USB_VENDOR_ID_HUION, USB_DEVICE_ID_HUION_TABLET) },
+   { HID_USB_DEVICE(USB_VENDOR_ID_JESS, USB_DEVICE_ID_JESS_ZEN_AIO_KBD) },
{ HID_USB_DEVICE(USB_VENDOR_ID_JESS2, 
USB_DEVICE_ID_JESS2_COLOR_RUMBLE_PAD) },
{ HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_ION, USB_DEVICE_ID_ICADE) },
{ HID_USB_DEVICE(USB_VENDOR_ID_KENSINGTON, USB_DEVICE_ID_KS_SLIMBLADE) 
},
diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index 37cbc2ecfc5f..6937086060a6 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -523,6 +523,7 @@
 
 #define USB_VENDOR_ID_JESS 0x0c45
 #define USB_DEVICE_ID_JESS_YUREX   0x1010
+#define USB_DEVICE_ID_JESS_ZEN_AIO_KBD 0x5112
 
 #define USB_VENDOR_ID_JESS20x0f30
 #define USB_DEVICE_ID_JESS2_COLOR_RUMBLE_PAD 0x0111
-- 
2.11.0

[PATCH] staging: pi433: fix include asm/compat.h to linux/compat.h

[Victor Carvalho]

staging: pi433: fix include asm/compat.h to linux/compat.h

Signed-off-by: Victor Carvalho 
---
 drivers/staging/pi433/pi433_if.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/pi433/pi433_if.c b/drivers/staging/pi433/pi433_if.c
index 3404cb9722c9..763104760650 100644
--- a/drivers/staging/pi433/pi433_if.c
+++ b/drivers/staging/pi433/pi433_if.c
@@ -48,7 +48,7 @@
 #include 
 #include 
 #ifdef CONFIG_COMPAT
-#include 
+#include 
 #endif
 
 #include "pi433_if.h"
-- 
2.14.3

[PATCH AUTOSEL for 4.4 05/32] module: set __jump_table alignment to 8

[alexander . levin]

From: David Daney 

[ Upstream commit ab42632156becd35d3884ee5c14da2bedbf3149a ]

For powerpc the __jump_table section in modules is not aligned, this
causes a WARN_ON() splat when loading a module containing a __jump_table.

Strict alignment became necessary with commit 3821fd35b58d
("jump_label: Reduce the size of struct static_key"), currently in
linux-next, which uses the two least significant bits of pointers to
__jump_table elements.

Fix by forcing __jump_table to 8, which is the same alignment used for
this section in the kernel proper.

Link: http://lkml.kernel.org/r/20170301220453.4756-1-david.da...@cavium.com

Reviewed-by: Jason Baron 
Acked-by: Jessica Yu 
Acked-by: Michael Ellerman  (powerpc)
Tested-by: Sachin Sant 
Signed-off-by: David Daney 
Signed-off-by: Steven Rostedt (VMware) 
Signed-off-by: Sasha Levin 
---
 scripts/module-common.lds | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/scripts/module-common.lds b/scripts/module-common.lds
index 73a2c7da0e55..53234e85192a 100644
--- a/scripts/module-common.lds
+++ b/scripts/module-common.lds
@@ -19,4 +19,6 @@ SECTIONS {
 
. = ALIGN(8);
.init_array 0 : { *(SORT(.init_array.*)) *(.init_array) }
+
+   __jump_table0 : ALIGN(8) { KEEP(*(__jump_table)) }
 }
-- 
2.11.0

[PATCH AUTOSEL for 4.9 17/52] gpio: altera: Use handle_level_irq when configured as a level_high

[alexander . levin]

From: Phil Reid 

[ Upstream commit f759921cfbf4847319d197a6ed7c9534d593f8bc ]

When a threaded irq handler is chained attached to one of the gpio
pins when configure for level irq the altera_gpio_irq_leveL_high_handler
does not mask the interrupt while being handled by the chained irq.
This resulting in the threaded irq not getting enough cycles to complete
quickly enough before the irq was disabled as faulty. handle_level_irq
should be used in this situation instead of handle_simple_irq.

In gpiochip_irqchip_add set default handler to handle_bad_irq as
per Documentation/gpio/driver.txt. Then set the correct handler in
the set_type callback.

Signed-off-by: Phil Reid 
Signed-off-by: Linus Walleij 
Signed-off-by: Sasha Levin 
---
 drivers/gpio/gpio-altera.c | 26 +++---
 1 file changed, 11 insertions(+), 15 deletions(-)

diff --git a/drivers/gpio/gpio-altera.c b/drivers/gpio/gpio-altera.c
index 5bddbd507ca9..3fe6a21e05a5 100644
--- a/drivers/gpio/gpio-altera.c
+++ b/drivers/gpio/gpio-altera.c
@@ -90,21 +90,18 @@ static int altera_gpio_irq_set_type(struct irq_data *d,
 
altera_gc = gpiochip_get_data(irq_data_get_irq_chip_data(d));
 
-   if (type == IRQ_TYPE_NONE)
+   if (type == IRQ_TYPE_NONE) {
+   irq_set_handler_locked(d, handle_bad_irq);
return 0;
-   if (type == IRQ_TYPE_LEVEL_HIGH &&
-   altera_gc->interrupt_trigger == IRQ_TYPE_LEVEL_HIGH)
-   return 0;
-   if (type == IRQ_TYPE_EDGE_RISING &&
-   altera_gc->interrupt_trigger == IRQ_TYPE_EDGE_RISING)
-   return 0;
-   if (type == IRQ_TYPE_EDGE_FALLING &&
-   altera_gc->interrupt_trigger == IRQ_TYPE_EDGE_FALLING)
-   return 0;
-   if (type == IRQ_TYPE_EDGE_BOTH &&
-   altera_gc->interrupt_trigger == IRQ_TYPE_EDGE_BOTH)
+   }
+   if (type == altera_gc->interrupt_trigger) {
+   if (type == IRQ_TYPE_LEVEL_HIGH)
+   irq_set_handler_locked(d, handle_level_irq);
+   else
+   irq_set_handler_locked(d, handle_simple_irq);
return 0;
-
+   }
+   irq_set_handler_locked(d, handle_bad_irq);
return -EINVAL;
 }
 
@@ -230,7 +227,6 @@ static void altera_gpio_irq_edge_handler(struct irq_desc 
*desc)
chained_irq_exit(chip, desc);
 }
 
-
 static void altera_gpio_irq_leveL_high_handler(struct irq_desc *desc)
 {
struct altera_gpio_chip *altera_gc;
@@ -310,7 +306,7 @@ static int altera_gpio_probe(struct platform_device *pdev)
altera_gc->interrupt_trigger = reg;
 
ret = gpiochip_irqchip_add(&altera_gc->mmchip.gc, &altera_irq_chip, 0,
-   handle_simple_irq, IRQ_TYPE_NONE);
+   handle_bad_irq, IRQ_TYPE_NONE);
 
if (ret) {
dev_err(&pdev->dev, "could not add irqchip\n");
-- 
2.11.0

[PATCH AUTOSEL for 4.4 28/32] netfilter: don't track fragmented packets

[alexander . levin]

From: Florian Westphal 

[ Upstream commit 7b4fdf77a450ec0fdcb2f677b080ddbf2c186544 ]

Andrey reports syzkaller splat caused by

NF_CT_ASSERT(!ip_is_fragment(ip_hdr(skb)));

in ipv4 nat.  But this assertion (and the comment) are wrong, this function
does see fragments when IP_NODEFRAG setsockopt is used.

As conntrack doesn't track packets without complete l4 header, only the
first fragment is tracked.

Because applying nat to first packet but not the rest makes no sense this
also turns off tracking of all fragments.

Reported-by: Andrey Konovalov 
Signed-off-by: Florian Westphal 
Signed-off-by: Pablo Neira Ayuso 
Signed-off-by: Sasha Levin 
---
 net/ipv4/netfilter/nf_conntrack_l3proto_ipv4.c | 4 
 net/ipv4/netfilter/nf_nat_l3proto_ipv4.c   | 5 -
 2 files changed, 4 insertions(+), 5 deletions(-)

diff --git a/net/ipv4/netfilter/nf_conntrack_l3proto_ipv4.c 
b/net/ipv4/netfilter/nf_conntrack_l3proto_ipv4.c
index 461ca926fd39..6a20195a3a2a 100644
--- a/net/ipv4/netfilter/nf_conntrack_l3proto_ipv4.c
+++ b/net/ipv4/netfilter/nf_conntrack_l3proto_ipv4.c
@@ -158,6 +158,10 @@ static unsigned int ipv4_conntrack_local(void *priv,
if (skb->len < sizeof(struct iphdr) ||
ip_hdrlen(skb) < sizeof(struct iphdr))
return NF_ACCEPT;
+
+   if (ip_is_fragment(ip_hdr(skb))) /* IP_NODEFRAG setsockopt set */
+   return NF_ACCEPT;
+
return nf_conntrack_in(state->net, PF_INET, state->hook, skb);
 }
 
diff --git a/net/ipv4/netfilter/nf_nat_l3proto_ipv4.c 
b/net/ipv4/netfilter/nf_nat_l3proto_ipv4.c
index 5075b7ecd26d..98a56077f604 100644
--- a/net/ipv4/netfilter/nf_nat_l3proto_ipv4.c
+++ b/net/ipv4/netfilter/nf_nat_l3proto_ipv4.c
@@ -268,11 +268,6 @@ nf_nat_ipv4_fn(void *priv, struct sk_buff *skb,
/* maniptype == SRC for postrouting. */
enum nf_nat_manip_type maniptype = HOOK2MANIP(state->hook);
 
-   /* We never see fragments: conntrack defrags on pre-routing
-* and local-out, and nf_nat_out protects post-routing.
-*/
-   NF_CT_ASSERT(!ip_is_fragment(ip_hdr(skb)));
-
ct = nf_ct_get(skb, &ctinfo);
/* Can't track?  It's not due to stress, or conntrack would
 * have dropped it.  Hence it's the user's responsibilty to
-- 
2.11.0

[PATCH AUTOSEL for 4.9 24/52] kvm: nVMX: VMCLEAR should not cause the vCPU to shut down

[alexander . levin]

From: Jim Mattson 

[ Upstream commit 587d7e72aedca91cee80c0a56811649c3efab765 ]

VMCLEAR should silently ignore a failure to clear the launch state of
the VMCS referenced by the operand.

Signed-off-by: Jim Mattson 
[Changed "kvm_write_guest(vcpu->kvm" to "kvm_vcpu_write_guest(vcpu".]
Signed-off-by: Radim Krčmář 

Signed-off-by: Sasha Levin 
---
 arch/x86/kvm/vmx.c | 22 --
 1 file changed, 4 insertions(+), 18 deletions(-)

diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index a8ae57acb6f6..22476d2ce002 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -7206,9 +7206,8 @@ static int handle_vmoff(struct kvm_vcpu *vcpu)
 static int handle_vmclear(struct kvm_vcpu *vcpu)
 {
struct vcpu_vmx *vmx = to_vmx(vcpu);
+   u32 zero = 0;
gpa_t vmptr;
-   struct vmcs12 *vmcs12;
-   struct page *page;
 
if (!nested_vmx_check_permission(vcpu))
return 1;
@@ -7219,22 +7218,9 @@ static int handle_vmclear(struct kvm_vcpu *vcpu)
if (vmptr == vmx->nested.current_vmptr)
nested_release_vmcs12(vmx);
 
-   page = nested_get_page(vcpu, vmptr);
-   if (page == NULL) {
-   /*
-* For accurate processor emulation, VMCLEAR beyond available
-* physical memory should do nothing at all. However, it is
-* possible that a nested vmx bug, not a guest hypervisor bug,
-* resulted in this case, so let's shut down before doing any
-* more damage:
-*/
-   kvm_make_request(KVM_REQ_TRIPLE_FAULT, vcpu);
-   return 1;
-   }
-   vmcs12 = kmap(page);
-   vmcs12->launch_state = 0;
-   kunmap(page);
-   nested_release_page(page);
+   kvm_vcpu_write_guest(vcpu,
+   vmptr + offsetof(struct vmcs12, launch_state),
+   &zero, sizeof(zero));
 
nested_free_vmcs02(vmx, vmptr);
 
-- 
2.11.0

[PATCH AUTOSEL for 4.9 28/52] scsi: lpfc: Fix crash during Hardware error recovery on SLI3 adapters

[alexander . levin]

From: James Smart 

[ Upstream commit 5d181531bc6169e19a02a27d202cf0e982db9d0e ]

if REG_VPI fails, the driver was incorrectly issuing INIT_VFI
(a SLI4 command) on a SLI3 adapter.

Signed-off-by: Dick Kennedy 
Signed-off-by: James Smart 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Sasha Levin 
---
 drivers/scsi/lpfc/lpfc_els.c | 14 ++
 1 file changed, 10 insertions(+), 4 deletions(-)

diff --git a/drivers/scsi/lpfc/lpfc_els.c b/drivers/scsi/lpfc/lpfc_els.c
index 4df3cdcf88ce..9c9563312a3d 100644
--- a/drivers/scsi/lpfc/lpfc_els.c
+++ b/drivers/scsi/lpfc/lpfc_els.c
@@ -8185,11 +8185,17 @@ lpfc_cmpl_reg_new_vport(struct lpfc_hba *phba, 
LPFC_MBOXQ_t *pmb)
spin_lock_irq(shost->host_lock);
vport->fc_flag |= FC_VPORT_NEEDS_REG_VPI;
spin_unlock_irq(shost->host_lock);
-   if (vport->port_type == LPFC_PHYSICAL_PORT
-   && !(vport->fc_flag & FC_LOGO_RCVD_DID_CHNG))
-   lpfc_issue_init_vfi(vport);
-   else
+   if (mb->mbxStatus == MBX_NOT_FINISHED)
+   break;
+   if ((vport->port_type == LPFC_PHYSICAL_PORT) &&
+   !(vport->fc_flag & FC_LOGO_RCVD_DID_CHNG)) {
+   if (phba->sli_rev == LPFC_SLI_REV4)
+   lpfc_issue_init_vfi(vport);
+   else
+   lpfc_initial_flogi(vport);
+   } else {
lpfc_initial_fdisc(vport);
+   }
break;
}
} else {
-- 
2.11.0

[PATCH AUTOSEL for 4.9 15/52] ARM: OMAP2+: Release device node after it is no longer needed.

[alexander . levin]

From: Guenter Roeck 

[ Upstream commit b92675d998a9fa37fe9e0e35053a95b4a23c158b ]

The device node returned by of_find_node_by_name() needs to be released
after it is no longer needed to avoid a device node leak.

Signed-off-by: Guenter Roeck 
Signed-off-by: Tony Lindgren 
Signed-off-by: Sasha Levin 
---
 arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c 
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index 483658d86f80..bca54154e14f 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -3910,15 +3910,20 @@ int __init omap3xxx_hwmod_init(void)
 
if (h_sham && omap3xxx_hwmod_is_hs_ip_block_usable(bus, "sham")) {
r = omap_hwmod_register_links(h_sham);
-   if (r < 0)
+   if (r < 0) {
+   of_node_put(bus);
return r;
+   }
}
 
if (h_aes && omap3xxx_hwmod_is_hs_ip_block_usable(bus, "aes")) {
r = omap_hwmod_register_links(h_aes);
-   if (r < 0)
+   if (r < 0) {
+   of_node_put(bus);
return r;
+   }
}
+   of_node_put(bus);
 
/*
 * Register hwmod links specific to certain ES levels of a
-- 
2.11.0

Re: [PATCH v4] perf tools: Add ARM Statistical Profiling Extensions (SPE) support

[Kim Phillips]

Hi Arnaldo,

Just got off the phone with Mark, who said he's at least a couple of
weeks away from reviewing this.

The SPE kernel-side PMU driver is already in Linus' tree, destined to
be in the 4.15 release (commit d5d9696b0380 "drivers/perf: Add support
for ARMv8.2 Statistical Profiling Extension").

How are things supposed to work for the userspace side to be in sync,
given the incumbent reviewer lag?

Kim

On Tue, 21 Nov 2017 17:33:02 -0600
Kim Phillips  wrote:

> 'perf record' and 'perf report --dump-raw-trace' supported in this
> release.
> 
> Example usage:
> 
> $ ./perf record -e arm_spe_0/ts_enable=1,pa_enable=1/ \
>   dd if=/dev/zero of=/dev/null count=1
> 
> perf report --dump-raw-trace
> 
> Note that the perf.data file is portable, so the report can be run on
> another architecture host if necessary.
> 
> Output will contain raw SPE data and its textual representation, such
> as:
> 
> 0x550 [0x30]: PERF_RECORD_AUXTRACE size: 0xc408  offset: 0  ref: 0x30005619  
> idx: 3  tid: 2109  cpu: 3
> .
> . ... ARM SPE data: size 50184 bytes
> .  :  49 00   LD
> .  0002:  b2 00 9c 7b 7a 00 80 ff ff  VA 
> 0x80007a7b9c00
> .  000b:  9a 00 00LAT 0 XLAT
> .  000e:  42 16   EV RETIRED 
> L1D-ACCESS TLB-ACCESS
> .  0010:  b0 b0 c9 15 08 00 00 ff ff  PC 
> 0xff0815c9b0 el3 ns=1
> .  0019:  98 00 00LAT 0 TOT
> .  001c:  71 00 20 fa fd 16 00 00 00  TS 98750308352
> .  0025:  49 01   ST
> .  0027:  b2 60 bc 0c 0f 00 00 ff ff  VA 
> 0x0f0cbc60
> .  0030:  9a 00 00LAT 0 XLAT
> .  0033:  42 16   EV RETIRED 
> L1D-ACCESS TLB-ACCESS
> .  0035:  b0 48 cc 15 08 00 00 ff ff  PC 
> 0xff0815cc48 el3 ns=1
> .  003e:  98 00 00LAT 0 TOT
> .  0041:  71 00 20 fa fd 16 00 00 00  TS 98750308352
> .  004a:  48 00   INSN-OTHER
> .  004c:  42 02   EV RETIRED
> .  004e:  b0 ac 47 0c 08 00 00 ff ff  PC 
> 0xff080c47ac el3 ns=1
> .  0057:  98 00 00LAT 0 TOT
> .  005a:  71 00 20 fa fd 16 00 00 00  TS 98750308352
> .  0063:  49 00   LD
> .  0065:  b2 18 48 e5 7a 00 80 ff ff  VA 
> 0x80007ae54818
> .  006e:  9a 00 00LAT 0 XLAT
> .  0071:  42 16   EV RETIRED 
> L1D-ACCESS TLB-ACCESS
> .  0073:  b0 08 f8 15 08 00 00 ff ff  PC 
> 0xff0815f808 el3 ns=1
> .  007c:  98 00 00LAT 0 TOT
> .  007f:  71 00 20 fa fd 16 00 00 00  TS 98750308352
> ...
> 
> Other release notes:
> 
> - applies to acme's perf/{core,urgent} branches, likely elsewhere
> 
> - Report is self-contained within the tool.  Record requires enabling
>   the kernel SPE driver by setting CONFIG_ARM_SPE_PMU.
> 
> - the intel-bts implementation was used as a starting point; its
>   min/default/max buffer sizes and power of 2 pages granularity need to be
>   revisited for ARM SPE
> 
> - recording across multiple SPE clusters/domains not supported
> 
> - snapshot support (record -S), and conversion to native perf events
>   (e.g., via 'perf inject --itrace'), are also not supported
> 
> - technically both cs-etm and spe can be used simultaneously, however
>   disabled for simplicity in this release
> 
> Signed-off-by: Kim Phillips 
> ---
> v4: rebased onto acme's perf/core, whitespace fixes.
> 
> v3: trying to address comments from v2:
> 
> - despite adding a find_all_arm_spe_pmus() function to scan for all
>   arm_spe_ device instances, in order to ensure auxtrace_record__init
>   successfully matches the evsel type with the correct arm_spe_pmu type,
>   I am still having trouble running in multi-SPE PPI (heterogeneous)
>   environments (mmap fails with EOPNOTSUPP, as does running with
>   --per-thread on homogeneous systems).
> 
> - arm_spe_reference: use gettime instead of direct cntvct register access
> 
> - spe-decoder: add a comment for why SPE_EVENTS code sets packet->index.
> 
> - added arm_spe_pmu_default_config that accesses the driver
>   caps/min_interval and sets the default sampling period to it.  This way
>   users don't have to specify -c explicitly.  Also set is_uncore to false.
> 
> - set more sampling bits in the arm_spe and its tracking evsel.  Still
>   unsure if too liberal, and not sure whether it needs anoth

Re: [PATCH 2/3] kbuild: add cc-if-name-version and compiler-specific variants

[Nick Desaulniers]

We could use something like this to warn people trying to build the
kernel with clang-3.8 for instance.

[PATCH v2 8/8] ARM: dts: omap3-n900: Fix the audio CODEC's reset pin

[Andrew F. Davis]

The correct DT property for specifying a GPIO used for reset
is "reset-gpios", fix this here.

Fixes: 14e3e295b2b9 ("ARM: dts: omap3-n900: Add TLV320AIC3X support")

Signed-off-by: Andrew F. Davis 
---
 arch/arm/boot/dts/omap3-n900.dts | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/omap3-n900.dts b/arch/arm/boot/dts/omap3-n900.dts
index 669c51c00c00..5362139d5312 100644
--- a/arch/arm/boot/dts/omap3-n900.dts
+++ b/arch/arm/boot/dts/omap3-n900.dts
@@ -558,7 +558,7 @@
tlv320aic3x: tlv320aic3x@18 {
compatible = "ti,tlv320aic3x";
reg = <0x18>;
-   gpio-reset = <&gpio2 28 GPIO_ACTIVE_HIGH>; /* 60 */
+   reset-gpios = <&gpio2 28 GPIO_ACTIVE_LOW>; /* 60 */
ai3x-gpio-func = <
0 /* AIC3X_GPIO1_FUNC_DISABLED */
5 /* AIC3X_GPIO2_FUNC_DIGITAL_MIC_INPUT */
@@ -575,7 +575,7 @@
tlv320aic3x_aux: tlv320aic3x@19 {
compatible = "ti,tlv320aic3x";
reg = <0x19>;
-   gpio-reset = <&gpio2 28 GPIO_ACTIVE_HIGH>; /* 60 */
+   reset-gpios = <&gpio2 28 GPIO_ACTIVE_LOW>; /* 60 */
 
AVDD-supply = <&vmmc2>;
DRVDD-supply = <&vmmc2>;
-- 
2.15.0

Re: [RFC PATCH] KVM: x86: Allow Qemu/KVM to use PVH entry point

[Paolo Bonzini]

On 29/11/2017 18:14, Maran Wilson wrote:
> That is one option. I guess this gets into a discussion about the QEMU
> side of the upcoming patches that would follow ...
> 
> I'm currently just initializing the CPU state in QEMU for testing since
> there is such minimal (non Linux specific) setup that is required by the
> ABI.  And (borrowing from the Intel clear container patches) that VM
> setup is only performed when user selects the "nofw" option with the q35
> model. But yeah, if folks think it important to move all such machine
> state initialization out of QEMU and into an option ROM, I can look into
> coding it up that way for the QEMU patches.

Yes, please do an option ROM.  I'll take care of porting it to qboot.

Thanks,

Paolo

[PATCH v2 3/8] ASoC: tlv320aic31xx: Fix the reset GPIO OF name

[Andrew F. Davis]

The correct DT property for specifying a GPIO used for reset
is "reset-gpios", fix this here.

Fixes: e00447fafbf7 ("ASoC: tlv320aic31xx: Add basic codec driver 
implementation")

Signed-off-by: Andrew F. Davis 
---
 sound/soc/codecs/tlv320aic31xx.c | 11 +--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/sound/soc/codecs/tlv320aic31xx.c b/sound/soc/codecs/tlv320aic31xx.c
index e2862372c26e..4837f25b0760 100644
--- a/sound/soc/codecs/tlv320aic31xx.c
+++ b/sound/soc/codecs/tlv320aic31xx.c
@@ -1279,9 +1279,16 @@ static void aic31xx_pdata_from_of(struct aic31xx_priv 
*aic31xx)
aic31xx->pdata.micbias_vg = MICBIAS_2_0V;
}
 
-   ret = of_get_named_gpio(np, "gpio-reset", 0);
-   if (ret > 0)
+   ret = of_get_named_gpio(np, "reset-gpios", 0);
+   if (ret > 0) {
aic31xx->pdata.gpio_reset = ret;
+   } else {
+   ret = of_get_named_gpio(np, "gpio-reset", 0);
+   if (ret > 0) {
+   dev_warn(aic31xx->dev, "Using deprecated property 
\"gpio-reset\", please update your DT");
+   aic31xx->pdata.gpio_reset = ret;
+   }
+   }
 }
 #else /* CONFIG_OF */
 static void aic31xx_pdata_from_of(struct aic31xx_priv *aic31xx)
-- 
2.15.0

[PATCH v2 4/8] ASoC: tlv320aic3x: Fix the reset GPIO OF name

[Andrew F. Davis]

The correct DT property for specifying a GPIO used for reset
is "reset-gpios", fix this here.

Fixes: c24fdc886fde ("ASoC: tlv320aic3x: Add device tree bindings")

Signed-off-by: Andrew F. Davis 
---
 sound/soc/codecs/tlv320aic3x.c | 15 +++
 1 file changed, 11 insertions(+), 4 deletions(-)

diff --git a/sound/soc/codecs/tlv320aic3x.c b/sound/soc/codecs/tlv320aic3x.c
index 06f92571eba4..b751cad545da 100644
--- a/sound/soc/codecs/tlv320aic3x.c
+++ b/sound/soc/codecs/tlv320aic3x.c
@@ -1804,11 +1804,18 @@ static int aic3x_i2c_probe(struct i2c_client *i2c,
if (!ai3x_setup)
return -ENOMEM;
 
-   ret = of_get_named_gpio(np, "gpio-reset", 0);
-   if (ret >= 0)
+   ret = of_get_named_gpio(np, "reset-gpios", 0);
+   if (ret >= 0) {
aic3x->gpio_reset = ret;
-   else
-   aic3x->gpio_reset = -1;
+   } else {
+   ret = of_get_named_gpio(np, "gpio-reset", 0);
+   if (ret > 0) {
+   dev_warn(&i2c->dev, "Using deprecated property 
\"gpio-reset\", please update your DT");
+   aic3x->gpio_reset = ret;
+   } else {
+   aic3x->gpio_reset = -1;
+   }
+   }
 
if (of_property_read_u32_array(np, "ai3x-gpio-func",
ai3x_setup->gpio_func, 2) >= 0) {
-- 
2.15.0