[PATCH 3.15 00/37] 3.15.8-stable review

[PATCH 3.15 00/37] 3.15.8-stable review

[Greg Kroah-Hartman]

This is the start of the stable review cycle for the 3.15.8 release.
There are 37 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 Fri Aug  1 01:48:13 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.15.8-rc1.gz
and the diffstat can be found below.

thanks,

greg k-h

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

Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Linux 3.15.8-rc1

Guenter Roeck <linux@roeck-us.net>
    platform_get_irq: Revert to platform_get_resource if of_irq_get fails

Johannes Berg <johannes.berg@intel.com>
    nl80211: move set_qos_map command into split state

Konstantin Khlebnikov <koct9i@gmail.com>
    mm: do not call do_fault_around for non-linear fault

Amit Shah <amit.shah@redhat.com>
    hwrng: virtio - ensure reads happen after successful probe

Linus Torvalds <torvalds@linux-foundation.org>
    Fix gcc-4.9.0 miscompilation of load_balance() in scheduler

Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
    mm: hugetlb: fix copy_hugetlb_page_range()

Jerome Glisse <jglisse@redhat.com>
    drm/radeon: fix cut and paste issue for hawaii.

Christian König <christian.koenig@amd.com>
    drm/radeon: fix irq ring buffer overflow handling

Sven Wegener <sven.wegener@stealer.net>
    x86_32, entry: Store badsys error code in %eax

Vasily Averin <vvs@parallels.com>
    fs: umount on symlink leaks mnt count

Randy Dunlap <rdunlap@infradead.org>
    parport: fix menu breakage

Guenter Roeck <linux@roeck-us.net>
    hwmon: (smsc47m192) Fix temperature limit and vrm write operations

John David Anglin <dave.anglin@bell.net>
    parisc: Remove SA_RESTORER define

Maxime COQUELIN <maxime.coquelin@st.com>
    pinctrl: st: Fix irqmux handler

Andrew Gallagher <andrewjcg@fb.com>
    fuse: add FUSE_NO_OPEN_SUPPORT flag to INIT

Miklos Szeredi <mszeredi@suse.cz>
    fuse: s_time_gran fix

Silesh C V <svellattu@mvista.com>
    coredump: fix the setting of PF_DUMPCORE

Dmitry Torokhov <dtor@chromium.org>
    Input: fix defuzzing logic

Hans de Goede <hdegoede@redhat.com>
    Input: synaptics - add min/max quirk for pnp-id LEN2002 (Edge E531)

Mikulas Patocka <mpatocka@redhat.com>
    slab_common: fix the check for duplicate slab names

Tyrel Datwyler <tyreld@linux.vnet.ibm.com>
    powerpc/pseries: dynamically added OF nodes need to call of_node_init

Minchan Kim <minchan@kernel.org>
    zram: avoid lockdep splat by revalidate_disk

Tony Luck <tony.luck@intel.com>
    tracing: Fix wraparound problems in "uptime" trace clock

Tejun Heo <tj@kernel.org>
    blkcg: don't call into policy draining if root_blkg is already gone

Romain Degez <romain.degez@gmail.com>
    ahci: add support for the Promise FastTrak TX8660 SATA HBA (ahci mode)

Martin Schwidefsky <schwidefsky@de.ibm.com>
    s390/ptrace: fix PSW mask check

Tejun Heo <tj@kernel.org>
    libata: introduce ata_host->n_tags to avoid oops on SAS controllers

Kevin Hao <haokexin@gmail.com>
    libata: support the ata host which implements a queue depth less than 32

Christoph Hellwig <hch@lst.de>
    block: don't assume last put of shared tags is for the host

Mikulas Patocka <mpatocka@redhat.com>
    block: provide compat ioctl for BLKZEROOUT

Max Filippov <jcmvbkbc@gmail.com>
    xtensa: fix sysmem reservation at the end of existing block

Christoph Hellwig <hch@lst.de>
    nfs: only show Posix ACLs in listxattr if actually present

Antti Palosaari <crope@iki.fi>
    media: tda10071: force modulation to QPSK on DVB-S

Hans Verkuil <hverkuil@xs4all.nl>
    media: hdpvr: fix two audio bugs

Antti Palosaari <crope@iki.fi>
    media: af9035: override tuner id when bad value set into eeprom

Rickard Strandqvist <rickard_strandqvist@spectrumdigital.se>
    media: media: v4l2-core: v4l2-dv-timings.c: Cleaning up code wrong value used in aspect ratio

Arnd Bergmann <arnd@arndb.de>
    media: staging: tighten omap4iss dependencies


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

Diffstat:

 Makefile                                  |  6 +++--
 arch/parisc/include/uapi/asm/signal.h     |  2 --
 arch/powerpc/platforms/pseries/dlpar.c    |  1 +
 arch/powerpc/platforms/pseries/reconfig.c |  1 +
 arch/s390/kernel/ptrace.c                 | 12 +++++++--
 arch/x86/kernel/entry_32.S                |  9 ++++---
 arch/xtensa/mm/init.c                     |  2 +-
 block/blk-cgroup.c                        |  7 +++++
 block/blk-tag.c                           | 33 +++++-------------------
 block/compat_ioctl.c                      |  1 +
 drivers/ata/ahci.c                        |  1 +
 drivers/ata/libata-core.c                 | 12 +++++++--
 drivers/base/platform.c                   |  9 +++++--
 drivers/block/zram/zram_drv.c             | 22 +++++++++++++---
 drivers/char/hw_random/core.c             |  6 +++++
 drivers/char/hw_random/virtio-rng.c       | 10 +++++++
 drivers/gpu/drm/radeon/cik.c              |  2 ++
 drivers/gpu/drm/radeon/evergreen.c        |  1 +
 drivers/gpu/drm/radeon/r600.c             |  1 +
 drivers/gpu/drm/radeon/si.c               |  1 +
 drivers/hwmon/smsc47m192.c                |  4 ++-
 drivers/input/input.c                     |  6 +++--
 drivers/input/mouse/synaptics.c           |  5 ++--
 drivers/media/dvb-frontends/tda10071.c    |  6 ++++-
 drivers/media/usb/dvb-usb-v2/af9035.c     | 40 +++++++++++++++++++++++-----
 drivers/media/usb/hdpvr/hdpvr-video.c     |  6 ++---
 drivers/media/v4l2-core/v4l2-dv-timings.c |  4 +--
 drivers/parport/Kconfig                   | 12 ++++-----
 drivers/pinctrl/pinctrl-st.c              |  2 +-
 drivers/staging/media/omap4iss/Kconfig    |  2 +-
 fs/coredump.c                             |  2 +-
 fs/fuse/inode.c                           |  5 +---
 fs/namei.c                                |  3 ++-
 fs/nfs/nfs3acl.c                          | 43 +++++++++++++++++++++++++++++++
 fs/nfs/nfs3proc.c                         |  4 +--
 include/linux/libata.h                    |  1 +
 include/uapi/linux/fuse.h                 |  3 +++
 kernel/trace/trace.c                      |  2 +-
 kernel/trace/trace_clock.c                |  9 ++++---
 mm/hugetlb.c                              |  1 +
 mm/memory.c                               |  2 +-
 mm/slab_common.c                          |  2 +-
 net/wireless/nl80211.c                    | 11 ++++----
 43 files changed, 222 insertions(+), 92 deletions(-)

[PATCH 3.15 01/37] media: staging: tighten omap4iss dependencies

[Greg Kroah-Hartman]

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

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

From: Arnd Bergmann <arnd@arndb.de>

commit 4856fbd12d69965d3ab680c686222db93872728d upstream.

The OMAP4 camera support depends on I2C and VIDEO_V4L2, both
of which can be loadable modules. This causes build failures
if we want the camera driver to be built-in.

This can be solved by turning the option into "tristate",
which unfortunately causes another problem, because the
driver incorrectly calls a platform-internal interface
for omap4_ctrl_pad_readl/omap4_ctrl_pad_writel.

Instead, this patch just forbids the invalid configurations
and ensures that the driver can only be built if all its
dependencies are built-in.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/staging/media/omap4iss/Kconfig |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/staging/media/omap4iss/Kconfig
+++ b/drivers/staging/media/omap4iss/Kconfig
@@ -1,6 +1,6 @@
 config VIDEO_OMAP4
 	bool "OMAP 4 Camera support"
-	depends on VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API && I2C && ARCH_OMAP4
+	depends on VIDEO_V4L2=y && VIDEO_V4L2_SUBDEV_API && I2C=y && ARCH_OMAP4
 	select VIDEOBUF2_DMA_CONTIG
 	---help---
 	  Driver for an OMAP 4 ISS controller.

[PATCH 3.15 02/37] media: media: v4l2-core: v4l2-dv-timings.c: Cleaning up code wrong value used in aspect ratio

[Greg Kroah-Hartman]

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

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

From: Rickard Strandqvist <rickard_strandqvist@spectrumdigital.se>

commit f71920efb1066d71d74811e1dbed658173adf9bf upstream.

Wrong value used in same cases for the aspect ratio.

Signed-off-by: Rickard Strandqvist <rickard_strandqvist@spectrumdigital.se>
Acked-by: Lad, Prabhakar <prabhakar.csengg@gmail.com>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/media/v4l2-core/v4l2-dv-timings.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

--- a/drivers/media/v4l2-core/v4l2-dv-timings.c
+++ b/drivers/media/v4l2-core/v4l2-dv-timings.c
@@ -599,10 +599,10 @@ struct v4l2_fract v4l2_calc_aspect_ratio
 		aspect.denominator = 9;
 	} else if (ratio == 34) {
 		aspect.numerator = 4;
-		aspect.numerator = 3;
+		aspect.denominator = 3;
 	} else if (ratio == 68) {
 		aspect.numerator = 15;
-		aspect.numerator = 9;
+		aspect.denominator = 9;
 	} else {
 		aspect.numerator = hor_landscape + 99;
 		aspect.denominator = 100;

[PATCH 3.15 03/37] media: af9035: override tuner id when bad value set into eeprom

[Greg Kroah-Hartman]

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

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

From: Antti Palosaari <crope@iki.fi>

commit 1cbbf90d0406913ad4b44194b07f4f41bde84e54 upstream.

Tuner ID set into EEPROM is wrong in some cases, which causes driver
to select wrong tuner profile. That leads device non-working. Fix
issue by overriding known bad tuner IDs with suitable default value.

Thanks to MX-NET Telekomunikace s.r.o. for providing non-working
DTV stick, that I could fix the bug!

Signed-off-by: Antti Palosaari <crope@iki.fi>
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/media/usb/dvb-usb-v2/af9035.c |   40 ++++++++++++++++++++++++++++------
 1 file changed, 33 insertions(+), 7 deletions(-)

--- a/drivers/media/usb/dvb-usb-v2/af9035.c
+++ b/drivers/media/usb/dvb-usb-v2/af9035.c
@@ -704,15 +704,41 @@ static int af9035_read_config(struct dvb
 		if (ret < 0)
 			goto err;
 
-		if (tmp == 0x00)
-			dev_dbg(&d->udev->dev,
-					"%s: [%d]tuner not set, using default\n",
-					__func__, i);
-		else
+		dev_dbg(&d->udev->dev, "%s: [%d]tuner=%02x\n",
+				__func__, i, tmp);
+
+		/* tuner sanity check */
+		if (state->chip_type == 0x9135) {
+			if (state->chip_version == 0x02) {
+				/* IT9135 BX (v2) */
+				switch (tmp) {
+				case AF9033_TUNER_IT9135_60:
+				case AF9033_TUNER_IT9135_61:
+				case AF9033_TUNER_IT9135_62:
+					state->af9033_config[i].tuner = tmp;
+					break;
+				}
+			} else {
+				/* IT9135 AX (v1) */
+				switch (tmp) {
+				case AF9033_TUNER_IT9135_38:
+				case AF9033_TUNER_IT9135_51:
+				case AF9033_TUNER_IT9135_52:
+					state->af9033_config[i].tuner = tmp;
+					break;
+				}
+			}
+		} else {
+			/* AF9035 */
 			state->af9033_config[i].tuner = tmp;
+		}
 
-		dev_dbg(&d->udev->dev, "%s: [%d]tuner=%02x\n",
-				__func__, i, state->af9033_config[i].tuner);
+		if (state->af9033_config[i].tuner != tmp) {
+			dev_info(&d->udev->dev,
+					"%s: [%d] overriding tuner from %02x to %02x\n",
+					KBUILD_MODNAME, i, tmp,
+					state->af9033_config[i].tuner);
+		}
 
 		switch (state->af9033_config[i].tuner) {
 		case AF9033_TUNER_TUA9001:

[PATCH 3.15 04/37] media: hdpvr: fix two audio bugs

[Greg Kroah-Hartman]

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

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

From: Hans Verkuil <hverkuil@xs4all.nl>

commit 3445857b22eafb70a6ac258979e955b116bfd2c6 upstream.

When the audio encoding is changed the driver calls hdpvr_set_audio
with the current opt->audio_input value. However, that should have
been opt->audio_input + 1. So changing the audio encoding inadvertently
changes the input as well. This bug has always been there.

The second bug was introduced in kernel 3.10 and that broke the
default_audio_input module option handling: the audio encoding was
never switched to AC3 if default_audio_input was set to 2 (SPDIF input).

In addition, since starting with 3.10 the audio encoding is always set
at the start the first bug now always happens when the driver is loaded.
In the past this bug would only surface if the user would change the
audio encoding after the driver was loaded.

Also fixes a small trivial typo (bufffer -> buffer).

Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Reported-by: Scott Doty <scott@corp.sonic.net>
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/media/usb/hdpvr/hdpvr-video.c |    6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

--- a/drivers/media/usb/hdpvr/hdpvr-video.c
+++ b/drivers/media/usb/hdpvr/hdpvr-video.c
@@ -82,7 +82,7 @@ static void hdpvr_read_bulk_callback(str
 }
 
 /*=========================================================================*/
-/* bufffer bits */
+/* buffer bits */
 
 /* function expects dev->io_mutex to be hold by caller */
 int hdpvr_cancel_queue(struct hdpvr_device *dev)
@@ -926,7 +926,7 @@ static int hdpvr_s_ctrl(struct v4l2_ctrl
 	case V4L2_CID_MPEG_AUDIO_ENCODING:
 		if (dev->flags & HDPVR_FLAG_AC3_CAP) {
 			opt->audio_codec = ctrl->val;
-			return hdpvr_set_audio(dev, opt->audio_input,
+			return hdpvr_set_audio(dev, opt->audio_input + 1,
 					      opt->audio_codec);
 		}
 		return 0;
@@ -1198,7 +1198,7 @@ int hdpvr_register_videodev(struct hdpvr
 	v4l2_ctrl_new_std_menu(hdl, &hdpvr_ctrl_ops,
 		V4L2_CID_MPEG_AUDIO_ENCODING,
 		ac3 ? V4L2_MPEG_AUDIO_ENCODING_AC3 : V4L2_MPEG_AUDIO_ENCODING_AAC,
-		0x7, V4L2_MPEG_AUDIO_ENCODING_AAC);
+		0x7, ac3 ? dev->options.audio_codec : V4L2_MPEG_AUDIO_ENCODING_AAC);
 	v4l2_ctrl_new_std_menu(hdl, &hdpvr_ctrl_ops,
 		V4L2_CID_MPEG_VIDEO_ENCODING,
 		V4L2_MPEG_VIDEO_ENCODING_MPEG_4_AVC, 0x3,

[PATCH 3.15 05/37] media: tda10071: force modulation to QPSK on DVB-S

[Greg Kroah-Hartman]

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

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

From: Antti Palosaari <crope@iki.fi>

commit db4175ae2095634dbecd4c847da439f9c83e1b3b upstream.

Only supported modulation for DVB-S is QPSK. Modulation parameter
contains invalid value for DVB-S on some cases, which leads driver
refusing tuning attempt. Due to that, hard code modulation to QPSK
in case of DVB-S.

Signed-off-by: Antti Palosaari <crope@iki.fi>
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/media/dvb-frontends/tda10071.c |    6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

--- a/drivers/media/dvb-frontends/tda10071.c
+++ b/drivers/media/dvb-frontends/tda10071.c
@@ -668,6 +668,7 @@ static int tda10071_set_frontend(struct
 	struct dtv_frontend_properties *c = &fe->dtv_property_cache;
 	int ret, i;
 	u8 mode, rolloff, pilot, inversion, div;
+	fe_modulation_t modulation;
 
 	dev_dbg(&priv->i2c->dev,
 			"%s: delivery_system=%d modulation=%d frequency=%d symbol_rate=%d inversion=%d pilot=%d rolloff=%d\n",
@@ -702,10 +703,13 @@ static int tda10071_set_frontend(struct
 
 	switch (c->delivery_system) {
 	case SYS_DVBS:
+		modulation = QPSK;
 		rolloff = 0;
 		pilot = 2;
 		break;
 	case SYS_DVBS2:
+		modulation = c->modulation;
+
 		switch (c->rolloff) {
 		case ROLLOFF_20:
 			rolloff = 2;
@@ -750,7 +754,7 @@ static int tda10071_set_frontend(struct
 
 	for (i = 0, mode = 0xff; i < ARRAY_SIZE(TDA10071_MODCOD); i++) {
 		if (c->delivery_system == TDA10071_MODCOD[i].delivery_system &&
-			c->modulation == TDA10071_MODCOD[i].modulation &&
+			modulation == TDA10071_MODCOD[i].modulation &&
 			c->fec_inner == TDA10071_MODCOD[i].fec) {
 			mode = TDA10071_MODCOD[i].val;
 			dev_dbg(&priv->i2c->dev, "%s: mode found=%02x\n",

[PATCH 3.15 06/37] nfs: only show Posix ACLs in listxattr if actually present

[Greg Kroah-Hartman]

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

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

From: Christoph Hellwig <hch@lst.de>

commit 74adf83f5d7720925499b4938f930591f947b660 upstream.

The big ACL switched nfs to use generic_listxattr, which calls all existing
->list handlers.  Add a custom .listxattr implementation that only lists
the ACLs if they actually are present on the given inode.

Signed-off-by: Christoph Hellwig <hch@lst.de>
Reported-by: Philippe Troin <phil@fifi.org>
Tested-by: Philippe Troin <phil@fifi.org>
Fixes: 013cdf1088d7 (nfs: use generic posix ACL infrastructure ...)
Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 fs/nfs/nfs3acl.c  |   43 +++++++++++++++++++++++++++++++++++++++++++
 fs/nfs/nfs3proc.c |    4 ++--
 2 files changed, 45 insertions(+), 2 deletions(-)

--- a/fs/nfs/nfs3acl.c
+++ b/fs/nfs/nfs3acl.c
@@ -247,3 +247,46 @@ const struct xattr_handler *nfs3_xattr_h
 	&posix_acl_default_xattr_handler,
 	NULL,
 };
+
+static int
+nfs3_list_one_acl(struct inode *inode, int type, const char *name, void *data,
+		size_t size, ssize_t *result)
+{
+	struct posix_acl *acl;
+	char *p = data + *result;
+
+	acl = get_acl(inode, type);
+	if (!acl)
+		return 0;
+
+	posix_acl_release(acl);
+
+	*result += strlen(name);
+	*result += 1;
+	if (!size)
+		return 0;
+	if (*result > size)
+		return -ERANGE;
+
+	strcpy(p, name);
+	return 0;
+}
+
+ssize_t
+nfs3_listxattr(struct dentry *dentry, char *data, size_t size)
+{
+	struct inode *inode = dentry->d_inode;
+	ssize_t result = 0;
+	int error;
+
+	error = nfs3_list_one_acl(inode, ACL_TYPE_ACCESS,
+			POSIX_ACL_XATTR_ACCESS, data, size, &result);
+	if (error)
+		return error;
+
+	error = nfs3_list_one_acl(inode, ACL_TYPE_DEFAULT,
+			POSIX_ACL_XATTR_DEFAULT, data, size, &result);
+	if (error)
+		return error;
+	return result;
+}
--- a/fs/nfs/nfs3proc.c
+++ b/fs/nfs/nfs3proc.c
@@ -891,7 +891,7 @@ static const struct inode_operations nfs
 	.getattr	= nfs_getattr,
 	.setattr	= nfs_setattr,
 #ifdef CONFIG_NFS_V3_ACL
-	.listxattr	= generic_listxattr,
+	.listxattr	= nfs3_listxattr,
 	.getxattr	= generic_getxattr,
 	.setxattr	= generic_setxattr,
 	.removexattr	= generic_removexattr,
@@ -905,7 +905,7 @@ static const struct inode_operations nfs
 	.getattr	= nfs_getattr,
 	.setattr	= nfs_setattr,
 #ifdef CONFIG_NFS_V3_ACL
-	.listxattr	= generic_listxattr,
+	.listxattr	= nfs3_listxattr,
 	.getxattr	= generic_getxattr,
 	.setxattr	= generic_setxattr,
 	.removexattr	= generic_removexattr,

[PATCH 3.15 07/37] xtensa: fix sysmem reservation at the end of existing block

[Greg Kroah-Hartman]

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

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

From: Max Filippov <jcmvbkbc@gmail.com>

commit be6ae382dc153da51cf066c8dd523aa955f02531 upstream.

When sysmem reservation occurs exactly at the end of an existing block
that block is deleted, because it is incorrectly included in the range
of memblocks to remove. Fix that by skipping such block.

Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 arch/xtensa/mm/init.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/arch/xtensa/mm/init.c
+++ b/arch/xtensa/mm/init.c
@@ -191,7 +191,7 @@ int __init mem_reserve(unsigned long sta
 		return -EINVAL;
 	}
 
-	if (it && start - it->start < bank_sz) {
+	if (it && start - it->start <= bank_sz) {
 		if (start == it->start) {
 			if (end - it->start < bank_sz) {
 				it->start = end;

[PATCH 3.15 08/37] block: provide compat ioctl for BLKZEROOUT

[Greg Kroah-Hartman]

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

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

From: Mikulas Patocka <mpatocka@redhat.com>

commit 3b3a1814d1703027f9867d0f5cbbfaf6c7482474 upstream.

This patch provides the compat BLKZEROOUT ioctl. The argument is a pointer
to two uint64_t values, so there is no need to translate it.

Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
Acked-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 block/compat_ioctl.c |    1 +
 1 file changed, 1 insertion(+)

--- a/block/compat_ioctl.c
+++ b/block/compat_ioctl.c
@@ -690,6 +690,7 @@ long compat_blkdev_ioctl(struct file *fi
 	case BLKROSET:
 	case BLKDISCARD:
 	case BLKSECDISCARD:
+	case BLKZEROOUT:
 	/*
 	 * the ones below are implemented in blkdev_locked_ioctl,
 	 * but we call blkdev_ioctl, which gets the lock for us

[PATCH 3.15 09/37] block: dont assume last put of shared tags is for the host

[Greg Kroah-Hartman]

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

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

From: Christoph Hellwig <hch@lst.de>

commit d45b3279a5a2252cafcd665bbf2db8c9b31ef783 upstream.

There is no inherent reason why the last put of a tag structure must be
the one for the Scsi_Host, as device model objects can be held for
arbitrary periods.  Merge blk_free_tags and __blk_free_tags into a single
funtion that just release a references and get rid of the BUG() when the
host reference wasn't the last.

Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Jens Axboe <axboe@fb.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 block/blk-tag.c |   33 +++++++--------------------------
 1 file changed, 7 insertions(+), 26 deletions(-)

--- a/block/blk-tag.c
+++ b/block/blk-tag.c
@@ -27,18 +27,15 @@ struct request *blk_queue_find_tag(struc
 EXPORT_SYMBOL(blk_queue_find_tag);
 
 /**
- * __blk_free_tags - release a given set of tag maintenance info
+ * blk_free_tags - release a given set of tag maintenance info
  * @bqt:	the tag map to free
  *
- * Tries to free the specified @bqt.  Returns true if it was
- * actually freed and false if there are still references using it
+ * Drop the reference count on @bqt and frees it when the last reference
+ * is dropped.
  */
-static int __blk_free_tags(struct blk_queue_tag *bqt)
+void blk_free_tags(struct blk_queue_tag *bqt)
 {
-	int retval;
-
-	retval = atomic_dec_and_test(&bqt->refcnt);
-	if (retval) {
+	if (atomic_dec_and_test(&bqt->refcnt)) {
 		BUG_ON(find_first_bit(bqt->tag_map, bqt->max_depth) <
 							bqt->max_depth);
 
@@ -50,9 +47,8 @@ static int __blk_free_tags(struct blk_qu
 
 		kfree(bqt);
 	}
-
-	return retval;
 }
+EXPORT_SYMBOL(blk_free_tags);
 
 /**
  * __blk_queue_free_tags - release tag maintenance info
@@ -69,28 +65,13 @@ void __blk_queue_free_tags(struct reques
 	if (!bqt)
 		return;
 
-	__blk_free_tags(bqt);
+	blk_free_tags(bqt);
 
 	q->queue_tags = NULL;
 	queue_flag_clear_unlocked(QUEUE_FLAG_QUEUED, q);
 }
 
 /**
- * blk_free_tags - release a given set of tag maintenance info
- * @bqt:	the tag map to free
- *
- * For externally managed @bqt frees the map.  Callers of this
- * function must guarantee to have released all the queues that
- * might have been using this tag map.
- */
-void blk_free_tags(struct blk_queue_tag *bqt)
-{
-	if (unlikely(!__blk_free_tags(bqt)))
-		BUG();
-}
-EXPORT_SYMBOL(blk_free_tags);
-
-/**
  * blk_queue_free_tags - release tag maintenance info
  * @q:  the request queue for the device
  *

[PATCH 3.15 10/37] libata: support the ata host which implements a queue depth less than 32

[Greg Kroah-Hartman]

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

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

From: Kevin Hao <haokexin@gmail.com>

commit 1871ee134b73fb4cadab75752a7152ed2813c751 upstream.

The sata on fsl mpc8315e is broken after the commit 8a4aeec8d2d6
("libata/ahci: accommodate tag ordered controllers"). The reason is
that the ata controller on this SoC only implement a queue depth of
16. When issuing the commands in tag order, all the commands in tag
16 ~ 31 are mapped to tag 0 unconditionally and then causes the sata
malfunction. It makes no senses to use a 32 queue in software while
the hardware has less queue depth. So consider the queue depth
implemented by the hardware when requesting a command tag.

Fixes: 8a4aeec8d2d6 ("libata/ahci: accommodate tag ordered controllers")
Signed-off-by: Kevin Hao <haokexin@gmail.com>
Acked-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/ata/libata-core.c |   22 +++++++++++++++++++---
 1 file changed, 19 insertions(+), 3 deletions(-)

--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -4787,6 +4787,10 @@ void swap_buf_le16(u16 *buf, unsigned in
  *	ata_qc_new - Request an available ATA command, for queueing
  *	@ap: target port
  *
+ *	Some ATA host controllers may implement a queue depth which is less
+ *	than ATA_MAX_QUEUE. So we shouldn't allocate a tag which is beyond
+ *	the hardware limitation.
+ *
  *	LOCKING:
  *	None.
  */
@@ -4794,14 +4798,16 @@ void swap_buf_le16(u16 *buf, unsigned in
 static struct ata_queued_cmd *ata_qc_new(struct ata_port *ap)
 {
 	struct ata_queued_cmd *qc = NULL;
-	unsigned int i, tag;
+	unsigned int i, tag, max_queue;
+
+	max_queue = ap->scsi_host->can_queue;
 
 	/* no command while frozen */
 	if (unlikely(ap->pflags & ATA_PFLAG_FROZEN))
 		return NULL;
 
-	for (i = 0; i < ATA_MAX_QUEUE; i++) {
-		tag = (i + ap->last_tag + 1) % ATA_MAX_QUEUE;
+	for (i = 0, tag = ap->last_tag + 1; i < max_queue; i++, tag++) {
+		tag = tag < max_queue ? tag : 0;
 
 		/* the last tag is reserved for internal command. */
 		if (tag == ATA_TAG_INTERNAL)
@@ -6169,6 +6175,16 @@ int ata_host_register(struct ata_host *h
 {
 	int i, rc;
 
+	/*
+	 * The max queue supported by hardware must not be greater than
+	 * ATA_MAX_QUEUE.
+	 */
+	if (sht->can_queue > ATA_MAX_QUEUE) {
+		dev_err(host->dev, "BUG: the hardware max queue is too large\n");
+		WARN_ON(1);
+		return -EINVAL;
+	}
+
 	/* host must have been started */
 	if (!(host->flags & ATA_HOST_STARTED)) {
 		dev_err(host->dev, "BUG: trying to register unstarted host\n");

[PATCH 3.15 11/37] libata: introduce ata_host->n_tags to avoid oops on SAS controllers

[Greg Kroah-Hartman]

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

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

From: Tejun Heo <tj@kernel.org>

commit 1a112d10f03e83fb3a2fdc4c9165865dec8a3ca6 upstream.

1871ee134b73 ("libata: support the ata host which implements a queue
depth less than 32") directly used ata_port->scsi_host->can_queue from
ata_qc_new() to determine the number of tags supported by the host;
unfortunately, SAS controllers doing SATA don't initialize ->scsi_host
leading to the following oops.

 BUG: unable to handle kernel NULL pointer dereference at 0000000000000058
 IP: [<ffffffff814e0618>] ata_qc_new_init+0x188/0x1b0
 PGD 0
 Oops: 0002 [#1] SMP
 Modules linked in: isci libsas scsi_transport_sas mgag200 drm_kms_helper ttm
 CPU: 1 PID: 518 Comm: udevd Not tainted 3.16.0-rc6+ #62
 Hardware name: Intel Corporation S2600CO/S2600CO, BIOS SE5C600.86B.02.02.0002.122320131210 12/23/2013
 task: ffff880c1a00b280 ti: ffff88061a000000 task.ti: ffff88061a000000
 RIP: 0010:[<ffffffff814e0618>]  [<ffffffff814e0618>] ata_qc_new_init+0x188/0x1b0
 RSP: 0018:ffff88061a003ae8  EFLAGS: 00010012
 RAX: 0000000000000001 RBX: ffff88000241ca80 RCX: 00000000000000fa
 RDX: 0000000000000020 RSI: 0000000000000020 RDI: ffff8806194aa298
 RBP: ffff88061a003ae8 R08: ffff8806194a8000 R09: 0000000000000000
 R10: 0000000000000000 R11: ffff88000241ca80 R12: ffff88061ad58200
 R13: ffff8806194aa298 R14: ffffffff814e67a0 R15: ffff8806194a8000
 FS:  00007f3ad7fe3840(0000) GS:ffff880627620000(0000) knlGS:0000000000000000
 CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
 CR2: 0000000000000058 CR3: 000000061a118000 CR4: 00000000001407e0
 Stack:
  ffff88061a003b20 ffffffff814e96e1 ffff88000241ca80 ffff88061ad58200
  ffff8800b6bf6000 ffff880c1c988000 ffff880619903850 ffff88061a003b68
  ffffffffa0056ce1 ffff88061a003b48 0000000013d6e6f8 ffff88000241ca80
 Call Trace:
  [<ffffffff814e96e1>] ata_sas_queuecmd+0xa1/0x430
  [<ffffffffa0056ce1>] sas_queuecommand+0x191/0x220 [libsas]
  [<ffffffff8149afee>] scsi_dispatch_cmd+0x10e/0x300 [<ffffffff814a3bc5>] scsi_request_fn+0x2f5/0x550
  [<ffffffff81317613>] __blk_run_queue+0x33/0x40
  [<ffffffff8131781a>] queue_unplugged+0x2a/0x90
  [<ffffffff8131ceb4>] blk_flush_plug_list+0x1b4/0x210
  [<ffffffff8131d274>] blk_finish_plug+0x14/0x50
  [<ffffffff8117eaa8>] __do_page_cache_readahead+0x198/0x1f0
  [<ffffffff8117ee21>] force_page_cache_readahead+0x31/0x50
  [<ffffffff8117ee7e>] page_cache_sync_readahead+0x3e/0x50
  [<ffffffff81172ac6>] generic_file_read_iter+0x496/0x5a0
  [<ffffffff81219897>] blkdev_read_iter+0x37/0x40
  [<ffffffff811e307e>] new_sync_read+0x7e/0xb0
  [<ffffffff811e3734>] vfs_read+0x94/0x170
  [<ffffffff811e43c6>] SyS_read+0x46/0xb0
  [<ffffffff811e33d1>] ? SyS_lseek+0x91/0xb0
  [<ffffffff8171ee29>] system_call_fastpath+0x16/0x1b
 Code: 00 00 00 88 50 29 83 7f 08 01 19 d2 83 e2 f0 83 ea 50 88 50 34 c6 81 1d 02 00 00 40 c6 81 17 02 00 00 00 5d c3 66 0f 1f 44 00 00 <89> 14 25 58 00 00 00

Fix it by introducing ata_host->n_tags which is initialized to
ATA_MAX_QUEUE - 1 in ata_host_init() for SAS controllers and set to
scsi_host_template->can_queue in ata_host_register() for !SAS ones.
As SAS hosts are never registered, this will give them the same
ATA_MAX_QUEUE - 1 as before.  Note that we can't use
scsi_host->can_queue directly for SAS hosts anyway as they can go
higher than the libata maximum.

Signed-off-by: Tejun Heo <tj@kernel.org>
Reported-by: Mike Qiu <qiudayu@linux.vnet.ibm.com>
Reported-by: Jesse Brandeburg <jesse.brandeburg@gmail.com>
Reported-by: Peter Hurley <peter@hurleysoftware.com>
Reported-by: Peter Zijlstra <peterz@infradead.org>
Tested-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Fixes: 1871ee134b73 ("libata: support the ata host which implements a queue depth less than 32")
Cc: Kevin Hao <haokexin@gmail.com>
Cc: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/ata/libata-core.c |   16 ++++------------
 include/linux/libata.h    |    1 +
 2 files changed, 5 insertions(+), 12 deletions(-)

--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -4798,9 +4798,8 @@ void swap_buf_le16(u16 *buf, unsigned in
 static struct ata_queued_cmd *ata_qc_new(struct ata_port *ap)
 {
 	struct ata_queued_cmd *qc = NULL;
-	unsigned int i, tag, max_queue;
-
-	max_queue = ap->scsi_host->can_queue;
+	unsigned int max_queue = ap->host->n_tags;
+	unsigned int i, tag;
 
 	/* no command while frozen */
 	if (unlikely(ap->pflags & ATA_PFLAG_FROZEN))
@@ -6094,6 +6093,7 @@ void ata_host_init(struct ata_host *host
 {
 	spin_lock_init(&host->lock);
 	mutex_init(&host->eh_mutex);
+	host->n_tags = ATA_MAX_QUEUE - 1;
 	host->dev = dev;
 	host->ops = ops;
 }
@@ -6175,15 +6175,7 @@ int ata_host_register(struct ata_host *h
 {
 	int i, rc;
 
-	/*
-	 * The max queue supported by hardware must not be greater than
-	 * ATA_MAX_QUEUE.
-	 */
-	if (sht->can_queue > ATA_MAX_QUEUE) {
-		dev_err(host->dev, "BUG: the hardware max queue is too large\n");
-		WARN_ON(1);
-		return -EINVAL;
-	}
+	host->n_tags = clamp(sht->can_queue, 1, ATA_MAX_QUEUE - 1);
 
 	/* host must have been started */
 	if (!(host->flags & ATA_HOST_STARTED)) {
--- a/include/linux/libata.h
+++ b/include/linux/libata.h
@@ -593,6 +593,7 @@ struct ata_host {
 	struct device 		*dev;
 	void __iomem * const	*iomap;
 	unsigned int		n_ports;
+	unsigned int		n_tags;			/* nr of NCQ tags */
 	void			*private_data;
 	struct ata_port_operations *ops;
 	unsigned long		flags;

[PATCH 3.15 12/37] s390/ptrace: fix PSW mask check

[Greg Kroah-Hartman]

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

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

From: Martin Schwidefsky <schwidefsky@de.ibm.com>

commit dab6cf55f81a6e16b8147aed9a843e1691dcd318 upstream.

The PSW mask check of the PTRACE_POKEUSR_AREA command is incorrect.
The PSW_MASK_USER define contains the PSW_MASK_ASC bits, the ptrace
interface accepts all combinations for the address-space-control
bits. To protect the kernel space the PSW mask check in ptrace needs
to reject the address-space-control bit combination for home space.

Fixes CVE-2014-3534

Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 arch/s390/kernel/ptrace.c |   12 ++++++++++--
 1 file changed, 10 insertions(+), 2 deletions(-)

--- a/arch/s390/kernel/ptrace.c
+++ b/arch/s390/kernel/ptrace.c
@@ -334,9 +334,14 @@ static int __poke_user(struct task_struc
 			unsigned long mask = PSW_MASK_USER;
 
 			mask |= is_ri_task(child) ? PSW_MASK_RI : 0;
-			if ((data & ~mask) != PSW_USER_BITS)
+			if ((data ^ PSW_USER_BITS) & ~mask)
+				/* Invalid psw mask. */
+				return -EINVAL;
+			if ((data & PSW_MASK_ASC) == PSW_ASC_HOME)
+				/* Invalid address-space-control bits */
 				return -EINVAL;
 			if ((data & PSW_MASK_EA) && !(data & PSW_MASK_BA))
+				/* Invalid addressing mode bits */
 				return -EINVAL;
 		}
 		*(addr_t *)((addr_t) &task_pt_regs(child)->psw + addr) = data;
@@ -672,9 +677,12 @@ static int __poke_user_compat(struct tas
 
 			mask |= is_ri_task(child) ? PSW32_MASK_RI : 0;
 			/* Build a 64 bit psw mask from 31 bit mask. */
-			if ((tmp & ~mask) != PSW32_USER_BITS)
+			if ((tmp ^ PSW32_USER_BITS) & ~mask)
 				/* Invalid psw mask. */
 				return -EINVAL;
+			if ((data & PSW32_MASK_ASC) == PSW32_ASC_HOME)
+				/* Invalid address-space-control bits */
+				return -EINVAL;
 			regs->psw.mask = (regs->psw.mask & ~PSW_MASK_USER) |
 				(regs->psw.mask & PSW_MASK_BA) |
 				(__u64)(tmp & mask) << 32;

[PATCH 3.15 13/37] ahci: add support for the Promise FastTrak TX8660 SATA HBA (ahci mode)

[Greg Kroah-Hartman]

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

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

From: Romain Degez <romain.degez@gmail.com>

commit b32bfc06aefab61acc872dec3222624e6cd867ed upstream.

Add support of the Promise FastTrak TX8660 SATA HBA in ahci mode by
registering the board in the ahci_pci_tbl[].

Note: this HBA also provide a hardware RAID mode when activated in
BIOS but specific drivers from the manufacturer are required in this
case.

Signed-off-by: Romain Degez <romain.degez@gmail.com>
Tested-by: Romain Degez <romain.degez@gmail.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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

--- a/drivers/ata/ahci.c
+++ b/drivers/ata/ahci.c
@@ -456,6 +456,7 @@ static const struct pci_device_id ahci_p
 
 	/* Promise */
 	{ PCI_VDEVICE(PROMISE, 0x3f20), board_ahci },	/* PDC42819 */
+	{ PCI_VDEVICE(PROMISE, 0x3781), board_ahci },   /* FastTrak TX8660 ahci-mode */
 
 	/* Asmedia */
 	{ PCI_VDEVICE(ASMEDIA, 0x0601), board_ahci },	/* ASM1060 */

[PATCH 3.15 14/37] blkcg: dont call into policy draining if root_blkg is already gone

[Greg Kroah-Hartman]

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

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

From: Tejun Heo <tj@kernel.org>

commit 0b462c89e31f7eb6789713437eb551833ee16ff3 upstream.

While a queue is being destroyed, all the blkgs are destroyed and its
->root_blkg pointer is set to NULL.  If someone else starts to drain
while the queue is in this state, the following oops happens.

  NULL pointer dereference at 0000000000000028
  IP: [<ffffffff8144e944>] blk_throtl_drain+0x84/0x230
  PGD e4a1067 PUD b773067 PMD 0
  Oops: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC
  Modules linked in: cfq_iosched(-) [last unloaded: cfq_iosched]
  CPU: 1 PID: 537 Comm: bash Not tainted 3.16.0-rc3-work+ #2
  Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
  task: ffff88000e222250 ti: ffff88000efd4000 task.ti: ffff88000efd4000
  RIP: 0010:[<ffffffff8144e944>]  [<ffffffff8144e944>] blk_throtl_drain+0x84/0x230
  RSP: 0018:ffff88000efd7bf0  EFLAGS: 00010046
  RAX: 0000000000000000 RBX: ffff880015091450 RCX: 0000000000000001
  RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
  RBP: ffff88000efd7c10 R08: 0000000000000000 R09: 0000000000000001
  R10: ffff88000e222250 R11: 0000000000000000 R12: ffff880015091450
  R13: ffff880015092e00 R14: ffff880015091d70 R15: ffff88001508fc28
  FS:  00007f1332650740(0000) GS:ffff88001fa80000(0000) knlGS:0000000000000000
  CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
  CR2: 0000000000000028 CR3: 0000000009446000 CR4: 00000000000006e0
  Stack:
   ffffffff8144e8f6 ffff880015091450 0000000000000000 ffff880015091d80
   ffff88000efd7c28 ffffffff8144ae2f ffff880015091450 ffff88000efd7c58
   ffffffff81427641 ffff880015091450 ffffffff82401f00 ffff880015091450
  Call Trace:
   [<ffffffff8144ae2f>] blkcg_drain_queue+0x1f/0x60
   [<ffffffff81427641>] __blk_drain_queue+0x71/0x180
   [<ffffffff81429b3e>] blk_queue_bypass_start+0x6e/0xb0
   [<ffffffff814498b8>] blkcg_deactivate_policy+0x38/0x120
   [<ffffffff8144ec44>] blk_throtl_exit+0x34/0x50
   [<ffffffff8144aea5>] blkcg_exit_queue+0x35/0x40
   [<ffffffff8142d476>] blk_release_queue+0x26/0xd0
   [<ffffffff81454968>] kobject_cleanup+0x38/0x70
   [<ffffffff81454848>] kobject_put+0x28/0x60
   [<ffffffff81427505>] blk_put_queue+0x15/0x20
   [<ffffffff817d07bb>] scsi_device_dev_release_usercontext+0x16b/0x1c0
   [<ffffffff810bc339>] execute_in_process_context+0x89/0xa0
   [<ffffffff817d064c>] scsi_device_dev_release+0x1c/0x20
   [<ffffffff817930e2>] device_release+0x32/0xa0
   [<ffffffff81454968>] kobject_cleanup+0x38/0x70
   [<ffffffff81454848>] kobject_put+0x28/0x60
   [<ffffffff817934d7>] put_device+0x17/0x20
   [<ffffffff817d11b9>] __scsi_remove_device+0xa9/0xe0
   [<ffffffff817d121b>] scsi_remove_device+0x2b/0x40
   [<ffffffff817d1257>] sdev_store_delete+0x27/0x30
   [<ffffffff81792ca8>] dev_attr_store+0x18/0x30
   [<ffffffff8126f75e>] sysfs_kf_write+0x3e/0x50
   [<ffffffff8126ea87>] kernfs_fop_write+0xe7/0x170
   [<ffffffff811f5e9f>] vfs_write+0xaf/0x1d0
   [<ffffffff811f69bd>] SyS_write+0x4d/0xc0
   [<ffffffff81d24692>] system_call_fastpath+0x16/0x1b

776687bce42b ("block, blk-mq: draining can't be skipped even if
bypass_depth was non-zero") made it easier to trigger this bug by
making blk_queue_bypass_start() drain even when it loses the first
bypass test to blk_cleanup_queue(); however, the bug has always been
there even before the commit as blk_queue_bypass_start() could race
against queue destruction, win the initial bypass test but perform the
actual draining after blk_cleanup_queue() already destroyed all blkgs.

Fix it by skippping calling into policy draining if all the blkgs are
already gone.

Signed-off-by: Tejun Heo <tj@kernel.org>
Reported-by: Shirish Pargaonkar <spargaonkar@suse.com>
Reported-by: Sasha Levin <sasha.levin@oracle.com>
Reported-by: Jet Chen <jet.chen@intel.com>
Tested-by: Shirish Pargaonkar <spargaonkar@suse.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 block/blk-cgroup.c |    7 +++++++
 1 file changed, 7 insertions(+)

--- a/block/blk-cgroup.c
+++ b/block/blk-cgroup.c
@@ -872,6 +872,13 @@ void blkcg_drain_queue(struct request_qu
 {
 	lockdep_assert_held(q->queue_lock);
 
+	/*
+	 * @q could be exiting and already have destroyed all blkgs as
+	 * indicated by NULL root_blkg.  If so, don't confuse policies.
+	 */
+	if (!q->root_blkg)
+		return;
+
 	blk_throtl_drain(q);
 }
 

[PATCH 3.15 15/37] tracing: Fix wraparound problems in "uptime" trace clock

[Greg Kroah-Hartman]

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

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

From: Tony Luck <tony.luck@intel.com>

commit 58d4e21e50ff3cc57910a8abc20d7e14375d2f61 upstream.

The "uptime" trace clock added in:

    commit 8aacf017b065a805d27467843490c976835eb4a5
    tracing: Add "uptime" trace clock that uses jiffies

has wraparound problems when the system has been up more
than 1 hour 11 minutes and 34 seconds. It converts jiffies
to nanoseconds using:
        (u64)jiffies_to_usecs(jiffy) * 1000ULL
but since jiffies_to_usecs() only returns a 32-bit value, it
truncates at 2^32 microseconds.  An additional problem on 32-bit
systems is that the argument is "unsigned long", so fixing the
return value only helps until 2^32 jiffies (49.7 days on a HZ=1000
system).

Avoid these problems by using jiffies_64 as our basis, and
not converting to nanoseconds (we do convert to clock_t because
user facing API must not be dependent on internal kernel
HZ values).

Link: http://lkml.kernel.org/p/99d63c5bfe9b320a3b428d773825a37095bf6a51.1405708254.git.tony.luck@intel.com

Fixes: 8aacf017b065 "tracing: Add "uptime" trace clock that uses jiffies"
Signed-off-by: Tony Luck <tony.luck@intel.com>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 kernel/trace/trace.c       |    2 +-
 kernel/trace/trace_clock.c |    9 +++++----
 2 files changed, 6 insertions(+), 5 deletions(-)

--- a/kernel/trace/trace.c
+++ b/kernel/trace/trace.c
@@ -823,7 +823,7 @@ static struct {
 	{ trace_clock_local,	"local",	1 },
 	{ trace_clock_global,	"global",	1 },
 	{ trace_clock_counter,	"counter",	0 },
-	{ trace_clock_jiffies,	"uptime",	1 },
+	{ trace_clock_jiffies,	"uptime",	0 },
 	{ trace_clock,		"perf",		1 },
 	ARCH_TRACE_CLOCKS
 };
--- a/kernel/trace/trace_clock.c
+++ b/kernel/trace/trace_clock.c
@@ -59,13 +59,14 @@ u64 notrace trace_clock(void)
 
 /*
  * trace_jiffy_clock(): Simply use jiffies as a clock counter.
+ * Note that this use of jiffies_64 is not completely safe on
+ * 32-bit systems. But the window is tiny, and the effect if
+ * we are affected is that we will have an obviously bogus
+ * timestamp on a trace event - i.e. not life threatening.
  */
 u64 notrace trace_clock_jiffies(void)
 {
-	u64 jiffy = jiffies - INITIAL_JIFFIES;
-
-	/* Return nsecs */
-	return (u64)jiffies_to_usecs(jiffy) * 1000ULL;
+	return jiffies_64_to_clock_t(jiffies_64 - INITIAL_JIFFIES);
 }
 
 /*

[PATCH 3.15 16/37] zram: avoid lockdep splat by revalidate_disk

[Greg Kroah-Hartman]

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

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

From: Minchan Kim <minchan@kernel.org>

commit b4c5c60920e3b0c4598f43e7317559f6aec51531 upstream.

Sasha reported lockdep warning [1] introduced by [2].

It could be fixed by doing disk revalidation out of the init_lock.  It's
okay because disk capacity change is protected by init_lock so that
revalidate_disk always sees up-to-date value so there is no race.

[1] https://lkml.org/lkml/2014/7/3/735
[2] zram: revalidate disk after capacity change

Fixes 2e32baea46ce ("zram: revalidate disk after capacity change").

Signed-off-by: Minchan Kim <minchan@kernel.org>
Reported-by: Sasha Levin <sasha.levin@oracle.com>
Cc: "Alexander E. Patrakov" <patrakov@gmail.com>
Cc: Nitin Gupta <ngupta@vflare.org>
Cc: Jerome Marchand <jmarchan@redhat.com>
Cc: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/block/zram/zram_drv.c |   22 ++++++++++++++++++----
 1 file changed, 18 insertions(+), 4 deletions(-)

--- a/drivers/block/zram/zram_drv.c
+++ b/drivers/block/zram/zram_drv.c
@@ -622,11 +622,18 @@ static void zram_reset_device(struct zra
 	memset(&zram->stats, 0, sizeof(zram->stats));
 
 	zram->disksize = 0;
-	if (reset_capacity) {
+	if (reset_capacity)
 		set_capacity(zram->disk, 0);
-		revalidate_disk(zram->disk);
-	}
+
 	up_write(&zram->init_lock);
+
+	/*
+	 * Revalidate disk out of the init_lock to avoid lockdep splat.
+	 * It's okay because disk's capacity is protected by init_lock
+	 * so that revalidate_disk always sees up-to-date capacity.
+	 */
+	if (reset_capacity)
+		revalidate_disk(zram->disk);
 }
 
 static ssize_t disksize_store(struct device *dev,
@@ -666,8 +673,15 @@ static ssize_t disksize_store(struct dev
 	zram->comp = comp;
 	zram->disksize = disksize;
 	set_capacity(zram->disk, zram->disksize >> SECTOR_SHIFT);
-	revalidate_disk(zram->disk);
 	up_write(&zram->init_lock);
+
+	/*
+	 * Revalidate disk out of the init_lock to avoid lockdep splat.
+	 * It's okay because disk's capacity is protected by init_lock
+	 * so that revalidate_disk always sees up-to-date capacity.
+	 */
+	revalidate_disk(zram->disk);
+
 	return len;
 
 out_destroy_comp:

[PATCH 3.15 17/37] powerpc/pseries: dynamically added OF nodes need to call of_node_init

[Greg Kroah-Hartman]

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

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

From: Tyrel Datwyler <tyreld@linux.vnet.ibm.com>

commit 97a9a7179aad701ab676e6f29eb90766a1acfde2 upstream.

Commit 75b57ecf9 refactored device tree nodes to use kobjects such that they
can be exposed via /sysfs. A secondary commit 0829f6d1f furthered this rework
by moving the kobect initialization logic out of of_node_add into its own
of_node_init function. The inital commit removed the existing kref_init calls
in the pseries dlpar code with the assumption kobject initialization would
occur in of_node_add. The second commit had the side effect of triggering a
BUG_ON during DLPAR, migration and suspend/resume operations as a result of
dynamically added nodes being uninitialized.

This patch fixes this by adding of_node_init calls in place of the previously
removed kref_init calls.

Fixes: 0829f6d1f69e ("of: device_node kobject lifecycle fixes")
Signed-off-by: Tyrel Datwyler <tyreld@linux.vnet.ibm.com>
Acked-by: Nathan Fontenot <nfont@linux.vnet.ibm.com>
Acked-by: Grant Likely <grant.likely@linaro.org>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 arch/powerpc/platforms/pseries/dlpar.c    |    1 +
 arch/powerpc/platforms/pseries/reconfig.c |    1 +
 2 files changed, 2 insertions(+)

--- a/arch/powerpc/platforms/pseries/dlpar.c
+++ b/arch/powerpc/platforms/pseries/dlpar.c
@@ -86,6 +86,7 @@ static struct device_node *dlpar_parse_c
 	}
 
 	of_node_set_flag(dn, OF_DYNAMIC);
+	of_node_init(dn);
 
 	return dn;
 }
--- a/arch/powerpc/platforms/pseries/reconfig.c
+++ b/arch/powerpc/platforms/pseries/reconfig.c
@@ -69,6 +69,7 @@ static int pSeries_reconfig_add_node(con
 
 	np->properties = proplist;
 	of_node_set_flag(np, OF_DYNAMIC);
+	of_node_init(np);
 
 	np->parent = derive_parent(path);
 	if (IS_ERR(np->parent)) {

[PATCH 3.15 18/37] slab_common: fix the check for duplicate slab names

[Greg Kroah-Hartman]

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

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

From: Mikulas Patocka <mpatocka@redhat.com>

commit 694617474e33b8603fc76e090ed7d09376514b1a upstream.

The patch 3e374919b314f20e2a04f641ebc1093d758f66a4 is supposed to fix the
problem where kmem_cache_create incorrectly reports duplicate cache name
and fails. The problem is described in the header of that patch.

However, the patch doesn't really fix the problem because of these
reasons:

* the logic to test for debugging is reversed. It was intended to perform
  the check only if slub debugging is enabled (which implies that caches
  with the same parameters are not merged). Therefore, there should be
  #if !defined(CONFIG_SLUB) || defined(CONFIG_SLUB_DEBUG_ON)
  The current code has the condition reversed and performs the test if
  debugging is disabled.

* slub debugging may be enabled or disabled based on kernel command line,
  CONFIG_SLUB_DEBUG_ON is just the default settings. Therefore the test
  based on definition of CONFIG_SLUB_DEBUG_ON is unreliable.

This patch fixes the problem by removing the test
"!defined(CONFIG_SLUB_DEBUG_ON)". Therefore, duplicate names are never
checked if the SLUB allocator is used.

Note to stable kernel maintainers: when backporint this patch, please
backport also the patch 3e374919b314f20e2a04f641ebc1093d758f66a4.

Acked-by: David Rientjes <rientjes@google.com>
Acked-by: Christoph Lameter <cl@linux.com>
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 mm/slab_common.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/mm/slab_common.c
+++ b/mm/slab_common.c
@@ -55,7 +55,7 @@ static int kmem_cache_sanity_check(const
 			continue;
 		}
 
-#if !defined(CONFIG_SLUB) || !defined(CONFIG_SLUB_DEBUG_ON)
+#if !defined(CONFIG_SLUB)
 		if (!strcmp(s->name, name)) {
 			pr_err("%s (%s): Cache name already exists.\n",
 			       __func__, name);

[PATCH 3.15 19/37] Input: synaptics - add min/max quirk for pnp-id LEN2002 (Edge E531)

[Greg Kroah-Hartman]

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

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

From: Hans de Goede <hdegoede@redhat.com>

commit e76aed9da7189eeb41b9856552ce5721181e8e8d upstream.

https://bugzilla.redhat.com/show_bug.cgi?id=1114768

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/input/mouse/synaptics.c |    5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

--- a/drivers/input/mouse/synaptics.c
+++ b/drivers/input/mouse/synaptics.c
@@ -132,7 +132,8 @@ static const struct min_max_quirk min_ma
 		1232, 5710, 1156, 4696
 	},
 	{
-		(const char * const []){"LEN0034", "LEN0036", "LEN2004", NULL},
+		(const char * const []){"LEN0034", "LEN0036", "LEN2002",
+					"LEN2004", NULL},
 		1024, 5112, 2024, 4832
 	},
 	{
@@ -168,7 +169,7 @@ static const char * const topbuttonpad_p
 	"LEN0049",
 	"LEN2000",
 	"LEN2001", /* Edge E431 */
-	"LEN2002",
+	"LEN2002", /* Edge E531 */
 	"LEN2003",
 	"LEN2004", /* L440 */
 	"LEN2005",

[PATCH 3.15 20/37] Input: fix defuzzing logic

[Greg Kroah-Hartman]

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

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

From: Dmitry Torokhov <dtor@chromium.org>

commit 50c5d36dab930b1f1b1e3348b8608aa8b9ee7610 upstream.

We attempt to remove noise from coordinates reported by devices in
input_handle_abs_event(), unfortunately, unless we were dropping the
event altogether, we were ignoring the adjusted value and were passing
on the original value instead.

Reviewed-by: Andrew de los Reyes <adlr@chromium.org>
Reviewed-by: Benson Leung <bleung@chromium.org>
Reviewed-by: David Herrmann <dh.herrmann@gmail.com>
Reviewed-by: Henrik Rydberg <rydberg@euromail.se>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/input/input.c |    6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

--- a/drivers/input/input.c
+++ b/drivers/input/input.c
@@ -257,9 +257,10 @@ static int input_handle_abs_event(struct
 }
 
 static int input_get_disposition(struct input_dev *dev,
-			  unsigned int type, unsigned int code, int value)
+			  unsigned int type, unsigned int code, int *pval)
 {
 	int disposition = INPUT_IGNORE_EVENT;
+	int value = *pval;
 
 	switch (type) {
 
@@ -357,6 +358,7 @@ static int input_get_disposition(struct
 		break;
 	}
 
+	*pval = value;
 	return disposition;
 }
 
@@ -365,7 +367,7 @@ static void input_handle_event(struct in
 {
 	int disposition;
 
-	disposition = input_get_disposition(dev, type, code, value);
+	disposition = input_get_disposition(dev, type, code, &value);
 
 	if ((disposition & INPUT_PASS_TO_DEVICE) && dev->event)
 		dev->event(dev, type, code, value);

[PATCH 3.15 21/37] coredump: fix the setting of PF_DUMPCORE

[Greg Kroah-Hartman]

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

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

From: Silesh C V <svellattu@mvista.com>

commit aed8adb7688d5744cb484226820163af31d2499a upstream.

Commit 079148b919d0 ("coredump: factor out the setting of PF_DUMPCORE")
cleaned up the setting of PF_DUMPCORE by removing it from all the
linux_binfmt->core_dump() and moving it to zap_threads().But this ended
up clearing all the previously set flags.  This causes issues during
core generation when tsk->flags is checked again (eg.  for PF_USED_MATH
to dump floating point registers).  Fix this.

Signed-off-by: Silesh C V <svellattu@mvista.com>
Acked-by: Oleg Nesterov <oleg@redhat.com>
Cc: Mandeep Singh Baines <msb@chromium.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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

--- a/fs/coredump.c
+++ b/fs/coredump.c
@@ -306,7 +306,7 @@ static int zap_threads(struct task_struc
 	if (unlikely(nr < 0))
 		return nr;
 
-	tsk->flags = PF_DUMPCORE;
+	tsk->flags |= PF_DUMPCORE;
 	if (atomic_read(&mm->mm_users) == nr + 1)
 		goto done;
 	/*

[PATCH 3.15 22/37] fuse: s_time_gran fix

[Greg Kroah-Hartman]

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

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

From: Miklos Szeredi <mszeredi@suse.cz>

commit a800bad36619ce47ac0222004635448e6c91ff72 upstream.

Default s_time_gran is 1, don't overwrite that if userspace didn't
explicitly specify one.

Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 fs/fuse/inode.c |    3 ---
 1 file changed, 3 deletions(-)

--- a/fs/fuse/inode.c
+++ b/fs/fuse/inode.c
@@ -907,9 +907,6 @@ static void process_init_reply(struct fu
 				fc->writeback_cache = 1;
 			if (arg->time_gran && arg->time_gran <= 1000000000)
 				fc->sb->s_time_gran = arg->time_gran;
-			else
-				fc->sb->s_time_gran = 1000000000;
-
 		} else {
 			ra_pages = fc->max_read / PAGE_CACHE_SIZE;
 			fc->no_lock = 1;

[PATCH 3.15 23/37] fuse: add FUSE_NO_OPEN_SUPPORT flag to INIT

[Greg Kroah-Hartman]

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

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

From: Andrew Gallagher <andrewjcg@fb.com>

commit d7afaec0b564f0609e116f562983b8e72fc3e9c9 upstream.

Here some additional changes to set a capability flag so that clients can
detect when it's appropriate to return -ENOSYS from open.

This amends the following commit introduced in 3.14:

  7678ac50615d  fuse: support clients that don't implement 'open'

However we can only add the flag to 3.15 and later since there was no
protocol version update in 3.14.

Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 fs/fuse/inode.c           |    2 +-
 include/uapi/linux/fuse.h |    3 +++
 2 files changed, 4 insertions(+), 1 deletion(-)

--- a/fs/fuse/inode.c
+++ b/fs/fuse/inode.c
@@ -935,7 +935,7 @@ static void fuse_send_init(struct fuse_c
 		FUSE_SPLICE_WRITE | FUSE_SPLICE_MOVE | FUSE_SPLICE_READ |
 		FUSE_FLOCK_LOCKS | FUSE_IOCTL_DIR | FUSE_AUTO_INVAL_DATA |
 		FUSE_DO_READDIRPLUS | FUSE_READDIRPLUS_AUTO | FUSE_ASYNC_DIO |
-		FUSE_WRITEBACK_CACHE;
+		FUSE_WRITEBACK_CACHE | FUSE_NO_OPEN_SUPPORT;
 	req->in.h.opcode = FUSE_INIT;
 	req->in.numargs = 1;
 	req->in.args[0].size = sizeof(*arg);
--- a/include/uapi/linux/fuse.h
+++ b/include/uapi/linux/fuse.h
@@ -101,6 +101,7 @@
  *  - add FATTR_CTIME
  *  - add ctime and ctimensec to fuse_setattr_in
  *  - add FUSE_RENAME2 request
+ *  - add FUSE_NO_OPEN_SUPPORT flag
  */
 
 #ifndef _LINUX_FUSE_H
@@ -229,6 +230,7 @@ struct fuse_file_lock {
  * FUSE_READDIRPLUS_AUTO: adaptive readdirplus
  * FUSE_ASYNC_DIO: asynchronous direct I/O submission
  * FUSE_WRITEBACK_CACHE: use writeback cache for buffered writes
+ * FUSE_NO_OPEN_SUPPORT: kernel supports zero-message opens
  */
 #define FUSE_ASYNC_READ		(1 << 0)
 #define FUSE_POSIX_LOCKS	(1 << 1)
@@ -247,6 +249,7 @@ struct fuse_file_lock {
 #define FUSE_READDIRPLUS_AUTO	(1 << 14)
 #define FUSE_ASYNC_DIO		(1 << 15)
 #define FUSE_WRITEBACK_CACHE	(1 << 16)
+#define FUSE_NO_OPEN_SUPPORT	(1 << 17)
 
 /**
  * CUSE INIT request/reply flags

[PATCH 3.15 24/37] pinctrl: st: Fix irqmux handler

[Greg Kroah-Hartman]

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

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

From: Maxime COQUELIN <maxime.coquelin@st.com>

commit 7a2deccf0ef12f7f6e33150d5875020c0c94fa94 upstream.

st_gpio_irqmux_handler() reads the status register to find out
which banks inside the controller have pending IRQs.
For each banks having pending IRQs, it calls the corresponding handler.

Problem is that current code restricts the number of possible banks inside the
controller to ST_GPIO_PINS_PER_BANK. This define represents the number of pins
inside a bank, so it shouldn't be used here.

On STiH407, PIO_FRONT0 controller has 10 banks, so IRQs pending in the two
last banks (PIO18 & PIO19) aren't handled.

This patch replace ST_GPIO_PINS_PER_BANK by the number of banks inside the
controller.

Cc: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Signed-off-by: Maxime Coquelin <maxime.coquelin@st.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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

--- a/drivers/pinctrl/pinctrl-st.c
+++ b/drivers/pinctrl/pinctrl-st.c
@@ -1467,7 +1467,7 @@ static void st_gpio_irqmux_handler(unsig
 
 	status = readl(info->irqmux_base);
 
-	for_each_set_bit(n, &status, ST_GPIO_PINS_PER_BANK)
+	for_each_set_bit(n, &status, info->nbanks)
 		__gpio_irq_handler(&info->banks[n]);
 
 	chained_irq_exit(chip, desc);

[PATCH 3.15 25/37] parisc: Remove SA_RESTORER define

[Greg Kroah-Hartman]

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

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

From: John David Anglin <dave.anglin@bell.net>

commit 20dbea494543aefaace874cc3ec93a39b94b1ec4 upstream.

The sa_restorer field in struct sigaction is obsolete and no longer in
the parisc implementation.  However, the core code assumes the field is
present if SA_RESTORER is defined. So, the define needs to be removed.

Signed-off-by: John David Anglin <dave.anglin@bell.net>
Signed-off-by: Helge Deller <deller@gmx.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 arch/parisc/include/uapi/asm/signal.h |    2 --
 1 file changed, 2 deletions(-)

--- a/arch/parisc/include/uapi/asm/signal.h
+++ b/arch/parisc/include/uapi/asm/signal.h
@@ -69,8 +69,6 @@
 #define SA_NOMASK	SA_NODEFER
 #define SA_ONESHOT	SA_RESETHAND
 
-#define SA_RESTORER	0x04000000 /* obsolete -- ignored */
-
 #define MINSIGSTKSZ	2048
 #define SIGSTKSZ	8192
 

[PATCH 3.15 26/37] hwmon: (smsc47m192) Fix temperature limit and vrm write operations

[Greg Kroah-Hartman]

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

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

From: Guenter Roeck <linux@roeck-us.net>

commit 043572d5444116b9d9ad8ae763cf069e7accbc30 upstream.

Temperature limit clamps are applied after converting the temperature
from milli-degrees C to degrees C, so either the clamp limit needs
to be specified in degrees C, not milli-degrees C, or clamping must
happen before converting to degrees C. Use the latter method to avoid
overflows.

vrm is an u8, so the written value needs to be limited to [0, 255].

Cc: Axel Lin <axel.lin@ingics.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Reviewed-by: Jean Delvare <jdelvare@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/hwmon/smsc47m192.c |    4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

--- a/drivers/hwmon/smsc47m192.c
+++ b/drivers/hwmon/smsc47m192.c
@@ -86,7 +86,7 @@ static inline u8 IN_TO_REG(unsigned long
  */
 static inline s8 TEMP_TO_REG(int val)
 {
-	return clamp_val(SCALE(val, 1, 1000), -128000, 127000);
+	return SCALE(clamp_val(val, -128000, 127000), 1, 1000);
 }
 
 static inline int TEMP_FROM_REG(s8 val)
@@ -384,6 +384,8 @@ static ssize_t set_vrm(struct device *de
 	err = kstrtoul(buf, 10, &val);
 	if (err)
 		return err;
+	if (val > 255)
+		return -EINVAL;
 
 	data->vrm = val;
 	return count;

[PATCH 3.15 27/37] parport: fix menu breakage

[Greg Kroah-Hartman]

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

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

From: Randy Dunlap <rdunlap@infradead.org>

commit edffe1b626b39bd7121691dfdecb548431003bbb upstream.

Do not split the PARPORT-related symbols with the new kconfig
symbol ARCH_MIGHT_HAVE_PC_PARPORT. The split was causing incorrect
display of these symbols -- they were not being displayed together
as they should be.

Fixes: d90c3eb31535 "Kconfig cleanup (PARPORT_PC dependencies)"

Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Cc: Mark Salter <msalter@redhat.com>
Cc: Ingo Molnar <mingo@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/parport/Kconfig |   12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

--- a/drivers/parport/Kconfig
+++ b/drivers/parport/Kconfig
@@ -5,6 +5,12 @@
 # Parport configuration.
 #
 
+config ARCH_MIGHT_HAVE_PC_PARPORT
+	bool
+	help
+	  Select this config option from the architecture Kconfig if
+	  the architecture might have PC parallel port hardware.
+
 menuconfig PARPORT
 	tristate "Parallel port support"
 	depends on HAS_IOMEM
@@ -31,12 +37,6 @@ menuconfig PARPORT
 
 	  If unsure, say Y.
 
-config ARCH_MIGHT_HAVE_PC_PARPORT
-	bool
-	help
-	  Select this config option from the architecture Kconfig if
-	  the architecture might have PC parallel port hardware.
-
 if PARPORT
 
 config PARPORT_PC

[PATCH 3.15 28/37] fs: umount on symlink leaks mnt count

[Greg Kroah-Hartman]

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

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

From: Vasily Averin <vvs@parallels.com>

commit 295dc39d941dc2ae53d5c170365af4c9d5c16212 upstream.

Currently umount on symlink blocks following umount:

/vz is separate mount

# ls /vz/ -al | grep test
drwxr-xr-x.  2 root root       4096 Jul 19 01:14 testdir
lrwxrwxrwx.  1 root root         11 Jul 19 01:16 testlink -> /vz/testdir
# umount -l /vz/testlink
umount: /vz/testlink: not mounted (expected)

# lsof /vz
# umount /vz
umount: /vz: device is busy. (unexpected)

In this case mountpoint_last() gets an extra refcount on path->mnt

Signed-off-by: Vasily Averin <vvs@openvz.org>
Acked-by: Ian Kent <raven@themaw.net>
Acked-by: Jeff Layton <jlayton@primarydata.com>
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 fs/namei.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

--- a/fs/namei.c
+++ b/fs/namei.c
@@ -2256,9 +2256,10 @@ done:
 		goto out;
 	}
 	path->dentry = dentry;
-	path->mnt = mntget(nd->path.mnt);
+	path->mnt = nd->path.mnt;
 	if (should_follow_link(dentry, nd->flags & LOOKUP_FOLLOW))
 		return 1;
+	mntget(path->mnt);
 	follow_mount(path);
 	error = 0;
 out:

[PATCH 3.15 29/37] x86_32, entry: Store badsys error code in %eax

[Greg Kroah-Hartman]

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

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

From: Sven Wegener <sven.wegener@stealer.net>

commit 8142b215501f8b291a108a202b3a053a265b03dd upstream.

Commit 554086d ("x86_32, entry: Do syscall exit work on badsys
(CVE-2014-4508)") introduced a regression in the x86_32 syscall entry
code, resulting in syscall() not returning proper errors for undefined
syscalls on CPUs supporting the sysenter feature.

The following code:

> int result = syscall(666);
> printf("result=%d errno=%d error=%s\n", result, errno, strerror(errno));

results in:

> result=666 errno=0 error=Success

Obviously, the syscall return value is the called syscall number, but it
should have been an ENOSYS error. When run under ptrace it behaves
correctly, which makes it hard to debug in the wild:

> result=-1 errno=38 error=Function not implemented

The %eax register is the return value register. For debugging via ptrace
the syscall entry code stores the complete register context on the
stack. The badsys handlers only store the ENOSYS error code in the
ptrace register set and do not set %eax like a regular syscall handler
would. The old resume_userspace call chain contains code that clobbers
%eax and it restores %eax from the ptrace registers afterwards. The same
goes for the ptrace-enabled call chain. When ptrace is not used, the
syscall return value is the passed-in syscall number from the untouched
%eax register.

Use %eax as the return value register in syscall_badsys and
sysenter_badsys, like a real syscall handler does, and have the caller
push the value onto the stack for ptrace access.

Signed-off-by: Sven Wegener <sven.wegener@stealer.net>
Link: http://lkml.kernel.org/r/alpine.LNX.2.11.1407221022380.31021@titan.int.lan.stealer.net
Reviewed-and-tested-by: Andy Lutomirski <luto@amacapital.net>
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 arch/x86/kernel/entry_32.S |    9 +++++----
 1 file changed, 5 insertions(+), 4 deletions(-)

--- a/arch/x86/kernel/entry_32.S
+++ b/arch/x86/kernel/entry_32.S
@@ -433,8 +433,8 @@ sysenter_do_call:
 	cmpl $(NR_syscalls), %eax
 	jae sysenter_badsys
 	call *sys_call_table(,%eax,4)
-	movl %eax,PT_EAX(%esp)
 sysenter_after_call:
+	movl %eax,PT_EAX(%esp)
 	LOCKDEP_SYS_EXIT
 	DISABLE_INTERRUPTS(CLBR_ANY)
 	TRACE_IRQS_OFF
@@ -514,6 +514,7 @@ ENTRY(system_call)
 	jae syscall_badsys
 syscall_call:
 	call *sys_call_table(,%eax,4)
+syscall_after_call:
 	movl %eax,PT_EAX(%esp)		# store the return value
 syscall_exit:
 	LOCKDEP_SYS_EXIT
@@ -683,12 +684,12 @@ syscall_fault:
 END(syscall_fault)
 
 syscall_badsys:
-	movl $-ENOSYS,PT_EAX(%esp)
-	jmp syscall_exit
+	movl $-ENOSYS,%eax
+	jmp syscall_after_call
 END(syscall_badsys)
 
 sysenter_badsys:
-	movl $-ENOSYS,PT_EAX(%esp)
+	movl $-ENOSYS,%eax
 	jmp sysenter_after_call
 END(syscall_badsys)
 	CFI_ENDPROC

[PATCH 3.15 32/37] mm: hugetlb: fix copy_hugetlb_page_range()

[Greg Kroah-Hartman]

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

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

From: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>

commit 0253d634e0803a8376a0d88efee0bf523d8673f9 upstream.

Commit 4a705fef9862 ("hugetlb: fix copy_hugetlb_page_range() to handle
migration/hwpoisoned entry") changed the order of
huge_ptep_set_wrprotect() and huge_ptep_get(), which leads to breakage
in some workloads like hugepage-backed heap allocation via libhugetlbfs.
This patch fixes it.

The test program for the problem is shown below:

  $ cat heap.c
  #include <unistd.h>
  #include <stdlib.h>
  #include <string.h>

  #define HPS 0x200000

  int main() {
  	int i;
  	char *p = malloc(HPS);
  	memset(p, '1', HPS);
  	for (i = 0; i < 5; i++) {
  		if (!fork()) {
  			memset(p, '2', HPS);
  			p = malloc(HPS);
  			memset(p, '3', HPS);
  			free(p);
  			return 0;
  		}
  	}
  	sleep(1);
  	free(p);
  	return 0;
  }

  $ export HUGETLB_MORECORE=yes ; export HUGETLB_NO_PREFAULT= ; hugectl --heap ./heap

Fixes 4a705fef9862 ("hugetlb: fix copy_hugetlb_page_range() to handle
migration/hwpoisoned entry"), so is applicable to -stable kernels which
include it.

Signed-off-by: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
Reported-by: Guillaume Morin <guillaume@morinfr.org>
Suggested-by: Guillaume Morin <guillaume@morinfr.org>
Acked-by: Hugh Dickins <hughd@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 mm/hugetlb.c |    1 +
 1 file changed, 1 insertion(+)

--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -2461,6 +2461,7 @@ int copy_hugetlb_page_range(struct mm_st
 		} else {
 			if (cow)
 				huge_ptep_set_wrprotect(src, addr, src_pte);
+			entry = huge_ptep_get(src_pte);
 			ptepage = pte_page(entry);
 			get_page(ptepage);
 			page_dup_rmap(ptepage);

[PATCH 3.15 34/37] hwrng: virtio - ensure reads happen after successful probe

[Greg Kroah-Hartman]

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

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

From: Amit Shah <amit.shah@redhat.com>

commit e052dbf554610e2104c5a7518c4d8374bed701bb upstream.

The hwrng core asks for random data in the hwrng_register() call itself
from commit d9e7972619.  This doesn't play well with virtio -- the
DRIVER_OK bit is only set by virtio core on a successful probe, and
we're not yet out of our probe routine when this call is made.  This
causes the host to not acknowledge any requests we put in the virtqueue,
and the insmod or kernel boot process just waits for data to arrive from
the host, which never happens.

CC: Kees Cook <keescook@chromium.org>
CC: Jason Cooper <jason@lakedaemon.net>
CC: Herbert Xu <herbert@gondor.apana.org.au>
Reviewed-by: Jason Cooper <jason@lakedaemon.net>
Signed-off-by: Amit Shah <amit.shah@redhat.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/char/hw_random/core.c       |    6 ++++++
 drivers/char/hw_random/virtio-rng.c |   10 ++++++++++
 2 files changed, 16 insertions(+)

--- a/drivers/char/hw_random/core.c
+++ b/drivers/char/hw_random/core.c
@@ -68,6 +68,12 @@ static void add_early_randomness(struct
 	unsigned char bytes[16];
 	int bytes_read;
 
+	/*
+	 * Currently only virtio-rng cannot return data during device
+	 * probe, and that's handled in virtio-rng.c itself.  If there
+	 * are more such devices, this call to rng_get_data can be
+	 * made conditional here instead of doing it per-device.
+	 */
 	bytes_read = rng_get_data(rng, bytes, sizeof(bytes), 1);
 	if (bytes_read > 0)
 		add_device_randomness(bytes, bytes_read);
--- a/drivers/char/hw_random/virtio-rng.c
+++ b/drivers/char/hw_random/virtio-rng.c
@@ -30,6 +30,8 @@ static unsigned int data_avail;
 static DECLARE_COMPLETION(have_data);
 static bool busy;
 
+static bool probe_done;
+
 static void random_recv_done(struct virtqueue *vq)
 {
 	/* We can get spurious callbacks, e.g. shared IRQs + virtio_pci. */
@@ -56,6 +58,13 @@ static int virtio_read(struct hwrng *rng
 {
 	int ret;
 
+	/*
+	 * Don't ask host for data till we're setup.  This call can
+	 * happen during hwrng_register(), after commit d9e7972619.
+	 */
+	if (unlikely(!probe_done))
+		return 0;
+
 	if (!busy) {
 		busy = true;
 		init_completion(&have_data);
@@ -110,6 +119,7 @@ static int probe_common(struct virtio_de
 		return err;
 	}
 
+	probe_done = true;
 	return 0;
 }
 

[PATCH 3.15 35/37] mm: do not call do_fault_around for non-linear fault

[Greg Kroah-Hartman]

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

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

From: Konstantin Khlebnikov <koct9i@gmail.com>

commit c118678bc79e8241f9d3434d9324c6400d72f48a upstream.

Ingo Korb reported that "repeated mapping of the same file on tmpfs
using remap_file_pages sometimes triggers a BUG at mm/filemap.c:202 when
the process exits".

He bisected the bug to d7c1755179b8 ("mm: implement ->map_pages for
shmem/tmpfs"), although the bug was actually added by commit
8c6e50b0290c ("mm: introduce vm_ops->map_pages()").

The problem is caused by calling do_fault_around for a _non-linear_
fault.  In this case pgoff is shifted and might become negative during
calculation.

Faulting around non-linear page-fault makes no sense and breaks the
logic in do_fault_around because pgoff is shifted.

Signed-off-by: Konstantin Khlebnikov <koct9i@gmail.com>
Reported-by: Ingo Korb <ingo.korb@tu-dortmund.de>
Tested-by: Ingo Korb <ingo.korb@tu-dortmund.de>
Cc: Hugh Dickins <hughd@google.com>
Cc: Sasha Levin <sasha.levin@oracle.com>
Cc: Dave Jones <davej@redhat.com>
Cc: Ning Qu <quning@google.com>
Cc: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>


---
 mm/memory.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/mm/memory.c
+++ b/mm/memory.c
@@ -3515,7 +3515,7 @@ static int do_read_fault(struct mm_struc
 	 * if page by the offset is not ready to be mapped (cold cache or
 	 * something).
 	 */
-	if (vma->vm_ops->map_pages) {
+	if (vma->vm_ops->map_pages && !(flags & FAULT_FLAG_NONLINEAR)) {
 		pte = pte_offset_map_lock(mm, pmd, address, &ptl);
 		do_fault_around(vma, address, pte, pgoff, flags);
 		if (!pte_same(*pte, orig_pte))

[PATCH 3.15 36/37] nl80211: move set_qos_map command into split state

[Greg Kroah-Hartman]

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

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

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

commit 02df00eb0019e7d15a1fcddebe4d020226c1ccda upstream.

The non-split wiphy state shouldn't be increased in size
so move the new set_qos_map command into the split if
statement.

Fixes: fa9ffc745610 ("cfg80211: Add support for QoS mapping")
Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 net/wireless/nl80211.c |   11 +++++------
 1 file changed, 5 insertions(+), 6 deletions(-)

--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -1470,18 +1470,17 @@ static int nl80211_send_wiphy(struct cfg
 		}
 		CMD(start_p2p_device, START_P2P_DEVICE);
 		CMD(set_mcast_rate, SET_MCAST_RATE);
+#ifdef CONFIG_NL80211_TESTMODE
+		CMD(testmode_cmd, TESTMODE);
+#endif
 		if (state->split) {
 			CMD(crit_proto_start, CRIT_PROTOCOL_START);
 			CMD(crit_proto_stop, CRIT_PROTOCOL_STOP);
 			if (dev->wiphy.flags & WIPHY_FLAG_HAS_CHANNEL_SWITCH)
 				CMD(channel_switch, CHANNEL_SWITCH);
+			CMD(set_qos_map, SET_QOS_MAP);
 		}
-		CMD(set_qos_map, SET_QOS_MAP);
-
-#ifdef CONFIG_NL80211_TESTMODE
-		CMD(testmode_cmd, TESTMODE);
-#endif
-
+		/* add into the if now */
 #undef CMD
 
 		if (dev->ops->connect || dev->ops->auth) {

[PATCH 3.15 37/37] platform_get_irq: Revert to platform_get_resource if of_irq_get fails

[Greg Kroah-Hartman]

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

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

From: Guenter Roeck <linux@roeck-us.net>

commit aff008ad813c7cf3cfe7b532e7ba2c526c136f22 upstream.

Commits 9ec36ca (of/irq: do irq resolution in platform_get_irq)
and ad69674 (of/irq: do irq resolution in platform_get_irq_byname)
change the semantics of platform_get_irq and platform_get_irq_byname
to always rely on devicetree information if devicetree is enabled
and if a devicetree node is attached to the device. The functions
now return an error if the devicetree data does not include interrupt
information, even if the information is available as platform resource
data.

This causes mfd client drivers to fail if the interrupt number is
passed via platform resources. Therefore, if of_irq_get fails, try
platform_get_resource as method of last resort. This restores the
original functionality for drivers depending on platform resources
to get irq information.

Cc: Russell King <linux@arm.linux.org.uk>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Grant Likely <grant.likely@linaro.org>
Cc: Grygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Acked-by: Rob Herring <robh@kernel.org>
[ Guenter Roeck: backported to 3.15 ]
Signed-off-by: Guenter Roeck <linux@roeck-us.net>

---
 drivers/base/platform.c |    9 +++++++--
 1 file changed, 7 insertions(+), 2 deletions(-)

--- a/drivers/base/platform.c
+++ b/drivers/base/platform.c
@@ -89,8 +89,13 @@ int platform_get_irq(struct platform_dev
 	return dev->archdata.irqs[num];
 #else
 	struct resource *r;
-	if (IS_ENABLED(CONFIG_OF_IRQ) && dev->dev.of_node)
-		return of_irq_get(dev->dev.of_node, num);
+	if (IS_ENABLED(CONFIG_OF_IRQ) && dev->dev.of_node) {
+		int ret;
+
+		ret = of_irq_get(dev->dev.of_node, num);
+		if (ret >= 0 || ret == -EPROBE_DEFER)
+			return ret;
+	}
 
 	r = platform_get_resource(dev, IORESOURCE_IRQ, num);
 

Re: [PATCH 3.15 33/37] Fix gcc-4.9.0 miscompilation of load_balance() in scheduler

[Jakub Jelinek]

On Tue, Jul 29, 2014 at 06:49:09PM -0700, Greg Kroah-Hartman wrote:
> 3.15-stable review patch.  If anyone has any objections, please let me know.

IMNSHO this is a too big hammer approach.  The bug happened on a single
file only (right?), so if anything, IMHO it could be disabled for that
single file only, and better do it only for compilers with the bug.
If there are wrong code bugs with -O2 (we've fixed many in the past), you
also don't turn off -O2 everywhere, similarly for -Os or any other options.
Disabling it just in case the same bug happens elsewhere when it actually
took 5 years before the bug caused miscompilation of something is too
defensive.  We had at least 15 other wrong-code bugfixes just in between
4.9.0 and 4.9.1.  -fvar-tracking-assignments doesn't make a small difference
in debug info, but significant for optimized code.
If you build the kernel without and with -fno-var-tracking-assignments,
you can use e.g. the dwlocstat tool to see what kind of difference it makes
for the kernel in particular in variable debug info coverage.
> 
> --- a/Makefile
> +++ b/Makefile
> @@ -669,6 +669,8 @@ KBUILD_CFLAGS	+= -fomit-frame-pointer
>  endif
>  endif
>  
> +KBUILD_CFLAGS   += $(call cc-option, -fno-var-tracking-assignments)
> +
>  ifdef CONFIG_DEBUG_INFO
>  KBUILD_CFLAGS	+= -g
>  KBUILD_AFLAGS	+= -Wa,--gdwarf-2
> 

	Jakub

Re: [PATCH 3.15 33/37] Fix gcc-4.9.0 miscompilation of load_balance() in scheduler

[Markus Trippelsdorf]

On 2014.07.30 at 08:53 +0200, Jakub Jelinek wrote:
> On Tue, Jul 29, 2014 at 06:49:09PM -0700, Greg Kroah-Hartman wrote:
> > 3.15-stable review patch.  If anyone has any objections, please let me know.
> 
> IMNSHO this is a too big hammer approach.  The bug happened on a single
> file only (right?), so if anything, IMHO it could be disabled for that
> single file only, and better do it only for compilers with the bug.

No. There are many more files affected. It just happens that Linus
analyzed the assembly of this single file (fair.c) and found a bug. 
Just build your redhat distro kernel with GCC_COMPARE_DEBUG=1 and you'll
see. So unless someone analyzes the assembly output of all other
affected files by hand and finds no issues, one has to assume the worst.

> If there are wrong code bugs with -O2 (we've fixed many in the past), you
> also don't turn off -O2 everywhere, similarly for -Os or any other options.
> Disabling it just in case the same bug happens elsewhere when it actually
> took 5 years before the bug caused miscompilation of something is too
> defensive.  We had at least 15 other wrong-code bugfixes just in between
> 4.9.0 and 4.9.1.  -fvar-tracking-assignments doesn't make a small difference
> in debug info, but significant for optimized code.
> If you build the kernel without and with -fno-var-tracking-assignments,
> you can use e.g. the dwlocstat tool to see what kind of difference it makes
> for the kernel in particular in variable debug info coverage.

I'm sure it would be possible to backport a proper check based on the
gcc testcase to the stable kernels, once it gets implemented.

-- 
Markus

Re: [PATCH 3.15 33/37] Fix gcc-4.9.0 miscompilation of load_balance() in scheduler

[Jakub Jelinek]

On Wed, Jul 30, 2014 at 09:13:08AM +0200, Markus Trippelsdorf wrote:
> On 2014.07.30 at 08:53 +0200, Jakub Jelinek wrote:
> > On Tue, Jul 29, 2014 at 06:49:09PM -0700, Greg Kroah-Hartman wrote:
> > > 3.15-stable review patch.  If anyone has any objections, please let me know.
> > 
> > IMNSHO this is a too big hammer approach.  The bug happened on a single
> > file only (right?), so if anything, IMHO it could be disabled for that
> > single file only, and better do it only for compilers with the bug.
> 
> No. There are many more files affected. It just happens that Linus
> analyzed the assembly of this single file (fair.c) and found a bug. 
> Just build your redhat distro kernel with GCC_COMPARE_DEBUG=1 and you'll
> see. So unless someone analyzes the assembly output of all other
> affected files by hand and finds no issues, one has to assume the worst.

I'm talking about wrong-code issues.  For -fcompare-debug, we indeed check
it primarily during gcc bootstrap (through bootstrap-debug) and some
testcases, and we'll certainly try to build some more code with
-fcompare-debug and fix the issues.

	Jakub

Re: [PATCH 3.15 33/37] Fix gcc-4.9.0 miscompilation of load_balance() in scheduler

[Markus Trippelsdorf]

On 2014.07.30 at 09:21 +0200, Jakub Jelinek wrote:
> On Wed, Jul 30, 2014 at 09:13:08AM +0200, Markus Trippelsdorf wrote:
> > On 2014.07.30 at 08:53 +0200, Jakub Jelinek wrote:
> > > On Tue, Jul 29, 2014 at 06:49:09PM -0700, Greg Kroah-Hartman wrote:
> > > > 3.15-stable review patch.  If anyone has any objections, please let me know.
> > > 
> > > IMNSHO this is a too big hammer approach.  The bug happened on a single
> > > file only (right?), so if anything, IMHO it could be disabled for that
> > > single file only, and better do it only for compilers with the bug.
> > 
> > No. There are many more files affected. It just happens that Linus
> > analyzed the assembly of this single file (fair.c) and found a bug. 
> > Just build your redhat distro kernel with GCC_COMPARE_DEBUG=1 and you'll
> > see. So unless someone analyzes the assembly output of all other
> > affected files by hand and finds no issues, one has to assume the worst.
> 
> I'm talking about wrong-code issues.  For -fcompare-debug, we indeed check
> it primarily during gcc bootstrap (through bootstrap-debug) and some
> testcases, and we'll certainly try to build some more code with
> -fcompare-debug and fix the issues.

Yes, I'm talking about wrong-code issues, too. For example the pr61801.c
testcase was reduced from kernel/exit.c.

-- 
Markus

Re: [PATCH 3.15 33/37] Fix gcc-4.9.0 miscompilation of load_balance() in scheduler

[Linus Torvalds]

On Tue, Jul 29, 2014 at 11:53 PM, Jakub Jelinek <jakub@redhat.com> wrote:
>
> IMNSHO this is a too big hammer approach.  The bug happened on a single
> file only (right?)

Very dubious. We happened to see it in a single case, and _maybe_ that
was the only one in the whole kernel. But it's much more likely that
it wasn't - it's not like the code in question was even all that
unusual (just a percpu access triggering an asm - but we have tons of
asms in the kernel).

I'd argue that we were very lucky to get the problem happening
reliably enough for a couple of people who then cared enoiugh to do
good bug reports (considering that it needed an interrupt in *just*
the right place) that we could debug it at all. In some code that gets
run much less than the scheduler, it could easily have been one of
those "people report it once in a blue moon, looks like memory
corruption".

Now, it would be interesting to hear if there is something very
special that made that instruction scheduling bug trigger just for
4.9.x, or if there is something else that made it very particular to
that code sequence. But in the absence of good reasoning to the
contrary, I'd much rather say "let's just avoid the bug entirely".

And that's partly because we really don't care that much about the
debug info. Yes, it gets used, but it's not *that* common, and the
last time the issue of debug info sucking up tons of resources came
up, the biggest users were people who just wanted line information for
oopses. Yes, there are people running kgdb etc, but on the whole it's
rare, and quite frankly, from everything I have _ever_ seen, that's
not how the real kernel bugs are ever really discovered. So the kind
of debug information that the variable tracking logic adds just isn't
all that important for the kernel.

                 Linus

Re: [PATCH 3.15 33/37] Fix gcc-4.9.0 miscompilation of load_balance() in scheduler

[Josh Boyer]

On Wed, Jul 30, 2014 at 11:47 AM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> On Tue, Jul 29, 2014 at 11:53 PM, Jakub Jelinek <jakub@redhat.com> wrote:
>>
>> IMNSHO this is a too big hammer approach.  The bug happened on a single
>> file only (right?)
>
> Very dubious. We happened to see it in a single case, and _maybe_ that
> was the only one in the whole kernel. But it's much more likely that
> it wasn't - it's not like the code in question was even all that
> unusual (just a percpu access triggering an asm - but we have tons of
> asms in the kernel).
>
> I'd argue that we were very lucky to get the problem happening
> reliably enough for a couple of people who then cared enoiugh to do
> good bug reports (considering that it needed an interrupt in *just*
> the right place) that we could debug it at all. In some code that gets
> run much less than the scheduler, it could easily have been one of
> those "people report it once in a blue moon, looks like memory
> corruption".
>
> Now, it would be interesting to hear if there is something very
> special that made that instruction scheduling bug trigger just for
> 4.9.x, or if there is something else that made it very particular to
> that code sequence. But in the absence of good reasoning to the
> contrary, I'd much rather say "let's just avoid the bug entirely".
>
> And that's partly because we really don't care that much about the
> debug info. Yes, it gets used, but it's not *that* common, and the
> last time the issue of debug info sucking up tons of resources came
> up, the biggest users were people who just wanted line information for
> oopses. Yes, there are people running kgdb etc, but on the whole it's
> rare, and quite frankly, from everything I have _ever_ seen, that's
> not how the real kernel bugs are ever really discovered. So the kind
> of debug information that the variable tracking logic adds just isn't
> all that important for the kernel.

Sorry to bring this back up after the fact, but it's important for a
number of things in various distros.  I don't disagree it should be
disabled by default, but making it unconditional is going to force the
distributions that care about perf, systemtap, and debuggers to
manually revert this.  That deviation is concerning because the
upstream kernel won't easily be buildable the same way distros build
it.

I'm happy to come up with a config option patch, but I'm not sure if
it would be accepted.  Is that a possibility at this point?

josh

Re: [PATCH 3.15 33/37] Fix gcc-4.9.0 miscompilation of load_balance() in scheduler

[Markus Trippelsdorf]

On 2014.08.05 at 07:31 -0400, Josh Boyer wrote:
> Sorry to bring this back up after the fact, but it's important for a
> number of things in various distros.  I don't disagree it should be
> disabled by default, but making it unconditional is going to force the
> distributions that care about perf, systemtap, and debuggers to
> manually revert this.  That deviation is concerning because the
> upstream kernel won't easily be buildable the same way distros build
> it.
> 
> I'm happy to come up with a config option patch, but I'm not sure if
> it would be accepted.  Is that a possibility at this point?

Please note that https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61923
isn't fixed yet. So it would be premature to manually revert Linus'
patch yet. 

When PR61923 gets fixed (and backported) its testcase could be combined
with the testcase Jakub posted earlier in this thread.

-- 
Markus

Re: [PATCH 3.15 33/37] Fix gcc-4.9.0 miscompilation of load_balance() in scheduler

[Jakub Jelinek]

On Tue, Aug 05, 2014 at 01:46:49PM +0200, Markus Trippelsdorf wrote:
> On 2014.08.05 at 07:31 -0400, Josh Boyer wrote:
> > Sorry to bring this back up after the fact, but it's important for a
> > number of things in various distros.  I don't disagree it should be
> > disabled by default, but making it unconditional is going to force the
> > distributions that care about perf, systemtap, and debuggers to
> > manually revert this.  That deviation is concerning because the
> > upstream kernel won't easily be buildable the same way distros build
> > it.
> > 
> > I'm happy to come up with a config option patch, but I'm not sure if
> > it would be accepted.  Is that a possibility at this point?
> 
> Please note that https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61923

But that isn't a wrong-code bug, in some cases it is no code generation difference
between -g and -g0 at all (just :TI on the dumps being different), in some
cases it can affect scheduling decisions for real, but still not in a way
that disregards the actual dependencies in between instructions.  You can
get such scheduling differences also if you just use slightly different
compiler revision.

> isn't fixed yet. So it would be premature to manually revert Linus'
> patch yet. 
> 
> When PR61923 gets fixed (and backported) its testcase could be combined
> with the testcase Jakub posted earlier in this thread.

Just some data to show that the debug info differences are nothing close to
insignificant.  I've built a 3.16 kernel (from Fedora 21 rpm) both normally
(which includes the -fno-var-tracking-assignments change) and with that line
in Makefile commented out.  E.g. on fs/ext4/ext4.o, dwlocstat says for
-fno-var-tracking-assignments:
dwlocstat --tabulate=0.0:10,99,100 fs/ext4/ext4.o
cov%	samples	cumul
0.0	19620/75%	19620/75%
0..10	518/1%	20138/77%
11..20	317/1%	20455/78%
21..30	362/1%	20817/79%
31..40	349/1%	21166/81%
41..50	240/0%	21406/82%
51..60	297/1%	21703/83%
61..70	293/1%	21996/84%
71..80	355/1%	22351/85%
81..90	402/1%	22753/87%
91..99	901/3%	23654/90%
100	2425/9%	26079/100%
and without it:
dwlocstat --tabulate=0.0:10,99,100 fs/ext4/ext4.o
cov%	samples	cumul
0.0	8697/33%	8697/33%
0..10	431/1%	9128/35%
11..20	371/1%	9499/36%
21..30	608/2%	10107/38%
31..40	525/2%	10632/40%
41..50	461/1%	11093/42%
51..60	881/3%	11974/45%
61..70	678/2%	12652/48%
71..80	894/3%	13546/51%
81..90	1036/3%	14582/55%
91..99	949/3%	15531/59%
100	10548/40%	26079/100%

So, with -fno-var-tracking-assignments, about 75% of parameters/variables have
no location info at all in ext4.o, 9% of parameters/variables have coverage
for all instructions where the parameter/variable is in scope, the rest
something in between.  Without -fno-var-tracking-assignments, only 33% of
params/vars have no location info at all, and 40% have coverage on all
instructions where they are in scope.  Even for the params/vars without 100%
coverage there can be seen improvements, e.g. in the 51%-90% coverage.

Or e.g. -fno-var-tracking-assignments:
dwlocstat --tabulate=0.0:10,99,100 lib/built-in.o
cov%	samples	cumul
0.0	6323/64%	6323/64%
0..10	144/1%	6467/66%
11..20	138/1%	6605/67%
21..30	123/1%	6728/68%
31..40	144/1%	6872/70%
41..50	169/1%	7041/72%
51..60	130/1%	7171/73%
61..70	146/1%	7317/74%
71..80	198/2%	7515/76%
81..90	258/2%	7773/79%
91..99	541/5%	8314/85%
100	1448/14%	9762/100%
without -fno-var-tracking-assignments:
dwlocstat --tabulate=0.0:10,99,100 lib/built-in.o
cov%	samples	cumul
0.0	2954/30%	2954/30%
0..10	131/1%	3085/31%
11..20	110/1%	3195/32%
21..30	141/1%	3336/34%
31..40	212/2%	3548/36%
41..50	226/2%	3774/38%
51..60	254/2%	4028/41%
61..70	237/2%	4265/43%
71..80	325/3%	4590/47%
81..90	420/4%	5010/51%
91..99	425/4%	5435/55%
100	4328/44%	9763/100%

It is visible also e.g. in the section sizes on vmlinux:
-fno-var-tracking-assignments:
readelf -WS vmlinux 2>&1 | awk '/\.debug_/{printf "%s %fMB\n", $2, strtonum("0x"$6)/1024.0/1024.0}'
.debug_aranges 0.115387MB
.debug_info 96.625183MB
.debug_abbrev 2.585021MB
.debug_line 5.936069MB
.debug_frame 1.710655MB
.debug_str 1.956143MB
.debug_loc 8.713246MB
.debug_ranges 3.020081MB
without -fno-var-tracking-assignments:
readelf -WS vmlinux 2>&1 | awk '/\.debug_/{printf "%s %fMB\n", $2, strtonum("0x"$6)/1024.0/1024.0}'
.debug_aranges 0.115387MB
.debug_info 99.564449MB
.debug_abbrev 2.665213MB
.debug_line 5.936069MB
.debug_frame 1.710655MB
.debug_str 1.955960MB
.debug_loc 22.607447MB
.debug_ranges 3.020264MB

.debug_info growth is only very small (not even 3MB), only few vars have the
same value everywhere, but .debug_loc growth is significant (2.6 times
bigger).

	Jakub

Re: [PATCH 3.15 33/37] Fix gcc-4.9.0 miscompilation of load_balance() in scheduler

[Greg Kroah-Hartman]

On Tue, Aug 05, 2014 at 07:31:22AM -0400, Josh Boyer wrote:
> On Wed, Jul 30, 2014 at 11:47 AM, Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
> > On Tue, Jul 29, 2014 at 11:53 PM, Jakub Jelinek <jakub@redhat.com> wrote:
> >>
> >> IMNSHO this is a too big hammer approach.  The bug happened on a single
> >> file only (right?)
> >
> > Very dubious. We happened to see it in a single case, and _maybe_ that
> > was the only one in the whole kernel. But it's much more likely that
> > it wasn't - it's not like the code in question was even all that
> > unusual (just a percpu access triggering an asm - but we have tons of
> > asms in the kernel).
> >
> > I'd argue that we were very lucky to get the problem happening
> > reliably enough for a couple of people who then cared enoiugh to do
> > good bug reports (considering that it needed an interrupt in *just*
> > the right place) that we could debug it at all. In some code that gets
> > run much less than the scheduler, it could easily have been one of
> > those "people report it once in a blue moon, looks like memory
> > corruption".
> >
> > Now, it would be interesting to hear if there is something very
> > special that made that instruction scheduling bug trigger just for
> > 4.9.x, or if there is something else that made it very particular to
> > that code sequence. But in the absence of good reasoning to the
> > contrary, I'd much rather say "let's just avoid the bug entirely".
> >
> > And that's partly because we really don't care that much about the
> > debug info. Yes, it gets used, but it's not *that* common, and the
> > last time the issue of debug info sucking up tons of resources came
> > up, the biggest users were people who just wanted line information for
> > oopses. Yes, there are people running kgdb etc, but on the whole it's
> > rare, and quite frankly, from everything I have _ever_ seen, that's
> > not how the real kernel bugs are ever really discovered. So the kind
> > of debug information that the variable tracking logic adds just isn't
> > all that important for the kernel.
> 
> Sorry to bring this back up after the fact, but it's important for a
> number of things in various distros.  I don't disagree it should be
> disabled by default, but making it unconditional is going to force the
> distributions that care about perf, systemtap, and debuggers to
> manually revert this.  That deviation is concerning because the
> upstream kernel won't easily be buildable the same way distros build
> it.

Why does this patch affect perf and other debuggers?

thanks,

greg k-h

Re: [PATCH 3.15 33/37] Fix gcc-4.9.0 miscompilation of load_balance() in scheduler

[Linus Torvalds]

On Tue, Aug 5, 2014 at 4:31 AM, Josh Boyer <jwboyer@fedoraproject.org> wrote:
>
> Sorry to bring this back up after the fact, but it's important for a
> number of things in various distros

You said that before, and I ignored you before, because you didn't
actually give any examples.

>.  I don't disagree it should be
> disabled by default, but making it unconditional is going to force the
> distributions that care about perf, systemtap, and debuggers to
> manually revert this.

Bah. I bet I use 'perf' more than most, and it doesn't care about
debug info. Sure, if you want the annotated source code, or put probes
in place, you want the line number information, but the amount of
debug information it needs is miniscule, and not impacted bu this at
all afaik.

And systemtap people have more problems than this.

Debuggers? Again, people who actually use kgdb have bigger issues than
some slightly worse local variable tracking.  People care about the
frame pointer information and type information, but if you use kgdb on
the kernel you can damn well look at the assembly code and source code
annotation for local variable information.

So I call bullshit. Give a real example of real-world use, not some
random handwaving of cases that happen to use debug info but - at
least for the kernel - don't actually care about the variable
tracking.

The variable tracking is absolutely the *least* important part of the
debug info. By a huge margin. To the point of being entirely
irrelevant for the kernel. You make it sound like you lose all debug
information, when in reality that's not the case at all.

Trust me, you lose *way* more debug information because the kernel
uses "-O2" rather than "-O".

               Linus

Re: [PATCH 3.15 33/37] Fix gcc-4.9.0 miscompilation of load_balance() in scheduler

[Josh Boyer]

On Tue, Aug 5, 2014 at 12:49 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> On Tue, Aug 5, 2014 at 4:31 AM, Josh Boyer <jwboyer@fedoraproject.org> wrote:
>>
>> Sorry to bring this back up after the fact, but it's important for a
>> number of things in various distros
>
> You said that before, and I ignored you before, because you didn't
> actually give any examples.

Actually, I haven't said anything on this until now.  You are perhaps
thinking of someone else.  I haven't participated in this thread until
today.

>>.  I don't disagree it should be
>> disabled by default, but making it unconditional is going to force the
>> distributions that care about perf, systemtap, and debuggers to
>> manually revert this.
>
> Bah. I bet I use 'perf' more than most, and it doesn't care about
> debug info. Sure, if you want the annotated source code, or put probes
> in place, you want the line number information, but the amount of
> debug information it needs is miniscule, and not impacted bu this at
> all afaik.
>
> And systemtap people have more problems than this.

They might have more problems, but they're telling me this breaks
systemtap full stop.  AFAIK, systemtap needs to put probes in place
for it to work.  I've added a couple systemtap developers on CC again,
and Jakub has an earlier post as well.  Hopefully they can expand upon
it.  If they can't, then things become simpler.

> Debuggers? Again, people who actually use kgdb have bigger issues than
> some slightly worse local variable tracking.  People care about the
> frame pointer information and type information, but if you use kgdb on
> the kernel you can damn well look at the assembly code and source code
> annotation for local variable information.
>
> So I call bullshit. Give a real example of real-world use, not some
> random handwaving of cases that happen to use debug info but - at
> least for the kernel - don't actually care about the variable
> tracking.

I'm not here to convince you that kernel developers need this option
set.  I doubt they do, and I'm not sure I could make a convincing
argument around that anyway.  But I'm also being told by the teams I
work with that this breaks something that previously worked for them,
and I'm asking if it can be conditionally enabled instead of blindly
defaulting to off.  Distros do terrible things like patch their gcc
with pre-release patches to fix issues, and giving the distros the
option of enabling this is all I'm after.

> The variable tracking is absolutely the *least* important part of the
> debug info. By a huge margin. To the point of being entirely
> irrelevant for the kernel. You make it sound like you lose all debug
> information, when in reality that's not the case at all.

I don't think I said that.  I said distros that care about the things
this enables in perf and systemtap are going to have to carry a revert
(assuming what I've been told is valid).  It's unnecessary deviation
form upstream because you decided you didn't give a crap about this
particular thing and thinks it's a waste of time.  Frankly, I don't
give a crap about it either but I do give a crap about people no
longer being able to use my distro kernels without that revert for
something that worked just fine before.  The distro knows when their
gcc packages have been fixed.

> Trust me, you lose *way* more debug information because the kernel
> uses "-O2" rather than "-O".

I'm not arguing it's useful.  I'm asking you to let distros to
continue to make the horrible choices they make so the things they
ship will work.  I don't think that's being unreasonable.

josh

Re: [PATCH 3.15 33/37] Fix gcc-4.9.0 miscompilation of load_balance() in scheduler

[Frank Ch. Eigler]

Hi -

> >>.  I don't disagree it should be
> >> disabled by default, but making it unconditional is going to force the
> >> distributions that care about perf, systemtap, and debuggers to
> >> manually revert this.
> >
> > Bah. I bet I use 'perf' more than most, and it doesn't care about
> > debug info. 

Actually, "perf probe" does (via HAVE_DWARF_SUPPORT), to place probes
and to extract variables at those probes, much as systemtap does.
Without var-tracking, probes placed at most interior points of
functions will make variables inaccessible.

Do you need a fully worked out example to see this?

- FChE

Re: [PATCH 3.15 33/37] Fix gcc-4.9.0 miscompilation of load_balance() in scheduler

[Linus Torvalds]

On Tue, Aug 5, 2014 at 2:07 PM, Frank Ch. Eigler <fche@redhat.com> wrote:
>
> Actually, "perf probe" does (via HAVE_DWARF_SUPPORT), to place probes
> and to extract variables at those probes, much as systemtap does.
> Without var-tracking, probes placed at most interior points of
> functions will make variables inaccessible.

.. and as mentioned, -O2 already does that for many things, even
*with* tracking.

In other words, anybody who relies on it has already learnt to work
around it. Or, more likely, there just isn't anybody who relies on it.

I don't understand how you guys can be so cavalier about a compiler
bug that has already resulted in actual real problems. You bring up
theoretical cases that nobody has actually reported, and are
apparently ignoring the fact that the compiler generates INCORRECT
CODE. So on one hand we have known breakage, on the other we have
theoretical "I can make an example" arguments of behavior that no sane
user has ever done.

Do you compile without -O2 too? Because I *guarantee* you that with
-O2 (even with tracking), you'll get "local variable 'xyz' optimized
away" cases.

Christ.

I have asked the compiler people at least twice whether there is some
way to limit it to just gcc-4.9.0/1, but the compiler people didn't
step up and say that it was safe.

In the meantime, crazy people can choose to compile with known-broken
compilers. Until you can get the compiler people to have some sane way
to know the problem is gone, I'm not going to maintain a kernel that
uses a known-broken compiler feature. It's that simple.

              Linus

Re: [PATCH 3.15 33/37] Fix gcc-4.9.0 miscompilation of load_balance() in scheduler

[Frank Ch. Eigler]

Hi -

On Tue, Aug 05, 2014 at 03:36:39PM -0700, Linus Torvalds wrote:
> > Actually, "perf probe" does (via HAVE_DWARF_SUPPORT), to place probes
> > and to extract variables at those probes, much as systemtap does.
> > Without var-tracking, probes placed at most interior points of
> > functions will make variables inaccessible.
> 
> .. and as mentioned, -O2 already does that for many things, even
> *with* tracking.

The whole point of variable tracking was to make -O2 usable (though
still imperfect) for those who use debuggers and such tools.


> [...]  I don't understand how you guys can be so cavalier about a
> compiler bug that has already resulted in actual real problems.

No one is minimizing the problem.  We are looking for a knob for those
who know that their compiler does not have that bug.  (Plus, those who
don't care about debug data could use CONFIG_DEBUG_INFO=n with the bad
compiler.)


> You bring up theoretical cases that nobody has actually reported
> [...]

I assure you that the years of effort that went into gcc variable
tracking was justified with actual reports.


> Do you compile without -O2 too? Because I *guarantee* you that with
> -O2 (even with tracking), you'll get "local variable 'xyz' optimized
> away" cases.

One gets many fewer than without it, and also fewer false positives
(where the non-var-tracking debuginfo claims a variable may be
available, but points to the wrong place).


> [...]  Until you can get the compiler people to have some sane way
> to know the problem is gone, I'm not going to maintain a kernel that
> uses a known-broken compiler feature. It's that simple.

Would you consider a patch that does a gcc COMPARE_DEBUG-based test?


- FChE

Re: [PATCH 3.15 33/37] Fix gcc-4.9.0 miscompilation of load_balance() in scheduler

[Linus Torvalds]

On Tue, Aug 5, 2014 at 4:30 PM, Frank Ch. Eigler <fche@redhat.com> wrote:
>
> Would you consider a patch that does a gcc COMPARE_DEBUG-based test?

Yes. But as mentioned, we don't have a really good way to do that. I
guess we can do something similar to what "cc-option" does, but that
will end up doing it for every single kernel build. I'd love to have
something like this be done at kconfig time (along with all the
*other* crazy conditional compiler options we do), but I guess that's
a largely independent issue.

And afaik, it will basically disallow every gcc version since 4.5 up
until 4.9.2 gets released. And afaik, even current gcc actually fails
the compare-debug test for at least some inputs, so ...

                 Linus

[PATCH] Kbuild: Add an option to enable GCC VTA

[Josh Stone]

Due to recent codegen issues, gcc -fvar-tracking-assignments was
unconditionally disabled in commit 2062afb4f804a ("Fix gcc-4.9.0
miscompilation of load_balance() in scheduler").  However, this reduces
the debuginfo coverage for variable locations, especially in inline
functions.  VTA is certainly not perfect either in those cases, but it
is much better than without.  With compiler versions that have fixed the
codegen bugs, we would prefer to have the better details for SystemTap,
and surely other debuginfo consumers like perf will benefit as well.

This patch simply makes CONFIG_DEBUG_INFO_VTA an option.  I considered
Frank and Linus's discussion of a cc-option-like -fcompare-debug test,
but I'm convinced that a narrow test of an arch-specific codegen issue
is not really useful.  GCC has their own regression tests for this, so
I'd suggest GCC_COMPARE_DEBUG=-fvar-tracking-assignments-toggle is more
useful for kernel developers to test confidence.

In fact, I ran into a couple more issues when testing for this patch[1],
although neither of those had any codegen impact.
 [1] https://bugzilla.redhat.com/show_bug.cgi?id=1140872

With gcc-4.9.1-11.fc22, I can now build 3.17 with Fedora's i686 and
x86_64 configs, and this is completely clean with GCC_COMPARE_DEBUG.

Cc: Frank Ch. Eigler <fche@redhat.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Jakub Jelinek <jakub@redhat.com>
Cc: Josh Boyer <jwboyer@fedoraproject.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Markus Trippelsdorf <markus@trippelsdorf.de>
Cc: Michel Dänzer <michel@daenzer.net>
Signed-off-by: Josh Stone <jistone@redhat.com>
---
 Makefile          |  4 ++++
 lib/Kconfig.debug | 18 +++++++++++++++++-
 2 files changed, 21 insertions(+), 1 deletion(-)

diff --git a/Makefile b/Makefile
index b77de27e58fc..dc107248beb5 100644
--- a/Makefile
+++ b/Makefile
@@ -709,7 +709,11 @@ KBUILD_CFLAGS	+= -fomit-frame-pointer
 endif
 endif
 
+ifdef CONFIG_DEBUG_INFO_VTA
+KBUILD_CFLAGS   += $(call cc-option, -fvar-tracking-assignments)
+else
 KBUILD_CFLAGS   += $(call cc-option, -fno-var-tracking-assignments)
+endif
 
 ifdef CONFIG_DEBUG_INFO
 ifdef CONFIG_DEBUG_INFO_SPLIT
diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index a28590083622..ce1107439d7d 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -165,7 +165,23 @@ config DEBUG_INFO_DWARF4
 	  Generate dwarf4 debug info. This requires recent versions
 	  of gcc and gdb. It makes the debug information larger.
 	  But it significantly improves the success of resolving
-	  variables in gdb on optimized code.
+	  variables in gdb on optimized code.  The gcc docs also
+	  recommend enabling -fvar-tracking-assignments for maximum
+	  benefit. (see DEBUG_INFO_VTA)
+
+config DEBUG_INFO_VTA
+	bool "Enable var-tracking-assignments for debuginfo"
+	depends on DEBUG_INFO
+	help
+	  Enable gcc -fvar-tracking-assignments for improved debug
+	  information on variable locations in optimized code.  Per
+	  gcc, DEBUG_INFO_DWARF4 is recommended for best use of VTA.
+
+	  VTA has been implicated in codegen bugs (gcc PR61801,
+	  PR61904), so this may deserve some caution.  One can set
+	  GCC_COMPARE_DEBUG=-fvar-tracking-assignments-toggle in the
+	  environment to automatically compile everything both ways,
+	  generating an error if anything differs.
 
 config ENABLE_WARN_DEPRECATED
 	bool "Enable __deprecated logic"
-- 
1.9.3

Re: [PATCH 3.15 33/37] Fix gcc-4.9.0 miscompilation of load_balance() in scheduler

[Jakub Jelinek]

On Tue, Aug 05, 2014 at 03:36:39PM -0700, Linus Torvalds wrote:
> On Tue, Aug 5, 2014 at 2:07 PM, Frank Ch. Eigler <fche@redhat.com> wrote:
> >
> > Actually, "perf probe" does (via HAVE_DWARF_SUPPORT), to place probes
> > and to extract variables at those probes, much as systemtap does.
> > Without var-tracking, probes placed at most interior points of
> > functions will make variables inaccessible.
> 
> .. and as mentioned, -O2 already does that for many things, even
> *with* tracking.

Sure, debug info coverage for highly optimized code is never going to be
perfect, but there is a difference if you have 75% of vars <optimized away>
or just 33% of vars (see the numbers I've posted, I've picked ext4.o just
randomly because it was one of the largest modules, can post more numbers if
needed).  BTW, because var-tracking is not performed at -O0, sometimes debug
info is actually worse in -O0 than at higher optimization levels, because
variable locations are bogus in prologues, epilogues and for variables with
register keyword anywhere.
There have been several man-years of work to get from the 25% var coverage
to 67%, several DWARF extensions (most of them to be available in DWARF5 or
work in progress on that) and with -fno-var-tracking-assignments that is
just returned to the old state.

> In other words, anybody who relies on it has already learnt to work
> around it. Or, more likely, there just isn't anybody who relies on it.
> 
> I don't understand how you guys can be so cavalier about a compiler
> bug that has already resulted in actual real problems. You bring up

I have no problem with a -fno-var-tracking-assignments workaround for
compilers that have the PR61801 wrong-code bug.  What I have problem with
is with disabling it even for compilers that have that bug fixed.
That is in essence disabling a useful feature just because it could have
other bugs.  If my memory serves me well, PR61801 is the only wrong-code
I remember caused by -fvar-tracking-assignments during the 5 years since
it has been introduced into gcc.  Sure, there have been several
-fcompare-debug bugs, where we generated slightly different code between
-g and -g0, and as you mentioned we have one still pending (Vladimir is
working on it right now), but that is mainly relevant to the case where
you'd ship -g0 built binaries (== kernel) and then only if bugs appear
wanted someone else to build kernel with -g and get identical binary, so
that you could debug it.  I believe if people build kernel with -g, then
they usually build it with -g from the beginning, and either save the kernel
with debug info somewhere, strip it to file or handle it similarly.
If there is a fear there could be other wrong-code bugs with
-fno-var-tracking-assignments, from the past experience that would be
~ another 5 years to discover it.  Compare that to the frequency of -O2
wrong code issues, with that you'd need to disable -O2 because of the fear
of unknown compiler bugs first.  And, we had various wrong-code bugs even at
-O0, so even that wouldn't help.  Compiler bugs are just that, bugs that
need to be reported, fixed, fixed compiler distributed to users, it is the
same thing with kernel bugs, libc bugs etc.

> theoretical cases that nobody has actually reported, and are
> apparently ignoring the fact that the compiler generates INCORRECT
> CODE. So on one hand we have known breakage, on the other we have

It actually isn't theoretical, actually various -fvar-tracking-assignments
changes have been done because people complained about important variables
in the kernel being optimized away, the whole DW_OP_GNU_entry_value DWARF
extension (DW_OP_entry_value in DWARF5 when it is released) was added
because of bugreports from people trying to debug the kernel.

	Jakub

Re: [PATCH 3.15 33/37] Fix gcc-4.9.0 miscompilation of load_balance() in scheduler

[Måns Rullgård]

Jakub Jelinek <jakub@redhat.com> writes:

> There have been several man-years of work to get from the 25% var coverage
> to 67%, several DWARF extensions (most of them to be available in DWARF5 or
> work in progress on that) and with -fno-var-tracking-assignments that is
> just returned to the old state.

This is a typical "but look at all the work we've put in, it *has* to
work" argument.  As always, it is completely without merit.

>> In other words, anybody who relies on it has already learnt to work
>> around it. Or, more likely, there just isn't anybody who relies on it.
>> 
>> I don't understand how you guys can be so cavalier about a compiler
>> bug that has already resulted in actual real problems. You bring up
>
> I have no problem with a -fno-var-tracking-assignments workaround for
> compilers that have the PR61801 wrong-code bug.

Are there any that with reasonable confidence do not?

-- 
Måns Rullgård
mans@mansr.com

Re: [PATCH 3.15 33/37] Fix gcc-4.9.0 miscompilation of load_balance() in scheduler

[Måns Rullgård]

Jakub Jelinek <jakub@redhat.com> writes:

> There have been several man-years of work to get from the 25% var coverage
> to 67%, several DWARF extensions (most of them to be available in DWARF5 or
> work in progress on that) and with -fno-var-tracking-assignments that is
> just returned to the old state.

This is a typical "but look at all the work we've put in, it *has* to
work" argument.  As always, it is completely without merit.

>> In other words, anybody who relies on it has already learnt to work
>> around it. Or, more likely, there just isn't anybody who relies on it.
>> 
>> I don't understand how you guys can be so cavalier about a compiler
>> bug that has already resulted in actual real problems. You bring up
>
> I have no problem with a -fno-var-tracking-assignments workaround for
> compilers that have the PR61801 wrong-code bug.

Are there any that with reasonable confidence do not?

-- 
M�ns Rullg�rd
mans@mansr.com

Re: [PATCH 3.15 33/37] Fix gcc-4.9.0 miscompilation of load_balance() in scheduler

[Alexei Starovoitov]

On Wed, Aug 6, 2014 at 1:14 AM, Jakub Jelinek <jakub@redhat.com> wrote:
> On Tue, Aug 05, 2014 at 03:36:39PM -0700, Linus Torvalds wrote:
d>> I don't understand how you guys can be so cavalier about a compiler
>> bug that has already resulted in actual real problems. You bring up
>
> I have no problem with a -fno-var-tracking-assignments workaround for
> compilers that have the PR61801 wrong-code bug.  What I have problem with
> is with disabling it even for compilers that have that bug fixed.
> That is in essence disabling a useful feature just because it could have
> other bugs.  If my memory serves me well, PR61801 is the only wrong-code
> I remember caused by -fvar-tracking-assignments during the 5 years since
> it has been introduced into gcc.  Sure, there have been several
> -fcompare-debug bugs, where we generated slightly different code between
> -g and -g0, and as you mentioned we have one still pending (Vladimir is
> working on it right now), but that is mainly relevant to the case where

I think gcc guys are taking a wrong lesson out of this. kernel doesn't
care too much whether gcc produces the same binary with -g and -g0.
kernel developers also don't care about amount debug info for variables,
but they care about hard to find compiler bugs. In this case sched2
mishap around debug_insn was a symptom. The root cause is lack
of attention to -mno-red-zone. Kernel is not another user space program
where data/control flow analysis is all compiler need to make things right.
-mno-red-zone lesson exposes lack of 'interrupt' concept in compiler.
I think there has to be some infra put in place to make sure that it's not
just a scheduling barrier. Otherwise next bug will pop much sooner
than 5 years and it will not be related to debug info at all.
In this sense Steven's perl script to detect red-zone violations did more
to re-enable var-tracking than -fcompare-debug fixes.

Re: [PATCH 3.15 00/37] 3.15.8-stable review

[Satoru Takeuchi]

At Tue, 29 Jul 2014 18:48:36 -0700,
Greg Kroah-Hartman wrote:
> 
> This is the start of the stable review cycle for the 3.15.8 release.
> There are 37 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 Fri Aug  1 01:48:13 UTC 2014.
> Anything received after that time might be too late.

All 3.15.8-rc1, 3.14.15-rc1, 3.10.51-rc1, and 3.4.101-rc1 passed my test.

 - Test Cases:
   - Build this kernel.
   - Boot this kernel.
   - Build the latest mainline kernel with this kernel.

 - Test Tool:
   https://github.com/satoru-takeuchi/test-linux-stable

 - Test Result (kernel .config, ktest config and test log):
   http://satoru-takeuchi.org/test-linux-stable/results/<version>-<test datetime>.tar.xz

 - Build Environment:
   - OS: Debian Jessy x86_64
   - CPU: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz x 4
   - memory: 8GB

 - Test Target Environment:
   - Debian Jessy x86_64 (KVM guest on the Build Environment)
   - # of vCPU: 2
   - memory: 2GB

Thanks,
Satoru

> 
> The whole patch series can be found in one patch at:
> 	kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.15.8-rc1.gz
> and the diffstat can be found below.
> 
> thanks,
> 
> greg k-h
> 
> -------------
> Pseudo-Shortlog of commits:
> 
> Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>     Linux 3.15.8-rc1
> 
> Guenter Roeck <linux@roeck-us.net>
>     platform_get_irq: Revert to platform_get_resource if of_irq_get fails
> 
> Johannes Berg <johannes.berg@intel.com>
>     nl80211: move set_qos_map command into split state
> 
> Konstantin Khlebnikov <koct9i@gmail.com>
>     mm: do not call do_fault_around for non-linear fault
> 
> Amit Shah <amit.shah@redhat.com>
>     hwrng: virtio - ensure reads happen after successful probe
> 
> Linus Torvalds <torvalds@linux-foundation.org>
>     Fix gcc-4.9.0 miscompilation of load_balance() in scheduler
> 
> Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
>     mm: hugetlb: fix copy_hugetlb_page_range()
> 
> Jerome Glisse <jglisse@redhat.com>
>     drm/radeon: fix cut and paste issue for hawaii.
> 
> Christian König <christian.koenig@amd.com>
>     drm/radeon: fix irq ring buffer overflow handling
> 
> Sven Wegener <sven.wegener@stealer.net>
>     x86_32, entry: Store badsys error code in %eax
> 
> Vasily Averin <vvs@parallels.com>
>     fs: umount on symlink leaks mnt count
> 
> Randy Dunlap <rdunlap@infradead.org>
>     parport: fix menu breakage
> 
> Guenter Roeck <linux@roeck-us.net>
>     hwmon: (smsc47m192) Fix temperature limit and vrm write operations
> 
> John David Anglin <dave.anglin@bell.net>
>     parisc: Remove SA_RESTORER define
> 
> Maxime COQUELIN <maxime.coquelin@st.com>
>     pinctrl: st: Fix irqmux handler
> 
> Andrew Gallagher <andrewjcg@fb.com>
>     fuse: add FUSE_NO_OPEN_SUPPORT flag to INIT
> 
> Miklos Szeredi <mszeredi@suse.cz>
>     fuse: s_time_gran fix
> 
> Silesh C V <svellattu@mvista.com>
>     coredump: fix the setting of PF_DUMPCORE
> 
> Dmitry Torokhov <dtor@chromium.org>
>     Input: fix defuzzing logic
> 
> Hans de Goede <hdegoede@redhat.com>
>     Input: synaptics - add min/max quirk for pnp-id LEN2002 (Edge E531)
> 
> Mikulas Patocka <mpatocka@redhat.com>
>     slab_common: fix the check for duplicate slab names
> 
> Tyrel Datwyler <tyreld@linux.vnet.ibm.com>
>     powerpc/pseries: dynamically added OF nodes need to call of_node_init
> 
> Minchan Kim <minchan@kernel.org>
>     zram: avoid lockdep splat by revalidate_disk
> 
> Tony Luck <tony.luck@intel.com>
>     tracing: Fix wraparound problems in "uptime" trace clock
> 
> Tejun Heo <tj@kernel.org>
>     blkcg: don't call into policy draining if root_blkg is already gone
> 
> Romain Degez <romain.degez@gmail.com>
>     ahci: add support for the Promise FastTrak TX8660 SATA HBA (ahci mode)
> 
> Martin Schwidefsky <schwidefsky@de.ibm.com>
>     s390/ptrace: fix PSW mask check
> 
> Tejun Heo <tj@kernel.org>
>     libata: introduce ata_host->n_tags to avoid oops on SAS controllers
> 
> Kevin Hao <haokexin@gmail.com>
>     libata: support the ata host which implements a queue depth less than 32
> 
> Christoph Hellwig <hch@lst.de>
>     block: don't assume last put of shared tags is for the host
> 
> Mikulas Patocka <mpatocka@redhat.com>
>     block: provide compat ioctl for BLKZEROOUT
> 
> Max Filippov <jcmvbkbc@gmail.com>
>     xtensa: fix sysmem reservation at the end of existing block
> 
> Christoph Hellwig <hch@lst.de>
>     nfs: only show Posix ACLs in listxattr if actually present
> 
> Antti Palosaari <crope@iki.fi>
>     media: tda10071: force modulation to QPSK on DVB-S
> 
> Hans Verkuil <hverkuil@xs4all.nl>
>     media: hdpvr: fix two audio bugs
> 
> Antti Palosaari <crope@iki.fi>
>     media: af9035: override tuner id when bad value set into eeprom
> 
> Rickard Strandqvist <rickard_strandqvist@spectrumdigital.se>
>     media: media: v4l2-core: v4l2-dv-timings.c: Cleaning up code wrong value used in aspect ratio
> 
> Arnd Bergmann <arnd@arndb.de>
>     media: staging: tighten omap4iss dependencies
> 
> 
> -------------
> 
> Diffstat:
> 
>  Makefile                                  |  6 +++--
>  arch/parisc/include/uapi/asm/signal.h     |  2 --
>  arch/powerpc/platforms/pseries/dlpar.c    |  1 +
>  arch/powerpc/platforms/pseries/reconfig.c |  1 +
>  arch/s390/kernel/ptrace.c                 | 12 +++++++--
>  arch/x86/kernel/entry_32.S                |  9 ++++---
>  arch/xtensa/mm/init.c                     |  2 +-
>  block/blk-cgroup.c                        |  7 +++++
>  block/blk-tag.c                           | 33 +++++-------------------
>  block/compat_ioctl.c                      |  1 +
>  drivers/ata/ahci.c                        |  1 +
>  drivers/ata/libata-core.c                 | 12 +++++++--
>  drivers/base/platform.c                   |  9 +++++--
>  drivers/block/zram/zram_drv.c             | 22 +++++++++++++---
>  drivers/char/hw_random/core.c             |  6 +++++
>  drivers/char/hw_random/virtio-rng.c       | 10 +++++++
>  drivers/gpu/drm/radeon/cik.c              |  2 ++
>  drivers/gpu/drm/radeon/evergreen.c        |  1 +
>  drivers/gpu/drm/radeon/r600.c             |  1 +
>  drivers/gpu/drm/radeon/si.c               |  1 +
>  drivers/hwmon/smsc47m192.c                |  4 ++-
>  drivers/input/input.c                     |  6 +++--
>  drivers/input/mouse/synaptics.c           |  5 ++--
>  drivers/media/dvb-frontends/tda10071.c    |  6 ++++-
>  drivers/media/usb/dvb-usb-v2/af9035.c     | 40 +++++++++++++++++++++++-----
>  drivers/media/usb/hdpvr/hdpvr-video.c     |  6 ++---
>  drivers/media/v4l2-core/v4l2-dv-timings.c |  4 +--
>  drivers/parport/Kconfig                   | 12 ++++-----
>  drivers/pinctrl/pinctrl-st.c              |  2 +-
>  drivers/staging/media/omap4iss/Kconfig    |  2 +-
>  fs/coredump.c                             |  2 +-
>  fs/fuse/inode.c                           |  5 +---
>  fs/namei.c                                |  3 ++-
>  fs/nfs/nfs3acl.c                          | 43 +++++++++++++++++++++++++++++++
>  fs/nfs/nfs3proc.c                         |  4 +--
>  include/linux/libata.h                    |  1 +
>  include/uapi/linux/fuse.h                 |  3 +++
>  kernel/trace/trace.c                      |  2 +-
>  kernel/trace/trace_clock.c                |  9 ++++---
>  mm/hugetlb.c                              |  1 +
>  mm/memory.c                               |  2 +-
>  mm/slab_common.c                          |  2 +-
>  net/wireless/nl80211.c                    | 11 ++++----
>  43 files changed, 222 insertions(+), 92 deletions(-)
> 
> 

Re: [PATCH 3.15 00/37] 3.15.8-stable review

[Satoru Takeuchi]

At Tue, 29 Jul 2014 18:48:36 -0700,
Greg Kroah-Hartman wrote:
> 
> This is the start of the stable review cycle for the 3.15.8 release.
> There are 37 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 Fri Aug  1 01:48:13 UTC 2014.
> Anything received after that time might be too late.

All 3.15.8-rc1, 3.14.15-rc1, 3.10.51-rc1, and 3.4.101-rc1 passed my test.

 - Test Cases:
   - Build this kernel.
   - Boot this kernel.
   - Build the latest mainline kernel with this kernel.

 - Test Tool:
   https://github.com/satoru-takeuchi/test-linux-stable

 - Test Result (kernel .config, ktest config and test log):
   http://satoru-takeuchi.org/test-linux-stable/results/<version>-<test datetime>.tar.xz

 - Build Environment:
   - OS: Debian Jessy x86_64
   - CPU: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz x 4
   - memory: 8GB

 - Test Target Environment:
   - Debian Jessy x86_64 (KVM guest on the Build Environment)
   - # of vCPU: 2
   - memory: 2GB

Thanks,
Satoru

> 
> The whole patch series can be found in one patch at:
> 	kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.15.8-rc1.gz
> and the diffstat can be found below.
> 
> thanks,
> 
> greg k-h
> 
> -------------
> Pseudo-Shortlog of commits:
> 
> Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>     Linux 3.15.8-rc1
> 
> Guenter Roeck <linux@roeck-us.net>
>     platform_get_irq: Revert to platform_get_resource if of_irq_get fails
> 
> Johannes Berg <johannes.berg@intel.com>
>     nl80211: move set_qos_map command into split state
> 
> Konstantin Khlebnikov <koct9i@gmail.com>
>     mm: do not call do_fault_around for non-linear fault
> 
> Amit Shah <amit.shah@redhat.com>
>     hwrng: virtio - ensure reads happen after successful probe
> 
> Linus Torvalds <torvalds@linux-foundation.org>
>     Fix gcc-4.9.0 miscompilation of load_balance() in scheduler
> 
> Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
>     mm: hugetlb: fix copy_hugetlb_page_range()
> 
> Jerome Glisse <jglisse@redhat.com>
>     drm/radeon: fix cut and paste issue for hawaii.
> 
> Christian K�nig <christian.koenig@amd.com>
>     drm/radeon: fix irq ring buffer overflow handling
> 
> Sven Wegener <sven.wegener@stealer.net>
>     x86_32, entry: Store badsys error code in %eax
> 
> Vasily Averin <vvs@parallels.com>
>     fs: umount on symlink leaks mnt count
> 
> Randy Dunlap <rdunlap@infradead.org>
>     parport: fix menu breakage
> 
> Guenter Roeck <linux@roeck-us.net>
>     hwmon: (smsc47m192) Fix temperature limit and vrm write operations
> 
> John David Anglin <dave.anglin@bell.net>
>     parisc: Remove SA_RESTORER define
> 
> Maxime COQUELIN <maxime.coquelin@st.com>
>     pinctrl: st: Fix irqmux handler
> 
> Andrew Gallagher <andrewjcg@fb.com>
>     fuse: add FUSE_NO_OPEN_SUPPORT flag to INIT
> 
> Miklos Szeredi <mszeredi@suse.cz>
>     fuse: s_time_gran fix
> 
> Silesh C V <svellattu@mvista.com>
>     coredump: fix the setting of PF_DUMPCORE
> 
> Dmitry Torokhov <dtor@chromium.org>
>     Input: fix defuzzing logic
> 
> Hans de Goede <hdegoede@redhat.com>
>     Input: synaptics - add min/max quirk for pnp-id LEN2002 (Edge E531)
> 
> Mikulas Patocka <mpatocka@redhat.com>
>     slab_common: fix the check for duplicate slab names
> 
> Tyrel Datwyler <tyreld@linux.vnet.ibm.com>
>     powerpc/pseries: dynamically added OF nodes need to call of_node_init
> 
> Minchan Kim <minchan@kernel.org>
>     zram: avoid lockdep splat by revalidate_disk
> 
> Tony Luck <tony.luck@intel.com>
>     tracing: Fix wraparound problems in "uptime" trace clock
> 
> Tejun Heo <tj@kernel.org>
>     blkcg: don't call into policy draining if root_blkg is already gone
> 
> Romain Degez <romain.degez@gmail.com>
>     ahci: add support for the Promise FastTrak TX8660 SATA HBA (ahci mode)
> 
> Martin Schwidefsky <schwidefsky@de.ibm.com>
>     s390/ptrace: fix PSW mask check
> 
> Tejun Heo <tj@kernel.org>
>     libata: introduce ata_host->n_tags to avoid oops on SAS controllers
> 
> Kevin Hao <haokexin@gmail.com>
>     libata: support the ata host which implements a queue depth less than 32
> 
> Christoph Hellwig <hch@lst.de>
>     block: don't assume last put of shared tags is for the host
> 
> Mikulas Patocka <mpatocka@redhat.com>
>     block: provide compat ioctl for BLKZEROOUT
> 
> Max Filippov <jcmvbkbc@gmail.com>
>     xtensa: fix sysmem reservation at the end of existing block
> 
> Christoph Hellwig <hch@lst.de>
>     nfs: only show Posix ACLs in listxattr if actually present
> 
> Antti Palosaari <crope@iki.fi>
>     media: tda10071: force modulation to QPSK on DVB-S
> 
> Hans Verkuil <hverkuil@xs4all.nl>
>     media: hdpvr: fix two audio bugs
> 
> Antti Palosaari <crope@iki.fi>
>     media: af9035: override tuner id when bad value set into eeprom
> 
> Rickard Strandqvist <rickard_strandqvist@spectrumdigital.se>
>     media: media: v4l2-core: v4l2-dv-timings.c: Cleaning up code wrong value used in aspect ratio
> 
> Arnd Bergmann <arnd@arndb.de>
>     media: staging: tighten omap4iss dependencies
> 
> 
> -------------
> 
> Diffstat:
> 
>  Makefile                                  |  6 +++--
>  arch/parisc/include/uapi/asm/signal.h     |  2 --
>  arch/powerpc/platforms/pseries/dlpar.c    |  1 +
>  arch/powerpc/platforms/pseries/reconfig.c |  1 +
>  arch/s390/kernel/ptrace.c                 | 12 +++++++--
>  arch/x86/kernel/entry_32.S                |  9 ++++---
>  arch/xtensa/mm/init.c                     |  2 +-
>  block/blk-cgroup.c                        |  7 +++++
>  block/blk-tag.c                           | 33 +++++-------------------
>  block/compat_ioctl.c                      |  1 +
>  drivers/ata/ahci.c                        |  1 +
>  drivers/ata/libata-core.c                 | 12 +++++++--
>  drivers/base/platform.c                   |  9 +++++--
>  drivers/block/zram/zram_drv.c             | 22 +++++++++++++---
>  drivers/char/hw_random/core.c             |  6 +++++
>  drivers/char/hw_random/virtio-rng.c       | 10 +++++++
>  drivers/gpu/drm/radeon/cik.c              |  2 ++
>  drivers/gpu/drm/radeon/evergreen.c        |  1 +
>  drivers/gpu/drm/radeon/r600.c             |  1 +
>  drivers/gpu/drm/radeon/si.c               |  1 +
>  drivers/hwmon/smsc47m192.c                |  4 ++-
>  drivers/input/input.c                     |  6 +++--
>  drivers/input/mouse/synaptics.c           |  5 ++--
>  drivers/media/dvb-frontends/tda10071.c    |  6 ++++-
>  drivers/media/usb/dvb-usb-v2/af9035.c     | 40 +++++++++++++++++++++++-----
>  drivers/media/usb/hdpvr/hdpvr-video.c     |  6 ++---
>  drivers/media/v4l2-core/v4l2-dv-timings.c |  4 +--
>  drivers/parport/Kconfig                   | 12 ++++-----
>  drivers/pinctrl/pinctrl-st.c              |  2 +-
>  drivers/staging/media/omap4iss/Kconfig    |  2 +-
>  fs/coredump.c                             |  2 +-
>  fs/fuse/inode.c                           |  5 +---
>  fs/namei.c                                |  3 ++-
>  fs/nfs/nfs3acl.c                          | 43 +++++++++++++++++++++++++++++++
>  fs/nfs/nfs3proc.c                         |  4 +--
>  include/linux/libata.h                    |  1 +
>  include/uapi/linux/fuse.h                 |  3 +++
>  kernel/trace/trace.c                      |  2 +-
>  kernel/trace/trace_clock.c                |  9 ++++---
>  mm/hugetlb.c                              |  1 +
>  mm/memory.c                               |  2 +-
>  mm/slab_common.c                          |  2 +-
>  net/wireless/nl80211.c                    | 11 ++++----
>  43 files changed, 222 insertions(+), 92 deletions(-)
> 
> 

Re: [PATCH 3.15 00/37] 3.15.8-stable review

[Greg Kroah-Hartman]

On Wed, Jul 30, 2014 at 08:58:44PM +0900, Satoru Takeuchi wrote:
> At Tue, 29 Jul 2014 18:48:36 -0700,
> Greg Kroah-Hartman wrote:
> > 
> > This is the start of the stable review cycle for the 3.15.8 release.
> > There are 37 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 Fri Aug  1 01:48:13 UTC 2014.
> > Anything received after that time might be too late.
> 
> All 3.15.8-rc1, 3.14.15-rc1, 3.10.51-rc1, and 3.4.101-rc1 passed my test.

Wonderful, thanks for testing and letting me know.

greg k-h

Re: [PATCH 3.15 00/37] 3.15.8-stable review

[Guenter Roeck]

On Tue, Jul 29, 2014 at 06:48:36PM -0700, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 3.15.8 release.
> There are 37 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 Fri Aug  1 01:48:13 UTC 2014.
> Anything received after that time might be too late.
> 
Build results:
	total: 141 pass: 141 fail: 0

Qemu tests all passed.

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

Guenter

Re: [PATCH 3.15 00/37] 3.15.8-stable review

[Greg Kroah-Hartman]

On Wed, Jul 30, 2014 at 09:09:31AM -0700, Guenter Roeck wrote:
> On Tue, Jul 29, 2014 at 06:48:36PM -0700, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 3.15.8 release.
> > There are 37 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 Fri Aug  1 01:48:13 UTC 2014.
> > Anything received after that time might be too late.
> > 
> Build results:
> 	total: 141 pass: 141 fail: 0
> 
> Qemu tests all passed.
> 
> Details are available at http://server.roeck-us.net:8010/builders.

Thanks for testing all of these and letting me know.

greg k-h

[PATCH RESEND] Kbuild: Add an option to enable GCC VTA

[Josh Stone]

Due to recent codegen issues, gcc -fvar-tracking-assignments was
unconditionally disabled in commit 2062afb4f804a ("Fix gcc-4.9.0
miscompilation of load_balance() in scheduler").  However, this reduces
the debuginfo coverage for variable locations, especially in inline
functions.  VTA is certainly not perfect either in those cases, but it
is much better than without.  With compiler versions that have fixed the
codegen bugs, we would prefer to have the better details for SystemTap,
and surely other debuginfo consumers like perf will benefit as well.

This patch simply makes CONFIG_DEBUG_INFO_VTA an option.  I considered
Frank and Linus's discussion of a cc-option-like -fcompare-debug test,
but I'm convinced that a narrow test of an arch-specific codegen issue
is not really useful.  GCC has their own regression tests for this, so
I'd suggest GCC_COMPARE_DEBUG=-fvar-tracking-assignments-toggle is more
useful for kernel developers to test confidence.

In fact, I ran into a couple more issues when testing for this patch[1],
although neither of those had any codegen impact.
 [1] https://bugzilla.redhat.com/show_bug.cgi?id=1140872

With gcc-4.9.2-1.fc22, I can now build v3.18-rc5 with Fedora's i686 and
x86_64 configs, and this is completely clean with GCC_COMPARE_DEBUG.

Cc: Frank Ch. Eigler <fche@redhat.com>
Cc: Jakub Jelinek <jakub@redhat.com>
Cc: Josh Boyer <jwboyer@fedoraproject.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Markus Trippelsdorf <markus@trippelsdorf.de>
Cc: Michel Dänzer <michel@daenzer.net>
Signed-off-by: Josh Stone <jistone@redhat.com>
---
 Makefile          |  4 ++++
 lib/Kconfig.debug | 18 +++++++++++++++++-
 2 files changed, 21 insertions(+), 1 deletion(-)

diff --git a/Makefile b/Makefile
index 00d618bbe8e7..a289efbe7e28 100644
--- a/Makefile
+++ b/Makefile
@@ -704,7 +704,11 @@ KBUILD_CFLAGS	+= -fomit-frame-pointer
 endif
 endif
 
+ifdef CONFIG_DEBUG_INFO_VTA
+KBUILD_CFLAGS   += $(call cc-option, -fvar-tracking-assignments)
+else
 KBUILD_CFLAGS   += $(call cc-option, -fno-var-tracking-assignments)
+endif
 
 ifdef CONFIG_DEBUG_INFO
 ifdef CONFIG_DEBUG_INFO_SPLIT
diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index 4e35a5d767ed..27410417de1d 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -165,7 +165,23 @@ config DEBUG_INFO_DWARF4
 	  Generate dwarf4 debug info. This requires recent versions
 	  of gcc and gdb. It makes the debug information larger.
 	  But it significantly improves the success of resolving
-	  variables in gdb on optimized code.
+	  variables in gdb on optimized code.  The gcc docs also
+	  recommend enabling -fvar-tracking-assignments for maximum
+	  benefit. (see DEBUG_INFO_VTA)
+
+config DEBUG_INFO_VTA
+	bool "Enable var-tracking-assignments for debuginfo"
+	depends on DEBUG_INFO
+	help
+	  Enable gcc -fvar-tracking-assignments for improved debug
+	  information on variable locations in optimized code.  Per
+	  gcc, DEBUG_INFO_DWARF4 is recommended for best use of VTA.
+
+	  VTA has been implicated in codegen bugs (gcc PR61801,
+	  PR61904), so this may deserve some caution.  One can set
+	  GCC_COMPARE_DEBUG=-fvar-tracking-assignments-toggle in the
+	  environment to automatically compile everything both ways,
+	  generating an error if anything differs.
 
 config ENABLE_WARN_DEPRECATED
 	bool "Enable __deprecated logic"
-- 
2.1.0

[PATCH] Kbuild: Add an option to enable GCC VTA

[Frank Ch. Eigler]

From: Josh Stone <jistone@redhat.com>

Due to isolated gcc codegen issues, gcc -fvar-tracking-assignments
was unconditionally disabled in commit 2062afb4f804 ("Fix gcc-4.9.0
miscompilation of load_balance()  in scheduler").

However, this reduces the debuginfo coverage for variable locations,
especially in inline functions.  VTA is certainly not perfect either
in those cases, but it is much better than without.  With compiler
versions that have fixed the codegen bugs, we would prefer to have the
better details for SystemTap, and surely other debuginfo consumers
like perf will benefit as well.

This patch simply makes CONFIG_DEBUG_INFO_VTA an option.  I considered
Frank and Linus's discussion of a cc-option-like -fcompare-debug test,
but I'm convinced that a narrow test of an arch-specific codegen issue
is not really useful.  GCC has their own regression tests for this, so
I'd suggest GCC_COMPARE_DEBUG=-fvar-tracking-assignments-toggle is more
useful for kernel developers to test confidence.

In fact, I ran into a couple more issues when testing for this patch[1],
although neither of those had any codegen impact.
 [1] https://bugzilla.redhat.com/show_bug.cgi?id=1140872

With gcc-4.9.2-1.fc22, I can now build v3.18-rc5 with Fedora's i686 and
x86_64 configs, and this is completely clean with GCC_COMPARE_DEBUG.

Cc: Jakub Jelinek <jakub@redhat.com>
Cc: Josh Boyer <jwboyer@fedoraproject.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Markus Trippelsdorf <markus@trippelsdorf.de>
Cc: Michel Dänzer <michel@daenzer.net>
Signed-off-by: Josh Stone <jistone@redhat.com>
Signed-off-by: Frank Ch. Eigler <fche@redhat.com>
---
 Makefile          |  8 ++++++--
 lib/Kconfig.debug | 21 ++++++++++++++++++++-
 2 files changed, 26 insertions(+), 3 deletions(-)

diff --git a/Makefile b/Makefile
index 6cc5b2434224..c8e1fcfdb41a 100644
--- a/Makefile
+++ b/Makefile
@@ -704,8 +704,6 @@ KBUILD_CFLAGS	+= -fomit-frame-pointer
 endif
 endif
 
-KBUILD_CFLAGS   += $(call cc-option, -fno-var-tracking-assignments)
-
 ifdef CONFIG_DEBUG_INFO
 ifdef CONFIG_DEBUG_INFO_SPLIT
 KBUILD_CFLAGS   += $(call cc-option, -gsplit-dwarf, -g)
@@ -718,6 +716,12 @@ ifdef CONFIG_DEBUG_INFO_DWARF4
 KBUILD_CFLAGS	+= $(call cc-option, -gdwarf-4,)
 endif
 
+ifdef CONFIG_DEBUG_INFO_VTA
+KBUILD_CFLAGS   += $(call cc-option, -fvar-tracking-assignments)
+else
+KBUILD_CFLAGS   += $(call cc-option, -fno-var-tracking-assignments)
+endif
+
 ifdef CONFIG_DEBUG_INFO_REDUCED
 KBUILD_CFLAGS 	+= $(call cc-option, -femit-struct-debug-baseonly) \
 		   $(call cc-option,-fno-var-tracking)
diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index 17670573dda8..e8d072d2b402 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -165,7 +165,26 @@ config DEBUG_INFO_DWARF4
 	  Generate dwarf4 debug info. This requires recent versions
 	  of gcc and gdb. It makes the debug information larger.
 	  But it significantly improves the success of resolving
-	  variables in gdb on optimized code.
+	  variables in gdb on optimized code.  The gcc docs also
+	  recommend enabling -fvar-tracking-assignments for maximum
+	  benefit. (see DEBUG_INFO_VTA)
+
+config DEBUG_INFO_VTA
+	bool "Enable var-tracking-assignments for debuginfo"
+	depends on DEBUG_INFO
+	help
+	  Enable gcc -fvar-tracking-assignments for improved debug
+	  information on variable locations in optimized code.	Per
+	  gcc, DEBUG_INFO_DWARF4 is recommended for best use of VTA,
+	  and allows maximal access to local variables in tracers
+	  and debuggers like perf, systemtap, kgdb, and crash.
+
+	  VTA has been implicated in codegen bugs (gcc PR61801,
+	  PR61904, both fixed in 2014-08), so this flag may be used
+	  to exclude this rare class of problem.  One can also set
+	  GCC_COMPARE_DEBUG=-fvar-tracking-assignments-toggle in the
+	  environment to automatically compile everything both ways,
+	  generating an error if anything differs.
 
 config GDB_SCRIPTS
 	bool "Provide GDB scripts for kernel debugging"
-- 
2.1.0

Re: [PATCH] Kbuild: Add an option to enable GCC VTA

[Josh Boyer]

On Thu, Apr 23, 2015 at 5:25 PM, Frank Ch. Eigler <fche@redhat.com> wrote:
> From: Josh Stone <jistone@redhat.com>
>
> Due to isolated gcc codegen issues, gcc -fvar-tracking-assignments
> was unconditionally disabled in commit 2062afb4f804 ("Fix gcc-4.9.0
> miscompilation of load_balance()  in scheduler").
>
> However, this reduces the debuginfo coverage for variable locations,
> especially in inline functions.  VTA is certainly not perfect either
> in those cases, but it is much better than without.  With compiler
> versions that have fixed the codegen bugs, we would prefer to have the
> better details for SystemTap, and surely other debuginfo consumers
> like perf will benefit as well.
>
> This patch simply makes CONFIG_DEBUG_INFO_VTA an option.  I considered
> Frank and Linus's discussion of a cc-option-like -fcompare-debug test,
> but I'm convinced that a narrow test of an arch-specific codegen issue
> is not really useful.  GCC has their own regression tests for this, so
> I'd suggest GCC_COMPARE_DEBUG=-fvar-tracking-assignments-toggle is more
> useful for kernel developers to test confidence.
>
> In fact, I ran into a couple more issues when testing for this patch[1],
> although neither of those had any codegen impact.
>  [1] https://bugzilla.redhat.com/show_bug.cgi?id=1140872
>
> With gcc-4.9.2-1.fc22, I can now build v3.18-rc5 with Fedora's i686 and
> x86_64 configs, and this is completely clean with GCC_COMPARE_DEBUG.
>
> Cc: Jakub Jelinek <jakub@redhat.com>
> Cc: Josh Boyer <jwboyer@fedoraproject.org>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: Linus Torvalds <torvalds@linux-foundation.org>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: Markus Trippelsdorf <markus@trippelsdorf.de>
> Cc: Michel Dänzer <michel@daenzer.net>
> Signed-off-by: Josh Stone <jistone@redhat.com>
> Signed-off-by: Frank Ch. Eigler <fche@redhat.com>

Frank, did you rebase this against some newer tree or something?
Curious why you sent it again.

>  Makefile          |  8 ++++++--
>  lib/Kconfig.debug | 21 ++++++++++++++++++++-
>  2 files changed, 26 insertions(+), 3 deletions(-)
>
> diff --git a/Makefile b/Makefile
> index 6cc5b2434224..c8e1fcfdb41a 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -704,8 +704,6 @@ KBUILD_CFLAGS       += -fomit-frame-pointer
>  endif
>  endif
>
> -KBUILD_CFLAGS   += $(call cc-option, -fno-var-tracking-assignments)
> -
>  ifdef CONFIG_DEBUG_INFO
>  ifdef CONFIG_DEBUG_INFO_SPLIT
>  KBUILD_CFLAGS   += $(call cc-option, -gsplit-dwarf, -g)
> @@ -718,6 +716,12 @@ ifdef CONFIG_DEBUG_INFO_DWARF4
>  KBUILD_CFLAGS  += $(call cc-option, -gdwarf-4,)
>  endif
>
> +ifdef CONFIG_DEBUG_INFO_VTA
> +KBUILD_CFLAGS   += $(call cc-option, -fvar-tracking-assignments)
> +else
> +KBUILD_CFLAGS   += $(call cc-option, -fno-var-tracking-assignments)
> +endif
> +

Is there a reason you moved this hunk under the DWARF4 options instead
of modifying it in-place like the original patch did?

josh

Re: [PATCH] Kbuild: Add an option to enable GCC VTA

[Frank Ch. Eigler]

Hi, Josh -

On Fri, Apr 24, 2015 at 08:40:02AM -0400, Josh Boyer wrote:
> [...]
> Frank, did you rebase this against some newer tree or something?

Yes; the lib/Kconfig.debug part didn't apply to current git.

> Curious why you sent it again.

At least as a patch-ping; the poor-debuginfo problems are reported to
affect non-fedora users too.


> > +ifdef CONFIG_DEBUG_INFO_VTA
> > +KBUILD_CFLAGS   += $(call cc-option, -fvar-tracking-assignments)
> > +else
> > +KBUILD_CFLAGS   += $(call cc-option, -fno-var-tracking-assignments)
> > +endif
> > +
> 
> Is there a reason you moved this hunk under the DWARF4 options instead
> of modifying it in-place like the original patch did?

Yes, this version appears a little safer, in the sense that without
CONFIG_DEBUG_INFO, neither setting of CONFIG_DEBUG_INFO_VTA would
affect the CFLAGS.  (In fact, Jakub advises the positive polarity
-fvar-tracking-assignments is redundant with -g, and the negative
polarity one only provides codegen-bug-protection in the
CONFIG_DEBUG_INFO case.)


- FChE