3.10.1-stable review

<rant>
I'm sitting on top of over 170 more patches that have been marked for the stable releases right now that are not included in this set of releases. The fact that there are this many patches for stable stuff that are waiting to be merged through the main -rc1 merge window cycle is worrying to me.

Why are subsystem maintainers holding on to fixes that are _supposedly_ affecting all users? I mean, 21 powerpc core changes that I don't see until a -rc1 merge? It's as if developers don't expect people to use a .0 release and are relying on me to get the fixes they have burried in their trees out to users. That's not that nice. 6 "core" iscsi-target fixes? That's the sign of either a broken subsystem maintainer, or a lack of understanding what the normal -rc kernel releases are supposed to be for.

So, I've picked through the patches and dug out only those that I've "guessed" at being more important than others for the 3.10.1 release. I'll get to the rest of these after 3.11-rc1 is out, and eventually they will make it into the stable releases, but I am going to be much more strict as to what is being added (carriage return changes for debug messages, really ACPI developers?)

</rant>

This is the start of the stable review cycle for the 3.10.1 release. There are 19 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.

Responses should be made by Sat Jul 13 21:45:35 UTC 2013. Anything received after that time might be too late.

The whole patch series can be found in one patch at:

	kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.10.1-rc1.gz

and the diffstat can be found below.

thanks,

greg k-h

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

Greg Kroah-Hartman <[email protected]>

    Linux 3.10.1-rc1

Michal Hocko <[email protected]>
Revert "memcg: avoid dangling reference count in creation failure"

Srivatsa S. Bhat <[email protected]>
cpufreq: Fix cpufreq regression after suspend/resume

Ben Hutchings <[email protected]>
SCSI: sd: Fix parsing of 'temporary ' cache mode prefix

Gleb Natapov <[email protected]>
KVM: VMX: mark unusable segment as nonpresent

J. Bruce Fields <[email protected]>
nfsd4: fix decoding of compounds across page boundaries

Andy Adamson <[email protected]>
NFSv4.1 end back channel session draining

Greg Kroah-Hartman <[email protected]>
Revert "serial: 8250_pci: add support for another kind of NetMos Technology PCI 9835 Multi-I/O Controller"

Peter Hurley <[email protected]>
tty: Reset itty for other pty

Zhang Yi <[email protected]>
futex: Take hugepages into account when generating futex_key

Greg Kroah-Hartman <[email protected]>
MAINTAINERS: add stable_kernel_rules.txt to stable maintainer information

Kees Cook <[email protected]>
crypto: sanitize argument for format string

Kees Cook <[email protected]>
block: do not pass disk names as format strings

Mikulas Patocka <[email protected]>
hpfs: better test for errors

Kees Cook <[email protected]>
charger-manager: Ensure event is not used as format string

Rusty Russell <[email protected]>
module: do percpu allocation after uniqueness check. No, really!

Jonathan Salwan <[email protected]>
drivers/cdrom/cdrom.c: use kzalloc() for failing hardware

Josh Durgin <[email protected]>

    libceph: fix invalid unsigned->signed conversion for timespec encoding

majianpeng <[email protected]>
ceph: fix sleeping function called from invalid context.

Tyler Hicks <[email protected]>
libceph: Fix NULL pointer dereference in auth client code

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

Diffstat:

 MAINTAINERS                        |  1 +
 Makefile                           |  4 ++--
 arch/x86/kvm/vmx.c                 | 11 +++++++++--
 block/genhd.c                      |  2 +-
 crypto/algapi.c                    |  3 ++-
 drivers/block/nbd.c                |  3 ++-
 drivers/cdrom/cdrom.c              |  2 +-
 drivers/cpufreq/cpufreq_stats.c    |  1 +
 drivers/power/charger-manager.c    |  2 +-
 drivers/scsi/osd/osd_uld.c         |  2 +-
 drivers/scsi/sd.c                  |  2 +-
 drivers/tty/serial/8250/8250_pci.c |  4 ----
 drivers/tty/tty_io.c               |  2 ++
 fs/ceph/xattr.c                    |  9 +++++----
 fs/hpfs/map.c                      |  3 ++-
 fs/hpfs/super.c                    |  8 +++++++-
 fs/nfs/nfs4state.c                 | 23 +++++++++++------------
 fs/nfsd/nfs4xdr.c                  |  2 +-
 include/linux/ceph/decode.h        |  5 -----
 include/linux/hugetlb.h            | 16 ++++++++++++++++
 kernel/futex.c                     |  3 ++-
 kernel/module.c                    | 34 ++++++++++++++++++----------------
 mm/hugetlb.c                       | 17 +++++++++++++++++
 mm/memcontrol.c                    |  2 --
 net/ceph/auth_none.c               |  6 ++++++
 25 files changed, 109 insertions(+), 58 deletions(-)

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

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

From: Tyler Hicks <[email protected]>

commit 2cb33cac622afde897aa02d3dcd9fbba8bae839e upstream.

A malicious monitor can craft an auth reply message that could cause a NULL function pointer dereference in the client's kernel.

To prevent this, the auth_none protocol handler needs an empty ceph_auth_client_ops->build_request() function.

CVE-2013-1059

---
 net/ceph/auth_none.c |    6 ++++++
 1 file changed, 6 insertions(+)

@@ -39,6 +39,11 @@ static int should_authenticate(struct ce
 	return xi->starting;
 }
 
+static int build_request(struct ceph_auth_client *ac, void *buf, void *end)
+{
+	return 0;
+}
+
 /*
  * the generic auth code decode the global_id, and we carry no actual
  * authenticate state, so nothing happens here.

@@ -106,6 +111,7 @@ static const struct ceph_auth_client_ops
 	.destroy = destroy,
 	.is_authenticated = is_authenticated,
 	.should_authenticate = should_authenticate,
+	.build_request = build_request,
 	.handle_reply = handle_reply,
 	.create_authorizer = ceph_auth_none_create_authorizer,
 	.destroy_authorizer = ceph_auth_none_destroy_authorizer,

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

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

From: majianpeng <[email protected]>

commit a1dc1937337a93e699eaa56968b7de6e1a9e77cf upstream.

[ 1121.231883] BUG: sleeping function called from invalid context at kernel/rwsem.c:20
[ 1121.231935] in_atomic(): 1, irqs_disabled(): 0, pid: 9831, name: mv
[ 1121.231971] 1 lock held by mv/9831:
[ 1121.231973]  #0:  (&(&ci->i_ceph_lock)->rlock){+.+...},at:[<ffffffffa02bbd38>] ceph_getxattr+0x58/0x1d0 [ceph]
[ 1121.231998] CPU: 3 PID: 9831 Comm: mv Not tainted 3.10.0-rc6+ #215
[ 1121.232000] Hardware name: To Be Filled By O.E.M. To Be Filled By
O.E.M./To be filled by O.E.M., BIOS 080015  11/09/2011
[ 1121.232027]  ffff88006d355a80 ffff880092f69ce0 ffffffff8168348c ffff880092f69cf8
[ 1121.232045]  ffffffff81070435 ffff88006d355a20 ffff880092f69d20 ffffffff816899ba
[ 1121.232052]  0000000300000004 ffff8800b76911d0 ffff88006d355a20 ffff880092f69d68
[ 1121.232056] Call Trace:
[ 1121.232062]  [<ffffffff8168348c>] dump_stack+0x19/0x1b
[ 1121.232067]  [<ffffffff81070435>] __might_sleep+0xe5/0x110
[ 1121.232071]  [<ffffffff816899ba>] down_read+0x2a/0x98
[ 1121.232080]  [<ffffffffa02baf70>] ceph_vxattrcb_layout+0x60/0xf0 [ceph]
[ 1121.232088]  [<ffffffffa02bbd7f>] ceph_getxattr+0x9f/0x1d0 [ceph]
[ 1121.232093]  [<ffffffff81188d28>] vfs_getxattr+0xa8/0xd0
[ 1121.232097]  [<ffffffff8118900b>] getxattr+0xab/0x1c0
[ 1121.232100]  [<ffffffff811704f2>] ? final_putname+0x22/0x50
[ 1121.232104]  [<ffffffff81155f80>] ? kmem_cache_free+0xb0/0x260
[ 1121.232107]  [<ffffffff811704f2>] ? final_putname+0x22/0x50
[ 1121.232110]  [<ffffffff8109e63d>] ? trace_hardirqs_on+0xd/0x10
[ 1121.232114]  [<ffffffff816957a7>] ? sysret_check+0x1b/0x56
[ 1121.232120]  [<ffffffff81189c9c>] SyS_fgetxattr+0x6c/0xc0
[ 1121.232125]  [<ffffffff81695782>] system_call_fastpath+0x16/0x1b
[ 1121.232129] BUG: scheduling while atomic: mv/9831/0x10000002
[ 1121.232154] 1 lock held by mv/9831:
[ 1121.232156]  #0:  (&(&ci->i_ceph_lock)->rlock){+.+...}, at:

[<ffffffffa02bbd38>] ceph_getxattr+0x58/0x1d0 [ceph]

I think move the ci->i_ceph_lock down is safe because we can't free ceph_inode_info at there.

---
 fs/ceph/xattr.c |    9 +++++----
 1 file changed, 5 insertions(+), 4 deletions(-)

@@ -675,17 +675,18 @@ ssize_t ceph_getxattr(struct dentry *den
 	if (!ceph_is_valid_xattr(name))
 		return -ENODATA;
 
-	spin_lock(&ci->i_ceph_lock);
-	dout("getxattr %p ver=%lld index_ver=%lld\n", inode,
-	     ci->i_xattrs.version, ci->i_xattrs.index_version);
 
 	/* let's see if a virtual xattr was requested */
 	vxattr = ceph_match_vxattr(inode, name);
 	if (vxattr && !(vxattr->exists_cb && !vxattr->exists_cb(ci))) {
 		err = vxattr->getxattr_cb(ci, value, size);
-		goto out;
+		return err;
 	}
 
+	spin_lock(&ci->i_ceph_lock);
+	dout("getxattr %p ver=%lld index_ver=%lld\n", inode,
+	     ci->i_xattrs.version, ci->i_xattrs.index_version);
+
 	if (__ceph_caps_issued_mask(ci, CEPH_CAP_XATTR_SHARED, 1) &&
 	    (ci->i_xattrs.index_version >= ci->i_xattrs.version)) {
 		goto get_xattr;

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

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

From: Josh Durgin <[email protected]>

commit 8b8cf8917f9b5d74e04f281272d8719ce335a497 upstream.

__kernel_time_t is a long, which cannot hold a U32_MAX on 32-bit architectures. Just drop this check as it has limited value.

This fixes a crash like:

[  957.905812] kernel BUG at /srv/autobuild-ceph/gitbuilder.git/build/include/linux/ceph/decode.h:164!
[  957.914849] Internal error: Oops - BUG: 0 [#1] SMP ARM
[  957.919978] Modules linked in: rbd libceph libcrc32c ipmi_devintf ipmi_si ipmi_msghandler nfsd nfs_acl auth_rpcgss nfs fscache lockd sunrpc
[  957.932547] CPU: 1    Tainted: G        W     (3.9.0-ceph-19bb6a83-highbank #1)
[  957.939881] PC is at ceph_osdc_build_request+0x8c/0x4f8 [libceph]
[  957.945967] LR is at 0xec520904
[  957.949103] pc : [<bf13e76c>]    lr : [<ec520904>]    psr: 20000153
[  957.949103] sp : ec753df8  ip : 00000001  fp : ec53e100
[  957.960571] r10: ebef25c0  r9 : ec5fa400  r8 : ecbcc000
[  957.965788] r7 : 00000000  r6 : 00000000  r5 : ffffffff  r4 : 00000020
[  957.972307] r3 : 51cc8143  r2 : ec520900  r1 : ec753e58  r0 : ec520908
[  957.978827] Flags: nzCv  IRQs on  FIQs off  Mode SVC_32  ISA ARM  Segment user
[  957.986039] Control: 10c5387d  Table: 2c59c04a  DAC: 00000015
[  957.991777] Process rbd (pid: 2138, stack limit = 0xec752238)
[  957.997514] Stack: (0xec753df8 to 0xec754000)
[  958.001864] 3de0:                                                       00000001 00000001
[  958.010032] 3e00: 00000001 bf139744 ecbcc000 ec55a0a0 00000024 00000000 ebef25c0 fffffffe
[  958.018204] 3e20: ffffffff 00000000 00000000 00000001 ec5fa400 ebef25c0 ec53e100 bf166b68
[  958.026377] 3e40: 00000000 0000220f fffffffe ffffffff ec753e58 bf13ff24 51cc8143 05b25ed2
[  958.034548] 3e60: 00000001 00000000 00000000 bf1688d4 00000001 00000000 00000000 00000000
[  958.042720] 3e80: 00000001 00000060 ec5fa400 ed53d200 ed439600 ed439300 00000001 00000060
[  958.050888] 3ea0: ec5fa400 ed53d200 00000000 bf16a320 00000000 ec53e100 00000040 ec753eb8
[  958.059059] 3ec0: ec51df00 ed53d7c0 ed53d200 ed53d7c0 00000000 ed53d7c0 ec5fa400 bf16ed70
[  958.067230] 3ee0: 00000000 00000060 00000002 ed53d200 00000000 bf16acf4 ed53d7c0 ec752000
[  958.075402] 3f00: ed980e50 e954f5d8 00000000 00000060 ed53d240 ed53d258 ec753f80 c04f44a8
[  958.083574] 3f20: edb7910c ec664700 01ade920 c02e4c44 00000060 c016b3dc ec51de40 01adfb84
[  958.091745] 3f40: 00000060 ec752000 ec753f80 ec752000 00000060 c0108444 00000007 ec51de48
[  958.099914] 3f60: ed0eb8c0 00000000 00000000 ec51de40 01adfb84 00000001 00000060 c0108858
[  958.108085] 3f80: 00000000 00000000 51cc8143 00000060 01adfb84 00000007 00000004 c000dd68
[  958.116257] 3fa0: 00000000 c000dbc0 00000060 01adfb84 00000007 01adfb84 00000060 01adfb80
[  958.124429] 3fc0: 00000060 01adfb84 00000007 00000004 beded1a8 00000000 01adf2f0 01ade920
[  958.132599] 3fe0: 00000000 beded180 b6811324 b6811334 800f0010 00000007 2e7f5821 2e7f5c21
[  958.140815] [<bf13e76c>] (ceph_osdc_build_request+0x8c/0x4f8 [libceph]) from [<bf166b68>] (rbd_osd_req_format_write+0x50/0x7c [rbd])
[  958.152739] [<bf166b68>] (rbd_osd_req_format_write+0x50/0x7c [rbd]) from [<bf1688d4>] (rbd_dev_header_watch_sync+0xe0/0x204 [rbd])
[  958.164486] [<bf1688d4>] (rbd_dev_header_watch_sync+0xe0/0x204 [rbd]) from [<bf16a320>] (rbd_dev_image_probe+0x23c/0x850 [rbd])
[  958.175967] [<bf16a320>] (rbd_dev_image_probe+0x23c/0x850 [rbd]) from [<bf16acf4>] (rbd_add+0x3c0/0x918 [rbd])
[  958.185975] [<bf16acf4>] (rbd_add+0x3c0/0x918 [rbd]) from [<c02e4c44>] (bus_attr_store+0x20/0x2c)
[  958.194850] [<c02e4c44>] (bus_attr_store+0x20/0x2c) from [<c016b3dc>] (sysfs_write_file+0x168/0x198)
[  958.203984] [<c016b3dc>] (sysfs_write_file+0x168/0x198) from [<c0108444>] (vfs_write+0x9c/0x170)
[  958.212768] [<c0108444>] (vfs_write+0x9c/0x170) from [<c0108858>] (sys_write+0x3c/0x70)
[  958.220768] [<c0108858>] (sys_write+0x3c/0x70) from [<c000dbc0>] (ret_fast_syscall+0x0/0x30)
[  958.229199] Code: e59d1058 e5913000 e3530000 ba000114 (e7f001f2)

---
 include/linux/ceph/decode.h |    5 -----
 1 file changed, 5 deletions(-)

@@ -160,11 +160,6 @@ static inline void ceph_decode_timespec(
 static inline void ceph_encode_timespec(struct ceph_timespec *tv,
 					const struct timespec *ts)
 {
-	BUG_ON(ts->tv_sec < 0);
-	BUG_ON(ts->tv_sec > (__kernel_time_t)U32_MAX);
-	BUG_ON(ts->tv_nsec < 0);
-	BUG_ON(ts->tv_nsec > (long)U32_MAX);
-
 	tv->tv_sec = cpu_to_le32((u32)ts->tv_sec);
 	tv->tv_nsec = cpu_to_le32((u32)ts->tv_nsec);
 }

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

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

From: Jonathan Salwan <[email protected]>

commit 542db01579fbb7ea7d1f7bb9ddcef1559df660b2 upstream.

In drivers/cdrom/cdrom.c mmc_ioctl_cdrom_read_data() allocates a memory area with kmalloc in line 2885.

  2885         cgc->buffer = kmalloc(blocksize, GFP_KERNEL);
  2886         if (cgc->buffer == NULL)
  2887                 return -ENOMEM;

In line 2908 we can find the copy_to_user function:

  2908         if (!ret && copy_to_user(arg, cgc->buffer, blocksize))

The cgc->buffer is never cleaned and initialized before this function. If ret = 0 with the previous basic block, it's possible to display some memory bytes in kernel space from userspace.

When we read a block from the disk it normally fills the ->buffer but if the drive is malfunctioning there is a chance that it would only be partially filled. The result is an leak information to userspace.

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

@@ -2882,7 +2882,7 @@ static noinline int mmc_ioctl_cdrom_read
 	if (lba < 0)
 		return -EINVAL;
 
-	cgc->buffer = kmalloc(blocksize, GFP_KERNEL);
+	cgc->buffer = kzalloc(blocksize, GFP_KERNEL);
 	if (cgc->buffer == NULL)
 		return -ENOMEM;
 

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

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

From: Rusty Russell <[email protected]>

commit 8d8022e8aba85192e937f1f0f7450e256d66ae5c upstream.

v3.8-rc1-5-g1fb9341 was supposed to stop parallel kvm loads exhausting percpu memory on large machines:

Now we have a new state MODULE_STATE_UNFORMED, we can insert the module into the list (and thus guarantee its uniqueness) before we allocate the per-cpu region.

In my defence, it didn't actually say the patch did this. Just that we "can".

This patch actually *does* it.

---
 kernel/module.c |   34 ++++++++++++++++++----------------
 1 file changed, 18 insertions(+), 16 deletions(-)

@@ -2927,7 +2927,6 @@ static struct module *layout_and_allocat
 {
 	/* Module within temporary copy. */
 	struct module *mod;
-	Elf_Shdr *pcpusec;
 	int err;
 
 	mod = setup_load_info(info, flags);

@@ -2942,17 +2941,10 @@ static struct module *layout_and_allocat
 	err = module_frob_arch_sections(info->hdr, info->sechdrs,
 					info->secstrings, mod);
 	if (err < 0)
-		goto out;
+		return ERR_PTR(err);
 
-	pcpusec = &info->sechdrs[info->index.pcpu];
-	if (pcpusec->sh_size) {
-		/* We have a special allocation for this section. */
-		err = percpu_modalloc(mod,
-				      pcpusec->sh_size, pcpusec->sh_addralign);
-		if (err)
-			goto out;
-		pcpusec->sh_flags &= ~(unsigned long)SHF_ALLOC;
-	}
+	/* We will do a special allocation for per-cpu sections later. */
+	info->sechdrs[info->index.pcpu].sh_flags &= ~(unsigned long)SHF_ALLOC;
 
 	/* Determine total sizes, and put offsets in sh_entsize.  For now
 	   this is done generically; there doesn't appear to be any

@@ -2963,17 +2955,22 @@ static struct module *layout_and_allocat
 	/* Allocate and move to the final place */
 	err = move_module(mod, info);
 	if (err)
-		goto free_percpu;
+		return ERR_PTR(err);
 
 	/* Module has been copied to its final place now: return it. */
 	mod = (void *)info->sechdrs[info->index.mod].sh_addr;
 	kmemleak_load_module(mod, info);
 	return mod;
+}
 
-free_percpu:
-	percpu_modfree(mod);
-out:
-	return ERR_PTR(err);
+static int alloc_module_percpu(struct module *mod, struct load_info *info)
+{
+	Elf_Shdr *pcpusec = &info->sechdrs[info->index.pcpu];
+	if (!pcpusec->sh_size)
+		return 0;
+
+	/* We have a special allocation for this section. */
+	return percpu_modalloc(mod, pcpusec->sh_size, pcpusec->sh_addralign);
 }
 
 /* mod is no longer valid after this! */

@@ -3237,6 +3234,11 @@ static int load_module(struct load_info
 	}
 #endif
 
+	/* To avoid stressing percpu allocator, do this once we're unique. */
+	err = alloc_module_percpu(mod, info);
+	if (err)
+		goto unlink_mod;
+
 	/* Now module is in final location, initialize linked lists, etc. */
 	err = module_unload_init(mod);
 	if (err)

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

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

From: Kees Cook <[email protected]>

commit 3594f4c0d7bc51e3a7e6d73c44e368ae079e42f3 upstream.

The exposed interface for cm_notify_event() could result in the event msg string being parsed as a format string. Make sure it is only used as a literal string.

---
 drivers/power/charger-manager.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

@@ -450,7 +450,7 @@ static void uevent_notify(struct charger
 	strncpy(env_str, event, UEVENT_BUF_SIZE);
 	kobject_uevent(&cm->dev->kobj, KOBJ_CHANGE);
 
-	dev_info(cm->dev, event);
+	dev_info(cm->dev, "%s", event);
 }
 
 /**

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

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

From: Mikulas Patocka <[email protected]>

commit 3ebacb05044f82c5f0bb456a894eb9dc57d0ed90 upstream.

The test if bitmap access is out of bound could errorneously pass if the device size is divisible by 16384 sectors and we are asking for one bitmap after the end.

Check for invalid size in the superblock. Invalid size could cause integer overflows in the rest of the code.

---
 fs/hpfs/map.c   |    3 ++-
 fs/hpfs/super.c |    8 +++++++-
 2 files changed, 9 insertions(+), 2 deletions(-)

@@ -17,7 +17,8 @@ __le32 *hpfs_map_bitmap(struct super_blo
 			 struct quad_buffer_head *qbh, char *id)
 {
 	secno sec;
-	if (hpfs_sb(s)->sb_chk) if (bmp_block * 16384 > hpfs_sb(s)->sb_fs_size) {
+	unsigned n_bands = (hpfs_sb(s)->sb_fs_size + 0x3fff) >> 14;
+	if (hpfs_sb(s)->sb_chk) if (bmp_block >= n_bands) {
 		hpfs_error(s, "hpfs_map_bitmap called with bad parameter: %08x at %s", bmp_block, id);
 		return NULL;
 	}

@@ -558,7 +558,13 @@ static int hpfs_fill_super(struct super_
 	sbi->sb_cp_table = NULL;
 	sbi->sb_c_bitmap = -1;
 	sbi->sb_max_fwd_alloc = 0xffffff;
-	
+
+	if (sbi->sb_fs_size >= 0x80000000) {
+		hpfs_error(s, "invalid size in superblock: %08x",
+			(unsigned)sbi->sb_fs_size);
+		goto bail4;
+	}
+
 	/* Load bitmap directory */
 	if (!(sbi->sb_bmp_dir = hpfs_load_bitmap_directory(s, le32_to_cpu(superblock->bitmaps))))
 		goto bail4;

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

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

From: Kees Cook <[email protected]>

commit ffc8b30866879ed9ba62bd0a86fecdbd51cd3d19 upstream.

Disk names may contain arbitrary strings, so they must not be interpreted as format strings. It seems that only md allows arbitrary strings to be used for disk names, but this could allow for a local memory corruption from uid 0 into ring 0.

CVE-2013-2851

---
 block/genhd.c              |    2 +-
 drivers/block/nbd.c        |    3 ++-
 drivers/scsi/osd/osd_uld.c |    2 +-
 3 files changed, 4 insertions(+), 3 deletions(-)

@@ -512,7 +512,7 @@ static void register_disk(struct gendisk
 
 	ddev->parent = disk->driverfs_dev;
 
-	dev_set_name(ddev, disk->disk_name);
+	dev_set_name(ddev, "%s", disk->disk_name);
 
 	/* delay uevents, until we scanned partition table */
 	dev_set_uevent_suppress(ddev, 1);

@@ -714,7 +714,8 @@ static int __nbd_ioctl(struct block_devi
 		else
 			blk_queue_flush(nbd->disk->queue, 0);
 
-		thread = kthread_create(nbd_thread, nbd, nbd->disk->disk_name);
+		thread = kthread_create(nbd_thread, nbd, "%s",
+					nbd->disk->disk_name);
 		if (IS_ERR(thread)) {
 			mutex_lock(&nbd->tx_lock);
 			return PTR_ERR(thread);

@@ -485,7 +485,7 @@ static int osd_probe(struct device *dev)
 	oud->class_dev.class = &osd_uld_class;
 	oud->class_dev.parent = dev;
 	oud->class_dev.release = __remove;
-	error = dev_set_name(&oud->class_dev, disk->disk_name);
+	error = dev_set_name(&oud->class_dev, "%s", disk->disk_name);
 	if (error) {
 		OSD_ERR("dev_set_name failed => %d\n", error);
 		goto err_put_cdev;

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

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

From: Kees Cook <[email protected]>

commit 1c8fca1d92e14859159a82b8a380d220139b7344 upstream.

The template lookup interface does not provide a way to use format strings, so make sure that the interface cannot be abused accidentally.

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

@@ -495,7 +495,8 @@ static struct crypto_template *__crypto_
 
 struct crypto_template *crypto_lookup_template(const char *name)
 {
-	return try_then_request_module(__crypto_lookup_template(name), name);
+	return try_then_request_module(__crypto_lookup_template(name), "%s",
+				       name);
 }
 EXPORT_SYMBOL_GPL(crypto_lookup_template);
 

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

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

From: Greg Kroah-Hartman <[email protected]>

commit 7b175c46720f8e6b92801bb634c93d1016f80c62 upstream.

This hopefully will help point developers to the proper way that patches should be submitted for inclusion in the stable kernel releases.

---
 MAINTAINERS |    1 +
 1 file changed, 1 insertion(+)

@@ -7667,6 +7667,7 @@ STABLE BRANCH
 M:	Greg Kroah-Hartman <[email protected]>
 L:	[email protected]
 S:	Supported
+F:	Documentation/stable_kernel_rules.txt
 
 STAGING SUBSYSTEM
 M:	Greg Kroah-Hartman <[email protected]>

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

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

From: Zhang Yi <[email protected]>

commit 13d60f4b6ab5b702dc8d2ee20999f98a93728aec upstream.

The futex_keys of process shared futexes are generated from the page offset, the mapping host and the mapping index of the futex user space address. This should result in an unique identifier for each futex.

Though this is not true when futexes are located in different subpages of an hugepage. The reason is, that the mapping index for all those futexes evaluates to the index of the base page of the hugetlbfs mapping. So a futex at offset 0 of the hugepage mapping and another one at offset PAGE_SIZE of the same hugepage mapping have identical futex_keys. This happens because the futex code blindly uses page->index.

Steps to reproduce the bug:

1. Map a file from hugetlbfs. Initialize pthread_mutex1 at offset 0 and pthread_mutex2 at offset PAGE_SIZE of the hugetlbfs mapping.

The mutexes must be initialized as PTHREAD_PROCESS_SHARED because PTHREAD_PROCESS_PRIVATE mutexes are not affected by this issue as their keys solely depend on the user space address.

2. Lock mutex1 and mutex2

3. Create thread1 and in the thread function lock mutex1, which results in thread1 blocking on the locked mutex1.

4. Create thread2 and in the thread function lock mutex2, which results in thread2 blocking on the locked mutex2.

5. Unlock mutex2. Despite the fact that mutex2 got unlocked, thread2 still blocks on mutex2 because the futex_key points to mutex1.

To solve this issue we need to take the normal page index of the page which contains the futex into account, if the futex is in an hugetlbfs mapping. In other words, we calculate the normal page mapping index of the subpage in the hugetlbfs mapping.

Mappings which are not based on hugetlbfs are not affected and still use page->index.

Thanks to Mel Gorman who provided a patch for adding proper evaluation functions to the hugetlbfs code to avoid exposing hugetlbfs specific details to the futex code.

[ tglx: Massaged changelog ]

---
 include/linux/hugetlb.h |   16 ++++++++++++++++
 kernel/futex.c          |    3 ++-
 mm/hugetlb.c            |   17 +++++++++++++++++
 3 files changed, 35 insertions(+), 1 deletion(-)

@@ -358,6 +358,17 @@ static inline int hstate_index(struct hs
 	return h - hstates;
 }
 
+pgoff_t __basepage_index(struct page *page);
+
+/* Return page->index in PAGE_SIZE units */
+static inline pgoff_t basepage_index(struct page *page)
+{
+	if (!PageCompound(page))
+		return page->index;
+
+	return __basepage_index(page);
+}
+
 #else	/* CONFIG_HUGETLB_PAGE */
 struct hstate {};
 #define alloc_huge_page_node(h, nid) NULL

@@ -378,6 +389,11 @@ static inline unsigned int pages_per_hug
 }
 #define hstate_index_to_shift(index) 0
 #define hstate_index(h) 0
+
+static inline pgoff_t basepage_index(struct page *page)
+{
+	return page->index;
+}
 #endif	/* CONFIG_HUGETLB_PAGE */
 
 #endif /* _LINUX_HUGETLB_H */

@@ -61,6 +61,7 @@
 #include <linux/nsproxy.h>
 #include <linux/ptrace.h>
 #include <linux/sched/rt.h>
+#include <linux/hugetlb.h>
 
 #include <asm/futex.h>
 

@@ -365,7 +366,7 @@ again:
 	} else {
 		key->both.offset |= FUT_OFF_INODE; /* inode-based key */
 		key->shared.inode = page_head->mapping->host;
-		key->shared.pgoff = page_head->index;
+		key->shared.pgoff = basepage_index(page);
 	}
 
 	get_futex_key_refs(key);

@@ -690,6 +690,23 @@ int PageHuge(struct page *page)
 }
 EXPORT_SYMBOL_GPL(PageHuge);
 
+pgoff_t __basepage_index(struct page *page)
+{
+	struct page *page_head = compound_head(page);
+	pgoff_t index = page_index(page_head);
+	unsigned long compound_idx;
+
+	if (!PageHuge(page_head))
+		return page_index(page);
+
+	if (compound_order(page_head) >= MAX_ORDER)
+		compound_idx = page_to_pfn(page) - page_to_pfn(page_head);
+	else
+		compound_idx = page - page_head;
+
+	return (index << compound_order(page_head)) + compound_idx;
+}
+
 static struct page *alloc_fresh_huge_page_node(struct hstate *h, int nid)
 {
 	struct page *page;

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

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

From: Peter Hurley <[email protected]>

commit 64e377dcd7d75c241d614458e9619d3445de44ef upstream.

Commit 19ffd68f816878aed456d5e87697f43bd9e3bd2b ('pty: Remove redundant itty reset') introduced a regression whereby the other pty's linkage is not cleared on teardown. This triggers a false positive diagnostic in testing.

Properly reset the itty linkage.

---
 drivers/tty/tty_io.c |    2 ++
 1 file changed, 2 insertions(+)

@@ -1618,6 +1618,8 @@ static void release_tty(struct tty_struc
 	tty_free_termios(tty);
 	tty_driver_remove_tty(tty->driver, tty);
 	tty->port->itty = NULL;
+	if (tty->link)
+		tty->link->port->itty = NULL;
 	cancel_work_sync(&tty->port->buf.work);
 
 	if (tty->link)

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

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

From: Greg Kroah-Hartman <[email protected]>

commit 828c6a102b1f2b8583fadc0e779c46b31d448f0b upstream.

This reverts commit 8d2f8cd424ca0b99001f3ff4f5db87c4e525f366.

As reported by Stefan, this device already works with the parport_serial driver, so the 8250_pci driver should not also try to grab it as well.

---
 drivers/tty/serial/8250/8250_pci.c |    4 ----
 1 file changed, 4 deletions(-)

@@ -4797,10 +4797,6 @@ static struct pci_device_id serial_pci_t
 		PCI_VENDOR_ID_IBM, 0x0299,
 		0, 0, pbn_b0_bt_2_115200 },
 
-	{	PCI_VENDOR_ID_NETMOS, PCI_DEVICE_ID_NETMOS_9835,
-		0x1000, 0x0012,
-		0, 0, pbn_b0_bt_2_115200 },
-
 	{	PCI_VENDOR_ID_NETMOS, PCI_DEVICE_ID_NETMOS_9901,
 		0xA000, 0x1000,
 		0, 0, pbn_b0_1_115200 },

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

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

From: Andy Adamson <[email protected]>

commit 62f288a02f97bd9f6b2361a6fff709729fe9e110 upstream.

We need to ensure that we clear NFS4_SLOT_TBL_DRAINING on the back channel when we're done recovering the session.

Regression introduced by commit 774d5f14e (NFSv4.1 Fix a pNFS session draining deadlock)

---
 fs/nfs/nfs4state.c |   23 +++++++++++------------
 1 file changed, 11 insertions(+), 12 deletions(-)

@@ -228,19 +228,8 @@ static int nfs41_setup_state_renewal(str
 	return status;
 }
 
-/*
- * Back channel returns NFS4ERR_DELAY for new requests when
- * NFS4_SESSION_DRAINING is set so there is no work to be done when draining
- * is ended.
- */
-static void nfs4_end_drain_session(struct nfs_client *clp)
+static void nfs4_end_drain_slot_table(struct nfs4_slot_table *tbl)
 {
-	struct nfs4_session *ses = clp->cl_session;
-	struct nfs4_slot_table *tbl;
-
-	if (ses == NULL)
-		return;
-	tbl = &ses->fc_slot_table;
 	if (test_and_clear_bit(NFS4_SLOT_TBL_DRAINING, &tbl->slot_tbl_state)) {
 		spin_lock(&tbl->slot_tbl_lock);
 		nfs41_wake_slot_table(tbl);

@@ -248,6 +237,16 @@ static void nfs4_end_drain_session(struc
 	}
 }
 
+static void nfs4_end_drain_session(struct nfs_client *clp)
+{
+	struct nfs4_session *ses = clp->cl_session;
+
+	if (ses != NULL) {
+		nfs4_end_drain_slot_table(&ses->bc_slot_table);
+		nfs4_end_drain_slot_table(&ses->fc_slot_table);
+	}
+}
+
 /*
  * Signal state manager thread if session fore channel is drained
  */

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

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

From: "J. Bruce Fields" <[email protected]>

commit 247500820ebd02ad87525db5d9b199e5b66f6636 upstream.

A freebsd NFSv4.0 client was getting rare IO errors expanding a tarball. A network trace showed the server returning BAD_XDR on the final getattr of a getattr+write+getattr compound. The final getattr started on a page boundary.

I believe the Linux client ignores errors on the post-write getattr, and that that's why we haven't seen this before.

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

@@ -162,8 +162,8 @@ static __be32 *read_buf(struct nfsd4_com
 	 */
 	memcpy(p, argp->p, avail);
 	/* step to next page */
-	argp->p = page_address(argp->pagelist[0]);
 	argp->pagelist++;
+	argp->p = page_address(argp->pagelist[0]);
 	if (argp->pagelen < PAGE_SIZE) {
 		argp->end = argp->p + (argp->pagelen>>2);
 		argp->pagelen = 0;

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

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

From: Gleb Natapov <[email protected]>

commit 03617c188f41eeeb4223c919ee7e66e5a114f2c6 upstream.

Some userspaces do not preserve unusable property. Since usable segment has to be present according to VMX spec we can use present property to amend userspace bug by making unusable segment always nonpresent. vmx_segment_access_rights() already marks nonpresent segment as unusable.

---
 arch/x86/kvm/vmx.c |   11 +++++++++--
 1 file changed, 9 insertions(+), 2 deletions(-)

@@ -3399,15 +3399,22 @@ static void vmx_get_segment(struct kvm_v
 	var->limit = vmx_read_guest_seg_limit(vmx, seg);
 	var->selector = vmx_read_guest_seg_selector(vmx, seg);
 	ar = vmx_read_guest_seg_ar(vmx, seg);
+	var->unusable = (ar >> 16) & 1;
 	var->type = ar & 15;
 	var->s = (ar >> 4) & 1;
 	var->dpl = (ar >> 5) & 3;
-	var->present = (ar >> 7) & 1;
+	/*
+	 * Some userspaces do not preserve unusable property. Since usable
+	 * segment has to be present according to VMX spec we can use present
+	 * property to amend userspace bug by making unusable segment always
+	 * nonpresent. vmx_segment_access_rights() already marks nonpresent
+	 * segment as unusable.
+	 */
+	var->present = !var->unusable;
 	var->avl = (ar >> 12) & 1;
 	var->l = (ar >> 13) & 1;
 	var->db = (ar >> 14) & 1;
 	var->g = (ar >> 15) & 1;
-	var->unusable = (ar >> 16) & 1;
 }
 
 static u64 vmx_get_segment_base(struct kvm_vcpu *vcpu, int seg)

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

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

From: Ben Hutchings <[email protected]>

commit 2ee3e26c673e75c05ef8b914f54fadee3d7b9c88 upstream.

Commit 39c60a0948cc '[SCSI] sd: fix array cache flushing bug causing performance problems' added temp as a pointer to "temporary " and used sizeof(temp) - 1 as its length. But sizeof(temp) is the size of the pointer, not the size of the string constant. Change temp to a static array so that sizeof() does what was intended.

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

@@ -142,7 +142,7 @@ sd_store_cache_type(struct device *dev,
 	char *buffer_data;
 	struct scsi_mode_data data;
 	struct scsi_sense_hdr sshdr;
-	const char *temp = "temporary ";
+	static const char temp[] = "temporary ";
 	int len;
 
 	if (sdp->type != TYPE_DISK)

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

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

From: "Srivatsa S. Bhat" <[email protected]>

commit f51e1eb63d9c28cec188337ee656a13be6980cfd upstream.

Toralf Förster reported that the cpufreq ondemand governor behaves erratically (doesn't scale well) after a suspend/resume cycle. The problem was that the cpufreq subsystem's idea of the cpu frequencies differed from the actual frequencies set in the hardware after a suspend/resume cycle. Toralf bisected the problem to commit a66b2e5 (cpufreq: Preserve sysfs files across suspend/resume).

Among other (harmless) things, that commit skipped the call to cpufreq_update_policy() in the resume path. But cpufreq_update_policy() plays an important role during resume, because it is responsible for checking if the BIOS changed the cpu frequencies behind our back and resynchronize the cpufreq subsystem's knowledge of the cpu frequencies, and update them accordingly.

So, restore the call to cpufreq_update_policy() in the resume path to fix the cpufreq regression.

---
 drivers/cpufreq/cpufreq_stats.c |    1 +
 1 file changed, 1 insertion(+)

@@ -349,6 +349,7 @@ static int __cpuinit cpufreq_stat_cpu_ca
 
 	switch (action) {
 	case CPU_ONLINE:
+	case CPU_ONLINE_FROZEN:
 		cpufreq_update_policy(cpu);
 		break;
 	case CPU_DOWN_PREPARE:

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

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

From: Michal Hocko <[email protected]>

commit fa460c2d37870e0a6f94c70e8b76d05ca11b6db0 upstream.

This reverts commit e4715f01be697a.

mem_cgroup_put is hierarchy aware so mem_cgroup_put(memcg) already drops an additional reference from all parents so the additional mem_cgrroup_put(parent) potentially causes use-after-free.

---
 mm/memcontrol.c |    2 --
 1 file changed, 2 deletions(-)

@@ -6303,8 +6303,6 @@ mem_cgroup_css_online(struct cgroup *con
 		 * call __mem_cgroup_free, so return directly
 		 */
 		mem_cgroup_put(memcg);
-		if (parent->use_hierarchy)
-			mem_cgroup_put(parent);
 	}
 	return error;
 }

Very much agreed.

This is the kind of stuff I was alluding to on the ksummit-discuss list. I was beginning to think we were the only ones noticing so I'm glad you're speaking up.

That's very much appreciated, Greg. Thanks.

josh

Let me guess, a lot of these are Power8 fixes ... This is a bit special this time around... we introduced some of the support in 3.9 and added a bunch in 3.10. We found bugs, it's brand new HW (not even final yet), and nobody out there has access to it nor will for a little while longer, so indeed nobody is going to use 3.10.0.

I've been pushing back on a lot of it as a maintainer (which is why a lot of stuff ended up in 3.10 instead of 3.9), but granted probably not enough this time around.

It's hard because the guys are getting a LOT of pressure in part because of distro schedules.

As you are aware (and I mentioned in another email), some enterprise distros impose a very specific schedule for stuff to go upstream, and if that misses, well .... you are out of the game for years or lots of $ to convince them otherwise. Additionally, one of them has brain damaged rules about preserving kernel ABIs which prevents any significant addition for the entire lifetime of the distro major release.

This is bad, this should not affect upstream in theory, but in practice it does because if we don't get into the damn enterprise distro, the whole exercise is pointless to begin with and we may as well not release the machines and stop the Linux business altogether.

So I make compromises. I delay some stuff because it's really not ready, and I take some because it affects things like thread_struct layout which I know *WILL* break kABI and will be VERY hard to get back to the distro later, fully expecting that various bits of fixes are going to eventually trickle later on until it's ready for public consumption.

Ben.

I get the impression as soon as we hit -rc1, some maintainers immediately go into "OH SHIT, I CAN'T SEND PATCHES OR LINUS WILL SHOUT AT ME" mode.

And the later in -rc we are, the more reluctant some people seem to be at sending stuff. Which, for slowing things down as we go through -rc is great, but not so much when people stop sending _everything_ and start thinking "I'll just get it in stable in a few weeks".

For .10 I had to start making a list of "shit that's broken that there's an outstanding patch for" and nagging people to send them week after week. Every time I reported a new bug I'd hit, I'd have to explain I wasn't running Linus' tree because there was so much other crap I had to carry just to get things to a baseline of stability before starting tests.

By rc7 things got a lot better, but if we have fixes sitting around in git trees for weeks on end with no progress, that kinda sucks.

Dave

I agree. But it seems that I need to now start shouting at them :(

The 20 powerpc patches are proof of that. I'm amost considering just not applying them at all, as obviously they weren't all that important.

We have patches with assigned CVE numbers sitting in subsystem trees that didn't hit Linus's tree until this merge window. Now granted, I don't necessarily agree that they were worth CVEs, but really, holding them off from being merged for 2 months or so is really bad, and means that something seems a bit broken with our development process.

And thanks for nagging people, I really appreciate it, sad it's necessary.

greg k-h

What I try to do is, get all "stable" patches in before -rc4 is out. Once -rc4 is out, then I get a bit more picky with what to push to Linus. If it's not a regression (something that's been broken for a while) I don't push it. -rc5, I get even pickier, and by -rc6 and beyond, I only push things that may crash the kernel. If things just give bad output (for tracing), I tag it with stable and wait for the merge window.

3.10 was actually really bad for me. I had some major changes done to ftrace, and there were a lot of patches sent to me after -rc4 came out. A lot of them were nits and didn't crash the kernel, thus I only tagged them with stable. Some of them, we didn't get correct until Linus opened the merge window.

Maybe this would be a good KS topic. What exactly is appropriate to push during the -rc's. Perhaps have criteria for the -rc levels.

-rc1-3, take all bug fixes.

-rc4,5, regressions, and more substantial bugs

-rc6-.. get your act together. Only critical bug fixes.

??

-- Steve

Just like others, I now have a cutoff-point for -stable patches. Depending on the severity of a bug, it is somewhere between -rc4 and -rc6. After -rc6 I only push regressions and crash fixes; the rest has to wait for the commit window.

So, yes, there are a couple of hwmon patches in your list.

hard place. Yes, I would prefer to push all -stable material even late in the -rc game, but that is not how things work nowadays anymore.

This should really be discussed at the Kernel Summit. Overall, I don't really care too much how to handle it. Just tell me. The outlook of "Either Linus will shout at you or Greg will" doesn't sound like a good solution, though.

Guenter

So regressions, crash fixes (and security issues) is exactly what I want to get after -rc3 or so. And yes, I will start shouting at people if other things show up.

However, I think your comments clearly show the problem:

That's f*cking sad. You know *why* it's sad?

Go read the rules for stable patches. Really.

Because the rules for stable patches are the rules _I_ use for that late -rc stuff, and is pretty much exactly what you yourself described as "this is what I send Linus after -rc4".

Now, that should make you think about THE ABSOLUTE CRAP YOU MARK FOR -stable!

If it isn't important enough to send to me after -rc4, then it damn well isn't important enough to mark for stable either!

It really is that simple.

Listen to yourself. In fact, there is a damn good solution": don't mark crap for stable, and don't send crap to me after -rc4.

If it doesn't fit the stable rules, they should go in the next merge window. It really is that simple. You even (unwittingly) pretty much described the stable rules, but then you apparently didn't understand that those were the rules for -stable too.

Of course, I suspect I see why this happens. Greg doesn't shout as much as me, and he has been taking any random patches into -stable. So the end result is that people think it's easier to mark things for -stable than it is to show that it actualy *is* stable, and they are trying to use -stable as a way to get any random late fixes in.

That is not how stable should work. When stable started, it had some rather clear rules. It's not for "fixes". It was meant to be solely for big issues.

The thing you just described that you put a stable tag on is *EXACTLY* the things that should not be marked for stable. For *EXACTLY* the same reason that you realized you shouldn't push it to me after -rc4.

Do you really not see this?

Greg, the reason you get a lot of stable patches seems to be that you make it easy to act as a door-mat. Clearly at least some people say "I know this patch isn't important enough to send to Linus, but I know Greg will silently accept it after the fact, so I'll just wait and mark it for stable".

You may need to learn to shout at people.

Linus

I tend to hold things off after -rc4 because you scare me more than Greg does ;-)

Actually, as I consider tracing a second class citizen, the things that I tend not to send you, but instead mark for stable, are things that can cause events to be dropped, or just incorrect trace data. Like a tracepoint saying preemption is off when it is enabled. If I find a bug that can cause some minor incorrect trace data to occur, and its after -rc4, I tend to just mark it with a stable tag and wait for the merge window to occur. I don't mean regressions either. Usually, the incorrect data comes from something new for that release, or something that's been there forever (like commit 11034ae9c20f4057a6127fc965906417978e69b2).

Should those be sent to you late in the game as well?

For the 3.11 merge window, I had quite a bit of stable tags, but those were commits that I would have sent to you but they were found very late, and by the time I was satisfied with the test output, you had already opened the window.

-- Steve

Have you guys *seen* Greg? The guy is a freakish giant. He *should* scare you. He might squish you without ever even noticing.

Linus

Greg might be a giant and he might squish people without ever even noticing, but that's just a grave, deadly physical threat no real kernel hacker ever feels threatened by. (Not much can hurt us deep in our dark basements after all, except maybe earthquakes, gamma ray eruptions and Mom trying to clean up around the computers.)

So Greg, if you want it all to change, create some _real_ threat: be frank with contributors and sometimes swear a bit. That will cut your mailqueue in half, promise!

Thanks,

Ingo

I don't think it's that simple. The problem here isn't that Greg is being too nice. The problem is that people are holding back fixes from Linus' tree. Greg might be able to yell at maintainers more, but if he does it's after the fact and it's sort of a too late situation. Those fixes should probably get in the tree because they should probably have been in the .0 release to begin with. I don't envy Greg here.

I know... let's push this off onto linux-next. It isn't like Stephen has anything better to do anyway ;).

More seriously though, those -stable fixes queued up for months show up there first. Perhaps if we watch the trees feeding into linux-next for a bit for fixes tagged with -stable in the middle -rc windows, we can prod maintainers more.

josh

Er.. probably should have said weeks or "a while" or something, not months.

Ok, I'll channel my "inner Linus" and take a cue from my kids and start swearing more.

I'm going to start pushing back on the "obviously this shouldn't be for stable" patches, and have done so, but you are right, the real issue is that it seems that subsystem maintainers are being lazy and just not sending the patches to Linus at all, because they "know" I will pick them up for the .1 or .2 release.

Specific example is, again, the powerpc patches. Out of 21 patches marked for stable that showed up in the -rc1 merge, at least 7 of them had _plenty_ of time to get into 3.10.0 as they are weeks, and sometimes months, old. Some of the other ones seem _very_ new, being only days old before they hit Linus's tree, which makes me worry about them for totally different reasons (i.e. not tested in linux-next at all.)

I can put a "delay" on patches to not hit a stable release for a few weeks until they get some testing in Linus's tree, but in reality, what's that going to help with?

I guess I can just not apply them at all, tough-love and all that, but that just puts an extra burden on the distro kernel maintainers to have to go dig up the fixes for their users.

Although really, who cares about powerpc anymore :)

Someone once did this, and I agree, it should be done more. I'll see about knocking up a script to try to automate it a bit to make it easier for me to do that. Dave has proven that we need to poke maintainers more to get their act together and push fixes to Linus.

greg k-h

So for the old ones that's me not actively sending you stuff that has a CC stable tag when I merge it. I should probably fix that indeed. This is especially true of (but not exclusively) stuff that I don't apply myself but merge via somebody else branch.

For the new stuff, this is a combinations of some last minute fuckups which are pretty specific to 3.10 and for which I'm in part responsible, and in part due to us basically ramping up testing on Power8 and getting ready for the next RHEL & SLES at the same time, thus doing more testing internally.

You'll notice that a lot of that stuff is P8 support so testing in "next" isn't going to help much since nobody outside of IBM has access to these guys yet. We are getting the stuff out there due to distro unrealistic expectations of having upstream code for new machines years before a release.

Also keep in mind that sometimes, that stuff has been around on patchwork for a while and got tested by various people, but the patch got a last minute rev of improved changeset comment or cosmetic polish.

Depends. In some of the patches I put in for stable, they fix something that 3.10 broke and the fixes are quite self-contained, waiting makes no sense.

At some stage I make a judgement call on a given patch, how "obvious" the fix is (I know they never are completely ... well most of the time), how invasive it is, what risk it represents outside of the are that it "fixes". I do mistakes, but generally I am fairly conservative in that area.

You know how the distro can be about that... especially when they invent idiotic junk such as kABI which prevents you from fixing things properly for the sake of [probably illegal] binary drivers, and so on... Distro seem to enjoy establishing a process that guarantee that an "enterprise release" is entirely comprise of utter junk (not even talking about all the in-house untested broken stupid crap they add to their kernels while at the same time being hard-ass with fixes coming from the vendors).

That was unfair :-)

Cheers,
Ben.

But Greg's a gentle giant. You're more like an angry penguin charging at you in excess of 100 mph.

-- Steve

41fa9a944 hwmon: (nct6775) Drop unsupported fan alarm attributes for NCT6775 b1d2bff6a hwmon: (nct6775) Fix temperature alarm attributes

Stable rules say: "It must fix a real bug that bothers people (not a, "This could be a problem..." type thing). All the above fit that rule.

But are those patches critical ? Sure, people complained about getting alarms on the wrong attribute or not getting alarms when they expected to, but critical ? No, unless some application at some point starts to shut down the system because of a false alarm. So I guess the above should not go into -stable, then.

Problem is with "bothers people" vs. "critical". A lot of things bother people which are not critical. I personally have to back-port patches from upstream into my company's tree to fix bugs. Do those patches always fix critical bugs ? No, but I still have to have them fixed. But I would still prefer to have those patches applied to -stable, first to ensure broad test coverage but also to prevent others to hit the same problems I had, and in the hope they do the same favor to me at some point.

Overall, given your feedback, I think that stable-rules should be clarified. "real bug ... bothers people" should replaced with a clear statement such as "It must fix a critical bug", and the list of examples should follow (instead of making the term "critical" a side note of the list of examples).

What you are really saying is that -stable shall not be used by anyone to assume that "this is a kernel you can use in your distribution", but that you _expect_ every distribution to run patched kernels and to spend a lot of time tracking down and applying upstream patches. Like Greg pointed out in one of his replies- you _want_ to put more burden on distribution maintainers.

Personally I am not sure if that really makes much sense - I for my part would prefer to have the official stable rules follow the "must fix a real bug that bothers people" rule rather than the "must fix a critical bug" rule, and have stable kernels which need as few as possible additional patches on top - all that for the simple reason to get as much test coverage as possible on a common baseline. But that may be just me.

Please keep in mind that not all of us were there at that time.

Unfortunately, my psychic capabilities really lag behind. Really, there are many rules in many areas in the kernel one can only learn from practice and from trying, not because it is written down. Where is it written down how submit patches for inclusion into -stable for anything in the /net tree ? The one way to find out is to send a request to -stable and get flamed at for doing so.

The point isn't really "Greg will silently accept it", but that there are many unwritten rules which one has to learn. Like with pretty much everything else, that also applies to -stable submission rules.

I have heard many maintainers state "not critical enough for -rc, I will submit it in the commit window and mark it for stable". Ok, I started to follow that approach as well, and you may feel free to shout at me for doing it.

But, really, folks, it _would_ help if you would consider clarifying the rules. Which may include more shouting by Greg - after all, we all learn from being shouted at.

Guenter

You cut out the important part:

- It must fix a problem that causes a build error (but not for things marked CONFIG_BROKEN), an oops, a hang, data corruption, a real security issue, or some "oh, that's not good" issue. In short, something critical.

That list is not a "or" list, it's an "and" list - it needs to follow *all* the rules. The exception is the "New device IDs and quirks are also accepted", which maybe should be made more clearly separate.

Right. And that's what the stable rules say. It's not enough to be a "real bug". It needs to be critical. If it's something that has been around forever, there needs to be a stronger argument than "I found a bug" for marking it for stable.

There is no "vs".

The "real bug that bothers people" rule is not meant to be seen as a separate rule from the next rule (already quoted above), it needs to be *in*addition*to*.

For example, we have the "causes a build error" case - but that should be seen in the "real bug that bothers people" light, and you should not mark Kconfig fixes for stable unless they have actually caused problems. Why? Because most Kconfig problems tend to be for unrealistic situations like "Oh, if I turn off PCI or networking, this driver no longer builds". Sure, that is a bug, and it's a bug that causes build error, but it's not something that bothers real people, because if you turn off networking or turn off PCI, you damn well had better also turn off all the other crap you don't need.

Yes, there are always going to be gray areas. And Greg is obviously a much nicer person than I am, so he's likely *always* going to be more generous about those gray aras than I would be. And within reason, I think that's perfectly fine - if there's a few patches that get marked for stable because it's easier for people to sneak them in that way, whatever. It becomes a problem only when it gets to be *too* common, which is apparently what happened now.

So I'm not going to argue that your particular patches were the problem here. I'm more arguing against your arguments than against the patches themselves. I'm not looking for some hard black-and-white rules that say "this is exactly how things have to work", because I don't think such rules can exist. But I _do_ want people to see the stable rules as fairly strict. And in particular, I really don't think people should see "post-rc4" to be any different from "stable".

If anything, I think post-rc4 should be easier to get into, if only because post-rc4 has the additional "hey, if it's new code that hasn't seen a release yet, we can be much more aggressive about it". For example, I think I'm *much* more open to reverting new commits entirely in the late rc's than we should ever be for stable.

Linus

I understand, but that is theory (mathematical interpretation) vs. reality. The "real bug ... must bother people" is the rule that is used in practice today. Problem may be that not even that rule is really followed anymore.

I am perfectly fine with that, but then you'll have to accept that the rules will be bent to the point where we are now ... if there are no clear rules, bending the rules until someone screams seems to be the best if not the only way to figure out how things are supposed to work.

My personal rule so far has been more pragmatic - if it is going to bother me as maintainer, I want it fixed in -stable. Otherwise I'll be bogged down forever having to tell people to use a later kernel to get a bug fixed. I don't really have enough time to do that, often people don't even have that option.

Guenter

The unwritten criteria that I've seen used (and sometimes even discussed on mailing lists) is that if it's something that distro kernel maintainers would want, then it's fit for stable. Now, there's a grey area here. The criteria before distro's "golden master" has been released is quite different compared to a criteria for a Service Pack 5 kernel. There's also a hjuge difference between a patch which has just hit mainline during the merge window, and a bug fix which has been in Linus's tree for weeks or months. It's likely that a bug fix which has been in the kernel since 3.8, even if it is not "critical" is one which might be suitable merging for 3.4. Heck, I've even had users screaming at me that it was somehow my duty as the ext4 maintainer to find these commits and backport them to 3.4 or 3.2. (Of course, I blow them off. :-)

So the problem is that maintainers are lazy. They don't want to go back for bug fixes that have "proven" themselves, and even if they aren't critical bug fixes, they are things which a distro maintainer or a stable kernel user might want (and sometimes stable uers are uppity enough to expect subsystem maintainers to do this back porting). So subsystem maintainers then react by marking submits for stable even though they really should soak for a release or two before submitting them, since by marking them as submit, the commit gets pushed to stable automatically --- albeit early.

Now, I'm not condoning this practice; but I suspect this is at least partially the reason why some maintainers have gotten more aggressive about marking patches for stable and not pushing them to mainline earlier.

If it really is the case that patches that are marked for -stable are patches that should just be sent to linus pre-rc4, and patches that had just been added to the subsystem maintainer tree a few weeks before the merge window shouldn't be automatically be merged into stable, maybe the right answer is that the stable kernel maintainers shouldn't be automatically including _any_ patches that are marked for stable which are sent to mainline during the merge window.

- Ted

Actually, this is a very good point. There were one or two stable patches I had pushed to linux-next that I wasn't too comfortable about. If the fix goes back to older trees, I rather have them stirring in linux-next and push it in the next merge window instead of pushing it to Linus and have it go to stable immediately.

Unless its a obvious fix, I tend to take about a month from the time I get a stable fix to the time I push it out. Making sure the stable fix doesn't introduce new bugs.

-- Steve

Indeed, which goes down to my comment somewhere else in this thread about "Cc:stable" being used as a convenient marker for a bug fix. Let's simply have a real marker and this should flow much smoother because end users will ask "Dear stable maintainers, could we please merge this patch, I need it".

Regards,
Willy

Like most of the other examples in this thread, one size doesn't fit all though.

Your example above: If that fix was for "tracing reports wrong results", no big deal, everyone can live with it for a month. If it was fixing "a bug in tracing can allow an unprivileged user to crash the kernel", a month is unacceptable, and at the least we should be getting an interim fix to mitigate the problem.

Dave

And even that isn't one size fits all. If the exploit is a -rc only, or even a newly released kernel. Is it that critical to get it fixed ASAP? I would think that the kernel releases takes time before they get to users main machines.

I would suspect that machines that allow unprivileged users would be running distro kernels, and not the latest release from Linus, and thus even a bug that "can allow an unprivileged user to crash the kernel" may still be able to sit around for a month before being submitted.

This wouldn't be the case if the bug was in older kernels that are being used.

-- Steve

That said, when I find a bug that can allow this, I still tend to make it #1 priority and get it out as quick as possible. Maybe a week at most. I had one such bug that only affected a -rc1 release, and I made sure the fix made it into -rc2.

-- Steve

But distros *do* ship the latest release from Linus. Fedora is often shipping .1 releases, and sometimes .0. This seems to be getting more difficult though as more and more fixes have been left for stable to fix and the Linus release contains a number of known regressions. We know about those regressions not just from following lists, but because we have users running rawhide kernels which are snapshots of Linus' tree almost daily. They see the regressions and complain. So yeah, there are machines out there running Linus' latest tree.

Justin

Hello,

On the one hand, you seem to want users with any kind of production systems to use distro kernels. On the other hand, developers want a broad testing base, with vanilla kernels (or better, rc) as early as possible. You cannot get both at the same time, some kinds of bugs just appear on production systems.

Users expect vanilla .0 releases usable as production systems, to be updated (meaning, no new features, just stabilizing) with the corresponding -stable series.

Just my 2p,
Jochen.

This really is a case by case basis. An unprivileged user exploit requires a box that lets other users than the owner of the box to log in. Most users of .0 releases do not do this.

But this isn't the point anyway. The point I was making is not to let the fix be worse than the bug it fixes. What happens if the fix to an unprivileged user exploit inadvertently opens an off by one bug that can be exploited by external users?

It comes down to each bug itself. If the fix is trivial and fixes a critical bug, it should be pushed rather quickly to mainline. But if the fix requires a redesign of some code, it would require more time. Luckily, most security bugs are quick fixes, and don't need a redesign of the code.

-- Steve

local exploits aren't just a problem for multi-user machines. An attacker who can own your firefox process, can now potentially escalate to root. (Ok, most exploits are just crashing the box, but how many times have we been proven wrong in the past when we thought something was just a DoS, and someone smarter has found a way to turn it into a root-hole?)

Dave

Of course I don't want to lower the importance of such a fix. But making sure the fix works and not rushed out is important too. It really is a case by case basis. Some bugs should get out to mainline and stable quickly, but a lot of them should also be verified to work before rushing to get them out the door. And verification does take a bit of time. The last thing we want a fix to do is to create a bug that could potentially be worse than the one being fixed.

-- Steve

I think that maintainers are balanced between the wish to satisfy their users and the risk of getting shouted at. Users expect stable versions to be bug-free. Most people I talk with have a different understanding of the development model than the one you present to contributors. They think that the .0 release is a draft and that all bugs will be fixed in -stable. I even know one person who uses -rc1 in production, claiming that these ones are stable. So end users don't necessarily understand the development model and ask what something they think is due : no known bugs.

On the other hand, we've seen many regressions introduced as fixes into -stable that had to be reverted afterwards, or sometimes completed with a missing patch.

I think that maintainers use the Cc:stable as a status for commits meaning "this is a bug fix". It's true that when you're digging into the commits to try to qualify fixes from features, it's really hard, and the new Cc:stable tag helps a lot.

So probably we should incite patch contributors to add a specific tag such as "Fixes: 3.5 and later", so that non-important patches do not need the Cc:stable anymore, but users who experience an issue can easily spot them and ask for their inclusion.

I've already experienced the other way around, been hit by a missing fix from 2.6.32.x that was not backported there probably because it was considered minor (and it was for most environments), except that it caused a complete web site to go down due to gro/gso issues with LVS. It's typically the type of bug that is not reported by most users, and that noone will consider critical, but once such a user encounters it, it's far too late, the harm is already done. It's too bad when both the bug and the fix are known and available, we just need to *know* they exist.

While we can't ask Greg to collect all the bug fixes on the planet, we should probably do something so that end users can more easily spot what is relevant to their usage and from time to time ask for these ones to be merged if that makes sense.

Willy

This is a really good idea. /me likes....

I will likely start adopting this for the ext4 tree.

- Ted

I agree, that would be very helpful.

Guenter

Huh? What's wrong with the existing way people mark stable patches to go back to much older kernel versions? Is that not working well enough for you?

And if something "fixes" an issue, then I want it in stable, just like Linus wants that in his tree.

Don't add another tag that requires users to dig for fixes that we are just too lazy to be including for all users, that way is crazy.

greg k-h

It's the difference between "this is a fix" and "please backport this fix into stable". As we aid in this thread, cc:stable is a bit too much automatic and sometimes not appropriate (not important enough fixes). But when fixes not apparently suitable for stable are merged into mainline, having the ability to spot them is useful, whether it is for later inclusion or just for users who'd like to run a kernel with more fixes than the critical ones accepted for stable.

I don't think so. If there is a gap between what is fixed and what is acceptable for -stable, this just fills this gap. It means less automatic submissions for -stable, only the important ones, and at the same time, a simple way of more easily spotting if a known bug affects your kernel when you're a -stable user and are experiencing an issue.

Willy

No, I've never said that.

I _want_ fixes in stable trees, as they are being done to, obviously, fix problems. So does Linus, why wouldn't a fix for something that is an issue for someone _not_ go into his tree after -rc4?

Ok, for some issues, they need some time to "bake" I can understand, but that's the exception not the rule at all.

If a distro would pick a patch up to solve a problem for a user, and that patch is in Linus's tree, there's almost no reason that shouldn't also be in the stable trees.

My issue is that people are trying to get me to take stuff that is _not_ fixes (i.e. build errors that are impossible to hit, or \n additions to debugging kernel messages, or pseudo-optimizations of functions).

The other larger issue is that people somehow are not willing to send their valid fixes to Linus after -rc4, and they flood in during the -rc1 merge and people expect me to backport them all into .1 because they are lazy.

Again, specific examples are the 7 powerpc patches that are over a month old that were marked for the stable tree, yet didn't hit Linus's tree until now. I can dig up more examples if wanted, just look at the flood that comes in for -rc1.

I _should_ be seeing more patches marked for stable showing up after -rc3 then for -rc1. As it is, I think there's something wrong with maintainers relying on me to do their work for them too much, and it's finally pushed me to start complaining and pushing back.

greg k-h

I do think that most of the fixes that are sent to stable should bake a little bit more, especially the ones that are not considered critical (and that according to Linus should not be in stable). After all that's what Davem does and there are probably less reverts in the stable net tree than in others.

It is *my* conception of the stable branch, but I think that many people have different expectations about what should be merged or not. For example in old LTS branches, I used to merge what was relevant for servers only, because I saw no reason why an old kernel would be used on a laptop (eg:
2.4). So I always skipped wifi, alsa, drm, etc... With 2.6.32, the Debian kernel guys provided me with a lot of fixes in these areas, explaining that these fixes addressed issues that their users were facing, and they were perfectly right. It's just that I didn't expect this at all.

But you see, maybe the '\n' additions are important to a specific development team who relies on this all the day for their work. Importance is a relative thing by nature. But I get your point anyway. Such low general importances fixes could be marked "fix" without being marked "cc:stable" so that users can later explicitly ask for their inclusion if they're concerned. That is the way we know the problem affects some users. A few tens of the fixes that went into 2.6.32.61 were requested by users, and I would never have have picked them on my own if they hadn't asked.

I'm 100% sure this is true. Some fixes are probably written against a -next tree, and adding a tag means "it will automatically be backported, no need for a separate branch for this".

I'm sure this is true. But at the same time I also think that there is a difference between what *you* expect in -stable and what Linus expects there. Linus says that something not suitable for past -rc4 has no place in -stable. You want most fixes that a distro would pick. But many of the fixes a distro would pick are probably not important enough to be picked past -rc4 and risk regressions. So these fixes are exposed to the world in -rc1 for the first time in their life, and unfortunately are merged at the same time.

The problem is to find a way to mark a fix as a candidate for stable but with a reserve for some observation period. Maybe just some indication that the fix should not be backported before the version it's merged into is released ? That could make sense after all : many fixes that went into 3.11-rc1 were not important enough to go into 3.10, so they can wait for 3.11 to be released before being backported. But that requires an extra queue.

Willy

We have lots of embeded systems running 2.6.32 kernel. And we encountered a critical bug, and we had to backported some patches which are not bug fixes to prevent the bug from happening.

If these patches are not too numerous nor too big, and that what they fix is really obvious, it could be useful to discuss their merging on the stable list, especially if you believe the bug is not specific to your environment.

Thanks,
Willy

You've not said this, but Linus has. Linus has pointed at the following words which are in stable_kernel_rules:

- It must fix a problem that causes a build error (but not for things marked CONFIG_BROKEN), an oops, a hang, data corruption, a real security issue, or some "oh, that's not good" issue. In short, something
critical. ^^^^^^^^^^^^^^^^^^^
^^^^^^^^

Linus has said he doesn't want fixes that aren't CRITICAL after -rc4.

So the problem is there's apparently a discrepancy between your standards for when a patch should hit stable, and Linus's criteria for post-rc4 inclusion.

Originally, this boundary for "nothing but regressions and critical fixes" was -rc3 at the latest, which is why I've sat on fixes after -rc2 has been released. But since you've wanted these fixes, I would mark them stable, with the assumption that by the time I've completed all of the regression tests before the merge window, it would be fine for stable.

Here's another real-life situation which is happening right now. It's almost -rc1, and I've believe that discovered a potential ext4 bug fix. It fixes a long-standing xfstest failure, that we've been trying to track down for several releases. This is the sort of thing that stable enterprise distro's would want (eventually), since otherwise their help desks would be tearing their hair out with a hard-to-reproduce and hard-to-root-cause bug report from the field. I'll probably want to push out this fix to Linus, assuming it passes all of my regression tests --- especially since Linus has said he'll now take bug-fixes before -rc4.

But is this the sort of thing that we would want in stable right away? I was thinking that perhaps the right thing to do was to mark it with a "Fixes: v3.8" (indicating that eventually this may want to be sent to all stable kernel releases v3.8+), but perhaps it shouldn't be automatically scooped up for stable, at least until a week or two after 3.11 comes out and we're sure that the bug fix doesn't introduce some other regression.

I'll note that technically this fix might not meet the "something critical" test in stable_kernel_rules, since it only occurs under extreme memory pressure, and it's otherwise extraordinarily hard to reproduce (but this is why it's extraordinarily expensive for enterprise distros to root cause these sorts of problem when they are reported from the field).

How about this? If patches marked for stable show up after 3.11-rc2, or 3.11-rc3, could they not get automatically scooped up until a week after 3.11 comes out? If a post-rc2 patch shows up in 3.10.x before 3.11 comes out, and it is not a __critical__ bug fix, I would be really uncomfortable about accidentally introducing a regression into the stable kernel tree --- at least for a subsystem like ext4, where a regression might lead to data corruption (which generally makes users a lot more cranky than a bug in some random graphics driver which just causes their system to reboot.)

If it's critical, I'll explicitly send it to [email protected]; but if it's not critical, I really would like more soak time in mainline before it gets picked up for stable. If you don't think this is appropriate for all subsystems, maybe it could be a per-subsystem policy --- but I really think this is a good idea for everyone.

Regards,

- Ted

P.S. Maybe this is a grey area that you're not worried about, and you're actually getting more cranky about people labelling whitespace fixes with [email protected]. My personal policy is those sorts of changes should *** NEVER *** be sent to the stable kernel series, regardless of when they hit either my tree or mainline....

Ugh, the conversation has degenerated now into parsing the meaning of specific words. This is why lawyers have created whole vocabularies that are not used by "normal" people. There's a very good reason why I'm not a lawyer, and this is one of them...

If I change the word "critical" to "real", would that make everyone happy here?

It comes down to the simple fact that for stable kernels I _want_ to take bugfixes that any user would hit. In other words, something that a distro kernel would take.

And, I'll throw up the famous "I know it when I see it", definition of what a valid fix is, to keep people from "word parsing" the exact way to write it all down.

It's a grey area, which is good, let's keep it that way.

And again, that's not the real problem here. The real problem is that people are keeping valid "fixes" out of the .0 kernel for some odd reason.

So here's what I'm going to do. I'm going to go through all of my pending stable patches in the next few days, discarding anything that remotely "hints"[1] that it should have been pushed to Linus for .0.

Then I'll notify those maintainers, and make them resend the patches, and explain _why_ they held off sending them, if they really want them in the stable releases.

That should hopefully start to notify maintainers that they need to step up and send stuff to Linus earlier, or they can justify why they didn't send them at the time (which is fine, I know I think I have valid reasons for why I didn't send some of my -stable patches in for the .0 release.)

I'll start digging through linux-next about -rc4 timeframe and watch for stable tags to show up, and start pestering people about why they are there and not in Linus's tree.

And then let's see what happens for 3.11.0, and the 3.12-rc1 merge window. If nothing's changed by then compared to this flood we got for 3.11-rc1, then we can revisit it then.

Yes, this is going to require more work on my behalf for the next few months, but what else was I going to do with my summer, actually enjoy the weather?...

Sound ok with everyone?

greg k-h

[1] A big hint is the date of the patch being a month or so before .0 was released. I'll point to the powerpc mess as an example of that...

Yes, but ***Linus*** has said he only wants critical fixes in his tree after -rc4. It seems pretty clear that what he wants post -rc4 and what you want in the stable tree are different.

You can change the stable_kernel_tree to be "real" bugs, but if Linus is still using "critical" as the standard for mainline post-rc4, then those of us who are maintainers are stuck between a rock and a hard place.

So it's not a matter of maintainers trying to lawyer the meaning of words, but that you and Linus have different criteria of what you feel should be sent to mainline after -rc4. And sorry, it's Linus's kernel, so I'm going to follow what appears to be Linus's criteria.

If you and Linus can't come up with an the same set of criteria, all I can do is to not send non-regression/non-critical, fixes post -rc4 (so Linus doesn't yell at me), and not mark non-critical bug fixes (even if distro kernels would want them) for stable (so you don't yell at me for not pushing them to Linus). What I'll probably do is mark them with "Fixes: v3.x" tag, and then I'll have to create my own scripts to send patches to [email protected] a week or two after Linus has released the 3.y.0 kernel.

Regards,

- Ted

You are confusing the words "real" and "critical" perhaps. I, and other large subsystem maintainers, based on how they submit fixes to Linus and to stable, view the late -rc portion as time for fixes that affect users and other issues like that. So far, it's worked out pretty well and we don't seem to be in disagreement with Linus's view of what is a valid late -rc fix based on recent kernel development cycles.

The issue now is, we have maintainers who aren't sending stuff to Linus at all in the late -rc cycle and are relying on me to pick up things that are obviously "real" and "critical" fixes after .0 is out for .1 and .2 to resolve "real" issues.

You are not one of these people, so I don't understand why you are getting upset and think that you somehow need to change how you mark stuff for stable.

The powerpc and iscsi people on the other hand, they need to look out...

chill out please and go enjoy the rest of the weekend,

greg k-h

A typical classification of bugs might be
critical: mission critical, no workaround, must be fixed prior to
customer release
severe (high): related to core functionality, must fix, but not
necessarily in first release.
moderate (medium): Bugs that do not affect any critical user
functionality; typically has workaround
minor (low): Bugs that do not interfere with core functionality
and are just annoyances that may or may not ever be fixed
cosmetic: misspellings

Such classifications are widely used in the industry. The term "affecting users" might apply to all of those, and even a cosmetic bug is "real".

I don't think this is about confusion, but about classification. Clearly we don't want patches for cosmetic or minor bugs in stable releases, but where is the cut-off point ? That may be clear for you and some of the maintainers, but for me and probably many other maintainers, "critical" has a well defined meaning which neither includes severe nor moderate bugs as per the classification above.

The term "real" is much more vague and left to interpretation. My cutoff point would be around "moderate" - it does affect users, but it is not critical functionality. What is yours ?

Guenter

And typically there's a distinction between severity (how bad is it), and priority (how soon it should be fixed), wich are not always linearly correlated.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]

In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

It appears it may not be good enough for some, otherwise we would not have this discussion.

Except if it is not critical, for a given definition of the word.

Depends. If -stable rules are going to be followed by the letter, as has been suggested, only critical bug fixes would be applied to -stable. The idea here is to provide guidance to distribution maintainers if that is happening. This tag would mean something like "This patch fixes a real bug which affects the following releases, but it will not be applied to -stable because it is not critical".

Guenter

I'm not going to try to parse definitions here, but this is just crazy.

What? It's a fix for a problem that is "real", why would that _not_ go into stable and Linus's tree?

Anyway, again, that's not the real issue here at all, the real issues are, again:
- people marking stuff for -stable that they shouldn't.
- people sitting on stuff for -stable way longer than they should be, relying on me to get stuff merged for the .1 or .2 release instead of getting it to Linus for .0.

let's work on those two first before we start worrying about if a specific "fix" shouldn't go into the stable tree or not.

greg k-h

So if I read this (and stable_kernel_rules.txt) correctly, that means that for example, let's say, we find in RHEL66 or SLES42 (possibly following a user report), for example, that PCI hotplug is broken with some category of devices on some machines.

We do a fix, it's roughtly 4 or 5 lines, pretty self contained. We get it into the distro.

That still doesn't qualify for stable right ? We have to start shooting at every distro around separately or wait for users of those other distros to also hit it ?

Where is the line when something "Doesn't work" (without crashing/oops'ing or being a security issue) ?

My personal line so far has been to take it and send it to -stable if the patch is simple enough and self contained (little risk of side effects).

But I can stop if that's indeed the accepted rule.

Cheers,
Ben.

Not before it's been in the distro, no. Something like a PCI change *definitely* should never be marked for stable, unless it causes crashes or is a _new_ regression that causes dead machines.

Because the likelihood that that 4-5 line "obvious" change breaks things is pretty high. It needs testing elsewhere - on the machines that weren't broken - in a big way first.

And don't bother talking about "obvious fix". Especially not when it comes to the PCI code.

Linus

PCI resource allocation code for sure. A bug specific to the hotplug code path not so ... (for example, a too short reset delay or shit like that). I agree with you overall but there's still a judgement call happening at some point I assume and we get at least *some* flexibility as maintainers as to what we want going there or not right ? :-)

Cheers,
Ben.

Can you stop about powerpc for a minute Greg ? It's becoming tiring.... When it's not this (seriously ? We are by FAR not the worst managed architecture around here but you seem to pick on any opportunity, public medium, etc... to trash us for whatever reason, time to find another axe to grind really).

Also look at the damn history. We rarely had that much stuff going back. You know 3.10 is special and you probably know why, and I've mentioned already that a lot of that stuff you are complaining about affects HW that people do NOT have presently access to outside of IBM.

Please, go play another violin.

Ben.

At least at one point in the past, the rule that Linus had laid down after discussing things at Kernel Summits was after -rc2, or maybe -rc3 at the latest, the ***only*** fixes that should be sent to Linus would be for regression fixes or for really serious data integrity issues. The concern was that people were pushing bug fixes in -rc5 or -rc6 that were in some cases causing regressions.

(As I recall, Linus laid down the law regarding this policy in his own inimitable and colorful style; which today would result in all sorts of tsk, tsking on Hacker News regarding his language. :-)

In any case, I've been very conservative in _not_ pushing bug fixes to Linus after -rc3 (unless they are fixing a regression or the bug fix is super-serious); I'd much rather have them cook in the ext4 tree where they can get a lot more testing (a full regression test run for ext4 takes over 24 hours), and for people trying out linux-next.

Maybe the pendulum has swung too far in the direction of holding back changes and trying to avoid the risk of introducing regressions; perhaps this would be a good topic to discuss at the Kernel Summit.

Regards,

- Ted

In my defense here, the patches that have been CC'ed to 3.10.y stable are to address bugs in iser-target, and it's interaction with existing iscsi-target code after the large set of refactoring changes went in to support multi-transport operation.

The reasons that they where not included in a v3.10-rc pull request is because the bugs where found sufficiently late enough in the cycle, and required large enough changes plus a non trival amount of manual failure injection testing to verify their correctness.

--nab

Bah, I sent out a similar email about discussing this at KS too. Before seeing this one.

-- Steve

If this is going to be picked up as a discussion topic at KS, I believe it can be easily merged with my "stable: too pushy maintainers" proposal I sent a couple days ago.

Thanks,

Jiri Kosina
SUSE Labs

Yes, I agree.

josh

Yes, there does seem to be a certain ebb and flow as to how strict the rules are about what should go into stable, what fixes are "good enough" for a given -rc, how tight those rule are in -rc2 vs in -rc6, etc. If nothing else, a good repetitive flogging and a restatement of the One True Way to handle these things might be worthwhile once again...

John

John W. Linville		Someday the world will need a hero, and you
[email protected]			might be all we have.  Be ready.

The rules are documented in stable_kernel_rules.txt for what I will accept.

I have been beating on maintainers for 8 years now to actually mark patches for stable, and only this past year have I finally seen people do it (we FINALLY got SCSI patches marked for stable in this merge window!!!) So now that maintainers are finally realizing that they need to mark patches, I'll be pushing back harder on the patches that they do submit, because the distros are rightfully pushing back on me for accepting things that are outside of the stable_kernel_rules.txt guidelines.

If you look on the stable@vger list, I've already rejected 3 today and asked about the huge 21 powerpc patches. Sure, it's not a lot, when staring down 174 more to go, but it's a start...

greg k-h

What do you mean FINALLY? There've been SCSI patches marked for stable in every other merge window as well. The whole reason I ran the stable patch tracker before you took it over was so I could get the Cc: to stable stuff working.

James

On the subject of the stable tree: could we get a standard format for requesting post-inclusion elevation of patches to stable status? It isn't all that unusual that the need for -stable is highlighted after a patch has been included in a maintainer's tree, and rebasing to add stable metadata annoys Linus.

-hpa

After it's in Linus's tree, just send the git id of the patch to [email protected], along with what stable tree(s) you want to see the patch backported to.

Documentation/stable_kernel_rules.txt should be pretty explicit about how to do this, but if not, patches to it are always welcome.

Yes, this requires you to remember to do this after it hits Linus's tree, so you could do like David does for networking, and keep a seperate tree to send to me specifically for stable patches. I think he uses patchwork, but I know others use git for this, and that's fine as well.

greg k-h

Perhaps just make a separate stable branch, where you cherry-pick the specific patch using the -x option. Adds a "(cherry picked from commit ...)". Then you could have some filter that monitors Linus commits and when a commit matches one of these patches, have it automatically sent to the stable list.

-- Steve

Actually, please don't use -x very much. It doesn't much help, and it can get very confusing before things are merged, and people who are on one branch don't even see the other "identical" commit.

But cherry-picking patches is fine, if they really are stable material. Feel free to send me a patch during -rc4 that ends up *also* being in your tree for the next merge window, and don't worry too much about it. It will cause merge problems if you then have other patches on top of it that touch the same code, but for stable-quality patches those tend to be really easy to fix up ("Oh, both branches already have this patch, I should obviously take the version from the branch that has five other patches on top too"), and most of the time it merges cleanly anyway because there isn't anything else right there on top of it anyway.

In fact, I'd *much* rather see the same fix committed twice in two different maintainer trees than see cross-maintainership merges, which is what some people do in order to pick up some trivial fix. The cross-maintainership merges are much more painful, and tend to result in "Oh, I didn't send in this pull request in a timely manner in the merge window, because I was waiting for that *other* pull request to go through first".

If it's that kind of a critical patch, it really probably *should* go in twice. Of course, if it gets more complicated and bigger, then duplicating the fix is a bad idea, and then you might want to have a separate branch just for that particular fix.

Linus

Actually I was trying to answer HPA's question about how to notify stable of a patch that wasn't tagged for stable, and one that you need to remember when its committed by you.

Say I get a bunch of patches and add them to a branch queued for an -rc (all fixes for the current release). Then I notice that one of the patches is a fix for older kernels as well, but it has already been made public. As to tag it for stable would require a rebase, but its still in a queue to be sent to you, and others may have based their work on it. The question now is, how do I remember to notify stable of this patch when its part of a queue going to you already?

Is it OK to cherry pick the patch separately, and add the stable tag, and queue that up to you first? That way the stable automated process will trigger when you take it.

Basically, there's been times when branches have been made public before it is realized that a commit in that branch should go back to older trees, not just a fix for the current -rc release. Thus, this is not a question of sending a stable fix to you, but a fix that is already queued to go to you and later realize it needs to go to older trees as well. Greg likes it when you send that patch after it is in mainline. But remembering which patch to send isn't always trivial, and can be forgotten about. I was giving an answer to that question.

Having the separate stable branch that will never be pushed to you and only used as a database of what needs to go to stable for older kernels is what I was going for. It doesn't need to be a git branch at all. It could just be a directory of files that was created via a git format-patch.

-- Steve

The git branch has the advantage of allowing git power tools for processing.

Say you "cherry-pick -x" all commits for stable to a private branch named "for-stable".
Then "git cherry -v linus/master for-stable" will prefix all commits that are already upstream with a minus sign, so you know when to ping stable. Commits prefixed with a plus sign are still pending (or got applied with some mutilation, i.e. you want to double-check).

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]

In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

FWIW, Documentation/stable_kernel_rules.txt currently says that you should send the patch. I checked to see whether sending the git id was sufficient, and upon reading stable_kernel_rules.txt, decided to simply run git format-patch/git send-email of the commits in mainline. Apparently no one seemed to mind....

- Ted

That is what I do as well, with an added explicit reference to the upstream git id in the commit log.

Guenter

My main point was actually to have something that could be automatically recognized and flagged by maintainer tools, which an informal email really can't.

This relates to the "a posteori metadata" problem with git. In theory I think git notes should handle those, but I have to admit that git notes somewhat creep me out because there doesn't seem to be any version control on them, and as far as I can tell there is only one note per object.

-hpa

OK, just read up some more on git notes, and *both* the assumptions I had made about git notes were fundamentally wrong. Not sure how well they would scale, though, but stuffing metadata like additional Acked-by:, Tested-by: and Cc: stable into notes seems more viable after reading the spec.

-hpa

I really don't want to use git notes for anything that actually gets distributed.

They can be useful for "local" notes (they can be very powerful for certain workflows), but they won't be pulled and pushed by me.

Linus

Perhaps notes can be used as that reminder to send to stable. Tag a commit with a note, and have some automated process that monitors Linus's tree and when a commit makes it in, automate an email to stable with said commit.

-- Steve

Including quick sanity tests to see if these patches apply cleanly to stable releases in this automation process will help weed out patches that don't apply as is to stable releases.

-- Shuah

Ick, no, I'm not going to be using git notes for anything, sorry.

Is it _really_ all that hard to remember what to mark for stable inclusion? If you figure it out after you have committed the patch, then just put a copy of it somewhere to remind yourself. That seems to be what both David and I do with no problems, and I think we both deal with more individual patches and developers than probably most everyone else combined.

That's what mailboxes are for, use a script of 'git send-email' to send it to yourself and save it somewhere. Use patchwork. Use a text file to remind yourself. Use quilt, like Andrew does, he has a great track record of marking patches for the stable trees properly. Use something, it really isn't that hard, or at least, it sure shouldn't be, if you really care about it.

greg k-h

Or use git notes locally ;-)

-- Steve

For the record, my main reason for wanting something like git notes is that it is now X years after a patch, the maintainer is gone, and tracking down someone who knows about the patch is really valuable. Someone acking a patch after the fact is someone who looked at it "back then", and can be tracked.

Yes, you can find this in mailing list archives and so on, but we have had problems with such extrinsic information not being as sticky as we'd like.

-hpa

Didn't Linus just say he won't do that?

Either way it would seem to fail to accomplish the record-keeping aspect.

-hpa

Regardless of any scalability and other technical merits, allowing tags to go into a commit log entry via git notes would IMO dilute the value of Acked-by and Reviewed-by tags and it would actively hurt our kernel development workflow I think.

Today there's a time limit on acking/reviewing patches: if it did not arrive by the time the code was committed and pushed out, it does not get into the commit log, ever. That gives people an incentive to be active _before_ a patch gets applied.

And that's really how it should work IMO: the most important, most critical decision point is when a patch gets applied to a tree with the intent to send it upstream. Maintainers need the most help at that point. Anything after that, unless it points out actual problems or room for improvements (which will generate new commits), is not very useful.

So adding git notes after that point to add Acked-by or Reviewed-by tags is just post facto whitewashing, ego stroking or pointless act self-serving bureaucracy, beyond being a sign of a broken Git workflow to begin with.

Thanks,

Ingo

I don't quite understand why they are pushing back on you rather than on the maintainers who have marked the commits they have problems with for -stable. Why are you supposed to play the role of the gatekeeper here? Can't maintainers be held responsible for the commits they mark for -stable in the same way as they are responsible for the commits they push to Linus?

Also, I don't really think that the distros have problems with fixes that are simple and provably correct, even though the problems they fix don't seem to be "serious enough" for -stable. They rather have problems with subtle changes whose impact is difficult to estimate by inspection and you're not going to be pushing back on those anyway (exactly because their impact is difficult to estimate).

And 2 of those 3 rejected were mine and for 1 of them I actually had a very specific reason to mark it for -stable as I told you: It fixed a breakage introduced inadvertently in 3.10 and I thought it would be good to reduce the exposure of that breakage by fixing it in 3.10.1 as well as in 3.11-rc.

Of course, you are free to disagree with that, but it's not like there was no reason.

Thanks,
Rafael

I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.

Because I'm an easy big target and people are lazy.

I know that, you know that, but managers who see tons of kernel patches just get scared :)

There was no real breakage, that is why I rejected it.

greg k-h

Well, why don't you tell them "Please talk to the maintainer directly" and if the maintainer doesn't want to talk to them, *then* you deal with the maintainer?

They can see in the git log who marked the commit for -stable, so contacting that person shouldn't be too difficult.

That's an interesting angle. :-)

So you're pushing back on things that aren't "broken enough" presumably to make those people feel better, but they will only feel better for a while until they realize that the problems they had (generally speaking, regressions in -stable caused by commits that shouldn't be there) are still present, even though they don't see tons of patches any more. I'm wondering what the point is, then?

That's the root of the problem: My "real breakage" doesn't seem to be the same as your "real breakage". To me, if I can *see* breakage in the code, it's broken. And I mean breakage, not just coding style problems etc. Code review is our first line of breakage detection and if we catch it at that level, we don't even ask the compiler what it thinks about that code. We don't apply the patch. And if we've already applied it, which is unfortunate, there is no reason whatsoever not to fix it. Regardless of whether or not it is called "stable" at this point.

Thanks,
Rafael

I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.

Looks like each maintainer may have his rule which may differ from the rule laid down by Linus.

I have 2 network patches which went into 3.10-rc6, though these two bugs are not regressions but has been there even before the git history.

On the other hand, 2 of my cgroup bug fixes were queued for 3.11 with stable tag added.

And what about Documentation fixes and updates? Should those patches also follow Linus' rule? I guess people have different opinions.

Documentation fixes that go in as part of a patch series follow the rules of that series. Ye olde Documentation maintainer (me) is mostly here for catching stuff that would otherwise fall between the cracks, and to reorganize Documentation after the fact into less of a "giant unorganized heap". (Working on that last bit...)

Documentation fixes aren't going to introduce runtime regressions or break "git bisect", and if the noise they generate is limited to the Documentation directory the maintainer tools can filter it out.

Rob

And maybe in the end, having 1/10 patch cause a regression is not *that* dramatic, and probably less than not fixing the 9 other bugs. In one case we rely on -stable to merge the 10 fixes, and on the other case we'd rely on -stable to just revert one of them.

Also there has never been any promise of very stable mainline kernels, and at the same time the rules for getting patches in -stable are strict. So this means that most fixes should probably be pushed to mainline anyway otherwise we risk never to get them, which means lower overall quality.

Just my two cents,
Willy

Apologies for the late post, I'm catching up on things, but this jumped out at me.

We went through a LOT of pain several years ago when people got into the mindset that a patch was acceptable if it fixed more people than it broke. eliminating that mindset did wonders for kernel stability.

Regressions are a lot more of a negative than bugfixes are a positive, a 10:1 ratio of fixes to regressions is _not_ good enough.

David Lang

At Tue, 16 Jul 2013 00:19:16 -0700 (PDT),

IMO, one of the reasons is the nature of stable-release: the stable tree is released soon after reviews of patches, so no actual regression tests can be done before the release.

For finding a regression, patch reviews won't be enough; all patches have been already reviewed, thus essentially they must be all positive/good fixes. And the compile is OK. So what's the problem?

Maybe some QA period before the release might help, but who would care? (Especially under the situation where everybody has own x.y stable tree?)

Takashi

I am not saying that no regressions will happen (for exactly the reasons that you are giving).

what I am complaining about is the attitude that a few regressions are Ok, as long as there are more fixes than there are regressions.

David Lang

At Tue, 16 Jul 2013 09:42:34 -0700 (PDT),

I don't expect that no regression will happen, too. I'm no dreamer:) But I expect we can reduce the regressions, at least.

Agreed. And this is the difficult point. No one introduced regressions at its will. Mostly they are overlooked mistakes. So, where is the border line and how to distinguish? Can't we backport uncritical fixes even if users want them explicitly? I guess there seem different opinions on these.

thanks,

Takashi

Hopefully people tracking the upstream stable trees would be throwing any pre-release stuff into their QA processes before it was officially released upstream, though I'd not count on it.

Linux testing is (realistically) done by inflicting changes on gradually wider sets of end users.

We go through these stages (possibly a couple of extra steps where maintainer trees are nested)
1) Author of a patch tests on their own machine (and perhaps a few others)
2) Patch is posted. A few more people grab and test.
3) Patch is applied to a maintainer tree, which is slurped into linux-next. A few hundred brave folks now have this patch in their binary, but most extra testing is purely accidental. These users aren't running focused tests on the area touched by the patch.
4) Patch is pulled by Linus. Pretty large jump in the number of users running the code so we start to get good breadth of testing on different machines with different sets of CONFIG options under varying workloads.
5) Linus releases a final 3.x version - another substantial bump in the number of testers because there are lots of people who wait for "release" quality kernels.
6) Fedora, Ubuntu etc. use this 3.x kernel as basis for a release. Probably two or three orders of magnitude more users (but only a fraction of their problems are reported back to LKML).

Thus code does get more and more QA - the longer you wait before taking a patch the lower the risk that it has some unintended side-effect or outright bug . But of course you are vulnerable in this whole period to whatever issue the patch was actually trying to fix. So you have a classic tradeoff.

-Tony

However, one thing that people should keep in mind that the testing is often self-selecting.

This is particularly true for "obvious fixes". The _only_ early testers tend to be the people who saw the problem in the first place, and the fact that a patch fixes it for *them* can be very very misleading during that early testing phase. Because obviously that self-selecting group of people were somehow fundamentally different from the rest of the world, and different in a way that was very particular to the problem.

This is in particular what we've often seen with things like the PCI layer resource management, and what we used to see a lot back in the bad old days wrt suspend/resume. And it's why I'd really prefer for even "obvious" patches to not be backported all that aggressively unless there is very strong pressure. It's very much why that stable documentation talks about "critical" issues.

There have been tons of obvious patches that turned out to simply be wrong - often for very non-obvious reasons. Even when they are small. And the problems seldom get caught in early testing, often exactly because of this self-selecting property of testers (and test*ing* - when you fix a particular behavior, you tend to test the behavior you're trying to fix, you don't test the other cases that the patch wasn't about).

Anyway, the point I'm making is that Q&A is limited and often even actively misleading ("Hey, I have three tested-by's, so it must be fine"), and we might actually want to have a new class of "non-critical patch that might be worth backporting to stable, but only do so after it's been in a release for some time". Because while it might be an "obvious" fix, maybe it's not critical enough that it needs to be backported _now_ - maybe it could wait a month or two, and get wider testing.

Linus

Should we add another stable tag?

Have the default Cc: stable have to wait a rc or two in mainline before it makes its way to the stable tree. Have a stable-critical for those that are bugs that are security fixes than need to be backported ASAP.

-- Steve

People mark stable patches that way already today with a:
Cc: stable <[email protected]> # delay for 3.12-rc4
or some such wording. I take those and don't apply them until the noted release happens, so you can do this if needed.

greg k-h

I guess the thing is, are stable patches prone to regressions. Do we just do that for patches that we think are too complex and may cause some harm. Of course, there's the question about having a clue about what patches might cause harm or not.

For tracing patches, I test them probably more than most people, as tracing isn't usually done on non development machines. A regression in tracing isn't likely to harm others.

Right now it doesn't seem to be an issue because we have "Greg" doing things at light speed. But when stable is maintained by a lesser deity, then we may need to look at changing the process.

-- Steve

We'd probably better switch the tag to be "# now" to imply that we don't want to delay them, and that by default those merged prior to rc4 are all postponed. I suspect that the switching could be mostly automated this way, avoiding to add burden to Greg :

- if commit ID >= -rc4
move to immediate queue, it's a "critical" fix as per Linus' rules

- if Cc: stable line has "now" at the end, move to immediate queue as

    the maintainer takes this reponsibility ;

- otherwise move to the next .2 queue.

Willy

I think this might work. I definitely agree that most fixes aren't worth the risk of allowing into a stable release that quickly, so it's the right default.

I can't speak for Greg, but that seems reasonably easy to implement. (Which I would have to do, as I was unable to reuse Greg's scripts.)

Ben.

Ben Hutchings
Humans are not rational beings; they are rationalising beings.

But this is not documented in stable_kernel_rules.txt. And it's not handled by your automatic scripts?

I like the idea of postpone stable patches by default.

I can't agree more, I know it's one of my defaults. I don't count the number of bugs I have introduced in Haproxy while fixing a bug, and I know this and care a lot about this. Still shit happens. And I'm sure I'm not the only one out there !

That's what was discussed earlier in this thread, something like not merging into stable before current kernel is released plus maybe one .1 stable version to ensure that we've got some bug reports. That would mean something like "don't backport this before 3.12.1 has been released" for example. The tag could simply be "Not-Before".

Willy

The way I typically mark those kinds of fixes is that I don't add a [email protected] tag to the commit and wait for explicit complaints to come up. I also sometimes remove -stable backport tags from fix submissions.

Requests for backports will arrive with a time delay (if at all), which gives the perfect opportunity to review its upstream status (whether there are followup problems with the patch, etc.) and forward the commit to -stable, at which point it's already been upstream for a couple of weeks, sometimes months.

I don't think this scenario needs to be or can be automated via a special
tag: the main problem is that when the fix is applied we rarely know how widely users care about it. I think dealing with them 'statistically' (i.e. waiting for a backport request) measures that property pretty accurately.

The nice thing about it is that it all self-balances if people just add -stable backport tags more judiciously.

Thanks,

Ingo

Hi Takashi,

Almost nobody *tests* the previews. Except the few regular testers, but they test in a finite environment so there is very little coverage in the end. I'm not dismissing their work, because without them we'd have zero testers. I'd prefer to have more than we currently have. But it's also almost impossible to test reviews on servers, so a wide category of fixes is probably never tested anyway during previews (eg: RAID cards, or fixes for bugs affecting large amounts of memory/disk/cpus).

What makes the success of -stable is that Greg is able to re-release very quickly when a bug is reported, sometimes even the same day. It's something I'm totally incapable of, not having enough contiguous spare time to work regularly enough on releases. That's the real key to success. As a user, I look at the changes between versions and generally only upgrade if something seems to be hitting me. That way I need less updates and skip more regressions. And I'm sure most users do the same.

Regards,
Willy

In my opinion, there is one exception, and that is when the problem being fixed is much more severe than the fix. *In particular* two
cases: permanently damaging hardware and corrupting data. For example:
no boot, as severe as it is, is much better than either of these two scenarios.

-hpa

True, but the key point of this subthread is that regressions are _really_ bad, and in practice it's impossible to do enough testing to guarantee that there aren't regressions.

as a result, you should only risk regressions if the problem that is being fixed is really important. Just because someone found a bug doesn't make it important enough to risk regressions over.

David Lang

And at at least one *other* point in the past, Linus stated that "holding back anything with a Cc: stable waiting for the merge window is wrong". This would imply that the post-rc5-or-so policy and the stable policy are effectively the same.

Now, "policy" is a big word, and Linus and the maintainers generally have exercised discretion here and I would think that a lot of it really depends on the trust relationship between Linus and maintainer, or between maintainer and submaintainer. I generally try to flag to Linus when I push something that he may consider questionable, and I very rarely get

I think it would, to the extent such a policy is needed and workable. I think there is a serious risk in getting to hung up on policy.

-hpa

Patches applied cleanly to 3.0.85, 3.4.52, 3.9.9, and 3.10

Compiled and booted on the following systems:

Samsung Series 9 900X4C Intel Corei5:

     (3.4.53-rc1, 3.9.10-rc1, 3.10.1-rc1)
HP ProBook 6475b AMD A10-4600M APU with Radeon(tm) HD Graphics:
     (3.0.86-rc1, 3.4.53-rc1, 3.9.10-rc1, and 3.10.1-rc1)

dmesgs for all releases look good. No regressions compared to the previous dmesgs for each of these releases. dmesg emerg, crit, alert, err are clean. No regressions in warn.

Cross-compile testing:
HP Compaq dc7700 SFF desktop: x86-64 Intel Core-i2:

     (3.0.86-rc1, 3.4.53-rc1, 3.9.10-rc1, and 3.10.1-rc1)

Cross-compile tests results:

alpha: defconfig passed on all
arm: defconfig passed on all
arm64: not applicable to 3.0.y, 3.4.y. defconfig passed on 3.9.y, and 3.10.y
c6x: not applicable to 3.0.y, defconfig passed on 3.4.y, 3.9.y, and 3.10.y
mips: defconfig passed on all
mipsel: defconfig passed on all
powerpc: wii_defconfig passed on all
sh: defconfig passed on all
sparc: defconfig passed on all
tile: tilegx_defconfig passed on all

-- Shuah

Shuah Khan, Linux Kernel Developer - Open Source Group Samsung Research America (Silicon Valley) [email protected] | (970) 672-0658

Great, thanks for testing all of these and letting me know.

greg k-h

At Thu, 11 Jul 2013 15:01:17 -0700,

This kernel can be built and boot without any problem. Building a kernel with this kernel also works fine.

- Build Machine: debian jessy x86_64
CPU: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz x 4
memory: 8GB

- Test machine: debian jessy x86_64(KVM guest on the Build Machine)
vCPU: x2
memory: 2GB

Thanks,
Satoru

And you expect that we all have time to dig that out from lkml in 1 day ? You have a rant about powerpc and don't CC me ? :-)

This one is really important/urgent:

74251fe21bfa9310ddba9e0436d1fcf389e602ee
"powerpc/powernv: Fix iommu initialization again"

Cheers,
Ben.