All of lore.kernel.org
 help / color / mirror / Atom feed
* [ 00/19] 3.10.1-stable review
@ 2013-07-11 22:01 Greg Kroah-Hartman
  2013-07-11 22:01 ` [ 01/19] libceph: Fix NULL pointer dereference in auth client code Greg Kroah-Hartman
                   ` (24 more replies)
  0 siblings, 25 replies; 213+ messages in thread
From: Greg Kroah-Hartman @ 2013-07-11 22:01 UTC (permalink / raw)
  To: linux-kernel; +Cc: Greg Kroah-Hartman, torvalds, akpm, stable

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



^ permalink raw reply	[flat|nested] 213+ messages in thread

* [ 01/19] libceph: Fix NULL pointer dereference in auth client code
  2013-07-11 22:01 [ 00/19] 3.10.1-stable review Greg Kroah-Hartman
@ 2013-07-11 22:01 ` Greg Kroah-Hartman
  2013-07-11 22:01 ` [ 02/19] ceph: fix sleeping function called from invalid context Greg Kroah-Hartman
                   ` (23 subsequent siblings)
  24 siblings, 0 replies; 213+ messages in thread
From: Greg Kroah-Hartman @ 2013-07-11 22:01 UTC (permalink / raw)
  To: linux-kernel
  Cc: Greg Kroah-Hartman, stable, Tyler Hicks, Chanam Park,
	Seth Arnold, Sage Weil

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,



^ permalink raw reply	[flat|nested] 213+ messages in thread

* [ 02/19] ceph: fix sleeping function called from invalid context.
  2013-07-11 22:01 [ 00/19] 3.10.1-stable review Greg Kroah-Hartman
  2013-07-11 22:01 ` [ 01/19] libceph: Fix NULL pointer dereference in auth client code Greg Kroah-Hartman
@ 2013-07-11 22:01 ` Greg Kroah-Hartman
  2013-07-11 22:01 ` [ 03/19] libceph: fix invalid unsigned->signed conversion for timespec encoding Greg Kroah-Hartman
                   ` (22 subsequent siblings)
  24 siblings, 0 replies; 213+ messages in thread
From: Greg Kroah-Hartman @ 2013-07-11 22:01 UTC (permalink / raw)
  To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Jianpeng Ma, Sage Weil

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;



^ permalink raw reply	[flat|nested] 213+ messages in thread

* [ 03/19] libceph: fix invalid unsigned->signed conversion for timespec encoding
  2013-07-11 22:01 [ 00/19] 3.10.1-stable review Greg Kroah-Hartman
  2013-07-11 22:01 ` [ 01/19] libceph: Fix NULL pointer dereference in auth client code Greg Kroah-Hartman
  2013-07-11 22:01 ` [ 02/19] ceph: fix sleeping function called from invalid context Greg Kroah-Hartman
@ 2013-07-11 22:01 ` Greg Kroah-Hartman
  2013-07-11 22:01 ` [ 04/19] drivers/cdrom/cdrom.c: use kzalloc() for failing hardware Greg Kroah-Hartman
                   ` (21 subsequent siblings)
  24 siblings, 0 replies; 213+ messages in thread
From: Greg Kroah-Hartman @ 2013-07-11 22:01 UTC (permalink / raw)
  To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Josh Durgin, Sage Weil

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);
 }



^ permalink raw reply	[flat|nested] 213+ messages in thread

* [ 04/19] drivers/cdrom/cdrom.c: use kzalloc() for failing hardware
  2013-07-11 22:01 [ 00/19] 3.10.1-stable review Greg Kroah-Hartman
                   ` (2 preceding siblings ...)
  2013-07-11 22:01 ` [ 03/19] libceph: fix invalid unsigned->signed conversion for timespec encoding Greg Kroah-Hartman
@ 2013-07-11 22:01 ` Greg Kroah-Hartman
  2013-07-11 22:01 ` [ 05/19] module: do percpu allocation after uniqueness check. No, really! Greg Kroah-Hartman
                   ` (20 subsequent siblings)
  24 siblings, 0 replies; 213+ messages in thread
From: Greg Kroah-Hartman @ 2013-07-11 22:01 UTC (permalink / raw)
  To: linux-kernel
  Cc: Greg Kroah-Hartman, stable, Dan Carpenter, Jens Axboe,
	Andrew Morton, Linus Torvalds, Jonathan Salwan, Luis Henriques

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;
 



^ permalink raw reply	[flat|nested] 213+ messages in thread

* [ 05/19] module: do percpu allocation after uniqueness check.  No, really!
  2013-07-11 22:01 [ 00/19] 3.10.1-stable review Greg Kroah-Hartman
                   ` (3 preceding siblings ...)
  2013-07-11 22:01 ` [ 04/19] drivers/cdrom/cdrom.c: use kzalloc() for failing hardware Greg Kroah-Hartman
@ 2013-07-11 22:01 ` Greg Kroah-Hartman
  2013-07-11 22:01 ` [ 06/19] charger-manager: Ensure event is not used as format string Greg Kroah-Hartman
                   ` (19 subsequent siblings)
  24 siblings, 0 replies; 213+ messages in thread
From: Greg Kroah-Hartman @ 2013-07-11 22:01 UTC (permalink / raw)
  To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Rusty Russell, Jim Hull

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)



^ permalink raw reply	[flat|nested] 213+ messages in thread

* [ 06/19] charger-manager: Ensure event is not used as format string
  2013-07-11 22:01 [ 00/19] 3.10.1-stable review Greg Kroah-Hartman
                   ` (4 preceding siblings ...)
  2013-07-11 22:01 ` [ 05/19] module: do percpu allocation after uniqueness check. No, really! Greg Kroah-Hartman
@ 2013-07-11 22:01 ` Greg Kroah-Hartman
  2013-07-11 22:01 ` [ 07/19] hpfs: better test for errors Greg Kroah-Hartman
                   ` (18 subsequent siblings)
  24 siblings, 0 replies; 213+ messages in thread
From: Greg Kroah-Hartman @ 2013-07-11 22:01 UTC (permalink / raw)
  To: linux-kernel
  Cc: Greg Kroah-Hartman, stable, Kees Cook, Anton Vorontsov,
	David Woodhouse, Anton Vorontsov

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);
 }
 
 /**



^ permalink raw reply	[flat|nested] 213+ messages in thread

* [ 07/19] hpfs: better test for errors
  2013-07-11 22:01 [ 00/19] 3.10.1-stable review Greg Kroah-Hartman
                   ` (5 preceding siblings ...)
  2013-07-11 22:01 ` [ 06/19] charger-manager: Ensure event is not used as format string Greg Kroah-Hartman
@ 2013-07-11 22:01 ` Greg Kroah-Hartman
  2013-07-11 22:01 ` [ 08/19] block: do not pass disk names as format strings Greg Kroah-Hartman
                   ` (17 subsequent siblings)
  24 siblings, 0 replies; 213+ messages in thread
From: Greg Kroah-Hartman @ 2013-07-11 22:01 UTC (permalink / raw)
  To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Mikulas Patocka, Linus Torvalds

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;



^ permalink raw reply	[flat|nested] 213+ messages in thread

* [ 08/19] block: do not pass disk names as format strings
  2013-07-11 22:01 [ 00/19] 3.10.1-stable review Greg Kroah-Hartman
                   ` (6 preceding siblings ...)
  2013-07-11 22:01 ` [ 07/19] hpfs: better test for errors Greg Kroah-Hartman
@ 2013-07-11 22:01 ` Greg Kroah-Hartman
  2013-07-11 22:01   ` Greg Kroah-Hartman
                   ` (16 subsequent siblings)
  24 siblings, 0 replies; 213+ messages in thread
From: Greg Kroah-Hartman @ 2013-07-11 22:01 UTC (permalink / raw)
  To: linux-kernel
  Cc: Greg Kroah-Hartman, stable, Kees Cook, Jens Axboe, Andrew Morton,
	Linus Torvalds

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;



^ permalink raw reply	[flat|nested] 213+ messages in thread

* [ 09/19] crypto: sanitize argument for format string
  2013-07-11 22:01 [ 00/19] 3.10.1-stable review Greg Kroah-Hartman
@ 2013-07-11 22:01   ` Greg Kroah-Hartman
  2013-07-11 22:01 ` [ 02/19] ceph: fix sleeping function called from invalid context Greg Kroah-Hartman
                     ` (23 subsequent siblings)
  24 siblings, 0 replies; 213+ messages in thread
From: Greg Kroah-Hartman @ 2013-07-11 22:01 UTC (permalink / raw)
  To: linux-kernel
  Cc: Greg Kroah-Hartman, stable, Kees Cook, Herbert Xu,
	David S. Miller, Andrew Morton, Linus Torvalds

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



^ permalink raw reply	[flat|nested] 213+ messages in thread

* [ 09/19] crypto: sanitize argument for format string
@ 2013-07-11 22:01   ` Greg Kroah-Hartman
  0 siblings, 0 replies; 213+ messages in thread
From: Greg Kroah-Hartman @ 2013-07-11 22:01 UTC (permalink / raw)
  To: linux-kernel
  Cc: Greg Kroah-Hartman, stable, Kees Cook, Herbert Xu,
	David S. Miller, Andrew Morton, Linus Torvalds

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



^ permalink raw reply	[flat|nested] 213+ messages in thread

* [ 10/19] MAINTAINERS: add stable_kernel_rules.txt to stable maintainer information
  2013-07-11 22:01 [ 00/19] 3.10.1-stable review Greg Kroah-Hartman
                   ` (8 preceding siblings ...)
  2013-07-11 22:01   ` Greg Kroah-Hartman
@ 2013-07-11 22:01 ` Greg Kroah-Hartman
  2013-07-11 22:01 ` [ 11/19] futex: Take hugepages into account when generating futex_key Greg Kroah-Hartman
                   ` (14 subsequent siblings)
  24 siblings, 0 replies; 213+ messages in thread
From: Greg Kroah-Hartman @ 2013-07-11 22:01 UTC (permalink / raw)
  To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, David Howells

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>



^ permalink raw reply	[flat|nested] 213+ messages in thread

* [ 11/19] futex: Take hugepages into account when generating futex_key
  2013-07-11 22:01 [ 00/19] 3.10.1-stable review Greg Kroah-Hartman
                   ` (9 preceding siblings ...)
  2013-07-11 22:01 ` [ 10/19] MAINTAINERS: add stable_kernel_rules.txt to stable maintainer information Greg Kroah-Hartman
@ 2013-07-11 22:01 ` Greg Kroah-Hartman
  2013-07-11 22:01 ` [ 12/19] tty: Reset itty for other pty Greg Kroah-Hartman
                   ` (13 subsequent siblings)
  24 siblings, 0 replies; 213+ messages in thread
From: Greg Kroah-Hartman @ 2013-07-11 22:01 UTC (permalink / raw)
  To: linux-kernel
  Cc: Greg Kroah-Hartman, stable, Zhang Yi, Jiang Biao, Ma Chenggong,
	Mel Gorman, Darren Hart, Peter Zijlstra, Thomas Gleixner

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;



^ permalink raw reply	[flat|nested] 213+ messages in thread

* [ 12/19] tty: Reset itty for other pty
  2013-07-11 22:01 [ 00/19] 3.10.1-stable review Greg Kroah-Hartman
                   ` (10 preceding siblings ...)
  2013-07-11 22:01 ` [ 11/19] futex: Take hugepages into account when generating futex_key Greg Kroah-Hartman
@ 2013-07-11 22:01 ` Greg Kroah-Hartman
  2013-07-11 22:01 ` [ 13/19] Revert "serial: 8250_pci: add support for another kind of NetMos Technology PCI 9835 Multi-I/O Controller" Greg Kroah-Hartman
                   ` (12 subsequent siblings)
  24 siblings, 0 replies; 213+ messages in thread
From: Greg Kroah-Hartman @ 2013-07-11 22:01 UTC (permalink / raw)
  To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Peter Hurley

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)



^ permalink raw reply	[flat|nested] 213+ messages in thread

* [ 13/19] Revert "serial: 8250_pci: add support for another kind of NetMos Technology PCI 9835 Multi-I/O Controller"
  2013-07-11 22:01 [ 00/19] 3.10.1-stable review Greg Kroah-Hartman
                   ` (11 preceding siblings ...)
  2013-07-11 22:01 ` [ 12/19] tty: Reset itty for other pty Greg Kroah-Hartman
@ 2013-07-11 22:01 ` Greg Kroah-Hartman
  2013-07-11 22:01 ` [ 14/19] NFSv4.1 end back channel session draining Greg Kroah-Hartman
                   ` (11 subsequent siblings)
  24 siblings, 0 replies; 213+ messages in thread
From: Greg Kroah-Hartman @ 2013-07-11 22:01 UTC (permalink / raw)
  To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Stefan Seyfried, Wang YanQing

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



^ permalink raw reply	[flat|nested] 213+ messages in thread

* [ 14/19] NFSv4.1 end back channel session draining
  2013-07-11 22:01 [ 00/19] 3.10.1-stable review Greg Kroah-Hartman
                   ` (12 preceding siblings ...)
  2013-07-11 22:01 ` [ 13/19] Revert "serial: 8250_pci: add support for another kind of NetMos Technology PCI 9835 Multi-I/O Controller" Greg Kroah-Hartman
@ 2013-07-11 22:01 ` Greg Kroah-Hartman
  2013-07-11 22:01 ` [ 15/19] nfsd4: fix decoding of compounds across page boundaries Greg Kroah-Hartman
                   ` (10 subsequent siblings)
  24 siblings, 0 replies; 213+ messages in thread
From: Greg Kroah-Hartman @ 2013-07-11 22:01 UTC (permalink / raw)
  To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Andy Adamson, Trond Myklebust

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



^ permalink raw reply	[flat|nested] 213+ messages in thread

* [ 15/19] nfsd4: fix decoding of compounds across page boundaries
  2013-07-11 22:01 [ 00/19] 3.10.1-stable review Greg Kroah-Hartman
                   ` (13 preceding siblings ...)
  2013-07-11 22:01 ` [ 14/19] NFSv4.1 end back channel session draining Greg Kroah-Hartman
@ 2013-07-11 22:01 ` Greg Kroah-Hartman
  2013-07-11 22:01 ` [ 16/19] KVM: VMX: mark unusable segment as nonpresent Greg Kroah-Hartman
                   ` (9 subsequent siblings)
  24 siblings, 0 replies; 213+ messages in thread
From: Greg Kroah-Hartman @ 2013-07-11 22:01 UTC (permalink / raw)
  To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Rick Macklem, J. Bruce Fields

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;



^ permalink raw reply	[flat|nested] 213+ messages in thread

* [ 16/19] KVM: VMX: mark unusable segment as nonpresent
  2013-07-11 22:01 [ 00/19] 3.10.1-stable review Greg Kroah-Hartman
                   ` (14 preceding siblings ...)
  2013-07-11 22:01 ` [ 15/19] nfsd4: fix decoding of compounds across page boundaries Greg Kroah-Hartman
@ 2013-07-11 22:01 ` Greg Kroah-Hartman
  2013-07-11 22:01 ` [ 17/19] SCSI: sd: Fix parsing of temporary cache mode prefix Greg Kroah-Hartman
                   ` (8 subsequent siblings)
  24 siblings, 0 replies; 213+ messages in thread
From: Greg Kroah-Hartman @ 2013-07-11 22:01 UTC (permalink / raw)
  To: linux-kernel
  Cc: Greg Kroah-Hartman, stable, Stefan Pietsch, Gleb Natapov, Paolo Bonzini

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)



^ permalink raw reply	[flat|nested] 213+ messages in thread

* [ 17/19] SCSI: sd: Fix parsing of temporary  cache mode prefix
  2013-07-11 22:01 [ 00/19] 3.10.1-stable review Greg Kroah-Hartman
                   ` (15 preceding siblings ...)
  2013-07-11 22:01 ` [ 16/19] KVM: VMX: mark unusable segment as nonpresent Greg Kroah-Hartman
@ 2013-07-11 22:01 ` Greg Kroah-Hartman
  2013-07-11 22:01 ` [ 18/19] cpufreq: Fix cpufreq regression after suspend/resume Greg Kroah-Hartman
                   ` (7 subsequent siblings)
  24 siblings, 0 replies; 213+ messages in thread
From: Greg Kroah-Hartman @ 2013-07-11 22:01 UTC (permalink / raw)
  To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Ben Hutchings, James Bottomley

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)



^ permalink raw reply	[flat|nested] 213+ messages in thread

* [ 18/19] cpufreq: Fix cpufreq regression after suspend/resume
  2013-07-11 22:01 [ 00/19] 3.10.1-stable review Greg Kroah-Hartman
                   ` (16 preceding siblings ...)
  2013-07-11 22:01 ` [ 17/19] SCSI: sd: Fix parsing of temporary cache mode prefix Greg Kroah-Hartman
@ 2013-07-11 22:01 ` Greg Kroah-Hartman
  2013-07-11 22:01 ` [ 19/19] Revert "memcg: avoid dangling reference count in creation failure" Greg Kroah-Hartman
                   ` (6 subsequent siblings)
  24 siblings, 0 replies; 213+ messages in thread
From: Greg Kroah-Hartman @ 2013-07-11 22:01 UTC (permalink / raw)
  To: linux-kernel
  Cc: Greg Kroah-Hartman, stable, Srivatsa S. Bhat, Rafael J. Wysocki

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:



^ permalink raw reply	[flat|nested] 213+ messages in thread

* [ 19/19] Revert "memcg: avoid dangling reference count in creation failure"
  2013-07-11 22:01 [ 00/19] 3.10.1-stable review Greg Kroah-Hartman
                   ` (17 preceding siblings ...)
  2013-07-11 22:01 ` [ 18/19] cpufreq: Fix cpufreq regression after suspend/resume Greg Kroah-Hartman
@ 2013-07-11 22:01 ` Greg Kroah-Hartman
  2013-07-11 22:14 ` [ 00/19] 3.10.1-stable review Josh Boyer
                   ` (5 subsequent siblings)
  24 siblings, 0 replies; 213+ messages in thread
From: Greg Kroah-Hartman @ 2013-07-11 22:01 UTC (permalink / raw)
  To: linux-kernel
  Cc: Greg Kroah-Hartman, stable, Michal Hocko, Li Zefan,
	KAMEZAWA Hiroyuki, Hugh Dickins, Tejun Heo, Glauber Costa,
	Johannes Weiner, Andrew Morton, Linus Torvalds

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



^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [ 00/19] 3.10.1-stable review
  2013-07-11 22:01 [ 00/19] 3.10.1-stable review Greg Kroah-Hartman
                   ` (18 preceding siblings ...)
  2013-07-11 22:01 ` [ 19/19] Revert "memcg: avoid dangling reference count in creation failure" Greg Kroah-Hartman
@ 2013-07-11 22:14 ` Josh Boyer
  2013-07-14 22:54   ` Benjamin Herrenschmidt
  2013-07-11 22:29 ` Dave Jones
                   ` (4 subsequent siblings)
  24 siblings, 1 reply; 213+ messages in thread
From: Josh Boyer @ 2013-07-11 22:14 UTC (permalink / raw)
  To: Greg Kroah-Hartman
  Cc: Linux-Kernel@Vger. Kernel. Org, Linus Torvalds, Andrew Morton, stable

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

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [ 00/19] 3.10.1-stable review
  2013-07-11 22:01 [ 00/19] 3.10.1-stable review Greg Kroah-Hartman
                   ` (19 preceding siblings ...)
  2013-07-11 22:14 ` [ 00/19] 3.10.1-stable review Josh Boyer
@ 2013-07-11 22:29 ` Dave Jones
  2013-07-11 22:44   ` Greg Kroah-Hartman
  2013-07-12  0:50 ` When to push bug fixes to mainline Theodore Ts'o
                   ` (3 subsequent siblings)
  24 siblings, 1 reply; 213+ messages in thread
From: Dave Jones @ 2013-07-11 22:29 UTC (permalink / raw)
  To: Greg Kroah-Hartman; +Cc: linux-kernel, torvalds, akpm, stable

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


^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [ 00/19] 3.10.1-stable review
  2013-07-11 22:29 ` Dave Jones
@ 2013-07-11 22:44   ` Greg Kroah-Hartman
  2013-07-12  1:51     ` Steven Rostedt
                       ` (2 more replies)
  0 siblings, 3 replies; 213+ messages in thread
From: Greg Kroah-Hartman @ 2013-07-11 22:44 UTC (permalink / raw)
  To: Dave Jones, linux-kernel, torvalds, akpm, stable

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

^ permalink raw reply	[flat|nested] 213+ messages in thread

* When to push bug fixes to mainline
  2013-07-11 22:01 [ 00/19] 3.10.1-stable review Greg Kroah-Hartman
                   ` (20 preceding siblings ...)
  2013-07-11 22:29 ` Dave Jones
@ 2013-07-12  0:50 ` Theodore Ts'o
  2013-07-12  1:20   ` [Ksummit-2013-discuss] " Nicholas A. Bellinger
                     ` (5 more replies)
  2013-07-12 17:20 ` [ 00/19] 3.10.1-stable review Shuah Khan
                   ` (2 subsequent siblings)
  24 siblings, 6 replies; 213+ messages in thread
From: Theodore Ts'o @ 2013-07-12  0:50 UTC (permalink / raw)
  To: Greg Kroah-Hartman
  Cc: linux-kernel, torvalds, akpm, stable, ksummit-2013-discuss

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

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [Ksummit-2013-discuss] When to push bug fixes to mainline
  2013-07-12  0:50 ` When to push bug fixes to mainline Theodore Ts'o
@ 2013-07-12  1:20   ` Nicholas A. Bellinger
  2013-07-12  1:54   ` Steven Rostedt
                     ` (4 subsequent siblings)
  5 siblings, 0 replies; 213+ messages in thread
From: Nicholas A. Bellinger @ 2013-07-12  1:20 UTC (permalink / raw)
  To: Theodore Ts'o
  Cc: Greg Kroah-Hartman, ksummit-2013-discuss, torvalds, linux-kernel, stable

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


^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [ 00/19] 3.10.1-stable review
  2013-07-11 22:44   ` Greg Kroah-Hartman
@ 2013-07-12  1:51     ` Steven Rostedt
  2013-07-12 14:15     ` Guenter Roeck
  2013-07-14 22:58     ` Benjamin Herrenschmidt
  2 siblings, 0 replies; 213+ messages in thread
From: Steven Rostedt @ 2013-07-12  1:51 UTC (permalink / raw)
  To: Greg Kroah-Hartman
  Cc: Dave Jones, linux-kernel, torvalds, akpm, stable, ksummit-2013-discuss

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



^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [Ksummit-2013-discuss] When to push bug fixes to mainline
  2013-07-12  0:50 ` When to push bug fixes to mainline Theodore Ts'o
  2013-07-12  1:20   ` [Ksummit-2013-discuss] " Nicholas A. Bellinger
@ 2013-07-12  1:54   ` Steven Rostedt
  2013-07-12  9:46     ` Jiri Kosina
  2013-07-12  2:57   ` John W. Linville
                     ` (3 subsequent siblings)
  5 siblings, 1 reply; 213+ messages in thread
From: Steven Rostedt @ 2013-07-12  1:54 UTC (permalink / raw)
  To: Theodore Ts'o
  Cc: Greg Kroah-Hartman, ksummit-2013-discuss, torvalds, linux-kernel, stable

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



^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [Ksummit-2013-discuss] When to push bug fixes to mainline
  2013-07-12  0:50 ` When to push bug fixes to mainline Theodore Ts'o
  2013-07-12  1:20   ` [Ksummit-2013-discuss] " Nicholas A. Bellinger
  2013-07-12  1:54   ` Steven Rostedt
@ 2013-07-12  2:57   ` John W. Linville
  2013-07-12  3:34     ` Greg Kroah-Hartman
  2013-07-12  3:25   ` Li Zefan
                     ` (2 subsequent siblings)
  5 siblings, 1 reply; 213+ messages in thread
From: John W. Linville @ 2013-07-12  2:57 UTC (permalink / raw)
  To: Theodore Ts'o, Greg Kroah-Hartman, linux-kernel, torvalds,
	akpm, stable, ksummit-2013-discuss

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.

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: When to push bug fixes to mainline
  2013-07-12  0:50 ` When to push bug fixes to mainline Theodore Ts'o
                     ` (2 preceding siblings ...)
  2013-07-12  2:57   ` John W. Linville
@ 2013-07-12  3:25   ` Li Zefan
  2013-07-15  4:22     ` Rob Landley
  2013-07-12  5:14   ` Willy Tarreau
  2013-07-12 17:11   ` H. Peter Anvin
  5 siblings, 1 reply; 213+ messages in thread
From: Li Zefan @ 2013-07-12  3:25 UTC (permalink / raw)
  To: Theodore Ts'o, Greg Kroah-Hartman, linux-kernel, torvalds,
	akpm, stable, ksummit-2013-discuss

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.


^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [Ksummit-2013-discuss] When to push bug fixes to mainline
  2013-07-12  2:57   ` John W. Linville
@ 2013-07-12  3:34     ` Greg Kroah-Hartman
  2013-07-12  7:32       ` James Bottomley
                         ` (2 more replies)
  0 siblings, 3 replies; 213+ messages in thread
From: Greg Kroah-Hartman @ 2013-07-12  3:34 UTC (permalink / raw)
  To: John W. Linville
  Cc: Theodore Ts'o, linux-kernel, torvalds, akpm, stable,
	ksummit-2013-discuss

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

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: When to push bug fixes to mainline
  2013-07-12  0:50 ` When to push bug fixes to mainline Theodore Ts'o
                     ` (3 preceding siblings ...)
  2013-07-12  3:25   ` Li Zefan
@ 2013-07-12  5:14   ` Willy Tarreau
  2013-07-16  7:19     ` David Lang
  2013-07-12 17:11   ` H. Peter Anvin
  5 siblings, 1 reply; 213+ messages in thread
From: Willy Tarreau @ 2013-07-12  5:14 UTC (permalink / raw)
  To: Theodore Ts'o, Greg Kroah-Hartman, linux-kernel, torvalds,
	akpm, stable, ksummit-2013-discuss

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


^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [Ksummit-2013-discuss] When to push bug fixes to mainline
  2013-07-12  3:34     ` Greg Kroah-Hartman
@ 2013-07-12  7:32       ` James Bottomley
  2013-07-12 17:20       ` H. Peter Anvin
  2013-07-13  0:24       ` Rafael J. Wysocki
  2 siblings, 0 replies; 213+ messages in thread
From: James Bottomley @ 2013-07-12  7:32 UTC (permalink / raw)
  To: Greg Kroah-Hartman
  Cc: John W. Linville, linux-kernel, stable, ksummit-2013-discuss, torvalds

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




^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [Ksummit-2013-discuss] When to push bug fixes to mainline
  2013-07-12  1:54   ` Steven Rostedt
@ 2013-07-12  9:46     ` Jiri Kosina
  2013-07-12 11:19       ` Josh Boyer
  0 siblings, 1 reply; 213+ messages in thread
From: Jiri Kosina @ 2013-07-12  9:46 UTC (permalink / raw)
  To: Steven Rostedt
  Cc: Theodore Ts'o, Greg Kroah-Hartman, torvalds,
	ksummit-2013-discuss, linux-kernel, stable

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

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [Ksummit-2013-discuss] When to push bug fixes to mainline
  2013-07-12  9:46     ` Jiri Kosina
@ 2013-07-12 11:19       ` Josh Boyer
  0 siblings, 0 replies; 213+ messages in thread
From: Josh Boyer @ 2013-07-12 11:19 UTC (permalink / raw)
  To: Jiri Kosina
  Cc: Steven Rostedt, Greg Kroah-Hartman,
	Linux-Kernel@Vger. Kernel. Org, stable, ksummit-2013-discuss,
	Linus Torvalds

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

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [ 00/19] 3.10.1-stable review
  2013-07-11 22:44   ` Greg Kroah-Hartman
  2013-07-12  1:51     ` Steven Rostedt
@ 2013-07-12 14:15     ` Guenter Roeck
  2013-07-12 15:22       ` Linus Torvalds
  2013-07-14 22:58     ` Benjamin Herrenschmidt
  2 siblings, 1 reply; 213+ messages in thread
From: Guenter Roeck @ 2013-07-12 14:15 UTC (permalink / raw)
  To: Greg Kroah-Hartman; +Cc: Dave Jones, linux-kernel, torvalds, akpm, stable

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

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [ 00/19] 3.10.1-stable review
  2013-07-12 14:15     ` Guenter Roeck
@ 2013-07-12 15:22       ` Linus Torvalds
  2013-07-12 15:47         ` Steven Rostedt
  2013-07-12 17:31         ` Guenter Roeck
  0 siblings, 2 replies; 213+ messages in thread
From: Linus Torvalds @ 2013-07-12 15:22 UTC (permalink / raw)
  To: Guenter Roeck
  Cc: Greg Kroah-Hartman, Dave Jones, Linux Kernel Mailing List,
	Andrew Morton, stable

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

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [ 00/19] 3.10.1-stable review
  2013-07-12 15:22       ` Linus Torvalds
@ 2013-07-12 15:47         ` Steven Rostedt
  2013-07-12 15:55           ` Linus Torvalds
  2013-07-12 17:31         ` Guenter Roeck
  1 sibling, 1 reply; 213+ messages in thread
From: Steven Rostedt @ 2013-07-12 15:47 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Guenter Roeck, Greg Kroah-Hartman, Dave Jones,
	Linux Kernel Mailing List, Andrew Morton, stable

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



^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [ 00/19] 3.10.1-stable review
  2013-07-12 15:47         ` Steven Rostedt
@ 2013-07-12 15:55           ` Linus Torvalds
  2013-07-12 16:17             ` Ingo Molnar
  2013-07-12 16:48             ` Steven Rostedt
  0 siblings, 2 replies; 213+ messages in thread
From: Linus Torvalds @ 2013-07-12 15:55 UTC (permalink / raw)
  To: Steven Rostedt
  Cc: Guenter Roeck, Greg Kroah-Hartman, Dave Jones,
	Linux Kernel Mailing List, Andrew Morton, stable

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

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [ 00/19] 3.10.1-stable review
  2013-07-12 15:55           ` Linus Torvalds
@ 2013-07-12 16:17             ` Ingo Molnar
  2013-07-12 16:35               ` Josh Boyer
  2013-07-12 16:48             ` Steven Rostedt
  1 sibling, 1 reply; 213+ messages in thread
From: Ingo Molnar @ 2013-07-12 16:17 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Steven Rostedt, Guenter Roeck, Greg Kroah-Hartman, Dave Jones,
	Linux Kernel Mailing List, Andrew Morton, stable


* 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

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [ 00/19] 3.10.1-stable review
  2013-07-12 16:17             ` Ingo Molnar
@ 2013-07-12 16:35               ` Josh Boyer
  2013-07-12 16:36                 ` Josh Boyer
  2013-07-12 17:05                 ` Greg Kroah-Hartman
  0 siblings, 2 replies; 213+ messages in thread
From: Josh Boyer @ 2013-07-12 16:35 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Linus Torvalds, Steven Rostedt, Guenter Roeck,
	Greg Kroah-Hartman, Dave Jones, Linux Kernel Mailing List,
	Andrew Morton, stable

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

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [ 00/19] 3.10.1-stable review
  2013-07-12 16:35               ` Josh Boyer
@ 2013-07-12 16:36                 ` Josh Boyer
  2013-07-12 17:05                 ` Greg Kroah-Hartman
  1 sibling, 0 replies; 213+ messages in thread
From: Josh Boyer @ 2013-07-12 16:36 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Linus Torvalds, Steven Rostedt, Guenter Roeck,
	Greg Kroah-Hartman, Dave Jones, Linux Kernel Mailing List,
	Andrew Morton, stable

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.

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [ 00/19] 3.10.1-stable review
  2013-07-12 15:55           ` Linus Torvalds
  2013-07-12 16:17             ` Ingo Molnar
@ 2013-07-12 16:48             ` Steven Rostedt
  1 sibling, 0 replies; 213+ messages in thread
From: Steven Rostedt @ 2013-07-12 16:48 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Guenter Roeck, Greg Kroah-Hartman, Dave Jones,
	Linux Kernel Mailing List, Andrew Morton, stable

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



^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [ 00/19] 3.10.1-stable review
  2013-07-12 16:35               ` Josh Boyer
  2013-07-12 16:36                 ` Josh Boyer
@ 2013-07-12 17:05                 ` Greg Kroah-Hartman
  2013-07-14 22:40                   ` Benjamin Herrenschmidt
  1 sibling, 1 reply; 213+ messages in thread
From: Greg Kroah-Hartman @ 2013-07-12 17:05 UTC (permalink / raw)
  To: Josh Boyer
  Cc: Ingo Molnar, Linus Torvalds, Steven Rostedt, Guenter Roeck,
	Dave Jones, Linux Kernel Mailing List, Andrew Morton, stable

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

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [Ksummit-2013-discuss] When to push bug fixes to mainline
  2013-07-12  0:50 ` When to push bug fixes to mainline Theodore Ts'o
                     ` (4 preceding siblings ...)
  2013-07-12  5:14   ` Willy Tarreau
@ 2013-07-12 17:11   ` H. Peter Anvin
  5 siblings, 0 replies; 213+ messages in thread
From: H. Peter Anvin @ 2013-07-12 17:11 UTC (permalink / raw)
  To: Theodore Ts'o, Greg Kroah-Hartman, linux-kernel, torvalds,
	akpm, stable, ksummit-2013-discuss

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


^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [ 00/19] 3.10.1-stable review
  2013-07-11 22:01 [ 00/19] 3.10.1-stable review Greg Kroah-Hartman
                   ` (21 preceding siblings ...)
  2013-07-12  0:50 ` When to push bug fixes to mainline Theodore Ts'o
@ 2013-07-12 17:20 ` Shuah Khan
  2013-07-12 17:29   ` Greg Kroah-Hartman
  2013-07-13  4:14 ` Satoru Takeuchi
  2013-07-14 23:06 ` Benjamin Herrenschmidt
  24 siblings, 1 reply; 213+ messages in thread
From: Shuah Khan @ 2013-07-12 17:20 UTC (permalink / raw)
  To: Greg Kroah-Hartman
  Cc: linux-kernel, torvalds, akpm, stable, Shuah Khan, shuahkhan

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

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [Ksummit-2013-discuss] When to push bug fixes to mainline
  2013-07-12  3:34     ` Greg Kroah-Hartman
  2013-07-12  7:32       ` James Bottomley
@ 2013-07-12 17:20       ` H. Peter Anvin
  2013-07-12 17:28         ` Greg Kroah-Hartman
  2013-07-13  0:24       ` Rafael J. Wysocki
  2 siblings, 1 reply; 213+ messages in thread
From: H. Peter Anvin @ 2013-07-12 17:20 UTC (permalink / raw)
  To: Greg Kroah-Hartman
  Cc: John W. Linville, Theodore Ts'o, linux-kernel, torvalds,
	akpm, stable, ksummit-2013-discuss

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


^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [Ksummit-2013-discuss] When to push bug fixes to mainline
  2013-07-12 17:20       ` H. Peter Anvin
@ 2013-07-12 17:28         ` Greg Kroah-Hartman
  2013-07-12 17:50           ` Steven Rostedt
  2013-07-12 17:57           ` Theodore Ts'o
  0 siblings, 2 replies; 213+ messages in thread
From: Greg Kroah-Hartman @ 2013-07-12 17:28 UTC (permalink / raw)
  To: H. Peter Anvin
  Cc: John W. Linville, Theodore Ts'o, linux-kernel, torvalds,
	akpm, stable, ksummit-2013-discuss

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

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [ 00/19] 3.10.1-stable review
  2013-07-12 17:20 ` [ 00/19] 3.10.1-stable review Shuah Khan
@ 2013-07-12 17:29   ` Greg Kroah-Hartman
  0 siblings, 0 replies; 213+ messages in thread
From: Greg Kroah-Hartman @ 2013-07-12 17:29 UTC (permalink / raw)
  To: Shuah Khan; +Cc: linux-kernel, torvalds, akpm, stable, shuahkhan

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

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [ 00/19] 3.10.1-stable review
  2013-07-12 15:22       ` Linus Torvalds
  2013-07-12 15:47         ` Steven Rostedt
@ 2013-07-12 17:31         ` Guenter Roeck
  2013-07-12 17:50           ` Linus Torvalds
  1 sibling, 1 reply; 213+ messages in thread
From: Guenter Roeck @ 2013-07-12 17:31 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Greg Kroah-Hartman, Dave Jones, Linux Kernel Mailing List,
	Andrew Morton, stable

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

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [ 00/19] 3.10.1-stable review
  2013-07-12 17:31         ` Guenter Roeck
@ 2013-07-12 17:50           ` Linus Torvalds
  2013-07-12 18:11             ` Guenter Roeck
                               ` (2 more replies)
  0 siblings, 3 replies; 213+ messages in thread
From: Linus Torvalds @ 2013-07-12 17:50 UTC (permalink / raw)
  To: Guenter Roeck
  Cc: Greg Kroah-Hartman, Dave Jones, Linux Kernel Mailing List,
	Andrew Morton, stable

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

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [Ksummit-2013-discuss] When to push bug fixes to mainline
  2013-07-12 17:28         ` Greg Kroah-Hartman
@ 2013-07-12 17:50           ` Steven Rostedt
  2013-07-12 17:59             ` Linus Torvalds
  2013-07-12 17:57           ` Theodore Ts'o
  1 sibling, 1 reply; 213+ messages in thread
From: Steven Rostedt @ 2013-07-12 17:50 UTC (permalink / raw)
  To: Greg Kroah-Hartman
  Cc: H. Peter Anvin, stable, linux-kernel, ksummit-2013-discuss, torvalds

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



^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [Ksummit-2013-discuss] When to push bug fixes to mainline
  2013-07-12 17:28         ` Greg Kroah-Hartman
  2013-07-12 17:50           ` Steven Rostedt
@ 2013-07-12 17:57           ` Theodore Ts'o
  2013-07-12 18:13             ` Guenter Roeck
  2013-07-12 18:16             ` H. Peter Anvin
  1 sibling, 2 replies; 213+ messages in thread
From: Theodore Ts'o @ 2013-07-12 17:57 UTC (permalink / raw)
  To: Greg Kroah-Hartman
  Cc: H. Peter Anvin, John W. Linville, linux-kernel, torvalds, akpm,
	stable, ksummit-2013-discuss

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

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [Ksummit-2013-discuss] When to push bug fixes to mainline
  2013-07-12 17:50           ` Steven Rostedt
@ 2013-07-12 17:59             ` Linus Torvalds
  2013-07-12 18:14               ` Steven Rostedt
  0 siblings, 1 reply; 213+ messages in thread
From: Linus Torvalds @ 2013-07-12 17:59 UTC (permalink / raw)
  To: Steven Rostedt
  Cc: Greg Kroah-Hartman, H. Peter Anvin, stable,
	Linux Kernel Mailing List, ksummit-2013-discuss

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

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [ 00/19] 3.10.1-stable review
  2013-07-12 17:50           ` Linus Torvalds
@ 2013-07-12 18:11             ` Guenter Roeck
  2013-07-12 19:35               ` Theodore Ts'o
  2013-07-12 19:50             ` Willy Tarreau
  2013-07-14 23:52             ` Benjamin Herrenschmidt
  2 siblings, 1 reply; 213+ messages in thread
From: Guenter Roeck @ 2013-07-12 18:11 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Greg Kroah-Hartman, Dave Jones, Linux Kernel Mailing List,
	Andrew Morton, stable

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

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [Ksummit-2013-discuss] When to push bug fixes to mainline
  2013-07-12 17:57           ` Theodore Ts'o
@ 2013-07-12 18:13             ` Guenter Roeck
  2013-07-12 18:16             ` H. Peter Anvin
  1 sibling, 0 replies; 213+ messages in thread
From: Guenter Roeck @ 2013-07-12 18:13 UTC (permalink / raw)
  To: Theodore Ts'o, Greg Kroah-Hartman, H. Peter Anvin,
	John W. Linville, linux-kernel, torvalds, akpm, stable,
	ksummit-2013-discuss

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

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [Ksummit-2013-discuss] When to push bug fixes to mainline
  2013-07-12 17:59             ` Linus Torvalds
@ 2013-07-12 18:14               ` Steven Rostedt
  2013-07-13 17:52                 ` Geert Uytterhoeven
  0 siblings, 1 reply; 213+ messages in thread
From: Steven Rostedt @ 2013-07-12 18:14 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Greg Kroah-Hartman, H. Peter Anvin, stable,
	Linux Kernel Mailing List, ksummit-2013-discuss

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


^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [Ksummit-2013-discuss] When to push bug fixes to mainline
  2013-07-12 17:57           ` Theodore Ts'o
  2013-07-12 18:13             ` Guenter Roeck
@ 2013-07-12 18:16             ` H. Peter Anvin
  2013-07-12 18:28               ` H. Peter Anvin
  1 sibling, 1 reply; 213+ messages in thread
From: H. Peter Anvin @ 2013-07-12 18:16 UTC (permalink / raw)
  To: Theodore Ts'o, Greg Kroah-Hartman, John W. Linville,
	linux-kernel, torvalds, akpm, stable, ksummit-2013-discuss

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



^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [Ksummit-2013-discuss] When to push bug fixes to mainline
  2013-07-12 18:16             ` H. Peter Anvin
@ 2013-07-12 18:28               ` H. Peter Anvin
  2013-07-12 19:44                 ` Linus Torvalds
  0 siblings, 1 reply; 213+ messages in thread
From: H. Peter Anvin @ 2013-07-12 18:28 UTC (permalink / raw)
  To: Theodore Ts'o, Greg Kroah-Hartman, John W. Linville,
	linux-kernel, torvalds, akpm, stable, ksummit-2013-discuss

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



^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [ 00/19] 3.10.1-stable review
  2013-07-12 18:11             ` Guenter Roeck
@ 2013-07-12 19:35               ` Theodore Ts'o
  2013-07-12 19:49                 ` Steven Rostedt
  0 siblings, 1 reply; 213+ messages in thread
From: Theodore Ts'o @ 2013-07-12 19:35 UTC (permalink / raw)
  To: Guenter Roeck
  Cc: Linus Torvalds, Greg Kroah-Hartman, Dave Jones,
	Linux Kernel Mailing List, Andrew Morton, stable

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

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [Ksummit-2013-discuss] When to push bug fixes to mainline
  2013-07-12 18:28               ` H. Peter Anvin
@ 2013-07-12 19:44                 ` Linus Torvalds
  2013-07-12 19:53                   ` Steven Rostedt
  2013-07-13  6:44                   ` Ingo Molnar
  0 siblings, 2 replies; 213+ messages in thread
From: Linus Torvalds @ 2013-07-12 19:44 UTC (permalink / raw)
  To: H. Peter Anvin
  Cc: Theodore Ts'o, Greg Kroah-Hartman, John W. Linville,
	Linux Kernel Mailing List, Andrew Morton, stable,
	ksummit-2013-discuss

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

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [ 00/19] 3.10.1-stable review
  2013-07-12 19:35               ` Theodore Ts'o
@ 2013-07-12 19:49                 ` Steven Rostedt
  2013-07-12 19:55                   ` Willy Tarreau
  2013-07-12 20:19                   ` Dave Jones
  0 siblings, 2 replies; 213+ messages in thread
From: Steven Rostedt @ 2013-07-12 19:49 UTC (permalink / raw)
  To: Theodore Ts'o
  Cc: Guenter Roeck, Linus Torvalds, Greg Kroah-Hartman, Dave Jones,
	Linux Kernel Mailing List, Andrew Morton, stable

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



^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [ 00/19] 3.10.1-stable review
  2013-07-12 17:50           ` Linus Torvalds
  2013-07-12 18:11             ` Guenter Roeck
@ 2013-07-12 19:50             ` Willy Tarreau
  2013-07-12 20:47               ` Theodore Ts'o
  2013-07-13  6:22               ` Greg Kroah-Hartman
  2013-07-14 23:52             ` Benjamin Herrenschmidt
  2 siblings, 2 replies; 213+ messages in thread
From: Willy Tarreau @ 2013-07-12 19:50 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Guenter Roeck, Greg Kroah-Hartman, Dave Jones,
	Linux Kernel Mailing List, Andrew Morton, stable

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


^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [Ksummit-2013-discuss] When to push bug fixes to mainline
  2013-07-12 19:44                 ` Linus Torvalds
@ 2013-07-12 19:53                   ` Steven Rostedt
  2013-07-12 20:09                     ` Shuah Khan
                                       ` (2 more replies)
  2013-07-13  6:44                   ` Ingo Molnar
  1 sibling, 3 replies; 213+ messages in thread
From: Steven Rostedt @ 2013-07-12 19:53 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: H. Peter Anvin, Greg Kroah-Hartman, stable,
	Linux Kernel Mailing List, ksummit-2013-discuss

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



^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [ 00/19] 3.10.1-stable review
  2013-07-12 19:49                 ` Steven Rostedt
@ 2013-07-12 19:55                   ` Willy Tarreau
  2013-07-12 20:19                   ` Dave Jones
  1 sibling, 0 replies; 213+ messages in thread
From: Willy Tarreau @ 2013-07-12 19:55 UTC (permalink / raw)
  To: Steven Rostedt
  Cc: Theodore Ts'o, Guenter Roeck, Linus Torvalds,
	Greg Kroah-Hartman, Dave Jones, Linux Kernel Mailing List,
	Andrew Morton, stable

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


^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [Ksummit-2013-discuss] When to push bug fixes to mainline
  2013-07-12 19:53                   ` Steven Rostedt
@ 2013-07-12 20:09                     ` Shuah Khan
  2013-07-12 20:33                     ` Greg Kroah-Hartman
  2013-07-12 22:17                     ` H. Peter Anvin
  2 siblings, 0 replies; 213+ messages in thread
From: Shuah Khan @ 2013-07-12 20:09 UTC (permalink / raw)
  To: Steven Rostedt
  Cc: Linus Torvalds, H. Peter Anvin, Greg Kroah-Hartman, stable,
	Linux Kernel Mailing List, ksummit-2013-discuss

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

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [ 00/19] 3.10.1-stable review
  2013-07-12 19:49                 ` Steven Rostedt
  2013-07-12 19:55                   ` Willy Tarreau
@ 2013-07-12 20:19                   ` Dave Jones
  2013-07-12 20:28                     ` Steven Rostedt
  1 sibling, 1 reply; 213+ messages in thread
From: Dave Jones @ 2013-07-12 20:19 UTC (permalink / raw)
  To: Steven Rostedt
  Cc: Theodore Ts'o, Guenter Roeck, Linus Torvalds,
	Greg Kroah-Hartman, Linux Kernel Mailing List, Andrew Morton,
	stable

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


^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [ 00/19] 3.10.1-stable review
  2013-07-12 20:19                   ` Dave Jones
@ 2013-07-12 20:28                     ` Steven Rostedt
  2013-07-12 20:31                       ` Steven Rostedt
                                         ` (2 more replies)
  0 siblings, 3 replies; 213+ messages in thread
From: Steven Rostedt @ 2013-07-12 20:28 UTC (permalink / raw)
  To: Dave Jones
  Cc: Theodore Ts'o, Guenter Roeck, Linus Torvalds,
	Greg Kroah-Hartman, Linux Kernel Mailing List, Andrew Morton,
	stable

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



^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [ 00/19] 3.10.1-stable review
  2013-07-12 20:28                     ` Steven Rostedt
@ 2013-07-12 20:31                       ` Steven Rostedt
  2013-07-12 21:19                       ` Justin M. Forbes
  2013-07-13  0:47                       ` Jochen Striepe
  2 siblings, 0 replies; 213+ messages in thread
From: Steven Rostedt @ 2013-07-12 20:31 UTC (permalink / raw)
  To: Dave Jones
  Cc: Theodore Ts'o, Guenter Roeck, Linus Torvalds,
	Greg Kroah-Hartman, Linux Kernel Mailing List, Andrew Morton,
	stable

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



^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [Ksummit-2013-discuss] When to push bug fixes to mainline
  2013-07-12 19:53                   ` Steven Rostedt
  2013-07-12 20:09                     ` Shuah Khan
@ 2013-07-12 20:33                     ` Greg Kroah-Hartman
  2013-07-12 20:46                       ` Steven Rostedt
  2013-07-12 22:19                       ` H. Peter Anvin
  2013-07-12 22:17                     ` H. Peter Anvin
  2 siblings, 2 replies; 213+ messages in thread
From: Greg Kroah-Hartman @ 2013-07-12 20:33 UTC (permalink / raw)
  To: Steven Rostedt
  Cc: Linus Torvalds, H. Peter Anvin, stable,
	Linux Kernel Mailing List, ksummit-2013-discuss

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

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [Ksummit-2013-discuss] When to push bug fixes to mainline
  2013-07-12 20:33                     ` Greg Kroah-Hartman
@ 2013-07-12 20:46                       ` Steven Rostedt
  2013-07-12 22:19                       ` H. Peter Anvin
  1 sibling, 0 replies; 213+ messages in thread
From: Steven Rostedt @ 2013-07-12 20:46 UTC (permalink / raw)
  To: Greg Kroah-Hartman
  Cc: Linus Torvalds, H. Peter Anvin, stable,
	Linux Kernel Mailing List, ksummit-2013-discuss

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



^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [ 00/19] 3.10.1-stable review
  2013-07-12 19:50             ` Willy Tarreau
@ 2013-07-12 20:47               ` Theodore Ts'o
  2013-07-12 21:02                 ` Guenter Roeck
  2013-07-13  6:22               ` Greg Kroah-Hartman
  1 sibling, 1 reply; 213+ messages in thread
From: Theodore Ts'o @ 2013-07-12 20:47 UTC (permalink / raw)
  To: Willy Tarreau
  Cc: Linus Torvalds, Guenter Roeck, Greg Kroah-Hartman, Dave Jones,
	Linux Kernel Mailing List, Andrew Morton, stable

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

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [ 00/19] 3.10.1-stable review
  2013-07-12 20:47               ` Theodore Ts'o
@ 2013-07-12 21:02                 ` Guenter Roeck
  0 siblings, 0 replies; 213+ messages in thread
From: Guenter Roeck @ 2013-07-12 21:02 UTC (permalink / raw)
  To: Theodore Ts'o, Willy Tarreau, Linus Torvalds,
	Greg Kroah-Hartman, Dave Jones, Linux Kernel Mailing List,
	Andrew Morton, stable

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

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [ 00/19] 3.10.1-stable review
  2013-07-12 20:28                     ` Steven Rostedt
  2013-07-12 20:31                       ` Steven Rostedt
@ 2013-07-12 21:19                       ` Justin M. Forbes
  2013-07-13  0:47                       ` Jochen Striepe
  2 siblings, 0 replies; 213+ messages in thread
From: Justin M. Forbes @ 2013-07-12 21:19 UTC (permalink / raw)
  To: Steven Rostedt
  Cc: Dave Jones, Theodore Ts'o, Guenter Roeck, Linus Torvalds,
	Greg Kroah-Hartman, Linux Kernel Mailing List, Andrew Morton,
	stable

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

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [Ksummit-2013-discuss] When to push bug fixes to mainline
  2013-07-12 19:53                   ` Steven Rostedt
  2013-07-12 20:09                     ` Shuah Khan
  2013-07-12 20:33                     ` Greg Kroah-Hartman
@ 2013-07-12 22:17                     ` H. Peter Anvin
  2 siblings, 0 replies; 213+ messages in thread
From: H. Peter Anvin @ 2013-07-12 22:17 UTC (permalink / raw)
  To: Steven Rostedt
  Cc: Linus Torvalds, Greg Kroah-Hartman, stable,
	Linux Kernel Mailing List, ksummit-2013-discuss

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



^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [Ksummit-2013-discuss] When to push bug fixes to mainline
  2013-07-12 20:33                     ` Greg Kroah-Hartman
  2013-07-12 20:46                       ` Steven Rostedt
@ 2013-07-12 22:19                       ` H. Peter Anvin
  1 sibling, 0 replies; 213+ messages in thread
From: H. Peter Anvin @ 2013-07-12 22:19 UTC (permalink / raw)
  To: Greg Kroah-Hartman
  Cc: Steven Rostedt, Linus Torvalds, stable,
	Linux Kernel Mailing List, ksummit-2013-discuss

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



^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [Ksummit-2013-discuss] When to push bug fixes to mainline
  2013-07-12  3:34     ` Greg Kroah-Hartman
  2013-07-12  7:32       ` James Bottomley
  2013-07-12 17:20       ` H. Peter Anvin
@ 2013-07-13  0:24       ` Rafael J. Wysocki
  2013-07-13  1:32         ` Greg Kroah-Hartman
  2 siblings, 1 reply; 213+ messages in thread
From: Rafael J. Wysocki @ 2013-07-13  0:24 UTC (permalink / raw)
  To: Greg Kroah-Hartman
  Cc: ksummit-2013-discuss, John W. Linville, linux-kernel, stable,
	ksummit-2013-discuss, torvalds

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.

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [ 00/19] 3.10.1-stable review
  2013-07-12 20:28                     ` Steven Rostedt
  2013-07-12 20:31                       ` Steven Rostedt
  2013-07-12 21:19                       ` Justin M. Forbes
@ 2013-07-13  0:47                       ` Jochen Striepe
  2013-07-13 11:11                         ` Steven Rostedt
  2 siblings, 1 reply; 213+ messages in thread
From: Jochen Striepe @ 2013-07-13  0:47 UTC (permalink / raw)
  To: Steven Rostedt
  Cc: Dave Jones, Theodore Ts'o, Guenter Roeck, Linus Torvalds,
	Greg Kroah-Hartman, Linux Kernel Mailing List, Andrew Morton,
	stable

	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.

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [Ksummit-2013-discuss] When to push bug fixes to mainline
  2013-07-13  0:24       ` Rafael J. Wysocki
@ 2013-07-13  1:32         ` Greg Kroah-Hartman
  2013-07-13 12:16           ` Rafael J. Wysocki
  0 siblings, 1 reply; 213+ messages in thread
From: Greg Kroah-Hartman @ 2013-07-13  1:32 UTC (permalink / raw)
  To: Rafael J. Wysocki
  Cc: ksummit-2013-discuss, John W. Linville, linux-kernel, stable,
	ksummit-2013-discuss, torvalds

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

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [ 00/19] 3.10.1-stable review
  2013-07-11 22:01 [ 00/19] 3.10.1-stable review Greg Kroah-Hartman
                   ` (22 preceding siblings ...)
  2013-07-12 17:20 ` [ 00/19] 3.10.1-stable review Shuah Khan
@ 2013-07-13  4:14 ` Satoru Takeuchi
  2013-07-14 23:06 ` Benjamin Herrenschmidt
  24 siblings, 0 replies; 213+ messages in thread
From: Satoru Takeuchi @ 2013-07-13  4:14 UTC (permalink / raw)
  To: Greg Kroah-Hartman; +Cc: linux-kernel, torvalds, akpm, stable

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

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [ 00/19] 3.10.1-stable review
  2013-07-12 19:50             ` Willy Tarreau
  2013-07-12 20:47               ` Theodore Ts'o
@ 2013-07-13  6:22               ` Greg Kroah-Hartman
  2013-07-13  6:36                 ` Willy Tarreau
  2013-07-13  6:43                 ` Guenter Roeck
  1 sibling, 2 replies; 213+ messages in thread
From: Greg Kroah-Hartman @ 2013-07-13  6:22 UTC (permalink / raw)
  To: Willy Tarreau
  Cc: Linus Torvalds, Guenter Roeck, Dave Jones,
	Linux Kernel Mailing List, Andrew Morton, stable

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

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [ 00/19] 3.10.1-stable review
  2013-07-13  6:22               ` Greg Kroah-Hartman
@ 2013-07-13  6:36                 ` Willy Tarreau
  2013-07-13  6:48                   ` Greg Kroah-Hartman
  2013-07-13  6:43                 ` Guenter Roeck
  1 sibling, 1 reply; 213+ messages in thread
From: Willy Tarreau @ 2013-07-13  6:36 UTC (permalink / raw)
  To: Greg Kroah-Hartman
  Cc: Linus Torvalds, Guenter Roeck, Dave Jones,
	Linux Kernel Mailing List, Andrew Morton, stable

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


^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [ 00/19] 3.10.1-stable review
  2013-07-13  6:22               ` Greg Kroah-Hartman
  2013-07-13  6:36                 ` Willy Tarreau
@ 2013-07-13  6:43                 ` Guenter Roeck
  2013-07-13  6:58                   ` Greg Kroah-Hartman
  1 sibling, 1 reply; 213+ messages in thread
From: Guenter Roeck @ 2013-07-13  6:43 UTC (permalink / raw)
  To: Greg Kroah-Hartman
  Cc: Willy Tarreau, Linus Torvalds, Dave Jones,
	Linux Kernel Mailing List, Andrew Morton, stable

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

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [Ksummit-2013-discuss] When to push bug fixes to mainline
  2013-07-12 19:44                 ` Linus Torvalds
  2013-07-12 19:53                   ` Steven Rostedt
@ 2013-07-13  6:44                   ` Ingo Molnar
  1 sibling, 0 replies; 213+ messages in thread
From: Ingo Molnar @ 2013-07-13  6:44 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: H. Peter Anvin, Theodore Ts'o, Greg Kroah-Hartman,
	John W. Linville, Linux Kernel Mailing List, Andrew Morton,
	stable, ksummit-2013-discuss


* 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

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [ 00/19] 3.10.1-stable review
  2013-07-13  6:36                 ` Willy Tarreau
@ 2013-07-13  6:48                   ` Greg Kroah-Hartman
  2013-07-13  7:12                     ` Willy Tarreau
  2013-07-13 11:42                     ` Theodore Ts'o
  0 siblings, 2 replies; 213+ messages in thread
From: Greg Kroah-Hartman @ 2013-07-13  6:48 UTC (permalink / raw)
  To: Willy Tarreau
  Cc: Linus Torvalds, Guenter Roeck, Dave Jones,
	Linux Kernel Mailing List, Andrew Morton, stable

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

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [ 00/19] 3.10.1-stable review
  2013-07-13  6:43                 ` Guenter Roeck
@ 2013-07-13  6:58                   ` Greg Kroah-Hartman
  0 siblings, 0 replies; 213+ messages in thread
From: Greg Kroah-Hartman @ 2013-07-13  6:58 UTC (permalink / raw)
  To: Guenter Roeck
  Cc: Willy Tarreau, Linus Torvalds, Dave Jones,
	Linux Kernel Mailing List, Andrew Morton, stable

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

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [ 00/19] 3.10.1-stable review
  2013-07-13  6:48                   ` Greg Kroah-Hartman
@ 2013-07-13  7:12                     ` Willy Tarreau
  2013-07-15  4:12                       ` Li Zefan
  2013-07-13 11:42                     ` Theodore Ts'o
  1 sibling, 1 reply; 213+ messages in thread
From: Willy Tarreau @ 2013-07-13  7:12 UTC (permalink / raw)
  To: Greg Kroah-Hartman
  Cc: Linus Torvalds, Guenter Roeck, Dave Jones,
	Linux Kernel Mailing List, Andrew Morton, stable

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


^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [ 00/19] 3.10.1-stable review
  2013-07-13  0:47                       ` Jochen Striepe
@ 2013-07-13 11:11                         ` Steven Rostedt
  2013-07-13 15:10                           ` Dave Jones
  0 siblings, 1 reply; 213+ messages in thread
From: Steven Rostedt @ 2013-07-13 11:11 UTC (permalink / raw)
  To: Jochen Striepe
  Cc: Dave Jones, Theodore Ts'o, Guenter Roeck, Linus Torvalds,
	Greg Kroah-Hartman, Linux Kernel Mailing List, Andrew Morton,
	stable

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



^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [ 00/19] 3.10.1-stable review
  2013-07-13  6:48                   ` Greg Kroah-Hartman
  2013-07-13  7:12                     ` Willy Tarreau
@ 2013-07-13 11:42                     ` Theodore Ts'o
  2013-07-13 18:27                       ` Greg Kroah-Hartman
  1 sibling, 1 reply; 213+ messages in thread
From: Theodore Ts'o @ 2013-07-13 11:42 UTC (permalink / raw)
  To: Greg Kroah-Hartman
  Cc: Willy Tarreau, Linus Torvalds, Guenter Roeck, Dave Jones,
	Linux Kernel Mailing List, Andrew Morton, stable

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

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [Ksummit-2013-discuss] When to push bug fixes to mainline
  2013-07-13  1:32         ` Greg Kroah-Hartman
@ 2013-07-13 12:16           ` Rafael J. Wysocki
  0 siblings, 0 replies; 213+ messages in thread
From: Rafael J. Wysocki @ 2013-07-13 12:16 UTC (permalink / raw)
  To: Greg Kroah-Hartman
  Cc: ksummit-2013-discuss, John W. Linville, linux-kernel, stable,
	ksummit-2013-discuss, torvalds

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.

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [ 00/19] 3.10.1-stable review
  2013-07-13 11:11                         ` Steven Rostedt
@ 2013-07-13 15:10                           ` Dave Jones
  2013-07-13 15:54                             ` Steven Rostedt
  0 siblings, 1 reply; 213+ messages in thread
From: Dave Jones @ 2013-07-13 15:10 UTC (permalink / raw)
  To: Steven Rostedt
  Cc: Jochen Striepe, Theodore Ts'o, Guenter Roeck, Linus Torvalds,
	Greg Kroah-Hartman, Linux Kernel Mailing List, Andrew Morton,
	stable

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

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [ 00/19] 3.10.1-stable review
  2013-07-13 15:10                           ` Dave Jones
@ 2013-07-13 15:54                             ` Steven Rostedt
  0 siblings, 0 replies; 213+ messages in thread
From: Steven Rostedt @ 2013-07-13 15:54 UTC (permalink / raw)
  To: Dave Jones
  Cc: Jochen Striepe, Theodore Ts'o, Guenter Roeck, Linus Torvalds,
	Greg Kroah-Hartman, Linux Kernel Mailing List, Andrew Morton,
	stable

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



^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [Ksummit-2013-discuss] When to push bug fixes to mainline
  2013-07-12 18:14               ` Steven Rostedt
@ 2013-07-13 17:52                 ` Geert Uytterhoeven
  0 siblings, 0 replies; 213+ messages in thread
From: Geert Uytterhoeven @ 2013-07-13 17:52 UTC (permalink / raw)
  To: Steven Rostedt
  Cc: Linus Torvalds, Greg Kroah-Hartman, H. Peter Anvin, stable,
	Linux Kernel Mailing List, ksummit-2013-discuss

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

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [ 00/19] 3.10.1-stable review
  2013-07-13 11:42                     ` Theodore Ts'o
@ 2013-07-13 18:27                       ` Greg Kroah-Hartman
  2013-07-14  2:22                         ` Theodore Ts'o
  0 siblings, 1 reply; 213+ messages in thread
From: Greg Kroah-Hartman @ 2013-07-13 18:27 UTC (permalink / raw)
  To: Theodore Ts'o, Willy Tarreau, Linus Torvalds, Guenter Roeck,
	Dave Jones, Linux Kernel Mailing List, Andrew Morton, stable

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

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [ 00/19] 3.10.1-stable review
  2013-07-13 18:27                       ` Greg Kroah-Hartman
@ 2013-07-14  2:22                         ` Theodore Ts'o
  2013-07-14  3:51                           ` Greg Kroah-Hartman
  0 siblings, 1 reply; 213+ messages in thread
From: Theodore Ts'o @ 2013-07-14  2:22 UTC (permalink / raw)
  To: Greg Kroah-Hartman
  Cc: Willy Tarreau, Linus Torvalds, Guenter Roeck, Dave Jones,
	Linux Kernel Mailing List, Andrew Morton, stable

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

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [ 00/19] 3.10.1-stable review
  2013-07-14  2:22                         ` Theodore Ts'o
@ 2013-07-14  3:51                           ` Greg Kroah-Hartman
  2013-07-14  5:24                             ` Guenter Roeck
  0 siblings, 1 reply; 213+ messages in thread
From: Greg Kroah-Hartman @ 2013-07-14  3:51 UTC (permalink / raw)
  To: Theodore Ts'o, Willy Tarreau, Linus Torvalds, Guenter Roeck,
	Dave Jones, Linux Kernel Mailing List, Andrew Morton, stable

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

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [ 00/19] 3.10.1-stable review
  2013-07-14  3:51                           ` Greg Kroah-Hartman
@ 2013-07-14  5:24                             ` Guenter Roeck
  2013-07-14 20:31                               ` Geert Uytterhoeven
  0 siblings, 1 reply; 213+ messages in thread
From: Guenter Roeck @ 2013-07-14  5:24 UTC (permalink / raw)
  To: Greg Kroah-Hartman
  Cc: Theodore Ts'o, Willy Tarreau, Linus Torvalds, Dave Jones,
	Linux Kernel Mailing List, Andrew Morton, stable

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
> 

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [ 00/19] 3.10.1-stable review
  2013-07-14  5:24                             ` Guenter Roeck
@ 2013-07-14 20:31                               ` Geert Uytterhoeven
  0 siblings, 0 replies; 213+ messages in thread
From: Geert Uytterhoeven @ 2013-07-14 20:31 UTC (permalink / raw)
  To: Guenter Roeck
  Cc: Greg Kroah-Hartman, Theodore Ts'o, Willy Tarreau,
	Linus Torvalds, Dave Jones, Linux Kernel Mailing List,
	Andrew Morton, stable

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

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [ 00/19] 3.10.1-stable review
  2013-07-12 17:05                 ` Greg Kroah-Hartman
@ 2013-07-14 22:40                   ` Benjamin Herrenschmidt
  0 siblings, 0 replies; 213+ messages in thread
From: Benjamin Herrenschmidt @ 2013-07-14 22:40 UTC (permalink / raw)
  To: Greg Kroah-Hartman
  Cc: Josh Boyer, Ingo Molnar, Linus Torvalds, Steven Rostedt,
	Guenter Roeck, Dave Jones, Linux Kernel Mailing List,
	Andrew Morton, stable

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.



^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [ 00/19] 3.10.1-stable review
  2013-07-11 22:14 ` [ 00/19] 3.10.1-stable review Josh Boyer
@ 2013-07-14 22:54   ` Benjamin Herrenschmidt
  0 siblings, 0 replies; 213+ messages in thread
From: Benjamin Herrenschmidt @ 2013-07-14 22:54 UTC (permalink / raw)
  To: Josh Boyer
  Cc: Greg Kroah-Hartman, Linux-Kernel@Vger. Kernel. Org,
	Linus Torvalds, Andrew Morton, stable

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.



^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [ 00/19] 3.10.1-stable review
  2013-07-11 22:44   ` Greg Kroah-Hartman
  2013-07-12  1:51     ` Steven Rostedt
  2013-07-12 14:15     ` Guenter Roeck
@ 2013-07-14 22:58     ` Benjamin Herrenschmidt
  2 siblings, 0 replies; 213+ messages in thread
From: Benjamin Herrenschmidt @ 2013-07-14 22:58 UTC (permalink / raw)
  To: Greg Kroah-Hartman; +Cc: Dave Jones, linux-kernel, torvalds, akpm, stable

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.



^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [ 00/19] 3.10.1-stable review
  2013-07-11 22:01 [ 00/19] 3.10.1-stable review Greg Kroah-Hartman
                   ` (23 preceding siblings ...)
  2013-07-13  4:14 ` Satoru Takeuchi
@ 2013-07-14 23:06 ` Benjamin Herrenschmidt
  24 siblings, 0 replies; 213+ messages in thread
From: Benjamin Herrenschmidt @ 2013-07-14 23:06 UTC (permalink / raw)
  To: Greg Kroah-Hartman; +Cc: linux-kernel, torvalds, akpm, stable

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.



^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [ 00/19] 3.10.1-stable review
  2013-07-12 17:50           ` Linus Torvalds
  2013-07-12 18:11             ` Guenter Roeck
  2013-07-12 19:50             ` Willy Tarreau
@ 2013-07-14 23:52             ` Benjamin Herrenschmidt
  2013-07-15  1:40               ` Linus Torvalds
  2 siblings, 1 reply; 213+ messages in thread
From: Benjamin Herrenschmidt @ 2013-07-14 23:52 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Guenter Roeck, Greg Kroah-Hartman, Dave Jones,
	Linux Kernel Mailing List, Andrew Morton, stable

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.



^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [ 00/19] 3.10.1-stable review
  2013-07-14 23:52             ` Benjamin Herrenschmidt
@ 2013-07-15  1:40               ` Linus Torvalds
  2013-07-15  2:08                 ` Benjamin Herrenschmidt
  0 siblings, 1 reply; 213+ messages in thread
From: Linus Torvalds @ 2013-07-15  1:40 UTC (permalink / raw)
  To: Benjamin Herrenschmidt
  Cc: Guenter Roeck, Greg Kroah-Hartman, Dave Jones,
	Linux Kernel Mailing List, Andrew Morton, stable

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

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [ 00/19] 3.10.1-stable review
  2013-07-15  1:40               ` Linus Torvalds
@ 2013-07-15  2:08                 ` Benjamin Herrenschmidt
  0 siblings, 0 replies; 213+ messages in thread
From: Benjamin Herrenschmidt @ 2013-07-15  2:08 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Guenter Roeck, Greg Kroah-Hartman, Dave Jones,
	Linux Kernel Mailing List, Andrew Morton, stable

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.



^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [ 00/19] 3.10.1-stable review
  2013-07-13  7:12                     ` Willy Tarreau
@ 2013-07-15  4:12                       ` Li Zefan
  2013-07-15  4:43                         ` Willy Tarreau
  0 siblings, 1 reply; 213+ messages in thread
From: Li Zefan @ 2013-07-15  4:12 UTC (permalink / raw)
  To: Willy Tarreau
  Cc: Greg Kroah-Hartman, Linus Torvalds, Guenter Roeck, Dave Jones,
	Linux Kernel Mailing List, Andrew Morton, stable

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



^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: When to push bug fixes to mainline
  2013-07-12  3:25   ` Li Zefan
@ 2013-07-15  4:22     ` Rob Landley
  0 siblings, 0 replies; 213+ messages in thread
From: Rob Landley @ 2013-07-15  4:22 UTC (permalink / raw)
  To: Li Zefan
  Cc: Theodore Ts'o, Greg Kroah-Hartman, linux-kernel, torvalds,
	akpm, stable, ksummit-2013-discuss

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

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [ 00/19] 3.10.1-stable review
  2013-07-15  4:12                       ` Li Zefan
@ 2013-07-15  4:43                         ` Willy Tarreau
  0 siblings, 0 replies; 213+ messages in thread
From: Willy Tarreau @ 2013-07-15  4:43 UTC (permalink / raw)
  To: Li Zefan
  Cc: Greg Kroah-Hartman, Linus Torvalds, Guenter Roeck, Dave Jones,
	Linux Kernel Mailing List, Andrew Morton, stable

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


^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: When to push bug fixes to mainline
  2013-07-12  5:14   ` Willy Tarreau
@ 2013-07-16  7:19     ` David Lang
  2013-07-16 16:40       ` [Ksummit-2013-discuss] " Takashi Iwai
  2013-07-16 18:40       ` H. Peter Anvin
  0 siblings, 2 replies; 213+ messages in thread
From: David Lang @ 2013-07-16  7:19 UTC (permalink / raw)
  To: Willy Tarreau
  Cc: Theodore Ts'o, Greg Kroah-Hartman, linux-kernel, torvalds,
	akpm, stable, ksummit-2013-discuss

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

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [Ksummit-2013-discuss] When to push bug fixes to mainline
  2013-07-16  7:19     ` David Lang
@ 2013-07-16 16:40       ` Takashi Iwai
  2013-07-16 16:42         ` David Lang
                           ` (2 more replies)
  2013-07-16 18:40       ` H. Peter Anvin
  1 sibling, 3 replies; 213+ messages in thread
From: Takashi Iwai @ 2013-07-16 16:40 UTC (permalink / raw)
  To: David Lang
  Cc: Willy Tarreau, Greg Kroah-Hartman, linux-kernel, stable,
	ksummit-2013-discuss, torvalds

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

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [Ksummit-2013-discuss] When to push bug fixes to mainline
  2013-07-16 16:40       ` [Ksummit-2013-discuss] " Takashi Iwai
@ 2013-07-16 16:42         ` David Lang
  2013-07-16 19:29           ` Takashi Iwai
  2013-07-16 16:59         ` Mark Brown
  2013-07-16 18:39         ` Willy Tarreau
  2 siblings, 1 reply; 213+ messages in thread
From: David Lang @ 2013-07-16 16:42 UTC (permalink / raw)
  To: Takashi Iwai
  Cc: Willy Tarreau, Greg Kroah-Hartman, linux-kernel, stable,
	ksummit-2013-discuss, torvalds

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

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [Ksummit-2013-discuss] When to push bug fixes to mainline
  2013-07-16 16:40       ` [Ksummit-2013-discuss] " Takashi Iwai
  2013-07-16 16:42         ` David Lang
@ 2013-07-16 16:59         ` Mark Brown
  2013-07-16 17:58             ` Luck, Tony
  2013-07-16 18:39         ` Willy Tarreau
  2 siblings, 1 reply; 213+ messages in thread
From: Mark Brown @ 2013-07-16 16:59 UTC (permalink / raw)
  To: Takashi Iwai
  Cc: David Lang, ksummit-2013-discuss, Greg Kroah-Hartman,
	linux-kernel, stable, torvalds, Willy Tarreau

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

^ permalink raw reply	[flat|nested] 213+ messages in thread

* RE: [Ksummit-2013-discuss] When to push bug fixes to mainline
  2013-07-16 16:59         ` Mark Brown
@ 2013-07-16 17:58             ` Luck, Tony
  0 siblings, 0 replies; 213+ messages in thread
From: Luck, Tony @ 2013-07-16 17:58 UTC (permalink / raw)
  To: Mark Brown, Takashi Iwai
  Cc: David Lang, ksummit-2013-discuss, Greg Kroah-Hartman,
	linux-kernel, stable, torvalds, Willy Tarreau

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

^ permalink raw reply	[flat|nested] 213+ messages in thread

* RE: [Ksummit-2013-discuss] When to push bug fixes to mainline
@ 2013-07-16 17:58             ` Luck, Tony
  0 siblings, 0 replies; 213+ messages in thread
From: Luck, Tony @ 2013-07-16 17:58 UTC (permalink / raw)
  To: Mark Brown, Takashi Iwai
  Cc: David Lang, ksummit-2013-discuss, Greg Kroah-Hartman,
	linux-kernel, stable, torvalds, Willy Tarreau

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

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [Ksummit-2013-discuss] When to push bug fixes to mainline
  2013-07-16 17:58             ` Luck, Tony
@ 2013-07-16 18:29               ` Linus Torvalds
  -1 siblings, 0 replies; 213+ messages in thread
From: Linus Torvalds @ 2013-07-16 18:29 UTC (permalink / raw)
  To: Luck, Tony
  Cc: Mark Brown, Takashi Iwai, David Lang, ksummit-2013-discuss,
	Greg Kroah-Hartman, linux-kernel, stable, Willy Tarreau

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

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [Ksummit-2013-discuss] When to push bug fixes to mainline
@ 2013-07-16 18:29               ` Linus Torvalds
  0 siblings, 0 replies; 213+ messages in thread
From: Linus Torvalds @ 2013-07-16 18:29 UTC (permalink / raw)
  To: Luck, Tony
  Cc: Mark Brown, Takashi Iwai, David Lang, ksummit-2013-discuss,
	Greg Kroah-Hartman, linux-kernel, stable, Willy Tarreau

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

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [Ksummit-2013-discuss] When to push bug fixes to mainline
  2013-07-16 16:40       ` [Ksummit-2013-discuss] " Takashi Iwai
  2013-07-16 16:42         ` David Lang
  2013-07-16 16:59         ` Mark Brown
@ 2013-07-16 18:39         ` Willy Tarreau
  2 siblings, 0 replies; 213+ messages in thread
From: Willy Tarreau @ 2013-07-16 18:39 UTC (permalink / raw)
  To: Takashi Iwai
  Cc: David Lang, Greg Kroah-Hartman, linux-kernel, stable,
	ksummit-2013-discuss, torvalds

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


^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [Ksummit-2013-discuss] When to push bug fixes to mainline
  2013-07-16  7:19     ` David Lang
  2013-07-16 16:40       ` [Ksummit-2013-discuss] " Takashi Iwai
@ 2013-07-16 18:40       ` H. Peter Anvin
  2013-07-16 20:29         ` David Lang
  1 sibling, 1 reply; 213+ messages in thread
From: H. Peter Anvin @ 2013-07-16 18:40 UTC (permalink / raw)
  To: David Lang
  Cc: Willy Tarreau, Greg Kroah-Hartman, linux-kernel, stable,
	ksummit-2013-discuss, torvalds

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


^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [Ksummit-2013-discuss] When to push bug fixes to mainline
  2013-07-16 18:29               ` Linus Torvalds
@ 2013-07-16 18:41                 ` Steven Rostedt
  -1 siblings, 0 replies; 213+ messages in thread
From: Steven Rostedt @ 2013-07-16 18:41 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Luck, Tony, David Lang, ksummit-2013-discuss, Greg Kroah-Hartman,
	linux-kernel, stable, Willy Tarreau

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



^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [Ksummit-2013-discuss] When to push bug fixes to mainline
@ 2013-07-16 18:41                 ` Steven Rostedt
  0 siblings, 0 replies; 213+ messages in thread
From: Steven Rostedt @ 2013-07-16 18:41 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Luck, Tony, David Lang, ksummit-2013-discuss, Greg Kroah-Hartman,
	linux-kernel, stable, Willy Tarreau

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



^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [Ksummit-2013-discuss] When to push bug fixes to mainline
  2013-07-16 18:29               ` Linus Torvalds
@ 2013-07-16 18:48                 ` Willy Tarreau
  -1 siblings, 0 replies; 213+ messages in thread
From: Willy Tarreau @ 2013-07-16 18:48 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Luck, Tony, Mark Brown, Takashi Iwai, David Lang,
	ksummit-2013-discuss, Greg Kroah-Hartman, linux-kernel, stable

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


^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [Ksummit-2013-discuss] When to push bug fixes to mainline
@ 2013-07-16 18:48                 ` Willy Tarreau
  0 siblings, 0 replies; 213+ messages in thread
From: Willy Tarreau @ 2013-07-16 18:48 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Luck, Tony, Mark Brown, Takashi Iwai, David Lang,
	ksummit-2013-discuss, Greg Kroah-Hartman, linux-kernel, stable

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


^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [Ksummit-2013-discuss] When to push bug fixes to mainline
  2013-07-16 18:41                 ` Steven Rostedt
@ 2013-07-16 19:11                   ` Greg Kroah-Hartman
  -1 siblings, 0 replies; 213+ messages in thread
From: Greg Kroah-Hartman @ 2013-07-16 19:11 UTC (permalink / raw)
  To: Steven Rostedt
  Cc: Linus Torvalds, Luck, Tony, David Lang, ksummit-2013-discuss,
	linux-kernel, stable, Willy Tarreau

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

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [Ksummit-2013-discuss] When to push bug fixes to mainline
@ 2013-07-16 19:11                   ` Greg Kroah-Hartman
  0 siblings, 0 replies; 213+ messages in thread
From: Greg Kroah-Hartman @ 2013-07-16 19:11 UTC (permalink / raw)
  To: Steven Rostedt
  Cc: Linus Torvalds, Luck, Tony, David Lang, ksummit-2013-discuss,
	linux-kernel, stable, Willy Tarreau

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

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [Ksummit-2013-discuss] When to push bug fixes to mainline
  2013-07-16 16:42         ` David Lang
@ 2013-07-16 19:29           ` Takashi Iwai
  0 siblings, 0 replies; 213+ messages in thread
From: Takashi Iwai @ 2013-07-16 19:29 UTC (permalink / raw)
  To: David Lang
  Cc: Takashi Iwai, Willy Tarreau, Greg Kroah-Hartman, linux-kernel,
	stable, ksummit-2013-discuss, torvalds

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

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [Ksummit-2013-discuss] When to push bug fixes to mainline
  2013-07-16 19:11                   ` Greg Kroah-Hartman
@ 2013-07-16 19:43                     ` Steven Rostedt
  -1 siblings, 0 replies; 213+ messages in thread
From: Steven Rostedt @ 2013-07-16 19:43 UTC (permalink / raw)
  To: Greg Kroah-Hartman
  Cc: Linus Torvalds, Luck, Tony, David Lang, ksummit-2013-discuss,
	linux-kernel, stable, Willy Tarreau

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



^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [Ksummit-2013-discuss] When to push bug fixes to mainline
@ 2013-07-16 19:43                     ` Steven Rostedt
  0 siblings, 0 replies; 213+ messages in thread
From: Steven Rostedt @ 2013-07-16 19:43 UTC (permalink / raw)
  To: Greg Kroah-Hartman
  Cc: Linus Torvalds, Luck, Tony, David Lang, ksummit-2013-discuss,
	linux-kernel, stable, Willy Tarreau

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



^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [Ksummit-2013-discuss] When to push bug fixes to mainline
  2013-07-16 19:43                     ` Steven Rostedt
@ 2013-07-16 20:10                       ` Willy Tarreau
  -1 siblings, 0 replies; 213+ messages in thread
From: Willy Tarreau @ 2013-07-16 20:10 UTC (permalink / raw)
  To: Steven Rostedt
  Cc: Greg Kroah-Hartman, Linus Torvalds, Luck, Tony, David Lang,
	ksummit-2013-discuss, linux-kernel, stable

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


^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [Ksummit-2013-discuss] When to push bug fixes to mainline
@ 2013-07-16 20:10                       ` Willy Tarreau
  0 siblings, 0 replies; 213+ messages in thread
From: Willy Tarreau @ 2013-07-16 20:10 UTC (permalink / raw)
  To: Steven Rostedt
  Cc: Greg Kroah-Hartman, Linus Torvalds, Luck, Tony, David Lang,
	ksummit-2013-discuss, linux-kernel, stable

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


^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [Ksummit-2013-discuss] When to push bug fixes to mainline
  2013-07-16 18:40       ` H. Peter Anvin
@ 2013-07-16 20:29         ` David Lang
  0 siblings, 0 replies; 213+ messages in thread
From: David Lang @ 2013-07-16 20:29 UTC (permalink / raw)
  To: H. Peter Anvin
  Cc: Willy Tarreau, Greg Kroah-Hartman, linux-kernel, stable,
	ksummit-2013-discuss, torvalds

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

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [Ksummit-2013-discuss] When to push bug fixes to mainline
  2013-07-16 20:10                       ` Willy Tarreau
@ 2013-07-17  2:58                         ` Ben Hutchings
  -1 siblings, 0 replies; 213+ messages in thread
From: Ben Hutchings @ 2013-07-17  2:58 UTC (permalink / raw)
  To: Willy Tarreau
  Cc: Steven Rostedt, David Lang, ksummit-2013-discuss,
	Greg Kroah-Hartman, linux-kernel, stable, Linus Torvalds

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

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [Ksummit-2013-discuss] When to push bug fixes to mainline
@ 2013-07-17  2:58                         ` Ben Hutchings
  0 siblings, 0 replies; 213+ messages in thread
From: Ben Hutchings @ 2013-07-17  2:58 UTC (permalink / raw)
  To: Willy Tarreau
  Cc: Steven Rostedt, David Lang, ksummit-2013-discuss,
	Greg Kroah-Hartman, linux-kernel, stable, Linus Torvalds

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

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [Ksummit-2013-discuss] When to push bug fixes to mainline
  2013-07-16 20:10                       ` Willy Tarreau
@ 2013-07-17  9:43                         ` Li Zefan
  -1 siblings, 0 replies; 213+ messages in thread
From: Li Zefan @ 2013-07-17  9:43 UTC (permalink / raw)
  To: Willy Tarreau
  Cc: Steven Rostedt, David Lang, ksummit-2013-discuss,
	Greg Kroah-Hartman, linux-kernel, stable, Linus Torvalds

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.


^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [Ksummit-2013-discuss] When to push bug fixes to mainline
@ 2013-07-17  9:43                         ` Li Zefan
  0 siblings, 0 replies; 213+ messages in thread
From: Li Zefan @ 2013-07-17  9:43 UTC (permalink / raw)
  To: Willy Tarreau
  Cc: Steven Rostedt, David Lang, ksummit-2013-discuss,
	Greg Kroah-Hartman, linux-kernel, stable, Linus Torvalds

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.


^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [Ksummit-2013-discuss] When to push bug fixes to mainline
  2013-07-16 18:29               ` Linus Torvalds
@ 2013-07-19 10:13                 ` Ingo Molnar
  -1 siblings, 0 replies; 213+ messages in thread
From: Ingo Molnar @ 2013-07-19 10:13 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Luck, Tony, Mark Brown, Takashi Iwai, David Lang,
	ksummit-2013-discuss, Greg Kroah-Hartman, linux-kernel, stable,
	Willy Tarreau


* 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

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [Ksummit-2013-discuss] When to push bug fixes to mainline
@ 2013-07-19 10:13                 ` Ingo Molnar
  0 siblings, 0 replies; 213+ messages in thread
From: Ingo Molnar @ 2013-07-19 10:13 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Luck, Tony, Mark Brown, Takashi Iwai, David Lang,
	ksummit-2013-discuss, Greg Kroah-Hartman, linux-kernel, stable,
	Willy Tarreau


* 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

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [ 00/19] 3.10.1-stable review
  2013-07-15 19:53               ` Sarah Sharp
  2013-07-15 20:41                 ` Sarah Sharp
  2013-07-18  0:42                 ` Thomas Gleixner
@ 2013-07-24 10:43                 ` Florian Holz
  2 siblings, 0 replies; 213+ messages in thread
From: Florian Holz @ 2013-07-24 10:43 UTC (permalink / raw)
  To: Sarah Sharp
  Cc: Linus Torvalds, Ingo Molnar, Guenter Roeck, Greg Kroah-Hartman,
	Steven Rostedt, Dave Jones, Linux Kernel Mailing List

Hi,

just a short comment.

I think, this snippet shows the key point in this argument:

At 15.07.2013 21:53 CEST +02:00 Sarah Sharp wrote:
> Good lord.  So anyone that is one of your "top maintainers" could be
> exposed to your verbal abuse just because they "should have known
> better"?
> 
> You know what the definition of an abuser is?  Someone that seeks out
> victims that they know will "just take it" and keep the abuse "between
> the two of them".  They pick victims that won't fight back or report the
> abuse.
> 
Sarah introduced the term "abuse" like in the first paragraph into the
discussion while complaining about the tone in some statements. It's her
claim, that all non-"polite" statements are an "abuse".

In the second paragraph, then she argues that "abuse" should be
prevented, using some definition of "abuse".

The claim that the unwanted kind of statements are really a kind of
abuse is still unfounded. She could have proven it -- eg by using
its/her/a definition -- but she only used this definition as foundation
to dislike the non-"polite" statements.

Imho this is just circular reasoning [1]
> (I) dislike -> (I regard as) impolite -> kind of abuse -> to be disliked (by all)
and so has no substance up to now. Maybe, logical package management
would have recognized this unmet dependency ;)

Disclaimer:
I dont' question the implication "abuse -> to be disliked".

Flo

[1] https://en.wikipedia.org/wiki/Circular_reasoning

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [ 00/19] 3.10.1-stable review
  2013-07-15 15:52 Sarah Sharp
                   ` (2 preceding siblings ...)
  2013-07-15 19:04 ` Rob Landley
@ 2013-07-23  8:26 ` Rogelio Serrano
  3 siblings, 0 replies; 213+ messages in thread
From: Rogelio Serrano @ 2013-07-23  8:26 UTC (permalink / raw)
  To: Sarah Sharp
  Cc: Linus Torvalds, Ingo Molnar, Guenter Roeck, Greg Kroah-Hartman,
	Steven Rostedt, Dave Jones, Linux Kernel Mailing List,
	Andrew Morton, stable, Darren Hart

Hi Sarah,

kinda reminds me of... baboons... its natural among mammals i guess...

Why hierarchy creates a destructive force within the human psyche (by
dr. Robert Sapolsky)
http://www.youtube.com/watch?v=A4UMyTnlaMY&feature=share


On Mon, Jul 15, 2013 at 11:52 PM, Sarah Sharp
<sarah.a.sharp@linux.intel.com> wrote:
> On Fri, 12 Jul 2013 18:17:08 +0200, 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!
>
> On Fri, 12 Jul 2013 08:22:27 -0700, Linus wrote:
>> 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.
>
> Seriously, guys?  Is this what we need in order to get improve -stable?
> Linus Torvalds is advocating for physical intimidation and violence.
> Ingo Molnar and Linus are advocating for verbal abuse.
>
> Not *fucking* cool.  Violence, whether it be physical intimidation,
> verbal threats or verbal abuse is not acceptable.  Keep it professional
> on the mailing lists.
>
> Let's discuss this at Kernel Summit where we can at least yell at each
> other in person.  Yeah, just try yelling at me about this.  I'll roar
> right back, louder, for all the people who lose their voice when they
> get yelled at by top maintainers.  I won't be the nice girl anymore.
>
> Sarah Sharp
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [ 00/19] 3.10.1-stable review
  2013-07-23  3:43 ` Mike Galbraith
  2013-07-23  4:16   ` Regina Obe
@ 2013-07-23  4:49   ` Regina Obe
  1 sibling, 0 replies; 213+ messages in thread
From: Regina Obe @ 2013-07-23  4:49 UTC (permalink / raw)
  To: Mike Galbraith; +Cc: linux-kernel

Mike,

I do want to partially apologize to Sarah for my first email.  That
was really much tongue in cheek to express what happens when things
get too polite
and professional and hope she wasn't too offended.  I saw Sarah's last post
http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg471360.html

and see she's changed her tune a bit which is a lot more agreeable to
me and I suspect others.

However I still thinks she's a little bit too pendantic to the point
of being really annoying and seeming like she's memorized the book of
conduct quoting things like  "

The book "No Assholes Rule" cites research that shows only 1% of
subordinates bully their superiors"

and is ready to throw it in peoples faces if they infringe on the rules.
Those rules are way too long to follow.  Why can't you guys just trust
your insticts and if you are relaly worried about Linus -- just make
it a rule "If anybody thinks X is acting as a jerk at this very moment
-- call it out"

Honestly do yo guys even have time to read 20 pages of what is and
ISN'T and insult. I also suspect the public viewers aren't going to be
looking up at an Org Chart "Hmm let me check if Linus is allowed to
insult this guy :) "

When you are at the party since she's probably going to miss this note
because its on a dead thread if you could convey my sentiments.

Thanks,
Regina

^ permalink raw reply	[flat|nested] 213+ messages in thread

* RE: [ 00/19] 3.10.1-stable review
  2013-07-23  3:43 ` Mike Galbraith
@ 2013-07-23  4:16   ` Regina Obe
  2013-07-23  4:49   ` Regina Obe
  1 sibling, 0 replies; 213+ messages in thread
From: Regina Obe @ 2013-07-23  4:16 UTC (permalink / raw)
  To: 'Mike Galbraith'; +Cc: 'linux-kernel'



> Which means you're likely not invited to the annual mud-wrestling and toga
party where this topic has been scheduled for further discussion.
> This thread and its offspring have been declared dead on LKML, we're in
kernel development mode again.

> -Mike

That's okay.  Just wanted to express my comments.

Regina


^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [ 00/19] 3.10.1-stable review
  2013-07-23  1:42 Regina Obe
@ 2013-07-23  3:43 ` Mike Galbraith
  2013-07-23  4:16   ` Regina Obe
  2013-07-23  4:49   ` Regina Obe
  0 siblings, 2 replies; 213+ messages in thread
From: Mike Galbraith @ 2013-07-23  3:43 UTC (permalink / raw)
  To: Regina Obe; +Cc: linux-kernel

On Mon, 2013-07-22 at 21:42 -0400, Regina Obe wrote:

> Linus,
> I want to start off by saying, though I'm mostly a windows developer,

Which means you're likely not invited to the annual mud-wrestling and
toga party where this topic has been scheduled for further discussion.
This thread and its offspring have been declared dead on LKML, we're in
kernel development mode again.

-Mike


^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [ 00/19] 3.10.1-stable review
@ 2013-07-23  1:42 Regina Obe
  2013-07-23  3:43 ` Mike Galbraith
  0 siblings, 1 reply; 213+ messages in thread
From: Regina Obe @ 2013-07-23  1:42 UTC (permalink / raw)
  To: linux-kernel

I wanted to take Sarah up on her offer to pay my respects for the
great work she is doing to bring civility to the LKLM community
as detailed in http://marc.info/?l=linux-kernel&m=137390362508794

Linus,
I want to start off by saying, though I'm mostly a windows developer,
I've gained a whole new level of appreciation for you, with the very
professional
way you have handled Sarah's pleas for civility and professionalism. I
hope you don't think of "professionalism" and "civility" as dirty
words, because I certainly did not mean it that way.
I have tried to express my own feelings in the most professional and
civil way I could
muster in this article
http://www.postgresonline.com/journal/archives/311-In-defense-of-being-blunt-and-to-the-point.html
.

I want to first say that while Sarah does not speak for me, and I
suspect she does not speak for all minorities, females, and the poor
down-trodden developers
in your ranks that have had their feelings torn apart by your less
than kind words, I do still appreciate her great efforts to bring
civility to LKML. You go girl, Sarah -- keep fighting the good fight,
we are with you - both men and women. I do hope your efforts do not
make it difficult for women to distinguish criticism from platitudes.

Perhaps some day, Sarah, your dream will come true and you can be a
top tier committer as you stated in your moving up the career rank
comment.
http://sarah.thesharps.us/2013/07/15/no-more-verbal-abuse/#comments

You won't even have to work for it, because Linus will be so scared of you
he'll just hand it over to you and accept any patch you give him.

Please don't take my above statement as an accusation that that is
what you are doing.  That is not at all what I meant.  I just meant to
say that if you wanted to exercise that
option, you are in a good position to. Consider it just my suggested
career advice just like the wonderful career advice you have given to
other women in your blog
http://sarah.thesharps.us/2013/06/23/dont-be-a-jerk/ .

I do have one final request. If you do succeed in your quest for
civility and professionalism,  please do try to keep the office
politics where they belong, in the office.
I'd still like to think there is still some semblance of openness
after you are done with your restructuring.

I want to thank you one more time for the great work you have done
bringing this GREAT INJUSTICE to our attention. I certainly would not
have discovered it without all the great accolades you have won for
this from both men and women
http://www.wired.co.uk/news/archive/2013-07/22/sarah-sharp . You must
be some kind of wonder woman. I am so very very appreciative that
there is a woman out there willing to stand up to Linus verbal abuse
and fight for those who are too afraid to stand up for themselves.

You are just SO *fucking* cool.

YOU GO GIRL SARAH.

Thanks,
Regina Obe

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [ 00/19] 3.10.1-stable review
  2013-07-16  2:01                     ` Joe Perches
@ 2013-07-21  4:15                       ` Rob Landley
  0 siblings, 0 replies; 213+ messages in thread
From: Rob Landley @ 2013-07-21  4:15 UTC (permalink / raw)
  To: Joe Perches
  Cc: NeilBrown, Steven Rostedt, J. Bruce Fields, Linus Torvalds,
	Sarah Sharp, Ingo Molnar, Guenter Roeck, Greg Kroah-Hartman,
	Dave Jones, Linux Kernel Mailing List, Andrew Morton, stable,
	Darren Hart

On 07/15/2013 09:01:56 PM, Joe Perches wrote:
> On Tue, 2013-07-16 at 11:54 +1000, NeilBrown wrote:
> > On Mon, 15 Jul 2013 16:50:52 -0700 Joe Perches <joe@perches.com>  
> wrote:
> >
> > > On Tue, 2013-07-16 at 09:42 +1000, NeilBrown wrote:
> > > > Being "polite" without being "nice" is quite possible.
> > > > It even has a name:  Diplomacy.
> > >
> > > And we all know how circular/indirect/implied/useless
> > > some of those diplomatic conversations can be.
> > >
> > > Just remember to bring a 'Big Stick' and don't be shy
> > > when it's necessary to display it.
> >
> > The behaviour you appear to be advocating is what is generally  
> called
> > "bullying".
> 
> Nope.  It's called not being a pushover and being
> direct, clear and not just being unnecessarily forceful.

Linux-kernel is an _epicially_ self-selected group.

I expect the vast majority of people would be on Neil's side of this  
argument, not Joe's. But they've already walked away, and are not  
coming back.

Rob

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [ 00/19] 3.10.1-stable review
  2013-07-15 19:04 ` Rob Landley
@ 2013-07-19 11:25   ` Ingo Molnar
  0 siblings, 0 replies; 213+ messages in thread
From: Ingo Molnar @ 2013-07-19 11:25 UTC (permalink / raw)
  To: Rob Landley
  Cc: Sarah Sharp, Linus Torvalds, Guenter Roeck, Greg Kroah-Hartman,
	Steven Rostedt, Dave Jones, Linux Kernel Mailing List,
	Andrew Morton, stable, Darren Hart


* Rob Landley <rob@landley.net> wrote:

> On 07/15/2013 10:52:48 AM, Sarah Sharp wrote:
> >On Fri, 12 Jul 2013 18:17:08 +0200, Ingo Molnar <mingo@kernel.org>
> >wrote:
> >> * Linus Torvalds <torvalds@linux-foundation.org> wrote:
> >Let's discuss this at Kernel Summit where we can at least yell at each
> >other in person.  Yeah, just try yelling at me about this.  I'll roar
> >right back, louder, for all the people who lose their voice when they
> >get yelled at by top maintainers.  I won't be the nice girl anymore.
> 
> Not _all_ of us lose our voice when yelled at by Linus's lieutenants. 
> Some of us just post updates to the same darn patch series for 5 years 
> (yes really; my perl removal series started in 2008 and was applied 
> earlier this year), on the theory it's useful to the people actually 
> applying it to their own trees (at one point, gentoo), and that someday 
> the stars might be right and cthulu will arise from the deep and accept 
> the patch series into his tree. (Or in my case, Andrew Morton.)

I think part of the root cause was that kbuild maintainership changed 
several times over the years and nobody really felt strongly enough about 
the Perl removal series.

Despite best efforts there will always be long-lived Linux forks: the 
-rt/PREEMPT_RT kernel is meanwhile nearly a decade old now... :-/

Thanks,

	Ingo

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [ 00/19] 3.10.1-stable review
  2013-07-17  5:22                           ` Sarah Sharp
@ 2013-07-19 11:10                             ` Ingo Molnar
  0 siblings, 0 replies; 213+ messages in thread
From: Ingo Molnar @ 2013-07-19 11:10 UTC (permalink / raw)
  To: Sarah Sharp
  Cc: Linus Torvalds, Rafael J. Wysocki, Rusty Russell, Willy Tarreau,
	Guenter Roeck, Greg Kroah-Hartman, Steven Rostedt, Dave Jones,
	Linux Kernel Mailing List, Andrew Morton, stable, Darren Hart,
	Mauro Carvalho Chehab


* Sarah Sharp <sarah.a.sharp@linux.intel.com> wrote:

> On Tue, Jul 16, 2013 at 03:12:45PM -0700, Linus Torvalds wrote:
> > I react very strongly when somebody argues against fixing regressions.
> > Let's just say that there's too many years of baggage that I carry
> > around on that issue..
> > 
> > So that is definitely one of the things that make me go ballistic.
> > Buggy code isn't actually one of them. Bugs happen. Even really stupid
> > bugs happen, and happen to good people. They had a bad day, or it was
> > just a brainfart.  Not that I will be _polite_ about bad code, mind
> > you, and there might be some bad words in there, but it doesn't make
> > me blow up.
> > 
> > Being cavalier about known regressions is definitely the primary
> > trigger. I suspect there are others, but I can't seem to recall any
> > other particular hot-button issues right now. Maybe Sarah can post a
> > few more pointers..
> 
> Hmm... The only thing I can think of off the top of my head is that you 
> tend to hate it when someone puts the needs of their particular 
> architecture or distro at a higher priority than the needs of the kernel 
> community.  If they start to push crap code late in the merge window to 
> further their personal goals, you tend to blow up at them.  See the 
> 'deep throat' comment on the PE binary signing thread, for instance.
> 
> The timing of when incidents happen also seems to effect whether you get 
> triggered.  I suspect most of the incidents of you "blowing up" at 
> people happen during the merge window.

Of course timing matters:

 - there are times when a bad pull request can have worse effects, such as 
   shortly before -rc1 or shortly before -final - when many people will be 
   exposed to a new kernel for the first time.

 - timing can also sometimes show a certain level of dishonesty on the 
   developer's side: trying to slip in a bad tree near the end of the 
   merge window, before people can complain it ...

 - there are times when Linus naturally more vulnerable to not having 
   enough time to think things through: such as when he is pulling a dozen 
   trees per day, during the merge window.

Dishonesty, bad timing, running a bad Git flow and making irreversible ABI 
mistakes [of which refusing to fix app regressions is one sort] are all 
hot button issues for Linus, and it's a pretty natural list I think: 
because they are the least actionable, most persistent and thus riskiest 
"meta" problems possible in a kernel project.

Some of Linus's "worst" flames had two or more of these hot button issues 
mixed together. Sometimes a maintainer can get away with a mistake (most 
likely Linus does not notice the mistake) but in general it's all pretty 
consistent.

All in one, with all due respect, I don't think your complaints voiced so 
far against Linus have much merit :-/ I think you'll experience it first 
hand once you become a top level maintainer.

Having said that, I do share your concern that women are more offput by 
the widespread 'manly' talk on lkml: LKML is filled with testosterone. I 
think your solution to create a separate culture is a good one - and 
eventually the two cultures will counter-balance each other in a good way 
and will maybe merge. I cannot think of a better solution either, and I 
fully support your efforts: it's one of the big unsolved problems of Linux 
kernel development.

Thanks,

	Ingo

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [ 00/19] 3.10.1-stable review
  2013-07-18 15:48                   ` Sarah Sharp
@ 2013-07-19 10:35                     ` Ingo Molnar
  0 siblings, 0 replies; 213+ messages in thread
From: Ingo Molnar @ 2013-07-19 10:35 UTC (permalink / raw)
  To: Sarah Sharp
  Cc: Thomas Gleixner, Linus Torvalds, Guenter Roeck,
	Greg Kroah-Hartman, Steven Rostedt, Dave Jones,
	Linux Kernel Mailing List, Andrew Morton, stable, Darren Hart,
	Hohndel, Dirk


* Sarah Sharp <sarah.a.sharp@linux.intel.com> wrote:

> On Thu, Jul 18, 2013 at 02:42:16AM +0200, Thomas Gleixner wrote:
> > If you can point me to a single instance of Linus "abusing" someone
> > who is not one of his trusted persons, who really should be able to
> > deal with that, or someone who did not provoke him to go into rant
> > mode, then I'm all on your side.
> 
> Not that I think this link will sway you, and this thread *should*
> really die down so we can discuss this at KS instead:
> 
> https://plus.google.com/+LinusTorvalds/posts/1vyfmNCYpi5
> 
> "So here's a plea: if you have anything to do with security in a distro,
> and think that my kids (replace "my kids" with "sales people on the
> road" if you think your main customers are businesses) need to have the
> root password to access some wireless network, or to be able to print
> out a paper, or to change the date-and-time settings, please just kill
> yourself now. The world will be a better place."
> 
> Linus asked someone to go kill themselves. [...]

No, he did not.

He, as he declared it in the first stentences of his post, was venting and 
cursing:

   Venting.

   I don't think I can talk about "security" people without cursing, so
   you might want to avert your eyes now.

I'm, as the author of several security patches, partly a distro "security 
person" too, and I was not offended, I took away the message from Linus:

don't "fix" perceived security threats by cumbersome security measures, 
because users will address that by creating even larger security threats:

   http://www.merseyworld.com/precinct/Apr99/prec8.html

Thanks,

	Ingo

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [ 00/19] 3.10.1-stable review
  2013-07-18 16:07                       ` Sarah Sharp
  2013-07-18 16:16                         ` Steven Rostedt
@ 2013-07-18 17:39                         ` Felipe Contreras
  1 sibling, 0 replies; 213+ messages in thread
From: Felipe Contreras @ 2013-07-18 17:39 UTC (permalink / raw)
  To: Sarah Sharp
  Cc: Ingo Molnar, Linus Torvalds, Guenter Roeck, Greg Kroah-Hartman,
	Steven Rostedt, Dave Jones, Linux Kernel Mailing List,
	Andrew Morton, stable, Darren Hart, Rusty Russell

On Thu, Jul 18, 2013 at 11:07 AM, Sarah Sharp
<sarah.a.sharp@linux.intel.com> wrote:

> To me, being "professional" means treating each other with respect.

Respect is earned, not automatic, and can be lost. A common mistake in
our modern society is to think that everyone deserves respect; they
don't.

We should tolerate each other, not respect each other.

-- 
Felipe Contreras

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [ 00/19] 3.10.1-stable review
  2013-07-18 16:07                       ` Sarah Sharp
@ 2013-07-18 16:16                         ` Steven Rostedt
  2013-07-18 17:39                         ` Felipe Contreras
  1 sibling, 0 replies; 213+ messages in thread
From: Steven Rostedt @ 2013-07-18 16:16 UTC (permalink / raw)
  To: Sarah Sharp
  Cc: Ingo Molnar, Linus Torvalds, Guenter Roeck, Greg Kroah-Hartman,
	Dave Jones, Linux Kernel Mailing List, Andrew Morton, stable,
	Darren Hart, Rusty Russell

On Thu, 2013-07-18 at 09:07 -0700, Sarah Sharp wrote:

> The following statement is not respectful, because it targets the
> person:
> 
> "Seriously, Maintainer.  Why are you pushing this kind of *crap* code to
> me again?  Why the hell did you mark it for stable when it's clearly
> not a bug fix?  Did you even try to f*cking compile this?"

No it does not target the person at all. It targets what the person
*did*.

"Why are you *pushing* this ..."
"Why the hell *did* you mark it..."
"*Did* you even try to ..."

See, it's all about the fact that the person did something stupid, and
they are being called out on it. It is not any more of an attack on the
person as the one attacking the code.

But we can discuss this in more detail at KS.

-- Steve



^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [ 00/19] 3.10.1-stable review
  2013-07-18 10:39                     ` Ingo Molnar
  2013-07-18 14:32                       ` J. Bruce Fields
@ 2013-07-18 16:07                       ` Sarah Sharp
  2013-07-18 16:16                         ` Steven Rostedt
  2013-07-18 17:39                         ` Felipe Contreras
  1 sibling, 2 replies; 213+ messages in thread
From: Sarah Sharp @ 2013-07-18 16:07 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Linus Torvalds, Guenter Roeck, Greg Kroah-Hartman,
	Steven Rostedt, Dave Jones, Linux Kernel Mailing List,
	Andrew Morton, stable, Darren Hart, Rusty Russell

On Thu, Jul 18, 2013 at 12:39:07PM +0200, Ingo Molnar wrote:
> 
> * Linus Torvalds <torvalds@linux-foundation.org> wrote:
> 
> > On Mon, Jul 15, 2013 at 1:41 PM, Sarah Sharp
> > <sarah.a.sharp@linux.intel.com> wrote:
> > >
> > > Oh, FFS, I just called out on private email for "playing the victim
> > > card".  I will repeat: this is not just about me, or other minorities.
> > > I should not have to ask for professional behavior on the mailing lists.
> > > Professional behavior should be the default.
> > 
> 
> > [...]
> > 
> > Because if you want me to "act professional", I can tell you that I'm 
> > not interested. I'm sitting in my home office wearign a bathrobe. The 
> > same way I'm not going to start wearing ties, I'm *also* not going to 
> > buy into the fake politeness, the lying, the office politics and 
> > backstabbing, the passive aggressiveness, and the buzzwords. Because 
> > THAT is what "acting professionally" results in: people resort to all 
> > kinds of really nasty things because they are forced to act out their 
> > normal urges in unnatural ways.
> 
> Sarah, that's a pretty potent argument by Linus, that "acting 
> professionally" risks replacing a raw but honest culture with a
> polished but dishonest culture - which is harmful to developing
> good technology.
> 
> That's a valid concern. What's your reply to that argument?

I don't feel the need to comment, because I feel it's a straw man
argument.  I feel that way because I disagree with the definition of
professionalism that people have been pushing.

To me, being "professional" means treating each other with respect.  I
can show emotion, express displeasure, be direct, and still show respect
for my fellow developers.

For example, I find the following statement to be both direct and
respectful, because it's criticizing code, not the person:

"This code is SHIT!  It adds new warnings and it's marked for stable
when it's clearly *crap code* that's not a bug fix.  I'm going to revert
this merge, and I expect a fix from you IMMEDIATELY."

The following statement is not respectful, because it targets the
person:

"Seriously, Maintainer.  Why are you pushing this kind of *crap* code to
me again?  Why the hell did you mark it for stable when it's clearly
not a bug fix?  Did you even try to f*cking compile this?"

I would appreciate it if people would replace the word "professional"
with "respectful" in this thread.  It means something different to me
than other people, and respect is much closer to what I'm looking for.

I would appreciate it if kernel developers would show respect for each
other, while focusing on criticizing code.  As Rusty said, be gentle
with people.  You've called their baby ugly.

Sarah Sharp

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [ 00/19] 3.10.1-stable review
  2013-07-18  0:42                 ` Thomas Gleixner
  2013-07-18  3:16                   ` CAI Qian
@ 2013-07-18 15:48                   ` Sarah Sharp
  2013-07-19 10:35                     ` Ingo Molnar
  1 sibling, 1 reply; 213+ messages in thread
From: Sarah Sharp @ 2013-07-18 15:48 UTC (permalink / raw)
  To: Thomas Gleixner, Linus Torvalds
  Cc: Ingo Molnar, Guenter Roeck, Greg Kroah-Hartman, Steven Rostedt,
	Dave Jones, Linux Kernel Mailing List, Andrew Morton, stable,
	Darren Hart, Hohndel, Dirk

On Thu, Jul 18, 2013 at 02:42:16AM +0200, Thomas Gleixner wrote:
> If you can point me to a single instance of Linus "abusing" someone
> who is not one of his trusted persons, who really should be able to
> deal with that, or someone who did not provoke him to go into rant
> mode, then I'm all on your side.

Not that I think this link will sway you, and this thread *should*
really die down so we can discuss this at KS instead:

https://plus.google.com/+LinusTorvalds/posts/1vyfmNCYpi5

"So here's a plea: if you have anything to do with security in a distro,
and think that my kids (replace "my kids" with "sales people on the
road" if you think your main customers are businesses) need to have the
root password to access some wireless network, or to be able to print
out a paper, or to change the date-and-time settings, please just kill
yourself now. The world will be a better place."

Linus asked someone to go kill themselves.  That someone was anyone
involved in distro security, specifically OpenSuse.  I think that
qualifies as "not one of his trusted persons".  I'll leave it up to you
whether you think that statement was justified or civil.

I don't think someone in a position of power should be encouraging
developers to commit suicide, even if they did make a mistake.  The
Portland open source community has already had to deal with two
developer suicides this year (Igal Koshevoy and Matthew):

http://stumptownsyndicate.org/2013/04/09/goodbye-igal/

I personally don't want to be responsible for anyone else contemplating
suicide, even because of an obviously sarcastic "joke".  I don't joke
about suicide.  I would appreciate it if other developers refrained from
joking about it as well.

Sarah Sharp

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [ 00/19] 3.10.1-stable review
  2013-07-18 10:39                     ` Ingo Molnar
@ 2013-07-18 14:32                       ` J. Bruce Fields
  2013-07-18 16:07                       ` Sarah Sharp
  1 sibling, 0 replies; 213+ messages in thread
From: J. Bruce Fields @ 2013-07-18 14:32 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Sarah Sharp, Linus Torvalds, Guenter Roeck, Greg Kroah-Hartman,
	Steven Rostedt, Dave Jones, Linux Kernel Mailing List,
	Andrew Morton, stable, Darren Hart

On Thu, Jul 18, 2013 at 12:39:07PM +0200, Ingo Molnar wrote:
> 
> * Linus Torvalds <torvalds@linux-foundation.org> wrote:
...
> > Because if you want me to "act professional", I can tell you that I'm 
> > not interested. I'm sitting in my home office wearign a bathrobe. The 
> > same way I'm not going to start wearing ties, I'm *also* not going to 
> > buy into the fake politeness, the lying, the office politics and 
> > backstabbing, the passive aggressiveness, and the buzzwords. Because 
> > THAT is what "acting professionally" results in: people resort to all 
> > kinds of really nasty things because they are forced to act out their 
> > normal urges in unnatural ways.
> 
> Sarah, that's a pretty potent argument by Linus, that "acting 
> professionally" risks replacing a raw but honest culture with a
> polished but dishonest culture - which is harmful to developing
> good technology.
> 
> That's a valid concern. What's your reply to that argument?

First they came for my "WTF!?!"'s, then before I knew it the only way I
could explain a simple integer-overflow problem involved
anonymously-mailed copies of K&R and subtle hint-dropping to
half-a-dozen managers!

I'm not convinced by the slippery-slope argument here.  

Speaking just for myself, yeah, I'd be happier with less yelling all
around.  I'd be even more unhappy to lose the clear, direct criticism.
(And the colorful personalities, too.  I don't see why anyone needs to
be bland.) I think that's a consistent position.

--b.

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [ 00/19] 3.10.1-stable review
  2013-07-18  4:01                       ` CAI Qian
  2013-07-18  5:03                         ` H. Peter Anvin
  2013-07-18 11:35                         ` Steven Rostedt
@ 2013-07-18 13:23                         ` Theodore Ts'o
  2 siblings, 0 replies; 213+ messages in thread
From: Theodore Ts'o @ 2013-07-18 13:23 UTC (permalink / raw)
  To: CAI Qian
  Cc: Steven Rostedt, Thomas Gleixner, Sarah Sharp, Linus Torvalds,
	Ingo Molnar, Guenter Roeck, Greg Kroah-Hartman, Dave Jones,
	Linux Kernel Mailing List, Andrew Morton, stable, Darren Hart

On Thu, Jul 18, 2013 at 12:01:18AM -0400, CAI Qian wrote:
> > > Could victim be someone else in the future since it is an example that
> > > people may follow?

Is Nik Wallenda an abuser because he walked across the Grand Canyon on
a tightrope without a safety net, and that's an example that other
people might follow (and fail at)?  Seriously, the argument that
someone are responsible for the actions and decisions of others is a
pretty weak one.

> > > http://en.wikipedia.org/wiki/Silvio_Berlusconi_underage_prostitution_charges
> > > It called "abuse of office" or abuse of the power.
> > 
> > Wow! You are now comparing Linus to a Prime Minister that has paid
> > underage prostitutes for sex?
> I apologize that this leads to misunderstanding. It was just happened to
> read the news that underage child does not feel like she is a victim
> either while the law still think that is an abuse.

Please show us the law which states that the language a coach might
use to his team players is "abuse".

And I think one of the big differences here is that there is a
gargantuan power differential between the Italian Prime Minister and
an underage prostitute.  The power differential between Linus and his
top subsystem maintainers?  Not so much.  Linus does not have hiring
and firing power over us, and since he works at a non-profit which
doesn't have stock options or a profit sharing agreement, he may be
making less money than compared to some of his top lieutenants.

So I'd suggest that people who are flinging around words like "abuse"
stop.  It's not helping your case, because it's not an accurate
description of what's going on.  Even if you believe that it really is
abuse, from a tactical point of view, do you think telling subsystem
maintainers (who have maintained that they do not feel personally
attack, and do not feel abused), that they are too stupid to realize
that they are really hapless victims is likely to make them listen to
your point of view?

There are much stronger arguments that can be made for more "civility".

Regards,

						- Ted

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [ 00/19] 3.10.1-stable review
  2013-07-18  4:01                       ` CAI Qian
  2013-07-18  5:03                         ` H. Peter Anvin
@ 2013-07-18 11:35                         ` Steven Rostedt
  2013-07-18 13:23                         ` Theodore Ts'o
  2 siblings, 0 replies; 213+ messages in thread
From: Steven Rostedt @ 2013-07-18 11:35 UTC (permalink / raw)
  To: CAI Qian
  Cc: Thomas Gleixner, Sarah Sharp, Linus Torvalds, Ingo Molnar,
	Guenter Roeck, Greg Kroah-Hartman, Dave Jones,
	Linux Kernel Mailing List, Andrew Morton, stable, Darren Hart

On Thu, 2013-07-18 at 00:01 -0400, CAI Qian wrote:
>  
> > > > So if you talk about abuse, then you need an abuser and a victim. So
> > > > your argumentation falls flat because there is no victim.
> > > Could victim be someone else in the future since it is an example that
> > > people may follow?
> > > http://en.wikipedia.org/wiki/Silvio_Berlusconi_underage_prostitution_charges
> > > It called "abuse of office" or abuse of the power.
> > 
> > Wow! You are now comparing Linus to a Prime Minister that has paid
> > underage prostitutes for sex?
> I apologize that this leads to misunderstanding. It was just happened to
> read the news that underage child does not feel like she is a victim
> either while the law still think that is an abuse. Another example, those
> BBC child abusers took ages to track down that probably because those
> children did not feel victims at that time either. 
> 
> Please don't get me wrong. I did neither compare Linus to those child abusers
> nor Thomas to those children. I simply pointed out there is also some common
> sense need to consider.

That story had nothing to do with this thread. "Abuse of power" is to
use ones power for personal gain, whether it be monetary or sexual.
Linus is not getting anything out of yelling at people (OK, it lets of
steam). Linus's yelling is a management style, nothing more.

-- Steve



^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [ 00/19] 3.10.1-stable review
  2013-07-15 21:50                   ` Linus Torvalds
@ 2013-07-18 10:39                     ` Ingo Molnar
  2013-07-18 14:32                       ` J. Bruce Fields
  2013-07-18 16:07                       ` Sarah Sharp
  0 siblings, 2 replies; 213+ messages in thread
From: Ingo Molnar @ 2013-07-18 10:39 UTC (permalink / raw)
  To: Sarah Sharp
  Cc: Linus Torvalds, Guenter Roeck, Greg Kroah-Hartman,
	Steven Rostedt, Dave Jones, Linux Kernel Mailing List,
	Andrew Morton, stable, Darren Hart


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

> On Mon, Jul 15, 2013 at 1:41 PM, Sarah Sharp
> <sarah.a.sharp@linux.intel.com> wrote:
> >
> > Oh, FFS, I just called out on private email for "playing the victim
> > card".  I will repeat: this is not just about me, or other minorities.
> > I should not have to ask for professional behavior on the mailing lists.
> > Professional behavior should be the default.
> 

> [...]
> 
> Because if you want me to "act professional", I can tell you that I'm 
> not interested. I'm sitting in my home office wearign a bathrobe. The 
> same way I'm not going to start wearing ties, I'm *also* not going to 
> buy into the fake politeness, the lying, the office politics and 
> backstabbing, the passive aggressiveness, and the buzzwords. Because 
> THAT is what "acting professionally" results in: people resort to all 
> kinds of really nasty things because they are forced to act out their 
> normal urges in unnatural ways.

Sarah, that's a pretty potent argument by Linus, that "acting 
professionally" risks replacing a raw but honest culture with a
polished but dishonest culture - which is harmful to developing
good technology.

That's a valid concern. What's your reply to that argument?

Thanks,

	Ingo

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [ 00/19] 3.10.1-stable review
  2013-07-18  6:06                           ` CAI Qian
@ 2013-07-18 10:21                             ` Ingo Molnar
  0 siblings, 0 replies; 213+ messages in thread
From: Ingo Molnar @ 2013-07-18 10:21 UTC (permalink / raw)
  To: CAI Qian
  Cc: H. Peter Anvin, Steven Rostedt, Thomas Gleixner, Sarah Sharp,
	Linus Torvalds, Guenter Roeck, Greg Kroah-Hartman, Dave Jones,
	Linux Kernel Mailing List, Andrew Morton, stable, Darren Hart


* CAI Qian <caiqian@redhat.com> wrote:

> > On 07/17/2013, CAI Qian wrote:
> > > 
> > > On 07/17/2013, CAI Qian wrote:
> > > > >
> > > > > Could victim be someone else in the future since it is an 
> > > > > example that people may follow?
> > > > >
> > > > > http://en.wikipedia.org/wiki/Silvio_Berlusconi_underage_prostitution_charges
> > > > >
> > > > > It called "abuse of office" or abuse of the power.
> > > > >
[...]
> > >
> > > Please don't get me wrong. I did neither compare Linus to those 
> > > child abusers nor Thomas to those children. I simply pointed out 
> > > there is also some common sense need to consider.
> > >
> > 
> > Actually, you did.
>
> I am sorry to mislead you feeling that way, hpa.

I think you are demonstrating the disutility of passive-aggressive 
communication patterns pretty nicely, making our point in essence.

Thanks,

	Ingo

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [ 00/19] 3.10.1-stable review
  2013-07-18  5:03                         ` H. Peter Anvin
@ 2013-07-18  6:06                           ` CAI Qian
  2013-07-18 10:21                             ` Ingo Molnar
  0 siblings, 1 reply; 213+ messages in thread
From: CAI Qian @ 2013-07-18  6:06 UTC (permalink / raw)
  To: H. Peter Anvin
  Cc: Steven Rostedt, Thomas Gleixner, Sarah Sharp, Linus Torvalds,
	Ingo Molnar, Guenter Roeck, Greg Kroah-Hartman, Dave Jones,
	Linux Kernel Mailing List, Andrew Morton, stable, Darren Hart



----- 原始邮件 -----
> 发件人: "H. Peter Anvin" <hpa@zytor.com>
> 收件人: "CAI Qian" <caiqian@redhat.com>
> 抄送: "Steven Rostedt" <rostedt@goodmis.org>, "Thomas Gleixner" <tglx@linutronix.de>, "Sarah Sharp"
> <sarah.a.sharp@linux.intel.com>, "Linus Torvalds" <torvalds@linux-foundation.org>, "Ingo Molnar" <mingo@kernel.org>,
> "Guenter Roeck" <linux@roeck-us.net>, "Greg Kroah-Hartman" <gregkh@linuxfoundation.org>, "Dave Jones"
> <davej@redhat.com>, "Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>, "Andrew Morton"
> <akpm@linux-foundation.org>, "stable" <stable@vger.kernel.org>, "Darren Hart" <dvhart@linux.intel.com>
> 发送时间: 星期四, 2013年 7 月 18日 下午 1:03:41
> 主题: Re: [ 00/19] 3.10.1-stable review
> 
> On 07/17/2013 09:01 PM, CAI Qian wrote:
> > 
> > Please don't get me wrong. I did neither compare Linus to those child
> > abusers
> > nor Thomas to those children. I simply pointed out there is also some
> > common
> > sense need to consider.
> >
> 
> Actually, you did.
I am sorry to mislead you feeling that way, hpa.
> 
> 	-hpa
> 
> 
> 
> --
> 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
> 

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [ 00/19] 3.10.1-stable review
  2013-07-18  4:01                       ` CAI Qian
@ 2013-07-18  5:03                         ` H. Peter Anvin
  2013-07-18  6:06                           ` CAI Qian
  2013-07-18 11:35                         ` Steven Rostedt
  2013-07-18 13:23                         ` Theodore Ts'o
  2 siblings, 1 reply; 213+ messages in thread
From: H. Peter Anvin @ 2013-07-18  5:03 UTC (permalink / raw)
  To: CAI Qian
  Cc: Steven Rostedt, Thomas Gleixner, Sarah Sharp, Linus Torvalds,
	Ingo Molnar, Guenter Roeck, Greg Kroah-Hartman, Dave Jones,
	Linux Kernel Mailing List, Andrew Morton, stable, Darren Hart

On 07/17/2013 09:01 PM, CAI Qian wrote:
> 
> Please don't get me wrong. I did neither compare Linus to those child abusers
> nor Thomas to those children. I simply pointed out there is also some common
> sense need to consider.
>

Actually, you did.

	-hpa




^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [ 00/19] 3.10.1-stable review
  2013-07-18  3:47                     ` Steven Rostedt
  2013-07-18  4:01                       ` CAI Qian
@ 2013-07-18  4:15                       ` CAI Qian
  1 sibling, 0 replies; 213+ messages in thread
From: CAI Qian @ 2013-07-18  4:15 UTC (permalink / raw)
  To: Steven Rostedt
  Cc: Thomas Gleixner, Sarah Sharp, Linus Torvalds, Ingo Molnar,
	Guenter Roeck, Greg Kroah-Hartman, Dave Jones,
	Linux Kernel Mailing List, Andrew Morton, stable, Darren Hart



----- Original Message -----
> From: "Steven Rostedt" <rostedt@goodmis.org>
> To: "CAI Qian" <caiqian@redhat.com>
> Cc: "Thomas Gleixner" <tglx@linutronix.de>, "Sarah Sharp" <sarah.a.sharp@linux.intel.com>, "Linus Torvalds"
> <torvalds@linux-foundation.org>, "Ingo Molnar" <mingo@kernel.org>, "Guenter Roeck" <linux@roeck-us.net>, "Greg
> Kroah-Hartman" <gregkh@linuxfoundation.org>, "Dave Jones" <davej@redhat.com>, "Linux Kernel Mailing List"
> <linux-kernel@vger.kernel.org>, "Andrew Morton" <akpm@linux-foundation.org>, "stable" <stable@vger.kernel.org>,
> "Darren Hart" <dvhart@linux.intel.com>
> Sent: Thursday, July 18, 2013 11:47:34 AM
> Subject: Re: [ 00/19] 3.10.1-stable review
> 
> On Wed, 2013-07-17 at 23:16 -0400, CAI Qian wrote:
> 
> > > So if you talk about abuse, then you need an abuser and a victim. So
> > > your argumentation falls flat because there is no victim.
> > Could victim be someone else in the future since it is an example that
> > people may follow?
> > http://en.wikipedia.org/wiki/Silvio_Berlusconi_underage_prostitution_charges
> > It called "abuse of office" or abuse of the power.
> 
> Wow! You are now comparing Linus to a Prime Minister that has paid
> underage prostitutes for sex?
> 
> That's pretty low.
> 
> What Linus does is not an abuse of power, it's a protection of his baby.
> He created Linux, and although today he's not the one writing the code,
> he is ultimately the front man responsible for the kernel.
Surely Linus has great responsibility, but isn't that every powerful person/organizatio
could tell the same story? Berlusconi has a country to take care of; Jimmy Savile has a
television kingdom to manage; NSA needs to protect world peace etc.
> 
> Think about it. If Linux does something horrible, Linus is the one that
> takes the most blame. That's a HUGE responsibility. Linus has the most
> to lose if Linux becomes crap.
> 
> Not only does Linus have to check on code, he must also dictate policy.
> Which means dealing with different people, and how they work. If someone
> gets lazy and uses his trust to get something whacky in, Linus takes the
> blame for it if that happens. Thus, to prevent people from taking
> advantage of his trust, he has to be hard on them to make sure he can
> keep their trust.
> 
> Linus takes his job seriously. He may joke and name his kernel after
> 90's operating systems, but that's just to make the job more fun. But to
> keep the job, he needs to be a hard ass.
> 
> The few times he's yelled at me, he always did it with a bit of comedy
> and wit. That makes the harsh yelling not so bad, and I actually got a
> chuckle out of it. But I also took the harsh yelling in a way that I had
> better not do that again.
> 
> This is the big leagues folks. You think major league baseball managers
> are nice to their players?
> 
> "You just walked 4 players. That's not good. Keep this up I'll have to
> take you out off the team".
> 
>   vs
> 
> "What the f*ck is wrong with you. Get you head out of your @ss and start
> throwing the ball over the God damn plate before I throw your @ss out of
> this field!"
> 
> They both relay basically the same thing. The first one is nice and
> polite but states that bad things will happen if they keep it up. The
> second is quite harsh (although never calling the person a name), and
> will probably wake the person up and change his game. Which one of those
> tones do you think successful baseball managers use?
> 
> Sometimes tone *does* matter. You want quality from the top maintainers,
> and they start to slack, you can't just treat them like this is a grade
> school sport. Results matter. You want them to understand that this is
> serious and cursing someone out gives that person that feeling.
> 
> -- Steve
> 
> 
> --
> 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
> 

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [ 00/19] 3.10.1-stable review
  2013-07-18  3:47                     ` Steven Rostedt
@ 2013-07-18  4:01                       ` CAI Qian
  2013-07-18  5:03                         ` H. Peter Anvin
                                           ` (2 more replies)
  2013-07-18  4:15                       ` CAI Qian
  1 sibling, 3 replies; 213+ messages in thread
From: CAI Qian @ 2013-07-18  4:01 UTC (permalink / raw)
  To: Steven Rostedt
  Cc: Thomas Gleixner, Sarah Sharp, Linus Torvalds, Ingo Molnar,
	Guenter Roeck, Greg Kroah-Hartman, Dave Jones,
	Linux Kernel Mailing List, Andrew Morton, stable, Darren Hart



----- Original Message -----
> From: "Steven Rostedt" <rostedt@goodmis.org>
> To: "CAI Qian" <caiqian@redhat.com>
> Cc: "Thomas Gleixner" <tglx@linutronix.de>, "Sarah Sharp" <sarah.a.sharp@linux.intel.com>, "Linus Torvalds"
> <torvalds@linux-foundation.org>, "Ingo Molnar" <mingo@kernel.org>, "Guenter Roeck" <linux@roeck-us.net>, "Greg
> Kroah-Hartman" <gregkh@linuxfoundation.org>, "Dave Jones" <davej@redhat.com>, "Linux Kernel Mailing List"
> <linux-kernel@vger.kernel.org>, "Andrew Morton" <akpm@linux-foundation.org>, "stable" <stable@vger.kernel.org>,
> "Darren Hart" <dvhart@linux.intel.com>
> Sent: Thursday, July 18, 2013 11:47:34 AM
> Subject: Re: [ 00/19] 3.10.1-stable review
> 
> On Wed, 2013-07-17 at 23:16 -0400, CAI Qian wrote:
> 
> > > So if you talk about abuse, then you need an abuser and a victim. So
> > > your argumentation falls flat because there is no victim.
> > Could victim be someone else in the future since it is an example that
> > people may follow?
> > http://en.wikipedia.org/wiki/Silvio_Berlusconi_underage_prostitution_charges
> > It called "abuse of office" or abuse of the power.
> 
> Wow! You are now comparing Linus to a Prime Minister that has paid
> underage prostitutes for sex?
I apologize that this leads to misunderstanding. It was just happened to
read the news that underage child does not feel like she is a victim
either while the law still think that is an abuse. Another example, those
BBC child abusers took ages to track down that probably because those
children did not feel victims at that time either. 

Please don't get me wrong. I did neither compare Linus to those child abusers
nor Thomas to those children. I simply pointed out there is also some common
sense need to consider.
> 
> That's pretty low.
> 
> What Linus does is not an abuse of power, it's a protection of his baby.
> He created Linux, and although today he's not the one writing the code,
> he is ultimately the front man responsible for the kernel.
> 
> Think about it. If Linux does something horrible, Linus is the one that
> takes the most blame. That's a HUGE responsibility. Linus has the most
> to lose if Linux becomes crap.
> 
> Not only does Linus have to check on code, he must also dictate policy.
> Which means dealing with different people, and how they work. If someone
> gets lazy and uses his trust to get something whacky in, Linus takes the
> blame for it if that happens. Thus, to prevent people from taking
> advantage of his trust, he has to be hard on them to make sure he can
> keep their trust.
> 
> Linus takes his job seriously. He may joke and name his kernel after
> 90's operating systems, but that's just to make the job more fun. But to
> keep the job, he needs to be a hard ass.
> 
> The few times he's yelled at me, he always did it with a bit of comedy
> and wit. That makes the harsh yelling not so bad, and I actually got a
> chuckle out of it. But I also took the harsh yelling in a way that I had
> better not do that again.
> 
> This is the big leagues folks. You think major league baseball managers
> are nice to their players?
> 
> "You just walked 4 players. That's not good. Keep this up I'll have to
> take you out off the team".
> 
>   vs
> 
> "What the f*ck is wrong with you. Get you head out of your @ss and start
> throwing the ball over the God damn plate before I throw your @ss out of
> this field!"
> 
> They both relay basically the same thing. The first one is nice and
> polite but states that bad things will happen if they keep it up. The
> second is quite harsh (although never calling the person a name), and
> will probably wake the person up and change his game. Which one of those
> tones do you think successful baseball managers use?
> 
> Sometimes tone *does* matter. You want quality from the top maintainers,
> and they start to slack, you can't just treat them like this is a grade
> school sport. Results matter. You want them to understand that this is
> serious and cursing someone out gives that person that feeling.
> 
> -- Steve
> 
> 
> 

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [ 00/19] 3.10.1-stable review
@ 2013-07-18  3:50 George Spelvin
  0 siblings, 0 replies; 213+ messages in thread
From: George Spelvin @ 2013-07-18  3:50 UTC (permalink / raw)
  To: tglx; +Cc: linux, linux-kernel, sarah.a.sharp

> If you can point me to a single instance of Linus "abusing" someone
> who is not one of his trusted persons, who really should be able to
> deal with that, or someone who did not provoke him to go into rant
> mode, then I'm all on your side.

Well, the one that comes to mind is Alan Cox and the TTY driver in
2009.

And I still have to agree with his point about Linus's more absolute
pronouncements on user-space regressions: taken literally, they mean
that breaking rootkits is not okay.

Here's the thread if anyonw would like to judge "who started it":

http://marc.info/?t=124870111900001


That said, I strongly agree with this point:
> Linus simply has to trusts his top level maintainers, because he
> cannot review, audit and check 10k patches which flow into his tree
> every merge window himself.
>
> So if he finds out that someone who has his ultimate trust sends him a
> pile of crap, he tells that person in his own unmisunderstandable way
> that he's not amused.

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [ 00/19] 3.10.1-stable review
  2013-07-18  3:16                   ` CAI Qian
@ 2013-07-18  3:47                     ` Steven Rostedt
  2013-07-18  4:01                       ` CAI Qian
  2013-07-18  4:15                       ` CAI Qian
  0 siblings, 2 replies; 213+ messages in thread
From: Steven Rostedt @ 2013-07-18  3:47 UTC (permalink / raw)
  To: CAI Qian
  Cc: Thomas Gleixner, Sarah Sharp, Linus Torvalds, Ingo Molnar,
	Guenter Roeck, Greg Kroah-Hartman, Dave Jones,
	Linux Kernel Mailing List, Andrew Morton, stable, Darren Hart

On Wed, 2013-07-17 at 23:16 -0400, CAI Qian wrote:

> > So if you talk about abuse, then you need an abuser and a victim. So
> > your argumentation falls flat because there is no victim.
> Could victim be someone else in the future since it is an example that
> people may follow?
> http://en.wikipedia.org/wiki/Silvio_Berlusconi_underage_prostitution_charges
> It called "abuse of office" or abuse of the power.

Wow! You are now comparing Linus to a Prime Minister that has paid
underage prostitutes for sex?

That's pretty low.

What Linus does is not an abuse of power, it's a protection of his baby.
He created Linux, and although today he's not the one writing the code,
he is ultimately the front man responsible for the kernel.

Think about it. If Linux does something horrible, Linus is the one that
takes the most blame. That's a HUGE responsibility. Linus has the most
to lose if Linux becomes crap.

Not only does Linus have to check on code, he must also dictate policy.
Which means dealing with different people, and how they work. If someone
gets lazy and uses his trust to get something whacky in, Linus takes the
blame for it if that happens. Thus, to prevent people from taking
advantage of his trust, he has to be hard on them to make sure he can
keep their trust.

Linus takes his job seriously. He may joke and name his kernel after
90's operating systems, but that's just to make the job more fun. But to
keep the job, he needs to be a hard ass.

The few times he's yelled at me, he always did it with a bit of comedy
and wit. That makes the harsh yelling not so bad, and I actually got a
chuckle out of it. But I also took the harsh yelling in a way that I had
better not do that again.

This is the big leagues folks. You think major league baseball managers
are nice to their players?

"You just walked 4 players. That's not good. Keep this up I'll have to
take you out off the team".

  vs

"What the f*ck is wrong with you. Get you head out of your @ss and start
throwing the ball over the God damn plate before I throw your @ss out of
this field!"

They both relay basically the same thing. The first one is nice and
polite but states that bad things will happen if they keep it up. The
second is quite harsh (although never calling the person a name), and
will probably wake the person up and change his game. Which one of those
tones do you think successful baseball managers use?

Sometimes tone *does* matter. You want quality from the top maintainers,
and they start to slack, you can't just treat them like this is a grade
school sport. Results matter. You want them to understand that this is
serious and cursing someone out gives that person that feeling.

-- Steve



^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [ 00/19] 3.10.1-stable review
  2013-07-18  0:42                 ` Thomas Gleixner
@ 2013-07-18  3:16                   ` CAI Qian
  2013-07-18  3:47                     ` Steven Rostedt
  2013-07-18 15:48                   ` Sarah Sharp
  1 sibling, 1 reply; 213+ messages in thread
From: CAI Qian @ 2013-07-18  3:16 UTC (permalink / raw)
  To: Thomas Gleixner
  Cc: Sarah Sharp, Linus Torvalds, Ingo Molnar, Guenter Roeck,
	Greg Kroah-Hartman, Steven Rostedt, Dave Jones,
	Linux Kernel Mailing List, Andrew Morton, stable, Darren Hart



----- Original Message -----
> From: "Thomas Gleixner" <tglx@linutronix.de>
> To: "Sarah Sharp" <sarah.a.sharp@linux.intel.com>
> Cc: "Linus Torvalds" <torvalds@linux-foundation.org>, "Ingo Molnar" <mingo@kernel.org>, "Guenter Roeck"
> <linux@roeck-us.net>, "Greg Kroah-Hartman" <gregkh@linuxfoundation.org>, "Steven Rostedt" <rostedt@goodmis.org>,
> "Dave Jones" <davej@redhat.com>, "Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>, "Andrew Morton"
> <akpm@linux-foundation.org>, "stable" <stable@vger.kernel.org>, "Darren Hart" <dvhart@linux.intel.com>
> Sent: Thursday, July 18, 2013 8:42:16 AM
> Subject: Re: [ 00/19] 3.10.1-stable review
> 
> On Mon, 15 Jul 2013, Sarah Sharp wrote:
> > On Mon, Jul 15, 2013 at 12:07:56PM -0700, Linus Torvalds wrote:
> > > On Mon, Jul 15, 2013 at 11:46 AM, Sarah Sharp
> > > <sarah.a.sharp@linux.intel.com> wrote:
> > > >
> > > > Bullshit.  I've seen you be polite, and explain to clueless maintainers
> > > > why there's no way you can revert their merge that caused regressions,
> > > > and ask them to fit it without resorting to tearing them down
> > > > emotionally:
> > > 
> > > Oh, I'll be polite when it's called for.
> > > 
> > > But when people who know better send me crap, I'll curse at them.
> > > 
> > > I suspect you'll notice me cursing *way* more at top developers than
> > > random people on the list. I expect more from them, and conversely
> > > I'll be a lot more upset when they do something that I really think
> > > was not great.
> > > 
> > > For example, my latest cursing explosion was for the x86 maintainers,
> > > and it comes from the fact that I *know* they know to do better. The
> > > x86 tip pulls have generally been through way more testing than most
> > > other pulls I get (not just compiling, but even booting randconfigs
> > > etc). So when an x86 pull request comes in that clearly missed that
> > > expected level of quality, I go to town.
> > >
> > Good lord.  So anyone that is one of your "top maintainers" could be
> > exposed to your verbal abuse just because they "should have known
> > better"?
> 
> I'm one of the "victims" of Linus' latest "verbal abuse". :)
>  
> Just for the record. I got grilled by Linus several times over the
> last years and I can't remember a single instance where it was
> unjustified. When I see such a mail in my inbox, I know that I fucked
> up royally and all I do is to figure out what I broke this time and
> fix it. I don't give a rat's ass about his "abusive" language. See
> below.
> 
> > exposed to your verbal abuse just because they "should have known
> > better"?
> 
> You know what "should have known better" stands for?
> 
>     It stands for violating trust.
> 
> Linus simply has to trusts his top level maintainers, because he
> cannot review, audit and check 10k patches which flow into his tree
> every merge window himself.
> 
> So if he finds out that someone who has his ultimate trust sends him a
> pile of crap, he tells that person in his own unmisunderstandable way
> that he's not amused.
> 
> > You know what the definition of an abuser is?  Someone that seeks out
> > victims that they know will "just take it" and keep the abuse "between
> > the two of them".  They pick victims that won't fight back or report the
> > abuse.
> 
> IOW, I'm a typical victim of abuse.
> 
> Let me clarify that.
> 
> The person who gets away with picking me for this kind of abuse has
> not been born yet. And Linus knows very well, that he gets the full
> pack back from me (in some different form of "abusive language") if he
> yelled at me for no reason. It's documented out there including his
> apologies.
> 
> So if you talk about abuse, then you need an abuser and a victim. So
> your argumentation falls flat because there is no victim.
Could victim be someone else in the future since it is an example that
people may follow?
http://en.wikipedia.org/wiki/Silvio_Berlusconi_underage_prostitution_charges
It called "abuse of office" or abuse of the power.
> 
> I do not care about his swear words and rants at all, because I know
> that it makes him feel better.
> 
>      That's a cultural thing.
> 
> Where I grew up it's part of the culture to explode, let off steam and
> then go and have a beer together. I strongly believe this prevents
> gastric ulcer and keeps you honest. Linus and I have this kind of
> relationship. We respect each other, we trust each other and when one
> side fucks up we yell at each other and then meet at the bar for a
> drink.
> 
> Linus did NOT abuse me in his latest rant. He simply told me in a very
> strong language that he's grumpy because I violated his trust. And
> that's legitimate. It's also legitimate to do that in public because
> it documents that the top level maintainers are not impeccable. And it
> sets a clear expectation bar for those who want to become maintainers
> of any level.
> 
> Aside of that I completely agree with Linus, that this policital
> correctness crusades are merily creating more subtle and hard to fight
> forms of real abuse.
> 
> I observe that every other day in big corporates, which have written
> down code of conducts and a gazillion of rules for interaction; they
> just foster dishonesty and other fallacies.
> 
> I really prefer the honest slap from Linus than dealing with people
> who signed and "comply" to some code of conduct and stab you in your
> back wherever they can.
> 
> If you can point me to a single instance of Linus "abusing" someone
> who is not one of his trusted persons, who really should be able to
> deal with that, or someone who did not provoke him to go into rant
> mode, then I'm all on your side.
> 
> Aside of that, I agree that Linus could achieve the same effect by
> using a different (more palatable to you) language, but that's a
> different story.
> 
> 
> Thanks,
> 
> 	tglx
> --
> 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
> 

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [ 00/19] 3.10.1-stable review
  2013-07-15 19:53               ` Sarah Sharp
  2013-07-15 20:41                 ` Sarah Sharp
@ 2013-07-18  0:42                 ` Thomas Gleixner
  2013-07-18  3:16                   ` CAI Qian
  2013-07-18 15:48                   ` Sarah Sharp
  2013-07-24 10:43                 ` Florian Holz
  2 siblings, 2 replies; 213+ messages in thread
From: Thomas Gleixner @ 2013-07-18  0:42 UTC (permalink / raw)
  To: Sarah Sharp
  Cc: Linus Torvalds, Ingo Molnar, Guenter Roeck, Greg Kroah-Hartman,
	Steven Rostedt, Dave Jones, Linux Kernel Mailing List,
	Andrew Morton, stable, Darren Hart

On Mon, 15 Jul 2013, Sarah Sharp wrote:
> On Mon, Jul 15, 2013 at 12:07:56PM -0700, Linus Torvalds wrote:
> > On Mon, Jul 15, 2013 at 11:46 AM, Sarah Sharp
> > <sarah.a.sharp@linux.intel.com> wrote:
> > >
> > > Bullshit.  I've seen you be polite, and explain to clueless maintainers
> > > why there's no way you can revert their merge that caused regressions,
> > > and ask them to fit it without resorting to tearing them down
> > > emotionally:
> > 
> > Oh, I'll be polite when it's called for.
> > 
> > But when people who know better send me crap, I'll curse at them.
> > 
> > I suspect you'll notice me cursing *way* more at top developers than
> > random people on the list. I expect more from them, and conversely
> > I'll be a lot more upset when they do something that I really think
> > was not great.
> > 
> > For example, my latest cursing explosion was for the x86 maintainers,
> > and it comes from the fact that I *know* they know to do better. The
> > x86 tip pulls have generally been through way more testing than most
> > other pulls I get (not just compiling, but even booting randconfigs
> > etc). So when an x86 pull request comes in that clearly missed that
> > expected level of quality, I go to town.
> >
> Good lord.  So anyone that is one of your "top maintainers" could be
> exposed to your verbal abuse just because they "should have known
> better"?

I'm one of the "victims" of Linus' latest "verbal abuse". :)
 
Just for the record. I got grilled by Linus several times over the
last years and I can't remember a single instance where it was
unjustified. When I see such a mail in my inbox, I know that I fucked
up royally and all I do is to figure out what I broke this time and
fix it. I don't give a rat's ass about his "abusive" language. See
below.

> exposed to your verbal abuse just because they "should have known
> better"?

You know what "should have known better" stands for?

    It stands for violating trust.

Linus simply has to trusts his top level maintainers, because he
cannot review, audit and check 10k patches which flow into his tree
every merge window himself.

So if he finds out that someone who has his ultimate trust sends him a
pile of crap, he tells that person in his own unmisunderstandable way
that he's not amused.

> You know what the definition of an abuser is?  Someone that seeks out
> victims that they know will "just take it" and keep the abuse "between
> the two of them".  They pick victims that won't fight back or report the
> abuse.

IOW, I'm a typical victim of abuse.

Let me clarify that.

The person who gets away with picking me for this kind of abuse has
not been born yet. And Linus knows very well, that he gets the full
pack back from me (in some different form of "abusive language") if he
yelled at me for no reason. It's documented out there including his
apologies.

So if you talk about abuse, then you need an abuser and a victim. So
your argumentation falls flat because there is no victim.

I do not care about his swear words and rants at all, because I know
that it makes him feel better.

     That's a cultural thing.

Where I grew up it's part of the culture to explode, let off steam and
then go and have a beer together. I strongly believe this prevents
gastric ulcer and keeps you honest. Linus and I have this kind of
relationship. We respect each other, we trust each other and when one
side fucks up we yell at each other and then meet at the bar for a
drink.

Linus did NOT abuse me in his latest rant. He simply told me in a very
strong language that he's grumpy because I violated his trust. And
that's legitimate. It's also legitimate to do that in public because
it documents that the top level maintainers are not impeccable. And it
sets a clear expectation bar for those who want to become maintainers
of any level.

Aside of that I completely agree with Linus, that this policital
correctness crusades are merily creating more subtle and hard to fight
forms of real abuse.

I observe that every other day in big corporates, which have written
down code of conducts and a gazillion of rules for interaction; they
just foster dishonesty and other fallacies.

I really prefer the honest slap from Linus than dealing with people
who signed and "comply" to some code of conduct and stab you in your
back wherever they can.

If you can point me to a single instance of Linus "abusing" someone
who is not one of his trusted persons, who really should be able to
deal with that, or someone who did not provoke him to go into rant
mode, then I'm all on your side.

Aside of that, I agree that Linus could achieve the same effect by
using a different (more palatable to you) language, but that's a
different story.


Thanks,

	tglx

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [ 00/19] 3.10.1-stable review
  2013-07-15 18:17         ` Linus Torvalds
  2013-07-15 18:46           ` Sarah Sharp
  2013-07-15 19:05           ` J. Bruce Fields
@ 2013-07-17  8:39           ` Janne Karhunen
  2 siblings, 0 replies; 213+ messages in thread
From: Janne Karhunen @ 2013-07-17  8:39 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: Linux Kernel Mailing List

On Mon, Jul 15, 2013 at 9:17 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:

>
> Google "management by perkele".

Actually, not even our former president mr. Kekkonen never went quite
as far using this method. I think something along the lines of
legendary 'saatanan tunarit' would suffice next time :)


--
Janne

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [ 00/19] 3.10.1-stable review
  2013-07-15 23:50                 ` Joe Perches
  2013-07-16  1:54                   ` NeilBrown
@ 2013-07-17  7:01                   ` CAI Qian
  1 sibling, 0 replies; 213+ messages in thread
From: CAI Qian @ 2013-07-17  7:01 UTC (permalink / raw)
  To: Joe Perches
  Cc: NeilBrown, Steven Rostedt, J. Bruce Fields, Linus Torvalds,
	Sarah Sharp, Ingo Molnar, Guenter Roeck, Greg Kroah-Hartman,
	Dave Jones, Linux Kernel Mailing List, Andrew Morton, stable,
	Darren Hart



----- Original Message -----
> From: "Joe Perches" <joe@perches.com>
> To: "NeilBrown" <neilb@suse.de>
> Cc: "Steven Rostedt" <rostedt@goodmis.org>, "J. Bruce Fields" <bfields@fieldses.org>, "Linus Torvalds"
> <torvalds@linux-foundation.org>, "Sarah Sharp" <sarah.a.sharp@linux.intel.com>, "Ingo Molnar" <mingo@kernel.org>,
> "Guenter Roeck" <linux@roeck-us.net>, "Greg Kroah-Hartman" <gregkh@linuxfoundation.org>, "Dave Jones"
> <davej@redhat.com>, "Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>, "Andrew Morton"
> <akpm@linux-foundation.org>, "stable" <stable@vger.kernel.org>, "Darren Hart" <dvhart@linux.intel.com>
> Sent: Tuesday, July 16, 2013 7:50:52 AM
> Subject: Re: [ 00/19] 3.10.1-stable review
> 
> On Tue, 2013-07-16 at 09:42 +1000, NeilBrown wrote:
> > Being "polite" without being "nice" is quite possible.
> > It even has a name:  Diplomacy.
> 
> And we all know how circular/indirect/implied/useless
> some of those diplomatic conversations can be.
Modern human is more diplomatic than ancient barbarians. Will the trend
continue?
> 
> Just remember to bring a 'Big Stick' and don't be shy
> when it's necessary to display it.
> 
> --
> 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
> 

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [ 00/19] 3.10.1-stable review
  2013-07-16 22:12                         ` Linus Torvalds
@ 2013-07-17  5:22                           ` Sarah Sharp
  2013-07-19 11:10                             ` Ingo Molnar
  0 siblings, 1 reply; 213+ messages in thread
From: Sarah Sharp @ 2013-07-17  5:22 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Rafael J. Wysocki, Rusty Russell, Willy Tarreau, Ingo Molnar,
	Guenter Roeck, Greg Kroah-Hartman, Steven Rostedt, Dave Jones,
	Linux Kernel Mailing List, Andrew Morton, stable, Darren Hart,
	Mauro Carvalho Chehab

On Tue, Jul 16, 2013 at 03:12:45PM -0700, Linus Torvalds wrote:
> I react very strongly when somebody argues against fixing regressions.
> Let's just say that there's too many years of baggage that I carry
> around on that issue..
> 
> So that is definitely one of the things that make me go ballistic.
> Buggy code isn't actually one of them. Bugs happen. Even really stupid
> bugs happen, and happen to good people. They had a bad day, or it was
> just a brainfart.  Not that I will be _polite_ about bad code, mind
> you, and there might be some bad words in there, but it doesn't make
> me blow up.
> 
> Being cavalier about known regressions is definitely the primary
> trigger. I suspect there are others, but I can't seem to recall any
> other particular hot-button issues right now. Maybe Sarah can post a
> few more pointers..

Hmm... The only thing I can think of off the top of my head is that you
tend to hate it when someone puts the needs of their particular
architecture or distro at a higher priority than the needs of the kernel
community.  If they start to push crap code late in the merge window to
further their personal goals, you tend to blow up at them.  See the
'deep throat' comment on the PE binary signing thread, for instance.

The timing of when incidents happen also seems to effect whether you get
triggered.  I suspect most of the incidents of you "blowing up" at
people happen during the merge window.

Sarah Sharp

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [ 00/19] 3.10.1-stable review
  2013-07-17  1:37                       ` Linus Torvalds
  2013-07-17  1:54                         ` Steven Rostedt
@ 2013-07-17  3:28                         ` Darren Hart
  1 sibling, 0 replies; 213+ messages in thread
From: Darren Hart @ 2013-07-17  3:28 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Rusty Russell, Sarah Sharp, Willy Tarreau, Ingo Molnar,
	Guenter Roeck, Greg Kroah-Hartman, Steven Rostedt, Dave Jones,
	Linux Kernel Mailing List, Andrew Morton, stable,
	Mauro Carvalho Chehab, Rafael J. Wysocki

On Tue, 2013-07-16 at 18:37 -0700, Linus Torvalds wrote:
> On Tue, Jul 16, 2013 at 6:02 PM, Rusty Russell <rusty@rustcorp.com.au> wrote:
> >>
> >> "Mauro, SHUT THE FUCK UP!"
> >
> > This one crosses the line.  There's no non-offensive way to tell a geek
> > "you are wrong", but this isn't even trying.  Bad Linus!
> 
> You know what? Not my proudest moment. I was really upset.

This goes a long way to resolving the stated issues in my opinion. Of
the three issues raised, Linus has either adequately justified himself
or conceded. This wasn't meant to be Linus on trial was it? :-)

I'm sure we could dig up a thousand more references of "bad" behavior
from others on LKML. Before we do let's first make sure the recipient is
not being "resistant to education" (a phrase I've picked up from Thomas
Gleixner and like very much) or has somehow provoked things. Ted Ts'o
will recall fondly all the pigs in guinea *smirk*.

I enjoy a good rant as much as anyone, but I recognize personal attacks
can be very harmful to the individual and possibly (difficult to prove)
the quality of the project. This is especially true when coming from
someone that is held in very high regard, such as Linus and the other
maintainers.

I think the one tangible TODO that has come out of this is to DOCUMENT
expectations. Paul Gortmaker has already submitted a netdev FAQ which I
have reviewed and David Miller approved of. I have committed to review
stable_kernel_rules. It appears there is also call to have Linus'
expectations of the maintainers documented. This would also be good for
everyone to read to better understand the responses they receive from
maintainers and why things are the way they are.

With that done, I think some tolerance in both directions would improve
things here. And as a last resort, we speak up when someone is under
attack.

"Whoa Nelly, calm down, don't forget your meds. Seriously though, that
(is not acceptable code|violates a core policy), see the following
documentation." This adds some burden on the broader audience to point
people at the docs, because even RTFM has to get annoying to repeat too
often.

And with that, I'll sign out of this thread unless anyone wants to
discuss documentation - but those should probably happen on LKML (or
maybe KS as some have suggested).

-- 
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel



^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [ 00/19] 3.10.1-stable review
  2013-07-17  1:37                       ` Linus Torvalds
@ 2013-07-17  1:54                         ` Steven Rostedt
  2013-07-17  3:28                         ` Darren Hart
  1 sibling, 0 replies; 213+ messages in thread
From: Steven Rostedt @ 2013-07-17  1:54 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Rusty Russell, Sarah Sharp, Willy Tarreau, Ingo Molnar,
	Guenter Roeck, Greg Kroah-Hartman, Dave Jones,
	Linux Kernel Mailing List, Andrew Morton, stable, Darren Hart,
	Mauro Carvalho Chehab, Rafael J. Wysocki

On Tue, 2013-07-16 at 18:37 -0700, Linus Torvalds wrote:

> Emotions aren't bad. Quite the reverse. 

Spock and Dr. Sheldon Cooper strongly disagree.

-- Steve



^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [ 00/19] 3.10.1-stable review
  2013-07-17  1:02                     ` Rusty Russell
@ 2013-07-17  1:37                       ` Linus Torvalds
  2013-07-17  1:54                         ` Steven Rostedt
  2013-07-17  3:28                         ` Darren Hart
  0 siblings, 2 replies; 213+ messages in thread
From: Linus Torvalds @ 2013-07-17  1:37 UTC (permalink / raw)
  To: Rusty Russell
  Cc: Sarah Sharp, Willy Tarreau, Ingo Molnar, Guenter Roeck,
	Greg Kroah-Hartman, Steven Rostedt, Dave Jones,
	Linux Kernel Mailing List, Andrew Morton, stable, Darren Hart,
	Mauro Carvalho Chehab, Rafael J. Wysocki

On Tue, Jul 16, 2013 at 6:02 PM, Rusty Russell <rusty@rustcorp.com.au> wrote:
>>
>> "Mauro, SHUT THE FUCK UP!"
>
> This one crosses the line.  There's no non-offensive way to tell a geek
> "you are wrong", but this isn't even trying.  Bad Linus!

You know what? Not my proudest moment. I was really upset.

But that said, in my defense I actually think that one stands out. I
have written a lot of public emails, and that one line is probably the
single most over-the-line one. Or at least pretty close to the top.
And it's not so much because of the swearing, but because of the "shut
up" part. Or is that just me not reacting to swearwords again?

Do I go overboard sometimes? Hell yes. But I get emotional about some
of this, and I not only think that's ok, I actually think it's
important. You mentioned the "lost the raw, red-hot anger of the
original", and I do think emotion is important to convey. It's not
just the message, it's also the fact that I'm really really pissed.

Neil Brown here somewhere earlier said

  "So my personal perspective on what it means to be responsible is:

   Don't flame:  include the facts, exclude the emotion."

and I can't overstate how much I disagree. You do need the factual
part too, but "exclude the emotion" is not good either.

Emotions aren't bad. Quite the reverse. If we are expected to have a
sense of personal trust between the people involved (and quite
frankly, apart from just "technical excellence" I think personal trust
is just about the top criterion for good maintainers), I definitely
think that it's not about just about the facts. You need to hear the
*person* too. And some people are calm and don't swear, and that's
them. Others aren't.

Yeah, yeah, I go overboard. Whatever. At least you guys know that when
I get emotional, I'm not going to come asking for a shoulder to cry
on.

I think a little excessive swearing is less awkward for everybody in the end.

            Linus

Side note: the whole "trust the person" doesn't mean you have to like
that person. "Trust" is about having your expectations met, not
necessarily about those expectations always being all that positive. .

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [ 00/19] 3.10.1-stable review
  2013-07-16 21:08                   ` Sarah Sharp
                                       ` (2 preceding siblings ...)
  2013-07-16 22:11                     ` Willy Tarreau
@ 2013-07-17  1:02                     ` Rusty Russell
  2013-07-17  1:37                       ` Linus Torvalds
  3 siblings, 1 reply; 213+ messages in thread
From: Rusty Russell @ 2013-07-17  1:02 UTC (permalink / raw)
  To: Sarah Sharp, Linus Torvalds
  Cc: Willy Tarreau, Ingo Molnar, Guenter Roeck, Greg Kroah-Hartman,
	Steven Rostedt, Dave Jones, Linux Kernel Mailing List,
	Andrew Morton, stable, Darren Hart, Mauro Carvalho Chehab,
	Rafael J. Wysocki

Sarah Sharp <sarah.a.sharp@linux.intel.com> writes:
> On Tue, Jul 16, 2013 at 02:22:14PM +0930, Rusty Russell wrote:
> Linus is complaining about code here, and the effects of merging bad
> code on his own tree.  I personally have no qualms with this type of
> harsh email, because it focuses on the code, not the person.
>
> I do, however, object when the verbal abuse shifts from being directed
> at code to being directed at *people*.  For example, Linus chose to
> curse at Mauro [2] and Rafael [3], rather than their code:
>
>
> "Mauro, SHUT THE FUCK UP!"

This one crosses the line.  There's no non-offensive way to tell a geek
"you are wrong", but this isn't even trying.  Bad Linus!

> "How long have you been a maintainer? And you *still* haven't learnt the
> first rule of kernel maintenance?"
>
> "Shut up, Mauro. And I don't _ever_ want to hear that kind of obvious
> garbage and idiocy from a kernel maintainer again. Seriously."
>
> "The fact that you then try to make *excuses* for breaking user space,
> and blaming some external program that *used* to work, is just
> shameful. It's not how we work."
>
> "Fix your f*cking "compliance tool", because it is obviously broken.
> And fix your approach to kernel programming."
...
> ...and I'm surprised to
> hear that kind of utter garbage from you in particular."

Linus repeats 5 times: you can tell he's upset.

> "Seriously. Why do I even have to mention this? Why do I have to
> explain this to somebody pretty much *every* f*cking merge window?"

This one is OK, actually.

So, I tried to rewrite Linus' email.  And it lost the raw, red-hot anger
of the original.  It no longer makes everyone listen.  It tempts one to
argue.

It is not as effective :(

But suggesting alternate expressions might be constructive.
Rusty.

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [ 00/19] 3.10.1-stable review
  2013-07-16 21:58                       ` Rafael J. Wysocki
@ 2013-07-16 22:12                         ` Linus Torvalds
  2013-07-17  5:22                           ` Sarah Sharp
  0 siblings, 1 reply; 213+ messages in thread
From: Linus Torvalds @ 2013-07-16 22:12 UTC (permalink / raw)
  To: Rafael J. Wysocki
  Cc: Sarah Sharp, Rusty Russell, Willy Tarreau, Ingo Molnar,
	Guenter Roeck, Greg Kroah-Hartman, Steven Rostedt, Dave Jones,
	Linux Kernel Mailing List, Andrew Morton, stable, Darren Hart,
	Mauro Carvalho Chehab

On Tue, Jul 16, 2013 at 2:58 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
>
> In fact, I didn't say what I really wanted to say in that reply to the reporter
> and that evidently confused you, which only made me think it was better to be
> more careful about sending replies to regression reports when Linus is on the
> CC list.  But it was kind of fun to watch you go ballistic by mistake. ;-)

And that's why I actually mentioned in my reply to Sarah that "(in
fact, with Rafael it was at least partially just bad communication,
and I haven't had that issue with him before)", because I have this
distinct memory that we ended up having that exact discussion about
misunderstanding and bad wording at the time.

I react very strongly when somebody argues against fixing regressions.
Let's just say that there's too many years of baggage that I carry
around on that issue..

So that is definitely one of the things that make me go ballistic.
Buggy code isn't actually one of them. Bugs happen. Even really stupid
bugs happen, and happen to good people. They had a bad day, or it was
just a brainfart.  Not that I will be _polite_ about bad code, mind
you, and there might be some bad words in there, but it doesn't make
me blow up.

Being cavalier about known regressions is definitely the primary
trigger. I suspect there are others, but I can't seem to recall any
other particular hot-button issues right now. Maybe Sarah can post a
few more pointers..

              Linus

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [ 00/19] 3.10.1-stable review
  2013-07-16 21:08                   ` Sarah Sharp
  2013-07-16 21:23                     ` Linus Torvalds
  2013-07-16 21:27                     ` Steven Rostedt
@ 2013-07-16 22:11                     ` Willy Tarreau
  2013-07-17  1:02                     ` Rusty Russell
  3 siblings, 0 replies; 213+ messages in thread
From: Willy Tarreau @ 2013-07-16 22:11 UTC (permalink / raw)
  To: Sarah Sharp
  Cc: Linus Torvalds, Rusty Russell, Ingo Molnar, Guenter Roeck,
	Greg Kroah-Hartman, Steven Rostedt, Dave Jones,
	Linux Kernel Mailing List, Andrew Morton, stable, Darren Hart,
	Mauro Carvalho Chehab, Rafael J. Wysocki

On Tue, Jul 16, 2013 at 02:08:56PM -0700, Sarah Sharp wrote:
> Rusty hit the nail on the head here.  I want everyone (including Linus)
> to be harsh with code but gentle with people.

Just as a side note Sarah, in some cultures/languages, "I want" is
extremely impolite, almost insulting to your interlocutor. In France,
if you want to quickly upset someone, simply say "I want you to do this
or that". The polite form is "I would like you to do that", "I would
appreciate..." or "let's do that", and when you're slightly upset or
in a hurry, better simply say "do that" without putting yourself
prominently as the one who has some unexplained reasons for demanding
something.

With that said, this thread has probably lived too long. I think we're
starting to fuck flies, and once we won't have any living flies left,
someone will have to bring new files, and it's certainly not me.

Regards,
Willy


^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [ 00/19] 3.10.1-stable review
  2013-07-16 21:23                     ` Linus Torvalds
@ 2013-07-16 21:58                       ` Rafael J. Wysocki
  2013-07-16 22:12                         ` Linus Torvalds
  0 siblings, 1 reply; 213+ messages in thread
From: Rafael J. Wysocki @ 2013-07-16 21:58 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Sarah Sharp, Rusty Russell, Willy Tarreau, Ingo Molnar,
	Guenter Roeck, Greg Kroah-Hartman, Steven Rostedt, Dave Jones,
	Linux Kernel Mailing List, Andrew Morton, stable, Darren Hart,
	Mauro Carvalho Chehab

On Tuesday, July 16, 2013 02:23:46 PM Linus Torvalds wrote:
> On Tue, Jul 16, 2013 at 2:08 PM, Sarah Sharp
> <sarah.a.sharp@linux.intel.com> wrote:
> >
> > I do, however, object when the verbal abuse shifts from being directed
> > at code to being directed at *people*.  For example, Linus chose to
> > curse at Mauro [2] and Rafael [3], rather than their code:
> 
> Umm. Because it was actually the person who was the problem?
> 
> Trust me, there's a really easy way for me to curse at people: if you
> are a maintainer, and you make excuses for your bugs rather than
> trying to fix them, I will curse at *YOU*.
> 
> Because then the problem really is you.
> 
> And in *both* of the examples you cite, that was exactly the issue. It
> wasn't that there was a bug - it was that the maintainer in question
> basically refused to fix a regression.
> 
> Sure, there was a code problem. But that wasn't the big issue. Code
> can be broken, and can be utter crap, but as long as it's fixed, who
> cares?
> 
> But when top-level maintainers start ignoring the #1 rule in the
> kernel ("We don't regress user space"), then it's not the broken code
> that annoys me any more.
> 
> See the difference?
> 
> And yes, people who don't get this are people who I will literally
> refuse to work with. In both of the cases you cite, things resolved
> themselves quickly (in fact, with Rafael it was at least partially
> just bad communication, and I haven't had that issue with him before).

Actually, I didn't feel like I was being attacked personally then.

In fact, I didn't say what I really wanted to say in that reply to the reporter
and that evidently confused you, which only made me think it was better to be
more careful about sending replies to regression reports when Linus is on the
CC list.  But it was kind of fun to watch you go ballistic by mistake. ;-)

And the problem itself was really confusing IIRC (that was a regression in a
piece of code that wasn't even executed as a result of a different bug and the
fix for that different bug caused the regression to show up).

So no, not really a good example of "Linus cursing at people" as far as I'm
concerned.

Rafael


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

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [ 00/19] 3.10.1-stable review
  2013-07-16 21:08                   ` Sarah Sharp
  2013-07-16 21:23                     ` Linus Torvalds
@ 2013-07-16 21:27                     ` Steven Rostedt
  2013-07-16 22:11                     ` Willy Tarreau
  2013-07-17  1:02                     ` Rusty Russell
  3 siblings, 0 replies; 213+ messages in thread
From: Steven Rostedt @ 2013-07-16 21:27 UTC (permalink / raw)
  To: Sarah Sharp
  Cc: Linus Torvalds, Rusty Russell, Willy Tarreau, Ingo Molnar,
	Guenter Roeck, Greg Kroah-Hartman, Dave Jones,
	Linux Kernel Mailing List, Andrew Morton, stable, Darren Hart,
	Mauro Carvalho Chehab, Rafael J. Wysocki

On Tue, 2013-07-16 at 14:08 -0700, Sarah Sharp wrote:

> 
> "Mauro, SHUT THE FUCK UP!"
> 
> "How long have you been a maintainer? And you *still* haven't learnt the
> first rule of kernel maintenance?"
> 
> "Shut up, Mauro. And I don't _ever_ want to hear that kind of obvious
> garbage and idiocy from a kernel maintainer again. Seriously."
> 
> "The fact that you then try to make *excuses* for breaking user space,
> and blaming some external program that *used* to work, is just
> shameful. It's not how we work."
> 
> "Fix your f*cking "compliance tool", because it is obviously broken.
> And fix your approach to kernel programming."
> 
> "Seriously. Why do I even have to mention this? Why do I have to
> explain this to somebody pretty much *every* f*cking merge window?"
> 
> "And btw, the *reason* for that rule becoming such a hard rule was
> pretty much exactly suspend/resume and ACPI. Exactly because we used
> to have those infinite "let's fix one thing and break another" dances.
> So you should be well acquainted with the rule, and I'm surprised to
> hear that kind of utter garbage from you in particular."

Reading all this again, it seems that Linus is pissed off at what Mauro
said, did or is doing. I don't really see a direct attack at Mauro as a
person. Not much different than being pissed off at someone asking Linus
to pull crap that's marked for stable. I see a very fine line between
the two.

Also, it seems that Linus is more disappointed with Mauro, as he expects
more from him.

Honestly, sometimes Linus needs to yell louder to top maintainers. As
its a way to wake us up that we need to be held to a higher regard.
Sometimes we may get complacent, and a bit lazy. If a top maintainer
starts to slack, major damage can be done. It needs to be serious.

I don't see the above as public shaming. It really just points out what
Linus expects from all maintainers, which would have been lost if this
were a private email.


> 
> 
> The personally directed verbal abuse is what I'm complaining about here.
> Linus goes from 0 to 11 at the drop of an "I don't think this is a
> regression" comment, and publicly ridicules his top maintainers.
> 
> This is not right.  This is not a community that people want to be a
> part of, except for a few top-tier maintainers who have "tough skins".
> No one should have to be the focus of a fire hose of personal verbal
> abuse.

I still don't see it as personal. Linus got pissed at what Mauro said
and did, not at Mauro as a person. Thus, not personal.

"I'm surprised to hear that kind of utter garbage from you in
particular"

I actually read the above as a complement.

> 
> We're adults, not high schoolers.  We can figure out how to deliver
> harsh technical criticism without resorting to name calling, cussing at
> people, or personal attacks.

Was there name calling in the above? I missed it.

> 
> If a maintainer is not doing their job, Linus should send them a private
> harsh email, and a public email that simply says, "I'm reverting this
> pull request because of X.  If this continues through the next merge
> window, this maintainer will need to train a replacement."  Don't
> publicly tear them to pieces because they made a simple mistake.

That kind of email will most likely be ignored by people. A harsh email
becomes popular and noticed by a larger audience.

> 
> 
> The definition of insanity is repeating the same thing, over and over,
> expecting the result to be different.  Linus keeps repeating the same
> mantras over and over to maintainers that forget rules like, "No
> regressions."

No, I think people have heard this. And sometimes we start to think:
well this one may be different. Seems that its the maintainers that try
to do the same thing over and over expecting a different result from
Linus which is what makes Linus insane.


> 
> Why aren't we trying different tactics?  Why aren't we improving our
> documentation so maintainers don't have to repeat themselves?

There's lots of documentation, and I think its more that maintainers
thinking "this time it's different" than anything else. I guarantee that
Mauro will not push userspace breakage again. And because of that email,
so will a lot of other maintainers.

-- Steve



^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [ 00/19] 3.10.1-stable review
  2013-07-16 21:08                   ` Sarah Sharp
@ 2013-07-16 21:23                     ` Linus Torvalds
  2013-07-16 21:58                       ` Rafael J. Wysocki
  2013-07-16 21:27                     ` Steven Rostedt
                                       ` (2 subsequent siblings)
  3 siblings, 1 reply; 213+ messages in thread
From: Linus Torvalds @ 2013-07-16 21:23 UTC (permalink / raw)
  To: Sarah Sharp
  Cc: Rusty Russell, Willy Tarreau, Ingo Molnar, Guenter Roeck,
	Greg Kroah-Hartman, Steven Rostedt, Dave Jones,
	Linux Kernel Mailing List, Andrew Morton, stable, Darren Hart,
	Mauro Carvalho Chehab, Rafael J. Wysocki

On Tue, Jul 16, 2013 at 2:08 PM, Sarah Sharp
<sarah.a.sharp@linux.intel.com> wrote:
>
> I do, however, object when the verbal abuse shifts from being directed
> at code to being directed at *people*.  For example, Linus chose to
> curse at Mauro [2] and Rafael [3], rather than their code:

Umm. Because it was actually the person who was the problem?

Trust me, there's a really easy way for me to curse at people: if you
are a maintainer, and you make excuses for your bugs rather than
trying to fix them, I will curse at *YOU*.

Because then the problem really is you.

And in *both* of the examples you cite, that was exactly the issue. It
wasn't that there was a bug - it was that the maintainer in question
basically refused to fix a regression.

Sure, there was a code problem. But that wasn't the big issue. Code
can be broken, and can be utter crap, but as long as it's fixed, who
cares?

But when top-level maintainers start ignoring the #1 rule in the
kernel ("We don't regress user space"), then it's not the broken code
that annoys me any more.

See the difference?

And yes, people who don't get this are people who I will literally
refuse to work with. In both of the cases you cite, things resolved
themselves quickly (in fact, with Rafael it was at least partially
just bad communication, and I haven't had that issue with him before).
Other people, who seem to treat regressions cavalierly, I will first
make it *very* clear that it is unacceptable, and then I will refuse
to take their patches. It has happened.

And yes, if that's the reason some person doesn't like working with
the kernel ("Linus screams at me when I break things and don't want to
fix them"), then dammit, good f*cking riddance. I already saw exactly
that comment on G+ earlier today - somebody who is well-known for not
fixing his regressions ("fix your user instead") was talking about how
he doesn't want to work with me for that very reason.

So apparently my cursing works.

Seriously, Sarah, you need to get off this "you can't curse at
people". Because you *can* curse at people, and it very much is
sometimes called for.

               Linus

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [ 00/19] 3.10.1-stable review
  2013-07-16  4:52                 ` Rusty Russell
@ 2013-07-16 21:08                   ` Sarah Sharp
  2013-07-16 21:23                     ` Linus Torvalds
                                       ` (3 more replies)
  0 siblings, 4 replies; 213+ messages in thread
From: Sarah Sharp @ 2013-07-16 21:08 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Rusty Russell, Willy Tarreau, Ingo Molnar, Guenter Roeck,
	Greg Kroah-Hartman, Steven Rostedt, Dave Jones,
	Linux Kernel Mailing List, Andrew Morton, stable, Darren Hart,
	Mauro Carvalho Chehab, Rafael J. Wysocki

On Tue, Jul 16, 2013 at 02:22:14PM +0930, Rusty Russell wrote:
> Linus Torvalds <torvalds@linux-foundation.org> writes:
> > On Mon, Jul 15, 2013 at 12:17 PM, Willy Tarreau <w@1wt.eu> wrote:
> >>
> >> BTW, I was amazed that you managed to get him have a much softer tone inr
> >> his last e-mail, you probably found a weakness here in his management
> >> process :-)
> >
> > Hey, I _like_ arguing, and "cursing" and "arguing" are actually not at
> > all the same thing.
> >
> > And I really don't tend to curse unless people are doing something
> > stupid and annoying. If people have concerns and questions that I feel
> > are valid, I'm more than happy to talk about it.
> >
> > I curse when there isn't any argument. The cursing happens for the
> > "you're so f*cking wrong that it's not even worth trying to make
> > logical arguments about it, because you have no possible excuse" case.
> >
> > .. and sometimes people surprise me and come back with a valid excuse
> > after all. "My whole family died in a tragic freak accident and my
> > pony got cancer, and I was distracted".
> >
> > And then I might even tell them I'm sorry.
> >
> > No. Not really.
> 
> You have to be harsh with code: People mistake politeness for
> uncertainty.  Whenever I said 'I prefer if you XYZ' some proportion
> didn't realize I meant 'Don't argue unless you have new facts: do XYZ or
> go away.'  This wastes my time, so I started being explicit.
> 
> But be gentle with people.  You've already called their baby ugly.

Rusty hit the nail on the head here.  I want everyone (including Linus)
to be harsh with code but gentle with people.

I personally don't care if emails are peppered with a little cussing.
You can see I've included some words like "fuck" in my emails too.
However, I object to how the cursing is *directed*.

In the x86 email [1], you could argue that Linus' tone was pretty
grumpy, maybe even abrasive.  However, he was criticizing *code* when he
cursed:


"This piece-of-shit commit is marked for stable, but you clearly never
even test-compiled it, did you?"

"I made the mistake of doing multiple merges back-to-back with the
intention of not doing a full allmodconfig build in between them, and
now I have to undo them all because this pull request was full of
unbelievable shit."

"And why the hell was this marked for stable even *IF* it hadn't been
complete and utter tripe? It even has a comment in the commit message
about how this probably doesn't matter."


Linus is complaining about code here, and the effects of merging bad
code on his own tree.  I personally have no qualms with this type of
harsh email, because it focuses on the code, not the person.

I do, however, object when the verbal abuse shifts from being directed
at code to being directed at *people*.  For example, Linus chose to
curse at Mauro [2] and Rafael [3], rather than their code:


"Mauro, SHUT THE FUCK UP!"

"How long have you been a maintainer? And you *still* haven't learnt the
first rule of kernel maintenance?"

"Shut up, Mauro. And I don't _ever_ want to hear that kind of obvious
garbage and idiocy from a kernel maintainer again. Seriously."

"The fact that you then try to make *excuses* for breaking user space,
and blaming some external program that *used* to work, is just
shameful. It's not how we work."

"Fix your f*cking "compliance tool", because it is obviously broken.
And fix your approach to kernel programming."

"Seriously. Why do I even have to mention this? Why do I have to
explain this to somebody pretty much *every* f*cking merge window?"

"And btw, the *reason* for that rule becoming such a hard rule was
pretty much exactly suspend/resume and ACPI. Exactly because we used
to have those infinite "let's fix one thing and break another" dances.
So you should be well acquainted with the rule, and I'm surprised to
hear that kind of utter garbage from you in particular."


The personally directed verbal abuse is what I'm complaining about here.
Linus goes from 0 to 11 at the drop of an "I don't think this is a
regression" comment, and publicly ridicules his top maintainers.

This is not right.  This is not a community that people want to be a
part of, except for a few top-tier maintainers who have "tough skins".
No one should have to be the focus of a fire hose of personal verbal
abuse.

We're adults, not high schoolers.  We can figure out how to deliver
harsh technical criticism without resorting to name calling, cussing at
people, or personal attacks.

If a maintainer is not doing their job, Linus should send them a private
harsh email, and a public email that simply says, "I'm reverting this
pull request because of X.  If this continues through the next merge
window, this maintainer will need to train a replacement."  Don't
publicly tear them to pieces because they made a simple mistake.


The definition of insanity is repeating the same thing, over and over,
expecting the result to be different.  Linus keeps repeating the same
mantras over and over to maintainers that forget rules like, "No
regressions."

Why aren't we trying different tactics?  Why aren't we improving our
documentation so maintainers don't have to repeat themselves?

Sarah Sharp

[1] https://lkml.org/lkml/2013/7/13/132
[2] http://marc.info/?l=linux-kernel&m=135628421403144&w=2
[3] http://marc.info/?l=linux-acpi&m=136157944603147&w=2

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [ 00/19] 3.10.1-stable review
  2013-07-16 15:40                   ` Darren Hart
@ 2013-07-16 18:18                     ` Willy Tarreau
  0 siblings, 0 replies; 213+ messages in thread
From: Willy Tarreau @ 2013-07-16 18:18 UTC (permalink / raw)
  To: Darren Hart
  Cc: NeilBrown, Sarah Sharp, Linus Torvalds, Ingo Molnar,
	Guenter Roeck, Greg Kroah-Hartman, Steven Rostedt, Dave Jones,
	Linux Kernel Mailing List, Andrew Morton, stable

Hi Darren,

On Tue, Jul 16, 2013 at 08:40:15AM -0700, Darren Hart wrote:
> On Tue, 2013-07-16 at 08:13 +0200, Willy Tarreau wrote:
> 
> > It can seem counter-producting first (as Sarah thinks) but I think that
> > the competent people find their way in this simply because they're backed
> > up by other ones. That's how I think we get that number of skilled people
> > at the top of each subsystem.
> > 
> 
> Hi Will,
> 
> I think you've made some excellent points and have done a good job
> relating the mostly digital interactions to more direct and tangible
> ones.
> 
> You have postulated (I believe) that because we have top-quality
> maintainers (and I agree, we do), the process must be working. Perhaps
> that was my interpretation and not your intent, but others have voiced
> such opinions as well, so the following is still relevant.
> 
> What that argument fails to take into account are the top-quality
> maintainers and contributors who are not present because of the
> sometimes caustic environment of Linux kernel development: "survivor's
> bias".

No, I'm not forgetting this, and I'm sure this is a fact. We don't have
that many shy people here I think. But the question would probably better
be "are the efforts and implications of adopting a softer communication
worth the gain of getting a few more talented people ?". I don't have the
response to this question, but for sure many things would change, some
current developers would not follow, release cycles would extend, but
maybe we'd get a slightly higher quality each time, who knows. Also, too
shy people rarely propose improvements, even if they tend to have the
greatest ideas since they spend more time thinking than talking. What I'm
sure about however is that the two models are incompatible, and breaking
one which works to try another one seems suicidal. And Linus would probably
suggest "try it, fork the kernel, build a team and manage it your way".

All in all, I think the best thing to do would be to improve the processes
so that it becomes much clearer for everyone so that newcomers are less
afraid of it and do less mistakes. With a smoother process we can expect
a higher quality from everyone and in turn reduce the risk that Linus
shouts too often. Everyone will benefit from this in the end. I'm not
the best placed to propose improvements, I'm not suffering from the
process, so let's hope that people who are unhappy with it will explain
their concerns in great details.

> There is a great article on the subject I read recently here:
> 
> http://youarenotsosmart.com/2013/05/23/survivorship-bias/

Seems interesting but very long, I'll have to read it later ! Thanks for
the link anyway.

Willy


^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [ 00/19] 3.10.1-stable review
  2013-07-16  6:13                 ` Willy Tarreau
@ 2013-07-16 15:40                   ` Darren Hart
  2013-07-16 18:18                     ` Willy Tarreau
  0 siblings, 1 reply; 213+ messages in thread
From: Darren Hart @ 2013-07-16 15:40 UTC (permalink / raw)
  To: Willy Tarreau
  Cc: NeilBrown, Sarah Sharp, Linus Torvalds, Ingo Molnar,
	Guenter Roeck, Greg Kroah-Hartman, Steven Rostedt, Dave Jones,
	Linux Kernel Mailing List, Andrew Morton, stable

On Tue, 2013-07-16 at 08:13 +0200, Willy Tarreau wrote:

> It can seem counter-producting first (as Sarah thinks) but I think that
> the competent people find their way in this simply because they're backed
> up by other ones. That's how I think we get that number of skilled people
> at the top of each subsystem.
> 

Hi Will,

I think you've made some excellent points and have done a good job
relating the mostly digital interactions to more direct and tangible
ones.

You have postulated (I believe) that because we have top-quality
maintainers (and I agree, we do), the process must be working. Perhaps
that was my interpretation and not your intent, but others have voiced
such opinions as well, so the following is still relevant.

What that argument fails to take into account are the top-quality
maintainers and contributors who are not present because of the
sometimes caustic environment of Linux kernel development: "survivor's
bias". There is a great article on the subject I read recently here:

http://youarenotsosmart.com/2013/05/23/survivorship-bias/


-- 
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel


^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [ 00/19] 3.10.1-stable review
  2013-07-16 15:09                     ` Kees Cook
@ 2013-07-16 15:27                       ` Darren Hart
  0 siblings, 0 replies; 213+ messages in thread
From: Darren Hart @ 2013-07-16 15:27 UTC (permalink / raw)
  To: Kees Cook
  Cc: Geert Uytterhoeven, Sarah Sharp, Linus Torvalds, Ingo Molnar,
	Guenter Roeck, Greg Kroah-Hartman, Steven Rostedt, Dave Jones,
	Linux Kernel Mailing List, Andrew Morton, stable

On Tue, 2013-07-16 at 08:09 -0700, Kees Cook wrote:
> On Tue, Jul 16, 2013 at 04:30:45PM +0200, Geert Uytterhoeven wrote:
> > On Mon, Jul 15, 2013 at 10:41 PM, Sarah Sharp
> > <sarah.a.sharp@linux.intel.com> wrote:
> > > I should not have to ask for professional behavior on the mailing lists.
> > > Professional behavior should be the default.
> > 
> > So, what does "professional" mean? A professional is paid for his work, an
> > amateur isn't. But this doesn't say anything about code quality, maintainer
> > responsiveness, etc.
> > Does it imply behavior that (hopefully) keeps getting you paid?
> 
> I think we're getting hung up on this specific phrase. I've interpreted
> this issue with lkml communication as a need to avoid bullying.  I think
> "no bullying", while still up for heavy interpretation, is better to
> focus on than "being professional".
> 

Agreed. The swearing will continue until code quality improves.

The bit I can get behind is the avoidance of personal attacks. Some on
this thread have argued that instances of such attacks are now few and
far between. Is that the case? How many are we talking about? 10/day?
10/year? Is it truly only the lieutenants getting public lashings?

I understand that it is the environment itself, the accepted norms, the
"standard you walk past" (as Sarah has quoted) that is the real focus.
So yes, let's not get hung up on professional/unprofessional or any
other such subjective term or fall into the PC traps.

-- 
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel


^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [ 00/19] 3.10.1-stable review
  2013-07-16 14:30                   ` Geert Uytterhoeven
  2013-07-16 15:00                     ` Steven Rostedt
@ 2013-07-16 15:09                     ` Kees Cook
  2013-07-16 15:27                       ` Darren Hart
  1 sibling, 1 reply; 213+ messages in thread
From: Kees Cook @ 2013-07-16 15:09 UTC (permalink / raw)
  To: Geert Uytterhoeven
  Cc: Sarah Sharp, Linus Torvalds, Ingo Molnar, Guenter Roeck,
	Greg Kroah-Hartman, Steven Rostedt, Dave Jones,
	Linux Kernel Mailing List, Andrew Morton, stable, Darren Hart

On Tue, Jul 16, 2013 at 04:30:45PM +0200, Geert Uytterhoeven wrote:
> On Mon, Jul 15, 2013 at 10:41 PM, Sarah Sharp
> <sarah.a.sharp@linux.intel.com> wrote:
> > I should not have to ask for professional behavior on the mailing lists.
> > Professional behavior should be the default.
> 
> So, what does "professional" mean? A professional is paid for his work, an
> amateur isn't. But this doesn't say anything about code quality, maintainer
> responsiveness, etc.
> Does it imply behavior that (hopefully) keeps getting you paid?

I think we're getting hung up on this specific phrase. I've interpreted
this issue with lkml communication as a need to avoid bullying.  I think
"no bullying", while still up for heavy interpretation, is better to
focus on than "being professional".

-Kees

-- 
Kees Cook                                            @outflux.net

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [ 00/19] 3.10.1-stable review
  2013-07-16 14:30                   ` Geert Uytterhoeven
@ 2013-07-16 15:00                     ` Steven Rostedt
  2013-07-16 15:09                     ` Kees Cook
  1 sibling, 0 replies; 213+ messages in thread
From: Steven Rostedt @ 2013-07-16 15:00 UTC (permalink / raw)
  To: Geert Uytterhoeven
  Cc: Sarah Sharp, Linus Torvalds, Ingo Molnar, Guenter Roeck,
	Greg Kroah-Hartman, Dave Jones, Linux Kernel Mailing List,
	Andrew Morton, stable, Darren Hart

On Tue, 2013-07-16 at 16:30 +0200, Geert Uytterhoeven wrote:
> On Mon, Jul 15, 2013 at 10:41 PM, Sarah Sharp
> <sarah.a.sharp@linux.intel.com> wrote:
> > I should not have to ask for professional behavior on the mailing lists.
> > Professional behavior should be the default.
> 
> So, what does "professional" mean? A professional is paid for his work, an
> amateur isn't. But this doesn't say anything about code quality, maintainer
> responsiveness, etc.
> Does it imply behavior that (hopefully) keeps getting you paid?
> 

Let me give you an example of a "professional" environment. When I use
to work for a large corporation, we had one guy doing some work for us
and he was rather new to our department (not new as a programmer). But I
swear, I have no idea how he became a programmer, and he's been with the
company for a while. He had to do a task that I was in charge of, and
gave him the requirements. He just couldn't understand it. I spent a
full week and a half "being nice" and going into details of what he
needed to do and he got no where. Finally, as I have now gone over every
aspect of what needed to be done and knew it in excruciating detail, I
sat down and wrote the entire thing myself in a single day. This was
something he was to do in two weeks.

When my manager heard about this, she blew up and sent a very nasty
email to the employee's manager, and things got really bad because of
the "nastiness" of the email and not the fact that we wasted two weeks
of being unproductive.

That's what a professional environment gives you, and honestly, I think
the Linux community can do without it.

-- Steve
 


^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [ 00/19] 3.10.1-stable review
  2013-07-15 19:07             ` Linus Torvalds
  2013-07-15 19:53               ` Sarah Sharp
@ 2013-07-16 14:45               ` Alex Elder
  1 sibling, 0 replies; 213+ messages in thread
From: Alex Elder @ 2013-07-16 14:45 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Sarah Sharp, Ingo Molnar, Guenter Roeck, Greg Kroah-Hartman,
	Steven Rostedt, Dave Jones, Linux Kernel Mailing List,
	Andrew Morton, stable, Darren Hart

On 07/15/2013 02:07 PM, Linus Torvalds wrote:
> But when people who know better send me crap, I'll curse at them.
> 
> I suspect you'll notice me cursing *way* more at top developers than
> random people on the list. I expect more from them, and conversely
> I'll be a lot more upset when they do something that I really think
> was not great.

I have always found this to be the case.

Linus has high expectations, and I think the quality of
Linux code speaks volumes about the long-term effect of
that.  Blistering messages from Linus are directed at
people who have an established reputation, but who
present something less than high-caliber work.

Our communication is very open and public though.  Those
with some experience in the community should know that
these strongly-worded messages are not sent indiscriminately.
This isn't obvious to a newcomer though.  A stranger may
not realize that the shouting is among friends who care a lot
about what they're doing.

If the conversation weren't so public it may not seem
as inappropriate.  The shaming and flaming style is
effective for keeping top people in line.  But it does
needlessly intimidate new people in the process.

					-Alex

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [ 00/19] 3.10.1-stable review
  2013-07-15 20:41                 ` Sarah Sharp
  2013-07-15 21:01                   ` Kees Cook
  2013-07-15 21:50                   ` Linus Torvalds
@ 2013-07-16 14:30                   ` Geert Uytterhoeven
  2013-07-16 15:00                     ` Steven Rostedt
  2013-07-16 15:09                     ` Kees Cook
  2 siblings, 2 replies; 213+ messages in thread
From: Geert Uytterhoeven @ 2013-07-16 14:30 UTC (permalink / raw)
  To: Sarah Sharp
  Cc: Linus Torvalds, Ingo Molnar, Guenter Roeck, Greg Kroah-Hartman,
	Steven Rostedt, Dave Jones, Linux Kernel Mailing List,
	Andrew Morton, stable, Darren Hart

On Mon, Jul 15, 2013 at 10:41 PM, Sarah Sharp
<sarah.a.sharp@linux.intel.com> wrote:
> I should not have to ask for professional behavior on the mailing lists.
> Professional behavior should be the default.

So, what does "professional" mean? A professional is paid for his work, an
amateur isn't. But this doesn't say anything about code quality, maintainer
responsiveness, etc.
Does it imply behavior that (hopefully) keeps getting you paid?

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

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [ 00/19] 3.10.1-stable review
  2013-07-15 22:40               ` NeilBrown
@ 2013-07-16  6:13                 ` Willy Tarreau
  2013-07-16 15:40                   ` Darren Hart
  0 siblings, 1 reply; 213+ messages in thread
From: Willy Tarreau @ 2013-07-16  6:13 UTC (permalink / raw)
  To: NeilBrown
  Cc: Sarah Sharp, Linus Torvalds, Ingo Molnar, Guenter Roeck,
	Greg Kroah-Hartman, Steven Rostedt, Dave Jones,
	Linux Kernel Mailing List, Andrew Morton, stable, Darren Hart

Hi Neil,

On Tue, Jul 16, 2013 at 08:40:36AM +1000, NeilBrown wrote:
> On Mon, 15 Jul 2013 21:17:27 +0200 Willy Tarreau <w@1wt.eu> wrote:
> 
> > Communication works two ways.
> 
> I understand that to mean (at least) that for communication, every message
> must be both sent and received.  So when constructing a message, it is
> important to think about how others will understand it.

Yes, and I'd say that "others" here is "most of the readers". I've been
using that in some large companies, sometimes people do wrong things and
defend themselves of stupid choices by putting tens of people in copy to
try to cover their ass.

This is where I please myself. I only assemble nice words that everyone
understands to build sentences that several readers will interprete with
a varying degree of aggressivity. The aggressivity is at its top for the
target, but non-existent for the most external readers. You end up with
a person justifying him/herself in public about something apparently not
existing, till the point where someone high asks "what are you talking
about, care to elaborate?". You get impressive results this way, wrong
projects being aborted, budgets to fix others. Not a single bad word,
yet it is an extermely unpleasant experience for the target who feels
naked in public and hates me. Quite frankly these persons would prefer
a single hard e-mail from Linus than a week long of chess game like this.
So yes, everyone's understanding is important.

> On a public email list there are an awful lot of "others", and it is very
> likely that any possible misunderstanding will be experienced by someone.
> I think it best to minimise opportunities for misunderstanding.

Yes exactly, especially for non-native readers who don't always
understand some cultural jokes. There were a number of non-important
jokes I didn't catch in this thread and that are not important. However
generally when Linus gives someone his "appreciation" for a given work,
there is very little room for misinterpretation, which is fine. He once
severely scolded me on the sec list for insisting on proposing a fix for
an issue I misunderstood. I had all the colorful details to understand
the issue and to realize that I was lacking some skills in the specific
area subject of the issue.

> > Sure it can be hard for newcomers but I don't remember having read him
> > scold a newcomer. 
> 
> I think that is not relevant.  He is scolding people senior developers in
> front of newcomers.  That is not likely to encourage people to want to become
> senior developers.

I'm not that sure, because instead newcomers think "this guy is a bastard, I
don't want to work with him, I'll work with maintainers instead". And that's
what is expected. They start by focusing on a given subsystem, and as years
pass, they realize that the guy with the big mouth is not that naughty,
especially when he helps them design or fix their work.

> Anecdote:  My son (in highschool) is doing a psych assignment where he is
> asking people to complete a survey which, among other things, asks about
> people fear/anxiety response to various situations (it is a fairly standard
> instrument I think[1]).  Last few times he checked, the situation with the
> highest average score was "One person bullying another".  Really, it isn't
> nice to watch.

That's an interesting study which very likely matches reality, but here
it's a bit different. The group of people is not just two guys having
words together, imagine a room with hundreds or thousands of people and
two in the middle fighting. They'll just get ignored by newcomers who
will preferably sit down close to people who discuss calmly.

I have another anecdote. A few years ago, one very discrete and respectful
developer used to help me with backports of some security fixes. At some
point I asked him "wouldn't you prefer to be on the sec list, it would be
easier", and he replied "Linus will never accept, he once scolded me in
public", and I replied "quite the opposite then, that's good for you".
And when I asked, Linus said "yes of course I want him on the list, he
can certainly help us". So as you see, if some people are impressed first,
they can still be brought in front of the one they fear and realize that
they were thinking wrong.

It can seem counter-producting first (as Sarah thinks) but I think that
the competent people find their way in this simply because they're backed
up by other ones. That's how I think we get that number of skilled people
at the top of each subsystem.

And last, from some feedback I got, I would suspect that some top developers
prefer one e-mail from Linus once in a while to countless e-mails from end
users who repeatedly criticize their work when something does not work like
they expect for whatever reasons (including PEBKAC).

Best regards,
Willy


^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [ 00/19] 3.10.1-stable review
  2013-07-15 19:23               ` Linus Torvalds
  2013-07-15 19:39                 ` Willy Tarreau
  2013-07-15 22:50                 ` Raymond Jennings
@ 2013-07-16  4:52                 ` Rusty Russell
  2013-07-16 21:08                   ` Sarah Sharp
  2 siblings, 1 reply; 213+ messages in thread
From: Rusty Russell @ 2013-07-16  4:52 UTC (permalink / raw)
  To: Linus Torvalds, Willy Tarreau
  Cc: Sarah Sharp, Ingo Molnar, Guenter Roeck, Greg Kroah-Hartman,
	Steven Rostedt, Dave Jones, Linux Kernel Mailing List,
	Andrew Morton, stable, Darren Hart

Linus Torvalds <torvalds@linux-foundation.org> writes:
> On Mon, Jul 15, 2013 at 12:17 PM, Willy Tarreau <w@1wt.eu> wrote:
>>
>> BTW, I was amazed that you managed to get him have a much softer tone inr
>> his last e-mail, you probably found a weakness here in his management
>> process :-)
>
> Hey, I _like_ arguing, and "cursing" and "arguing" are actually not at
> all the same thing.
>
> And I really don't tend to curse unless people are doing something
> stupid and annoying. If people have concerns and questions that I feel
> are valid, I'm more than happy to talk about it.
>
> I curse when there isn't any argument. The cursing happens for the
> "you're so f*cking wrong that it's not even worth trying to make
> logical arguments about it, because you have no possible excuse" case.
>
> .. and sometimes people surprise me and come back with a valid excuse
> after all. "My whole family died in a tragic freak accident and my
> pony got cancer, and I was distracted".
>
> And then I might even tell them I'm sorry.
>
> No. Not really.

You have to be harsh with code: People mistake politeness for
uncertainty.  Whenever I said 'I prefer if you XYZ' some proportion
didn't realize I meant 'Don't argue unless you have new facts: do XYZ or
go away.'  This wastes my time, so I started being explicit.

But be gentle with people.  You've already called their baby ugly.

Cheers,
Rusty.

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [ 00/19] 3.10.1-stable review
  2013-07-15 18:46           ` Sarah Sharp
                               ` (2 preceding siblings ...)
  2013-07-15 19:17             ` Willy Tarreau
@ 2013-07-16  2:44             ` Li Zefan
  3 siblings, 0 replies; 213+ messages in thread
From: Li Zefan @ 2013-07-16  2:44 UTC (permalink / raw)
  To: Sarah Sharp
  Cc: Linus Torvalds, Ingo Molnar, Guenter Roeck, Greg Kroah-Hartman,
	Steven Rostedt, Dave Jones, Linux Kernel Mailing List,
	Andrew Morton, stable, Darren Hart

>> Sarah, first off, I don't have that many tools at hand. Secondly, I
>> simply don't believe in being polite or politically correct.
> 
> Bullshit.  I've seen you be polite, and explain to clueless maintainers
> why there's no way you can revert their merge that caused regressions,
> and ask them to fit it without resorting to tearing them down
> emotionally:
> 

As an asian, who are considered as much shyer than Western developers,
I don't see any attitute problem in Linus. But whenever I need to send
a patch to him, I tend to be more careful not to make mistakes.


^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [ 00/19] 3.10.1-stable review
  2013-07-16  1:54                   ` NeilBrown
@ 2013-07-16  2:01                     ` Joe Perches
  2013-07-21  4:15                       ` Rob Landley
  0 siblings, 1 reply; 213+ messages in thread
From: Joe Perches @ 2013-07-16  2:01 UTC (permalink / raw)
  To: NeilBrown
  Cc: Steven Rostedt, J. Bruce Fields, Linus Torvalds, Sarah Sharp,
	Ingo Molnar, Guenter Roeck, Greg Kroah-Hartman, Dave Jones,
	Linux Kernel Mailing List, Andrew Morton, stable, Darren Hart

On Tue, 2013-07-16 at 11:54 +1000, NeilBrown wrote:
> On Mon, 15 Jul 2013 16:50:52 -0700 Joe Perches <joe@perches.com> wrote:
> 
> > On Tue, 2013-07-16 at 09:42 +1000, NeilBrown wrote:
> > > Being "polite" without being "nice" is quite possible.
> > > It even has a name:  Diplomacy.
> > 
> > And we all know how circular/indirect/implied/useless
> > some of those diplomatic conversations can be.
> > 
> > Just remember to bring a 'Big Stick' and don't be shy
> > when it's necessary to display it.
> 
> The behaviour you appear to be advocating is what is generally called
> "bullying".

Nope.  It's called not being a pushover and being
direct, clear and not just being unnecessarily forceful.

I also think that depends on "when it's necessary".
That comes after speaking softly, multiple times.

cheers, Joe


^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [ 00/19] 3.10.1-stable review
  2013-07-15 23:50                 ` Joe Perches
@ 2013-07-16  1:54                   ` NeilBrown
  2013-07-16  2:01                     ` Joe Perches
  2013-07-17  7:01                   ` CAI Qian
  1 sibling, 1 reply; 213+ messages in thread
From: NeilBrown @ 2013-07-16  1:54 UTC (permalink / raw)
  To: Joe Perches
  Cc: Steven Rostedt, J. Bruce Fields, Linus Torvalds, Sarah Sharp,
	Ingo Molnar, Guenter Roeck, Greg Kroah-Hartman, Dave Jones,
	Linux Kernel Mailing List, Andrew Morton, stable, Darren Hart

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

On Mon, 15 Jul 2013 16:50:52 -0700 Joe Perches <joe@perches.com> wrote:

> On Tue, 2013-07-16 at 09:42 +1000, NeilBrown wrote:
> > Being "polite" without being "nice" is quite possible.
> > It even has a name:  Diplomacy.
> 
> And we all know how circular/indirect/implied/useless
> some of those diplomatic conversations can be.
> 
> Just remember to bring a 'Big Stick' and don't be shy
> when it's necessary to display it.

The behaviour you appear to be advocating is what is generally called
"bullying".  I think that is what started this thread.

NeilBrown

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [ 00/19] 3.10.1-stable review
  2013-07-15 23:42               ` NeilBrown
@ 2013-07-15 23:50                 ` Joe Perches
  2013-07-16  1:54                   ` NeilBrown
  2013-07-17  7:01                   ` CAI Qian
  0 siblings, 2 replies; 213+ messages in thread
From: Joe Perches @ 2013-07-15 23:50 UTC (permalink / raw)
  To: NeilBrown
  Cc: Steven Rostedt, J. Bruce Fields, Linus Torvalds, Sarah Sharp,
	Ingo Molnar, Guenter Roeck, Greg Kroah-Hartman, Dave Jones,
	Linux Kernel Mailing List, Andrew Morton, stable, Darren Hart

On Tue, 2013-07-16 at 09:42 +1000, NeilBrown wrote:
> Being "polite" without being "nice" is quite possible.
> It even has a name:  Diplomacy.

And we all know how circular/indirect/implied/useless
some of those diplomatic conversations can be.

Just remember to bring a 'Big Stick' and don't be shy
when it's necessary to display it.


^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [ 00/19] 3.10.1-stable review
  2013-07-15 19:19             ` Steven Rostedt
@ 2013-07-15 23:42               ` NeilBrown
  2013-07-15 23:50                 ` Joe Perches
  0 siblings, 1 reply; 213+ messages in thread
From: NeilBrown @ 2013-07-15 23:42 UTC (permalink / raw)
  To: Steven Rostedt
  Cc: J. Bruce Fields, Linus Torvalds, Sarah Sharp, Ingo Molnar,
	Guenter Roeck, Greg Kroah-Hartman, Dave Jones,
	Linux Kernel Mailing List, Andrew Morton, stable, Darren Hart

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

On Mon, 15 Jul 2013 15:19:44 -0400 Steven Rostedt <rostedt@goodmis.org> wrote:

> On Mon, 2013-07-15 at 15:05 -0400, J. Bruce Fields wrote:
> 
> > "Nice", "subtle", and "polite" all seem mostly orthogonal to me.
> > 
> 
> "Nice" and "polite" are rather attached.

Being "polite" without being "nice" is quite possible.  It even has a name:
 Diplomacy.

NeilBrown

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [ 00/19] 3.10.1-stable review
  2013-07-15 19:23               ` Linus Torvalds
  2013-07-15 19:39                 ` Willy Tarreau
@ 2013-07-15 22:50                 ` Raymond Jennings
  2013-07-16  4:52                 ` Rusty Russell
  2 siblings, 0 replies; 213+ messages in thread
From: Raymond Jennings @ 2013-07-15 22:50 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Willy Tarreau, Sarah Sharp, Ingo Molnar, Guenter Roeck,
	Greg Kroah-Hartman, Steven Rostedt, Dave Jones,
	Linux Kernel Mailing List, Andrew Morton, stable, Darren Hart

On Mon, 2013-07-15 at 12:23 -0700, Linus Torvalds wrote:
> On Mon, Jul 15, 2013 at 12:17 PM, Willy Tarreau <w@1wt.eu> wrote:
> >
> > BTW, I was amazed that you managed to get him have a much softer tone inr
> > his last e-mail, you probably found a weakness here in his management
> > process :-)
> 
> Hey, I _like_ arguing, and "cursing" and "arguing" are actually not at
> all the same thing.
> 
> And I really don't tend to curse unless people are doing something
> stupid and annoying. If people have concerns and questions that I feel
> are valid, I'm more than happy to talk about it.
> 
> I curse when there isn't any argument. The cursing happens for the
> "you're so f*cking wrong that it's not even worth trying to make
> logical arguments about it, because you have no possible excuse" case.
> 
> .. and sometimes people surprise me and come back with a valid excuse
> after all. "My whole family died in a tragic freak accident and my
> pony got cancer, and I was distracted".

...At least with the recent SCOTUS ruling, if you took your pony to a
vet you wouldn't have to worry about Hasbro suing him for patent
infringement...

> And then I might even tell them I'm sorry.
> 
> No. Not really.
> 
>            Linus
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/



^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [ 00/19] 3.10.1-stable review
  2013-07-15 19:17             ` Willy Tarreau
  2013-07-15 19:23               ` Linus Torvalds
@ 2013-07-15 22:40               ` NeilBrown
  2013-07-16  6:13                 ` Willy Tarreau
  1 sibling, 1 reply; 213+ messages in thread
From: NeilBrown @ 2013-07-15 22:40 UTC (permalink / raw)
  To: Willy Tarreau
  Cc: Sarah Sharp, Linus Torvalds, Ingo Molnar, Guenter Roeck,
	Greg Kroah-Hartman, Steven Rostedt, Dave Jones,
	Linux Kernel Mailing List, Andrew Morton, stable, Darren Hart

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

On Mon, 15 Jul 2013 21:17:27 +0200 Willy Tarreau <w@1wt.eu> wrote:

> Communication works two ways.

I understand that to mean (at least) that for communication, every message
must be both sent and received.  So when constructing a message, it is
important to think about how others will understand it.
On a public email list there are an awful lot of "others", and it is very
likely that any possible misunderstanding will be experienced by someone.
I think it best to minimise opportunities for misunderstanding.

> 
> Sure it can be hard for newcomers but I don't remember having read him
> scold a newcomer. 

I think that is not relevant.  He is scolding people senior developers in
front of newcomers.  That is not likely to encourage people to want to become
senior developers.

Anecdote:  My son (in highschool) is doing a psych assignment where he is
asking people to complete a survey which, among other things, asks about
people fear/anxiety response to various situations (it is a fairly standard
instrument I think[1]).  Last few times he checked, the situation with the
highest average score was "One person bullying another".  Really, it isn't
nice to watch.

NeilBrown

[1] e.g.
http://horan.asu.edu/ced522readings/ced-fearquestionnaire.htm

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [ 00/19] 3.10.1-stable review
  2013-07-15 20:41                 ` Sarah Sharp
  2013-07-15 21:01                   ` Kees Cook
@ 2013-07-15 21:50                   ` Linus Torvalds
  2013-07-18 10:39                     ` Ingo Molnar
  2013-07-16 14:30                   ` Geert Uytterhoeven
  2 siblings, 1 reply; 213+ messages in thread
From: Linus Torvalds @ 2013-07-15 21:50 UTC (permalink / raw)
  To: Sarah Sharp
  Cc: Ingo Molnar, Guenter Roeck, Greg Kroah-Hartman, Steven Rostedt,
	Dave Jones, Linux Kernel Mailing List, Andrew Morton, stable,
	Darren Hart

On Mon, Jul 15, 2013 at 1:41 PM, Sarah Sharp
<sarah.a.sharp@linux.intel.com> wrote:
>
> Oh, FFS, I just called out on private email for "playing the victim
> card".  I will repeat: this is not just about me, or other minorities.
> I should not have to ask for professional behavior on the mailing lists.
> Professional behavior should be the default.

Bullshit.

The thing is, the "victim card" is exactly about trying to enforce
your particular expectations on others, and trying to do so in a very
particular way. It's the old "think of the children" argument.  And
it's bogus.  Calling things "professional" is just more of the same -
trying to enforce some kind of convention on others by trying to claim
that it's the only acceptable way.

  [ Since you seem to want to keep this in public, I'll just
cut-and-paste from my reply, so you have already seen this part of my
argument, it's only slightly edited because now I'm no longer typing
on my cellphone ]

The thing is, different people act and react differently. On both
sides. And I think we should recognize that and also *allow* for that.
And sometimes it means, for example, that people interact primarily
with certain people that they like more - because they are a better
"fit".

I think we actually do it very naturally, simply because we are human,
and this is how people interact in real life too. Sometimes we do it
consciously - the way we have people at various companies that act as
go-betweens - but most of the time we do it just because humans are
all about social interactions and we don't even think about what we do
and why.

For example, you work mostly through Greg. I don't think either of you
*planned* it that way, but it's likely because you guys work well
together.

See what I'm saying? People are different. I'm not polite, and I get
upset easily but generally don't hold a grudge - I have these
explosive emails. And that works well for some people. And it probably
doesn't work well with you.

And you know what? That's fine. Not everybody had to get along or work
well with each other. But the fact that it doesn't work with you
doesn't make it "wrong".

This isn't all that different from working around language issues etc
by having certain people work as in-betweens on that front.

And where we differ is in thinking either side has to necessarily
change. You think people need to act "nicer". While I think it's
*natural* that people have different behavior - and different
expectations. We all have issues somewhere and don't all like each
other. There are certain people I refuse to work with, for example.
They may be good engineers, but they just aren't people I can work
with.

And hey, I don't actually think we've personally even had any
problems. And I realize that you may react very strongly and get
nervous about us having problems, but realistically, do you actually
expect to like all the other kernel engineers?

And equally importantly, not everybody has to like you, or necessarily
think they have to be liked by you. OK?

So as far as I'm concerned, the discussion is about "how to work
together DESPITE people being different". Not about trying to make
everybody please each other. Because I can pretty much guarantee that
I'll continue cursing. To me, the discussion would be about how to
work together despite these kinds of cultural differences, not about
"how do we make everybody nice and sing songs sound the campfire"

Do you think you might be interested in *that* kind of discussion
instead of the "you are abusing me" kind of discussion?

Because if you want me to "act professional", I can tell you that I'm
not interested. I'm sitting in my home office wearign a bathrobe. The
same way I'm not going to start wearing ties, I'm *also* not going to
buy into the fake politeness, the lying, the office politics and
backstabbing, the passive aggressiveness, and the buzzwords. Because
THAT is what "acting professionally" results in: people resort to all
kinds of really nasty things because they are forced to act out their
normal urges in unnatural ways.

               Linus

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [ 00/19] 3.10.1-stable review
  2013-07-15 20:41                 ` Sarah Sharp
@ 2013-07-15 21:01                   ` Kees Cook
  2013-07-15 21:50                   ` Linus Torvalds
  2013-07-16 14:30                   ` Geert Uytterhoeven
  2 siblings, 0 replies; 213+ messages in thread
From: Kees Cook @ 2013-07-15 21:01 UTC (permalink / raw)
  To: Sarah Sharp
  Cc: Linus Torvalds, Ingo Molnar, Guenter Roeck, Greg Kroah-Hartman,
	Steven Rostedt, Dave Jones, Linux Kernel Mailing List,
	Andrew Morton, stable, Darren Hart

On Mon, Jul 15, 2013 at 01:41:35PM -0700, Sarah Sharp wrote:
> "The standard you walk past is the standard you accept."

I think this sums up the situation very well. Even if we accept that some
people can "correctly" choose when to be abusive, it creates an atmosphere
where other people will come to think that kind of thing is okay.

I always enjoyed this presentation about maintaining a good social tone
in an online community:
http://www.slideshare.net/vishnu/how-to-protect-yourhow-to-protect-your-open-source-project-from-poisonous-people

People's mistakes can be pointed out without the kind of abuse I've
read on lkml. People need to know the severity of problems they create,
and almost never are those problems _intentional_ (which would still
require one to one accept that it's okay to be abusive as a form of
"self defense"). Expecting people to change their behaviors, methods, or
practices in order to avoid mistakes seems like a reasonable thing. This
is how I've tried to fix my stupid mistakes when I encounter them or
they're pointed out.

When someone cuts me off in traffic, I assume they're oblivious rather
than malicious. If I drove 8 hours a day, I'm sure my resolve to accept
and understand these mistakes would erode over time, but I still think
it would be more productive to let them know it was uncool with a short
honk rather than trying to ram them. :)

-Kees

-- 
Kees Cook                                            @outflux.net

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [ 00/19] 3.10.1-stable review
  2013-07-15 19:53               ` Sarah Sharp
@ 2013-07-15 20:41                 ` Sarah Sharp
  2013-07-15 21:01                   ` Kees Cook
                                     ` (2 more replies)
  2013-07-18  0:42                 ` Thomas Gleixner
  2013-07-24 10:43                 ` Florian Holz
  2 siblings, 3 replies; 213+ messages in thread
From: Sarah Sharp @ 2013-07-15 20:41 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Ingo Molnar, Guenter Roeck, Greg Kroah-Hartman, Steven Rostedt,
	Dave Jones, Linux Kernel Mailing List, Andrew Morton, stable,
	Darren Hart

On Mon, Jul 15, 2013 at 12:53:16PM -0700, Sarah Sharp wrote:
> Good lord.  So anyone that is one of your "top maintainers" could be
> exposed to your verbal abuse just because they "should have known
> better"?
> 
> You know what the definition of an abuser is?  Someone that seeks out
> victims that they know will "just take it" and keep the abuse "between
> the two of them".  They pick victims that won't fight back or report the
> abuse.

Oh, FFS, I just called out on private email for "playing the victim
card".  I will repeat: this is not just about me, or other minorities.
I should not have to ask for professional behavior on the mailing lists.
Professional behavior should be the default.

"The standard you walk past is the standard you accept."

http://www.smh.com.au/federal-politics/political-news/unlikely-feminist-hero-army-chiefs-video-message-draws-plaudits-20130614-2o86b.html

"Those who think that it is ok to behave in a way that demeans or
exploits their colleagues have no place in this army. If that does not
suit you, then get out.

The same goes for those that think that toughness is built on
humiliating others.  Every one of us is responsible for the culture and
reputation of our Army, and the environment in which we work. If you
become aware of any individual degrading another, then show moral
courage and take a stand against it."

> In karate, or any other sport, if your opponent is motionless on the
> floor, you stop.  You can't see the person you're emailing.  You can't
> see if the first conversation-disabling blow has completely knocked them
> out.  You can't see if you've misjudged their mental strength for the
> day and completely wiped out their ability to use their brain to correct
> the technical mistake you're trying to get them to fix.
> 
> Ask them to fix their mistake.  If they protest, then lay into them.  If
> you *know* they don't take verbal abuse well, don't.

Sarah Sharp

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [ 00/19] 3.10.1-stable review
  2013-07-15 19:07             ` Linus Torvalds
@ 2013-07-15 19:53               ` Sarah Sharp
  2013-07-15 20:41                 ` Sarah Sharp
                                   ` (2 more replies)
  2013-07-16 14:45               ` Alex Elder
  1 sibling, 3 replies; 213+ messages in thread
From: Sarah Sharp @ 2013-07-15 19:53 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Ingo Molnar, Guenter Roeck, Greg Kroah-Hartman, Steven Rostedt,
	Dave Jones, Linux Kernel Mailing List, Andrew Morton, stable,
	Darren Hart

On Mon, Jul 15, 2013 at 12:07:56PM -0700, Linus Torvalds wrote:
> On Mon, Jul 15, 2013 at 11:46 AM, Sarah Sharp
> <sarah.a.sharp@linux.intel.com> wrote:
> >
> > Bullshit.  I've seen you be polite, and explain to clueless maintainers
> > why there's no way you can revert their merge that caused regressions,
> > and ask them to fit it without resorting to tearing them down
> > emotionally:
> 
> Oh, I'll be polite when it's called for.
> 
> But when people who know better send me crap, I'll curse at them.
> 
> I suspect you'll notice me cursing *way* more at top developers than
> random people on the list. I expect more from them, and conversely
> I'll be a lot more upset when they do something that I really think
> was not great.
> 
> For example, my latest cursing explosion was for the x86 maintainers,
> and it comes from the fact that I *know* they know to do better. The
> x86 tip pulls have generally been through way more testing than most
> other pulls I get (not just compiling, but even booting randconfigs
> etc). So when an x86 pull request comes in that clearly missed that
> expected level of quality, I go to town.

Good lord.  So anyone that is one of your "top maintainers" could be
exposed to your verbal abuse just because they "should have known
better"?

You know what the definition of an abuser is?  Someone that seeks out
victims that they know will "just take it" and keep the abuse "between
the two of them".  They pick victims that won't fight back or report the
abuse.

> Similarly, you will see fireworks if some long-term maintainer makes
> excuses for breaking user space etc. That will make me go into
> incoherent rages.
> 
> The "polite Linus" example that you point to? That was a maintainer
> asking for direction for when things went wrong and *before* sending
> me something dubious. Of course I'm polite then.
> 
> Sarah, I don't have Tourettes syndrome. You seem to think that my
> cursing is uncontrolled and random. I argue that it has causes. Big
> difference.

It does not matter if your cursing fits have causes.  The fact is that
if you misjudge someone's emotional state for the day, you yelling at
them is not productive.

In karate, or any other sport, if your opponent is motionless on the
floor, you stop.  You can't see the person you're emailing.  You can't
see if the first conversation-disabling blow has completely knocked them
out.  You can't see if you've misjudged their mental strength for the
day and completely wiped out their ability to use their brain to correct
the technical mistake you're trying to get them to fix.

Ask them to fix their mistake.  If they protest, then lay into them.  If
you *know* they don't take verbal abuse well, don't.

Let's get this personal baggage out of the way right now, before anyone
else brings it up:

I've been through verbal abuse before.  I won't take that shit from you,
or any of the other Linux kernel developers.  Tell me, politely, what I
have done wrong, and I will fix it.  You don't need to SHOUT, call me
names, or tell me to SHUT THE FUCK UP!

I'm not the only one that won't take verbal abuse.  Stop abusing your
developers.

Sarah Sharp

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [ 00/19] 3.10.1-stable review
  2013-07-15 19:23               ` Linus Torvalds
@ 2013-07-15 19:39                 ` Willy Tarreau
  2013-07-15 22:50                 ` Raymond Jennings
  2013-07-16  4:52                 ` Rusty Russell
  2 siblings, 0 replies; 213+ messages in thread
From: Willy Tarreau @ 2013-07-15 19:39 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Sarah Sharp, Ingo Molnar, Guenter Roeck, Greg Kroah-Hartman,
	Steven Rostedt, Dave Jones, Linux Kernel Mailing List,
	Andrew Morton, stable, Darren Hart

On Mon, Jul 15, 2013 at 12:23:05PM -0700, Linus Torvalds wrote:
> On Mon, Jul 15, 2013 at 12:17 PM, Willy Tarreau <w@1wt.eu> wrote:
> >
> > BTW, I was amazed that you managed to get him have a much softer tone inr
> > his last e-mail, you probably found a weakness here in his management
> > process :-)
> 
> Hey, I _like_ arguing, and "cursing" and "arguing" are actually not at
> all the same thing.
> 
> And I really don't tend to curse unless people are doing something
> stupid and annoying. If people have concerns and questions that I feel
> are valid, I'm more than happy to talk about it.

Oh I know, you've even kindly helped me a few times backporting fixes for
things I absolutely did not understand and took the time to explain to me.
So I have nothing against your communication mode, quite the opposite, and
people who know me know that mine has some similarities (a bit less extreme
in wording though). I'm used to say that I prefer to discuss with people who
I disagree with because they're those from whom there is more to learn, and
they're the most likely to make me change my opinions.

> I curse when there isn't any argument. The cursing happens for the
> "you're so f*cking wrong that it's not even worth trying to make
> logical arguments about it, because you have no possible excuse" case.
> 
> .. and sometimes people surprise me and come back with a valid excuse
> after all. "My whole family died in a tragic freak accident and my
> pony got cancer, and I was distracted".

Not a valid excuse, the patch should not have been sent in the first
place :-)

Willy


^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [ 00/19] 3.10.1-stable review
  2013-07-15 19:17             ` Willy Tarreau
@ 2013-07-15 19:23               ` Linus Torvalds
  2013-07-15 19:39                 ` Willy Tarreau
                                   ` (2 more replies)
  2013-07-15 22:40               ` NeilBrown
  1 sibling, 3 replies; 213+ messages in thread
From: Linus Torvalds @ 2013-07-15 19:23 UTC (permalink / raw)
  To: Willy Tarreau
  Cc: Sarah Sharp, Ingo Molnar, Guenter Roeck, Greg Kroah-Hartman,
	Steven Rostedt, Dave Jones, Linux Kernel Mailing List,
	Andrew Morton, stable, Darren Hart

On Mon, Jul 15, 2013 at 12:17 PM, Willy Tarreau <w@1wt.eu> wrote:
>
> BTW, I was amazed that you managed to get him have a much softer tone inr
> his last e-mail, you probably found a weakness here in his management
> process :-)

Hey, I _like_ arguing, and "cursing" and "arguing" are actually not at
all the same thing.

And I really don't tend to curse unless people are doing something
stupid and annoying. If people have concerns and questions that I feel
are valid, I'm more than happy to talk about it.

I curse when there isn't any argument. The cursing happens for the
"you're so f*cking wrong that it's not even worth trying to make
logical arguments about it, because you have no possible excuse" case.

.. and sometimes people surprise me and come back with a valid excuse
after all. "My whole family died in a tragic freak accident and my
pony got cancer, and I was distracted".

And then I might even tell them I'm sorry.

No. Not really.

           Linus

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [ 00/19] 3.10.1-stable review
  2013-07-15 19:05           ` J. Bruce Fields
@ 2013-07-15 19:19             ` Steven Rostedt
  2013-07-15 23:42               ` NeilBrown
  0 siblings, 1 reply; 213+ messages in thread
From: Steven Rostedt @ 2013-07-15 19:19 UTC (permalink / raw)
  To: J. Bruce Fields
  Cc: Linus Torvalds, Sarah Sharp, Ingo Molnar, Guenter Roeck,
	Greg Kroah-Hartman, Dave Jones, Linux Kernel Mailing List,
	Andrew Morton, stable, Darren Hart

On Mon, 2013-07-15 at 15:05 -0400, J. Bruce Fields wrote:

> "Nice", "subtle", and "polite" all seem mostly orthogonal to me.
> 

"Nice" and "polite" are rather attached. But "subtle" is orthogonal, as
in....


 "Fuck you, subtly"

-- Steve



^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [ 00/19] 3.10.1-stable review
  2013-07-15 18:46           ` Sarah Sharp
  2013-07-15 19:07             ` Steven Rostedt
  2013-07-15 19:07             ` Linus Torvalds
@ 2013-07-15 19:17             ` Willy Tarreau
  2013-07-15 19:23               ` Linus Torvalds
  2013-07-15 22:40               ` NeilBrown
  2013-07-16  2:44             ` Li Zefan
  3 siblings, 2 replies; 213+ messages in thread
From: Willy Tarreau @ 2013-07-15 19:17 UTC (permalink / raw)
  To: Sarah Sharp
  Cc: Linus Torvalds, Ingo Molnar, Guenter Roeck, Greg Kroah-Hartman,
	Steven Rostedt, Dave Jones, Linux Kernel Mailing List,
	Andrew Morton, stable, Darren Hart

Hello Sarah,

On Mon, Jul 15, 2013 at 11:46:42AM -0700, Sarah Sharp wrote:
> On Mon, Jul 15, 2013 at 11:17:06AM -0700, Linus Torvalds wrote:
> > On Mon, Jul 15, 2013 at 11:04 AM, Sarah Sharp
> > <sarah.a.sharp@linux.intel.com> wrote:
> > >
> > > However, I am serious about this.  Linus, you're one of the worst
> > > offenders when it comes to verbally abusing people and publicly tearing
> > > their emotions apart.
> > 
> > Yes. And I do it partly (mostly) because it's who I am, and partly
> > because I honestly despise being subtle or "nice".
> > 
> > The fact is, people need to know what my position on things are. And I
> > can't just say "please don't do that", because people won't listen. I
> > say "On the internet, nobody can hear you being subtle", and I mean
> > it.
> > 
> > And I definitely am not willing to string people along, either. I've
> > had that happen too - not telling people clearly enough that I don't
> > like their approach, they go on to re-architect something, and get
> > really upset when I am then not willing to take their work.
> 
> You can tell developers in no uncertain terms that you're not willing to
> take their work *without* verbally tearing them apart.  You're Linus
> Torvalds, for crying out loud!  I simple, "No, that's a bad idea, stop
> working on this RIGHT now," is more than enough from you.  If it's not,
> well, those people are just dense and can probably put up with stronger
> language.

Communication works two ways. You feel emotions based on your references
and on the references you're used from the other person. Most of us have
already been scolded by Linus, and while it usually is an unpleasant moment,
I do think that it's efficient and (it might surprise you) probably a mark
of respect. Please re-read some of the famous public flames from Linus.
When he tells you "stop saying such idiocies, you're a f*cking moron", he
doesn't really mean that, he means that he's very disappointed that *that
person* says this or that, so he takes the time to say it to that person.
The proof is that most often in the next mail he explains to the person
how to do the thing right. He just tries to ensure that the person he's
telling words to understands that he/she has crossed a line.

Sure it can be hard for newcomers but I don't remember having read him
scold a newcomer. So that's probably not that much of a problem in the
end, and helps getting the things done in time. I'm much more concerned
by the "administrative" development mode that we're taking in fact and
that some people seem to have expressed in this thread (what patch flow
to follow, when to send/not to send, etc...).

BTW, I was amazed that you managed to get him have a much softer tone inr
his last e-mail, you probably found a weakness here in his management
process :-)

Best regards,
Willy


^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [ 00/19] 3.10.1-stable review
  2013-07-15 18:46           ` Sarah Sharp
  2013-07-15 19:07             ` Steven Rostedt
@ 2013-07-15 19:07             ` Linus Torvalds
  2013-07-15 19:53               ` Sarah Sharp
  2013-07-16 14:45               ` Alex Elder
  2013-07-15 19:17             ` Willy Tarreau
  2013-07-16  2:44             ` Li Zefan
  3 siblings, 2 replies; 213+ messages in thread
From: Linus Torvalds @ 2013-07-15 19:07 UTC (permalink / raw)
  To: Sarah Sharp
  Cc: Ingo Molnar, Guenter Roeck, Greg Kroah-Hartman, Steven Rostedt,
	Dave Jones, Linux Kernel Mailing List, Andrew Morton, stable,
	Darren Hart

On Mon, Jul 15, 2013 at 11:46 AM, Sarah Sharp
<sarah.a.sharp@linux.intel.com> wrote:
>
> Bullshit.  I've seen you be polite, and explain to clueless maintainers
> why there's no way you can revert their merge that caused regressions,
> and ask them to fit it without resorting to tearing them down
> emotionally:

Oh, I'll be polite when it's called for.

But when people who know better send me crap, I'll curse at them.

I suspect you'll notice me cursing *way* more at top developers than
random people on the list. I expect more from them, and conversely
I'll be a lot more upset when they do something that I really think
was not great.

For example, my latest cursing explosion was for the x86 maintainers,
and it comes from the fact that I *know* they know to do better. The
x86 tip pulls have generally been through way more testing than most
other pulls I get (not just compiling, but even booting randconfigs
etc). So when an x86 pull request comes in that clearly missed that
expected level of quality, I go to town.

Similarly, you will see fireworks if some long-term maintainer makes
excuses for breaking user space etc. That will make me go into
incoherent rages.

The "polite Linus" example that you point to? That was a maintainer
asking for direction for when things went wrong and *before* sending
me something dubious. Of course I'm polite then.

Sarah, I don't have Tourettes syndrome. You seem to think that my
cursing is uncontrolled and random. I argue that it has causes. Big
difference.

            Linus

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [ 00/19] 3.10.1-stable review
  2013-07-15 18:46           ` Sarah Sharp
@ 2013-07-15 19:07             ` Steven Rostedt
  2013-07-15 19:07             ` Linus Torvalds
                               ` (2 subsequent siblings)
  3 siblings, 0 replies; 213+ messages in thread
From: Steven Rostedt @ 2013-07-15 19:07 UTC (permalink / raw)
  To: Sarah Sharp
  Cc: Linus Torvalds, Ingo Molnar, Guenter Roeck, Greg Kroah-Hartman,
	Dave Jones, Linux Kernel Mailing List, Andrew Morton, stable,
	Darren Hart

On Mon, 2013-07-15 at 11:46 -0700, Sarah Sharp wrote:

> *Snort*.  Perhaps we haven't interacted very often, but I have never
> seen you be nice in person at KS.  Well, there was that one time you
> came to me and very quietly explained you had a problem with your USB
> 3.0 ports, but you came off as "scared to talk to a girl kernel
> developer" more than "I'm trying to be polite".
> 

After this email thread, I think I just added you as one of the kernel
developers that scare me ;-)

-- Steve



^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [ 00/19] 3.10.1-stable review
  2013-07-15 18:17         ` Linus Torvalds
  2013-07-15 18:46           ` Sarah Sharp
@ 2013-07-15 19:05           ` J. Bruce Fields
  2013-07-15 19:19             ` Steven Rostedt
  2013-07-17  8:39           ` Janne Karhunen
  2 siblings, 1 reply; 213+ messages in thread
From: J. Bruce Fields @ 2013-07-15 19:05 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Sarah Sharp, Ingo Molnar, Guenter Roeck, Greg Kroah-Hartman,
	Steven Rostedt, Dave Jones, Linux Kernel Mailing List,
	Andrew Morton, stable, Darren Hart

On Mon, Jul 15, 2013 at 11:17:06AM -0700, Linus Torvalds wrote:
> On Mon, Jul 15, 2013 at 11:04 AM, Sarah Sharp
> <sarah.a.sharp@linux.intel.com> wrote:
> >
> > However, I am serious about this.  Linus, you're one of the worst
> > offenders when it comes to verbally abusing people and publicly tearing
> > their emotions apart.
> 
> Yes. And I do it partly (mostly) because it's who I am, and partly
> because I honestly despise being subtle or "nice".

"Nice", "subtle", and "polite" all seem mostly orthogonal to me.

> The fact is, people need to know what my position on things are. And I
> can't just say "please don't do that", because people won't listen. I
> say "On the internet, nobody can hear you being subtle", and I mean
> it.

And "please don't do that" isn't very subtle.

--b.

> 
> And I definitely am not willing to string people along, either. I've
> had that happen too - not telling people clearly enough that I don't
> like their approach, they go on to re-architect something, and get
> really upset when I am then not willing to take their work.
> 
> Sarah, first off, I don't have that many tools at hand. Secondly, I
> simply don't believe in being polite or politically correct. And you
> can point at all those cultural factors where some cultures are not
> happy with confrontation (and feel free to make it about gender too -
> I think that's almost entirely cultural too). And please bring up
> "cultural sensitivity" while at it. And I'll give you back that same
> "cultural sensitivity". Please be sensitive to _my_ culture too.
> 
> Google "management by perkele".
> 
> Do you really want to oppress a minority? Because Finns are a minority
> compared to almost any other country. If you want to talk cultural
> sensitivity, I'll join you. But my culture includes cursing.
> 
> And some of the above is written tonge-in-cheek, but all of it is also
> serious. I really fundamentally believe that being honest and open
> about your emotions about core/process is good. And because it's damn
> hard to read people over email, I think you need to be *more* honest
> and *more* open over email. I'm generally nicer in person. Not always.
> 
> And yes, I'll happily be part of the discussion at the KS. But I think
> you also need to be aware that your "high horse" isn't necessarily all
> that high.
> 
>               Linus
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [ 00/19] 3.10.1-stable review
  2013-07-15 15:52 Sarah Sharp
  2013-07-15 17:08 ` Linus Torvalds
  2013-07-15 17:33 ` Darren Hart
@ 2013-07-15 19:04 ` Rob Landley
  2013-07-19 11:25   ` Ingo Molnar
  2013-07-23  8:26 ` Rogelio Serrano
  3 siblings, 1 reply; 213+ messages in thread
From: Rob Landley @ 2013-07-15 19:04 UTC (permalink / raw)
  To: Sarah Sharp
  Cc: Linus Torvalds, Ingo Molnar, Guenter Roeck, Greg Kroah-Hartman,
	Steven Rostedt, Dave Jones, Linux Kernel Mailing List,
	Andrew Morton, stable, Darren Hart

On 07/15/2013 10:52:48 AM, Sarah Sharp wrote:
> On Fri, 12 Jul 2013 18:17:08 +0200, Ingo Molnar <mingo@kernel.org>  
> wrote:
> > * Linus Torvalds <torvalds@linux-foundation.org> wrote:
> Let's discuss this at Kernel Summit where we can at least yell at each
> other in person.  Yeah, just try yelling at me about this.  I'll roar
> right back, louder, for all the people who lose their voice when they
> get yelled at by top maintainers.  I won't be the nice girl anymore.

Not _all_ of us lose our voice when yelled at by Linus's lieutenants.  
Some of us just post updates to the same darn patch series for 5 years  
(yes really; my perl removal series started in 2008 and was applied  
earlier this year), on the theory it's useful to the people actually  
applying it to their own trees (at one point, gentoo), and that someday  
the stars might be right and cthulu will arise from the deep and accept  
the patch series into his tree. (Or in my case, Andrew Morton.)

Hoping initmpfs has an easier time of it, it's already being used in  
supercomputers.

Rob

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [ 00/19] 3.10.1-stable review
  2013-07-15 18:17         ` Linus Torvalds
@ 2013-07-15 18:46           ` Sarah Sharp
  2013-07-15 19:07             ` Steven Rostedt
                               ` (3 more replies)
  2013-07-15 19:05           ` J. Bruce Fields
  2013-07-17  8:39           ` Janne Karhunen
  2 siblings, 4 replies; 213+ messages in thread
From: Sarah Sharp @ 2013-07-15 18:46 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Ingo Molnar, Guenter Roeck, Greg Kroah-Hartman, Steven Rostedt,
	Dave Jones, Linux Kernel Mailing List, Andrew Morton, stable,
	Darren Hart

On Mon, Jul 15, 2013 at 11:17:06AM -0700, Linus Torvalds wrote:
> On Mon, Jul 15, 2013 at 11:04 AM, Sarah Sharp
> <sarah.a.sharp@linux.intel.com> wrote:
> >
> > However, I am serious about this.  Linus, you're one of the worst
> > offenders when it comes to verbally abusing people and publicly tearing
> > their emotions apart.
> 
> Yes. And I do it partly (mostly) because it's who I am, and partly
> because I honestly despise being subtle or "nice".
> 
> The fact is, people need to know what my position on things are. And I
> can't just say "please don't do that", because people won't listen. I
> say "On the internet, nobody can hear you being subtle", and I mean
> it.
> 
> And I definitely am not willing to string people along, either. I've
> had that happen too - not telling people clearly enough that I don't
> like their approach, they go on to re-architect something, and get
> really upset when I am then not willing to take their work.

You can tell developers in no uncertain terms that you're not willing to
take their work *without* verbally tearing them apart.  You're Linus
Torvalds, for crying out loud!  I simple, "No, that's a bad idea, stop
working on this RIGHT now," is more than enough from you.  If it's not,
well, those people are just dense and can probably put up with stronger
language.

> Sarah, first off, I don't have that many tools at hand. Secondly, I
> simply don't believe in being polite or politically correct.

Bullshit.  I've seen you be polite, and explain to clueless maintainers
why there's no way you can revert their merge that caused regressions,
and ask them to fit it without resorting to tearing them down
emotionally:

http://marc.info/?l=linux-kernel&m=136130347127908&w=2

You just don't want to take the time to be polite to everyone.  Don't
give me the "I'm not polite" card.  Go write some documentation about
what's acceptable for stable.  While you're at it, write some more
documentation about why it's impossible for you to revert merges, so
maintainers know not to send you crap, or piss away time trying to argue
with you that they don't need to fix regressions.  When maintainers
challenge you, point them to it, and say, "Fix this now."

If they protest, then you can bring out the big threats and say, "If you
don't fix this, I won't pull from you the next merge window.  Go find a
backup maintainer that can handle your tree, and train them for the next
release.  You may need to hand over your maintainership to them."

If the maintainer doesn't have sub-maintainers that could take over,
that's a problem we need to fix *before* things like this happen.  We
should discuss which kernel subsystems don't have backups at KS.

There are other tools at hand.  You just don't use them.

> And you can point at all those cultural factors where some cultures
> are not happy with confrontation (and feel free to make it about
> gender too - I think that's almost entirely cultural too). And please
> bring up "cultural sensitivity" while at it. And I'll give you back
> that same "cultural sensitivity". Please be sensitive to _my_ culture
> too.
> 
> Google "management by perkele".
> 
> Do you really want to oppress a minority? Because Finns are a minority
> compared to almost any other country. If you want to talk cultural
> sensitivity, I'll join you. But my culture includes cursing.

Did I mention minorities here at all?  Nope.  My only comment was that I
wasn't going to be a "nice girl" anymore, which is a comment about my
personality, not about the discussion at hand.

*No one* deserves to be yelled at IN ALL CAPS in email, or publicly
ridiculed.  It doesn't matter if they are a minority or not.

You are in a position of power.  Stop verbally abusing your developers.

> And some of the above is written tonge-in-cheek, but all of it is also
> serious. I really fundamentally believe that being honest and open
> about your emotions about core/process is good. And because it's damn
> hard to read people over email, I think you need to be *more* honest
> and *more* open over email. I'm generally nicer in person. Not always.

*Snort*.  Perhaps we haven't interacted very often, but I have never
seen you be nice in person at KS.  Well, there was that one time you
came to me and very quietly explained you had a problem with your USB
3.0 ports, but you came off as "scared to talk to a girl kernel
developer" more than "I'm trying to be polite".

> And yes, I'll happily be part of the discussion at the KS. But I think
> you also need to be aware that your "high horse" isn't necessarily all
> that high.

Dude, I'm not on a horse here.  I'm not asking you to change your
communication styles in order to help minorities.  I'm not some crazy
feminist ranting about cooties on Google+.

I'm trying to improve the kernel mailing lists for all developers.  We
can give negative technical feedback without verbal abuse.

Sarah Sharp

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [ 00/19] 3.10.1-stable review
  2013-07-15 17:08 ` Linus Torvalds
  2013-07-15 17:46   ` Sarah Sharp
@ 2013-07-15 18:22   ` Steven Rostedt
  1 sibling, 0 replies; 213+ messages in thread
From: Steven Rostedt @ 2013-07-15 18:22 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Sarah Sharp, Ingo Molnar, Guenter Roeck, Greg Kroah-Hartman,
	Dave Jones, Linux Kernel Mailing List, Andrew Morton, stable,
	Darren Hart

On Mon, 2013-07-15 at 10:08 -0700, Linus Torvalds wrote:

> Greg has taught you well. You have controlled your fear. Now, release
> your anger. Only your hatred can destroy me.
> 
> Come to the dark side, Sarah. We have cookies.

http://rostedt.homelinux.com/private/darth-cookie.png

-- Steve



^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [ 00/19] 3.10.1-stable review
  2013-07-15 18:04       ` Sarah Sharp
@ 2013-07-15 18:17         ` Linus Torvalds
  2013-07-15 18:46           ` Sarah Sharp
                             ` (2 more replies)
  0 siblings, 3 replies; 213+ messages in thread
From: Linus Torvalds @ 2013-07-15 18:17 UTC (permalink / raw)
  To: Sarah Sharp
  Cc: Ingo Molnar, Guenter Roeck, Greg Kroah-Hartman, Steven Rostedt,
	Dave Jones, Linux Kernel Mailing List, Andrew Morton, stable,
	Darren Hart

On Mon, Jul 15, 2013 at 11:04 AM, Sarah Sharp
<sarah.a.sharp@linux.intel.com> wrote:
>
> However, I am serious about this.  Linus, you're one of the worst
> offenders when it comes to verbally abusing people and publicly tearing
> their emotions apart.

Yes. And I do it partly (mostly) because it's who I am, and partly
because I honestly despise being subtle or "nice".

The fact is, people need to know what my position on things are. And I
can't just say "please don't do that", because people won't listen. I
say "On the internet, nobody can hear you being subtle", and I mean
it.

And I definitely am not willing to string people along, either. I've
had that happen too - not telling people clearly enough that I don't
like their approach, they go on to re-architect something, and get
really upset when I am then not willing to take their work.

Sarah, first off, I don't have that many tools at hand. Secondly, I
simply don't believe in being polite or politically correct. And you
can point at all those cultural factors where some cultures are not
happy with confrontation (and feel free to make it about gender too -
I think that's almost entirely cultural too). And please bring up
"cultural sensitivity" while at it. And I'll give you back that same
"cultural sensitivity". Please be sensitive to _my_ culture too.

Google "management by perkele".

Do you really want to oppress a minority? Because Finns are a minority
compared to almost any other country. If you want to talk cultural
sensitivity, I'll join you. But my culture includes cursing.

And some of the above is written tonge-in-cheek, but all of it is also
serious. I really fundamentally believe that being honest and open
about your emotions about core/process is good. And because it's damn
hard to read people over email, I think you need to be *more* honest
and *more* open over email. I'm generally nicer in person. Not always.

And yes, I'll happily be part of the discussion at the KS. But I think
you also need to be aware that your "high horse" isn't necessarily all
that high.

              Linus

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [ 00/19] 3.10.1-stable review
  2013-07-15 17:50     ` Linus Torvalds
@ 2013-07-15 18:04       ` Sarah Sharp
  2013-07-15 18:17         ` Linus Torvalds
  0 siblings, 1 reply; 213+ messages in thread
From: Sarah Sharp @ 2013-07-15 18:04 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Ingo Molnar, Guenter Roeck, Greg Kroah-Hartman, Steven Rostedt,
	Dave Jones, Linux Kernel Mailing List, Andrew Morton, stable,
	Darren Hart

On Mon, Jul 15, 2013 at 10:50:52AM -0700, Linus Torvalds wrote:
> On Mon, Jul 15, 2013 at 10:46 AM, Sarah Sharp
> <sarah.a.sharp@linux.intel.com> wrote:
> >
> > But, but, the light side has brownies.  Pot brownies that will make
> > everyone feel sleepy and peaceful and possibly hungry.  For more pot
> > brownies...
> 
> Hmm. Maybe we should have a BoF at the KS.
> 
> I'll bring the regular cookies.

Well, we're not in the Netherlands, so I don't think pot brownies could
be smuggled into KS. ;)

However, I am serious about this.  Linus, you're one of the worst
offenders when it comes to verbally abusing people and publicly tearing
their emotions apart.

http://marc.info/?l=linux-kernel&m=135628421403144&w=2
http://marc.info/?l=linux-acpi&m=136157944603147&w=2

I'm not going to put up with that shit any more.

Sarah Sharp

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [ 00/19] 3.10.1-stable review
  2013-07-15 17:46   ` Sarah Sharp
@ 2013-07-15 17:50     ` Linus Torvalds
  2013-07-15 18:04       ` Sarah Sharp
  0 siblings, 1 reply; 213+ messages in thread
From: Linus Torvalds @ 2013-07-15 17:50 UTC (permalink / raw)
  To: Sarah Sharp
  Cc: Ingo Molnar, Guenter Roeck, Greg Kroah-Hartman, Steven Rostedt,
	Dave Jones, Linux Kernel Mailing List, Andrew Morton, stable,
	Darren Hart

On Mon, Jul 15, 2013 at 10:46 AM, Sarah Sharp
<sarah.a.sharp@linux.intel.com> wrote:
>
> But, but, the light side has brownies.  Pot brownies that will make
> everyone feel sleepy and peaceful and possibly hungry.  For more pot
> brownies...

Hmm. Maybe we should have a BoF at the KS.

I'll bring the regular cookies.

               Linus

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [ 00/19] 3.10.1-stable review
  2013-07-15 17:08 ` Linus Torvalds
@ 2013-07-15 17:46   ` Sarah Sharp
  2013-07-15 17:50     ` Linus Torvalds
  2013-07-15 18:22   ` Steven Rostedt
  1 sibling, 1 reply; 213+ messages in thread
From: Sarah Sharp @ 2013-07-15 17:46 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Ingo Molnar, Guenter Roeck, Greg Kroah-Hartman, Steven Rostedt,
	Dave Jones, Linux Kernel Mailing List, Andrew Morton, stable,
	Darren Hart

On Mon, Jul 15, 2013 at 10:08:13AM -0700, Linus Torvalds wrote:
> On Mon, Jul 15, 2013 at 8:52 AM, Sarah Sharp
> <sarah.a.sharp@linux.intel.com> wrote:
> >
> >                                                             I'll roar
> > right back, louder, for all the people who lose their voice when they
> > get yelled at by top maintainers.  I won't be the nice girl anymore.
> 
> That's the spirit.
> 
> Greg has taught you well. You have controlled your fear. Now, release
> your anger. Only your hatred can destroy me.
> 
> Come to the dark side, Sarah. We have cookies.

But, but, the light side has brownies.  Pot brownies that will make
everyone feel sleepy and peaceful and possibly hungry.  For more pot
brownies...

Sarah Sharp

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [ 00/19] 3.10.1-stable review
  2013-07-15 15:52 Sarah Sharp
  2013-07-15 17:08 ` Linus Torvalds
@ 2013-07-15 17:33 ` Darren Hart
  2013-07-15 19:04 ` Rob Landley
  2013-07-23  8:26 ` Rogelio Serrano
  3 siblings, 0 replies; 213+ messages in thread
From: Darren Hart @ 2013-07-15 17:33 UTC (permalink / raw)
  To: Sarah Sharp
  Cc: Linus Torvalds, Ingo Molnar, Guenter Roeck, Greg Kroah-Hartman,
	Steven Rostedt, Dave Jones, Linux Kernel Mailing List,
	Andrew Morton, stable

On Mon, 2013-07-15 at 08:52 -0700, Sarah Sharp wrote:
> On Fri, 12 Jul 2013 18:17:08 +0200, 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!
> 
> On Fri, 12 Jul 2013 08:22:27 -0700, Linus wrote:
> > 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.
> 
> Seriously, guys?  Is this what we need in order to get improve -stable?
> Linus Torvalds is advocating for physical intimidation and violence.
> Ingo Molnar and Linus are advocating for verbal abuse.
> 
> Not *fucking* cool.  Violence, whether it be physical intimidation,
> verbal threats or verbal abuse is not acceptable.  Keep it professional
> on the mailing lists.
>
> Let's discuss this at Kernel Summit where we can at least yell at each
> other in person.  Yeah, just try yelling at me about this.  I'll roar
> right back, louder, for all the people who lose their voice when they
> get yelled at by top maintainers.  I won't be the nice girl anymore.
> 
> Sarah Sharp


Having sent Greg an inappropriate device support patch (for stable)
right smack dab in the middle of this thread, what I can say as a
developer who tends to have to work all over the place in the kernel,
is that deriving the rules is still difficult (as Guenter Roeck has
alluded to in his posts here).

Greg's response to me was direct, informative, and maybe just a little
bit shame-inducing "You know better than that." I know Greg well enough
not to take that personally and I can see him saying that with a smile
on his face, so no complaints there. However, the truth is, I didn't
know better because despite having read the docs, it wasn't clear to
me. Part of the reason there is the language used wasn't clear to me,
specifically "New device IDs and quirks are also accepted". I took
quirks to mean augmenting existing drivers to handle new devices with
subtle changes when in fact it meant something more along the lines of
a couple of lines to add device IDs and existing quirks to a new
device. Greg provided me with example commit IDs which met that
requirement (and perhaps such examples should be added to the docs).

I believe we could improve that documentation to help clarify the
requirements to people that don't work with it everyday. I have offered
to have a look and see what would have made it more clear to me, and I
will do that.

I do believe our processes are becoming a bit fragmented. While every
maintainer certainly needs some autonomy to be able to define how
people work with them in order to maximize their efficiency, the
difference (or lack thereof) between -RC4 and stable wasn't clear to
me, and couldn't be deduced from stable_kernel_rules. Guenter mentioned
some tribal-knowledge associated with /net rules (which I had just
unwittingly violated in the patch mentioned above). I wonder if we
could somehow merge policies where possible, and document those that
should be different in a place where people are likely to find them -
perhaps associated with get_maintainer.pl since anyone submitting
patches should be checking that output anyway.

In summary, better consolidated documentation using language that is
clear to non-subsystem-experts and less tribal knowledge. If people
don't read the documentation that we put in front of their nose....
well, then I suppose we can scold them a bit.

-- 
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel


^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [ 00/19] 3.10.1-stable review
  2013-07-15 15:52 Sarah Sharp
@ 2013-07-15 17:08 ` Linus Torvalds
  2013-07-15 17:46   ` Sarah Sharp
  2013-07-15 18:22   ` Steven Rostedt
  2013-07-15 17:33 ` Darren Hart
                   ` (2 subsequent siblings)
  3 siblings, 2 replies; 213+ messages in thread
From: Linus Torvalds @ 2013-07-15 17:08 UTC (permalink / raw)
  To: Sarah Sharp
  Cc: Ingo Molnar, Guenter Roeck, Greg Kroah-Hartman, Steven Rostedt,
	Dave Jones, Linux Kernel Mailing List, Andrew Morton, stable,
	Darren Hart

On Mon, Jul 15, 2013 at 8:52 AM, Sarah Sharp
<sarah.a.sharp@linux.intel.com> wrote:
>
>                                                             I'll roar
> right back, louder, for all the people who lose their voice when they
> get yelled at by top maintainers.  I won't be the nice girl anymore.

That's the spirit.

Greg has taught you well. You have controlled your fear. Now, release
your anger. Only your hatred can destroy me.

Come to the dark side, Sarah. We have cookies.

                   Linus

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [ 00/19] 3.10.1-stable review
@ 2013-07-15 15:52 Sarah Sharp
  2013-07-15 17:08 ` Linus Torvalds
                   ` (3 more replies)
  0 siblings, 4 replies; 213+ messages in thread
From: Sarah Sharp @ 2013-07-15 15:52 UTC (permalink / raw)
  To: Linus Torvalds, Ingo Molnar, Guenter Roeck, Greg Kroah-Hartman
  Cc: Steven Rostedt, Dave Jones, Linux Kernel Mailing List,
	Andrew Morton, stable, Darren Hart

On Fri, 12 Jul 2013 18:17:08 +0200, 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!

On Fri, 12 Jul 2013 08:22:27 -0700, Linus wrote:
> 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.

Seriously, guys?  Is this what we need in order to get improve -stable?
Linus Torvalds is advocating for physical intimidation and violence.
Ingo Molnar and Linus are advocating for verbal abuse.

Not *fucking* cool.  Violence, whether it be physical intimidation,
verbal threats or verbal abuse is not acceptable.  Keep it professional
on the mailing lists.

Let's discuss this at Kernel Summit where we can at least yell at each
other in person.  Yeah, just try yelling at me about this.  I'll roar
right back, louder, for all the people who lose their voice when they
get yelled at by top maintainers.  I won't be the nice girl anymore.

Sarah Sharp

^ permalink raw reply	[flat|nested] 213+ messages in thread

end of thread, other threads:[~2013-07-24 10:50 UTC | newest]

Thread overview: 213+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-07-11 22:01 [ 00/19] 3.10.1-stable review Greg Kroah-Hartman
2013-07-11 22:01 ` [ 01/19] libceph: Fix NULL pointer dereference in auth client code Greg Kroah-Hartman
2013-07-11 22:01 ` [ 02/19] ceph: fix sleeping function called from invalid context Greg Kroah-Hartman
2013-07-11 22:01 ` [ 03/19] libceph: fix invalid unsigned->signed conversion for timespec encoding Greg Kroah-Hartman
2013-07-11 22:01 ` [ 04/19] drivers/cdrom/cdrom.c: use kzalloc() for failing hardware Greg Kroah-Hartman
2013-07-11 22:01 ` [ 05/19] module: do percpu allocation after uniqueness check. No, really! Greg Kroah-Hartman
2013-07-11 22:01 ` [ 06/19] charger-manager: Ensure event is not used as format string Greg Kroah-Hartman
2013-07-11 22:01 ` [ 07/19] hpfs: better test for errors Greg Kroah-Hartman
2013-07-11 22:01 ` [ 08/19] block: do not pass disk names as format strings Greg Kroah-Hartman
2013-07-11 22:01 ` [ 09/19] crypto: sanitize argument for format string Greg Kroah-Hartman
2013-07-11 22:01   ` Greg Kroah-Hartman
2013-07-11 22:01 ` [ 10/19] MAINTAINERS: add stable_kernel_rules.txt to stable maintainer information Greg Kroah-Hartman
2013-07-11 22:01 ` [ 11/19] futex: Take hugepages into account when generating futex_key Greg Kroah-Hartman
2013-07-11 22:01 ` [ 12/19] tty: Reset itty for other pty Greg Kroah-Hartman
2013-07-11 22:01 ` [ 13/19] Revert "serial: 8250_pci: add support for another kind of NetMos Technology PCI 9835 Multi-I/O Controller" Greg Kroah-Hartman
2013-07-11 22:01 ` [ 14/19] NFSv4.1 end back channel session draining Greg Kroah-Hartman
2013-07-11 22:01 ` [ 15/19] nfsd4: fix decoding of compounds across page boundaries Greg Kroah-Hartman
2013-07-11 22:01 ` [ 16/19] KVM: VMX: mark unusable segment as nonpresent Greg Kroah-Hartman
2013-07-11 22:01 ` [ 17/19] SCSI: sd: Fix parsing of temporary cache mode prefix Greg Kroah-Hartman
2013-07-11 22:01 ` [ 18/19] cpufreq: Fix cpufreq regression after suspend/resume Greg Kroah-Hartman
2013-07-11 22:01 ` [ 19/19] Revert "memcg: avoid dangling reference count in creation failure" Greg Kroah-Hartman
2013-07-11 22:14 ` [ 00/19] 3.10.1-stable review Josh Boyer
2013-07-14 22:54   ` Benjamin Herrenschmidt
2013-07-11 22:29 ` Dave Jones
2013-07-11 22:44   ` Greg Kroah-Hartman
2013-07-12  1:51     ` Steven Rostedt
2013-07-12 14:15     ` Guenter Roeck
2013-07-12 15:22       ` Linus Torvalds
2013-07-12 15:47         ` Steven Rostedt
2013-07-12 15:55           ` Linus Torvalds
2013-07-12 16:17             ` Ingo Molnar
2013-07-12 16:35               ` Josh Boyer
2013-07-12 16:36                 ` Josh Boyer
2013-07-12 17:05                 ` Greg Kroah-Hartman
2013-07-14 22:40                   ` Benjamin Herrenschmidt
2013-07-12 16:48             ` Steven Rostedt
2013-07-12 17:31         ` Guenter Roeck
2013-07-12 17:50           ` Linus Torvalds
2013-07-12 18:11             ` Guenter Roeck
2013-07-12 19:35               ` Theodore Ts'o
2013-07-12 19:49                 ` Steven Rostedt
2013-07-12 19:55                   ` Willy Tarreau
2013-07-12 20:19                   ` Dave Jones
2013-07-12 20:28                     ` Steven Rostedt
2013-07-12 20:31                       ` Steven Rostedt
2013-07-12 21:19                       ` Justin M. Forbes
2013-07-13  0:47                       ` Jochen Striepe
2013-07-13 11:11                         ` Steven Rostedt
2013-07-13 15:10                           ` Dave Jones
2013-07-13 15:54                             ` Steven Rostedt
2013-07-12 19:50             ` Willy Tarreau
2013-07-12 20:47               ` Theodore Ts'o
2013-07-12 21:02                 ` Guenter Roeck
2013-07-13  6:22               ` Greg Kroah-Hartman
2013-07-13  6:36                 ` Willy Tarreau
2013-07-13  6:48                   ` Greg Kroah-Hartman
2013-07-13  7:12                     ` Willy Tarreau
2013-07-15  4:12                       ` Li Zefan
2013-07-15  4:43                         ` Willy Tarreau
2013-07-13 11:42                     ` Theodore Ts'o
2013-07-13 18:27                       ` Greg Kroah-Hartman
2013-07-14  2:22                         ` Theodore Ts'o
2013-07-14  3:51                           ` Greg Kroah-Hartman
2013-07-14  5:24                             ` Guenter Roeck
2013-07-14 20:31                               ` Geert Uytterhoeven
2013-07-13  6:43                 ` Guenter Roeck
2013-07-13  6:58                   ` Greg Kroah-Hartman
2013-07-14 23:52             ` Benjamin Herrenschmidt
2013-07-15  1:40               ` Linus Torvalds
2013-07-15  2:08                 ` Benjamin Herrenschmidt
2013-07-14 22:58     ` Benjamin Herrenschmidt
2013-07-12  0:50 ` When to push bug fixes to mainline Theodore Ts'o
2013-07-12  1:20   ` [Ksummit-2013-discuss] " Nicholas A. Bellinger
2013-07-12  1:54   ` Steven Rostedt
2013-07-12  9:46     ` Jiri Kosina
2013-07-12 11:19       ` Josh Boyer
2013-07-12  2:57   ` John W. Linville
2013-07-12  3:34     ` Greg Kroah-Hartman
2013-07-12  7:32       ` James Bottomley
2013-07-12 17:20       ` H. Peter Anvin
2013-07-12 17:28         ` Greg Kroah-Hartman
2013-07-12 17:50           ` Steven Rostedt
2013-07-12 17:59             ` Linus Torvalds
2013-07-12 18:14               ` Steven Rostedt
2013-07-13 17:52                 ` Geert Uytterhoeven
2013-07-12 17:57           ` Theodore Ts'o
2013-07-12 18:13             ` Guenter Roeck
2013-07-12 18:16             ` H. Peter Anvin
2013-07-12 18:28               ` H. Peter Anvin
2013-07-12 19:44                 ` Linus Torvalds
2013-07-12 19:53                   ` Steven Rostedt
2013-07-12 20:09                     ` Shuah Khan
2013-07-12 20:33                     ` Greg Kroah-Hartman
2013-07-12 20:46                       ` Steven Rostedt
2013-07-12 22:19                       ` H. Peter Anvin
2013-07-12 22:17                     ` H. Peter Anvin
2013-07-13  6:44                   ` Ingo Molnar
2013-07-13  0:24       ` Rafael J. Wysocki
2013-07-13  1:32         ` Greg Kroah-Hartman
2013-07-13 12:16           ` Rafael J. Wysocki
2013-07-12  3:25   ` Li Zefan
2013-07-15  4:22     ` Rob Landley
2013-07-12  5:14   ` Willy Tarreau
2013-07-16  7:19     ` David Lang
2013-07-16 16:40       ` [Ksummit-2013-discuss] " Takashi Iwai
2013-07-16 16:42         ` David Lang
2013-07-16 19:29           ` Takashi Iwai
2013-07-16 16:59         ` Mark Brown
2013-07-16 17:58           ` Luck, Tony
2013-07-16 17:58             ` Luck, Tony
2013-07-16 18:29             ` Linus Torvalds
2013-07-16 18:29               ` Linus Torvalds
2013-07-16 18:41               ` Steven Rostedt
2013-07-16 18:41                 ` Steven Rostedt
2013-07-16 19:11                 ` Greg Kroah-Hartman
2013-07-16 19:11                   ` Greg Kroah-Hartman
2013-07-16 19:43                   ` Steven Rostedt
2013-07-16 19:43                     ` Steven Rostedt
2013-07-16 20:10                     ` Willy Tarreau
2013-07-16 20:10                       ` Willy Tarreau
2013-07-17  2:58                       ` Ben Hutchings
2013-07-17  2:58                         ` Ben Hutchings
2013-07-17  9:43                       ` Li Zefan
2013-07-17  9:43                         ` Li Zefan
2013-07-16 18:48               ` Willy Tarreau
2013-07-16 18:48                 ` Willy Tarreau
2013-07-19 10:13               ` Ingo Molnar
2013-07-19 10:13                 ` Ingo Molnar
2013-07-16 18:39         ` Willy Tarreau
2013-07-16 18:40       ` H. Peter Anvin
2013-07-16 20:29         ` David Lang
2013-07-12 17:11   ` H. Peter Anvin
2013-07-12 17:20 ` [ 00/19] 3.10.1-stable review Shuah Khan
2013-07-12 17:29   ` Greg Kroah-Hartman
2013-07-13  4:14 ` Satoru Takeuchi
2013-07-14 23:06 ` Benjamin Herrenschmidt
2013-07-15 15:52 Sarah Sharp
2013-07-15 17:08 ` Linus Torvalds
2013-07-15 17:46   ` Sarah Sharp
2013-07-15 17:50     ` Linus Torvalds
2013-07-15 18:04       ` Sarah Sharp
2013-07-15 18:17         ` Linus Torvalds
2013-07-15 18:46           ` Sarah Sharp
2013-07-15 19:07             ` Steven Rostedt
2013-07-15 19:07             ` Linus Torvalds
2013-07-15 19:53               ` Sarah Sharp
2013-07-15 20:41                 ` Sarah Sharp
2013-07-15 21:01                   ` Kees Cook
2013-07-15 21:50                   ` Linus Torvalds
2013-07-18 10:39                     ` Ingo Molnar
2013-07-18 14:32                       ` J. Bruce Fields
2013-07-18 16:07                       ` Sarah Sharp
2013-07-18 16:16                         ` Steven Rostedt
2013-07-18 17:39                         ` Felipe Contreras
2013-07-16 14:30                   ` Geert Uytterhoeven
2013-07-16 15:00                     ` Steven Rostedt
2013-07-16 15:09                     ` Kees Cook
2013-07-16 15:27                       ` Darren Hart
2013-07-18  0:42                 ` Thomas Gleixner
2013-07-18  3:16                   ` CAI Qian
2013-07-18  3:47                     ` Steven Rostedt
2013-07-18  4:01                       ` CAI Qian
2013-07-18  5:03                         ` H. Peter Anvin
2013-07-18  6:06                           ` CAI Qian
2013-07-18 10:21                             ` Ingo Molnar
2013-07-18 11:35                         ` Steven Rostedt
2013-07-18 13:23                         ` Theodore Ts'o
2013-07-18  4:15                       ` CAI Qian
2013-07-18 15:48                   ` Sarah Sharp
2013-07-19 10:35                     ` Ingo Molnar
2013-07-24 10:43                 ` Florian Holz
2013-07-16 14:45               ` Alex Elder
2013-07-15 19:17             ` Willy Tarreau
2013-07-15 19:23               ` Linus Torvalds
2013-07-15 19:39                 ` Willy Tarreau
2013-07-15 22:50                 ` Raymond Jennings
2013-07-16  4:52                 ` Rusty Russell
2013-07-16 21:08                   ` Sarah Sharp
2013-07-16 21:23                     ` Linus Torvalds
2013-07-16 21:58                       ` Rafael J. Wysocki
2013-07-16 22:12                         ` Linus Torvalds
2013-07-17  5:22                           ` Sarah Sharp
2013-07-19 11:10                             ` Ingo Molnar
2013-07-16 21:27                     ` Steven Rostedt
2013-07-16 22:11                     ` Willy Tarreau
2013-07-17  1:02                     ` Rusty Russell
2013-07-17  1:37                       ` Linus Torvalds
2013-07-17  1:54                         ` Steven Rostedt
2013-07-17  3:28                         ` Darren Hart
2013-07-15 22:40               ` NeilBrown
2013-07-16  6:13                 ` Willy Tarreau
2013-07-16 15:40                   ` Darren Hart
2013-07-16 18:18                     ` Willy Tarreau
2013-07-16  2:44             ` Li Zefan
2013-07-15 19:05           ` J. Bruce Fields
2013-07-15 19:19             ` Steven Rostedt
2013-07-15 23:42               ` NeilBrown
2013-07-15 23:50                 ` Joe Perches
2013-07-16  1:54                   ` NeilBrown
2013-07-16  2:01                     ` Joe Perches
2013-07-21  4:15                       ` Rob Landley
2013-07-17  7:01                   ` CAI Qian
2013-07-17  8:39           ` Janne Karhunen
2013-07-15 18:22   ` Steven Rostedt
2013-07-15 17:33 ` Darren Hart
2013-07-15 19:04 ` Rob Landley
2013-07-19 11:25   ` Ingo Molnar
2013-07-23  8:26 ` Rogelio Serrano
2013-07-18  3:50 George Spelvin
2013-07-23  1:42 Regina Obe
2013-07-23  3:43 ` Mike Galbraith
2013-07-23  4:16   ` Regina Obe
2013-07-23  4:49   ` Regina Obe

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.