2014-12-14 20:50:00

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 3.10 00/24] 3.10.63-stable review

This is the start of the stable review cycle for the 3.10.63 release.
There are 24 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 Tue Dec 16 20:17:48 UTC 2014.
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/v3.0/stable-review/patch-3.10.63-rc1.gz
and the diffstat can be found below.

thanks,

greg k-h

-------------
Pseudo-Shortlog of commits:

Greg Kroah-Hartman <[email protected]>
Linux 3.10.63-rc1

Takashi Iwai <[email protected]>
ALSA: usb-audio: Don't resubmit pending URBs at MIDI error recovery

Anton Blanchard <[email protected]>
powerpc: 32 bit getcpu VDSO function uses 64 bit instructions

Stephen Boyd <[email protected]>
ARM: sched_clock: Load cycle count after epoch stabilizes

Todd Fujinaka <[email protected]>
igb: bring link up when PHY is powered up

Jan Kara <[email protected]>
ext2: Fix oops in ext2_get_block() called from ext2_quota_write()

Nadav Har'El <[email protected]>
nEPT: Nested INVEPT

Daniel Borkmann <[email protected]>
net: sctp: use MAX_HEADER for headroom reserve in output path

willy tarreau <[email protected]>
net: mvneta: fix Tx interrupt delay

Nicolas Dichtel <[email protected]>
rtnetlink: release net refcnt on error in do_setlink()

Jack Morgenstein <[email protected]>
net/mlx4_core: Limit count field to 24 bits in qp_alloc_res

Thadeu Lima de Souza Cascardo <[email protected]>
tg3: fix ring init when there are more TX than RX channels

Yuri Chislov <[email protected]>
ipv6: gre: fix wrong skb->protocol in WCCP

Dmitry Torokhov <[email protected]>
sata_fsl: fix error handling of irq_of_parse_and_map

Tejun Heo <[email protected]>
ahci: disable MSI on SAMSUNG 0xa800 SSD

Devin Ryles <[email protected]>
AHCI: Add DeviceIDs for Sunrise Point-LP SATA controller

Sakari Ailus <[email protected]>
media: smiapp: Only some selection targets are settable

Daniel Vetter <[email protected]>
drm/i915: Unlock panel even when LVDS is disabled

Petr Mladek <[email protected]>
drm/radeon: kernel panic in drm_calc_vbltimestamp_from_scanoutpos with 3.18.0-rc6

Grygorii Strashko <[email protected]>
i2c: davinci: generate STP always when NACK is received

Alexander Kochetkov <[email protected]>
i2c: omap: fix i207 errata handling

Alexander Kochetkov <[email protected]>
i2c: omap: fix NACK and Arbitration Lost irq handling

Seth Forshee <[email protected]>
xen-netfront: Remove BUGs on paged skb data which crosses a page boundary

Hugh Dickins <[email protected]>
mm: fix swapoff hang after page migration and fork

Weijie Yang <[email protected]>
mm: frontswap: invalidate expired data on a dup-store failure


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

Diffstat:

Makefile | 4 ++--
arch/arm/kernel/sched_clock.c | 13 +++++------
arch/powerpc/kernel/vdso32/getcpu.S | 4 ++--
arch/x86/include/uapi/asm/vmx.h | 1 +
arch/x86/kvm/vmx.c | 8 +++++++
drivers/ata/ahci.c | 4 ++++
drivers/ata/sata_fsl.c | 2 +-
drivers/gpu/drm/i915/intel_lvds.c | 22 +++++++++---------
drivers/gpu/drm/radeon/radeon_kms.c | 2 ++
drivers/i2c/busses/i2c-davinci.c | 8 +++----
drivers/i2c/busses/i2c-omap.c | 10 ++++-----
drivers/media/i2c/smiapp/smiapp-core.c | 2 +-
drivers/net/ethernet/broadcom/tg3.c | 3 ++-
drivers/net/ethernet/intel/igb/igb_main.c | 2 ++
drivers/net/ethernet/marvell/mvneta.c | 2 +-
.../net/ethernet/mellanox/mlx4/resource_tracker.c | 2 +-
drivers/net/xen-netfront.c | 5 -----
fs/ext2/super.c | 1 +
mm/frontswap.c | 4 +++-
mm/memory.c | 26 +++++++++++-----------
net/core/rtnetlink.c | 1 +
net/ipv6/ip6_gre.c | 4 ++--
net/sctp/output.c | 4 ++--
sound/usb/midi.c | 2 ++
24 files changed, 75 insertions(+), 61 deletions(-)


2014-12-14 20:21:48

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 3.10 01/24] mm: frontswap: invalidate expired data on a dup-store failure

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

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

From: Weijie Yang <[email protected]>

commit fb993fa1a2f669215fa03a09eed7848f2663e336 upstream.

If a frontswap dup-store failed, it should invalidate the expired page
in the backend, or it could trigger some data corruption issue.
Such as:
1. use zswap as the frontswap backend with writeback feature
2. store a swap page(version_1) to entry A, success
3. dup-store a newer page(version_2) to the same entry A, fail
4. use __swap_writepage() write version_2 page to swapfile, success
5. zswap do shrink, writeback version_1 page to swapfile
6. version_2 page is overwrited by version_1, data corrupt.

This patch fixes this issue by invalidating expired data immediately
when meet a dup-store failure.

Signed-off-by: Weijie Yang <[email protected]>
Cc: Konrad Rzeszutek Wilk <[email protected]>
Cc: Seth Jennings <[email protected]>
Cc: Dan Streetman <[email protected]>
Cc: Minchan Kim <[email protected]>
Cc: Bob Liu <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
mm/frontswap.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)

--- a/mm/frontswap.c
+++ b/mm/frontswap.c
@@ -244,8 +244,10 @@ int __frontswap_store(struct page *page)
the (older) page from frontswap
*/
inc_frontswap_failed_stores();
- if (dup)
+ if (dup) {
__frontswap_clear(sis, offset);
+ frontswap_ops->invalidate_page(type, offset);
+ }
}
if (frontswap_writethrough_enabled)
/* report failure so swap also writes to swap device */

2014-12-14 20:21:53

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 3.10 10/24] AHCI: Add DeviceIDs for Sunrise Point-LP SATA controller

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

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

From: Devin Ryles <[email protected]>

commit 249cd0a187ed4ef1d0af7f74362cc2791ec5581b upstream.

This patch adds DeviceIDs for Sunrise Point-LP.

Signed-off-by: Devin Ryles <[email protected]>
Signed-off-by: Tejun Heo <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/ata/ahci.c | 3 +++
1 file changed, 3 insertions(+)

--- a/drivers/ata/ahci.c
+++ b/drivers/ata/ahci.c
@@ -320,6 +320,9 @@ static const struct pci_device_id ahci_p
{ PCI_VDEVICE(INTEL, 0x8c87), board_ahci }, /* 9 Series RAID */
{ PCI_VDEVICE(INTEL, 0x8c8e), board_ahci }, /* 9 Series RAID */
{ PCI_VDEVICE(INTEL, 0x8c8f), board_ahci }, /* 9 Series RAID */
+ { PCI_VDEVICE(INTEL, 0x9d03), board_ahci }, /* Sunrise Point-LP AHCI */
+ { PCI_VDEVICE(INTEL, 0x9d05), board_ahci }, /* Sunrise Point-LP RAID */
+ { PCI_VDEVICE(INTEL, 0x9d07), board_ahci }, /* Sunrise Point-LP RAID */
{ PCI_VDEVICE(INTEL, 0xa103), board_ahci }, /* Sunrise Point-H AHCI */
{ PCI_VDEVICE(INTEL, 0xa103), board_ahci }, /* Sunrise Point-H RAID */
{ PCI_VDEVICE(INTEL, 0xa105), board_ahci }, /* Sunrise Point-H RAID */

2014-12-14 20:22:20

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 3.10 13/24] ipv6: gre: fix wrong skb->protocol in WCCP

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

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

From: Yuri Chislov <[email protected]>

[ Upstream commit be6572fdb1bfbe23b2624d477de50af50b02f5d6 ]

When using GRE redirection in WCCP, it sets the wrong skb->protocol,
that is, ETH_P_IP instead of ETH_P_IPV6 for the encapuslated traffic.

Fixes: c12b395a4664 ("gre: Support GRE over IPv6")
Cc: Dmitry Kozlov <[email protected]>
Signed-off-by: Yuri Chislov <[email protected]>
Tested-by: Yuri Chislov <[email protected]>
Signed-off-by: Daniel Borkmann <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
net/ipv6/ip6_gre.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

--- a/net/ipv6/ip6_gre.c
+++ b/net/ipv6/ip6_gre.c
@@ -512,11 +512,11 @@ static int ip6gre_rcv(struct sk_buff *sk

skb->protocol = gre_proto;
/* WCCP version 1 and 2 protocol decoding.
- * - Change protocol to IP
+ * - Change protocol to IPv6
* - When dealing with WCCPv2, Skip extra 4 bytes in GRE header
*/
if (flags == 0 && gre_proto == htons(ETH_P_WCCP)) {
- skb->protocol = htons(ETH_P_IP);
+ skb->protocol = htons(ETH_P_IPV6);
if ((*(h + offset) & 0xF0) != 0x40)
offset += 4;
}

2014-12-14 20:22:01

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 3.10 11/24] ahci: disable MSI on SAMSUNG 0xa800 SSD

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

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

From: Tejun Heo <[email protected]>

commit 2b21ef0aae65f22f5ba86b13c4588f6f0c2dbefb upstream.

Just like 0x1600 which got blacklisted by 66a7cbc303f4 ("ahci: disable
MSI instead of NCQ on Samsung pci-e SSDs on macbooks"), 0xa800 chokes
on NCQ commands if MSI is enabled. Disable MSI.

Signed-off-by: Tejun Heo <[email protected]>
Reported-by: Dominik Mierzejewski <[email protected]>
Link: https://bugzilla.kernel.org/show_bug.cgi?id=89171
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/ata/ahci.c | 1 +
1 file changed, 1 insertion(+)

--- a/drivers/ata/ahci.c
+++ b/drivers/ata/ahci.c
@@ -494,6 +494,7 @@ static const struct pci_device_id ahci_p
* enabled. https://bugzilla.kernel.org/show_bug.cgi?id=60731
*/
{ PCI_VDEVICE(SAMSUNG, 0x1600), board_ahci_nomsi },
+ { PCI_VDEVICE(SAMSUNG, 0xa800), board_ahci_nomsi },

/* Enmotus */
{ PCI_DEVICE(0x1c44, 0x8000), board_ahci },

2014-12-14 20:22:31

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 3.10 12/24] sata_fsl: fix error handling of irq_of_parse_and_map

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

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

From: Dmitry Torokhov <[email protected]>

commit aad0b624129709c94c2e19e583b6053520353fa8 upstream.

irq_of_parse_and_map() returns 0 on error (the result is unsigned int),
so testing for negative result never works.

Signed-off-by: Dmitry Torokhov <[email protected]>
Signed-off-by: Tejun Heo <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/ata/sata_fsl.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/ata/sata_fsl.c
+++ b/drivers/ata/sata_fsl.c
@@ -1501,7 +1501,7 @@ static int sata_fsl_probe(struct platfor
host_priv->csr_base = csr_base;

irq = irq_of_parse_and_map(ofdev->dev.of_node, 0);
- if (irq < 0) {
+ if (!irq) {
dev_err(&ofdev->dev, "invalid irq from platform\n");
goto error_exit_with_cleanup;
}

2014-12-14 20:22:39

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 3.10 14/24] tg3: fix ring init when there are more TX than RX channels

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

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

From: Thadeu Lima de Souza Cascardo <[email protected]>

[ Upstream commit a620a6bc1c94c22d6c312892be1e0ae171523125 ]

If TX channels are set to 4 and RX channels are set to less than 4,
using ethtool -L, the driver will try to initialize more RX channels
than it has allocated, causing an oops.

This fix only initializes the RX ring if it has been allocated.

Signed-off-by: Thadeu Lima de Souza Cascardo <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/net/ethernet/broadcom/tg3.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)

--- a/drivers/net/ethernet/broadcom/tg3.c
+++ b/drivers/net/ethernet/broadcom/tg3.c
@@ -8392,7 +8392,8 @@ static int tg3_init_rings(struct tg3 *tp
if (tnapi->rx_rcb)
memset(tnapi->rx_rcb, 0, TG3_RX_RCB_RING_BYTES(tp));

- if (tg3_rx_prodring_alloc(tp, &tnapi->prodring)) {
+ if (tnapi->prodring.rx_std &&
+ tg3_rx_prodring_alloc(tp, &tnapi->prodring)) {
tg3_free_rings(tp);
return -ENOMEM;
}

2014-12-14 20:22:44

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 3.10 15/24] net/mlx4_core: Limit count field to 24 bits in qp_alloc_res

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

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

From: Jack Morgenstein <[email protected]>

[ Upstream commit 2d5c57d7fbfaa642fb7f0673df24f32b83d9066c ]

Some VF drivers use the upper byte of "param1" (the qp count field)
in mlx4_qp_reserve_range() to pass flags which are used to optimize
the range allocation.

Under the current code, if any of these flags are set, the 32-bit
count field yields a count greater than 2^24, which is out of range,
and this VF fails.

As these flags represent a "best-effort" allocation hint anyway, they may
safely be ignored. Therefore, the PF driver may simply mask out the bits.

Fixes: c82e9aa0a8 "mlx4_core: resource tracking for HCA resources used by guests"
Signed-off-by: Jack Morgenstein <[email protected]>
Signed-off-by: Or Gerlitz <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/net/ethernet/mellanox/mlx4/resource_tracker.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/net/ethernet/mellanox/mlx4/resource_tracker.c
+++ b/drivers/net/ethernet/mellanox/mlx4/resource_tracker.c
@@ -1207,7 +1207,7 @@ static int qp_alloc_res(struct mlx4_dev

switch (op) {
case RES_OP_RESERVE:
- count = get_param_l(&in_param);
+ count = get_param_l(&in_param) & 0xffffff;
align = get_param_h(&in_param);
err = __mlx4_qp_reserve_range(dev, count, align, &base);
if (err)

2014-12-14 20:23:02

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 3.10 16/24] rtnetlink: release net refcnt on error in do_setlink()

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

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

From: Nicolas Dichtel <[email protected]>

[ Upstream commit e0ebde0e131b529fd721b24f62872def5ec3718c ]

rtnl_link_get_net() holds a reference on the 'struct net', we need to release
it in case of error.

CC: Eric W. Biederman <[email protected]>
Fixes: b51642f6d77b ("net: Enable a userns root rtnl calls that are safe for unprivilged users")
Signed-off-by: Nicolas Dichtel <[email protected]>
Reviewed-by: "Eric W. Biederman" <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
net/core/rtnetlink.c | 1 +
1 file changed, 1 insertion(+)

--- a/net/core/rtnetlink.c
+++ b/net/core/rtnetlink.c
@@ -1318,6 +1318,7 @@ static int do_setlink(const struct sk_bu
goto errout;
}
if (!netlink_ns_capable(skb, net->user_ns, CAP_NET_ADMIN)) {
+ put_net(net);
err = -EPERM;
goto errout;
}

2014-12-14 20:22:52

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 3.10 17/24] net: mvneta: fix Tx interrupt delay

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

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

From: willy tarreau <[email protected]>

[ Upstream commit aebea2ba0f7495e1a1c9ea5e753d146cb2f6b845 ]

The mvneta driver sets the amount of Tx coalesce packets to 16 by
default. Normally that does not cause any trouble since the driver
uses a much larger Tx ring size (532 packets). But some sockets
might run with very small buffers, much smaller than the equivalent
of 16 packets. This is what ping is doing for example, by setting
SNDBUF to 324 bytes rounded up to 2kB by the kernel.

The problem is that there is no documented method to force a specific
packet to emit an interrupt (eg: the last of the ring) nor is it
possible to make the NIC emit an interrupt after a given delay.

In this case, it causes trouble, because when ping sends packets over
its raw socket, the few first packets leave the system, and the first
15 packets will be emitted without an IRQ being generated, so without
the skbs being freed. And since the socket's buffer is small, there's
no way to reach that amount of packets, and the ping ends up with
"send: no buffer available" after sending 6 packets. Running with 3
instances of ping in parallel is enough to hide the problem, because
with 6 packets per instance, that's 18 packets total, which is enough
to grant a Tx interrupt before all are sent.

The original driver in the LSP kernel worked around this design flaw
by using a software timer to clean up the Tx descriptors. This timer
was slow and caused terrible network performance on some Tx-bound
workloads (such as routing) but was enough to make tools like ping
work correctly.

Instead here, we simply set the packet counts before interrupt to 1.
This ensures that each packet sent will produce an interrupt. NAPI
takes care of coalescing interrupts since the interrupt is disabled
once generated.

No measurable performance impact nor CPU usage were observed on small
nor large packets, including when saturating the link on Tx, and this
fixes tools like ping which rely on too small a send buffer. If one
wants to increase this value for certain workloads where it is safe
to do so, "ethtool -C $dev tx-frames" will override this default
setting.

This fix needs to be applied to stable kernels starting with 3.10.

Tested-By: Maggie Mae Roxas <[email protected]>
Signed-off-by: Willy Tarreau <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/net/ethernet/marvell/mvneta.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/net/ethernet/marvell/mvneta.c
+++ b/drivers/net/ethernet/marvell/mvneta.c
@@ -210,7 +210,7 @@
/* Various constants */

/* Coalescing */
-#define MVNETA_TXDONE_COAL_PKTS 16
+#define MVNETA_TXDONE_COAL_PKTS 1
#define MVNETA_RX_COAL_PKTS 32
#define MVNETA_RX_COAL_USEC 100


2014-12-14 20:23:17

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 3.10 19/24] nEPT: Nested INVEPT

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

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

From: Nadav Har'El <[email protected]>

commit bfd0a56b90005f8c8a004baf407ad90045c2b11e upstream.

If we let L1 use EPT, we should probably also support the INVEPT instruction.

In our current nested EPT implementation, when L1 changes its EPT table
for L2 (i.e., EPT12), L0 modifies the shadow EPT table (EPT02), and in
the course of this modification already calls INVEPT. But if last level
of shadow page is unsync not all L1's changes to EPT12 are intercepted,
which means roots need to be synced when L1 calls INVEPT. Global INVEPT
should not be different since roots are synced by kvm_mmu_load() each
time EPTP02 changes.

Reviewed-by: Xiao Guangrong <[email protected]>
Signed-off-by: Nadav Har'El <[email protected]>
Signed-off-by: Jun Nakajima <[email protected]>
Signed-off-by: Xinhao Xu <[email protected]>
Signed-off-by: Yang Zhang <[email protected]>
Signed-off-by: Gleb Natapov <[email protected]>
Signed-off-by: Paolo Bonzini <[email protected]>
[bwh: Backported to 3.2:
- Adjust context, filename
- Simplify handle_invept() as recommended by Paolo - nEPT is not
supported so we always raise #UD]
Signed-off-by: Ben Hutchings <[email protected]>
Cc: Vinson Lee <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
arch/x86/include/uapi/asm/vmx.h | 1 +
arch/x86/kvm/vmx.c | 8 ++++++++
2 files changed, 9 insertions(+)

--- a/arch/x86/include/uapi/asm/vmx.h
+++ b/arch/x86/include/uapi/asm/vmx.h
@@ -65,6 +65,7 @@
#define EXIT_REASON_EOI_INDUCED 45
#define EXIT_REASON_EPT_VIOLATION 48
#define EXIT_REASON_EPT_MISCONFIG 49
+#define EXIT_REASON_INVEPT 50
#define EXIT_REASON_PREEMPTION_TIMER 52
#define EXIT_REASON_WBINVD 54
#define EXIT_REASON_XSETBV 55
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -6242,6 +6242,12 @@ static int handle_vmptrst(struct kvm_vcp
return 1;
}

+static int handle_invept(struct kvm_vcpu *vcpu)
+{
+ kvm_queue_exception(vcpu, UD_VECTOR);
+ return 1;
+}
+
/*
* The exit handlers return 1 if the exit was handled fully and guest execution
* may resume. Otherwise they set the kvm_run parameter to indicate what needs
@@ -6286,6 +6292,7 @@ static int (*const kvm_vmx_exit_handlers
[EXIT_REASON_PAUSE_INSTRUCTION] = handle_pause,
[EXIT_REASON_MWAIT_INSTRUCTION] = handle_invalid_op,
[EXIT_REASON_MONITOR_INSTRUCTION] = handle_invalid_op,
+ [EXIT_REASON_INVEPT] = handle_invept,
};

static const int kvm_vmx_max_exit_handlers =
@@ -6512,6 +6519,7 @@ static bool nested_vmx_exit_handled(stru
case EXIT_REASON_VMPTRST: case EXIT_REASON_VMREAD:
case EXIT_REASON_VMRESUME: case EXIT_REASON_VMWRITE:
case EXIT_REASON_VMOFF: case EXIT_REASON_VMON:
+ case EXIT_REASON_INVEPT:
/*
* VMX instructions trap unconditionally. This allows L1 to
* emulate them for its L2 guest, i.e., allows 3-level nesting!

2014-12-14 20:48:04

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 3.10 23/24] powerpc: 32 bit getcpu VDSO function uses 64 bit instructions

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

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

From: Anton Blanchard <[email protected]>

commit 152d44a853e42952f6c8a504fb1f8eefd21fd5fd upstream.

I used some 64 bit instructions when adding the 32 bit getcpu VDSO
function. Fix it.

Fixes: 18ad51dd342a ("powerpc: Add VDSO version of getcpu")
Signed-off-by: Anton Blanchard <[email protected]>
Signed-off-by: Michael Ellerman <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
arch/powerpc/kernel/vdso32/getcpu.S | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

--- a/arch/powerpc/kernel/vdso32/getcpu.S
+++ b/arch/powerpc/kernel/vdso32/getcpu.S
@@ -30,8 +30,8 @@
V_FUNCTION_BEGIN(__kernel_getcpu)
.cfi_startproc
mfspr r5,SPRN_USPRG3
- cmpdi cr0,r3,0
- cmpdi cr1,r4,0
+ cmpwi cr0,r3,0
+ cmpwi cr1,r4,0
clrlwi r6,r5,16
rlwinm r7,r5,16,31-15,31-0
beq cr0,1f

2014-12-14 20:48:13

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 3.10 24/24] ALSA: usb-audio: Dont resubmit pending URBs at MIDI error recovery

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

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

From: Takashi Iwai <[email protected]>

commit 66139a48cee1530c91f37c145384b4ee7043f0b7 upstream.

In snd_usbmidi_error_timer(), the driver tries to resubmit MIDI input
URBs to reactivate the MIDI stream, but this causes the error when
some of URBs are still pending like:

WARNING: CPU: 0 PID: 0 at ../drivers/usb/core/urb.c:339 usb_submit_urb+0x5f/0x70()
URB ef705c40 submitted while active
CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.16.6-2-desktop #1
Hardware name: FOXCONN TPS01/TPS01, BIOS 080015 03/23/2010
c0984bfa f4009ed4 c078deaf f4009ee4 c024c884 c09a135c f4009f00 00000000
c0984bfa 00000153 c061ac4f c061ac4f 00000009 00000001 ef705c40 e854d1c0
f4009eec c024c8d3 00000009 f4009ee4 c09a135c f4009f00 f4009f04 c061ac4f
Call Trace:
[<c0205df6>] try_stack_unwind+0x156/0x170
[<c020482a>] dump_trace+0x5a/0x1b0
[<c0205e56>] show_trace_log_lvl+0x46/0x50
[<c02049d1>] show_stack_log_lvl+0x51/0xe0
[<c0205eb7>] show_stack+0x27/0x50
[<c078deaf>] dump_stack+0x45/0x65
[<c024c884>] warn_slowpath_common+0x84/0xa0
[<c024c8d3>] warn_slowpath_fmt+0x33/0x40
[<c061ac4f>] usb_submit_urb+0x5f/0x70
[<f7974104>] snd_usbmidi_submit_urb+0x14/0x60 [snd_usbmidi_lib]
[<f797483a>] snd_usbmidi_error_timer+0x6a/0xa0 [snd_usbmidi_lib]
[<c02570c0>] call_timer_fn+0x30/0x130
[<c0257442>] run_timer_softirq+0x1c2/0x260
[<c0251493>] __do_softirq+0xc3/0x270
[<c0204732>] do_softirq_own_stack+0x22/0x30
[<c025186d>] irq_exit+0x8d/0xa0
[<c0795228>] smp_apic_timer_interrupt+0x38/0x50
[<c0794a3c>] apic_timer_interrupt+0x34/0x3c
[<c0673d9e>] cpuidle_enter_state+0x3e/0xd0
[<c028bb8d>] cpu_idle_loop+0x29d/0x3e0
[<c028bd23>] cpu_startup_entry+0x53/0x60
[<c0bfac1e>] start_kernel+0x415/0x41a

For avoiding these errors, check the pending URBs and skip
resubmitting such ones.

Reported-and-tested-by: Stefan Seyfried <[email protected]>
Acked-by: Clemens Ladisch <[email protected]>
Signed-off-by: Takashi Iwai <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
sound/usb/midi.c | 2 ++
1 file changed, 2 insertions(+)

--- a/sound/usb/midi.c
+++ b/sound/usb/midi.c
@@ -364,6 +364,8 @@ static void snd_usbmidi_error_timer(unsi
if (in && in->error_resubmit) {
in->error_resubmit = 0;
for (j = 0; j < INPUT_URBS; ++j) {
+ if (atomic_read(&in->urbs[j]->use_count))
+ continue;
in->urbs[j]->dev = umidi->dev;
snd_usbmidi_submit_urb(in->urbs[j], GFP_ATOMIC);
}

2014-12-14 20:50:06

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 3.10 09/24] media: smiapp: Only some selection targets are settable

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

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

From: Sakari Ailus <[email protected]>

commit b31eb901c4e5eeef4c83c43dfbc7fe0d4348cb21 upstream.

Setting a non-settable selection target caused BUG() to be called. The check
for valid selections only takes the selection target into account, but does
not tell whether it may be set, or only get. Fix the issue by simply
returning an error to the user.

Signed-off-by: Sakari Ailus <[email protected]>
Signed-off-by: Mauro Carvalho Chehab <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/media/i2c/smiapp/smiapp-core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/media/i2c/smiapp/smiapp-core.c
+++ b/drivers/media/i2c/smiapp/smiapp-core.c
@@ -2139,7 +2139,7 @@ static int smiapp_set_selection(struct v
ret = smiapp_set_compose(subdev, fh, sel);
break;
default:
- BUG();
+ ret = -EINVAL;
}

mutex_unlock(&sensor->mutex);

2014-12-14 20:50:13

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 3.10 08/24] drm/i915: Unlock panel even when LVDS is disabled

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

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

From: Daniel Vetter <[email protected]>

commit b0616c5306b342ceca07044dbc4f917d95c4f825 upstream.

Otherwise we'll have backtraces in assert_panel_unlocked because the
BIOS locks the register. In the reporter's case this regression was
introduced in

commit c31407a3672aaebb4acddf90944a114fa5c8af7b
Author: Chris Wilson <[email protected]>
Date: Thu Oct 18 21:07:01 2012 +0100

drm/i915: Add no-lvds quirk for Supermicro X7SPA-H

Reported-by: Alexey Orishko <[email protected]>
Cc: Alexey Orishko <[email protected]>
Cc: Chris Wilson <[email protected]>
Cc: Francois Tigeot <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
Tested-by: Alexey Orishko <[email protected]>
Signed-off-by: Jani Nikula <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/gpu/drm/i915/intel_lvds.c | 22 +++++++++++-----------
1 file changed, 11 insertions(+), 11 deletions(-)

--- a/drivers/gpu/drm/i915/intel_lvds.c
+++ b/drivers/gpu/drm/i915/intel_lvds.c
@@ -1097,6 +1097,17 @@ bool intel_lvds_init(struct drm_device *
int pipe;
u8 pin;

+ /*
+ * Unlock registers and just leave them unlocked. Do this before
+ * checking quirk lists to avoid bogus WARNINGs.
+ */
+ if (HAS_PCH_SPLIT(dev)) {
+ I915_WRITE(PCH_PP_CONTROL,
+ I915_READ(PCH_PP_CONTROL) | PANEL_UNLOCK_REGS);
+ } else {
+ I915_WRITE(PP_CONTROL,
+ I915_READ(PP_CONTROL) | PANEL_UNLOCK_REGS);
+ }
if (!intel_lvds_supported(dev))
return false;

@@ -1280,17 +1291,6 @@ out:
DRM_DEBUG_KMS("detected %s-link lvds configuration\n",
lvds_encoder->is_dual_link ? "dual" : "single");

- /*
- * Unlock registers and just
- * leave them unlocked
- */
- if (HAS_PCH_SPLIT(dev)) {
- I915_WRITE(PCH_PP_CONTROL,
- I915_READ(PCH_PP_CONTROL) | PANEL_UNLOCK_REGS);
- } else {
- I915_WRITE(PP_CONTROL,
- I915_READ(PP_CONTROL) | PANEL_UNLOCK_REGS);
- }
lvds_connector->lid_notifier.notifier_call = intel_lid_notify;
if (acpi_lid_notifier_register(&lvds_connector->lid_notifier)) {
DRM_DEBUG_KMS("lid notifier registration failed\n");

2014-12-14 20:50:23

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 3.10 07/24] drm/radeon: kernel panic in drm_calc_vbltimestamp_from_scanoutpos with 3.18.0-rc6

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

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

From: Petr Mladek <[email protected]>

commit f5475cc43c899e33098d4db44b7c5e710f16589d upstream.

I was unable too boot 3.18.0-rc6 because of the following kernel
panic in drm_calc_vbltimestamp_from_scanoutpos():

[drm] Initialized drm 1.1.0 20060810
[drm] radeon kernel modesetting enabled.
[drm] initializing kernel modesetting (RV100 0x1002:0x515E 0x15D9:0x8080).
[drm] register mmio base: 0xC8400000
[drm] register mmio size: 65536
radeon 0000:0b:01.0: VRAM: 128M 0x00000000D0000000 - 0x00000000D7FFFFFF (16M used)
radeon 0000:0b:01.0: GTT: 512M 0x00000000B0000000 - 0x00000000CFFFFFFF
[drm] Detected VRAM RAM=128M, BAR=128M
[drm] RAM width 16bits DDR
[TTM] Zone kernel: Available graphics memory: 3829346 kiB
[TTM] Zone dma32: Available graphics memory: 2097152 kiB
[TTM] Initializing pool allocator
[TTM] Initializing DMA pool allocator
[drm] radeon: 16M of VRAM memory ready
[drm] radeon: 512M of GTT memory ready.
[drm] GART: num cpu pages 131072, num gpu pages 131072
[drm] PCI GART of 512M enabled (table at 0x0000000037880000).
radeon 0000:0b:01.0: WB disabled
radeon 0000:0b:01.0: fence driver on ring 0 use gpu addr 0x00000000b0000000 and cpu addr 0xffff8800bbbfa000
[drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[drm] Driver supports precise vblank timestamp query.
[drm] radeon: irq initialized.
[drm] Loading R100 Microcode
radeon 0000:0b:01.0: Direct firmware load for radeon/R100_cp.bin failed with error -2
radeon_cp: Failed to load firmware "radeon/R100_cp.bin"
[drm:r100_cp_init] *ERROR* Failed to load firmware!
radeon 0000:0b:01.0: failed initializing CP (-2).
radeon 0000:0b:01.0: Disabling GPU acceleration
[drm] radeon: cp finalized
BUG: unable to handle kernel NULL pointer dereference at 000000000000025c
IP: [<ffffffff8150423b>] drm_calc_vbltimestamp_from_scanoutpos+0x4b/0x320
PGD 0
Oops: 0000 [#1] SMP
Modules linked in:
CPU: 1 PID: 1 Comm: swapper/0 Not tainted 3.18.0-rc6-4-default #2649
Hardware name: Supermicro X7DB8/X7DB8, BIOS 6.00 07/26/2006
task: ffff880234da2010 ti: ffff880234da4000 task.ti: ffff880234da4000
RIP: 0010:[<ffffffff8150423b>] [<ffffffff8150423b>] drm_calc_vbltimestamp_from_scanoutpos+0x4b/0x320
RSP: 0000:ffff880234da7918 EFLAGS: 00010086
RAX: ffffffff81557890 RBX: 0000000000000000 RCX: ffff880234da7a48
RDX: ffff880234da79f4 RSI: 0000000000000000 RDI: ffff880232e15000
RBP: ffff880234da79b8 R08: 0000000000000000 R09: 0000000000000000
R10: 000000000000000a R11: 0000000000000001 R12: ffff880232dda1c0
R13: ffff880232e1518c R14: 0000000000000292 R15: ffff880232e15000
FS: 0000000000000000(0000) GS:ffff88023fc40000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 000000000000025c CR3: 0000000002014000 CR4: 00000000000007e0
Stack:
ffff880234da79d8 0000000000000286 ffff880232dcbc00 0000000000002480
ffff880234da7958 0000000000000296 ffff880234da7998 ffffffff8151b51d
ffff880234da7a48 0000000032dcbeb0 ffff880232dcbc00 ffff880232dcbc58
Call Trace:
[<ffffffff8151b51d>] ? drm_vma_offset_remove+0x1d/0x110
[<ffffffff8152dc98>] radeon_get_vblank_timestamp_kms+0x38/0x60
[<ffffffff8152076a>] ? ttm_bo_release_list+0xba/0x180
[<ffffffff81503751>] drm_get_last_vbltimestamp+0x41/0x70
[<ffffffff81503933>] vblank_disable_and_save+0x73/0x1d0
[<ffffffff81106b2f>] ? try_to_del_timer_sync+0x4f/0x70
[<ffffffff81505245>] drm_vblank_cleanup+0x65/0xa0
[<ffffffff815604fa>] radeon_irq_kms_fini+0x1a/0x70
[<ffffffff8156c07e>] r100_init+0x26e/0x410
[<ffffffff8152ae3e>] radeon_device_init+0x7ae/0xb50
[<ffffffff8152d57f>] radeon_driver_load_kms+0x8f/0x210
[<ffffffff81506965>] drm_dev_register+0xb5/0x110
[<ffffffff8150998f>] drm_get_pci_dev+0x8f/0x200
[<ffffffff815291cd>] radeon_pci_probe+0xad/0xe0
[<ffffffff8141a365>] local_pci_probe+0x45/0xa0
[<ffffffff8141b741>] pci_device_probe+0xd1/0x130
[<ffffffff81633dad>] driver_probe_device+0x12d/0x3e0
[<ffffffff8163413b>] __driver_attach+0x9b/0xa0
[<ffffffff816340a0>] ? __device_attach+0x40/0x40
[<ffffffff81631cd3>] bus_for_each_dev+0x63/0xa0
[<ffffffff8163378e>] driver_attach+0x1e/0x20
[<ffffffff81633390>] bus_add_driver+0x180/0x240
[<ffffffff81634914>] driver_register+0x64/0xf0
[<ffffffff81419cac>] __pci_register_driver+0x4c/0x50
[<ffffffff81509bf5>] drm_pci_init+0xf5/0x120
[<ffffffff821dc871>] ? ttm_init+0x6a/0x6a
[<ffffffff821dc908>] radeon_init+0x97/0xb5
[<ffffffff810002fc>] do_one_initcall+0xbc/0x1f0
[<ffffffff810e3278>] ? __wake_up+0x48/0x60
[<ffffffff8218e256>] kernel_init_freeable+0x18a/0x215
[<ffffffff8218d983>] ? initcall_blacklist+0xc0/0xc0
[<ffffffff818a78f0>] ? rest_init+0x80/0x80
[<ffffffff818a78fe>] kernel_init+0xe/0xf0
[<ffffffff818c0c3c>] ret_from_fork+0x7c/0xb0
[<ffffffff818a78f0>] ? rest_init+0x80/0x80
Code: 45 ac 0f 88 a8 01 00 00 3b b7 d0 01 00 00 49 89 ff 0f 83 99 01 00 00 48 8b 47 20 48 8b 80 88 00 00 00 48 85 c0 0f 84 cd 01 00 00 <41> 8b b1 5c 02 00 00 41 8b 89 58 02 00 00 89 75 98 41 8b b1 60
RIP [<ffffffff8150423b>] drm_calc_vbltimestamp_from_scanoutpos+0x4b/0x320
RSP <ffff880234da7918>
CR2: 000000000000025c
---[ end trace ad2c0aadf48e2032 ]---
Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000009

It has helped me to add a NULL pointer check that was suggested at
http://lists.freedesktop.org/archives/dri-devel/2014-October/070663.html

I am not familiar with the code. But the change looks sane
and we need something fast at this stage of 3.18 development.

Suggested-by: Helge Deller <[email protected]>
Signed-off-by: Petr Mladek <[email protected]>
Tested-by: Petr Mladek <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/gpu/drm/radeon/radeon_kms.c | 2 ++
1 file changed, 2 insertions(+)

--- a/drivers/gpu/drm/radeon/radeon_kms.c
+++ b/drivers/gpu/drm/radeon/radeon_kms.c
@@ -666,6 +666,8 @@ int radeon_get_vblank_timestamp_kms(stru

/* Get associated drm_crtc: */
drmcrtc = &rdev->mode_info.crtcs[crtc]->base;
+ if (!drmcrtc)
+ return -EINVAL;

/* Helper routine in DRM core does all the work: */
return drm_calc_vbltimestamp_from_scanoutpos(dev, crtc, max_error,

2014-12-14 20:50:30

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 3.10 05/24] i2c: omap: fix i207 errata handling

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

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

From: Alexander Kochetkov <[email protected]>

commit ccfc866356674cb3a61829d239c685af6e85f197 upstream.

commit 6d9939f651419a63e091105663821f9c7d3fec37 (i2c: omap: split out [XR]DR
and [XR]RDY) changed the way how errata i207 (I2C: RDR Flag May Be Incorrectly
Set) get handled. 6d9939f6514 code doesn't correspond to workaround provided by
errata.

According to errata ISR must filter out spurious RDR before data read not after.
ISR must read RXSTAT to get number of bytes available to read. Because RDR
could be set while there could no data in the receive FIFO.

Restored pre 6d9939f6514 way of handling errata.

Found by code review. Real impact haven't seen.
Tested on Beagleboard XM C.

Signed-off-by: Alexander Kochetkov <[email protected]>
Fixes: 6d9939f651419a63e09110 i2c: omap: split out [XR]DR and [XR]RDY
Tested-by: Felipe Balbi <[email protected]>
Reviewed-by: Felipe Balbi <[email protected]>
Signed-off-by: Wolfram Sang <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/i2c/busses/i2c-omap.c | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)

--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -958,11 +958,13 @@ omap_i2c_isr_thread(int this_irq, void *
if (dev->fifo_size)
num_bytes = dev->buf_len;

- omap_i2c_receive_data(dev, num_bytes, true);
-
- if (dev->errata & I2C_OMAP_ERRATA_I207)
+ if (dev->errata & I2C_OMAP_ERRATA_I207) {
i2c_omap_errata_i207(dev, stat);
+ num_bytes = (omap_i2c_read_reg(dev,
+ OMAP_I2C_BUFSTAT_REG) >> 8) & 0x3F;
+ }

+ omap_i2c_receive_data(dev, num_bytes, true);
omap_i2c_ack_stat(dev, OMAP_I2C_STAT_RDR);
continue;
}

2014-12-14 20:51:09

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 3.10 03/24] xen-netfront: Remove BUGs on paged skb data which crosses a page boundary

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

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

From: Seth Forshee <[email protected]>

commit 8d609725d4357f499e2103e46011308b32f53513 upstream.

These BUGs can be erroneously triggered by frags which refer to
tail pages within a compound page. The data in these pages may
overrun the hardware page while still being contained within the
compound page, but since compound_order() evaluates to 0 for tail
pages the assertion fails. The code already iterates through
subsequent pages correctly in this scenario, so the BUGs are
unnecessary and can be removed.

Fixes: f36c374782e4 ("xen/netfront: handle compound page fragments on transmit")
Signed-off-by: Seth Forshee <[email protected]>
Reviewed-by: David Vrabel <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/net/xen-netfront.c | 5 -----
1 file changed, 5 deletions(-)

--- a/drivers/net/xen-netfront.c
+++ b/drivers/net/xen-netfront.c
@@ -459,9 +459,6 @@ static void xennet_make_frags(struct sk_
len = skb_frag_size(frag);
offset = frag->page_offset;

- /* Data must not cross a page boundary. */
- BUG_ON(len + offset > PAGE_SIZE<<compound_order(page));
-
/* Skip unused frames from start of page */
page += offset >> PAGE_SHIFT;
offset &= ~PAGE_MASK;
@@ -469,8 +466,6 @@ static void xennet_make_frags(struct sk_
while (len > 0) {
unsigned long bytes;

- BUG_ON(offset >= PAGE_SIZE);
-
bytes = PAGE_SIZE - offset;
if (bytes > len)
bytes = len;

2014-12-14 20:51:17

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 3.10 04/24] i2c: omap: fix NACK and Arbitration Lost irq handling

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

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

From: Alexander Kochetkov <[email protected]>

commit 27caca9d2e01c92b26d0690f065aad093fea01c7 upstream.

commit 1d7afc95946487945cc7f5019b41255b72224b70 (i2c: omap: ack IRQ in parts)
changed the interrupt handler to complete transfers without clearing
XRDY (AL case) and ARDY (NACK case) flags. XRDY or ARDY interrupts will be
fired again. As a result, ISR keep processing transfer after it was already
complete (from the driver code point of view).

A didn't see real impacts of the 1d7afc9, but it is really bad idea to
have ISR running on user data after transfer was complete.

It looks, what 1d7afc9 violate TI specs in what how AL and NACK should be
handled (see Note 1, sprugn4r, Figure 17-31 and Figure 17-32).

According to specs (if I understood correctly), in case of NACK and AL driver
must reset NACK, AL, ARDY, RDR, and RRDY (Master Receive Mode), and
NACK, AL, ARDY, and XDR (Master Transmitter Mode).

All that is done down the code under the if condition:
if (stat & (OMAP_I2C_STAT_ARDY | OMAP_I2C_STAT_NACK | OMAP_I2C_STAT_AL)) ...

The patch restore pre 1d7afc9 logic of handling NACK and AL interrupts, so
no interrupts is fired after ISR informs the rest of driver what transfer
complete.

Note: instead of removing break under NACK case, we could just replace 'break'
with 'continue' and allow NACK transfer to finish using ARDY event. I found
that NACK and ARDY bits usually set together. That case confirm TI wiki:
http://processors.wiki.ti.com/index.php/I2C_Tips#Detecting_and_handling_NACK

In order if someone interested in the event traces for NACK and AL cases,
I sent them to mailing list.

Tested on Beagleboard XM C.

Signed-off-by: Alexander Kochetkov <[email protected]>
Fixes: 1d7afc9 i2c: omap: ack IRQ in parts
Acked-by: Felipe Balbi <[email protected]>
Tested-by: Aaro Koskinen <[email protected]>
Signed-off-by: Wolfram Sang <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/i2c/busses/i2c-omap.c | 2 --
1 file changed, 2 deletions(-)

--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -928,14 +928,12 @@ omap_i2c_isr_thread(int this_irq, void *
if (stat & OMAP_I2C_STAT_NACK) {
err |= OMAP_I2C_STAT_NACK;
omap_i2c_ack_stat(dev, OMAP_I2C_STAT_NACK);
- break;
}

if (stat & OMAP_I2C_STAT_AL) {
dev_err(dev->dev, "Arbitration lost\n");
err |= OMAP_I2C_STAT_AL;
omap_i2c_ack_stat(dev, OMAP_I2C_STAT_AL);
- break;
}

/*

2014-12-14 20:51:24

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 3.10 22/24] ARM: sched_clock: Load cycle count after epoch stabilizes

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

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

From: Stephen Boyd <[email protected]>

commit 336ae1180df5f69b9e0fb6561bec01c5f64361cf upstream.

There is a small race between when the cycle count is read from
the hardware and when the epoch stabilizes. Consider this
scenario:

CPU0 CPU1
---- ----
cyc = read_sched_clock()
cyc_to_sched_clock()
update_sched_clock()
...
cd.epoch_cyc = cyc;
epoch_cyc = cd.epoch_cyc;
...
epoch_ns + cyc_to_ns((cyc - epoch_cyc)

The cyc on cpu0 was read before the epoch changed. But we
calculate the nanoseconds based on the new epoch by subtracting
the new epoch from the old cycle count. Since epoch is most likely
larger than the old cycle count we calculate a large number that
will be converted to nanoseconds and added to epoch_ns, causing
time to jump forward too much.

Fix this problem by reading the hardware after the epoch has
stabilized.

Cc: Russell King <[email protected]>
Signed-off-by: Stephen Boyd <[email protected]>
Signed-off-by: John Stultz <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>


---
arch/arm/kernel/sched_clock.c | 13 +++++--------
1 file changed, 5 insertions(+), 8 deletions(-)

--- a/arch/arm/kernel/sched_clock.c
+++ b/arch/arm/kernel/sched_clock.c
@@ -51,10 +51,11 @@ static inline u64 notrace cyc_to_ns(u64
return (cyc * mult) >> shift;
}

-static unsigned long long notrace cyc_to_sched_clock(u32 cyc, u32 mask)
+static unsigned long long notrace sched_clock_32(void)
{
u64 epoch_ns;
u32 epoch_cyc;
+ u32 cyc;

if (cd.suspended)
return cd.epoch_ns;
@@ -73,7 +74,9 @@ static unsigned long long notrace cyc_to
smp_rmb();
} while (epoch_cyc != cd.epoch_cyc_copy);

- return epoch_ns + cyc_to_ns((cyc - epoch_cyc) & mask, cd.mult, cd.shift);
+ cyc = read_sched_clock();
+ cyc = (cyc - epoch_cyc) & sched_clock_mask;
+ return epoch_ns + cyc_to_ns(cyc, cd.mult, cd.shift);
}

/*
@@ -165,12 +168,6 @@ void __init setup_sched_clock(u32 (*read
pr_debug("Registered %pF as sched_clock source\n", read);
}

-static unsigned long long notrace sched_clock_32(void)
-{
- u32 cyc = read_sched_clock();
- return cyc_to_sched_clock(cyc, sched_clock_mask);
-}
-
unsigned long long __read_mostly (*sched_clock_func)(void) = sched_clock_32;

unsigned long long notrace sched_clock(void)

2014-12-14 20:51:30

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 3.10 21/24] igb: bring link up when PHY is powered up

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

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

From: Todd Fujinaka <[email protected]>

commit aec653c43b0c55667355e26d7de1236bda9fb4e3 upstream.

Call igb_setup_link() when the PHY is powered up.

Signed-off-by: Todd Fujinaka <[email protected]>
Reported-by: Jeff Westfahl <[email protected]>
Tested-by: Aaron Brown <[email protected]>
Signed-off-by: Jeff Kirsher <[email protected]>
Cc: Vincent Donnefort <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/net/ethernet/intel/igb/igb_main.c | 2 ++
1 file changed, 2 insertions(+)

--- a/drivers/net/ethernet/intel/igb/igb_main.c
+++ b/drivers/net/ethernet/intel/igb/igb_main.c
@@ -1584,6 +1584,8 @@ void igb_power_up_link(struct igb_adapte
igb_power_up_phy_copper(&adapter->hw);
else
igb_power_up_serdes_link_82575(&adapter->hw);
+
+ igb_setup_link(&adapter->hw);
}

/**

2014-12-14 20:51:34

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 3.10 20/24] ext2: Fix oops in ext2_get_block() called from ext2_quota_write()

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

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

From: Jan Kara <[email protected]>

commit df4e7ac0bb70abc97fbfd9ef09671fc084b3f9db upstream.

ext2_quota_write() doesn't properly setup bh it passes to
ext2_get_block() and thus we hit assertion BUG_ON(maxblocks == 0) in
ext2_get_blocks() (or we could actually ask for mapping arbitrary number
of blocks depending on whatever value was on stack).

Fix ext2_quota_write() to properly fill in number of blocks to map.

Reviewed-by: "Theodore Ts'o" <[email protected]>
Reviewed-by: Christoph Hellwig <[email protected]>
Reported-by: Christoph Hellwig <[email protected]>
Signed-off-by: Jan Kara <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
fs/ext2/super.c | 1 +
1 file changed, 1 insertion(+)

--- a/fs/ext2/super.c
+++ b/fs/ext2/super.c
@@ -1493,6 +1493,7 @@ static ssize_t ext2_quota_write(struct s
sb->s_blocksize - offset : towrite;

tmp_bh.b_state = 0;
+ tmp_bh.b_size = sb->s_blocksize;
err = ext2_get_block(inode, blk, &tmp_bh, 1);
if (err < 0)
goto out;

2014-12-14 20:51:38

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 3.10 02/24] mm: fix swapoff hang after page migration and fork

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

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

From: Hugh Dickins <[email protected]>

commit 2022b4d18a491a578218ce7a4eca8666db895a73 upstream.

I've been seeing swapoff hangs in recent testing: it's cycling around
trying unsuccessfully to find an mm for some remaining pages of swap.

I have been exercising swap and page migration more heavily recently,
and now notice a long-standing error in copy_one_pte(): it's trying to
add dst_mm to swapoff's mmlist when it finds a swap entry, but is doing
so even when it's a migration entry or an hwpoison entry.

Which wouldn't matter much, except it adds dst_mm next to src_mm,
assuming src_mm is already on the mmlist: which may not be so. Then if
pages are later swapped out from dst_mm, swapoff won't be able to find
where to replace them.

There's already a !non_swap_entry() test for stats: move that up before
the swap_duplicate() and the addition to mmlist.

Signed-off-by: Hugh Dickins <[email protected]>
Cc: Kelley Nielsen <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
mm/memory.c | 24 ++++++++++++------------
1 file changed, 12 insertions(+), 12 deletions(-)

--- a/mm/memory.c
+++ b/mm/memory.c
@@ -834,20 +834,20 @@ copy_one_pte(struct mm_struct *dst_mm, s
if (!pte_file(pte)) {
swp_entry_t entry = pte_to_swp_entry(pte);

- if (swap_duplicate(entry) < 0)
- return entry.val;
+ if (likely(!non_swap_entry(entry))) {
+ if (swap_duplicate(entry) < 0)
+ return entry.val;

- /* make sure dst_mm is on swapoff's mmlist. */
- if (unlikely(list_empty(&dst_mm->mmlist))) {
- spin_lock(&mmlist_lock);
- if (list_empty(&dst_mm->mmlist))
- list_add(&dst_mm->mmlist,
- &src_mm->mmlist);
- spin_unlock(&mmlist_lock);
- }
- if (likely(!non_swap_entry(entry)))
+ /* make sure dst_mm is on swapoff's mmlist. */
+ if (unlikely(list_empty(&dst_mm->mmlist))) {
+ spin_lock(&mmlist_lock);
+ if (list_empty(&dst_mm->mmlist))
+ list_add(&dst_mm->mmlist,
+ &src_mm->mmlist);
+ spin_unlock(&mmlist_lock);
+ }
rss[MM_SWAPENTS]++;
- else if (is_migration_entry(entry)) {
+ } else if (is_migration_entry(entry)) {
page = migration_entry_to_page(entry);

if (PageAnon(page))

2014-12-15 03:29:36

by Guenter Roeck

[permalink] [raw]
Subject: Re: [PATCH 3.10 00/24] 3.10.63-stable review

On 12/14/2014 12:20 PM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 3.10.63 release.
> There are 24 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 Tue Dec 16 20:17:48 UTC 2014.
> Anything received after that time might be too late.
>

Build results:
total: 137 pass: 137 fail: 0

Qemu tests:
total: 27 pass: 27 fail: 0

Details are available at http://server.roeck-us.net:8010/builders.

Guenter

2014-12-15 09:36:12

by Paolo Bonzini

[permalink] [raw]
Subject: Re: [PATCH 3.10 19/24] nEPT: Nested INVEPT



On 14/12/2014 21:20, Greg Kroah-Hartman wrote:
> 3.10-stable review patch. If anyone has any objections, please let me know.
>
> ------------------
>
> From: Nadav Har'El <[email protected]>
>
> commit bfd0a56b90005f8c8a004baf407ad90045c2b11e upstream.
>
> If we let L1 use EPT, we should probably also support the INVEPT instruction.
>
> In our current nested EPT implementation, when L1 changes its EPT table
> for L2 (i.e., EPT12), L0 modifies the shadow EPT table (EPT02), and in
> the course of this modification already calls INVEPT. But if last level
> of shadow page is unsync not all L1's changes to EPT12 are intercepted,
> which means roots need to be synced when L1 calls INVEPT. Global INVEPT
> should not be different since roots are synced by kvm_mmu_load() each
> time EPTP02 changes.
>
> Reviewed-by: Xiao Guangrong <[email protected]>
> Signed-off-by: Nadav Har'El <[email protected]>
> Signed-off-by: Jun Nakajima <[email protected]>
> Signed-off-by: Xinhao Xu <[email protected]>
> Signed-off-by: Yang Zhang <[email protected]>
> Signed-off-by: Gleb Natapov <[email protected]>
> Signed-off-by: Paolo Bonzini <[email protected]>
> [bwh: Backported to 3.2:
> - Adjust context, filename
> - Simplify handle_invept() as recommended by Paolo - nEPT is not
> supported so we always raise #UD]
> Signed-off-by: Ben Hutchings <[email protected]>
> Cc: Vinson Lee <[email protected]>
> Signed-off-by: Greg Kroah-Hartman <[email protected]>
>
> ---
> arch/x86/include/uapi/asm/vmx.h | 1 +
> arch/x86/kvm/vmx.c | 8 ++++++++
> 2 files changed, 9 insertions(+)
>
> --- a/arch/x86/include/uapi/asm/vmx.h
> +++ b/arch/x86/include/uapi/asm/vmx.h
> @@ -65,6 +65,7 @@
> #define EXIT_REASON_EOI_INDUCED 45
> #define EXIT_REASON_EPT_VIOLATION 48
> #define EXIT_REASON_EPT_MISCONFIG 49
> +#define EXIT_REASON_INVEPT 50
> #define EXIT_REASON_PREEMPTION_TIMER 52
> #define EXIT_REASON_WBINVD 54
> #define EXIT_REASON_XSETBV 55
> --- a/arch/x86/kvm/vmx.c
> +++ b/arch/x86/kvm/vmx.c
> @@ -6242,6 +6242,12 @@ static int handle_vmptrst(struct kvm_vcp
> return 1;
> }
>
> +static int handle_invept(struct kvm_vcpu *vcpu)
> +{
> + kvm_queue_exception(vcpu, UD_VECTOR);
> + return 1;
> +}
> +
> /*
> * The exit handlers return 1 if the exit was handled fully and guest execution
> * may resume. Otherwise they set the kvm_run parameter to indicate what needs
> @@ -6286,6 +6292,7 @@ static int (*const kvm_vmx_exit_handlers
> [EXIT_REASON_PAUSE_INSTRUCTION] = handle_pause,
> [EXIT_REASON_MWAIT_INSTRUCTION] = handle_invalid_op,
> [EXIT_REASON_MONITOR_INSTRUCTION] = handle_invalid_op,
> + [EXIT_REASON_INVEPT] = handle_invept,
> };
>
> static const int kvm_vmx_max_exit_handlers =
> @@ -6512,6 +6519,7 @@ static bool nested_vmx_exit_handled(stru
> case EXIT_REASON_VMPTRST: case EXIT_REASON_VMREAD:
> case EXIT_REASON_VMRESUME: case EXIT_REASON_VMWRITE:
> case EXIT_REASON_VMOFF: case EXIT_REASON_VMON:
> + case EXIT_REASON_INVEPT:
> /*
> * VMX instructions trap unconditionally. This allows L1 to
> * emulate them for its L2 guest, i.e., allows 3-level nesting!
>
>

Reviewed-by: Paolo Bonzini <[email protected]>

Thanks Greg.

Paolo

2014-12-16 03:06:46

by Shuah Khan

[permalink] [raw]
Subject: Re: [PATCH 3.10 00/24] 3.10.63-stable review

On 12/14/2014 01:20 PM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 3.10.63 release.
> There are 24 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 Tue Dec 16 20:17:48 UTC 2014.
> 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/v3.0/stable-review/patch-3.10.63-rc1.gz
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
>

Compiled and booted on my test system. No dmesg regressions.

-- Shuah


--
Shuah Khan
Sr. Linux Kernel Developer
Samsung Open Source Group
Samsung Research America (Silicon Valley)
[email protected] | (970) 217-8978