[ 00/19] 3.10.1-stable review

[ 00/19] 3.10.1-stable review

[Greg Kroah-Hartman]

<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 <gregkh@linuxfoundation.org>
    Linux 3.10.1-rc1

Michal Hocko <mhocko@suse.cz>
    Revert "memcg: avoid dangling reference count in creation failure"

Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
    cpufreq: Fix cpufreq regression after suspend/resume

Ben Hutchings <ben@decadent.org.uk>
    SCSI: sd: Fix parsing of 'temporary ' cache mode prefix

Gleb Natapov <gleb@redhat.com>
    KVM: VMX: mark unusable segment as nonpresent

J. Bruce Fields <bfields@redhat.com>
    nfsd4: fix decoding of compounds across page boundaries

Andy Adamson <andros@netapp.com>
    NFSv4.1 end back channel session draining

Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Revert "serial: 8250_pci: add support for another kind of NetMos Technology PCI 9835 Multi-I/O Controller"

Peter Hurley <peter@hurleysoftware.com>
    tty: Reset itty for other pty

Zhang Yi <wetpzy@gmail.com>
    futex: Take hugepages into account when generating futex_key

Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    MAINTAINERS: add stable_kernel_rules.txt to stable maintainer information

Kees Cook <keescook@chromium.org>
    crypto: sanitize argument for format string

Kees Cook <keescook@chromium.org>
    block: do not pass disk names as format strings

Mikulas Patocka <mikulas@artax.karlin.mff.cuni.cz>
    hpfs: better test for errors

Kees Cook <keescook@chromium.org>
    charger-manager: Ensure event is not used as format string

Rusty Russell <rusty@rustcorp.com.au>
    module: do percpu allocation after uniqueness check. No, really!

Jonathan Salwan <jonathan.salwan@gmail.com>
    drivers/cdrom/cdrom.c: use kzalloc() for failing hardware

Josh Durgin <josh.durgin@inktank.com>
    libceph: fix invalid unsigned->signed conversion for timespec encoding

majianpeng <majianpeng@gmail.com>
    ceph: fix sleeping function called from invalid context.

Tyler Hicks <tyhicks@canonical.com>
    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(-)

[ 01/19] libceph: Fix NULL pointer dereference in auth client code

[Greg Kroah-Hartman]

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

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

From: Tyler Hicks <tyhicks@canonical.com>

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

Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
Reported-by: Chanam Park <chanam.park@hkpco.kr>
Reviewed-by: Seth Arnold <seth.arnold@canonical.com>
Reviewed-by: Sage Weil <sage@inktank.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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

--- a/net/ceph/auth_none.c
+++ b/net/ceph/auth_none.c
@@ -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,

[ 02/19] ceph: fix sleeping function called from invalid context.

[Greg Kroah-Hartman]

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

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

From: majianpeng <majianpeng@gmail.com>

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.

Signed-off-by: Jianpeng Ma <majianpeng@gmail.com>
Reviewed-by: Sage Weil <sage@inktank.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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

--- a/fs/ceph/xattr.c
+++ b/fs/ceph/xattr.c
@@ -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;

[ 03/19] libceph: fix invalid unsigned->signed conversion for timespec encoding

[Greg Kroah-Hartman]

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

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

From: Josh Durgin <josh.durgin@inktank.com>

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)

Signed-off-by: Josh Durgin <josh.durgin@inktank.com>
Reviewed-by: Sage Weil <sage@inktank.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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

--- a/include/linux/ceph/decode.h
+++ b/include/linux/ceph/decode.h
@@ -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);
 }

[ 04/19] drivers/cdrom/cdrom.c: use kzalloc() for failing hardware

[Greg Kroah-Hartman]

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

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

From: Jonathan Salwan <jonathan.salwan@gmail.com>

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.

Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Cc: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Jonathan Salwan <jonathan.salwan@gmail.com>
Cc: Luis Henriques <luis.henriques@canonical.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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

--- a/drivers/cdrom/cdrom.c
+++ b/drivers/cdrom/cdrom.c
@@ -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;
 

[ 05/19] module: do percpu allocation after uniqueness check. No, really!

[Greg Kroah-Hartman]

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

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

From: Rusty Russell <rusty@rustcorp.com.au>

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.

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Tested-by: Jim Hull <jim.hull@hp.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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

--- a/kernel/module.c
+++ b/kernel/module.c
@@ -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)

[ 06/19] charger-manager: Ensure event is not used as format string

[Greg Kroah-Hartman]

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

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

From: Kees Cook <keescook@chromium.org>

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.

Signed-off-by: Kees Cook <keescook@chromium.org>
Cc: Anton Vorontsov <cbou@mail.ru>
Cc: David Woodhouse <dwmw2@infradead.org>
Signed-off-by: Anton Vorontsov <anton@enomsg.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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

--- a/drivers/power/charger-manager.c
+++ b/drivers/power/charger-manager.c
@@ -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);
 }
 
 /**

[ 07/19] hpfs: better test for errors

[Greg Kroah-Hartman]

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

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

From: Mikulas Patocka <mikulas@artax.karlin.mff.cuni.cz>

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.

Signed-off-by: Mikulas Patocka <mpatocka@artax.karlin.mff.cuni.cz>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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

--- a/fs/hpfs/map.c
+++ b/fs/hpfs/map.c
@@ -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;
 	}
--- a/fs/hpfs/super.c
+++ b/fs/hpfs/super.c
@@ -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;

[ 08/19] block: do not pass disk names as format strings

[Greg Kroah-Hartman]

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

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

From: Kees Cook <keescook@chromium.org>

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

Signed-off-by: Kees Cook <keescook@chromium.org>
Cc: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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

--- a/block/genhd.c
+++ b/block/genhd.c
@@ -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);
--- a/drivers/block/nbd.c
+++ b/drivers/block/nbd.c
@@ -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);
--- a/drivers/scsi/osd/osd_uld.c
+++ b/drivers/scsi/osd/osd_uld.c
@@ -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;

[ 09/19] crypto: sanitize argument for format string

[Greg Kroah-Hartman]

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

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

From: Kees Cook <keescook@chromium.org>

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.

Signed-off-by: Kees Cook <keescook@chromium.org>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: "David S. Miller" <davem@davemloft.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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

--- a/crypto/algapi.c
+++ b/crypto/algapi.c
@@ -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);
 

[ 09/19] crypto: sanitize argument for format string

[Greg Kroah-Hartman]

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

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

From: Kees Cook <keescook@chromium.org>

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.

Signed-off-by: Kees Cook <keescook@chromium.org>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: "David S. Miller" <davem@davemloft.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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

--- a/crypto/algapi.c
+++ b/crypto/algapi.c
@@ -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);
 

[ 10/19] MAINTAINERS: add stable_kernel_rules.txt to stable maintainer information

[Greg Kroah-Hartman]

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

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

From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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.

Reported-by: David Howells <dhowells@redhat.com>
Acked-by: David Howells <dhowells@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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

--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -7667,6 +7667,7 @@ STABLE BRANCH
 M:	Greg Kroah-Hartman <gregkh@linuxfoundation.org>
 L:	stable@vger.kernel.org
 S:	Supported
+F:	Documentation/stable_kernel_rules.txt
 
 STAGING SUBSYSTEM
 M:	Greg Kroah-Hartman <gregkh@linuxfoundation.org>

[ 11/19] futex: Take hugepages into account when generating futex_key

[Greg Kroah-Hartman]

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

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

From: Zhang Yi <wetpzy@gmail.com>

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 ]

Signed-off-by: Zhang Yi <zhang.yi20@zte.com.cn>
Reviewed-by: Jiang Biao <jiang.biao2@zte.com.cn>
Tested-by: Ma Chenggong <ma.chenggong@zte.com.cn>
Reviewed-by: 'Mel Gorman' <mgorman@suse.de>
Acked-by: 'Darren Hart' <dvhart@linux.intel.com>
Cc: 'Peter Zijlstra' <peterz@infradead.org>
Link: http://lkml.kernel.org/r/000101ce71a6%24a83c5880%24f8b50980%24@com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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

--- a/include/linux/hugetlb.h
+++ b/include/linux/hugetlb.h
@@ -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 */
--- a/kernel/futex.c
+++ b/kernel/futex.c
@@ -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);
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -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;

[ 12/19] tty: Reset itty for other pty

[Greg Kroah-Hartman]

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

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

From: Peter Hurley <peter@hurleysoftware.com>

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.

Signed-off-by: Peter Hurley <peter@hurleysoftware.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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

--- a/drivers/tty/tty_io.c
+++ b/drivers/tty/tty_io.c
@@ -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)

[ 13/19] Revert "serial: 8250_pci: add support for another kind of NetMos Technology PCI 9835 Multi-I/O Controller"

[Greg Kroah-Hartman]

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

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

From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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.

Reported-by: Stefan Seyfried <stefan.seyfried@googlemail.com>
Cc: Wang YanQing <udknight@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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

--- a/drivers/tty/serial/8250/8250_pci.c
+++ b/drivers/tty/serial/8250/8250_pci.c
@@ -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 },

[ 14/19] NFSv4.1 end back channel session draining

[Greg Kroah-Hartman]

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

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

From: Andy Adamson <andros@netapp.com>

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)

Signed-off-by: Andy Adamson <andros@netapp.com>
[Trond: Changed order to start back-channel first. Minor code cleanup]
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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

--- a/fs/nfs/nfs4state.c
+++ b/fs/nfs/nfs4state.c
@@ -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
  */

[ 15/19] nfsd4: fix decoding of compounds across page boundaries

[Greg Kroah-Hartman]

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

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

From: "J. Bruce Fields" <bfields@redhat.com>

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.

Reported-by: Rick Macklem <rmacklem@uoguelph.ca>
Signed-off-by: J. Bruce Fields <bfields@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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

--- a/fs/nfsd/nfs4xdr.c
+++ b/fs/nfsd/nfs4xdr.c
@@ -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;

[ 16/19] KVM: VMX: mark unusable segment as nonpresent

[Greg Kroah-Hartman]

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

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

From: Gleb Natapov <gleb@redhat.com>

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.

Reported-by: Stefan Pietsch <stefan.pietsch@lsexperts.de>
Tested-by: Stefan Pietsch <stefan.pietsch@lsexperts.de>
Signed-off-by: Gleb Natapov <gleb@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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

--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -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)

[ 17/19] SCSI: sd: Fix parsing of temporary cache mode prefix

[Greg Kroah-Hartman]

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

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

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

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.

Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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

--- a/drivers/scsi/sd.c
+++ b/drivers/scsi/sd.c
@@ -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)

[ 18/19] cpufreq: Fix cpufreq regression after suspend/resume

[Greg Kroah-Hartman]

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

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

From: "Srivatsa S. Bhat" <srivatsa.bhat@linux.vnet.ibm.com>

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.

Reported-and-tested-by: Toralf Förster <toralf.foerster@gmx.de>
Signed-off-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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

--- a/drivers/cpufreq/cpufreq_stats.c
+++ b/drivers/cpufreq/cpufreq_stats.c
@@ -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:

[ 19/19] Revert "memcg: avoid dangling reference count in creation failure"

[Greg Kroah-Hartman]

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

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

From: Michal Hocko <mhocko@suse.cz>

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.

Signed-off-by: Michal Hocko <mhocko@suse.cz>
Signed-off-by: Li Zefan <lizefan@huawei.com>
Acked-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: Hugh Dickins <hughd@google.com>
Cc: Tejun Heo <tj@kernel.org>
Cc: Glauber Costa <glommer@openvz.org>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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

--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -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;
 }

Re: [ 00/19] 3.10.1-stable review

[Josh Boyer]

On Thu, Jul 11, 2013 at 6:01 PM, Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
> <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.

Very much agreed.

>   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.

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.

>   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?)

That's very much appreciated, Greg.  Thanks.

josh

Re: [ 00/19] 3.10.1-stable review

[Dave Jones]

On Thu, Jul 11, 2013 at 03:01:17PM -0700, Greg Kroah-Hartman wrote:
 > <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.

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

Re: [ 00/19] 3.10.1-stable review

[Greg Kroah-Hartman]

On Thu, Jul 11, 2013 at 06:29:35PM -0400, Dave Jones wrote:
> On Thu, Jul 11, 2013 at 03:01:17PM -0700, Greg Kroah-Hartman wrote:
>  > <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.
> 
> 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.

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

> 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".

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.

> 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.

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

When to push bug fixes to mainline

[Theodore Ts'o]

On Thu, Jul 11, 2013 at 03:01:17PM -0700, Greg Kroah-Hartman wrote:
> <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.

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

Re: [Ksummit-2013-discuss] When to push bug fixes to mainline

[Nicholas A. Bellinger]

On Thu, 2013-07-11 at 20:50 -0400, Theodore Ts'o wrote:
> On Thu, Jul 11, 2013 at 03:01:17PM -0700, Greg Kroah-Hartman wrote:
> > <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.
> 

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

Re: [ 00/19] 3.10.1-stable review

[Steven Rostedt]

On Thu, 2013-07-11 at 15:44 -0700, Greg Kroah-Hartman wrote:

> > 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.
> 
> 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.

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

Re: [Ksummit-2013-discuss] When to push bug fixes to mainline

[Steven Rostedt]

On Thu, 2013-07-11 at 20:50 -0400, Theodore Ts'o wrote:

> 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.

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

-- Steve

Re: [Ksummit-2013-discuss] When to push bug fixes to mainline

[John W. Linville]

On Thu, Jul 11, 2013 at 08:50:23PM -0400, Theodore Ts'o wrote:

> 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.

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
linville@tuxdriver.com			might be all we have.  Be ready.

Re: When to push bug fixes to mainline

[Li Zefan]

On 2013/7/12 8:50, Theodore Ts'o wrote:
> On Thu, Jul 11, 2013 at 03:01:17PM -0700, Greg Kroah-Hartman wrote:
>> <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.
> 
> 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.
> 

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.

Re: [Ksummit-2013-discuss] When to push bug fixes to mainline

[Greg Kroah-Hartman]

On Thu, Jul 11, 2013 at 10:57:46PM -0400, John W. Linville wrote:
> On Thu, Jul 11, 2013 at 08:50:23PM -0400, Theodore Ts'o wrote:
> 
> > 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.
> 
> 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...

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

Re: When to push bug fixes to mainline

[Willy Tarreau]

On Thu, Jul 11, 2013 at 08:50:23PM -0400, Theodore Ts'o wrote:
> On Thu, Jul 11, 2013 at 03:01:17PM -0700, Greg Kroah-Hartman wrote:
> > <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.
> 
> 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.

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

Re: [Ksummit-2013-discuss] When to push bug fixes to mainline

[James Bottomley]

On Thu, 2013-07-11 at 20:34 -0700, Greg Kroah-Hartman wrote:
> On Thu, Jul 11, 2013 at 10:57:46PM -0400, John W. Linville wrote:
> > On Thu, Jul 11, 2013 at 08:50:23PM -0400, Theodore Ts'o wrote:
> > 
> > > 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.
> > 
> > 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...
> 
> 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!!!)

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

>   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
> _______________________________________________
> Ksummit-2013-discuss mailing list
> Ksummit-2013-discuss@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/ksummit-2013-discuss

Re: [Ksummit-2013-discuss] When to push bug fixes to mainline

[Jiri Kosina]

On Thu, 11 Jul 2013, Steven Rostedt wrote:

> > 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.
> 
> Bah, I sent out a similar email about discussing this at KS too. Before
> seeing this one.

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

Re: [Ksummit-2013-discuss] When to push bug fixes to mainline

[Josh Boyer]

On Fri, Jul 12, 2013 at 5:46 AM, Jiri Kosina <jkosina@suse.cz> wrote:
> On Thu, 11 Jul 2013, Steven Rostedt wrote:
>
>> > 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.
>>
>> Bah, I sent out a similar email about discussing this at KS too. Before
>> seeing this one.
>
> 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.

Yes, I agree.

josh

Re: [ 00/19] 3.10.1-stable review

[Guenter Roeck]

On Thu, Jul 11, 2013 at 03:44:55PM -0700, Greg Kroah-Hartman wrote:
> On Thu, Jul 11, 2013 at 06:29:35PM -0400, Dave Jones wrote:
> > On Thu, Jul 11, 2013 at 03:01:17PM -0700, Greg Kroah-Hartman wrote:
> >  > <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.
> > 
> > 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.
> 
> I agree.  But it seems that I need to now start shouting at them :(
> 
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.

>From a maintainer perspective, seems to me we are stuck between a rock and a
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

Re: [ 00/19] 3.10.1-stable review

[Linus Torvalds]

On Fri, Jul 12, 2013 at 7:15 AM, Guenter Roeck <linux@roeck-us.net> wrote:
>> >
>> > 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.
>>
>> I agree.  But it seems that I need to now start shouting at them :(
>
> 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 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:

> So, yes, there are a couple of hwmon patches in your list.
>
> From a maintainer perspective, seems to me we are stuck between a rock and a
> 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.

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.

> 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.

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

Re: [ 00/19] 3.10.1-stable review

[Steven Rostedt]

On Fri, 2013-07-12 at 08:22 -0700, Linus Torvalds wrote:

> 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.
> 

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

Re: [ 00/19] 3.10.1-stable review

[Linus Torvalds]

On Fri, Jul 12, 2013 at 8:47 AM, Steven Rostedt <rostedt@goodmis.org> wrote:
>
> I tend to hold things off after -rc4 because you scare me more than Greg
> does ;-)

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

              Linus

Re: [ 00/19] 3.10.1-stable review

[Ingo Molnar]

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

> On Fri, Jul 12, 2013 at 8:47 AM, Steven Rostedt <rostedt@goodmis.org> wrote:
> >
> > I tend to hold things off after -rc4 because you scare me more than Greg
> > does ;-)
> 
> Have you guys *seen* Greg? The guy is a freakish giant. He *should*
> scare you. He might squish you without ever even noticing.

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

Re: [ 00/19] 3.10.1-stable review

[Josh Boyer]

On Fri, Jul 12, 2013 at 12:17 PM, Ingo Molnar <mingo@kernel.org> wrote:
>
> * Linus Torvalds <torvalds@linux-foundation.org> wrote:
>
>> On Fri, Jul 12, 2013 at 8:47 AM, Steven Rostedt <rostedt@goodmis.org> wrote:
>> >
>> > I tend to hold things off after -rc4 because you scare me more than Greg
>> > does ;-)
>>
>> Have you guys *seen* Greg? The guy is a freakish giant. He *should*
>> scare you. He might squish you without ever even noticing.
>
> 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!

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

Re: [ 00/19] 3.10.1-stable review

[Josh Boyer]

On Fri, Jul 12, 2013 at 12:35 PM, Josh Boyer <jwboyer@gmail.com> wrote:
> On Fri, Jul 12, 2013 at 12:17 PM, Ingo Molnar <mingo@kernel.org> wrote:
>>
>> * Linus Torvalds <torvalds@linux-foundation.org> wrote:
>>
>>> On Fri, Jul 12, 2013 at 8:47 AM, Steven Rostedt <rostedt@goodmis.org> wrote:
>>> >
>>> > I tend to hold things off after -rc4 because you scare me more than Greg
>>> > does ;-)
>>>
>>> Have you guys *seen* Greg? The guy is a freakish giant. He *should*
>>> scare you. He might squish you without ever even noticing.
>>
>> 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!
>
> 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

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

> 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.

Re: [ 00/19] 3.10.1-stable review

[Steven Rostedt]

On Fri, 2013-07-12 at 08:55 -0700, Linus Torvalds wrote:
> On Fri, Jul 12, 2013 at 8:47 AM, Steven Rostedt <rostedt@goodmis.org> wrote:
> >
> > I tend to hold things off after -rc4 because you scare me more than Greg
> > does ;-)
> 
> Have you guys *seen* Greg? The guy is a freakish giant. He *should*
> scare you. He might squish you without ever even noticing.

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

-- Steve

Re: [ 00/19] 3.10.1-stable review

[Greg Kroah-Hartman]

On Fri, Jul 12, 2013 at 12:35:26PM -0400, Josh Boyer wrote:
> On Fri, Jul 12, 2013 at 12:17 PM, Ingo Molnar <mingo@kernel.org> wrote:
> >
> > * Linus Torvalds <torvalds@linux-foundation.org> wrote:
> >
> >> On Fri, Jul 12, 2013 at 8:47 AM, Steven Rostedt <rostedt@goodmis.org> wrote:
> >> >
> >> > I tend to hold things off after -rc4 because you scare me more than Greg
> >> > does ;-)
> >>
> >> Have you guys *seen* Greg? The guy is a freakish giant. He *should*
> >> scare you. He might squish you without ever even noticing.
> >
> > 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!

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

> 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'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 :)

> 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.

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

Re: [Ksummit-2013-discuss] When to push bug fixes to mainline

[H. Peter Anvin]

On 07/11/2013 05:50 PM, Theodore Ts'o wrote:
> 
> At least at one point in the past...
> 

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

> 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.

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

Re: [ 00/19] 3.10.1-stable review

[Shuah Khan]

On 07/11/2013 04:24 PM, Greg Kroah-Hartman wrote:

>
> 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
>

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) shuah.kh@samsung.com | (970) 672-0658

Re: [Ksummit-2013-discuss] When to push bug fixes to mainline

[H. Peter Anvin]

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

Re: [Ksummit-2013-discuss] When to push bug fixes to mainline

[Greg Kroah-Hartman]

On Fri, Jul 12, 2013 at 10:20:46AM -0700, H. Peter Anvin wrote:
> 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.

After it's in Linus's tree, just send the git id of the patch to
stable@vger.kernel.org, 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

Re: [ 00/19] 3.10.1-stable review

[Greg Kroah-Hartman]

On Fri, Jul 12, 2013 at 05:20:29PM +0000, Shuah Khan wrote:
> On 07/11/2013 04:24 PM, Greg Kroah-Hartman wrote:
> 
> >
> > 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
> >
> 
> 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)

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

greg k-h

Re: [ 00/19] 3.10.1-stable review

[Guenter Roeck]

On Fri, Jul 12, 2013 at 08:22:27AM -0700, Linus Torvalds wrote:
> On Fri, Jul 12, 2013 at 7:15 AM, Guenter Roeck <linux@roeck-us.net> wrote:
> >> >
> >> > 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.
> >>
> >> I agree.  But it seems that I need to now start shouting at them :(
> >
> > 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 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:
> 
> > So, yes, there are a couple of hwmon patches in your list.
> >
> > From a maintainer perspective, seems to me we are stuck between a rock and a
> > 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.
> 
> That's f*cking sad. You know *why* it's sad?
> 
> Go read the rules for stable patches. Really.
> 
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.

> 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.
> 
> > 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.
> 
> 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.
> 
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.

> 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.
> 
Please keep in mind that not all of us were there at that time.

> 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?
> 
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.

> 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".
> 
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

Re: [ 00/19] 3.10.1-stable review

[Linus Torvalds]

On Fri, Jul 12, 2013 at 10:31 AM, Guenter Roeck <linux@roeck-us.net> wrote:
>
> 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.

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.

> 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.

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.

> Problem is with "bothers people" vs. "critical".

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

Re: [Ksummit-2013-discuss] When to push bug fixes to mainline

[Steven Rostedt]

On Fri, 2013-07-12 at 10:28 -0700, Greg Kroah-Hartman wrote:

> 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.

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

Re: [Ksummit-2013-discuss] When to push bug fixes to mainline

[Theodore Ts'o]

On Fri, Jul 12, 2013 at 10:28:36AM -0700, Greg Kroah-Hartman wrote:
> On Fri, Jul 12, 2013 at 10:20:46AM -0700, H. Peter Anvin wrote:
> > 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.
> 
> After it's in Linus's tree, just send the git id of the patch to
> stable@vger.kernel.org, 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.

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

Re: [Ksummit-2013-discuss] When to push bug fixes to mainline

[Linus Torvalds]

On Fri, Jul 12, 2013 at 10:50 AM, Steven Rostedt <rostedt@goodmis.org> wrote:
>
> 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.

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

Re: [ 00/19] 3.10.1-stable review

[Guenter Roeck]

On Fri, Jul 12, 2013 at 10:50:08AM -0700, Linus Torvalds wrote:
> On Fri, Jul 12, 2013 at 10:31 AM, Guenter Roeck <linux@roeck-us.net> wrote:
> >
> > 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.
> 
> 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.
> 
> > 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.
> 
> 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.
> 
> > Problem is with "bothers people" vs. "critical".
> 
> 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*.
> 
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.

> 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

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.

> stable rules as fairly strict. And in particular, I really don't think
> people should see "post-rc4" to be any different from "stable".
> 
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

Re: [Ksummit-2013-discuss] When to push bug fixes to mainline

[Guenter Roeck]

On Fri, Jul 12, 2013 at 01:57:18PM -0400, Theodore Ts'o wrote:
> On Fri, Jul 12, 2013 at 10:28:36AM -0700, Greg Kroah-Hartman wrote:
> > On Fri, Jul 12, 2013 at 10:20:46AM -0700, H. Peter Anvin wrote:
> > > 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.
> > 
> > After it's in Linus's tree, just send the git id of the patch to
> > stable@vger.kernel.org, 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.
> 
> 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....
> 
That is what I do as well, with an added explicit reference to the upstream
git id in the commit log.

Guenter

Re: [Ksummit-2013-discuss] When to push bug fixes to mainline

[Steven Rostedt]

On Fri, 2013-07-12 at 10:59 -0700, Linus Torvalds wrote:
> On Fri, Jul 12, 2013 at 10:50 AM, Steven Rostedt <rostedt@goodmis.org> wrote:
> >
> > 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.
> 
> 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.
> 

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

Re: [Ksummit-2013-discuss] When to push bug fixes to mainline

[H. Peter Anvin]

On 07/12/2013 10:57 AM, Theodore Ts'o wrote:
> On Fri, Jul 12, 2013 at 10:28:36AM -0700, Greg Kroah-Hartman wrote:
>> On Fri, Jul 12, 2013 at 10:20:46AM -0700, H. Peter Anvin wrote:
>>> 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.
>>
>> After it's in Linus's tree, just send the git id of the patch to
>> stable@vger.kernel.org, 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.
> 
> 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....
> 

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

Re: [Ksummit-2013-discuss] When to push bug fixes to mainline

[H. Peter Anvin]

On 07/12/2013 11:16 AM, H. Peter Anvin wrote:
> 
> 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.
> 

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

Re: [ 00/19] 3.10.1-stable review

[Theodore Ts'o]

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

Re: [Ksummit-2013-discuss] When to push bug fixes to mainline

[Linus Torvalds]

On Fri, Jul 12, 2013 at 11:28 AM, H. Peter Anvin <hpa@zytor.com> wrote:
>
> 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.

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

Re: [ 00/19] 3.10.1-stable review

[Steven Rostedt]

On Fri, 2013-07-12 at 15:35 -0400, Theodore Ts'o wrote:

> 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.

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

Re: [ 00/19] 3.10.1-stable review

[Willy Tarreau]

On Fri, Jul 12, 2013 at 10:50:08AM -0700, Linus Torvalds wrote:
> 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.

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

Re: [Ksummit-2013-discuss] When to push bug fixes to mainline

[Steven Rostedt]

On Fri, 2013-07-12 at 12:44 -0700, Linus Torvalds wrote:

> 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.

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

Re: [ 00/19] 3.10.1-stable review

[Willy Tarreau]

On Fri, Jul 12, 2013 at 03:49:11PM -0400, Steven Rostedt wrote:
> On Fri, 2013-07-12 at 15:35 -0400, Theodore Ts'o wrote:
> 
> > 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.
> 
> 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.

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

Re: [Ksummit-2013-discuss] When to push bug fixes to mainline

[Shuah Khan]

On Fri, Jul 12, 2013 at 1:53 PM, Steven Rostedt <rostedt@goodmis.org> wrote:
> On Fri, 2013-07-12 at 12:44 -0700, Linus Torvalds wrote:
>
>> 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.
>
> 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

Re: [ 00/19] 3.10.1-stable review

[Dave Jones]

On Fri, Jul 12, 2013 at 03:49:11PM -0400, Steven Rostedt wrote:
 > On Fri, 2013-07-12 at 15:35 -0400, Theodore Ts'o wrote:
 > 
 > > 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.
 > 
 > 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.

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

Re: [ 00/19] 3.10.1-stable review

[Steven Rostedt]

On Fri, 2013-07-12 at 16:19 -0400, Dave Jones wrote:

> 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.

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

Re: [ 00/19] 3.10.1-stable review

[Steven Rostedt]

On Fri, 2013-07-12 at 16:28 -0400, Steven Rostedt wrote:
> On Fri, 2013-07-12 at 16:19 -0400, Dave Jones wrote:

> 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.

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

Re: [Ksummit-2013-discuss] When to push bug fixes to mainline

[Greg Kroah-Hartman]

On Fri, Jul 12, 2013 at 03:53:17PM -0400, Steven Rostedt wrote:
> On Fri, 2013-07-12 at 12:44 -0700, Linus Torvalds wrote:
> 
> > 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.
> 
> 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.

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

Re: [Ksummit-2013-discuss] When to push bug fixes to mainline

[Steven Rostedt]

On Fri, 2013-07-12 at 13:33 -0700, Greg Kroah-Hartman wrote:

> 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.

Or use git notes locally ;-)

-- Steve

Re: [ 00/19] 3.10.1-stable review

[Theodore Ts'o]

On Fri, Jul 12, 2013 at 09:50:51PM +0200, Willy Tarreau wrote:
> 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.

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

I will likely start adopting this for the ext4 tree.

					- Ted

Re: [ 00/19] 3.10.1-stable review

[Guenter Roeck]

On Fri, Jul 12, 2013 at 04:47:44PM -0400, Theodore Ts'o wrote:
> On Fri, Jul 12, 2013 at 09:50:51PM +0200, Willy Tarreau wrote:
> > 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.
> 
> This is a really good idea.   /me likes....
> 
I agree, that would be very helpful.

Guenter

Re: [ 00/19] 3.10.1-stable review

[Justin M. Forbes]

On Fri, Jul 12, 2013 at 04:28:20PM -0400, Steven Rostedt wrote:
> 
> 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.
> 
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

Re: [Ksummit-2013-discuss] When to push bug fixes to mainline

[H. Peter Anvin]

On 07/12/2013 12:53 PM, Steven Rostedt wrote:
> On Fri, 2013-07-12 at 12:44 -0700, Linus Torvalds wrote:
> 
>> 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.
> 
> 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.
> 

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

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

	-hpa

Re: [Ksummit-2013-discuss] When to push bug fixes to mainline

[H. Peter Anvin]

On 07/12/2013 01:33 PM, Greg Kroah-Hartman wrote:
> 
> 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.
> 

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

Re: [Ksummit-2013-discuss] When to push bug fixes to mainline

[Rafael J. Wysocki]

On Thursday, July 11, 2013 08:34:30 PM Greg Kroah-Hartman wrote:
> On Thu, Jul 11, 2013 at 10:57:46PM -0400, John W. Linville wrote:
> > On Thu, Jul 11, 2013 at 08:50:23PM -0400, Theodore Ts'o wrote:
> > 
> > > 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.
> > 
> > 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...
> 
> 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.

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).

> 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...

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.

Re: [ 00/19] 3.10.1-stable review

[Jochen Striepe]

	Hello,

On Fri, Jul 12, 2013 at 04:28:20PM -0400, Steven Rostedt wrote:
> 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.

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.

Re: [Ksummit-2013-discuss] When to push bug fixes to mainline

[Greg Kroah-Hartman]

On Sat, Jul 13, 2013 at 02:24:07AM +0200, Rafael J. Wysocki wrote:
> On Thursday, July 11, 2013 08:34:30 PM Greg Kroah-Hartman wrote:
> > On Thu, Jul 11, 2013 at 10:57:46PM -0400, John W. Linville wrote:
> > > On Thu, Jul 11, 2013 at 08:50:23PM -0400, Theodore Ts'o wrote:
> > > 
> > > > 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.
> > > 
> > > 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...
> > 
> > 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.
> 
> 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?

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

> 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).

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

> > 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...
> 
> 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.

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

greg k-h

Re: [ 00/19] 3.10.1-stable review

[Satoru Takeuchi]

At Thu, 11 Jul 2013 15:01:17 -0700,
Greg Kroah-Hartman wrote:
> 
> <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.
> 

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

> 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 <gregkh@linuxfoundation.org>
>     Linux 3.10.1-rc1
> 
> Michal Hocko <mhocko@suse.cz>
>     Revert "memcg: avoid dangling reference count in creation failure"
> 
> Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
>     cpufreq: Fix cpufreq regression after suspend/resume
> 
> Ben Hutchings <ben@decadent.org.uk>
>     SCSI: sd: Fix parsing of 'temporary ' cache mode prefix
> 
> Gleb Natapov <gleb@redhat.com>
>     KVM: VMX: mark unusable segment as nonpresent
> 
> J. Bruce Fields <bfields@redhat.com>
>     nfsd4: fix decoding of compounds across page boundaries
> 
> Andy Adamson <andros@netapp.com>
>     NFSv4.1 end back channel session draining
> 
> Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>     Revert "serial: 8250_pci: add support for another kind of NetMos Technology PCI 9835 Multi-I/O Controller"
> 
> Peter Hurley <peter@hurleysoftware.com>
>     tty: Reset itty for other pty
> 
> Zhang Yi <wetpzy@gmail.com>
>     futex: Take hugepages into account when generating futex_key
> 
> Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>     MAINTAINERS: add stable_kernel_rules.txt to stable maintainer information
> 
> Kees Cook <keescook@chromium.org>
>     crypto: sanitize argument for format string
> 
> Kees Cook <keescook@chromium.org>
>     block: do not pass disk names as format strings
> 
> Mikulas Patocka <mikulas@artax.karlin.mff.cuni.cz>
>     hpfs: better test for errors
> 
> Kees Cook <keescook@chromium.org>
>     charger-manager: Ensure event is not used as format string
> 
> Rusty Russell <rusty@rustcorp.com.au>
>     module: do percpu allocation after uniqueness check. No, really!
> 
> Jonathan Salwan <jonathan.salwan@gmail.com>
>     drivers/cdrom/cdrom.c: use kzalloc() for failing hardware
> 
> Josh Durgin <josh.durgin@inktank.com>
>     libceph: fix invalid unsigned->signed conversion for timespec encoding
> 
> majianpeng <majianpeng@gmail.com>
>     ceph: fix sleeping function called from invalid context.
> 
> Tyler Hicks <tyhicks@canonical.com>
>     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(-)
> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe stable" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [ 00/19] 3.10.1-stable review

[Greg Kroah-Hartman]

On Fri, Jul 12, 2013 at 09:50:51PM +0200, Willy Tarreau wrote:
> On Fri, Jul 12, 2013 at 10:50:08AM -0700, Linus Torvalds wrote:
> > 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.
> 
> 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.

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

Re: [ 00/19] 3.10.1-stable review

[Willy Tarreau]

On Fri, Jul 12, 2013 at 11:22:23PM -0700, Greg Kroah-Hartman wrote:
> > 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.
> 
> 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.

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.

> 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.

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

Re: [ 00/19] 3.10.1-stable review

[Guenter Roeck]

On Fri, Jul 12, 2013 at 11:22:23PM -0700, Greg Kroah-Hartman wrote:
> On Fri, Jul 12, 2013 at 09:50:51PM +0200, Willy Tarreau wrote:
> > On Fri, Jul 12, 2013 at 10:50:08AM -0700, Linus Torvalds wrote:
> > > 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.
> > 
> > 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.
> 
> 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?
> 
It appears it may not be good enough for some, otherwise we would not have
this discussion.

> And if something "fixes" an issue, then I want it in stable, just like
> Linus wants that in his tree.
> 
Except if it is not critical, for a given definition of the word.

> 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.
> 
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

Re: [Ksummit-2013-discuss] When to push bug fixes to mainline

[Ingo Molnar]

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

> On Fri, Jul 12, 2013 at 11:28 AM, H. Peter Anvin <hpa@zytor.com> wrote:
> >
> > 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.
> 
> I really don't want to use git notes for anything that actually gets 
> distributed.

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

Re: [ 00/19] 3.10.1-stable review

[Greg Kroah-Hartman]

On Sat, Jul 13, 2013 at 08:36:07AM +0200, Willy Tarreau wrote:
> On Fri, Jul 12, 2013 at 11:22:23PM -0700, Greg Kroah-Hartman wrote:
> > > 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.
> > 
> > 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.
> 
> 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).

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

Re: [ 00/19] 3.10.1-stable review

[Greg Kroah-Hartman]

On Fri, Jul 12, 2013 at 11:43:17PM -0700, Guenter Roeck wrote:
> > And if something "fixes" an issue, then I want it in stable, just like
> > Linus wants that in his tree.
> > 
> Except if it is not critical, for a given definition of the word.

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

> > 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.
> > 
> 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".

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

Re: [ 00/19] 3.10.1-stable review

[Willy Tarreau]

On Fri, Jul 12, 2013 at 11:48:01PM -0700, Greg Kroah-Hartman wrote:
> > > And if something "fixes" an issue, then I want it in stable, just like
> > > Linus wants that in his tree.
> > 
> > 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).
> 
> 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.

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.

> 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.

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.

> 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).

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.

> 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.

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".

> 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.

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

Re: [ 00/19] 3.10.1-stable review

[Steven Rostedt]

On Sat, 2013-07-13 at 02:47 +0200, Jochen Striepe wrote:
> 	Hello,
> 
> On Fri, Jul 12, 2013 at 04:28:20PM -0400, Steven Rostedt wrote:
> > 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.
> 
> 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.

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

Re: [ 00/19] 3.10.1-stable review

[Theodore Ts'o]

On Fri, Jul 12, 2013 at 11:48:01PM -0700, Greg Kroah-Hartman wrote:
> > 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).
> 
> No, I've never said that.

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.                                             ^^^^^^^^^^^^^^^^^^^
   ^^^^^^^^

> 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?

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).

> 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.

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 stable@vger.kernel.org;
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 stable@vger.kernel.org.  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....

Re: [Ksummit-2013-discuss] When to push bug fixes to mainline

[Rafael J. Wysocki]

On Friday, July 12, 2013 06:32:11 PM Greg Kroah-Hartman wrote:
> On Sat, Jul 13, 2013 at 02:24:07AM +0200, Rafael J. Wysocki wrote:
> > On Thursday, July 11, 2013 08:34:30 PM Greg Kroah-Hartman wrote:
> > > On Thu, Jul 11, 2013 at 10:57:46PM -0400, John W. Linville wrote:
> > > > On Thu, Jul 11, 2013 at 08:50:23PM -0400, Theodore Ts'o wrote:
> > > > 
> > > > > 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.
> > > > 
> > > > 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...
> > > 
> > > 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.
> > 
> > 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?
> 
> Because I'm an easy big target and people are lazy.

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.

> > 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).
> 
> I know that, you know that, but managers who see tons of kernel patches
> just get scared :)

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?

> > > 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...
> > 
> > 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.
> 
> There was no real breakage, that is why I rejected it.

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.

Re: [ 00/19] 3.10.1-stable review

[Dave Jones]

On Sat, Jul 13, 2013 at 07:11:29AM -0400, Steven Rostedt wrote:

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

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

Re: [ 00/19] 3.10.1-stable review

[Steven Rostedt]

On Sat, 2013-07-13 at 11:10 -0400, Dave Jones wrote:
> On Sat, Jul 13, 2013 at 07:11:29AM -0400, Steven Rostedt wrote:
> 
>  > > Users expect vanilla .0 releases usable as production systems, to
>  > > be updated (meaning, no new features, just stabilizing) with the
>  > > corresponding -stable series.
>  > 
>  > 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.
> 
> 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?)

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

Re: [Ksummit-2013-discuss] When to push bug fixes to mainline

[Geert Uytterhoeven]

On Fri, Jul 12, 2013 at 8:14 PM, Steven Rostedt <rostedt@goodmis.org> wrote:
> On Fri, 2013-07-12 at 10:59 -0700, Linus Torvalds wrote:
>> On Fri, Jul 12, 2013 at 10:50 AM, Steven Rostedt <rostedt@goodmis.org> wrote:
>> >
>> > 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.
>>
>> 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.
>>
>
> 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.

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 -- geert@linux-m68k.org

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

Re: [ 00/19] 3.10.1-stable review

[Greg Kroah-Hartman]

On Sat, Jul 13, 2013 at 07:42:11AM -0400, Theodore Ts'o wrote:
> On Fri, Jul 12, 2013 at 11:48:01PM -0700, Greg Kroah-Hartman wrote:
> > > 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).
> > 
> > No, I've never said that.
> 
> 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.                                             ^^^^^^^^^^^^^^^^^^^
>    ^^^^^^^^

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...

Re: [ 00/19] 3.10.1-stable review

[Theodore Ts'o]

On Sat, Jul 13, 2013 at 11:27:17AM -0700, Greg Kroah-Hartman wrote:
> 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.

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 stable@vger.kernel.org a week or two after Linus has
released the 3.y.0 kernel.

Regards,

					- Ted

Re: [ 00/19] 3.10.1-stable review

[Greg Kroah-Hartman]

On Sat, Jul 13, 2013 at 10:22:19PM -0400, Theodore Ts'o wrote:
> On Sat, Jul 13, 2013 at 11:27:17AM -0700, Greg Kroah-Hartman wrote:
> > 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.
> 
> 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.

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

Re: [ 00/19] 3.10.1-stable review

[Guenter Roeck]

On Sat, Jul 13, 2013 at 08:51:28PM -0700, Greg Kroah-Hartman wrote:
> On Sat, Jul 13, 2013 at 10:22:19PM -0400, Theodore Ts'o wrote:
> > On Sat, Jul 13, 2013 at 11:27:17AM -0700, Greg Kroah-Hartman wrote:
> > > 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.
> > 
> > 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.
> 
> You are confusing the words "real" and "critical" perhaps.  I, and other

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

> 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
> 

Re: [ 00/19] 3.10.1-stable review

[Geert Uytterhoeven]

On Sun, Jul 14, 2013 at 7:24 AM, Guenter Roeck <linux@roeck-us.net> wrote:
>> You are confusing the words "real" and "critical" perhaps.  I, and other
>
> 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".

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 -- geert@linux-m68k.org

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

Re: [ 00/19] 3.10.1-stable review

[Benjamin Herrenschmidt]

On Fri, 2013-07-12 at 10:05 -0700, Greg Kroah-Hartman wrote:
> 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.)

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.

> 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?

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.

> 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.

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).

> Although really, who cares about powerpc anymore :)

That was unfair :-)

Cheers,
Ben.

Re: [ 00/19] 3.10.1-stable review

[Benjamin Herrenschmidt]

On Thu, 2013-07-11 at 18:14 -0400, Josh Boyer wrote:
>    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.  

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.

Re: [ 00/19] 3.10.1-stable review

[Benjamin Herrenschmidt]

On Thu, 2013-07-11 at 15:44 -0700, Greg Kroah-Hartman wrote:
> > 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".
> 
> 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.

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.

Re: [ 00/19] 3.10.1-stable review

[Benjamin Herrenschmidt]

On Thu, 2013-07-11 at 15:01 -0700, Greg Kroah-Hartman wrote:
> s 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.

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.

Re: [ 00/19] 3.10.1-stable review

[Benjamin Herrenschmidt]

On Fri, 2013-07-12 at 10:50 -0700, Linus Torvalds wrote:
> 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.

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.

Re: [ 00/19] 3.10.1-stable review

[Linus Torvalds]

On Sun, Jul 14, 2013 at 4:52 PM, Benjamin Herrenschmidt
<benh@kernel.crashing.org> wrote:
>
> 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 ?

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

Re: [ 00/19] 3.10.1-stable review

[Benjamin Herrenschmidt]

On Sun, 2013-07-14 at 18:40 -0700, Linus Torvalds wrote:
> 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.

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.

Re: [ 00/19] 3.10.1-stable review

[Li Zefan]

> 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,

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.

> 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.

Re: When to push bug fixes to mainline

[Rob Landley]

On 07/11/2013 10:25:51 PM, Li Zefan wrote:
> On 2013/7/12 8:50, Theodore Ts'o wrote:
> > On Thu, Jul 11, 2013 at 03:01:17PM -0700, Greg Kroah-Hartman wrote:
> >> <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.
> >
> > 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.
> >
> 
> 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

Re: [ 00/19] 3.10.1-stable review

[Willy Tarreau]

On Mon, Jul 15, 2013 at 12:12:04PM +0800, Li Zefan wrote:
> > 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,
> 
> 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

Re: When to push bug fixes to mainline

[David Lang]

On Fri, 12 Jul 2013, Willy Tarreau wrote:

> 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.

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

Re: [Ksummit-2013-discuss] When to push bug fixes to mainline

[Takashi Iwai]

At Tue, 16 Jul 2013 00:19:16 -0700 (PDT),
David Lang wrote:
> 
> On Fri, 12 Jul 2013, Willy Tarreau wrote:
> 
> > 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.
> 
> 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.

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

Re: [Ksummit-2013-discuss] When to push bug fixes to mainline

[David Lang]

On Tue, 16 Jul 2013, Takashi Iwai wrote:

> At Tue, 16 Jul 2013 00:19:16 -0700 (PDT),
> David Lang wrote:
>>
>> On Fri, 12 Jul 2013, Willy Tarreau wrote:
>>
>>> 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.
>>
>> 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.
>
> 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?)

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

Re: [Ksummit-2013-discuss] When to push bug fixes to mainline

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 405 bytes --]

On Tue, Jul 16, 2013 at 06:40:39PM +0200, Takashi Iwai wrote:

> 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?)

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.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

RE: [Ksummit-2013-discuss] When to push bug fixes to mainline

[Luck, Tony]

>> 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?)
>
> 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

RE: [Ksummit-2013-discuss] When to push bug fixes to mainline

[Luck, Tony]

>> 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?)
>
> 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

Re: [Ksummit-2013-discuss] When to push bug fixes to mainline

[Linus Torvalds]

On Tue, Jul 16, 2013 at 10:58 AM, Luck, Tony <tony.luck@intel.com> wrote:
>
> Linux testing is (realistically) done by inflicting changes on gradually wider
> sets of end users.

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

Re: [Ksummit-2013-discuss] When to push bug fixes to mainline

[Linus Torvalds]

On Tue, Jul 16, 2013 at 10:58 AM, Luck, Tony <tony.luck@intel.com> wrote:
>
> Linux testing is (realistically) done by inflicting changes on gradually wider
> sets of end users.

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

Re: [Ksummit-2013-discuss] When to push bug fixes to mainline

[Willy Tarreau]

Hi Takashi,

On Tue, Jul 16, 2013 at 06:40:39PM +0200, Takashi Iwai wrote:
> 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?)

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

Re: [Ksummit-2013-discuss] When to push bug fixes to mainline

[H. Peter Anvin]

On 07/16/2013 12:19 AM, David Lang wrote:
> On Fri, 12 Jul 2013, Willy Tarreau wrote:
> 
>> 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.
> 
> 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.
> 

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

Re: [Ksummit-2013-discuss] When to push bug fixes to mainline

[Steven Rostedt]

On Tue, 2013-07-16 at 11:29 -0700, Linus Torvalds wrote:

> 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.

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

Re: [Ksummit-2013-discuss] When to push bug fixes to mainline

[Steven Rostedt]

On Tue, 2013-07-16 at 11:29 -0700, Linus Torvalds wrote:

> 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.

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

Re: [Ksummit-2013-discuss] When to push bug fixes to mainline

[Willy Tarreau]

On Tue, Jul 16, 2013 at 11:29:15AM -0700, Linus Torvalds wrote:
> 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).

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 !

> 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.

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

Re: [Ksummit-2013-discuss] When to push bug fixes to mainline

[Willy Tarreau]

On Tue, Jul 16, 2013 at 11:29:15AM -0700, Linus Torvalds wrote:
> 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).

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 !

> 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.

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

Re: [Ksummit-2013-discuss] When to push bug fixes to mainline

[Greg Kroah-Hartman]

On Tue, Jul 16, 2013 at 02:41:24PM -0400, Steven Rostedt wrote:
> On Tue, 2013-07-16 at 11:29 -0700, Linus Torvalds wrote:
> 
> > 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.
> 
> 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.

People mark stable patches that way already today with a:
	Cc: stable <stable@vger.kernel.org> # 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

Re: [Ksummit-2013-discuss] When to push bug fixes to mainline

[Greg Kroah-Hartman]

On Tue, Jul 16, 2013 at 02:41:24PM -0400, Steven Rostedt wrote:
> On Tue, 2013-07-16 at 11:29 -0700, Linus Torvalds wrote:
> 
> > 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.
> 
> 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.

People mark stable patches that way already today with a:
	Cc: stable <stable@vger.kernel.org> # 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

Re: [Ksummit-2013-discuss] When to push bug fixes to mainline

[Takashi Iwai]

At Tue, 16 Jul 2013 09:42:34 -0700 (PDT),
David Lang wrote:
> 
> On Tue, 16 Jul 2013, Takashi Iwai wrote:
> 
> > At Tue, 16 Jul 2013 00:19:16 -0700 (PDT),
> > David Lang wrote:
> >>
> >> On Fri, 12 Jul 2013, Willy Tarreau wrote:
> >>
> >>> 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.
> >>
> >> 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.
> >
> > 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?)
> 
> I am not saying that no regressions will happen (for exactly the reasons that 
> you are giving).

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

> 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.

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

Re: [Ksummit-2013-discuss] When to push bug fixes to mainline

[Steven Rostedt]

On Tue, 2013-07-16 at 12:11 -0700, Greg Kroah-Hartman wrote:

> People mark stable patches that way already today with a:
> 	Cc: stable <stable@vger.kernel.org> # 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.

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

Re: [Ksummit-2013-discuss] When to push bug fixes to mainline

[Steven Rostedt]

On Tue, 2013-07-16 at 12:11 -0700, Greg Kroah-Hartman wrote:

> People mark stable patches that way already today with a:
> 	Cc: stable <stable@vger.kernel.org> # 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.

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

Re: [Ksummit-2013-discuss] When to push bug fixes to mainline

[Willy Tarreau]

On Tue, Jul 16, 2013 at 03:43:09PM -0400, Steven Rostedt wrote:
> On Tue, 2013-07-16 at 12:11 -0700, Greg Kroah-Hartman wrote:
> 
> > People mark stable patches that way already today with a:
> > 	Cc: stable <stable@vger.kernel.org> # 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.
> 
> 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.

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

Re: [Ksummit-2013-discuss] When to push bug fixes to mainline

[Willy Tarreau]

On Tue, Jul 16, 2013 at 03:43:09PM -0400, Steven Rostedt wrote:
> On Tue, 2013-07-16 at 12:11 -0700, Greg Kroah-Hartman wrote:
> 
> > People mark stable patches that way already today with a:
> > 	Cc: stable <stable@vger.kernel.org> # 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.
> 
> 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.

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

Re: [Ksummit-2013-discuss] When to push bug fixes to mainline

[David Lang]

On Tue, 16 Jul 2013, H. Peter Anvin wrote:

> On 07/16/2013 12:19 AM, David Lang wrote:
>> On Fri, 12 Jul 2013, Willy Tarreau wrote:
>>
>>> 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.
>>
>> 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.
>>
>
> 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.

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

Re: [Ksummit-2013-discuss] When to push bug fixes to mainline

[Ben Hutchings]

[-- Attachment #1: Type: text/plain, Size: 1689 bytes --]

On Tue, 2013-07-16 at 22:10 +0200, Willy Tarreau wrote:
> On Tue, Jul 16, 2013 at 03:43:09PM -0400, Steven Rostedt wrote:
> > On Tue, 2013-07-16 at 12:11 -0700, Greg Kroah-Hartman wrote:
> > 
> > > People mark stable patches that way already today with a:
> > > 	Cc: stable <stable@vger.kernel.org> # 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.
> > 
> > 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.
> 
> 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 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 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.

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.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

Re: [Ksummit-2013-discuss] When to push bug fixes to mainline

[Ben Hutchings]

[-- Attachment #1: Type: text/plain, Size: 1689 bytes --]

On Tue, 2013-07-16 at 22:10 +0200, Willy Tarreau wrote:
> On Tue, Jul 16, 2013 at 03:43:09PM -0400, Steven Rostedt wrote:
> > On Tue, 2013-07-16 at 12:11 -0700, Greg Kroah-Hartman wrote:
> > 
> > > People mark stable patches that way already today with a:
> > > 	Cc: stable <stable@vger.kernel.org> # 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.
> > 
> > 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.
> 
> 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 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 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.

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.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

Re: [Ksummit-2013-discuss] When to push bug fixes to mainline

[Li Zefan]

On 2013/7/17 4:10, Willy Tarreau wrote:
> On Tue, Jul 16, 2013 at 03:43:09PM -0400, Steven Rostedt wrote:
>> On Tue, 2013-07-16 at 12:11 -0700, Greg Kroah-Hartman wrote:
>>
>>> People mark stable patches that way already today with a:
>>> 	Cc: stable <stable@vger.kernel.org> # 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.

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

>>
>> 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.
> 
> 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.
> 

I like the idea of postpone stable patches by default.

Re: [Ksummit-2013-discuss] When to push bug fixes to mainline

[Li Zefan]

On 2013/7/17 4:10, Willy Tarreau wrote:
> On Tue, Jul 16, 2013 at 03:43:09PM -0400, Steven Rostedt wrote:
>> On Tue, 2013-07-16 at 12:11 -0700, Greg Kroah-Hartman wrote:
>>
>>> People mark stable patches that way already today with a:
>>> 	Cc: stable <stable@vger.kernel.org> # 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.

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

>>
>> 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.
> 
> 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.
> 

I like the idea of postpone stable patches by default.

Re: [Ksummit-2013-discuss] When to push bug fixes to mainline

[Ingo Molnar]

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

> [...]
> 
> 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.

The way I typically mark those kinds of fixes is that I don't add a 
stable@vger.kernel.org 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

Re: [Ksummit-2013-discuss] When to push bug fixes to mainline

[Ingo Molnar]

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

> [...]
> 
> 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.

The way I typically mark those kinds of fixes is that I don't add a 
stable@vger.kernel.org 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