Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1489470 > unrolled thread

[PATCH 4.4 000/118] 4.4.22-stable review

Back to article view | Back to linux.kernel

Contents

  [PATCH 4.4 000/118] 4.4.22-stable review Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2016-09-22 21:30 +0200
    [PATCH 4.4 055/118] ARM: dts: overo: fix gpmc nand cs0 range Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2016-09-22 21:30 +0200
    [PATCH 4.4 025/118] x86/AMD: Apply erratum 665 on machines without a BIOS fix Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2016-09-22 21:30 +0200
    [PATCH 4.4 060/118] bus: arm-ccn: Fix XP watchpoint settings bitmask Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2016-09-22 21:30 +0200
    [PATCH 4.4 029/118] iio: adc: rockchip_saradc: reset saradc controller before programming it Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2016-09-22 21:30 +0200
    [PATCH 4.4 034/118] iio: accel: bmc150: reset chip at init time Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2016-09-22 21:30 +0200
    [PATCH 4.4 062/118] dm log writes: move IO accounting earlier to fix error path Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2016-09-22 21:30 +0200
    [PATCH 4.4 022/118] IB/uverbs: Fix race between uverbs_close and remove_one Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2016-09-22 21:30 +0200
      Re: [PATCH 4.4 022/118] IB/uverbs: Fix race between uverbs_close and remove_one Vegard Nossum <vegard.nossum@gmail.com> - 2016-10-03 14:30 +0200
        Re: [PATCH 4.4 022/118] IB/uverbs: Fix race between uverbs_close and  remove_one Jason Gunthorpe <jgunthorpe@obsidianresearch.com> - 2016-10-03 19:10 +0200
    [PATCH 4.4 048/118] cpuset: make sure new tasks conform to the current config of the cpuset Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2016-09-22 21:30 +0200
      Re: [PATCH 4.4 048/118] cpuset: make sure new tasks conform to the current config of the cpuset Takashi Iwai <tiwai@suse.de> - 2016-09-26 14:40 +0200
        Re: [PATCH 4.4 048/118] cpuset: make sure new tasks conform to the  current config of the cpuset Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2016-09-26 17:40 +0200
          Re: [PATCH 4.4 048/118] cpuset: make sure new tasks conform to the current config of the cpuset Takashi Iwai <tiwai@suse.de> - 2016-09-26 17:50 +0200
    [PATCH 4.4 021/118] dm flakey: fix reads to be issued if drop_writes configured Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2016-09-22 21:30 +0200
    [PATCH 4.4 027/118] iio: accel: kxsd9: Fix raw read return Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2016-09-22 21:30 +0200
    [PATCH 4.4 037/118] iio:core: fix IIO_VAL_FRACTIONAL sign handling Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2016-09-22 21:30 +0200
    [PATCH 4.4 003/118] clocksource/drivers/sun4i: Clear interrupts after stopping timer in probe function Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2016-09-22 21:30 +0200
    [PATCH 4.4 056/118] ARM: dts: overo: fix gpmc nand on boards with ethernet Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2016-09-22 21:30 +0200
    [PATCH 4.4 066/118] arm64: spinlocks: implement smp_mb__before_spinlock() as smp_mb() Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2016-09-22 21:30 +0200
    [PATCH 4.4 059/118] bus: arm-ccn: Do not attempt to configure XPs for cycle counter Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2016-09-22 21:30 +0200
    [PATCH 4.4 030/118] iio: adc: ti_am335x_adc: Protect FIFO1 from concurrent access Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2016-09-22 21:30 +0200
    [PATCH 4.4 026/118] kvm-arm: Unmap shadow pagetables properly Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2016-09-22 21:30 +0200
    [PATCH 4.4 053/118] ARM: OMAP3: hwmod data: Add sysc information for DSI Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2016-09-22 21:30 +0200
    [PATCH 4.4 008/118] tipc: move linearization of buffers to generic code Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2016-09-22 21:30 +0200
    [PATCH 4.4 031/118] iio: adc: ti_am335x_adc: Increase timeout value waiting for ADC sample Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2016-09-22 21:30 +0200
    [PATCH 4.4 028/118] iio: proximity: as3935: set up buffer timestamps for non-zero values Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2016-09-22 21:40 +0200
    [PATCH 4.4 012/118] kernfs: dont depend on d_find_any_alias() when generating notifications Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2016-09-22 21:40 +0200
    [PATCH 4.4 015/118] nfsd: Close race between nfsd4_release_lockowner and nfsd4_lock Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2016-09-22 21:40 +0200
    Re: [PATCH 4.4 000/118] 4.4.22-stable review Holger Hoffstätte <holger@applied-asynchrony.com> - 2016-09-22 22:00 +0200
      Re: [PATCH 4.4 000/118] 4.4.22-stable review Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2016-09-23 10:20 +0200
        Re: [PATCH 4.4 000/118] 4.4.22-stable review Holger Hoffstätte <holger@applied-asynchrony.com> - 2016-09-23 10:50 +0200
          Re: [PATCH 4.4 000/118] 4.4.22-stable review Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2016-09-23 11:30 +0200
    Re: [PATCH 4.4 000/118] 4.4.22-stable review Guenter Roeck <linux@roeck-us.net> - 2016-09-23 01:50 +0200
    Re: [PATCH 4.4 000/118] 4.4.22-stable review Guenter Roeck <linux@roeck-us.net> - 2016-09-23 05:10 +0200
      Re: [PATCH 4.4 000/118] 4.4.22-stable review Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2016-09-23 10:10 +0200
      Re: [PATCH 4.4 000/118] 4.4.22-stable review Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2016-09-23 10:10 +0200
        Re: [PATCH 4.4 000/118] 4.4.22-stable review Guenter Roeck <linux@roeck-us.net> - 2016-09-23 15:30 +0200
          Re: [PATCH 4.4 000/118] 4.4.22-stable review Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2016-09-23 17:20 +0200
            Re: [PATCH 4.4 000/118] 4.4.22-stable review Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2016-09-23 17:40 +0200
              Re: [PATCH 4.4 000/118] 4.4.22-stable review Andrew Donnellan <andrew.donnellan@au1.ibm.com> - 2016-09-28 10:50 +0200
                Re: [PATCH 4.4 000/118] 4.4.22-stable review Mauricio Faria de Oliveira <mauricfo@linux.vnet.ibm.com> - 2016-09-28 15:30 +0200
                  Re: [PATCH 4.4 000/118] 4.4.22-stable review Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2016-10-10 10:50 +0200
      Re: [PATCH 4.4 000/118] 4.4.22-stable review Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2016-09-23 10:20 +0200
      Re: [PATCH 4.4 000/118] 4.4.22-stable review Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2016-09-23 10:20 +0200
    Re: [PATCH 4.4 000/118] 4.4.22-stable review Shuah Khan <shuah.kh@samsung.com> - 2016-09-23 18:10 +0200

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#1489489 — [PATCH 4.4 059/118] bus: arm-ccn: Do not attempt to configure XPs for cycle counter

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

------------------

From: Pawel Moll <pawel.moll@arm.com>

commit b7c1beb278e8e3dc664ed3df3fc786db126120a9 upstream.

Fuzzing the CCN perf driver revealed a small but definitely dangerous
mistake in the event setup code. When a cycle counter is requested, the
driver should not reconfigure the events bus at all, otherwise it will
corrupt (in most but the simplest cases) its configuration and may end
up accessing XP array out of its bounds and corrupting control
registers.

Reported-by: Mark Rutland <mark.rutland@arm.com>
Reviewed-by: Mark Rutland <mark.rutland@arm.com>
Tested-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Pawel Moll <pawel.moll@arm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/bus/arm-ccn.c |    4 ++++
 1 file changed, 4 insertions(+)

--- a/drivers/bus/arm-ccn.c
+++ b/drivers/bus/arm-ccn.c
@@ -895,6 +895,10 @@ static void arm_ccn_pmu_xp_dt_config(str
 	struct arm_ccn_component *xp;
 	u32 val, dt_cfg;
 
+	/* Nothing to do for cycle counter */
+	if (hw->idx == CCN_IDX_PMU_CYCLE_COUNTER)
+		return;
+
 	if (CCN_CONFIG_TYPE(event->attr.config) == CCN_TYPE_XP)
 		xp = &ccn->xp[CCN_CONFIG_XP(event->attr.config)];
 	else

[toc] | [prev] | [next] | [standalone]

#1489490 — [PATCH 4.4 030/118] iio: adc: ti_am335x_adc: Protect FIFO1 from concurrent access

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

------------------

From: Vignesh R <vigneshr@ti.com>

commit 90c43ec6997a892448f1f86180a515f59cafd8a3 upstream.

It is possible that two or more ADC channels can be simultaneously
requested for raw samples, in which case there can be race in access to
FIFO data resulting in loss of samples.
If am335x_tsc_se_set_once() is called again from tiadc_read_raw(), when
ADC is still acquired to sample one of the channels, the second process
might be put into uninterruptible sleep state. Fix these issues, by
protecting FIFO access and channel configurations with a mutex. Since
tiadc_read_raw() might take anywhere between few microseconds to few
milliseconds to finish execution (depending on averaging and delay
values supplied via DT), its better to use mutex instead of spinlock.

Fixes: 7ca6740cd1cd4 ("mfd: input: iio: ti_amm335x: Rework TSC/ADC synchronization")
Signed-off-by: Vignesh R <vigneshr@ti.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/iio/adc/ti_am335x_adc.c |   14 +++++++++++---
 1 file changed, 11 insertions(+), 3 deletions(-)

--- a/drivers/iio/adc/ti_am335x_adc.c
+++ b/drivers/iio/adc/ti_am335x_adc.c
@@ -32,6 +32,7 @@
 
 struct tiadc_device {
 	struct ti_tscadc_dev *mfd_tscadc;
+	struct mutex fifo1_lock; /* to protect fifo access */
 	int channels;
 	u8 channel_line[8];
 	u8 channel_step[8];
@@ -360,6 +361,7 @@ static int tiadc_read_raw(struct iio_dev
 		int *val, int *val2, long mask)
 {
 	struct tiadc_device *adc_dev = iio_priv(indio_dev);
+	int ret = IIO_VAL_INT;
 	int i, map_val;
 	unsigned int fifo1count, read, stepid;
 	bool found = false;
@@ -373,6 +375,7 @@ static int tiadc_read_raw(struct iio_dev
 	if (!step_en)
 		return -EINVAL;
 
+	mutex_lock(&adc_dev->fifo1_lock);
 	fifo1count = tiadc_readl(adc_dev, REG_FIFO1CNT);
 	while (fifo1count--)
 		tiadc_readl(adc_dev, REG_FIFO1);
@@ -389,7 +392,8 @@ static int tiadc_read_raw(struct iio_dev
 
 		if (time_after(jiffies, timeout)) {
 			am335x_tsc_se_adc_done(adc_dev->mfd_tscadc);
-			return -EAGAIN;
+			ret = -EAGAIN;
+			goto err_unlock;
 		}
 	}
 	map_val = adc_dev->channel_step[chan->scan_index];
@@ -415,8 +419,11 @@ static int tiadc_read_raw(struct iio_dev
 	am335x_tsc_se_adc_done(adc_dev->mfd_tscadc);
 
 	if (found == false)
-		return -EBUSY;
-	return IIO_VAL_INT;
+		ret =  -EBUSY;
+
+err_unlock:
+	mutex_unlock(&adc_dev->fifo1_lock);
+	return ret;
 }
 
 static const struct iio_info tiadc_info = {
@@ -485,6 +492,7 @@ static int tiadc_probe(struct platform_d
 
 	tiadc_step_config(indio_dev);
 	tiadc_writel(adc_dev, REG_FIFO1THR, FIFO1_THRESHOLD);
+	mutex_init(&adc_dev->fifo1_lock);
 
 	err = tiadc_channel_init(indio_dev, adc_dev->channels);
 	if (err < 0)

[toc] | [prev] | [next] | [standalone]

#1489492 — [PATCH 4.4 026/118] kvm-arm: Unmap shadow pagetables properly

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

------------------

From: Suzuki K Poulose <suzuki.poulose@arm.com>

commit 293f293637b55db4f9f522a5a72514e98a541076 upstream.

On arm/arm64, we depend on the kvm_unmap_hva* callbacks (via
mmu_notifiers::invalidate_*) to unmap the stage2 pagetables when
the userspace buffer gets unmapped. However, when the Hypervisor
process exits without explicit unmap of the guest buffers, the only
notifier we get is kvm_arch_flush_shadow_all() (via mmu_notifier::release
) which does nothing on arm. Later this causes us to access pages that
were already released [via exit_mmap() -> unmap_vmas()] when we actually
get to unmap the stage2 pagetable [via kvm_arch_destroy_vm() ->
kvm_free_stage2_pgd()]. This triggers crashes with CONFIG_DEBUG_PAGEALLOC,
which unmaps any free'd pages from the linear map.

 [  757.644120] Unable to handle kernel paging request at virtual address
  ffff800661e00000
 [  757.652046] pgd = ffff20000b1a2000
 [  757.655471] [ffff800661e00000] *pgd=00000047fffe3003, *pud=00000047fcd8c003,
  *pmd=00000047fcc7c003, *pte=00e8004661e00712
 [  757.666492] Internal error: Oops: 96000147 [#3] PREEMPT SMP
 [  757.672041] Modules linked in:
 [  757.675100] CPU: 7 PID: 3630 Comm: qemu-system-aar Tainted: G      D
 4.8.0-rc1 #3
 [  757.683240] Hardware name: AppliedMicro X-Gene Mustang Board/X-Gene Mustang Board,
  BIOS 3.06.15 Aug 19 2016
 [  757.692938] task: ffff80069cdd3580 task.stack: ffff8006adb7c000
 [  757.698840] PC is at __flush_dcache_area+0x1c/0x40
 [  757.703613] LR is at kvm_flush_dcache_pmd+0x60/0x70
 [  757.708469] pc : [<ffff20000809dbdc>] lr : [<ffff2000080b4a70>] pstate: 20000145
 ...
 [  758.357249] [<ffff20000809dbdc>] __flush_dcache_area+0x1c/0x40
 [  758.363059] [<ffff2000080b6748>] unmap_stage2_range+0x458/0x5f0
 [  758.368954] [<ffff2000080b708c>] kvm_free_stage2_pgd+0x34/0x60
 [  758.374761] [<ffff2000080b2280>] kvm_arch_destroy_vm+0x20/0x68
 [  758.380570] [<ffff2000080aa330>] kvm_put_kvm+0x210/0x358
 [  758.385860] [<ffff2000080aa524>] kvm_vm_release+0x2c/0x40
 [  758.391239] [<ffff2000082ad234>] __fput+0x114/0x2e8
 [  758.396096] [<ffff2000082ad46c>] ____fput+0xc/0x18
 [  758.400869] [<ffff200008104658>] task_work_run+0x108/0x138
 [  758.406332] [<ffff2000080dc8ec>] do_exit+0x48c/0x10e8
 [  758.411363] [<ffff2000080dd5fc>] do_group_exit+0x6c/0x130
 [  758.416739] [<ffff2000080ed924>] get_signal+0x284/0xa18
 [  758.421943] [<ffff20000808a098>] do_signal+0x158/0x860
 [  758.427060] [<ffff20000808aad4>] do_notify_resume+0x6c/0x88
 [  758.432608] [<ffff200008083624>] work_pending+0x10/0x14
 [  758.437812] Code: 9ac32042 8b010001 d1000443 8a230000 (d50b7e20)

This patch fixes the issue by moving the kvm_free_stage2_pgd() to
kvm_arch_flush_shadow_all().

Tested-by: Itaru Kitayama <itaru.kitayama@riken.jp>
Reported-by: Itaru Kitayama <itaru.kitayama@riken.jp>
Reported-by: James Morse <james.morse@arm.com>
Cc: Marc Zyngier <marc.zyngier@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Christoffer Dall <christoffer.dall@linaro.org>
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 arch/arm/kvm/arm.c |    2 --
 arch/arm/kvm/mmu.c |    1 +
 2 files changed, 1 insertion(+), 2 deletions(-)

--- a/arch/arm/kvm/arm.c
+++ b/arch/arm/kvm/arm.c
@@ -155,8 +155,6 @@ void kvm_arch_destroy_vm(struct kvm *kvm
 {
 	int i;
 
-	kvm_free_stage2_pgd(kvm);
-
 	for (i = 0; i < KVM_MAX_VCPUS; ++i) {
 		if (kvm->vcpus[i]) {
 			kvm_arch_vcpu_free(kvm->vcpus[i]);
--- a/arch/arm/kvm/mmu.c
+++ b/arch/arm/kvm/mmu.c
@@ -1852,6 +1852,7 @@ void kvm_arch_memslots_updated(struct kv
 
 void kvm_arch_flush_shadow_all(struct kvm *kvm)
 {
+	kvm_free_stage2_pgd(kvm);
 }
 
 void kvm_arch_flush_shadow_memslot(struct kvm *kvm,

[toc] | [prev] | [next] | [standalone]

#1489493 — [PATCH 4.4 053/118] ARM: OMAP3: hwmod data: Add sysc information for DSI

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

------------------

From: Sebastian Reichel <sre@kernel.org>

commit b46211d6dcfb81a8af66b8684a42d629183670d4 upstream.

Add missing sysconfig/sysstatus information
to OMAP3 hwmod. The information has been
checked against OMAP34xx and OMAP36xx TRM.

Without this change DSI block is not reset
during boot, which is required for working
Nokia N950 display.

Signed-off-by: Sebastian Reichel <sre@kernel.org>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |   12 ++++++++++++
 1 file changed, 12 insertions(+)

--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -723,8 +723,20 @@ static struct omap_hwmod omap3xxx_dss_di
  * display serial interface controller
  */
 
+static struct omap_hwmod_class_sysconfig omap3xxx_dsi_sysc = {
+	.rev_offs	= 0x0000,
+	.sysc_offs	= 0x0010,
+	.syss_offs	= 0x0014,
+	.sysc_flags	= (SYSC_HAS_AUTOIDLE | SYSC_HAS_CLOCKACTIVITY |
+			   SYSC_HAS_ENAWAKEUP | SYSC_HAS_SIDLEMODE |
+			   SYSC_HAS_SOFTRESET | SYSS_HAS_RESET_STATUS),
+	.idlemodes	= (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
+	.sysc_fields	= &omap_hwmod_sysc_type1,
+};
+
 static struct omap_hwmod_class omap3xxx_dsi_hwmod_class = {
 	.name = "dsi",
+	.sysc	= &omap3xxx_dsi_sysc,
 };
 
 static struct omap_hwmod_irq_info omap3xxx_dsi1_irqs[] = {

[toc] | [prev] | [next] | [standalone]

#1489494 — [PATCH 4.4 008/118] tipc: move linearization of buffers to generic code

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

------------------

From: Jon Paul Maloy <jon.maloy@ericsson.com>

commit c7cad0d6f70cd4ce8644ffe528a4df1cdc2e77f5 upstream.

In commit 5cbb28a4bf65c7e4 ("tipc: linearize arriving NAME_DISTR
and LINK_PROTO buffers") we added linearization of NAME_DISTRIBUTOR,
LINK_PROTOCOL/RESET and LINK_PROTOCOL/ACTIVATE to the function
tipc_udp_recv(). The location of the change was selected in order
to make the commit easily appliable to 'net' and 'stable'.

We now move this linearization to where it should be done, in the
functions tipc_named_rcv() and tipc_link_proto_rcv() respectively.

Reviewed-by: Ying Xue <ying.xue@windriver.com>
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Juerg Haefliger <juerg.haefliger@hpe.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 net/tipc/link.c       |    2 ++
 net/tipc/name_distr.c |    1 +
 net/tipc/udp_media.c  |    5 -----
 3 files changed, 3 insertions(+), 5 deletions(-)

--- a/net/tipc/link.c
+++ b/net/tipc/link.c
@@ -1262,6 +1262,8 @@ static int tipc_link_proto_rcv(struct ti
 		/* fall thru' */
 
 	case ACTIVATE_MSG:
+		skb_linearize(skb);
+		hdr = buf_msg(skb);
 
 		/* Complete own link name with peer's interface name */
 		if_name =  strrchr(l->name, ':') + 1;
--- a/net/tipc/name_distr.c
+++ b/net/tipc/name_distr.c
@@ -397,6 +397,7 @@ void tipc_named_rcv(struct net *net, str
 
 	spin_lock_bh(&tn->nametbl_lock);
 	for (skb = skb_dequeue(inputq); skb; skb = skb_dequeue(inputq)) {
+		skb_linearize(skb);
 		msg = buf_msg(skb);
 		mtype = msg_type(msg);
 		item = (struct distr_item *)msg_data(msg);
--- a/net/tipc/udp_media.c
+++ b/net/tipc/udp_media.c
@@ -48,7 +48,6 @@
 #include <linux/tipc_netlink.h>
 #include "core.h"
 #include "bearer.h"
-#include "msg.h"
 
 /* IANA assigned UDP port */
 #define UDP_PORT_DEFAULT	6118
@@ -224,10 +223,6 @@ static int tipc_udp_recv(struct sock *sk
 {
 	struct udp_bearer *ub;
 	struct tipc_bearer *b;
-	int usr = msg_user(buf_msg(skb));
-
-	if ((usr == LINK_PROTOCOL) || (usr == NAME_DISTRIBUTOR))
-		skb_linearize(skb);
 
 	ub = rcu_dereference_sk_user_data(sk);
 	if (!ub) {

[toc] | [prev] | [next] | [standalone]

#1489496 — [PATCH 4.4 031/118] iio: adc: ti_am335x_adc: Increase timeout value waiting for ADC sample

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

------------------

From: Vignesh R <vigneshr@ti.com>

commit 7175cce1c3f1d8c8840d2004f78f96a3904249b5 upstream.

Now that open delay and sample delay for each channel is configurable
via DT, the default IDLE_TIMEOUT value is not enough as this is
calculated based on hardcoded macros. This results in driver returning
EBUSY sometimes. Fix this by increasing the timeout
value based on maximum value possible to open delay and sample delays
for each channel.

Fixes: 5dc11e810676e ("iio: adc: ti_am335x_adc: make sample delay, open delay, averaging DT parameters")
Signed-off-by: Vignesh R <vigneshr@ti.com>
Acked-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/iio/adc/ti_am335x_adc.c      |    2 +-
 include/linux/mfd/ti_am335x_tscadc.h |    8 ++++----
 2 files changed, 5 insertions(+), 5 deletions(-)

--- a/drivers/iio/adc/ti_am335x_adc.c
+++ b/drivers/iio/adc/ti_am335x_adc.c
@@ -382,7 +382,7 @@ static int tiadc_read_raw(struct iio_dev
 
 	am335x_tsc_se_set_once(adc_dev->mfd_tscadc, step_en);
 
-	timeout = jiffies + usecs_to_jiffies
+	timeout = jiffies + msecs_to_jiffies
 				(IDLE_TIMEOUT * adc_dev->channels);
 	/* Wait for Fifo threshold interrupt */
 	while (1) {
--- a/include/linux/mfd/ti_am335x_tscadc.h
+++ b/include/linux/mfd/ti_am335x_tscadc.h
@@ -138,16 +138,16 @@
 /*
  * time in us for processing a single channel, calculated as follows:
  *
- * num cycles = open delay + (sample delay + conv time) * averaging
+ * max num cycles = open delay + (sample delay + conv time) * averaging
  *
- * num cycles: 152 + (1 + 13) * 16 = 376
+ * max num cycles: 262143 + (255 + 13) * 16 = 266431
  *
  * clock frequency: 26MHz / 8 = 3.25MHz
  * clock period: 1 / 3.25MHz = 308ns
  *
- * processing time: 376 * 308ns = 116us
+ * max processing time: 266431 * 308ns = 83ms(approx)
  */
-#define IDLE_TIMEOUT 116 /* microsec */
+#define IDLE_TIMEOUT 83 /* milliseconds */
 
 #define TSCADC_CELLS		2
 

[toc] | [prev] | [next] | [standalone]

#1489498 — [PATCH 4.4 028/118] iio: proximity: as3935: set up buffer timestamps for non-zero values

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

------------------

From: Alison Schofield <amsfield22@gmail.com>

commit f8adf645db03345af2d9a8b6095b02327ea50885 upstream.

Use the iio_pollfunc_store_time parameter during triggered buffer
set-up to get valid timestamps.

Signed-off-by: Alison Schofield <amsfield22@gmail.com>
Cc: Daniel Baluta <daniel.baluta@gmail.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/iio/proximity/as3935.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/iio/proximity/as3935.c
+++ b/drivers/iio/proximity/as3935.c
@@ -392,7 +392,7 @@ static int as3935_probe(struct spi_devic
 		return ret;
 	}
 
-	ret = iio_triggered_buffer_setup(indio_dev, NULL,
+	ret = iio_triggered_buffer_setup(indio_dev, iio_pollfunc_store_time,
 		&as3935_trigger_handler, NULL);
 
 	if (ret) {

[toc] | [prev] | [next] | [standalone]

#1489499 — [PATCH 4.4 012/118] kernfs: dont depend on d_find_any_alias() when generating notifications

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

------------------

From: Tejun Heo <tj@kernel.org>

commit df6a58c5c5aa8ecb1e088ecead3fa33ae70181f1 upstream.

kernfs_notify_workfn() sends out file modified events for the
scheduled kernfs_nodes.  Because the modifications aren't from
userland, it doesn't have the matching file struct at hand and can't
use fsnotify_modify().  Instead, it looked up the inode and then used
d_find_any_alias() to find the dentry and used fsnotify_parent() and
fsnotify() directly to generate notifications.

The assumption was that the relevant dentries would have been pinned
if there are listeners, which isn't true as inotify doesn't pin
dentries at all and watching the parent doesn't pin the child dentries
even for dnotify.  This led to, for example, inotify watchers not
getting notifications if the system is under memory pressure and the
matching dentries got reclaimed.  It can also be triggered through
/proc/sys/vm/drop_caches or a remount attempt which involves shrinking
dcache.

fsnotify_parent() only uses the dentry to access the parent inode,
which kernfs can do easily.  Update kernfs_notify_workfn() so that it
uses fsnotify() directly for both the parent and target inodes without
going through d_find_any_alias().  While at it, supply the target file
name to fsnotify() from kernfs_node->name.

Signed-off-by: Tejun Heo <tj@kernel.org>
Reported-by: Evgeny Vereshchagin <evvers@ya.ru>
Fixes: d911d9874801 ("kernfs: make kernfs_notify() trigger inotify events too")
Cc: John McCutchan <john@johnmccutchan.com>
Cc: Robert Love <rlove@rlove.org>
Cc: Eric Paris <eparis@parisplace.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 fs/kernfs/file.c |   28 +++++++++++++++++++++-------
 1 file changed, 21 insertions(+), 7 deletions(-)

--- a/fs/kernfs/file.c
+++ b/fs/kernfs/file.c
@@ -833,21 +833,35 @@ repeat:
 	mutex_lock(&kernfs_mutex);
 
 	list_for_each_entry(info, &kernfs_root(kn)->supers, node) {
+		struct kernfs_node *parent;
 		struct inode *inode;
-		struct dentry *dentry;
 
+		/*
+		 * We want fsnotify_modify() on @kn but as the
+		 * modifications aren't originating from userland don't
+		 * have the matching @file available.  Look up the inodes
+		 * and generate the events manually.
+		 */
 		inode = ilookup(info->sb, kn->ino);
 		if (!inode)
 			continue;
 
-		dentry = d_find_any_alias(inode);
-		if (dentry) {
-			fsnotify_parent(NULL, dentry, FS_MODIFY);
-			fsnotify(inode, FS_MODIFY, inode, FSNOTIFY_EVENT_INODE,
-				 NULL, 0);
-			dput(dentry);
+		parent = kernfs_get_parent(kn);
+		if (parent) {
+			struct inode *p_inode;
+
+			p_inode = ilookup(info->sb, parent->ino);
+			if (p_inode) {
+				fsnotify(p_inode, FS_MODIFY | FS_EVENT_ON_CHILD,
+					 inode, FSNOTIFY_EVENT_INODE, kn->name, 0);
+				iput(p_inode);
+			}
+
+			kernfs_put(parent);
 		}
 
+		fsnotify(inode, FS_MODIFY, inode, FSNOTIFY_EVENT_INODE,
+			 kn->name, 0);
 		iput(inode);
 	}
 

[toc] | [prev] | [next] | [standalone]

#1489500 — [PATCH 4.4 015/118] nfsd: Close race between nfsd4_release_lockowner and nfsd4_lock

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

------------------

From: Chuck Lever <chuck.lever@oracle.com>

commit 885848186fbc2d1d8fb6d2fdc2156638ae289a46 upstream.

nfsd4_release_lockowner finds a lock owner that has no lock state,
and drops cl_lock. Then release_lockowner picks up cl_lock and
unhashes the lock owner.

During the window where cl_lock is dropped, I don't see anything
preventing a concurrent nfsd4_lock from finding that same lock owner
and adding lock state to it.

Move release_lockowner() into nfsd4_release_lockowner and hang onto
the cl_lock until after the lock owner's state cannot be found
again.

Found by inspection, we don't currently have a reproducer.

Fixes: 2c41beb0e5cf ("nfsd: reduce cl_lock thrashing in ... ")
Reviewed-by: Jeff Layton <jlayton@redhat.com>
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Signed-off-by: J. Bruce Fields <bfields@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 fs/nfsd/nfs4state.c |   40 +++++++++++++++++-----------------------
 1 file changed, 17 insertions(+), 23 deletions(-)

--- a/fs/nfsd/nfs4state.c
+++ b/fs/nfsd/nfs4state.c
@@ -1200,27 +1200,6 @@ free_ol_stateid_reaplist(struct list_hea
 	}
 }
 
-static void release_lockowner(struct nfs4_lockowner *lo)
-{
-	struct nfs4_client *clp = lo->lo_owner.so_client;
-	struct nfs4_ol_stateid *stp;
-	struct list_head reaplist;
-
-	INIT_LIST_HEAD(&reaplist);
-
-	spin_lock(&clp->cl_lock);
-	unhash_lockowner_locked(lo);
-	while (!list_empty(&lo->lo_owner.so_stateids)) {
-		stp = list_first_entry(&lo->lo_owner.so_stateids,
-				struct nfs4_ol_stateid, st_perstateowner);
-		WARN_ON(!unhash_lock_stateid(stp));
-		put_ol_stateid_locked(stp, &reaplist);
-	}
-	spin_unlock(&clp->cl_lock);
-	free_ol_stateid_reaplist(&reaplist);
-	nfs4_put_stateowner(&lo->lo_owner);
-}
-
 static void release_open_stateid_locks(struct nfs4_ol_stateid *open_stp,
 				       struct list_head *reaplist)
 {
@@ -5952,6 +5931,7 @@ nfsd4_release_lockowner(struct svc_rqst
 	__be32 status;
 	struct nfsd_net *nn = net_generic(SVC_NET(rqstp), nfsd_net_id);
 	struct nfs4_client *clp;
+	LIST_HEAD (reaplist);
 
 	dprintk("nfsd4_release_lockowner clientid: (%08x/%08x):\n",
 		clid->cl_boot, clid->cl_id);
@@ -5982,9 +5962,23 @@ nfsd4_release_lockowner(struct svc_rqst
 		nfs4_get_stateowner(sop);
 		break;
 	}
+	if (!lo) {
+		spin_unlock(&clp->cl_lock);
+		return status;
+	}
+
+	unhash_lockowner_locked(lo);
+	while (!list_empty(&lo->lo_owner.so_stateids)) {
+		stp = list_first_entry(&lo->lo_owner.so_stateids,
+				       struct nfs4_ol_stateid,
+				       st_perstateowner);
+		WARN_ON(!unhash_lock_stateid(stp));
+		put_ol_stateid_locked(stp, &reaplist);
+	}
 	spin_unlock(&clp->cl_lock);
-	if (lo)
-		release_lockowner(lo);
+	free_ol_stateid_reaplist(&reaplist);
+	nfs4_put_stateowner(&lo->lo_owner);
+
 	return status;
 }
 

[toc] | [prev] | [next] | [standalone]

#1489513

On 09/22/16 19:28, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.4.22 release.
> There are 118 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.

Greg,

did you forget to add the -net patches in stable-queue.git/tree/net-4.4
or are they on hold for some reason? I think they were supposed to go
into .22.

Holger

[toc] | [prev] | [next] | [standalone]

#1489830

On Thu, Sep 22, 2016 at 09:56:28PM +0200, Holger Hoffstätte wrote:
> On 09/22/16 19:28, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.4.22 release.
> > There are 118 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.
> 
> Greg,
> 
> did you forget to add the -net patches in stable-queue.git/tree/net-4.4
> or are they on hold for some reason? I think they were supposed to go
> into .22.

Really?  I just put them there as I was pondering applying them, waiting
for the network maintainer to send me some more patches, or not.  They
aren't all correct, and are missing some patches, I just haven't gotten
the chance to do the work yet.

Why do you think they should go into this release?

thanks,

greg k-h

[toc] | [prev] | [next] | [standalone]

#1489853

On 09/23/16 10:14, Greg Kroah-Hartman wrote:
> On Thu, Sep 22, 2016 at 09:56:28PM +0200, Holger Hoffstätte wrote:
>> did you forget to add the -net patches in stable-queue.git/tree/net-4.4
>> or are they on hold for some reason? I think they were supposed to go
>> into .22.
> 
> Really?  I just put them there as I was pondering applying them, waiting
> for the network maintainer to send me some more patches, or not.  They

Ahh..alright then.

> Why do you think they should go into this release?

Never mind - they are not really urgent. I just had most of them merged
locally already and was just wondering.

thanks.

Holger

[toc] | [prev] | [next] | [standalone]

#1489887

On Fri, Sep 23, 2016 at 10:43:27AM +0200, Holger Hoffstätte wrote:
> On 09/23/16 10:14, Greg Kroah-Hartman wrote:
> > On Thu, Sep 22, 2016 at 09:56:28PM +0200, Holger Hoffstätte wrote:
> >> did you forget to add the -net patches in stable-queue.git/tree/net-4.4
> >> or are they on hold for some reason? I think they were supposed to go
> >> into .22.
> > 
> > Really?  I just put them there as I was pondering applying them, waiting
> > for the network maintainer to send me some more patches, or not.  They
> 
> Ahh..alright then.
> 
> > Why do you think they should go into this release?
> 
> Never mind - they are not really urgent. I just had most of them merged
> locally already and was just wondering.

If you have them merged, and tested, mind sending them to me with your
tested-by mark on them?  That way I know they work and can focus on the
ones that will require backporting effort.

thanks,

greg k-h

[toc] | [prev] | [next] | [standalone]

#1489659

On Thu, Sep 22, 2016 at 07:28:20PM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.4.22 release.
> There are 118 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
> 
> Responses should be made by Sat Sep 24 17:29:17 UTC 2016.
> Anything received after that time might be too late.
> 
Build results:
	total: 149 pass: 136 fail: 13
Failed builds:
	avr32:defconfig
	avr32:allnoconfig
	avr32:merisc_defconfig
	avr32:atngw100mkii_evklcd101_defconfig
	powerpc:defconfig
	powerpc:allmodconfig
	powerpc:allnoconfig
	powerpc:ppc6xx_defconfig
	powerpc:mpc83xx_defconfig
	powerpc:tqm8xx_defconfig
	powerpc:85xx/sbc8548_defconfig
	powerpc:83xx/mpc834x_mds_defconfig
	powerpc:86xx/sbc8641d_defconfig

Qemu test results:
	total: 101 pass: 90 fail: 11
Failed tests:
	openrisc:or1ksim_defconfig
	powerpc:mac99:nosmp:ppc_book3s_defconfig
	powerpc:g3beige:nosmp:ppc_book3s_defconfig
	powerpc:mac99:smp:ppc_book3s_defconfig
	powerpc:virtex-ml507:44x/virtex5_defconfig
	powerpc:mpc8548cds:85xx/mpc85xx_cds_defconfig
	powerpc:mpc8548cds:smpdev:85xx/mpc85xx_cds_defconfig
	powerpc:bamboo:44x/bamboo_defconfig
	powerpc:mac99:ppc64_book3s_defconfig:nosmp
	powerpc:mac99:ppc64_book3s_defconfig:smp4
	powerpc:pseries:pseries_defconfig

Build errors:

avr32:

arch/avr32/kernel/built-in.o: In function `arch_ptrace':
(.text+0x810): undefined reference to `___copy_from_user'
arch/avr32/kernel/built-in.o:(___ksymtab+___copy_from_user+0x0): undefined
reference to `___copy_from_user'
kernel/built-in.o: In function `devm_request_resource':
(.text+0x52c8): undefined reference to `___copy_from_user'
kernel/built-in.o: In function `proc_do_large_bitmap':
(.text+0x588c): undefined reference to `___copy_from_user'
kernel/built-in.o: In function `proc_dostring':
(.text+0x5b20): undefined reference to `___copy_from_user'
kernel/built-in.o:sysctl.c:(.text+0x6088): more undefined references to
`___copy_from_user' follow

Hmm .. I've seen that before. Looks like a missing commit from upstream.
I'll check later tonight.

---

powerpc:

drivers/misc/cxl/vphb.c:263:9: error: 'pcibios_free_controller_deferred'
undeclared

arch/powerpc/include/asm/uaccess.h: In function 'copy_from_user':
arch/powerpc/include/asm/uaccess.h:328:1: error: wrong type argument to unary plus
 + memset(to, 0, n);

I'll have to look into those.

---

runtime:

qemu openrisc crashes with a NULL pointer dereference. There is no backtrace;
I'll have to bisect.

qemu ppc all fail to build with "drivers/misc/cxl/vphb.c:263:9: error:
'pcibios_free_controller_deferred' undeclared".


Details are available at http://kerneltests.org/builders.

Guenter

[toc] | [prev] | [next] | [standalone]

#1489723

On 09/22/2016 10:28 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.4.22 release.
> There are 118 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Sat Sep 24 17:29:17 UTC 2016.
> Anything received after that time might be too late.
>

avr32:

upstream patch 65c0044ca8d7 ("avr32: fix 'undefined reference to `___copy_from_user'")
	is needed in both v4.4 and v4.7 to fix the build problem.

ppc:

5b675d932899 ("ppc32: fix copy_from_user()")
	is corrupt in both v4.4 and v4.7.

e5767a13d7cb ("cxl: use pcibios_free_controller_deferred() when removing vPHBs")
	does not apply to v4.4 nor to v4.7 (and isn't marked stable ???).

openrisc:

upstream patch 8e4b72054f55 ("openrisc: fix the fix of copy_from_user()")
	is needed in both v4.4 and v4.7 to fix the runtime problem.

Guenter

[toc] | [prev] | [next] | [standalone]

#1489825

On Thu, Sep 22, 2016 at 08:01:35PM -0700, Guenter Roeck wrote:
> ppc:
> 
> 5b675d932899 ("ppc32: fix copy_from_user()")
> 	is corrupt in both v4.4 and v4.7.

Ugh, my fault, now fixed up.

greg k-h

[toc] | [prev] | [next] | [standalone]

#1489828

On Thu, Sep 22, 2016 at 08:01:35PM -0700, Guenter Roeck wrote:
> e5767a13d7cb ("cxl: use pcibios_free_controller_deferred() when removing vPHBs")
> 	does not apply to v4.4 nor to v4.7 (and isn't marked stable ???).

I don't understand what you mean here.  It did apply, and it was marked
for stable inclusion.  It is commit
6f38a8b9a45833495dc878c335c5431cd98a16ed in Linus's tree.  Does it break
the build?

thanks,

greg k-h

[toc] | [prev] | [next] | [standalone]

#1490081

On 09/23/2016 01:08 AM, Greg Kroah-Hartman wrote:
> On Thu, Sep 22, 2016 at 08:01:35PM -0700, Guenter Roeck wrote:
>> e5767a13d7cb ("cxl: use pcibios_free_controller_deferred() when removing vPHBs")
>> 	does not apply to v4.4 nor to v4.7 (and isn't marked stable ???).
>
> I don't understand what you mean here.  It did apply, and it was marked
> for stable inclusion.  It is commit
> 6f38a8b9a45833495dc878c335c5431cd98a16ed in Linus's tree.  Does it break
> the build?
>

drivers/misc/cxl/vphb.c: In function 'cxl_pci_vphb_add':
drivers/misc/cxl/vphb.c:263:9: error: 'pcibios_free_controller_deferred' undeclared

Yes, it does break the build, by calling a function which does not exist in 4.4 or 4.7.

Sorry, the Cc: stable was dropped in the 4.4/4.7 versions, so I didn't see it.
I meant to say "it doesn't build".

You will either have to drop e5767a13d7cb. or you'll also need commit 2dd9c11b9d4
("powerpc/pseries: use pci_host_bridge.release_fn() to kfree(phb)") from upstream.
I didn't check though if that applies (or works) with the older kernels.

Guenter

[toc] | [prev] | [next] | [standalone]

#1490243

On Fri, Sep 23, 2016 at 06:25:33AM -0700, Guenter Roeck wrote:
> On 09/23/2016 01:08 AM, Greg Kroah-Hartman wrote:
> > On Thu, Sep 22, 2016 at 08:01:35PM -0700, Guenter Roeck wrote:
> > > e5767a13d7cb ("cxl: use pcibios_free_controller_deferred() when removing vPHBs")
> > > 	does not apply to v4.4 nor to v4.7 (and isn't marked stable ???).
> > 
> > I don't understand what you mean here.  It did apply, and it was marked
> > for stable inclusion.  It is commit
> > 6f38a8b9a45833495dc878c335c5431cd98a16ed in Linus's tree.  Does it break
> > the build?
> > 
> 
> drivers/misc/cxl/vphb.c: In function 'cxl_pci_vphb_add':
> drivers/misc/cxl/vphb.c:263:9: error: 'pcibios_free_controller_deferred' undeclared
> 
> Yes, it does break the build, by calling a function which does not exist in 4.4 or 4.7.
> 
> Sorry, the Cc: stable was dropped in the 4.4/4.7 versions, so I didn't see it.
> I meant to say "it doesn't build".
> 
> You will either have to drop e5767a13d7cb. or you'll also need commit 2dd9c11b9d4
> ("powerpc/pseries: use pci_host_bridge.release_fn() to kfree(phb)") from upstream.
> I didn't check though if that applies (or works) with the older kernels.

I'm going to drop it, thanks for pointing this out, I should have caught
it earlier too...

greg k-h

[toc] | [prev] | [next] | [standalone]

#1490272

On Fri, Sep 23, 2016 at 05:11:48PM +0200, Greg Kroah-Hartman wrote:
> On Fri, Sep 23, 2016 at 06:25:33AM -0700, Guenter Roeck wrote:
> > On 09/23/2016 01:08 AM, Greg Kroah-Hartman wrote:
> > > On Thu, Sep 22, 2016 at 08:01:35PM -0700, Guenter Roeck wrote:
> > > > e5767a13d7cb ("cxl: use pcibios_free_controller_deferred() when removing vPHBs")
> > > > 	does not apply to v4.4 nor to v4.7 (and isn't marked stable ???).
> > > 
> > > I don't understand what you mean here.  It did apply, and it was marked
> > > for stable inclusion.  It is commit
> > > 6f38a8b9a45833495dc878c335c5431cd98a16ed in Linus's tree.  Does it break
> > > the build?
> > > 
> > 
> > drivers/misc/cxl/vphb.c: In function 'cxl_pci_vphb_add':
> > drivers/misc/cxl/vphb.c:263:9: error: 'pcibios_free_controller_deferred' undeclared
> > 
> > Yes, it does break the build, by calling a function which does not exist in 4.4 or 4.7.
> > 
> > Sorry, the Cc: stable was dropped in the 4.4/4.7 versions, so I didn't see it.
> > I meant to say "it doesn't build".
> > 
> > You will either have to drop e5767a13d7cb. or you'll also need commit 2dd9c11b9d4
> > ("powerpc/pseries: use pci_host_bridge.release_fn() to kfree(phb)") from upstream.
> > I didn't check though if that applies (or works) with the older kernels.
> 
> I'm going to drop it, thanks for pointing this out, I should have caught
> it earlier too...

Should be removed, hopefully all will build properly...

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | linux.kernel

csiph-web