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

Groups > linux.kernel > #1366649 > unrolled thread

[PATCH 3.2 00/62] 3.2.79-rc1 review

Back to article view | Back to linux.kernel

Contents

  [PATCH 3.2 00/62] 3.2.79-rc1 review Ben Hutchings <ben@decadent.org.uk> - 2016-03-29 22:20 +0200
    [PATCH 3.2 27/62] USB: option: add support for SIM7100E Ben Hutchings <ben@decadent.org.uk> - 2016-03-29 22:20 +0200
    [PATCH 3.2 13/62] xen/pciback: Check PF instead of VF for  PCI_COMMAND_MEMORY Ben Hutchings <ben@decadent.org.uk> - 2016-03-29 22:20 +0200
    [PATCH 3.2 12/62] libata: fix HDIO_GET_32BIT ioctl Ben Hutchings <ben@decadent.org.uk> - 2016-03-29 22:20 +0200
    [PATCH 3.2 52/62] ALSA: seq: oss: Don't drain at closing a client Ben Hutchings <ben@decadent.org.uk> - 2016-03-29 22:20 +0200
    [PATCH 3.2 41/62] ipr: Fix out-of-bounds null overwrite Ben Hutchings <ben@decadent.org.uk> - 2016-03-29 22:20 +0200
    [PATCH 3.2 20/62] af_unix: Don't set err in unix_stream_read_generic  unless there was an error Ben Hutchings <ben@decadent.org.uk> - 2016-03-29 22:20 +0200
    [PATCH 3.2 21/62] af_unix: Guard against other == sk in  unix_dgram_sendmsg Ben Hutchings <ben@decadent.org.uk> - 2016-03-29 22:20 +0200
    [PATCH 3.2 35/62] sunrpc/cache: fix off-by-one in qword_get() Ben Hutchings <ben@decadent.org.uk> - 2016-03-29 22:20 +0200
    [PATCH 3.2 42/62] ipr: Fix regression when loading firmware Ben Hutchings <ben@decadent.org.uk> - 2016-03-29 22:20 +0200
    [PATCH 3.2 15/62] xen/pcifront: Fix mysterious crashes when NUMA  locality information was extracted. Ben Hutchings <ben@decadent.org.uk> - 2016-03-29 22:20 +0200
    [PATCH 3.2 50/62] ASoC: wm8994: Fix enum ctl accesses in a wrong type Ben Hutchings <ben@decadent.org.uk> - 2016-03-29 22:20 +0200
    [PATCH 3.2 49/62] ASoC: wm8958: Fix enum ctl accesses in a wrong type Ben Hutchings <ben@decadent.org.uk> - 2016-03-29 22:20 +0200
    [PATCH 3.2 57/62] ubi: Fix out of bounds write in volume update code Ben Hutchings <ben@decadent.org.uk> - 2016-03-29 22:30 +0200
    [PATCH 3.2 03/62] iommu/vt-d: Fix 64-bit accesses to 32-bit  DMAR_GSTS_REG Ben Hutchings <ben@decadent.org.uk> - 2016-03-29 22:30 +0200
    [PATCH 3.2 45/62] ALSA: timer: Fix broken compat timer user  status ioctl Ben Hutchings <ben@decadent.org.uk> - 2016-03-29 22:30 +0200
    [PATCH 3.2 05/62] cfg80211/wext: fix message ordering Ben Hutchings <ben@decadent.org.uk> - 2016-03-29 22:30 +0200
    [PATCH 3.2 14/62] xen/pciback: Save the number of MSI-X entries  to be copied later. Ben Hutchings <ben@decadent.org.uk> - 2016-03-29 22:30 +0200
    [PATCH 3.2 18/62] tracing: Fix freak link error caused by branch  tracer Ben Hutchings <ben@decadent.org.uk> - 2016-03-29 22:30 +0200
    [PATCH 3.2 16/62] ALSA: seq: Fix leak of pool buffer at  concurrent writes Ben Hutchings <ben@decadent.org.uk> - 2016-03-29 22:30 +0200
    [PATCH 3.2 62/62] HID: usbhid: fix recursive deadlock Ben Hutchings <ben@decadent.org.uk> - 2016-03-29 22:30 +0200
    [PATCH 3.2 08/62] drm/i915: fix error path in intel_setup_gmbus() Ben Hutchings <ben@decadent.org.uk> - 2016-03-29 22:30 +0200
    [PATCH 3.2 19/62] ALSA: seq: Fix double port list deletion Ben Hutchings <ben@decadent.org.uk> - 2016-03-29 22:30 +0200
    [PATCH 3.2 58/62] Revert "drm/radeon: call hpd_irq_event on resume" Ben Hutchings <ben@decadent.org.uk> - 2016-03-29 22:30 +0200
    [PATCH 3.2 10/62] s390/dasd: prevent incorrect length error under  z/VM after PAV changes Ben Hutchings <ben@decadent.org.uk> - 2016-03-29 22:30 +0200
    [PATCH 3.2 07/62] nfs: fix nfs_size_to_loff_t Ben Hutchings <ben@decadent.org.uk> - 2016-03-29 22:30 +0200
    [PATCH 3.2 04/62] wext: fix message delay/ordering Ben Hutchings <ben@decadent.org.uk> - 2016-03-29 22:30 +0200
    [PATCH 3.2 06/62] mac80211: fix use of uninitialised values in RX  aggregation Ben Hutchings <ben@decadent.org.uk> - 2016-03-29 22:30 +0200
    [PATCH 3.2 46/62] ALSA: hdspm: Fix wrong boolean ctl value accesses Ben Hutchings <ben@decadent.org.uk> - 2016-03-29 22:30 +0200
    [PATCH 3.2 01/62] Revert "crypto: algif_skcipher - Do not  dereference ctx without socket lock" Ben Hutchings <ben@decadent.org.uk> - 2016-03-29 22:30 +0200
    [PATCH 3.2 17/62] tracepoints: Do not trace when cpu is offline Ben Hutchings <ben@decadent.org.uk> - 2016-03-29 22:30 +0200
    Re: [PATCH 3.2 00/62] 3.2.79-rc1 review Guenter Roeck <linux@roeck-us.net> - 2016-03-29 22:30 +0200
      Re: [PATCH 3.2 00/62] 3.2.79-rc1 review Ben Hutchings <ben@decadent.org.uk> - 2016-03-29 23:10 +0200
    [PATCH 3.2 02/62] crypto: {blk,giv}cipher: Set has_setkey Ben Hutchings <ben@decadent.org.uk> - 2016-03-29 22:30 +0200

Page 2 of 2 — ← Prev page 1 [2]

#1366673 — [PATCH 3.2 62/62] HID: usbhid: fix recursive deadlock

3.2.79-rc1 review patch.  If anyone has any objections, please let me know.

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

From: Ioan-Adrian Ratiu <adi@adirat.com>

commit e470127e9606b1fa151c4184243e61296d1e0c0f upstream.

The critical section protected by usbhid->lock in hid_ctrl() is too
big and because of this it causes a recursive deadlock. "Too big" means
the case statement and the call to hid_input_report() do not need to be
protected by the spinlock (no URB operations are done inside them).

The deadlock happens because in certain rare cases drivers try to grab
the lock while handling the ctrl irq which grabs the lock before them
as described above. For example newer wacom tablets like 056a:033c try
to reschedule proximity reads from wacom_intuos_schedule_prox_event()
calling hid_hw_request() -> usbhid_request() -> usbhid_submit_report()
which tries to grab the usbhid lock already held by hid_ctrl().

There are two ways to get out of this deadlock:
    1. Make the drivers work "around" the ctrl critical region, in the
    wacom case for ex. by delaying the scheduling of the proximity read
    request itself to a workqueue.
    2. Shrink the critical region so the usbhid lock protects only the
    instructions which modify usbhid state, calling hid_input_report()
    with the spinlock unlocked, allowing the device driver to grab the
    lock first, finish and then grab the lock afterwards in hid_ctrl().

This patch implements the 2nd solution.

Signed-off-by: Ioan-Adrian Ratiu <adi@adirat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
[bwh: Backported to 3.2: adjust context]
Cc: Jason Gerecke <jason.gerecke@wacom.com>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
---
 drivers/hid/usbhid/hid-core.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

--- a/drivers/hid/usbhid/hid-core.c
+++ b/drivers/hid/usbhid/hid-core.c
@@ -448,8 +448,6 @@ static void hid_ctrl(struct urb *urb)
 	struct usbhid_device *usbhid = hid->driver_data;
 	int unplug = 0, status = urb->status;
 
-	spin_lock(&usbhid->lock);
-
 	switch (status) {
 	case 0:			/* success */
 		if (usbhid->ctrl[usbhid->ctrltail].dir == USB_DIR_IN)
@@ -469,6 +467,8 @@ static void hid_ctrl(struct urb *urb)
 		hid_warn(urb->dev, "ctrl urb status %d received\n", status);
 	}
 
+	spin_lock(&usbhid->lock);
+
 	if (unplug)
 		usbhid->ctrltail = usbhid->ctrlhead;
 	else

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

#1366674 — [PATCH 3.2 08/62] drm/i915: fix error path in intel_setup_gmbus()

3.2.79-rc1 review patch.  If anyone has any objections, please let me know.

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

From: Rasmus Villemoes <linux@rasmusvillemoes.dk>

commit ed3f9fd1e865975ceefdb2a43b453e090b1fd787 upstream.

This fails to undo the setup for pin==0; moreover, something
interesting happens if the setup failed already at pin==0.

Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Fixes: f899fc64cda8 ("drm/i915: use GMBUS to manage i2c links")
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1455048677-19882-3-git-send-email-linux@rasmusvillemoes.dk
(cherry picked from commit 2417c8c03f508841b85bf61acc91836b7b0e2560)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
[bwh: Backported to 3.2: index variable is i, not pin]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
---
 drivers/gpu/drm/i915/intel_i2c.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/gpu/drm/i915/intel_i2c.c
+++ b/drivers/gpu/drm/i915/intel_i2c.c
@@ -410,7 +410,7 @@ int intel_setup_gmbus(struct drm_device
 	return 0;
 
 err:
-	while (--i) {
+	while (i--) {
 		struct intel_gmbus *bus = &dev_priv->gmbus[i];
 		i2c_del_adapter(&bus->adapter);
 	}

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

#1366675 — [PATCH 3.2 19/62] ALSA: seq: Fix double port list deletion

3.2.79-rc1 review patch.  If anyone has any objections, please let me know.

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

From: Takashi Iwai <tiwai@suse.de>

commit 13d5e5d4725c64ec06040d636832e78453f477b7 upstream.

The commit [7f0973e973cd: ALSA: seq: Fix lockdep warnings due to
double mutex locks] split the management of two linked lists (source
and destination) into two individual calls for avoiding the AB/BA
deadlock.  However, this may leave the possible double deletion of one
of two lists when the counterpart is being deleted concurrently.
It ends up with a list corruption, as revealed by syzkaller fuzzer.

This patch fixes it by checking the list emptiness and skipping the
deletion and the following process.

BugLink: http://lkml.kernel.org/r/CACT4Y+bay9qsrz6dQu31EcGaH9XwfW7o3oBzSQUG9fMszoh=Sg@mail.gmail.com
Fixes: 7f0973e973cd ('ALSA: seq: Fix lockdep warnings due to 'double mutex locks)
Reported-by: Dmitry Vyukov <dvyukov@google.com>
Tested-by: Dmitry Vyukov <dvyukov@google.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
---
 sound/core/seq/seq_ports.c | 13 ++++++++-----
 1 file changed, 8 insertions(+), 5 deletions(-)

--- a/sound/core/seq/seq_ports.c
+++ b/sound/core/seq/seq_ports.c
@@ -540,19 +540,22 @@ static void delete_and_unsubscribe_port(
 					bool is_src, bool ack)
 {
 	struct snd_seq_port_subs_info *grp;
+	struct list_head *list;
+	bool empty;
 
 	grp = is_src ? &port->c_src : &port->c_dest;
+	list = is_src ? &subs->src_list : &subs->dest_list;
 	down_write(&grp->list_mutex);
 	write_lock_irq(&grp->list_lock);
-	if (is_src)
-		list_del(&subs->src_list);
-	else
-		list_del(&subs->dest_list);
+	empty = list_empty(list);
+	if (!empty)
+		list_del_init(list);
 	grp->exclusive = 0;
 	write_unlock_irq(&grp->list_lock);
 	up_write(&grp->list_mutex);
 
-	unsubscribe_port(client, port, grp, &subs->info, ack);
+	if (!empty)
+		unsubscribe_port(client, port, grp, &subs->info, ack);
 }
 
 /* connect two ports */

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

#1366676 — [PATCH 3.2 58/62] Revert "drm/radeon: call hpd_irq_event on resume"

3.2.79-rc1 review patch.  If anyone has any objections, please let me know.

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

From: Linus Torvalds <torvalds@linux-foundation.org>

commit 256faedcfd646161477d47a1a78c32a562d2e845 upstream.

This reverts commit dbb17a21c131eca94eb31136eee9a7fe5aff00d9.

It turns out that commit can cause problems for systems with multiple
GPUs, and causes X to hang on at least a HP Pavilion dv7 with hybrid
graphics.

This got noticed originally in 4.4.4, where this patch had already
gotten back-ported, but 4.5-rc7 was verified to have the same problem.

Alexander Deucher says:
 "It looks like you have a muxed system so I suspect what's happening is
  that one of the display is being reported as connected for both the
  IGP and the dGPU and then the desktop environment gets confused or
  there some sort problem in the detect functions since the mux is not
  switched to the dGPU.  I don't see an easy fix unless Dave has any
  ideas.  I'd say just revert for now"

Reported-by: Jörg-Volker Peetz <jvpeetz@web.de>
Acked-by: Alexander Deucher <Alexander.Deucher@amd.com>
Cc: Dave Airlie <airlied@gmail.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
---
 drivers/gpu/drm/radeon/radeon_device.c | 1 -
 1 file changed, 1 deletion(-)

--- a/drivers/gpu/drm/radeon/radeon_device.c
+++ b/drivers/gpu/drm/radeon/radeon_device.c
@@ -960,7 +960,6 @@ int radeon_resume_kms(struct drm_device
 	}
 
 	drm_kms_helper_poll_enable(dev);
-	drm_helper_hpd_irq_event(dev);
 	return 0;
 }
 

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

#1366677 — [PATCH 3.2 10/62] s390/dasd: prevent incorrect length error under z/VM after PAV changes

3.2.79-rc1 review patch.  If anyone has any objections, please let me know.

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

From: Stefan Haberland <stefan.haberland@de.ibm.com>

commit 020bf042e5b397479c1174081b935d0ff15d1a64 upstream.

The channel checks the specified length and the provided amount of
data for CCWs and provides an incorrect length error if the size does
not match. Under z/VM with simulation activated the length may get
changed. Having the suppress length indication bit set is stated as
good CCW coding practice and avoids errors under z/VM.

Signed-off-by: Stefan Haberland <stefan.haberland@de.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
---
 drivers/s390/block/dasd_alias.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/s390/block/dasd_alias.c
+++ b/drivers/s390/block/dasd_alias.c
@@ -749,7 +749,7 @@ static int reset_summary_unit_check(stru
 	ASCEBC((char *) &cqr->magic, 4);
 	ccw = cqr->cpaddr;
 	ccw->cmd_code = DASD_ECKD_CCW_RSCK;
-	ccw->flags = 0 ;
+	ccw->flags = CCW_FLAG_SLI;
 	ccw->count = 16;
 	ccw->cda = (__u32)(addr_t) cqr->data;
 	((char *)cqr->data)[0] = reason;

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

#1366678 — [PATCH 3.2 07/62] nfs: fix nfs_size_to_loff_t

3.2.79-rc1 review patch.  If anyone has any objections, please let me know.

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

From: Christoph Hellwig <hch@lst.de>

commit 50ab8ec74a153eb30db26529088bc57dd700b24c upstream.

See http: //www.infradead.org/rpr.html
X-Evolution-Source: 1451162204.2173.11@leira.trondhjem.org
Content-Transfer-Encoding: 8bit
Mime-Version: 1.0

We support OFFSET_MAX just fine, so don't round down below it.  Also
switch to using min_t to make the helper more readable.

Signed-off-by: Christoph Hellwig <hch@lst.de>
Fixes: 433c92379d9c ("NFS: Clean up nfs_size_to_loff_t()")
Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
---
 include/linux/nfs_fs.h | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

--- a/include/linux/nfs_fs.h
+++ b/include/linux/nfs_fs.h
@@ -588,9 +588,7 @@ static inline void nfs3_forget_cached_ac
 
 static inline loff_t nfs_size_to_loff_t(__u64 size)
 {
-	if (size > (__u64) OFFSET_MAX - 1)
-		return OFFSET_MAX - 1;
-	return (loff_t) size;
+	return min_t(u64, size, OFFSET_MAX);
 }
 
 static inline ino_t

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

#1366679 — [PATCH 3.2 04/62] wext: fix message delay/ordering

3.2.79-rc1 review patch.  If anyone has any objections, please let me know.

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

From: Johannes Berg <johannes.berg@intel.com>

commit 8bf862739a7786ae72409220914df960a0aa80d8 upstream.

Beniamino reported that he was getting an RTM_NEWLINK message for a
given interface, after the RTM_DELLINK for it. It turns out that the
message is a wireless extensions message, which was sent because the
interface had been connected and disconnection while it was deleted
caused a wext message.

For its netlink messages, wext uses RTM_NEWLINK, but the message is
without all the regular rtnetlink attributes, so "ip monitor link"
prints just rudimentary information:

5: wlan1: <BROADCAST,MULTICAST> mtu 1500 qdisc mq state DOWN group default
    link/ether 02:00:00:00:01:00 brd ff:ff:ff:ff:ff:ff
Deleted 5: wlan1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default
    link/ether 02:00:00:00:01:00 brd ff:ff:ff:ff:ff:ff
5: wlan1: <BROADCAST,MULTICAST,UP>
    link/ether
(from my hwsim reproduction)

This can cause userspace to get confused since it doesn't expect an
RTM_NEWLINK message after RTM_DELLINK.

The reason for this is that wext schedules a worker to send out the
messages, and the scheduling delay can cause the messages to get out
to userspace in different order.

To fix this, have wext register a netdevice notifier and flush out
any pending messages when netdevice state changes. This fixes any
ordering whenever the original message wasn't sent by a notifier
itself.

Reported-by: Beniamino Galvani <bgalvani@redhat.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
---
 net/wireless/wext-core.c | 51 +++++++++++++++++++++++++++++++++++++-----------
 1 file changed, 40 insertions(+), 11 deletions(-)

--- a/net/wireless/wext-core.c
+++ b/net/wireless/wext-core.c
@@ -342,6 +342,39 @@ static const int compat_event_type_size[
 
 /* IW event code */
 
+static void wireless_nlevent_flush(void)
+{
+	struct sk_buff *skb;
+	struct net *net;
+
+	ASSERT_RTNL();
+
+	for_each_net(net) {
+		while ((skb = skb_dequeue(&net->wext_nlevents)))
+			rtnl_notify(skb, net, 0, RTNLGRP_LINK, NULL,
+				    GFP_KERNEL);
+	}
+}
+
+static int wext_netdev_notifier_call(struct notifier_block *nb,
+				     unsigned long state, void *ptr)
+{
+	/*
+	 * When a netdev changes state in any way, flush all pending messages
+	 * to avoid them going out in a strange order, e.g. RTM_NEWLINK after
+	 * RTM_DELLINK, or with IFF_UP after without IFF_UP during dev_close()
+	 * or similar - all of which could otherwise happen due to delays from
+	 * schedule_work().
+	 */
+	wireless_nlevent_flush();
+
+	return NOTIFY_OK;
+}
+
+static struct notifier_block wext_netdev_notifier = {
+	.notifier_call = wext_netdev_notifier_call,
+};
+
 static int __net_init wext_pernet_init(struct net *net)
 {
 	skb_queue_head_init(&net->wext_nlevents);
@@ -360,7 +393,12 @@ static struct pernet_operations wext_per
 
 static int __init wireless_nlevent_init(void)
 {
-	return register_pernet_subsys(&wext_pernet_ops);
+	int err = register_pernet_subsys(&wext_pernet_ops);
+
+	if (err)
+		return err;
+
+	return register_netdevice_notifier(&wext_netdev_notifier);
 }
 
 subsys_initcall(wireless_nlevent_init);
@@ -368,17 +406,8 @@ subsys_initcall(wireless_nlevent_init);
 /* Process events generated by the wireless layer or the driver. */
 static void wireless_nlevent_process(struct work_struct *work)
 {
-	struct sk_buff *skb;
-	struct net *net;
-
 	rtnl_lock();
-
-	for_each_net(net) {
-		while ((skb = skb_dequeue(&net->wext_nlevents)))
-			rtnl_notify(skb, net, 0, RTNLGRP_LINK, NULL,
-				    GFP_KERNEL);
-	}
-
+	wireless_nlevent_flush();
 	rtnl_unlock();
 }
 

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

#1366680 — [PATCH 3.2 06/62] mac80211: fix use of uninitialised values in RX aggregation

3.2.79-rc1 review patch.  If anyone has any objections, please let me know.

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

From: Chris Bainbridge <chris.bainbridge@gmail.com>

commit f39ea2690bd61efec97622c48323f40ed6e16317 upstream.

Use kzalloc instead of kmalloc for struct tid_ampdu_rx to
initialize the "removed" field (all others are initialized
manually). That fixes:

UBSAN: Undefined behaviour in net/mac80211/rx.c:932:29
load of value 2 is not a valid value for type '_Bool'
CPU: 3 PID: 1134 Comm: kworker/u16:7 Not tainted 4.5.0-rc1+ #265
Workqueue: phy0 rt2x00usb_work_rxdone
 0000000000000004 ffff880254a7ba50 ffffffff8181d866 0000000000000007
 ffff880254a7ba78 ffff880254a7ba68 ffffffff8188422d ffffffff8379b500
 ffff880254a7bab8 ffffffff81884747 0000000000000202 0000000348620032
Call Trace:
 [<ffffffff8181d866>] dump_stack+0x45/0x5f
 [<ffffffff8188422d>] ubsan_epilogue+0xd/0x40
 [<ffffffff81884747>] __ubsan_handle_load_invalid_value+0x67/0x70
 [<ffffffff82227b4d>] ieee80211_sta_reorder_release.isra.16+0x5ed/0x730
 [<ffffffff8222ca14>] ieee80211_prepare_and_rx_handle+0xd04/0x1c00
 [<ffffffff8222db03>] __ieee80211_rx_handle_packet+0x1f3/0x750
 [<ffffffff8222e4a7>] ieee80211_rx_napi+0x447/0x990

While at it, convert to use sizeof(*tid_agg_rx) instead.

Fixes: 788211d81bfdf ("mac80211: fix RX A-MPDU session reorder timer deletion")
Signed-off-by: Chris Bainbridge <chris.bainbridge@gmail.com>
[reword commit message, use sizeof(*tid_agg_rx)]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
---
 net/mac80211/agg-rx.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/net/mac80211/agg-rx.c
+++ b/net/mac80211/agg-rx.c
@@ -280,7 +280,7 @@ void ieee80211_process_addba_request(str
 	}
 
 	/* prepare A-MPDU MLME for Rx aggregation */
-	tid_agg_rx = kmalloc(sizeof(struct tid_ampdu_rx), GFP_KERNEL);
+	tid_agg_rx = kzalloc(sizeof(*tid_agg_rx), GFP_KERNEL);
 	if (!tid_agg_rx)
 		goto end;
 

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

#1366682 — [PATCH 3.2 46/62] ALSA: hdspm: Fix wrong boolean ctl value accesses

3.2.79-rc1 review patch.  If anyone has any objections, please let me know.

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

From: Takashi Iwai <tiwai@suse.de>

commit 537e48136295c5860a92138c5ea3959b9542868b upstream.

snd-hdspm driver accesses enum item values (int) instead of boolean
values (long) wrongly for some ctl elements.  This patch fixes them.

Signed-off-by: Takashi Iwai <tiwai@suse.de>
[bwh: Backported to 3.2: drop change to snd_hdspm_put_system_sample_rate()]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
---
--- a/sound/pci/rme9652/hdspm.c
+++ b/sound/pci/rme9652/hdspm.c
@@ -4386,7 +4386,7 @@ static int snd_hdspm_get_tco_word_term(s
 {
 	struct hdspm *hdspm = snd_kcontrol_chip(kcontrol);
 
-	ucontrol->value.enumerated.item[0] = hdspm->tco->term;
+	ucontrol->value.integer.value[0] = hdspm->tco->term;
 
 	return 0;
 }
@@ -4397,8 +4397,8 @@ static int snd_hdspm_put_tco_word_term(s
 {
 	struct hdspm *hdspm = snd_kcontrol_chip(kcontrol);
 
-	if (hdspm->tco->term != ucontrol->value.enumerated.item[0]) {
-		hdspm->tco->term = ucontrol->value.enumerated.item[0];
+	if (hdspm->tco->term != ucontrol->value.integer.value[0]) {
+		hdspm->tco->term = ucontrol->value.integer.value[0];
 
 		hdspm_tco_write(hdspm);
 

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

#1366684 — [PATCH 3.2 01/62] Revert "crypto: algif_skcipher - Do not dereference ctx without socket lock"

3.2.79-rc1 review patch.  If anyone has any objections, please let me know.

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

From: Ben Hutchings <ben@decadent.org.uk>

This reverts commit c54ddfbb1b691d77c52b76ca6e13ca7082eb3b82, which
was a poorly backported version of commit
6454c2b83f719057069777132b13949e4c6b6350 upstream.  The small part I
was able to backport makes no sense by itself.

Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
---
 crypto/algif_skcipher.c | 5 +----
 1 file changed, 1 insertion(+), 4 deletions(-)

--- a/crypto/algif_skcipher.c
+++ b/crypto/algif_skcipher.c
@@ -249,11 +249,8 @@ static int skcipher_sendmsg(struct kiocb
 {
 	struct sock *sk = sock->sk;
 	struct alg_sock *ask = alg_sk(sk);
-	struct sock *psk = ask->parent;
-	struct alg_sock *pask = alg_sk(psk);
 	struct skcipher_ctx *ctx = ask->private;
-	struct ablkcipher_tfm *skc = pask->private;
-	struct crypto_ablkcipher *tfm = skc->base;
+	struct crypto_ablkcipher *tfm = crypto_ablkcipher_reqtfm(&ctx->req);
 	unsigned ivsize = crypto_ablkcipher_ivsize(tfm);
 	struct skcipher_sg_list *sgl;
 	struct af_alg_control con = {};

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

#1366685 — [PATCH 3.2 17/62] tracepoints: Do not trace when cpu is offline

3.2.79-rc1 review patch.  If anyone has any objections, please let me know.

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

From: "Steven Rostedt (Red Hat)" <rostedt@goodmis.org>

commit f37755490fe9bf76f6ba1d8c6591745d3574a6a6 upstream.

The tracepoint infrastructure uses RCU sched protection to enable and
disable tracepoints safely. There are some instances where tracepoints are
used in infrastructure code (like kfree()) that get called after a CPU is
going offline, and perhaps when it is coming back online but hasn't been
registered yet.

This can probuce the following warning:

 [ INFO: suspicious RCU usage. ]
 4.4.0-00006-g0fe53e8-dirty #34 Tainted: G S
 -------------------------------
 include/trace/events/kmem.h:141 suspicious rcu_dereference_check() usage!

 other info that might help us debug this:

 RCU used illegally from offline CPU!  rcu_scheduler_active = 1, debug_locks = 1
 no locks held by swapper/8/0.

 stack backtrace:
  CPU: 8 PID: 0 Comm: swapper/8 Tainted: G S              4.4.0-00006-g0fe53e8-dirty #34
  Call Trace:
  [c0000005b76c78d0] [c0000000008b9540] .dump_stack+0x98/0xd4 (unreliable)
  [c0000005b76c7950] [c00000000010c898] .lockdep_rcu_suspicious+0x108/0x170
  [c0000005b76c79e0] [c00000000029adc0] .kfree+0x390/0x440
  [c0000005b76c7a80] [c000000000055f74] .destroy_context+0x44/0x100
  [c0000005b76c7b00] [c0000000000934a0] .__mmdrop+0x60/0x150
  [c0000005b76c7b90] [c0000000000e3ff0] .idle_task_exit+0x130/0x140
  [c0000005b76c7c20] [c000000000075804] .pseries_mach_cpu_die+0x64/0x310
  [c0000005b76c7cd0] [c000000000043e7c] .cpu_die+0x3c/0x60
  [c0000005b76c7d40] [c0000000000188d8] .arch_cpu_idle_dead+0x28/0x40
  [c0000005b76c7db0] [c000000000101e6c] .cpu_startup_entry+0x50c/0x560
  [c0000005b76c7ed0] [c000000000043bd8] .start_secondary+0x328/0x360
  [c0000005b76c7f90] [c000000000008a6c] start_secondary_prolog+0x10/0x14

This warning is not a false positive either. RCU is not protecting code that
is being executed while the CPU is offline.

Instead of playing "whack-a-mole(TM)" and adding conditional statements to
the tracepoints we find that are used in this instance, simply add a
cpu_online() test to the tracepoint code where the tracepoint will be
ignored if the CPU is offline.

Use of raw_smp_processor_id() is fine, as there should never be a case where
the tracepoint code goes from running on a CPU that is online and suddenly
gets migrated to a CPU that is offline.

Link: http://lkml.kernel.org/r/1455387773-4245-1-git-send-email-kda@linux-powerpc.org

Reported-by: Denis Kirjanov <kda@linux-powerpc.org>
Fixes: 97e1c18e8d17b ("tracing: Kernel Tracepoints")
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
---
 include/linux/tracepoint.h | 5 +++++
 1 file changed, 5 insertions(+)

--- a/include/linux/tracepoint.h
+++ b/include/linux/tracepoint.h
@@ -14,8 +14,10 @@
  * See the file COPYING for more details.
  */
 
+#include <linux/smp.h>
 #include <linux/errno.h>
 #include <linux/types.h>
+#include <linux/cpumask.h>
 #include <linux/rcupdate.h>
 #include <linux/jump_label.h>
 
@@ -126,6 +128,9 @@ static inline void tracepoint_synchroniz
 		void *it_func;						\
 		void *__data;						\
 									\
+		if (!cpu_online(raw_smp_processor_id()))		\
+			return;						\
+									\
 		if (!(cond))						\
 			return;						\
 		rcu_read_lock_sched_notrace();				\

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

#1366686

On Tue, Mar 29, 2016 at 08:18:21PM +0100, Ben Hutchings wrote:
> This is the start of the stable review cycle for the 3.2.79 release.
> There are 62 patches in this series, which will be posted as responses
> to this one.  If anyone has any issues with these being applied, please
> let me know.
> 
> Responses should be made by Thu Mar 31 22:00:00 UTC 2016.
> Anything received after that time might be too late.
> 
Build results:
	total: 94 pass: 94 fail: 0
Qemu test results:
	total: 61 pass: 61 fail: 0

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

Guenter

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

#1366711

[Multipart message — attachments visible in raw view] — view raw

On Tue, 2016-03-29 at 13:26 -0700, Guenter Roeck wrote:
> On Tue, Mar 29, 2016 at 08:18:21PM +0100, Ben Hutchings wrote:
> > 
> > This is the start of the stable review cycle for the 3.2.79 release.
> > There are 62 patches in this series, which will be posted as responses
> > to this one.  If anyone has any issues with these being applied, please
> > let me know.
> > 
> > Responses should be made by Thu Mar 31 22:00:00 UTC 2016.
> > Anything received after that time might be too late.
> > 
> Build results:
> 	total: 94 pass: 94 fail: 0
> Qemu test results:
> 	total: 61 pass: 61 fail: 0
> 
> Details are available at http://kerneltests.org/builders.

Thanks for checking.

Ben.

-- 
Ben Hutchings
Tomorrow will be cancelled due to lack of interest.

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

#1366687 — [PATCH 3.2 02/62] crypto: {blk,giv}cipher: Set has_setkey

3.2.79-rc1 review patch.  If anyone has any objections, please let me know.

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

From: Ben Hutchings <ben@decadent.org.uk>

Commit a1383cd86a06 ("crypto: skcipher - Add crypto_skcipher_has_setkey")
was incorrectly backported to the 3.2.y and 3.16.y stable branches.
We need to set ablkcipher_tfm::has_setkey in the
crypto_init_blkcipher_ops_async() and crypto_init_givcipher_ops()
functions as well as crypto_init_ablkcipher_ops().

Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
---
--- a/crypto/ablkcipher.c
+++ b/crypto/ablkcipher.c
@@ -461,6 +461,7 @@ static int crypto_init_givcipher_ops(str
 	crt->givdecrypt = alg->givdecrypt ?: no_givdecrypt;
 	crt->base = __crypto_ablkcipher_cast(tfm);
 	crt->ivsize = alg->ivsize;
+	crt->has_setkey = alg->max_keysize;
 
 	return 0;
 }
--- a/crypto/blkcipher.c
+++ b/crypto/blkcipher.c
@@ -458,6 +458,7 @@ static int crypto_init_blkcipher_ops_asy
 	}
 	crt->base = __crypto_ablkcipher_cast(tfm);
 	crt->ivsize = alg->ivsize;
+	crt->has_setkey = alg->max_keysize;
 
 	return 0;
 }

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | linux.kernel

csiph-web