[ 01/78] x86 bpf_jit: fix a bug in emitting the 16-bit immediate operand of AND

[ 01/78] x86 bpf_jit: fix a bug in emitting the 16-bit immediate operand of AND

[Greg KH]

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

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

From: Feiran Zhuang  <zhuangfeiran@ict.ac.cn>

[ Upstream commit 1d24fb3684f347226747c6b11ea426b7b992694e ]

When K >= 0xFFFF0000, AND needs the two least significant bytes of K as
its operand, but EMIT2() gives it the least significant byte of K and
0x2. EMIT() should be used here to replace EMIT2().

Signed-off-by: Feiran Zhuang  <zhuangfeiran@ict.ac.cn>
Acked-by: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
 arch/x86/net/bpf_jit_comp.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/arch/x86/net/bpf_jit_comp.c
+++ b/arch/x86/net/bpf_jit_comp.c
@@ -289,7 +289,7 @@ void bpf_jit_compile(struct sk_filter *f
 					EMIT2(0x24, K & 0xFF); /* and imm8,%al */
 				} else if (K >= 0xFFFF0000) {
 					EMIT2(0x66, 0x25);	/* and imm16,%ax */
-					EMIT2(K, 2);
+					EMIT(K, 2);
 				} else {
 					EMIT1_off32(0x25, K);	/* and imm32,%eax */
 				}

[ 02/78] via-rhine: fix wait-bit inversion.

[Greg KH]

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

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


From: Andreas Mohr <andi@lisas.de>

[ Upstream commit 3f8c91a7398b9266fbe7abcbe4bd5dffef907643 ]

Bug appeared in a384a33bb1c9ec2d99db2046b41f57023fa7d77b
("via-rhine: RHINE_WAIT_FOR macro removal). It can be noticed
during suspend/resume.

Signed-off-by: Andreas Mohr <andi@lisas.de>
Acked-by: Francois Romieu <romieu@fr.zoreil.com>
Cc: David Lv <DavidLv@viatech.com.cn>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
 drivers/net/ethernet/via/via-rhine.c |   12 +++++++-----
 1 file changed, 7 insertions(+), 5 deletions(-)

--- a/drivers/net/ethernet/via/via-rhine.c
+++ b/drivers/net/ethernet/via/via-rhine.c
@@ -503,30 +503,32 @@ static int rhine_vlan_rx_add_vid(struct
 static int rhine_vlan_rx_kill_vid(struct net_device *dev, unsigned short vid);
 static void rhine_restart_tx(struct net_device *dev);
 
-static void rhine_wait_bit(struct rhine_private *rp, u8 reg, u8 mask, bool high)
+static void rhine_wait_bit(struct rhine_private *rp, u8 reg, u8 mask, bool low)
 {
 	void __iomem *ioaddr = rp->base;
 	int i;
 
 	for (i = 0; i < 1024; i++) {
-		if (high ^ !!(ioread8(ioaddr + reg) & mask))
+		bool has_mask_bits = !!(ioread8(ioaddr + reg) & mask);
+
+		if (low ^ has_mask_bits)
 			break;
 		udelay(10);
 	}
 	if (i > 64) {
 		netif_dbg(rp, hw, rp->dev, "%s bit wait (%02x/%02x) cycle "
-			  "count: %04d\n", high ? "high" : "low", reg, mask, i);
+			  "count: %04d\n", low ? "low" : "high", reg, mask, i);
 	}
 }
 
 static void rhine_wait_bit_high(struct rhine_private *rp, u8 reg, u8 mask)
 {
-	rhine_wait_bit(rp, reg, mask, true);
+	rhine_wait_bit(rp, reg, mask, false);
 }
 
 static void rhine_wait_bit_low(struct rhine_private *rp, u8 reg, u8 mask)
 {
-	rhine_wait_bit(rp, reg, mask, false);
+	rhine_wait_bit(rp, reg, mask, true);
 }
 
 static u32 rhine_get_events(struct rhine_private *rp)

[ 03/78] tg3: Fix 5717 serdes powerdown problem

[Greg KH]

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

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


From: Matt Carlson <mcarlson@broadcom.com>

[ Upstream commit 085f1afc56619bda424941412fdeaff1e32c21dc ]

If port 0 of a 5717 serdes device powers down, it hides the phy from
port 1.  This patch works around the problem by keeping port 0's phy
powered up.

Signed-off-by: Matt Carlson <mcarlson@broadcom.com>
Signed-off-by: Michael Chan <mchan@broadcom.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
 drivers/net/ethernet/broadcom/tg3.c |    4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

--- a/drivers/net/ethernet/broadcom/tg3.c
+++ b/drivers/net/ethernet/broadcom/tg3.c
@@ -2771,7 +2771,9 @@ static void tg3_power_down_phy(struct tg
 	if (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5700 ||
 	    GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5704 ||
 	    (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5780 &&
-	     (tp->phy_flags & TG3_PHYFLG_MII_SERDES)))
+	     (tp->phy_flags & TG3_PHYFLG_MII_SERDES)) ||
+	    (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5717 &&
+	     !tp->pci_fn))
 		return;
 
 	if (GET_CHIP_REV(tp->pci_chip_rev_id) == CHIPREV_5784_AX ||

[ 04/78] sky2: dont overwrite settings for PHY Quick link

[Greg KH]

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

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


From: Lino Sanfilippo <LinoSanfilippo@gmx.de>

[ Upstream commit 2240eb4ae3dc4acff20d1a8947c441c451513e37 ]

This patch corrects a bug in function sky2_open() of the Marvell Yukon 2 driver
in which the settings for PHY quick link are overwritten.

Signed-off-by: Lino Sanfilippo <LinoSanfilippo@gmx.de>
Acked-by: Stephen Hemminger <shemminger@vyattta.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
 drivers/net/ethernet/marvell/sky2.c |    5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

--- a/drivers/net/ethernet/marvell/sky2.c
+++ b/drivers/net/ethernet/marvell/sky2.c
@@ -1767,13 +1767,14 @@ static int sky2_open(struct net_device *
 
 	sky2_hw_up(sky2);
 
+	/* Enable interrupts from phy/mac for port */
+	imask = sky2_read32(hw, B0_IMSK);
+
 	if (hw->chip_id == CHIP_ID_YUKON_OPT ||
 	    hw->chip_id == CHIP_ID_YUKON_PRM ||
 	    hw->chip_id == CHIP_ID_YUKON_OP_2)
 		imask |= Y2_IS_PHY_QLNK;	/* enable PHY Quick Link */
 
-	/* Enable interrupts from phy/mac for port */
-	imask = sky2_read32(hw, B0_IMSK);
 	imask |= portirq_msk[port];
 	sky2_write32(hw, B0_IMSK, imask);
 	sky2_read32(hw, B0_IMSK);

[ 05/78] rose_dev: fix memcpy-bug in rose_set_mac_address

[Greg KH]

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

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


From: "danborkmann@iogearbox.net" <danborkmann@iogearbox.net>

[ Upstream commit 81213b5e8ae68e204aa7a3f83c4f9100405dbff9 ]

If both addresses equal, nothing needs to be done. If the device is down,
then we simply copy the new address to dev->dev_addr. If the device is up,
then we add another loopback device with the new address, and if that does
not fail, we remove the loopback device with the old address. And only
then, we update the dev->dev_addr.

Signed-off-by: Daniel Borkmann <daniel.borkmann@tik.ee.ethz.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
 net/rose/rose_dev.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

--- a/net/rose/rose_dev.c
+++ b/net/rose/rose_dev.c
@@ -96,11 +96,11 @@ static int rose_set_mac_address(struct n
 	struct sockaddr *sa = addr;
 	int err;
 
-	if (!memcpy(dev->dev_addr, sa->sa_data, dev->addr_len))
+	if (!memcmp(dev->dev_addr, sa->sa_data, dev->addr_len))
 		return 0;
 
 	if (dev->flags & IFF_UP) {
-		err = rose_add_loopback_node((rose_address *)dev->dev_addr);
+		err = rose_add_loopback_node((rose_address *)sa->sa_data);
 		if (err)
 			return err;
 

[ 06/78] net: usb: cdc_eem: fix mtu

[Greg KH]

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

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


From: Rabin Vincent <rabin@rab.in>

[ Upstream commit 78fb72f7936c01d5b426c03a691eca082b03f2b9 ]

Make CDC EEM recalculate the hard_mtu after adjusting the
hard_header_len.

Without this, usbnet adjusts the MTU down to 1494 bytes, and the host is
unable to receive standard 1500-byte frames from the device.

Tested with the Linux USB Ethernet gadget.

Cc: Oliver Neukum <oliver@neukum.name>
Signed-off-by: Rabin Vincent <rabin@rab.in>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
 drivers/net/usb/cdc_eem.c |    1 +
 1 file changed, 1 insertion(+)

--- a/drivers/net/usb/cdc_eem.c
+++ b/drivers/net/usb/cdc_eem.c
@@ -93,6 +93,7 @@ static int eem_bind(struct usbnet *dev,
 	/* no jumbogram (16K) support for now */
 
 	dev->net->hard_header_len += EEM_HEAD + ETH_FCS_LEN;
+	dev->hard_mtu = dev->net->mtu + dev->net->hard_header_len;
 
 	return 0;
 }

[ 07/78] Fix non TBI PHY access; a bad merge undid bug fix in a previous commit.

[Greg KH]

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

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


From: Kenth Eriksson <kenth.eriksson@transmode.com>

[ Upstream commit 464b57da56910c8737ede75ad820b9a7afc46b3e ]

The merge done in commit b26e478f undid bug fix in commit c3e072f8
("net: fsl_pq_mdio: fix non tbi phy access"), with the result that non
TBI (e.g. MDIO) PHYs cannot be accessed.

Signed-off-by: Kenth Eriksson <kenth.eriksson@transmode.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
 drivers/net/ethernet/freescale/fsl_pq_mdio.c |   12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

--- a/drivers/net/ethernet/freescale/fsl_pq_mdio.c
+++ b/drivers/net/ethernet/freescale/fsl_pq_mdio.c
@@ -356,13 +356,13 @@ static int fsl_pq_mdio_probe(struct plat
 
 		if (prop)
 			tbiaddr = *prop;
-	}
 
-	if (tbiaddr == -1) {
-		err = -EBUSY;
-		goto err_free_irqs;
-	} else {
-		out_be32(tbipa, tbiaddr);
+		if (tbiaddr == -1) {
+			err = -EBUSY;
+			goto err_free_irqs;
+		} else {
+			out_be32(tbipa, tbiaddr);
+		}
 	}
 
 	err = of_mdiobus_register(new_bus, np);

[ 08/78] ALSA: hda/realtek - Fix ADC assignment with a shared HP/Mic pin

[Greg KH]

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

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

From: Takashi Iwai <tiwai@suse.de>

commit 26acaf08556a3c64ebf8ea3654b51e6acbb0a26c upstream.

The recent Realtek driver tries to assign an extra input via the
headphone plug when only a single input source is found.  The code
worked on Samsung Q1, but it broke ASUS 1015 where the mic is a
digital-mic and only a specific ADC works.

This patch fixes the assignment of ADC in the shared mic/hp case.
Instead of assuming the single ADC at first, reduce the ADCs after
trying to assign both mic and HP pins.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=42973

Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 sound/pci/hda/patch_realtek.c |   11 +++++++----
 1 file changed, 7 insertions(+), 4 deletions(-)

--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -2709,9 +2709,6 @@ static int alc_auto_fill_adc_caps(struct
 	int max_nums = ARRAY_SIZE(spec->private_adc_nids);
 	int i, nums = 0;
 
-	if (spec->shared_mic_hp)
-		max_nums = 1; /* no multi streams with the shared HP/mic */
-
 	nid = codec->start_nid;
 	for (i = 0; i < codec->num_nodes; i++, nid++) {
 		hda_nid_t src;
@@ -3723,6 +3720,7 @@ static void alc_remove_invalid_adc_nids(
 	if (spec->dyn_adc_switch)
 		return;
 
+ again:
 	nums = 0;
 	for (n = 0; n < spec->num_adc_nids; n++) {
 		hda_nid_t cap = spec->private_capsrc_nids[n];
@@ -3743,6 +3741,11 @@ static void alc_remove_invalid_adc_nids(
 	if (!nums) {
 		/* check whether ADC-switch is possible */
 		if (!alc_check_dyn_adc_switch(codec)) {
+			if (spec->shared_mic_hp) {
+				spec->shared_mic_hp = 0;
+				spec->private_imux[0].num_items = 1;
+				goto again;
+			}
 			printk(KERN_WARNING "hda_codec: %s: no valid ADC found;"
 			       " using fallback 0x%x\n",
 			       codec->chip_name, spec->private_adc_nids[0]);
@@ -3760,7 +3763,7 @@ static void alc_remove_invalid_adc_nids(
 
 	if (spec->auto_mic)
 		alc_auto_mic_check_imux(codec); /* check auto-mic setups */
-	else if (spec->input_mux->num_items == 1)
+	else if (spec->input_mux->num_items == 1 || spec->shared_mic_hp)
 		spec->num_adc_nids = 1; /* reduce to a single ADC */
 }
 

[ 09/78] ASoC: wm8994: Update WM8994 DCS calibration

[Greg KH]

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

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

From: Mark Brown <broonie@opensource.wolfsonmicro.com>

commit e16605855d58803fe0608417150c7a618b4f8243 upstream.

Based on latest production information.

Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 sound/soc/codecs/wm8994.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/sound/soc/codecs/wm8994.c
+++ b/sound/soc/codecs/wm8994.c
@@ -3427,7 +3427,7 @@ static int wm8994_codec_probe(struct snd
 		case 2:
 		case 3:
 			wm8994->hubs.dcs_codes_l = -9;
-			wm8994->hubs.dcs_codes_r = -5;
+			wm8994->hubs.dcs_codes_r = -7;
 			break;
 		default:
 			break;

[ 10/78] mtd: ixp4xx: oops in ixp4xx_flash_probe

[Greg KH]

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

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

From: Marc Kleine-Budde <mkl@blackshift.org>

commit a3c1e3b732b3708a80e4035b9d845f3f7c7dd0c9 upstream.

In commit "c797533 mtd: abstract last MTD partition parser argument" the
third argument of "mtd_device_parse_register()" changed from start address
of the MTD device to a pointer to a struct.

The "ixp4xx_flash_probe()" function was not converted properly, causing
an oops during boot.

This patch fixes the problem by filling the needed information into a
"struct mtd_part_parser_data" and passing it to
"mtd_device_parse_register()".

Signed-off-by: Marc Kleine-Budde <mkl@blackshift.org>
Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/mtd/maps/ixp4xx.c |    5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

--- a/drivers/mtd/maps/ixp4xx.c
+++ b/drivers/mtd/maps/ixp4xx.c
@@ -182,6 +182,9 @@ static int ixp4xx_flash_probe(struct pla
 {
 	struct flash_platform_data *plat = dev->dev.platform_data;
 	struct ixp4xx_flash_info *info;
+	struct mtd_part_parser_data ppdata = {
+		.origin = dev->resource->start,
+	};
 	int err = -1;
 
 	if (!plat)
@@ -247,7 +250,7 @@ static int ixp4xx_flash_probe(struct pla
 	/* Use the fast version */
 	info->map.write = ixp4xx_write16;
 
-	err = mtd_device_parse_register(info->mtd, probes, dev->resource->start,
+	err = mtd_device_parse_register(info->mtd, probes, &ppdata,
 			plat->parts, plat->nr_parts);
 	if (err) {
 		printk(KERN_ERR "Could not parse partitions\n");

[ 11/78] mtd: mips: lantiq: reintroduce support for cmdline partitions

[Greg KH]

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

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

From: Daniel Schwierzeck <daniel.schwierzeck@googlemail.com>

commit bf011f2ed53d587fdd8148c173c4f09ed77bdf1a upstream.

Since commit ca97dec2ab5c87e9fbdf7e882e1820004a3966fa the
command line parsing of MTD partitions does not work anymore.

Signed-off-by: Daniel Schwierzeck <daniel.schwierzeck@googlemail.com>
Signed-off-by: John Crispin <blogic@openwrt.org>
Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Acked-by: John Crispin <blogic@openwrt.org>
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/mtd/maps/lantiq-flash.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

--- a/drivers/mtd/maps/lantiq-flash.c
+++ b/drivers/mtd/maps/lantiq-flash.c
@@ -45,6 +45,7 @@ struct ltq_mtd {
 };
 
 static char ltq_map_name[] = "ltq_nor";
+static const char *ltq_probe_types[] __devinitconst = { "cmdlinepart", NULL };
 
 static map_word
 ltq_read16(struct map_info *map, unsigned long adr)
@@ -168,7 +169,7 @@ ltq_mtd_probe(struct platform_device *pd
 	cfi->addr_unlock1 ^= 1;
 	cfi->addr_unlock2 ^= 1;
 
-	err = mtd_device_parse_register(ltq_mtd->mtd, NULL, 0,
+	err = mtd_device_parse_register(ltq_mtd->mtd, ltq_probe_types, 0,
 			ltq_mtd_data->parts, ltq_mtd_data->nr_parts);
 	if (err) {
 		dev_err(&pdev->dev, "failed to add partitions\n");

[ 12/78] mtd: nand: gpmi: use correct member for checking NAND_BBT_USE_FLASH

[Greg KH]

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

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

From: Wolfram Sang <w.sang@pengutronix.de>

commit 5289966ea576a062b80319975b31b661c196ff9d upstream.

This has been moved from .options to .bbt_options meanwhile. So, it
currently checks for something totally different (NAND_OWN_BUFFERS) and
decides according to that.

Artem Bityutskiy: the options were moved in
a40f734 mtd: nand: consolidate redundant flash-based BBT flags

Artem Bityutskiy: CCing -stable

Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
Acked-by: Huang Shijie <b32955@freescale.com>
Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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

--- a/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
+++ b/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
@@ -1124,7 +1124,7 @@ static int gpmi_block_markbad(struct mtd
 		chip->bbt[block >> 2] |= 0x01 << ((block & 0x03) << 1);
 
 	/* Do we have a flash based bad block table ? */
-	if (chip->options & NAND_BBT_USE_FLASH)
+	if (chip->bbt_options & NAND_BBT_USE_FLASH)
 		ret = nand_update_bbt(mtd, ofs);
 	else {
 		chipnr = (int)(ofs >> chip->chip_shift);

[ 13/78] mtd: sst25l: initialize writebufsize

[Greg KH]

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

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

From: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>

commit c4cc625ea5958d065c21cc0fcea29e9ed8f3d2bc upstream.

The writebufsize concept was introduce by commit
"0e4ca7e mtd: add writebufsize field to mtd_info struct" and it represents
the maximum amount of data the device writes to the media at a time. This is
an important parameter for UBIFS which is used during recovery and which
basically defines how big a corruption caused by a power cut can be.

Set writebufsize to the flash page size because it is the maximum amount of
data it writes at a time.

Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/mtd/devices/sst25l.c |    1 +
 1 file changed, 1 insertion(+)

--- a/drivers/mtd/devices/sst25l.c
+++ b/drivers/mtd/devices/sst25l.c
@@ -402,6 +402,7 @@ static int __devinit sst25l_probe(struct
 	flash->mtd.flags	= MTD_CAP_NORFLASH;
 	flash->mtd.erasesize	= flash_info->erase_size;
 	flash->mtd.writesize	= flash_info->page_size;
+	flash->mtd.writebufsize	= flash_info->page_size;
 	flash->mtd.size		= flash_info->page_size * flash_info->nr_pages;
 	flash->mtd.erase	= sst25l_erase;
 	flash->mtd.read		= sst25l_read;

[ 14/78] mtd: doc2001plus: initialize writebufsize

[Greg KH]

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

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

From: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>

commit 71f60fbebf0f18dd4e855335a009efda251b1697 upstream.

The writebufsize concept was introduce by commit
"0e4ca7e mtd: add writebufsize field to mtd_info struct" and it represents
the maximum amount of data the device writes to the media at a time. This is
an important parameter for UBIFS which is used during recovery and which
basically defines how big a corruption caused by a power cut can be.

Set it to be equivalent to mtd->writesize because this is the maximum amount
of data the driver writes at a time.

Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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

--- a/drivers/mtd/devices/doc2001plus.c
+++ b/drivers/mtd/devices/doc2001plus.c
@@ -467,7 +467,7 @@ void DoCMilPlus_init(struct mtd_info *mt
 
 	mtd->type = MTD_NANDFLASH;
 	mtd->flags = MTD_CAP_NANDFLASH;
-	mtd->writesize = 512;
+	mtd->writebufsize = mtd->writesize = 512;
 	mtd->oobsize = 16;
 	mtd->owner = THIS_MODULE;
 	mtd->erase = doc_erase;

[ 15/78] mtd: doc2000: initialize writebufsize

[Greg KH]

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

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

From: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>

commit cd1986a3c111f7ed597619705290fa52a975014f upstream.

The writebufsize concept was introduce by commit
"0e4ca7e mtd: add writebufsize field to mtd_info struct" and it represents
the maximum amount of data the device writes to the media at a time. This is
an important parameter for UBIFS which is used during recovery and which
basically defines how big a corruption caused by a power cut can be.

Set it to be equivalent to mtd->writesize because this is the maximum amount
of data the driver writes at a time.

Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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

--- a/drivers/mtd/devices/doc2000.c
+++ b/drivers/mtd/devices/doc2000.c
@@ -562,7 +562,7 @@ void DoC2k_init(struct mtd_info *mtd)
 
 	mtd->type = MTD_NANDFLASH;
 	mtd->flags = MTD_CAP_NANDFLASH;
-	mtd->writesize = 512;
+	mtd->writebufsize = mtd->writesize = 512;
 	mtd->oobsize = 16;
 	mtd->owner = THIS_MODULE;
 	mtd->erase = doc_erase;

[ 16/78] mtd: doc2001: initialize writebufsize

[Greg KH]

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

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

From: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>

commit cca84b569ebe3372b28949e00b0a3a17f87e2970 upstream.

The writebufsize concept was introduce by commit
"0e4ca7e mtd: add writebufsize field to mtd_info struct" and it represents
the maximum amount of data the device writes to the media at a time. This is
an important parameter for UBIFS which is used during recovery and which
basically defines how big a corruption caused by a power cut can be.

Set it to be equivalent to mtd->writesize because this is the maximum amount
of data the driver writes at a time.

Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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

--- a/drivers/mtd/devices/doc2001.c
+++ b/drivers/mtd/devices/doc2001.c
@@ -346,7 +346,7 @@ void DoCMil_init(struct mtd_info *mtd)
 
 	/* FIXME: erase size is not always 8KiB */
 	mtd->erasesize = 0x2000;
-	mtd->writesize = 512;
+	mtd->writebufsize = mtd->writesize = 512;
 	mtd->oobsize = 16;
 	mtd->owner = THIS_MODULE;
 	mtd->erase = doc_erase;

[ 17/78] mtd: docg3: initialize writebufsize

[Greg KH]

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

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

From: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>

commit 82c4c58d6f1a78e8de875272a19ab9220b8066aa upstream.

The writebufsize concept was introduce by commit
"0e4ca7e mtd: add writebufsize field to mtd_info struct" and it represents
the maximum amount of data the device writes to the media at a time. This is
an important parameter for UBIFS which is used during recovery and which
basically defines how big a corruption caused by a power cut can be.

Set it to be equivalent to mtd->writesize because this is the maximum amount
of data the driver writes at a time.

Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Acked-by: Robert Jarzmik <robert.jarzmik@free.fr>
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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

--- a/drivers/mtd/devices/docg3.c
+++ b/drivers/mtd/devices/docg3.c
@@ -1817,7 +1817,7 @@ static void __init doc_set_driver_info(i
 	mtd->erasesize = DOC_LAYOUT_BLOCK_SIZE * DOC_LAYOUT_NBPLANES;
 	if (docg3->reliable == 2)
 		mtd->erasesize /= 2;
-	mtd->writesize = DOC_LAYOUT_PAGE_SIZE;
+	mtd->writebufsize = mtd->writesize = DOC_LAYOUT_PAGE_SIZE;
 	mtd->oobsize = DOC_LAYOUT_OOB_SIZE;
 	mtd->owner = THIS_MODULE;
 	mtd->erase = doc_erase;

[ 18/78] mtd: block2mtd: initialize writebufsize

[Greg KH]

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

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

From: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>

commit b604387411ec6a072e95910099262616edd2bd2f upstream.

The writebufsize concept was introduce by commit
"0e4ca7e mtd: add writebufsize field to mtd_info struct" and it represents
the maximum amount of data the device writes to the media at a time. This is
an important parameter for UBIFS which is used during recovery and which
basically defines how big a corruption caused by a power cut can be.

However, we forgot to set this parameter for block2mtd. Set it to PAGE_SIZE
because this is actually the amount of data we write at a time.

Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Acked-by: Joern Engel <joern@lazybastard.org>
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/mtd/devices/block2mtd.c |    1 +
 1 file changed, 1 insertion(+)

--- a/drivers/mtd/devices/block2mtd.c
+++ b/drivers/mtd/devices/block2mtd.c
@@ -283,6 +283,7 @@ static struct block2mtd_dev *add_device(
 	dev->mtd.size = dev->blkdev->bd_inode->i_size & PAGE_MASK;
 	dev->mtd.erasesize = erase_size;
 	dev->mtd.writesize = 1;
+	dev->mtd.writebufsize = PAGE_SIZE;
 	dev->mtd.type = MTD_RAM;
 	dev->mtd.flags = MTD_CAP_RAM;
 	dev->mtd.erase = block2mtd_erase;

[ 19/78] mtd: lart: initialize writebufsize

[Greg KH]

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

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

From: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>

commit fcc44a07dae0af16e84e93425fc8afe642ddc603 upstream.

The writebufsize concept was introduce by commit
"0e4ca7e mtd: add writebufsize field to mtd_info struct" and it represents
the maximum amount of data the device writes to the media at a time. This is
an important parameter for UBIFS which is used during recovery and which
basically defines how big a corruption caused by a power cut can be.

Set writebufsize to 4 because this drivers writes at max 4 bytes at a time.

Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/mtd/devices/lart.c |    1 +
 1 file changed, 1 insertion(+)

--- a/drivers/mtd/devices/lart.c
+++ b/drivers/mtd/devices/lart.c
@@ -630,6 +630,7 @@ static int __init lart_flash_init (void)
    mtd.name = module_name;
    mtd.type = MTD_NORFLASH;
    mtd.writesize = 1;
+   mtd.writebufsize = 4;
    mtd.flags = MTD_CAP_NORFLASH;
    mtd.size = FLASH_BLOCKSIZE_PARAM * FLASH_NUMBLOCKS_16m_PARAM + FLASH_BLOCKSIZE_MAIN * FLASH_NUMBLOCKS_16m_MAIN;
    mtd.erasesize = FLASH_BLOCKSIZE_MAIN;

[ 20/78] mtd: m25p80: set writebufsize

[Greg KH]

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

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

From: Brian Norris <computersforpeace@gmail.com>

commit b54f47c8bcfc5f766bf13ec31bd7dd1d4726d33b upstream.

Using UBI on m25p80 can give messages like:

    UBI error: io_init: bad write buffer size 0 for 1 min. I/O unit

We need to initialize writebufsize; I think "page_size" is the correct
"bufsize", although I'm not sure. Comments?

Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/mtd/devices/m25p80.c |    1 +
 1 file changed, 1 insertion(+)

--- a/drivers/mtd/devices/m25p80.c
+++ b/drivers/mtd/devices/m25p80.c
@@ -932,6 +932,7 @@ static int __devinit m25p_probe(struct s
 	ppdata.of_node = spi->dev.of_node;
 	flash->mtd.dev.parent = &spi->dev;
 	flash->page_size = info->page_size;
+	flash->mtd.writebufsize = flash->page_size;
 
 	if (info->addr_width)
 		flash->addr_width = info->addr_width;

[ 21/78] ACPI: Do cpufreq clamping for throttling per package v2

[Greg KH]

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

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

From: Andi Kleen <andi@firstfloor.org>

commit 2815ab92ba3ab27556212cc306288dc95692824b upstream.

On Intel CPUs the processor typically uses the highest frequency
set by any logical CPU. When the system overheats
Linux first forces the frequency to the lowest available one
to lower the temperature.

However this was done only per logical CPU, which means all
logical CPUs in a package would need to go through this before
the frequency is actually lowered.

Worse this delay actually prevents real throttling, because
the real throttle code only proceeds when the lowest frequency
is already reached.

So when a throttle event happens force the lowest frequency
for all CPUs in the package where it happened. The per CPU
state is now kept per package, not per logical CPU. An alternative
would be to do it per cpufreq unit, but since we want to bring
down the temperature of the complete chip it's better
to do it for all.

In principle it may even make sense to do it for all CPUs,
but I kept it on the package for now.

With this change the frequency is actually lowered, which
in terms also allows real throttling to proceed.

I also removed an unnecessary per cpu variable initialization.

v2: Fix package mapping

Signed-off-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/acpi/processor_thermal.c |   45 ++++++++++++++++++++++++++++++++-------
 1 file changed, 37 insertions(+), 8 deletions(-)

--- a/drivers/acpi/processor_thermal.c
+++ b/drivers/acpi/processor_thermal.c
@@ -57,6 +57,27 @@ ACPI_MODULE_NAME("processor_thermal");
 static DEFINE_PER_CPU(unsigned int, cpufreq_thermal_reduction_pctg);
 static unsigned int acpi_thermal_cpufreq_is_init = 0;
 
+#define reduction_pctg(cpu) \
+	per_cpu(cpufreq_thermal_reduction_pctg, phys_package_first_cpu(cpu))
+
+/*
+ * Emulate "per package data" using per cpu data (which should really be
+ * provided elsewhere)
+ *
+ * Note we can lose a CPU on cpu hotunplug, in this case we forget the state
+ * temporarily. Fortunately that's not a big issue here (I hope)
+ */
+static int phys_package_first_cpu(int cpu)
+{
+	int i;
+	int id = topology_physical_package_id(cpu);
+
+	for_each_online_cpu(i)
+		if (topology_physical_package_id(i) == id)
+			return i;
+	return 0;
+}
+
 static int cpu_has_cpufreq(unsigned int cpu)
 {
 	struct cpufreq_policy policy;
@@ -76,7 +97,7 @@ static int acpi_thermal_cpufreq_notifier
 
 	max_freq = (
 	    policy->cpuinfo.max_freq *
-	    (100 - per_cpu(cpufreq_thermal_reduction_pctg, policy->cpu) * 20)
+	    (100 - reduction_pctg(policy->cpu) * 20)
 	) / 100;
 
 	cpufreq_verify_within_limits(policy, 0, max_freq);
@@ -102,16 +123,28 @@ static int cpufreq_get_cur_state(unsigne
 	if (!cpu_has_cpufreq(cpu))
 		return 0;
 
-	return per_cpu(cpufreq_thermal_reduction_pctg, cpu);
+	return reduction_pctg(cpu);
 }
 
 static int cpufreq_set_cur_state(unsigned int cpu, int state)
 {
+	int i;
+
 	if (!cpu_has_cpufreq(cpu))
 		return 0;
 
-	per_cpu(cpufreq_thermal_reduction_pctg, cpu) = state;
-	cpufreq_update_policy(cpu);
+	reduction_pctg(cpu) = state;
+
+	/*
+	 * Update all the CPUs in the same package because they all
+	 * contribute to the temperature and often share the same
+	 * frequency.
+	 */
+	for_each_online_cpu(i) {
+		if (topology_physical_package_id(i) ==
+		    topology_physical_package_id(cpu))
+			cpufreq_update_policy(i);
+	}
 	return 0;
 }
 
@@ -119,10 +152,6 @@ void acpi_thermal_cpufreq_init(void)
 {
 	int i;
 
-	for (i = 0; i < nr_cpu_ids; i++)
-		if (cpu_present(i))
-			per_cpu(cpufreq_thermal_reduction_pctg, i) = 0;
-
 	i = cpufreq_register_notifier(&acpi_thermal_cpufreq_notifier_block,
 				      CPUFREQ_POLICY_NOTIFIER);
 	if (!i)

[ 22/78] PNPACPI: Fix device ref leaking in acpi_pnp_match

[Greg KH]

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

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

From: Yinghai Lu <yinghai@kernel.org>

commit 89e96ada572fb216e582dbe3f64e1a6939a37f74 upstream.

During testing pci root bus removal, found some root bus bridge is not freed.
If booting with pnpacpi=off, those hostbridge could be freed without problem.
It turns out that some devices reference are not released during acpi_pnp_match.
that match should not hold one device ref during every calling.
Add pu_device calling before returning.

Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: Len Brown <len.brown@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/pnp/pnpacpi/core.c |    7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

--- a/drivers/pnp/pnpacpi/core.c
+++ b/drivers/pnp/pnpacpi/core.c
@@ -321,9 +321,14 @@ static int __init acpi_pnp_match(struct
 {
 	struct acpi_device *acpi = to_acpi_device(dev);
 	struct pnp_dev *pnp = _pnp;
+	struct device *physical_device;
+
+	physical_device = acpi_get_physical_device(acpi->handle);
+	if (physical_device)
+		put_device(physical_device);
 
 	/* true means it matched */
-	return !acpi_get_physical_device(acpi->handle)
+	return !physical_device
 	    && compare_pnp_id(pnp->id, acpi_device_hid(acpi));
 }
 

[ 23/78] ACPICA: Fix regression in FADT revision checks

[Greg KH]

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

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

From: Julian Anastasov <ja@ssi.bg>

commit 3e80acd1af40fcd91a200b0416a7616b20c5d647 upstream.

	commit 64b3db22c04586997ab4be46dd5a5b99f8a2d390 (2.6.39),
"Remove use of unreliable FADT revision field" causes regression
for old P4 systems because now cst_control and other fields are
not reset to 0.

	The effect is that acpi_processor_power_init will notice
cst_control != 0 and a write to CST_CNT register is performed
that should not happen. As result, the system oopses after the
"No _CST, giving up" message, sometimes in acpi_ns_internalize_name,
sometimes in acpi_ns_get_type, usually at random places. May be
during migration to CPU 1 in acpi_processor_get_throttling.

	Every one of these settings help to avoid this problem:
 - acpi=off
 - processor.nocst=1
 - maxcpus=1

	The fix is to update acpi_gbl_FADT.header.length after
the original value is used to check for old revisions.

https://bugzilla.kernel.org/show_bug.cgi?id=42700
https://bugzilla.redhat.com/show_bug.cgi?id=727865

Signed-off-by: Julian Anastasov <ja@ssi.bg>
Acked-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Cc: Jonathan Nieder <jrnieder@gmail.com>
Cc: Josh Boyer <jwboyer@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/acpi/acpica/tbfadt.c |    8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

--- a/drivers/acpi/acpica/tbfadt.c
+++ b/drivers/acpi/acpica/tbfadt.c
@@ -363,10 +363,6 @@ static void acpi_tb_convert_fadt(void)
 	u32 address32;
 	u32 i;
 
-	/* Update the local FADT table header length */
-
-	acpi_gbl_FADT.header.length = sizeof(struct acpi_table_fadt);
-
 	/*
 	 * Expand the 32-bit FACS and DSDT addresses to 64-bit as necessary.
 	 * Later code will always use the X 64-bit field. Also, check for an
@@ -408,6 +404,10 @@ static void acpi_tb_convert_fadt(void)
 		acpi_gbl_FADT.boot_flags = 0;
 	}
 
+	/* Update the local FADT table header length */
+
+	acpi_gbl_FADT.header.length = sizeof(struct acpi_table_fadt);
+
 	/*
 	 * Expand the ACPI 1.0 32-bit addresses to the ACPI 2.0 64-bit "X"
 	 * generic address structures as necessary. Later code will always use

[ 24/78] modpost: fix ALL_INIT_DATA_SECTIONS

[Greg KH]

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

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

From: Jan Beulich <JBeulich@suse.com>

commit 9aaf440f8fabcebf9ea79a62ccf4c212e6544b49 upstream.

This was lacking a comma between two supposed to be separate strings.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Signed-off-by: Michal Marek <mmarek@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 scripts/mod/modpost.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/scripts/mod/modpost.c
+++ b/scripts/mod/modpost.c
@@ -849,7 +849,7 @@ static void check_section(const char *mo
 
 #define ALL_INIT_DATA_SECTIONS \
 	".init.setup$", ".init.rodata$", \
-	".devinit.rodata$", ".cpuinit.rodata$", ".meminit.rodata$" \
+	".devinit.rodata$", ".cpuinit.rodata$", ".meminit.rodata$", \
 	".init.data$", ".devinit.data$", ".cpuinit.data$", ".meminit.data$"
 #define ALL_EXIT_DATA_SECTIONS \
 	".exit.data$", ".devexit.data$", ".cpuexit.data$", ".memexit.data$"

[ 25/78] genirq: Adjust irq thread affinity on IRQ_SET_MASK_OK_NOCOPY return value

[Greg KH]

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

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

From: Jiang Liu <liuj97@gmail.com>

commit f5cb92ac82d06cb583c1f66666314c5c0a4d7913 upstream.

irq_move_masked_irq() checks the return code of
chip->irq_set_affinity() only for 0, but IRQ_SET_MASK_OK_NOCOPY is
also a valid return code, which is there to avoid a redundant copy of
the cpumask. But in case of IRQ_SET_MASK_OK_NOCOPY we not only avoid
the redundant copy, we also fail to adjust the thread affinity of an
eventually threaded interrupt handler.

Handle IRQ_SET_MASK_OK (==0) and IRQ_SET_MASK_OK_NOCOPY(==1) return
values correctly by checking the valid return values seperately.

Signed-off-by: Jiang Liu <jiang.liu@huawei.com>
Cc: Jiang Liu <liuj97@gmail.com>
Cc: Keping Chen <chenkeping@huawei.com>
Link: http://lkml.kernel.org/r/1333120296-13563-2-git-send-email-jiang.liu@huawei.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 kernel/irq/migration.c |   10 +++++++---
 1 file changed, 7 insertions(+), 3 deletions(-)

--- a/kernel/irq/migration.c
+++ b/kernel/irq/migration.c
@@ -43,12 +43,16 @@ void irq_move_masked_irq(struct irq_data
 	 * masking the irqs.
 	 */
 	if (likely(cpumask_any_and(desc->pending_mask, cpu_online_mask)
-		   < nr_cpu_ids))
-		if (!chip->irq_set_affinity(&desc->irq_data,
-					    desc->pending_mask, false)) {
+		   < nr_cpu_ids)) {
+		int ret = chip->irq_set_affinity(&desc->irq_data,
+						 desc->pending_mask, false);
+		switch (ret) {
+		case IRQ_SET_MASK_OK:
 			cpumask_copy(desc->irq_data.affinity, desc->pending_mask);
+		case IRQ_SET_MASK_OK_NOCOPY:
 			irq_set_thread_affinity(desc);
 		}
+	}
 
 	cpumask_clear(desc->pending_mask);
 }

[ 26/78] tracing: Fix ftrace stack trace entries

[Greg KH]

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

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

From: Wolfgang Mauerer <wolfgang.mauerer@siemens.com>

commit 01de982abf8c9e10fc3089e10585cd2cc914bdab upstream.

8 hex characters tell only half the tale for 64 bit CPUs,
so use the appropriate length.

Link: http://lkml.kernel.org/r/1332411501-8059-2-git-send-email-wolfgang.mauerer@siemens.com

Signed-off-by: Wolfgang Mauerer <wolfgang.mauerer@siemens.com>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 kernel/trace/trace_entries.h |   16 ++++++++++++----
 kernel/trace/trace_export.c  |    2 +-
 2 files changed, 13 insertions(+), 5 deletions(-)

--- a/kernel/trace/trace_entries.h
+++ b/kernel/trace/trace_entries.h
@@ -156,6 +156,12 @@ FTRACE_ENTRY_DUP(wakeup, ctx_switch_entr
 
 #define FTRACE_STACK_ENTRIES	8
 
+#ifndef CONFIG_64BIT
+# define IP_FMT "%08lx"
+#else
+# define IP_FMT "%016lx"
+#endif
+
 FTRACE_ENTRY(kernel_stack, stack_entry,
 
 	TRACE_STACK,
@@ -165,8 +171,9 @@ FTRACE_ENTRY(kernel_stack, stack_entry,
 		__dynamic_array(unsigned long,	caller	)
 	),
 
-	F_printk("\t=> (%08lx)\n\t=> (%08lx)\n\t=> (%08lx)\n\t=> (%08lx)\n"
-		 "\t=> (%08lx)\n\t=> (%08lx)\n\t=> (%08lx)\n\t=> (%08lx)\n",
+	F_printk("\t=> (" IP_FMT ")\n\t=> (" IP_FMT ")\n\t=> (" IP_FMT ")\n"
+		 "\t=> (" IP_FMT ")\n\t=> (" IP_FMT ")\n\t=> (" IP_FMT ")\n"
+		 "\t=> (" IP_FMT ")\n\t=> (" IP_FMT ")\n",
 		 __entry->caller[0], __entry->caller[1], __entry->caller[2],
 		 __entry->caller[3], __entry->caller[4], __entry->caller[5],
 		 __entry->caller[6], __entry->caller[7])
@@ -181,8 +188,9 @@ FTRACE_ENTRY(user_stack, userstack_entry
 		__array(	unsigned long,	caller, FTRACE_STACK_ENTRIES	)
 	),
 
-	F_printk("\t=> (%08lx)\n\t=> (%08lx)\n\t=> (%08lx)\n\t=> (%08lx)\n"
-		 "\t=> (%08lx)\n\t=> (%08lx)\n\t=> (%08lx)\n\t=> (%08lx)\n",
+	F_printk("\t=> (" IP_FMT ")\n\t=> (" IP_FMT ")\n\t=> (" IP_FMT ")\n"
+		 "\t=> (" IP_FMT ")\n\t=> (" IP_FMT ")\n\t=> (" IP_FMT ")\n"
+		 "\t=> (" IP_FMT ")\n\t=> (" IP_FMT ")\n",
 		 __entry->caller[0], __entry->caller[1], __entry->caller[2],
 		 __entry->caller[3], __entry->caller[4], __entry->caller[5],
 		 __entry->caller[6], __entry->caller[7])
--- a/kernel/trace/trace_export.c
+++ b/kernel/trace/trace_export.c
@@ -150,7 +150,7 @@ ftrace_define_fields_##name(struct ftrac
 #define __dynamic_array(type, item)
 
 #undef F_printk
-#define F_printk(fmt, args...) #fmt ", "  __stringify(args)
+#define F_printk(fmt, args...) __stringify(fmt) ", "  __stringify(args)
 
 #undef FTRACE_ENTRY
 #define FTRACE_ENTRY(call, struct_name, etype, tstruct, print)		\

[ 27/78] tracing: Fix ent_size in trace output

[Greg KH]

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

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

From: Steven Rostedt <srostedt@redhat.com>

commit 12b5da349a8b94c9dbc3430a6bc42eabd9eaf50b upstream.

When reading the trace file, the records of each of the per_cpu buffers
are examined to find the next event to print out. At the point of looking
at the event, the size of the event is recorded. But if the first event is
chosen, the other events in the other CPU buffers will reset the event size
that is stored in the iterator descriptor, causing the event size passed to
the output functions to be incorrect.

In most cases this is not a problem, but for the case of stack traces, it
is. With the change to the stack tracing to record a dynamic number of
back traces, the output depends on the size of the entry instead of the
fixed 8 back traces. When the entry size is not correct, the back traces
would not be fully printed.

Note, reading from the per-cpu trace files were not affected.

Reported-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 kernel/trace/trace.c |    4 ++++
 1 file changed, 4 insertions(+)

--- a/kernel/trace/trace.c
+++ b/kernel/trace/trace.c
@@ -1644,6 +1644,7 @@ __find_next_entry(struct trace_iterator
 	int cpu_file = iter->cpu_file;
 	u64 next_ts = 0, ts;
 	int next_cpu = -1;
+	int next_size = 0;
 	int cpu;
 
 	/*
@@ -1675,9 +1676,12 @@ __find_next_entry(struct trace_iterator
 			next_cpu = cpu;
 			next_ts = ts;
 			next_lost = lost_events;
+			next_size = iter->ent_size;
 		}
 	}
 
+	iter->ent_size = next_size;
+
 	if (ent_cpu)
 		*ent_cpu = next_cpu;
 

[ 28/78] m68k/mac: Add missing platform check before registering platform devices

[Greg KH]

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

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

From: Geert Uytterhoeven <geert@linux-m68k.org>

commit 6cfeba53911d6d2f17ebbd1246893557d5ff5aeb upstream.

On multi-platform kernels, the Mac platform devices should be registered
when running on Mac only. Else it may crash later.

Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 arch/m68k/mac/config.c |    3 +++
 1 file changed, 3 insertions(+)

--- a/arch/m68k/mac/config.c
+++ b/arch/m68k/mac/config.c
@@ -981,6 +981,9 @@ int __init mac_platform_init(void)
 {
 	u8 *swim_base;
 
+	if (!MACH_IS_MAC)
+		return -ENODEV;
+
 	/*
 	 * Serial devices
 	 */

[ 29/78] mac80211: fix possible tid_rx->reorder_timer use after free

[Greg KH]

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

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

From: Stanislaw Gruszka <sgruszka@redhat.com>

commit d72308bff5c2fa207949a5925b020bce74495e33 upstream.

Is possible that we will arm the tid_rx->reorder_timer after
del_timer_sync() in ___ieee80211_stop_rx_ba_session(). We need to stop
timer after RCU grace period finish, so move it to
ieee80211_free_tid_rx(). Timer will not be armed again, as
rcu_dereference(sta->ampdu_mlme.tid_rx[tid]) will return NULL.

Debug object detected problem with the following warning:
ODEBUG: free active (active state 0) object type: timer_list hint: sta_rx_agg_reorder_timer_expired+0x0/0xf0 [mac80211]

Bug report (with all warning messages):
https://bugzilla.redhat.com/show_bug.cgi?id=804007

Reported-by: "jan p. springer" <jsd@igroup.org>
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 net/mac80211/agg-rx.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

--- a/net/mac80211/agg-rx.c
+++ b/net/mac80211/agg-rx.c
@@ -49,6 +49,8 @@ static void ieee80211_free_tid_rx(struct
 		container_of(h, struct tid_ampdu_rx, rcu_head);
 	int i;
 
+	del_timer_sync(&tid_rx->reorder_timer);
+
 	for (i = 0; i < tid_rx->buf_size; i++)
 		dev_kfree_skb(tid_rx->reorder_buf[i]);
 	kfree(tid_rx->reorder_buf);
@@ -91,7 +93,6 @@ void ___ieee80211_stop_rx_ba_session(str
 				     tid, WLAN_BACK_RECIPIENT, reason);
 
 	del_timer_sync(&tid_rx->session_timer);
-	del_timer_sync(&tid_rx->reorder_timer);
 
 	call_rcu(&tid_rx->rcu_head, ieee80211_free_tid_rx);
 }

[ 30/78] rtlwifi: rtl8192ce: rtl8192cu: rtl8192de: Fix low-gain setting when scanning

[Greg KH]

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

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

From: Larry Finger <Larry.Finger@lwfinger.net>

commit 643c61e119459e9d750087b7b34be94491efebf9 upstream.

In https://bugzilla.redhat.com/show_bug.cgi?id=770207, slowdowns of driver
rtl8192ce are reported. One fix (commit a9b89e2) has already been applied,
and it helped, but the maximum RX speed would still drop to 1 Mbps. As in
the previous fix, the initial gain was determined to be the problem; however,
the problem arises from a setting of the gain when scans are started.

Driver rtl8192de also has the same code structure - this one is fixed as well.

Reported-and-Tested-by: Ivan Pesin <ivan.pesin@gmail.com>
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/net/wireless/rtlwifi/rtl8192c/phy_common.c |    2 +-
 drivers/net/wireless/rtlwifi/rtl8192de/phy.c       |    2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

--- a/drivers/net/wireless/rtlwifi/rtl8192c/phy_common.c
+++ b/drivers/net/wireless/rtlwifi/rtl8192c/phy_common.c
@@ -1968,7 +1968,7 @@ void rtl92c_phy_set_io(struct ieee80211_
 		break;
 	case IO_CMD_PAUSE_DM_BY_SCAN:
 		rtlphy->initgain_backup.xaagccore1 = dm_digtable.cur_igvalue;
-		dm_digtable.cur_igvalue = 0x17;
+		dm_digtable.cur_igvalue = 0x37;
 		rtl92c_dm_write_dig(hw);
 		break;
 	default:
--- a/drivers/net/wireless/rtlwifi/rtl8192de/phy.c
+++ b/drivers/net/wireless/rtlwifi/rtl8192de/phy.c
@@ -3192,7 +3192,7 @@ static void rtl92d_phy_set_io(struct iee
 		break;
 	case IO_CMD_PAUSE_DM_BY_SCAN:
 		rtlphy->initgain_backup.xaagccore1 = de_digtable.cur_igvalue;
-		de_digtable.cur_igvalue = 0x17;
+		de_digtable.cur_igvalue = 0x37;
 		rtl92d_dm_write_dig(hw);
 		break;
 	default:

[ 31/78] ath9k: fix max noise floor threshold

[Greg KH]

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

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

From: Rajkumar Manoharan <rmanohar@qca.qualcomm.com>

commit 2ee0a07028d2cde6e131b73f029dae2b93c50f3a upstream.

Currently the maximum noise floor limit is set as too high (-60dB). The
assumption of having a higher threshold limit is that it would help
de-sensitize the receiver (reduce phy errors) from continuous
interference. But when we have a bursty interference where there are
collisions and then free air time and if the receiver is desensitized too
much, it will miss the normal packets too. Lets make use of chips
specific min, nom and max limits always. This patch helps to improve the
connection stability in congested networks.

Cc: Paul Stewart <pstew@google.com>
Tested-by: Gary Morain <gmorain@google.com>
Signed-off-by: Madhan Jaganathan <madhanj@qca.qualcomm.com>
Signed-off-by: Rajkumar Manoharan <rmanohar@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/net/wireless/ath/ath9k/calib.c |    5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

--- a/drivers/net/wireless/ath/ath9k/calib.c
+++ b/drivers/net/wireless/ath/ath9k/calib.c
@@ -20,7 +20,6 @@
 
 /* Common calibration code */
 
-#define ATH9K_NF_TOO_HIGH	-60
 
 static int16_t ath9k_hw_get_nf_hist_mid(int16_t *nfCalBuffer)
 {
@@ -346,10 +345,10 @@ static void ath9k_hw_nf_sanitize(struct
 			"NF calibrated [%s] [chain %d] is %d\n",
 			(i >= 3 ? "ext" : "ctl"), i % 3, nf[i]);
 
-		if (nf[i] > ATH9K_NF_TOO_HIGH) {
+		if (nf[i] > limit->max) {
 			ath_dbg(common, CALIBRATE,
 				"NF[%d] (%d) > MAX (%d), correcting to MAX\n",
-				i, nf[i], ATH9K_NF_TOO_HIGH);
+				i, nf[i], limit->max);
 			nf[i] = limit->max;
 		} else if (nf[i] < limit->min) {
 			ath_dbg(common, CALIBRATE,

[ 32/78] drm: Validate requested virtual size against allocated fb size

[Greg KH]

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

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

From: Chris Wilson <chris@chris-wilson.co.uk>

commit 62fb376e214d3c1bfdf6fbb77dac162f6da04d7e upstream.

mplayer -vo fbdev tries to create a screen that is twice as tall as the
allocated framebuffer for "doublebuffering". By default, and all in-tree
users, only sufficient memory is allocated and mapped to satisfy the
smallest framebuffer and the virtual size is no larger than the actual.
For these users, we should therefore reject any userspace request to
create a screen that requires a buffer larger than the framebuffer
originally allocated.

References: https://bugs.freedesktop.org/show_bug.cgi?id=38138
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/gpu/drm/drm_fb_helper.c |    8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -617,9 +617,13 @@ int drm_fb_helper_check_var(struct fb_va
 		return -EINVAL;
 
 	/* Need to resize the fb object !!! */
-	if (var->bits_per_pixel > fb->bits_per_pixel || var->xres > fb->width || var->yres > fb->height) {
+	if (var->bits_per_pixel > fb->bits_per_pixel ||
+	    var->xres > fb->width || var->yres > fb->height ||
+	    var->xres_virtual > fb->width || var->yres_virtual > fb->height) {
 		DRM_DEBUG("fb userspace requested width/height/bpp is greater than current fb "
-			  "object %dx%d-%d > %dx%d-%d\n", var->xres, var->yres, var->bits_per_pixel,
+			  "request %dx%d-%d (virtual %dx%d) > %dx%d-%d\n",
+			  var->xres, var->yres, var->bits_per_pixel,
+			  var->xres_virtual, var->yres_virtual,
 			  fb->width, fb->height, fb->bits_per_pixel);
 		return -EINVAL;
 	}

[ 33/78] drm/radeon/kms: fix fans after resume

[Greg KH]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1941 bytes --]

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

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

From: Alex Deucher <alexander.deucher@amd.com>

commit 402976fe51b2d1a58a29ba06fa1ca5ace3a4cdcd upstream.

On pre-R600 asics, the SpeedFanControl table is not
executed as part of ASIC_Init as it is on newer asics.

Fixes:
https://bugzilla.kernel.org/show_bug.cgi?id=29412

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/gpu/drm/radeon/atom.c |   15 ++++++++++++++-
 drivers/gpu/drm/radeon/atom.h |    1 +
 2 files changed, 15 insertions(+), 1 deletion(-)

--- a/drivers/gpu/drm/radeon/atom.c
+++ b/drivers/gpu/drm/radeon/atom.c
@@ -1306,8 +1306,11 @@ struct atom_context *atom_parse(struct c
 
 int atom_asic_init(struct atom_context *ctx)
 {
+	struct radeon_device *rdev = ctx->card->dev->dev_private;
 	int hwi = CU16(ctx->data_table + ATOM_DATA_FWI_PTR);
 	uint32_t ps[16];
+	int ret;
+
 	memset(ps, 0, 64);
 
 	ps[0] = cpu_to_le32(CU32(hwi + ATOM_FWI_DEFSCLK_PTR));
@@ -1317,7 +1320,17 @@ int atom_asic_init(struct atom_context *
 
 	if (!CU16(ctx->cmd_table + 4 + 2 * ATOM_CMD_INIT))
 		return 1;
-	return atom_execute_table(ctx, ATOM_CMD_INIT, ps);
+	ret = atom_execute_table(ctx, ATOM_CMD_INIT, ps);
+	if (ret)
+		return ret;
+
+	memset(ps, 0, 64);
+
+	if (rdev->family < CHIP_R600) {
+		if (CU16(ctx->cmd_table + 4 + 2 * ATOM_CMD_SPDFANCNTL))
+			atom_execute_table(ctx, ATOM_CMD_SPDFANCNTL, ps);
+	}
+	return ret;
 }
 
 void atom_destroy(struct atom_context *ctx)
--- a/drivers/gpu/drm/radeon/atom.h
+++ b/drivers/gpu/drm/radeon/atom.h
@@ -44,6 +44,7 @@
 #define ATOM_CMD_SETSCLK	0x0A
 #define ATOM_CMD_SETMCLK	0x0B
 #define ATOM_CMD_SETPCLK	0x0C
+#define ATOM_CMD_SPDFANCNTL	0x39
 
 #define ATOM_DATA_FWI_PTR	0xC
 #define ATOM_DATA_IIO_PTR	0x32

[ 34/78] drm/i915: no-lvds quirk on MSI DC500

[Greg KH]

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

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

From: Anisse Astier <anisse@astier.eu>

commit 97effadb65ed08809e1720c8d3ee80b73a93665c upstream.

This hardware doesn't have an LVDS, it's a desktop box. Fix incorrect
LVDS detection.

Signed-off-by: Anisse Astier <anisse@astier.eu>
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/gpu/drm/i915/intel_lvds.c |    8 ++++++++
 1 file changed, 8 insertions(+)

--- a/drivers/gpu/drm/i915/intel_lvds.c
+++ b/drivers/gpu/drm/i915/intel_lvds.c
@@ -739,6 +739,14 @@ static const struct dmi_system_id intel_
 			DMI_MATCH(DMI_BOARD_NAME, "AT5NM10T-I"),
 		},
 	},
+	{
+		.callback = intel_no_lvds_dmi_callback,
+		.ident = "MSI Wind Box DC500",
+		.matches = {
+			DMI_MATCH(DMI_BOARD_VENDOR, "MICRO-STAR INTERNATIONAL CO., LTD"),
+			DMI_MATCH(DMI_BOARD_NAME, "MS-7469"),
+		},
+	},
 
 	{ }	/* terminating entry */
 };

[ 35/78] drm/i915: treat src w & h as fixed point in sprite handling code

[Greg KH]

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

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

From: Jesse Barnes <jbarnes@virtuousgeek.org>

commit b4db1e35ac59c144965f517bc575a0d75b60b03f upstream.

This was missed when we converted the source values to 16.16 fixed point.

Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Tested-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/gpu/drm/i915/intel_sprite.c |    3 +++
 1 file changed, 3 insertions(+)

--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -411,6 +411,9 @@ intel_update_plane(struct drm_plane *pla
 
 	old_obj = intel_plane->obj;
 
+	src_w = src_w >> 16;
+	src_h = src_h >> 16;
+
 	/* Pipe must be running... */
 	if (!(I915_READ(PIPECONF(pipe)) & PIPECONF_ENABLE))
 		return -EINVAL;

[ 36/78] drm/i915: Sanitize BIOS debugging bits from PIPECONF

[Greg KH]

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

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

From: Chris Wilson <chris@chris-wilson.co.uk>

commit f47166d2b0001fcb752b40c5a2d4db986dfbea68 upstream.

Quoting the BSpec from time immemorial:

  PIPEACONF, bits 28:27: Frame Start Delay (Debug)

  Used to delay the frame start signal that is sent to the display planes.
  Care must be taken to insure that there are enough lines during VBLANK
  to support this setting.

An instance of the BIOS leaving these bits set was found in the wild,
where it caused our modesetting to go all squiffy and skewiff.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=47271
Reported-and-tested-by: Eva Wang <evawang@linpus.com>
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=43012
Reported-and-tested-by: Carl Richell <carl@system76.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/gpu/drm/i915/i915_reg.h      |    1 +
 drivers/gpu/drm/i915/intel_display.c |    6 ++++++
 2 files changed, 7 insertions(+)

--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -2313,6 +2313,7 @@
 #define   PIPECONF_DISABLE	0
 #define   PIPECONF_DOUBLE_WIDE	(1<<30)
 #define   I965_PIPECONF_ACTIVE	(1<<30)
+#define   PIPECONF_FRAME_START_DELAY_MASK (3<<27)
 #define   PIPECONF_SINGLE_WIDE	0
 #define   PIPECONF_PIPE_UNLOCKED 0
 #define   PIPECONF_PIPE_LOCKED	(1<<25)
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -7497,6 +7497,12 @@ static void intel_sanitize_modesetting(s
 	struct drm_i915_private *dev_priv = dev->dev_private;
 	u32 reg, val;
 
+	/* Clear any frame start delays used for debugging left by the BIOS */
+	for_each_pipe(pipe) {
+		reg = PIPECONF(pipe);
+		I915_WRITE(reg, I915_READ(reg) & ~PIPECONF_FRAME_START_DELAY_MASK);
+	}
+
 	if (HAS_PCH_SPLIT(dev))
 		return;
 

[ 37/78] drm/i915: Add lock on drm_helper_resume_force_mode

[Greg KH]

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

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

From: Sean Paul <seanpaul@chromium.org>

commit 927a2f119e8235238a2fc64871051b16c9bdae75 upstream.

i915_drm_thaw was not locking the mode_config lock when calling
drm_helper_resume_force_mode. When there were multiple wake sources,
this caused FDI training failure on SNB which in turn corrupted the
display.

Signed-off-by: Sean Paul <seanpaul@chromium.org>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/gpu/drm/i915/i915_drv.c |    2 ++
 1 file changed, 2 insertions(+)

--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -508,7 +508,9 @@ static int i915_drm_thaw(struct drm_devi
 		drm_irq_install(dev);
 
 		/* Resume the modeset for every activated CRTC */
+		mutex_lock(&dev->mode_config.mutex);
 		drm_helper_resume_force_mode(dev);
+		mutex_unlock(&dev->mode_config.mutex);
 
 		if (IS_IRONLAKE_M(dev))
 			ironlake_enable_rc6(dev);

[ 38/78] drm/i915: quirk away broken OpRegion VBT

[Greg KH]

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

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

From: Daniel Vetter <daniel.vetter@ffwll.ch>

commit 25e341cfc33d94435472983825163e97fe370a6c upstream.

Somehow the BIOS manages to screw things up when copying the VBT
around, because the one we scrap from the VBIOS rom actually works.

Tested-by: Markus Heinz <markus.heinz@uni-dortmund.de>
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=28812
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/gpu/drm/i915/intel_bios.c |   23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

--- a/drivers/gpu/drm/i915/intel_bios.c
+++ b/drivers/gpu/drm/i915/intel_bios.c
@@ -24,6 +24,7 @@
  *    Eric Anholt <eric@anholt.net>
  *
  */
+#include <linux/dmi.h>
 #include <drm/drm_dp_helper.h>
 #include "drmP.h"
 #include "drm.h"
@@ -621,6 +622,26 @@ init_vbt_defaults(struct drm_i915_privat
 	dev_priv->edp.bpp = 18;
 }
 
+static int __init intel_no_opregion_vbt_callback(const struct dmi_system_id *id)
+{
+	DRM_DEBUG_KMS("Falling back to manually reading VBT from "
+		      "VBIOS ROM for %s\n",
+		      id->ident);
+	return 1;
+}
+
+static const struct dmi_system_id intel_no_opregion_vbt[] = {
+	{
+		.callback = intel_no_opregion_vbt_callback,
+		.ident = "ThinkCentre A57",
+		.matches = {
+			DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
+			DMI_MATCH(DMI_PRODUCT_NAME, "97027RG"),
+		},
+	},
+	{ }
+};
+
 /**
  * intel_parse_bios - find VBT and initialize settings from the BIOS
  * @dev: DRM device
@@ -641,7 +662,7 @@ intel_parse_bios(struct drm_device *dev)
 	init_vbt_defaults(dev_priv);
 
 	/* XXX Should this validation be moved to intel_opregion.c? */
-	if (dev_priv->opregion.vbt) {
+	if (!dmi_check_system(intel_no_opregion_vbt) && dev_priv->opregion.vbt) {
 		struct vbt_header *vbt = dev_priv->opregion.vbt;
 		if (memcmp(vbt->signature, "$VBT", 4) == 0) {
 			DRM_DEBUG_KMS("Using VBT from OpRegion: %20s\n",

[ 39/78] firmware_class: Rework usermodehelper check

[Greg KH]

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

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

From: "Rafael J. Wysocki" <rjw@sisk.pl>

commit fe2e39d8782d885755139304d8dba0b3e5bfa878 upstream.

Instead of two functions, read_lock_usermodehelper() and
usermodehelper_is_disabled(), used in combination, introduce
usermodehelper_read_trylock() that will only return with umhelper_sem
held if usermodehelper_disabled is unset (and will return -EAGAIN
otherwise) and make _request_firmware() use it.

Rename read_unlock_usermodehelper() to
usermodehelper_read_unlock() to follow the naming convention of the
new function.

Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/base/firmware_class.c |   11 +++++------
 include/linux/kmod.h          |    5 ++---
 kernel/kmod.c                 |   24 +++++++++++-------------
 3 files changed, 18 insertions(+), 22 deletions(-)

--- a/drivers/base/firmware_class.c
+++ b/drivers/base/firmware_class.c
@@ -533,12 +533,10 @@ static int _request_firmware(const struc
 		return 0;
 	}
 
-	read_lock_usermodehelper();
-
-	if (WARN_ON(usermodehelper_is_disabled())) {
+	retval = usermodehelper_read_trylock();
+	if (WARN_ON(retval)) {
 		dev_err(device, "firmware: %s will not be loaded\n", name);
-		retval = -EBUSY;
-		goto out;
+		goto out_nolock;
 	}
 
 	if (uevent)
@@ -573,8 +571,9 @@ static int _request_firmware(const struc
 	fw_destroy_instance(fw_priv);
 
 out:
-	read_unlock_usermodehelper();
+	usermodehelper_read_unlock();
 
+out_nolock:
 	if (retval) {
 		release_firmware(firmware);
 		*firmware_p = NULL;
--- a/include/linux/kmod.h
+++ b/include/linux/kmod.h
@@ -116,8 +116,7 @@ extern void usermodehelper_init(void);
 
 extern int usermodehelper_disable(void);
 extern void usermodehelper_enable(void);
-extern bool usermodehelper_is_disabled(void);
-extern void read_lock_usermodehelper(void);
-extern void read_unlock_usermodehelper(void);
+extern int usermodehelper_read_trylock(void);
+extern void usermodehelper_read_unlock(void);
 
 #endif /* __LINUX_KMOD_H__ */
--- a/kernel/kmod.c
+++ b/kernel/kmod.c
@@ -296,17 +296,24 @@ static DECLARE_WAIT_QUEUE_HEAD(running_h
  */
 #define RUNNING_HELPERS_TIMEOUT	(5 * HZ)
 
-void read_lock_usermodehelper(void)
+int usermodehelper_read_trylock(void)
 {
+	int ret = 0;
+
 	down_read(&umhelper_sem);
+	if (usermodehelper_disabled) {
+		up_read(&umhelper_sem);
+		ret = -EAGAIN;
+	}
+	return ret;
 }
-EXPORT_SYMBOL_GPL(read_lock_usermodehelper);
+EXPORT_SYMBOL_GPL(usermodehelper_read_trylock);
 
-void read_unlock_usermodehelper(void)
+void usermodehelper_read_unlock(void)
 {
 	up_read(&umhelper_sem);
 }
-EXPORT_SYMBOL_GPL(read_unlock_usermodehelper);
+EXPORT_SYMBOL_GPL(usermodehelper_read_unlock);
 
 /**
  * usermodehelper_disable - prevent new helpers from being started
@@ -347,15 +354,6 @@ void usermodehelper_enable(void)
 	up_write(&umhelper_sem);
 }
 
-/**
- * usermodehelper_is_disabled - check if new helpers are allowed to be started
- */
-bool usermodehelper_is_disabled(void)
-{
-	return usermodehelper_disabled;
-}
-EXPORT_SYMBOL_GPL(usermodehelper_is_disabled);
-
 static void helper_lock(void)
 {
 	atomic_inc(&running_helpers);

[ 40/78] firmware_class: Split _request_firmware() into three functions, v2

[Greg KH]

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

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

From: "Rafael J. Wysocki" <rjw@sisk.pl>

commit 811fa4004485dec8977176bf605a5b0508ee206c upstream.

Split _request_firmware() into three functions,
_request_firmware_prepare() doing preparatory work that need not be
done under umhelper_sem, _request_firmware_cleanup() doing the
post-error cleanup and _request_firmware() carrying out the remaining
operations.

This change is requisite for moving the acquisition of umhelper_sem
from _request_firmware() to the callers, which is going to be done
subsequently.

Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Reviewed-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/base/firmware_class.c |   58 +++++++++++++++++++++++++++++-------------
 1 file changed, 41 insertions(+), 17 deletions(-)

--- a/drivers/base/firmware_class.c
+++ b/drivers/base/firmware_class.c
@@ -435,7 +435,7 @@ static void firmware_class_timeout(u_lon
 }
 
 static struct firmware_priv *
-fw_create_instance(struct firmware *firmware, const char *fw_name,
+fw_create_instance(const struct firmware *firmware, const char *fw_name,
 		   struct device *device, bool uevent, bool nowait)
 {
 	struct firmware_priv *fw_priv;
@@ -449,7 +449,7 @@ fw_create_instance(struct firmware *firm
 		goto err_out;
 	}
 
-	fw_priv->fw = firmware;
+	fw_priv->fw = (struct firmware *)firmware;
 	fw_priv->nowait = nowait;
 	strcpy(fw_priv->fw_id, fw_name);
 	init_completion(&fw_priv->completion);
@@ -510,13 +510,10 @@ static void fw_destroy_instance(struct f
 	device_unregister(f_dev);
 }
 
-static int _request_firmware(const struct firmware **firmware_p,
-			     const char *name, struct device *device,
-			     bool uevent, bool nowait)
+static int _request_firmware_prepare(const struct firmware **firmware_p,
+				     const char *name, struct device *device)
 {
-	struct firmware_priv *fw_priv;
 	struct firmware *firmware;
-	int retval = 0;
 
 	if (!firmware_p)
 		return -EINVAL;
@@ -533,10 +530,26 @@ static int _request_firmware(const struc
 		return 0;
 	}
 
+	return 1;
+}
+
+static void _request_firmware_cleanup(const struct firmware **firmware_p)
+{
+	release_firmware(*firmware_p);
+	*firmware_p = NULL;
+}
+
+static int _request_firmware(const struct firmware *firmware,
+			     const char *name, struct device *device,
+			     bool uevent, bool nowait)
+{
+	struct firmware_priv *fw_priv;
+	int retval;
+
 	retval = usermodehelper_read_trylock();
 	if (WARN_ON(retval)) {
 		dev_err(device, "firmware: %s will not be loaded\n", name);
-		goto out_nolock;
+		return retval;
 	}
 
 	if (uevent)
@@ -572,13 +585,6 @@ static int _request_firmware(const struc
 
 out:
 	usermodehelper_read_unlock();
-
-out_nolock:
-	if (retval) {
-		release_firmware(firmware);
-		*firmware_p = NULL;
-	}
-
 	return retval;
 }
 
@@ -601,7 +607,17 @@ int
 request_firmware(const struct firmware **firmware_p, const char *name,
                  struct device *device)
 {
-        return _request_firmware(firmware_p, name, device, true, false);
+	int ret;
+
+	ret = _request_firmware_prepare(firmware_p, name, device);
+	if (ret <= 0)
+		return ret;
+
+	ret = _request_firmware(*firmware_p, name, device, true, false);
+	if (ret)
+		_request_firmware_cleanup(firmware_p);
+
+	return ret;
 }
 
 /**
@@ -639,8 +655,16 @@ static int request_firmware_work_func(vo
 		return 0;
 	}
 
-	ret = _request_firmware(&fw, fw_work->name, fw_work->device,
+	ret = _request_firmware_prepare(&fw, fw_work->name, fw_work->device);
+	if (ret <= 0)
+		goto out;
+
+	ret = _request_firmware(fw, fw_work->name, fw_work->device,
 				fw_work->uevent, true);
+	if (ret)
+		_request_firmware_cleanup(&fw);
+
+ out:
 	fw_work->cont(fw, fw_work->context);
 
 	module_put(fw_work->module);

[ 41/78] firmware_class: Do not warn that system is not ready from async loads

[Greg KH]

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

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

From: "Rafael J. Wysocki" <rjw@sisk.pl>

commit 9b78c1da60b3c62ccdd1509f0902ad19ceaf776b upstream.

If firmware is requested asynchronously, by calling
request_firmware_nowait(), there is no reason to fail the request
(and warn the user) when the system is (presumably temporarily)
unready to handle it (because user space is not available yet or
frozen).  For this reason, introduce an alternative routine for
read-locking umhelper_sem, usermodehelper_read_lock_wait(), that
will wait for usermodehelper_disabled to be unset (possibly with
a timeout) and make request_firmware_work_func() use it instead of
usermodehelper_read_trylock().

Accordingly, modify request_firmware() so that it uses
usermodehelper_read_trylock() to acquire umhelper_sem and remove
the code related to that lock from _request_firmware().

Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/base/firmware_class.c |   51 +++++++++++++++++++++---------------
 include/linux/kmod.h          |    1 
 kernel/kmod.c                 |   58 ++++++++++++++++++++++++++++++++----------
 3 files changed, 76 insertions(+), 34 deletions(-)

--- a/drivers/base/firmware_class.c
+++ b/drivers/base/firmware_class.c
@@ -81,6 +81,11 @@ enum {
 
 static int loading_timeout = 60;	/* In seconds */
 
+static inline long firmware_loading_timeout(void)
+{
+	return loading_timeout > 0 ? loading_timeout * HZ : MAX_SCHEDULE_TIMEOUT;
+}
+
 /* fw_lock could be moved to 'struct firmware_priv' but since it is just
  * guarding for corner cases a global lock should be OK */
 static DEFINE_MUTEX(fw_lock);
@@ -541,31 +546,22 @@ static void _request_firmware_cleanup(co
 
 static int _request_firmware(const struct firmware *firmware,
 			     const char *name, struct device *device,
-			     bool uevent, bool nowait)
+			     bool uevent, bool nowait, long timeout)
 {
 	struct firmware_priv *fw_priv;
-	int retval;
-
-	retval = usermodehelper_read_trylock();
-	if (WARN_ON(retval)) {
-		dev_err(device, "firmware: %s will not be loaded\n", name);
-		return retval;
-	}
+	int retval = 0;
 
 	if (uevent)
 		dev_dbg(device, "firmware: requesting %s\n", name);
 
 	fw_priv = fw_create_instance(firmware, name, device, uevent, nowait);
-	if (IS_ERR(fw_priv)) {
-		retval = PTR_ERR(fw_priv);
-		goto out;
-	}
+	if (IS_ERR(fw_priv))
+		return PTR_ERR(fw_priv);
 
 	if (uevent) {
-		if (loading_timeout > 0)
+		if (timeout != MAX_SCHEDULE_TIMEOUT)
 			mod_timer(&fw_priv->timeout,
-				  round_jiffies_up(jiffies +
-						   loading_timeout * HZ));
+				  round_jiffies_up(jiffies + timeout));
 
 		kobject_uevent(&fw_priv->dev.kobj, KOBJ_ADD);
 	}
@@ -582,9 +578,6 @@ static int _request_firmware(const struc
 	mutex_unlock(&fw_lock);
 
 	fw_destroy_instance(fw_priv);
-
-out:
-	usermodehelper_read_unlock();
 	return retval;
 }
 
@@ -613,7 +606,14 @@ request_firmware(const struct firmware *
 	if (ret <= 0)
 		return ret;
 
-	ret = _request_firmware(*firmware_p, name, device, true, false);
+	ret = usermodehelper_read_trylock();
+	if (WARN_ON(ret)) {
+		dev_err(device, "firmware: %s will not be loaded\n", name);
+	} else {
+		ret = _request_firmware(*firmware_p, name, device, true, false,
+					firmware_loading_timeout());
+		usermodehelper_read_unlock();
+	}
 	if (ret)
 		_request_firmware_cleanup(firmware_p);
 
@@ -648,6 +648,7 @@ static int request_firmware_work_func(vo
 {
 	struct firmware_work *fw_work = arg;
 	const struct firmware *fw;
+	long timeout;
 	int ret;
 
 	if (!arg) {
@@ -659,8 +660,16 @@ static int request_firmware_work_func(vo
 	if (ret <= 0)
 		goto out;
 
-	ret = _request_firmware(fw, fw_work->name, fw_work->device,
-				fw_work->uevent, true);
+	timeout = usermodehelper_read_lock_wait(firmware_loading_timeout());
+	if (timeout) {
+		ret = _request_firmware(fw, fw_work->name, fw_work->device,
+					fw_work->uevent, true, timeout);
+		usermodehelper_read_unlock();
+	} else {
+		dev_dbg(fw_work->device, "firmware: %s loading timed out\n",
+			fw_work->name);
+		ret = -EAGAIN;
+	}
 	if (ret)
 		_request_firmware_cleanup(&fw);
 
--- a/include/linux/kmod.h
+++ b/include/linux/kmod.h
@@ -117,6 +117,7 @@ extern void usermodehelper_init(void);
 extern int usermodehelper_disable(void);
 extern void usermodehelper_enable(void);
 extern int usermodehelper_read_trylock(void);
+extern long usermodehelper_read_lock_wait(long timeout);
 extern void usermodehelper_read_unlock(void);
 
 #endif /* __LINUX_KMOD_H__ */
--- a/kernel/kmod.c
+++ b/kernel/kmod.c
@@ -291,6 +291,12 @@ static atomic_t running_helpers = ATOMIC
 static DECLARE_WAIT_QUEUE_HEAD(running_helpers_waitq);
 
 /*
+ * Used by usermodehelper_read_lock_wait() to wait for usermodehelper_disabled
+ * to become 'false'.
+ */
+static DECLARE_WAIT_QUEUE_HEAD(usermodehelper_disabled_waitq);
+
+/*
  * Time to wait for running_helpers to become zero before the setting of
  * usermodehelper_disabled in usermodehelper_disable() fails
  */
@@ -309,6 +315,33 @@ int usermodehelper_read_trylock(void)
 }
 EXPORT_SYMBOL_GPL(usermodehelper_read_trylock);
 
+long usermodehelper_read_lock_wait(long timeout)
+{
+	DEFINE_WAIT(wait);
+
+	if (timeout < 0)
+		return -EINVAL;
+
+	down_read(&umhelper_sem);
+	for (;;) {
+		prepare_to_wait(&usermodehelper_disabled_waitq, &wait,
+				TASK_UNINTERRUPTIBLE);
+		if (!usermodehelper_disabled)
+			break;
+
+		up_read(&umhelper_sem);
+
+		timeout = schedule_timeout(timeout);
+		if (!timeout)
+			break;
+
+		down_read(&umhelper_sem);
+	}
+	finish_wait(&usermodehelper_disabled_waitq, &wait);
+	return timeout;
+}
+EXPORT_SYMBOL_GPL(usermodehelper_read_lock_wait);
+
 void usermodehelper_read_unlock(void)
 {
 	up_read(&umhelper_sem);
@@ -316,6 +349,17 @@ void usermodehelper_read_unlock(void)
 EXPORT_SYMBOL_GPL(usermodehelper_read_unlock);
 
 /**
+ * usermodehelper_enable - allow new helpers to be started again
+ */
+void usermodehelper_enable(void)
+{
+	down_write(&umhelper_sem);
+	usermodehelper_disabled = 0;
+	wake_up(&usermodehelper_disabled_waitq);
+	up_write(&umhelper_sem);
+}
+
+/**
  * usermodehelper_disable - prevent new helpers from being started
  */
 int usermodehelper_disable(void)
@@ -338,22 +382,10 @@ int usermodehelper_disable(void)
 	if (retval)
 		return 0;
 
-	down_write(&umhelper_sem);
-	usermodehelper_disabled = 0;
-	up_write(&umhelper_sem);
+	usermodehelper_enable();
 	return -EAGAIN;
 }
 
-/**
- * usermodehelper_enable - allow new helpers to be started again
- */
-void usermodehelper_enable(void)
-{
-	down_write(&umhelper_sem);
-	usermodehelper_disabled = 0;
-	up_write(&umhelper_sem);
-}
-
 static void helper_lock(void)
 {
 	atomic_inc(&running_helpers);

[ 42/78] PM / Runtime: dont forget to wake up waitqueue on failure

[Greg KH]

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

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

From: Alan Stern <stern@rowland.harvard.edu>

commit f2791d733a2f06997b573d1a3cfde21e6f529826 upstream.

This patch (as1535) fixes a bug in the runtime PM core.  When a
runtime suspend attempt completes, whether successfully or not, the
device's power.wait_queue is supposed to be signalled.  But this
doesn't happen in the failure pathway of rpm_suspend() when another
autosuspend attempt is rescheduled.  As a result, a task can get stuck
indefinitely on the wait queue (I have seen this happen in testing).

The patch fixes the problem by moving the wake_up_all() call up near
the start of the failure code.

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/base/power/runtime.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

--- a/drivers/base/power/runtime.c
+++ b/drivers/base/power/runtime.c
@@ -532,6 +532,8 @@ static int rpm_suspend(struct device *de
 	dev->power.suspend_time = ktime_set(0, 0);
 	dev->power.max_time_suspended_ns = -1;
 	dev->power.deferred_resume = false;
+	wake_up_all(&dev->power.wait_queue);
+
 	if (retval == -EAGAIN || retval == -EBUSY) {
 		dev->power.runtime_error = 0;
 
@@ -547,7 +549,6 @@ static int rpm_suspend(struct device *de
 	} else {
 		pm_runtime_cancel_pending(dev);
 	}
-	wake_up_all(&dev->power.wait_queue);
 	goto out;
 }
 

[ 43/78] PM / Hibernate: Disable usermode helpers right before freezing tasks

[Greg KH]

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

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

From: "Rafael J. Wysocki" <rjw@sisk.pl>

commit 7b5179ac14dbad945647ac9e76bbbf14ed9e0dbe upstream.

There is no reason to call usermodehelper_disable() before creating
memory bitmaps in hibernate() and software_resume(), so call it right
before freeze_processes(), in accordance with the other suspend and
hibernation code.  Consequently, call usermodehelper_enable() right
after the thawing of tasks rather than after freeing the memory
bitmaps.

Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 kernel/power/hibernate.c |   23 ++++++++++-------------
 1 file changed, 10 insertions(+), 13 deletions(-)

--- a/kernel/power/hibernate.c
+++ b/kernel/power/hibernate.c
@@ -609,19 +609,19 @@ int hibernate(void)
 	if (error)
 		goto Exit;
 
-	error = usermodehelper_disable();
-	if (error)
-		goto Exit;
-
 	/* Allocate memory management structures */
 	error = create_basic_memory_bitmaps();
 	if (error)
-		goto Enable_umh;
+		goto Exit;
 
 	printk(KERN_INFO "PM: Syncing filesystems ... ");
 	sys_sync();
 	printk("done.\n");
 
+	error = usermodehelper_disable();
+	if (error)
+		goto Exit;
+
 	error = freeze_processes();
 	if (error)
 		goto Free_bitmaps;
@@ -658,9 +658,8 @@ int hibernate(void)
  Thaw:
 	thaw_processes();
  Free_bitmaps:
-	free_basic_memory_bitmaps();
- Enable_umh:
 	usermodehelper_enable();
+	free_basic_memory_bitmaps();
  Exit:
 	pm_notifier_call_chain(PM_POST_HIBERNATION);
 	pm_restore_console();
@@ -775,15 +774,13 @@ static int software_resume(void)
 	if (error)
 		goto close_finish;
 
-	error = usermodehelper_disable();
+	error = create_basic_memory_bitmaps();
 	if (error)
 		goto close_finish;
 
-	error = create_basic_memory_bitmaps();
-	if (error) {
-		usermodehelper_enable();
+	error = usermodehelper_disable();
+	if (error)
 		goto close_finish;
-	}
 
 	pr_debug("PM: Preparing processes for restore.\n");
 	error = freeze_processes();
@@ -803,8 +800,8 @@ static int software_resume(void)
 	swsusp_free();
 	thaw_processes();
  Done:
-	free_basic_memory_bitmaps();
 	usermodehelper_enable();
+	free_basic_memory_bitmaps();
  Finish:
 	pm_notifier_call_chain(PM_POST_RESTORE);
 	pm_restore_console();

[ 00/78] 3.3.2-stable review

[Greg KH]

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

Responses should be made by Fri Apr 13 23:10:16 UTC 2012.
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.3.2-rc1.gz
and the diffstat can be found below.

thanks,

greg k-h

-------------
 Makefile                                           |    4 +-
 arch/arm/mach-at91/at91sam9263_devices.c           |    3 +-
 arch/arm/mach-at91/at91sam9g45_devices.c           |    6 +-
 arch/arm/mach-at91/board-sam9263ek.c               |    1 +
 arch/arm/mach-at91/board-sam9m10g45ek.c            |    1 +
 arch/m68k/mac/config.c                             |    3 +
 arch/x86/include/asm/timer.h                       |    8 +-
 arch/x86/kernel/apic/io_apic.c                     |   40 +----
 arch/x86/kernel/kgdb.c                             |   60 ++++++++
 arch/x86/kernel/tsc.c                              |    3 +-
 arch/x86/net/bpf_jit_comp.c                        |    2 +-
 drivers/acpi/acpica/tbfadt.c                       |    8 +-
 drivers/acpi/processor_thermal.c                   |   45 +++++-
 drivers/base/firmware_class.c                      |   96 ++++++++----
 drivers/base/power/runtime.c                       |    3 +-
 drivers/base/regmap/regcache-rbtree.c              |    8 +-
 drivers/dma/ioat/dma.c                             |   16 +-
 drivers/dma/ioat/dma.h                             |    6 +-
 drivers/dma/ioat/dma_v2.c                          |    8 +-
 drivers/dma/ioat/dma_v3.c                          |    8 +-
 drivers/gpu/drm/drm_fb_helper.c                    |    8 +-
 drivers/gpu/drm/i915/i915_drv.c                    |    2 +
 drivers/gpu/drm/i915/i915_reg.h                    |    1 +
 drivers/gpu/drm/i915/intel_bios.c                  |   23 ++-
 drivers/gpu/drm/i915/intel_display.c               |    6 +
 drivers/gpu/drm/i915/intel_lvds.c                  |    8 +
 drivers/gpu/drm/i915/intel_sprite.c                |    3 +
 drivers/gpu/drm/radeon/atom.c                      |   15 +-
 drivers/gpu/drm/radeon/atom.h                      |    1 +
 drivers/media/dvb/dvb-core/dvb_frontend.c          |   12 ++
 drivers/media/video/uvc/uvc_video.c                |   50 +++---
 drivers/mfd/da9052-spi.c                           |    4 +-
 drivers/mfd/twl6030-irq.c                          |   13 +-
 drivers/misc/kgdbts.c                              |  160 ++++++++++++++------
 drivers/mmc/core/sdio_bus.c                        |   12 +-
 drivers/mmc/host/atmel-mci.c                       |    9 +-
 drivers/mmc/host/sdhci-dove.c                      |    1 +
 drivers/mtd/devices/block2mtd.c                    |    1 +
 drivers/mtd/devices/doc2000.c                      |    2 +-
 drivers/mtd/devices/doc2001.c                      |    2 +-
 drivers/mtd/devices/doc2001plus.c                  |    2 +-
 drivers/mtd/devices/docg3.c                        |    2 +-
 drivers/mtd/devices/lart.c                         |    1 +
 drivers/mtd/devices/m25p80.c                       |    1 +
 drivers/mtd/devices/sst25l.c                       |    1 +
 drivers/mtd/maps/ixp4xx.c                          |    5 +-
 drivers/mtd/maps/lantiq-flash.c                    |    3 +-
 drivers/mtd/nand/gpmi-nand/gpmi-nand.c             |    2 +-
 drivers/net/ethernet/broadcom/tg3.c                |    4 +-
 drivers/net/ethernet/freescale/fsl_pq_mdio.c       |   12 +-
 drivers/net/ethernet/marvell/sky2.c                |    5 +-
 drivers/net/ethernet/via/via-rhine.c               |   12 +-
 drivers/net/usb/cdc_eem.c                          |    1 +
 drivers/net/usb/zaurus.c                           |    5 +
 drivers/net/wireless/ath/ath9k/calib.c             |    5 +-
 drivers/net/wireless/iwlegacy/3945-mac.c           |    1 -
 drivers/net/wireless/iwlegacy/4965-mac.c           |    1 -
 drivers/net/wireless/iwlegacy/common.c             |   18 ++-
 drivers/net/wireless/rtlwifi/rtl8192c/phy_common.c |    2 +-
 drivers/net/wireless/rtlwifi/rtl8192de/phy.c       |    2 +-
 drivers/platform/x86/acer-wmi.c                    |    1 +
 drivers/pnp/pnpacpi/core.c                         |    7 +-
 drivers/staging/android/lowmemorykiller.c          |   47 +-----
 drivers/target/tcm_fc/tcm_fc.h                     |    1 +
 drivers/target/tcm_fc/tfc_cmd.c                    |   10 +-
 drivers/target/tcm_fc/tfc_conf.c                   |   13 +-
 drivers/target/tcm_fc/tfc_io.c                     |    2 +
 drivers/usb/host/ohci-at91.c                       |    4 +-
 fs/cifs/file.c                                     |   10 +-
 fs/locks.c                                         |    3 +-
 fs/nfs/nfs4proc.c                                  |    2 +-
 include/linux/fs.h                                 |    5 +
 include/linux/kernel.h                             |   13 ++
 include/linux/kgdb.h                               |    7 +-
 include/linux/kmod.h                               |   27 +++-
 kernel/cred.c                                      |    2 +
 kernel/debug/debug_core.c                          |   53 +++----
 kernel/irq/migration.c                             |   10 +-
 kernel/kmod.c                                      |  117 ++++++++++----
 kernel/power/hibernate.c                           |   18 +--
 kernel/power/process.c                             |    8 +
 kernel/power/suspend.c                             |    7 -
 kernel/power/user.c                                |   10 +-
 kernel/sysctl.c                                    |    8 +-
 kernel/trace/trace.c                               |    4 +
 kernel/trace/trace_entries.h                       |   16 +-
 kernel/trace/trace_export.c                        |    2 +-
 net/mac80211/agg-rx.c                              |    3 +-
 net/rose/rose_dev.c                                |    4 +-
 scripts/mod/modpost.c                              |    9 +-
 scripts/mod/modpost.h                              |    1 +
 security/tomoyo/mount.c                            |   38 ++---
 sound/pci/hda/patch_realtek.c                      |   11 +-
 sound/soc/codecs/ak4642.c                          |    2 +-
 sound/soc/codecs/wm8994.c                          |    2 +-
 sound/soc/tegra/tegra_i2s.c                        |    2 +-
 96 files changed, 815 insertions(+), 411 deletions(-)

[ 44/78] PM / Sleep: Move disabling of usermode helpers to the freezer

[Greg KH]

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

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

From: "Rafael J. Wysocki" <rjw@sisk.pl>

commit 1e73203cd1157a03facc41ffb54050f5b28e55bd upstream.

The core suspend/hibernation code calls usermodehelper_disable() to
avoid race conditions between the freezer and the starting of
usermode helpers and each code path has to do that on its own.
However, it is always called right before freeze_processes()
and usermodehelper_enable() is always called right after
thaw_processes().  For this reason, to avoid code duplication and
to make the connection between usermodehelper_disable() and the
freezer more visible, make freeze_processes() call it and remove the
direct usermodehelper_disable() and usermodehelper_enable() calls
from all suspend/hibernation code paths.

Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 kernel/power/hibernate.c |   11 -----------
 kernel/power/process.c   |    7 +++++++
 kernel/power/suspend.c   |    7 -------
 kernel/power/user.c      |   10 +---------
 4 files changed, 8 insertions(+), 27 deletions(-)

--- a/kernel/power/hibernate.c
+++ b/kernel/power/hibernate.c
@@ -16,7 +16,6 @@
 #include <linux/string.h>
 #include <linux/device.h>
 #include <linux/async.h>
-#include <linux/kmod.h>
 #include <linux/delay.h>
 #include <linux/fs.h>
 #include <linux/mount.h>
@@ -618,10 +617,6 @@ int hibernate(void)
 	sys_sync();
 	printk("done.\n");
 
-	error = usermodehelper_disable();
-	if (error)
-		goto Exit;
-
 	error = freeze_processes();
 	if (error)
 		goto Free_bitmaps;
@@ -658,7 +653,6 @@ int hibernate(void)
  Thaw:
 	thaw_processes();
  Free_bitmaps:
-	usermodehelper_enable();
 	free_basic_memory_bitmaps();
  Exit:
 	pm_notifier_call_chain(PM_POST_HIBERNATION);
@@ -778,10 +772,6 @@ static int software_resume(void)
 	if (error)
 		goto close_finish;
 
-	error = usermodehelper_disable();
-	if (error)
-		goto close_finish;
-
 	pr_debug("PM: Preparing processes for restore.\n");
 	error = freeze_processes();
 	if (error) {
@@ -800,7 +790,6 @@ static int software_resume(void)
 	swsusp_free();
 	thaw_processes();
  Done:
-	usermodehelper_enable();
 	free_basic_memory_bitmaps();
  Finish:
 	pm_notifier_call_chain(PM_POST_RESTORE);
--- a/kernel/power/process.c
+++ b/kernel/power/process.c
@@ -16,6 +16,7 @@
 #include <linux/freezer.h>
 #include <linux/delay.h>
 #include <linux/workqueue.h>
+#include <linux/kmod.h>
 
 /* 
  * Timeout for stopping processes
@@ -122,6 +123,10 @@ int freeze_processes(void)
 {
 	int error;
 
+	error = usermodehelper_disable();
+	if (error)
+		return error;
+
 	if (!pm_freezing)
 		atomic_inc(&system_freezing_cnt);
 
@@ -187,6 +192,8 @@ void thaw_processes(void)
 	} while_each_thread(g, p);
 	read_unlock(&tasklist_lock);
 
+	usermodehelper_enable();
+
 	schedule();
 	printk("done.\n");
 }
--- a/kernel/power/suspend.c
+++ b/kernel/power/suspend.c
@@ -12,7 +12,6 @@
 #include <linux/delay.h>
 #include <linux/errno.h>
 #include <linux/init.h>
-#include <linux/kmod.h>
 #include <linux/console.h>
 #include <linux/cpu.h>
 #include <linux/syscalls.h>
@@ -101,17 +100,12 @@ static int suspend_prepare(void)
 	if (error)
 		goto Finish;
 
-	error = usermodehelper_disable();
-	if (error)
-		goto Finish;
-
 	error = suspend_freeze_processes();
 	if (!error)
 		return 0;
 
 	suspend_stats.failed_freeze++;
 	dpm_save_failed_step(SUSPEND_FREEZE);
-	usermodehelper_enable();
  Finish:
 	pm_notifier_call_chain(PM_POST_SUSPEND);
 	pm_restore_console();
@@ -259,7 +253,6 @@ int suspend_devices_and_enter(suspend_st
 static void suspend_finish(void)
 {
 	suspend_thaw_processes();
-	usermodehelper_enable();
 	pm_notifier_call_chain(PM_POST_SUSPEND);
 	pm_restore_console();
 }
--- a/kernel/power/user.c
+++ b/kernel/power/user.c
@@ -12,7 +12,6 @@
 #include <linux/suspend.h>
 #include <linux/syscalls.h>
 #include <linux/reboot.h>
-#include <linux/kmod.h>
 #include <linux/string.h>
 #include <linux/device.h>
 #include <linux/miscdevice.h>
@@ -222,14 +221,8 @@ static long snapshot_ioctl(struct file *
 		sys_sync();
 		printk("done.\n");
 
-		error = usermodehelper_disable();
-		if (error)
-			break;
-
 		error = freeze_processes();
-		if (error)
-			usermodehelper_enable();
-		else
+		if (!error)
 			data->frozen = 1;
 		break;
 
@@ -238,7 +231,6 @@ static long snapshot_ioctl(struct file *
 			break;
 		pm_restore_gfp_mask();
 		thaw_processes();
-		usermodehelper_enable();
 		data->frozen = 0;
 		break;
 

[ 45/78] PM / Sleep: Mitigate race between the freezer and request_firmware()

[Greg KH]

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

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

From: "Rafael J. Wysocki" <rjw@sisk.pl>

commit 247bc03742545fec2f79939a3b9f738392a0f7b4 upstream.

There is a race condition between the freezer and request_firmware()
such that if request_firmware() is run on one CPU and
freeze_processes() is run on another CPU and usermodehelper_disable()
called by it succeeds to grab umhelper_sem for writing before
usermodehelper_read_trylock() called from request_firmware()
acquires it for reading, the request_firmware() will fail and
trigger a WARN_ON() complaining that it was called at a wrong time.
However, in fact, it wasn't called at a wrong time and
freeze_processes() simply happened to be executed simultaneously.

To avoid this race, at least in some cases, modify
usermodehelper_read_trylock() so that it doesn't fail if the
freezing of tasks has just started and hasn't been completed yet.
Instead, during the freezing of tasks, it will try to freeze the
task that has called it so that it can wait until user space is
thawed without triggering the scary warning.

For this purpose, change usermodehelper_disabled so that it can
take three different values, UMH_ENABLED (0), UMH_FREEZING and
UMH_DISABLED.  The first one means that usermode helpers are
enabled, the last one means "hard disable" (i.e. the system is not
ready for usermode helpers to be used) and the second one
is reserved for the freezer.  Namely, when freeze_processes() is
started, it sets usermodehelper_disabled to UMH_FREEZING which
tells usermodehelper_read_trylock() that it shouldn't fail just
yet and should call try_to_freeze() if woken up and cannot
return immediately.  This way all freezable tasks that happen
to call request_firmware() right before freeze_processes() is
started and lose the race for umhelper_sem with it will be
frozen and will sleep until thaw_processes() unsets
usermodehelper_disabled.  [For the non-freezable callers of
request_firmware() the race for umhelper_sem against
freeze_processes() is unfortunately unavoidable.]

Reported-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 include/linux/kmod.h   |   21 +++++++++++++++++++--
 kernel/kmod.c          |   47 +++++++++++++++++++++++++++++++++++++----------
 kernel/power/process.c |    3 ++-
 3 files changed, 58 insertions(+), 13 deletions(-)

--- a/include/linux/kmod.h
+++ b/include/linux/kmod.h
@@ -112,10 +112,27 @@ call_usermodehelper(char *path, char **a
 
 extern struct ctl_table usermodehelper_table[];
 
+enum umh_disable_depth {
+	UMH_ENABLED = 0,
+	UMH_FREEZING,
+	UMH_DISABLED,
+};
+
 extern void usermodehelper_init(void);
 
-extern int usermodehelper_disable(void);
-extern void usermodehelper_enable(void);
+extern int __usermodehelper_disable(enum umh_disable_depth depth);
+extern void __usermodehelper_set_disable_depth(enum umh_disable_depth depth);
+
+static inline int usermodehelper_disable(void)
+{
+	return __usermodehelper_disable(UMH_DISABLED);
+}
+
+static inline void usermodehelper_enable(void)
+{
+	__usermodehelper_set_disable_depth(UMH_ENABLED);
+}
+
 extern int usermodehelper_read_trylock(void);
 extern long usermodehelper_read_lock_wait(long timeout);
 extern void usermodehelper_read_unlock(void);
--- a/kernel/kmod.c
+++ b/kernel/kmod.c
@@ -279,7 +279,7 @@ static void __call_usermodehelper(struct
  * land has been frozen during a system-wide hibernation or suspend operation).
  * Should always be manipulated under umhelper_sem acquired for write.
  */
-static int usermodehelper_disabled = 1;
+static enum umh_disable_depth usermodehelper_disabled = UMH_DISABLED;
 
 /* Number of helpers running */
 static atomic_t running_helpers = ATOMIC_INIT(0);
@@ -304,13 +304,30 @@ static DECLARE_WAIT_QUEUE_HEAD(usermodeh
 
 int usermodehelper_read_trylock(void)
 {
+	DEFINE_WAIT(wait);
 	int ret = 0;
 
 	down_read(&umhelper_sem);
-	if (usermodehelper_disabled) {
+	for (;;) {
+		prepare_to_wait(&usermodehelper_disabled_waitq, &wait,
+				TASK_INTERRUPTIBLE);
+		if (!usermodehelper_disabled)
+			break;
+
+		if (usermodehelper_disabled == UMH_DISABLED)
+			ret = -EAGAIN;
+
 		up_read(&umhelper_sem);
-		ret = -EAGAIN;
+
+		if (ret)
+			break;
+
+		schedule();
+		try_to_freeze();
+
+		down_read(&umhelper_sem);
 	}
+	finish_wait(&usermodehelper_disabled_waitq, &wait);
 	return ret;
 }
 EXPORT_SYMBOL_GPL(usermodehelper_read_trylock);
@@ -349,25 +366,35 @@ void usermodehelper_read_unlock(void)
 EXPORT_SYMBOL_GPL(usermodehelper_read_unlock);
 
 /**
- * usermodehelper_enable - allow new helpers to be started again
+ * __usermodehelper_set_disable_depth - Modify usermodehelper_disabled.
+ * depth: New value to assign to usermodehelper_disabled.
+ *
+ * Change the value of usermodehelper_disabled (under umhelper_sem locked for
+ * writing) and wakeup tasks waiting for it to change.
  */
-void usermodehelper_enable(void)
+void __usermodehelper_set_disable_depth(enum umh_disable_depth depth)
 {
 	down_write(&umhelper_sem);
-	usermodehelper_disabled = 0;
+	usermodehelper_disabled = depth;
 	wake_up(&usermodehelper_disabled_waitq);
 	up_write(&umhelper_sem);
 }
 
 /**
- * usermodehelper_disable - prevent new helpers from being started
+ * __usermodehelper_disable - Prevent new helpers from being started.
+ * @depth: New value to assign to usermodehelper_disabled.
+ *
+ * Set usermodehelper_disabled to @depth and wait for running helpers to exit.
  */
-int usermodehelper_disable(void)
+int __usermodehelper_disable(enum umh_disable_depth depth)
 {
 	long retval;
 
+	if (!depth)
+		return -EINVAL;
+
 	down_write(&umhelper_sem);
-	usermodehelper_disabled = 1;
+	usermodehelper_disabled = depth;
 	up_write(&umhelper_sem);
 
 	/*
@@ -382,7 +409,7 @@ int usermodehelper_disable(void)
 	if (retval)
 		return 0;
 
-	usermodehelper_enable();
+	__usermodehelper_set_disable_depth(UMH_ENABLED);
 	return -EAGAIN;
 }
 
--- a/kernel/power/process.c
+++ b/kernel/power/process.c
@@ -123,7 +123,7 @@ int freeze_processes(void)
 {
 	int error;
 
-	error = usermodehelper_disable();
+	error = __usermodehelper_disable(UMH_FREEZING);
 	if (error)
 		return error;
 
@@ -135,6 +135,7 @@ int freeze_processes(void)
 	error = try_to_freeze_tasks(true);
 	if (!error) {
 		printk("done.");
+		__usermodehelper_set_disable_depth(UMH_DISABLED);
 		oom_killer_disable();
 	}
 	printk("\n");

[ 46/78] kgdb,debug_core: pass the breakpoint struct instead of address and memory

[Greg KH]

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

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

From: Jason Wessel <jason.wessel@windriver.com>

commit 98b54aa1a2241b59372468bd1e9c2d207bdba54b upstream.

There is extra state information that needs to be exposed in the
kgdb_bpt structure for tracking how a breakpoint was installed.  The
debug_core only uses the the probe_kernel_write() to install
breakpoints, but this is not enough for all the archs.  Some arch such
as x86 need to use text_poke() in order to install a breakpoint into a
read only page.

Passing the kgdb_bpt structure to kgdb_arch_set_breakpoint() and
kgdb_arch_remove_breakpoint() allows other archs to set the type
variable which indicates how the breakpoint was installed.

Signed-off-by: Jason Wessel <jason.wessel@windriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 include/linux/kgdb.h      |    4 +--
 kernel/debug/debug_core.c |   53 ++++++++++++++++++++--------------------------
 2 files changed, 26 insertions(+), 31 deletions(-)

--- a/include/linux/kgdb.h
+++ b/include/linux/kgdb.h
@@ -207,8 +207,8 @@ extern void kgdb_arch_set_pc(struct pt_r
 
 /* Optional functions. */
 extern int kgdb_validate_break_address(unsigned long addr);
-extern int kgdb_arch_set_breakpoint(unsigned long addr, char *saved_instr);
-extern int kgdb_arch_remove_breakpoint(unsigned long addr, char *bundle);
+extern int kgdb_arch_set_breakpoint(struct kgdb_bkpt *bpt);
+extern int kgdb_arch_remove_breakpoint(struct kgdb_bkpt *bpt);
 
 /**
  *	kgdb_arch_late - Perform any architecture specific initalization.
--- a/kernel/debug/debug_core.c
+++ b/kernel/debug/debug_core.c
@@ -157,37 +157,39 @@ early_param("nokgdbroundup", opt_nokgdbr
  * Weak aliases for breakpoint management,
  * can be overriden by architectures when needed:
  */
-int __weak kgdb_arch_set_breakpoint(unsigned long addr, char *saved_instr)
+int __weak kgdb_arch_set_breakpoint(struct kgdb_bkpt *bpt)
 {
 	int err;
 
-	err = probe_kernel_read(saved_instr, (char *)addr, BREAK_INSTR_SIZE);
+	err = probe_kernel_read(bpt->saved_instr, (char *)bpt->bpt_addr,
+				BREAK_INSTR_SIZE);
 	if (err)
 		return err;
-
-	return probe_kernel_write((char *)addr, arch_kgdb_ops.gdb_bpt_instr,
-				  BREAK_INSTR_SIZE);
+	err = probe_kernel_write((char *)bpt->bpt_addr,
+				 arch_kgdb_ops.gdb_bpt_instr, BREAK_INSTR_SIZE);
+	return err;
 }
 
-int __weak kgdb_arch_remove_breakpoint(unsigned long addr, char *bundle)
+int __weak kgdb_arch_remove_breakpoint(struct kgdb_bkpt *bpt)
 {
-	return probe_kernel_write((char *)addr,
-				  (char *)bundle, BREAK_INSTR_SIZE);
+	return probe_kernel_write((char *)bpt->bpt_addr,
+				  (char *)bpt->saved_instr, BREAK_INSTR_SIZE);
 }
 
 int __weak kgdb_validate_break_address(unsigned long addr)
 {
-	char tmp_variable[BREAK_INSTR_SIZE];
+	struct kgdb_bkpt tmp;
 	int err;
-	/* Validate setting the breakpoint and then removing it.  In the
+	/* Validate setting the breakpoint and then removing it.  If the
 	 * remove fails, the kernel needs to emit a bad message because we
 	 * are deep trouble not being able to put things back the way we
 	 * found them.
 	 */
-	err = kgdb_arch_set_breakpoint(addr, tmp_variable);
+	tmp.bpt_addr = addr;
+	err = kgdb_arch_set_breakpoint(&tmp);
 	if (err)
 		return err;
-	err = kgdb_arch_remove_breakpoint(addr, tmp_variable);
+	err = kgdb_arch_remove_breakpoint(&tmp);
 	if (err)
 		printk(KERN_ERR "KGDB: Critical breakpoint error, kernel "
 		   "memory destroyed at: %lx", addr);
@@ -231,7 +233,6 @@ static void kgdb_flush_swbreak_addr(unsi
  */
 int dbg_activate_sw_breakpoints(void)
 {
-	unsigned long addr;
 	int error;
 	int ret = 0;
 	int i;
@@ -240,16 +241,15 @@ int dbg_activate_sw_breakpoints(void)
 		if (kgdb_break[i].state != BP_SET)
 			continue;
 
-		addr = kgdb_break[i].bpt_addr;
-		error = kgdb_arch_set_breakpoint(addr,
-				kgdb_break[i].saved_instr);
+		error = kgdb_arch_set_breakpoint(&kgdb_break[i]);
 		if (error) {
 			ret = error;
-			printk(KERN_INFO "KGDB: BP install failed: %lx", addr);
+			printk(KERN_INFO "KGDB: BP install failed: %lx",
+			       kgdb_break[i].bpt_addr);
 			continue;
 		}
 
-		kgdb_flush_swbreak_addr(addr);
+		kgdb_flush_swbreak_addr(kgdb_break[i].bpt_addr);
 		kgdb_break[i].state = BP_ACTIVE;
 	}
 	return ret;
@@ -298,7 +298,6 @@ int dbg_set_sw_break(unsigned long addr)
 
 int dbg_deactivate_sw_breakpoints(void)
 {
-	unsigned long addr;
 	int error;
 	int ret = 0;
 	int i;
@@ -306,15 +305,14 @@ int dbg_deactivate_sw_breakpoints(void)
 	for (i = 0; i < KGDB_MAX_BREAKPOINTS; i++) {
 		if (kgdb_break[i].state != BP_ACTIVE)
 			continue;
-		addr = kgdb_break[i].bpt_addr;
-		error = kgdb_arch_remove_breakpoint(addr,
-					kgdb_break[i].saved_instr);
+		error = kgdb_arch_remove_breakpoint(&kgdb_break[i]);
 		if (error) {
-			printk(KERN_INFO "KGDB: BP remove failed: %lx\n", addr);
+			printk(KERN_INFO "KGDB: BP remove failed: %lx\n",
+			       kgdb_break[i].bpt_addr);
 			ret = error;
 		}
 
-		kgdb_flush_swbreak_addr(addr);
+		kgdb_flush_swbreak_addr(kgdb_break[i].bpt_addr);
 		kgdb_break[i].state = BP_SET;
 	}
 	return ret;
@@ -348,7 +346,6 @@ int kgdb_isremovedbreak(unsigned long ad
 
 int dbg_remove_all_break(void)
 {
-	unsigned long addr;
 	int error;
 	int i;
 
@@ -356,12 +353,10 @@ int dbg_remove_all_break(void)
 	for (i = 0; i < KGDB_MAX_BREAKPOINTS; i++) {
 		if (kgdb_break[i].state != BP_ACTIVE)
 			goto setundefined;
-		addr = kgdb_break[i].bpt_addr;
-		error = kgdb_arch_remove_breakpoint(addr,
-				kgdb_break[i].saved_instr);
+		error = kgdb_arch_remove_breakpoint(&kgdb_break[i]);
 		if (error)
 			printk(KERN_ERR "KGDB: breakpoint remove failed: %lx\n",
-			   addr);
+			       kgdb_break[i].bpt_addr);
 setundefined:
 		kgdb_break[i].state = BP_UNDEFINED;
 	}

[ 47/78] kgdbts: Fix kernel oops with CONFIG_DEBUG_RODATA

[Greg KH]

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

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

From: Jason Wessel <jason.wessel@windriver.com>

commit 456ca7ff24841bf2d2a2dfd690fe7d42ef70d932 upstream.

On x86 the kgdb test suite will oops when the kernel is compiled with
CONFIG_DEBUG_RODATA and you run the tests after boot time. This is
regression has existed since 2.6.26 by commit: b33cb815 (kgdbts: Use
HW breakpoints with CONFIG_DEBUG_RODATA).

The test suite can use hw breakpoints for all the tests, but it has to
execute the hardware breakpoint specific tests first in order to
determine that the hw breakpoints actually work.  Specifically the
very first test causes an oops:

# echo V1I1 > /sys/module/kgdbts/parameters/kgdbts
kgdb: Registered I/O driver kgdbts.
kgdbts:RUN plant and detach test

Entering kdb (current=0xffff880017aa9320, pid 1078) on processor 0 due to Keyboard Entry
[0]kdb> kgdbts: ERROR PUT: end of test buffer on 'plant_and_detach_test' line 1 expected OK got $E14#aa
WARNING: at drivers/misc/kgdbts.c:730 run_simple_test+0x151/0x2c0()
[...oops clipped...]

This commit re-orders the running of the tests and puts the RODATA
check into its own function so as to correctly avoid the kernel oops
by detecting and using the hw breakpoints.

Signed-off-by: Jason Wessel <jason.wessel@windriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/misc/kgdbts.c |   52 ++++++++++++++++++++++++++------------------------
 1 file changed, 28 insertions(+), 24 deletions(-)

--- a/drivers/misc/kgdbts.c
+++ b/drivers/misc/kgdbts.c
@@ -885,6 +885,22 @@ static void run_singlestep_break_test(vo
 	kgdbts_break_test();
 }
 
+static void test_debug_rodata(void)
+{
+#ifdef CONFIG_DEBUG_RODATA
+	/* Until there is an api to write to read-only text segments, use
+	 * HW breakpoints for the remainder of any tests, else print a
+	 * failure message if hw breakpoints do not work.
+	 */
+	if (!(arch_kgdb_ops.flags & KGDB_HW_BREAKPOINT && hwbreaks_ok)) {
+		eprintk("kgdbts: HW breakpoints BROKEN, ending tests\n");
+		return;
+	}
+	force_hwbrks = 1;
+	v1printk("kgdbts:Using HW breakpoints for SW breakpoint tests\n");
+#endif /* CONFIG_DEBUG_RODATA */
+}
+
 static void kgdbts_run_tests(void)
 {
 	char *ptr;
@@ -907,6 +923,18 @@ static void kgdbts_run_tests(void)
 	if (ptr)
 		sstep_test = simple_strtol(ptr+1, NULL, 10);
 
+	/* All HW break point tests */
+	if (arch_kgdb_ops.flags & KGDB_HW_BREAKPOINT) {
+		hwbreaks_ok = 1;
+		v1printk("kgdbts:RUN hw breakpoint test\n");
+		run_breakpoint_test(1);
+		v1printk("kgdbts:RUN hw write breakpoint test\n");
+		run_hw_break_test(1);
+		v1printk("kgdbts:RUN access write breakpoint test\n");
+		run_hw_break_test(0);
+	}
+	test_debug_rodata();
+
 	/* required internal KGDB tests */
 	v1printk("kgdbts:RUN plant and detach test\n");
 	run_plant_and_detach_test(0);
@@ -924,35 +952,11 @@ static void kgdbts_run_tests(void)
 
 	/* ===Optional tests=== */
 
-	/* All HW break point tests */
-	if (arch_kgdb_ops.flags & KGDB_HW_BREAKPOINT) {
-		hwbreaks_ok = 1;
-		v1printk("kgdbts:RUN hw breakpoint test\n");
-		run_breakpoint_test(1);
-		v1printk("kgdbts:RUN hw write breakpoint test\n");
-		run_hw_break_test(1);
-		v1printk("kgdbts:RUN access write breakpoint test\n");
-		run_hw_break_test(0);
-	}
-
 	if (nmi_sleep) {
 		v1printk("kgdbts:RUN NMI sleep %i seconds test\n", nmi_sleep);
 		run_nmi_sleep_test(nmi_sleep);
 	}
 
-#ifdef CONFIG_DEBUG_RODATA
-	/* Until there is an api to write to read-only text segments, use
-	 * HW breakpoints for the remainder of any tests, else print a
-	 * failure message if hw breakpoints do not work.
-	 */
-	if (!(arch_kgdb_ops.flags & KGDB_HW_BREAKPOINT && hwbreaks_ok)) {
-		eprintk("kgdbts: HW breakpoints do not work,"
-			"skipping remaining tests\n");
-		return;
-	}
-	force_hwbrks = 1;
-#endif /* CONFIG_DEBUG_RODATA */
-
 	/* If the do_fork test is run it will be the last test that is
 	 * executed because a kernel thread will be spawned at the very
 	 * end to unregister the debug hooks.

[ 48/78] kgdbts: (1 of 2) fix single step awareness to work correctly with SMP

[Greg KH]

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

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

From: Jason Wessel <jason.wessel@windriver.com>

commit 486c5987a00a89d56c2c04c506417ef8f823ca2e upstream.

The do_fork and sys_open tests have never worked properly on anything
other than a UP configuration with the kgdb test suite.  This is
because the test suite did not fully implement the behavior of a real
debugger.  A real debugger tracks the state of what thread it asked to
single step and can correctly continue other threads of execution or
conditionally stop while waiting for the original thread single step
request to return.

Below is a simple method to cause a fatal kernel oops with the kgdb
test suite on a 4 processor x86 system:

while [ 1 ] ; do ls > /dev/null 2> /dev/null; done&
while [ 1 ] ; do ls > /dev/null 2> /dev/null; done&
while [ 1 ] ; do ls > /dev/null 2> /dev/null; done&
while [ 1 ] ; do ls > /dev/null 2> /dev/null; done&
echo V1I1F1000 > /sys/module/kgdbts/parameters/kgdbts

Very soon after starting the test the kernel will oops with a message like:

kgdbts: BP mismatch 3b7da66480 expected ffffffff8106a590
WARNING: at drivers/misc/kgdbts.c:303 check_and_rewind_pc+0xe0/0x100()
Call Trace:
 [<ffffffff812994a0>] check_and_rewind_pc+0xe0/0x100
 [<ffffffff81298945>] validate_simple_test+0x25/0xc0
 [<ffffffff81298f77>] run_simple_test+0x107/0x2c0
 [<ffffffff81298a18>] kgdbts_put_char+0x18/0x20

The warn will turn to a hard kernel crash shortly after that because
the pc will not get properly rewound to the right value after hitting
a breakpoint leading to a hard lockup.

This change is broken up into 2 pieces because archs that have hw
single stepping (2.6.26 and up) need different changes than archs that
do not have hw single stepping (3.0 and up).  This change implements
the correct behavior for an arch that supports hw single stepping.

A minor defect was fixed where sys_open should be do_sys_open
for the sys_open break point test.  This solves the problem of running
a 64 bit with a 32 bit user space.  The sys_open() never gets called
when using the 32 bit file system for the kgdb testsuite because the
32 bit binaries invoke the compat_sys_open() call leading to the test
never completing.

In order to mimic a real debugger, the kgdb test suite now tracks the
most recent thread that was continued (cont_thread_id), with the
intent to single step just this thread.  When the response to the
single step request stops in a different thread that hit the original
break point that thread will now get continued, while the debugger
waits for the thread with the single step pending.  Here is a high
level description of the sequence of events.

   cont_instead_of_sstep = 0;

1) set breakpoint at do_fork
2) continue
3)   Save the thread id where we stop to cont_thread_id
4) Remove breakpoint at do_fork
5) Reset the PC if needed depending on kernel exception type
6) if (cont_instead_of_sstep) { continue } else { single step }
7)   Check where we stopped
       if current thread != cont_thread_id {
           cont_instead_of_sstep = 1;
           goto step 5
       } else {
           cont_instead_of_sstep = 0;
       }
8) clean up and run test again if needed

Signed-off-by: Jason Wessel <jason.wessel@windriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/misc/kgdbts.c |   54 +++++++++++++++++++++++++++++++++++++++-----------
 1 file changed, 43 insertions(+), 11 deletions(-)

--- a/drivers/misc/kgdbts.c
+++ b/drivers/misc/kgdbts.c
@@ -134,6 +134,9 @@ static int force_hwbrks;
 static int hwbreaks_ok;
 static int hw_break_val;
 static int hw_break_val2;
+static int cont_instead_of_sstep;
+static unsigned long cont_thread_id;
+static unsigned long sstep_thread_id;
 #if defined(CONFIG_ARM) || defined(CONFIG_MIPS) || defined(CONFIG_SPARC)
 static int arch_needs_sstep_emulation = 1;
 #else
@@ -211,7 +214,7 @@ static unsigned long lookup_addr(char *a
 	if (!strcmp(arg, "kgdbts_break_test"))
 		addr = (unsigned long)kgdbts_break_test;
 	else if (!strcmp(arg, "sys_open"))
-		addr = (unsigned long)sys_open;
+		addr = (unsigned long)do_sys_open;
 	else if (!strcmp(arg, "do_fork"))
 		addr = (unsigned long)do_fork;
 	else if (!strcmp(arg, "hw_break_val"))
@@ -283,6 +286,16 @@ static void hw_break_val_write(void)
 	hw_break_val++;
 }
 
+static int get_thread_id_continue(char *put_str, char *arg)
+{
+	char *ptr = &put_str[11];
+
+	if (put_str[1] != 'T' || put_str[2] != '0')
+		return 1;
+	kgdb_hex2long(&ptr, &cont_thread_id);
+	return 0;
+}
+
 static int check_and_rewind_pc(char *put_str, char *arg)
 {
 	unsigned long addr = lookup_addr(arg);
@@ -324,6 +337,18 @@ static int check_single_step(char *put_s
 	gdb_regs_to_pt_regs(kgdbts_gdb_regs, &kgdbts_regs);
 	v2printk("Singlestep stopped at IP: %lx\n",
 		   instruction_pointer(&kgdbts_regs));
+
+	if (sstep_thread_id != cont_thread_id && !arch_needs_sstep_emulation) {
+		/*
+		 * Ensure we stopped in the same thread id as before, else the
+		 * debugger should continue until the original thread that was
+		 * single stepped is scheduled again, emulating gdb's behavior.
+		 */
+		v2printk("ThrID does not match: %lx\n", cont_thread_id);
+		cont_instead_of_sstep = 1;
+		ts.idx -= 4;
+		return 0;
+	}
 	if (instruction_pointer(&kgdbts_regs) == addr) {
 		eprintk("kgdbts: SingleStep failed at %lx\n",
 			   instruction_pointer(&kgdbts_regs));
@@ -368,7 +393,12 @@ static int got_break(char *put_str, char
 static void emul_sstep_get(char *arg)
 {
 	if (!arch_needs_sstep_emulation) {
-		fill_get_buf(arg);
+		if (cont_instead_of_sstep) {
+			cont_instead_of_sstep = 0;
+			fill_get_buf("c");
+		} else {
+			fill_get_buf(arg);
+		}
 		return;
 	}
 	switch (sstep_state) {
@@ -398,9 +428,11 @@ static void emul_sstep_get(char *arg)
 static int emul_sstep_put(char *put_str, char *arg)
 {
 	if (!arch_needs_sstep_emulation) {
-		if (!strncmp(put_str+1, arg, 2))
-			return 0;
-		return 1;
+		char *ptr = &put_str[11];
+		if (put_str[1] != 'T' || put_str[2] != '0')
+			return 1;
+		kgdb_hex2long(&ptr, &sstep_thread_id);
+		return 0;
 	}
 	switch (sstep_state) {
 	case 1:
@@ -502,10 +534,10 @@ static struct test_struct bad_read_test[
 static struct test_struct singlestep_break_test[] = {
 	{ "?", "S0*" }, /* Clear break points */
 	{ "kgdbts_break_test", "OK", sw_break, }, /* set sw breakpoint */
-	{ "c", "T0*", }, /* Continue */
+	{ "c", "T0*", NULL, get_thread_id_continue }, /* Continue */
+	{ "kgdbts_break_test", "OK", sw_rem_break }, /*remove breakpoint */
 	{ "g", "kgdbts_break_test", NULL, check_and_rewind_pc },
 	{ "write", "OK", write_regs }, /* Write registers */
-	{ "kgdbts_break_test", "OK", sw_rem_break }, /*remove breakpoint */
 	{ "s", "T0*", emul_sstep_get, emul_sstep_put }, /* Single step */
 	{ "g", "kgdbts_break_test", NULL, check_single_step },
 	{ "kgdbts_break_test", "OK", sw_break, }, /* set sw breakpoint */
@@ -523,10 +555,10 @@ static struct test_struct singlestep_bre
 static struct test_struct do_fork_test[] = {
 	{ "?", "S0*" }, /* Clear break points */
 	{ "do_fork", "OK", sw_break, }, /* set sw breakpoint */
-	{ "c", "T0*", }, /* Continue */
+	{ "c", "T0*", NULL, get_thread_id_continue }, /* Continue */
+	{ "do_fork", "OK", sw_rem_break }, /*remove breakpoint */
 	{ "g", "do_fork", NULL, check_and_rewind_pc }, /* check location */
 	{ "write", "OK", write_regs }, /* Write registers */
-	{ "do_fork", "OK", sw_rem_break }, /*remove breakpoint */
 	{ "s", "T0*", emul_sstep_get, emul_sstep_put }, /* Single step */
 	{ "g", "do_fork", NULL, check_single_step },
 	{ "do_fork", "OK", sw_break, }, /* set sw breakpoint */
@@ -541,10 +573,10 @@ static struct test_struct do_fork_test[]
 static struct test_struct sys_open_test[] = {
 	{ "?", "S0*" }, /* Clear break points */
 	{ "sys_open", "OK", sw_break, }, /* set sw breakpoint */
-	{ "c", "T0*", }, /* Continue */
+	{ "c", "T0*", NULL, get_thread_id_continue }, /* Continue */
+	{ "sys_open", "OK", sw_rem_break }, /*remove breakpoint */
 	{ "g", "sys_open", NULL, check_and_rewind_pc }, /* check location */
 	{ "write", "OK", write_regs }, /* Write registers */
-	{ "sys_open", "OK", sw_rem_break }, /*remove breakpoint */
 	{ "s", "T0*", emul_sstep_get, emul_sstep_put }, /* Single step */
 	{ "g", "sys_open", NULL, check_single_step },
 	{ "sys_open", "OK", sw_break, }, /* set sw breakpoint */

[ 49/78] kgdbts: (2 of 2) fix single step awareness to work correctly with SMP

[Greg KH]

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

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

From: Jason Wessel <jason.wessel@windriver.com>

commit 23bbd8e346f1ef3fc1219c79cea53d8d52b207d8 upstream.

The do_fork and sys_open tests have never worked properly on anything
other than a UP configuration with the kgdb test suite.  This is
because the test suite did not fully implement the behavior of a real
debugger.  A real debugger tracks the state of what thread it asked to
single step and can correctly continue other threads of execution or
conditionally stop while waiting for the original thread single step
request to return.

Below is a simple method to cause a fatal kernel oops with the kgdb
test suite on a 2 processor ARM system:

while [ 1 ] ; do ls > /dev/null 2> /dev/null; done&
while [ 1 ] ; do ls > /dev/null 2> /dev/null; done&
echo V1I1F100 > /sys/module/kgdbts/parameters/kgdbts

Very soon after starting the test the kernel will start warning with
messages like:

kgdbts: BP mismatch c002487c expected c0024878
------------[ cut here ]------------
WARNING: at drivers/misc/kgdbts.c:317 check_and_rewind_pc+0x9c/0xc4()
[<c01f6520>] (check_and_rewind_pc+0x9c/0xc4)
[<c01f595c>] (validate_simple_test+0x3c/0xc4)
[<c01f60d4>] (run_simple_test+0x1e8/0x274)

The kernel will eventually recovers, but the test suite has completely
failed to test anything useful.

This patch implements behavior similar to a real debugger that does
not rely on hardware single stepping by using only software planted
breakpoints.

In order to mimic a real debugger, the kgdb test suite now tracks the
most recent thread that was continued (cont_thread_id), with the
intent to single step just this thread.  When the response to the
single step request stops in a different thread that hit the original
break point that thread will now get continued, while the debugger
waits for the thread with the single step pending.  Here is a high
level description of the sequence of events.

   cont_instead_of_sstep = 0;

1) set breakpoint at do_fork
2) continue
3)   Save the thread id where we stop to cont_thread_id
4) Remove breakpoint at do_fork
5) Reset the PC if needed depending on kernel exception type
6) soft single step
7)   Check where we stopped
       if current thread != cont_thread_id {
           if (here for more than 2 times for the same thead) {
              ### must be a really busy system, start test again ###
	      goto step 1
           }
           goto step 5
       } else {
           cont_instead_of_sstep = 0;
       }
8) clean up and run test again if needed
9) Clear out any threads that were waiting on a break point at the
   point in time the test is ended with get_cont_catch().  This
   happens sometimes because breakpoints are used in place of single
   stepping and some threads could have been in the debugger exception
   handling queue because breakpoints were hit concurrently on
   different CPUs.  This also means we wait at least one second before
   unplumbing the debugger connection at the very end, so as respond
   to any debug threads waiting to be serviced.

Signed-off-by: Jason Wessel <jason.wessel@windriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/misc/kgdbts.c |   73 ++++++++++++++++++++++++++++++++++++++++++--------
 1 file changed, 62 insertions(+), 11 deletions(-)

--- a/drivers/misc/kgdbts.c
+++ b/drivers/misc/kgdbts.c
@@ -142,7 +142,9 @@ static int arch_needs_sstep_emulation =
 #else
 static int arch_needs_sstep_emulation;
 #endif
+static unsigned long cont_addr;
 static unsigned long sstep_addr;
+static int restart_from_top_after_write;
 static int sstep_state;
 
 /* Storage for the registers, in GDB format. */
@@ -190,7 +192,8 @@ static int kgdbts_unreg_thread(void *ptr
 	 */
 	while (!final_ack)
 		msleep_interruptible(1500);
-
+	/* Pause for any other threads to exit after final ack. */
+	msleep_interruptible(1000);
 	if (configured)
 		kgdb_unregister_io_module(&kgdbts_io_ops);
 	configured = 0;
@@ -312,13 +315,21 @@ static int check_and_rewind_pc(char *put
 	if (addr + BREAK_INSTR_SIZE == ip)
 		offset = -BREAK_INSTR_SIZE;
 #endif
-	if (strcmp(arg, "silent") && ip + offset != addr) {
+
+	if (arch_needs_sstep_emulation && sstep_addr &&
+	    ip + offset == sstep_addr &&
+	    ((!strcmp(arg, "sys_open") || !strcmp(arg, "do_fork")))) {
+		/* This is special case for emulated single step */
+		v2printk("Emul: rewind hit single step bp\n");
+		restart_from_top_after_write = 1;
+	} else if (strcmp(arg, "silent") && ip + offset != addr) {
 		eprintk("kgdbts: BP mismatch %lx expected %lx\n",
 			   ip + offset, addr);
 		return 1;
 	}
 	/* Readjust the instruction pointer if needed */
 	ip += offset;
+	cont_addr = ip;
 #ifdef GDB_ADJUSTS_BREAK_OFFSET
 	instruction_pointer_set(&kgdbts_regs, ip);
 #endif
@@ -328,6 +339,8 @@ static int check_and_rewind_pc(char *put
 static int check_single_step(char *put_str, char *arg)
 {
 	unsigned long addr = lookup_addr(arg);
+	static int matched_id;
+
 	/*
 	 * From an arch indepent point of view the instruction pointer
 	 * should be on a different instruction
@@ -338,17 +351,28 @@ static int check_single_step(char *put_s
 	v2printk("Singlestep stopped at IP: %lx\n",
 		   instruction_pointer(&kgdbts_regs));
 
-	if (sstep_thread_id != cont_thread_id && !arch_needs_sstep_emulation) {
+	if (sstep_thread_id != cont_thread_id) {
 		/*
 		 * Ensure we stopped in the same thread id as before, else the
 		 * debugger should continue until the original thread that was
 		 * single stepped is scheduled again, emulating gdb's behavior.
 		 */
 		v2printk("ThrID does not match: %lx\n", cont_thread_id);
+		if (arch_needs_sstep_emulation) {
+			if (matched_id &&
+			    instruction_pointer(&kgdbts_regs) != addr)
+				goto continue_test;
+			matched_id++;
+			ts.idx -= 2;
+			sstep_state = 0;
+			return 0;
+		}
 		cont_instead_of_sstep = 1;
 		ts.idx -= 4;
 		return 0;
 	}
+continue_test:
+	matched_id = 0;
 	if (instruction_pointer(&kgdbts_regs) == addr) {
 		eprintk("kgdbts: SingleStep failed at %lx\n",
 			   instruction_pointer(&kgdbts_regs));
@@ -390,6 +414,31 @@ static int got_break(char *put_str, char
 	return 1;
 }
 
+static void get_cont_catch(char *arg)
+{
+	/* Always send detach because the test is completed at this point */
+	fill_get_buf("D");
+}
+
+static int put_cont_catch(char *put_str, char *arg)
+{
+	/* This is at the end of the test and we catch any and all input */
+	v2printk("kgdbts: cleanup task: %lx\n", sstep_thread_id);
+	ts.idx--;
+	return 0;
+}
+
+static int emul_reset(char *put_str, char *arg)
+{
+	if (strncmp(put_str, "$OK", 3))
+		return 1;
+	if (restart_from_top_after_write) {
+		restart_from_top_after_write = 0;
+		ts.idx = -1;
+	}
+	return 0;
+}
+
 static void emul_sstep_get(char *arg)
 {
 	if (!arch_needs_sstep_emulation) {
@@ -443,8 +492,7 @@ static int emul_sstep_put(char *put_str,
 		v2printk("Stopped at IP: %lx\n",
 			 instruction_pointer(&kgdbts_regs));
 		/* Want to stop at IP + break instruction size by default */
-		sstep_addr = instruction_pointer(&kgdbts_regs) +
-			BREAK_INSTR_SIZE;
+		sstep_addr = cont_addr + BREAK_INSTR_SIZE;
 		break;
 	case 2:
 		if (strncmp(put_str, "$OK", 3)) {
@@ -456,6 +504,9 @@ static int emul_sstep_put(char *put_str,
 		if (strncmp(put_str, "$T0", 3)) {
 			eprintk("kgdbts: failed continue sstep\n");
 			return 1;
+		} else {
+			char *ptr = &put_str[11];
+			kgdb_hex2long(&ptr, &sstep_thread_id);
 		}
 		break;
 	case 4:
@@ -558,13 +609,13 @@ static struct test_struct do_fork_test[]
 	{ "c", "T0*", NULL, get_thread_id_continue }, /* Continue */
 	{ "do_fork", "OK", sw_rem_break }, /*remove breakpoint */
 	{ "g", "do_fork", NULL, check_and_rewind_pc }, /* check location */
-	{ "write", "OK", write_regs }, /* Write registers */
+	{ "write", "OK", write_regs, emul_reset }, /* Write registers */
 	{ "s", "T0*", emul_sstep_get, emul_sstep_put }, /* Single step */
 	{ "g", "do_fork", NULL, check_single_step },
 	{ "do_fork", "OK", sw_break, }, /* set sw breakpoint */
 	{ "7", "T0*", skip_back_repeat_test }, /* Loop based on repeat_test */
 	{ "D", "OK", NULL, final_ack_set }, /* detach and unregister I/O */
-	{ "", "" },
+	{ "", "", get_cont_catch, put_cont_catch },
 };
 
 /* Test for hitting a breakpoint at sys_open for what ever the number
@@ -576,13 +627,13 @@ static struct test_struct sys_open_test[
 	{ "c", "T0*", NULL, get_thread_id_continue }, /* Continue */
 	{ "sys_open", "OK", sw_rem_break }, /*remove breakpoint */
 	{ "g", "sys_open", NULL, check_and_rewind_pc }, /* check location */
-	{ "write", "OK", write_regs }, /* Write registers */
+	{ "write", "OK", write_regs, emul_reset }, /* Write registers */
 	{ "s", "T0*", emul_sstep_get, emul_sstep_put }, /* Single step */
 	{ "g", "sys_open", NULL, check_single_step },
 	{ "sys_open", "OK", sw_break, }, /* set sw breakpoint */
 	{ "7", "T0*", skip_back_repeat_test }, /* Loop based on repeat_test */
 	{ "D", "OK", NULL, final_ack_set }, /* detach and unregister I/O */
-	{ "", "" },
+	{ "", "", get_cont_catch, put_cont_catch },
 };
 
 /*
@@ -725,8 +776,8 @@ static int run_simple_test(int is_get_ch
 	/* This callback is a put char which is when kgdb sends data to
 	 * this I/O module.
 	 */
-	if (ts.tst[ts.idx].get[0] == '\0' &&
-		ts.tst[ts.idx].put[0] == '\0') {
+	if (ts.tst[ts.idx].get[0] == '\0' && ts.tst[ts.idx].put[0] == '\0' &&
+	    !ts.tst[ts.idx].get_handler) {
 		eprintk("kgdbts: ERROR: beyond end of test on"
 			   " '%s' line %i\n", ts.name, ts.idx);
 		return 0;

[ 50/78] x86,kgdb: Fix DEBUG_RODATA limitation using text_poke()

[Greg KH]

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

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

From: Jason Wessel <jason.wessel@windriver.com>

commit 3751d3e85cf693e10e2c47c03c8caa65e171099b upstream.

There has long been a limitation using software breakpoints with a
kernel compiled with CONFIG_DEBUG_RODATA going back to 2.6.26. For
this particular patch, it will apply cleanly and has been tested all
the way back to 2.6.36.

The kprobes code uses the text_poke() function which accommodates
writing a breakpoint into a read-only page.  The x86 kgdb code can
solve the problem similarly by overriding the default breakpoint
set/remove routines and using text_poke() directly.

The x86 kgdb code will first attempt to use the traditional
probe_kernel_write(), and next try using a the text_poke() function.
The break point install method is tracked such that the correct break
point removal routine will get called later on.

Cc: x86@kernel.org
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Inspried-by: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
Signed-off-by: Jason Wessel <jason.wessel@windriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 arch/x86/kernel/kgdb.c |   60 +++++++++++++++++++++++++++++++++++++++++++++++++
 drivers/misc/kgdbts.c  |   17 -------------
 include/linux/kgdb.h   |    3 +-
 3 files changed, 62 insertions(+), 18 deletions(-)

--- a/arch/x86/kernel/kgdb.c
+++ b/arch/x86/kernel/kgdb.c
@@ -43,6 +43,8 @@
 #include <linux/smp.h>
 #include <linux/nmi.h>
 #include <linux/hw_breakpoint.h>
+#include <linux/uaccess.h>
+#include <linux/memory.h>
 
 #include <asm/debugreg.h>
 #include <asm/apicdef.h>
@@ -740,6 +742,64 @@ void kgdb_arch_set_pc(struct pt_regs *re
 	regs->ip = ip;
 }
 
+int kgdb_arch_set_breakpoint(struct kgdb_bkpt *bpt)
+{
+	int err;
+	char opc[BREAK_INSTR_SIZE];
+
+	bpt->type = BP_BREAKPOINT;
+	err = probe_kernel_read(bpt->saved_instr, (char *)bpt->bpt_addr,
+				BREAK_INSTR_SIZE);
+	if (err)
+		return err;
+	err = probe_kernel_write((char *)bpt->bpt_addr,
+				 arch_kgdb_ops.gdb_bpt_instr, BREAK_INSTR_SIZE);
+#ifdef CONFIG_DEBUG_RODATA
+	if (!err)
+		return err;
+	/*
+	 * It is safe to call text_poke() because normal kernel execution
+	 * is stopped on all cores, so long as the text_mutex is not locked.
+	 */
+	if (mutex_is_locked(&text_mutex))
+		return -EBUSY;
+	text_poke((void *)bpt->bpt_addr, arch_kgdb_ops.gdb_bpt_instr,
+		  BREAK_INSTR_SIZE);
+	err = probe_kernel_read(opc, (char *)bpt->bpt_addr, BREAK_INSTR_SIZE);
+	if (err)
+		return err;
+	if (memcmp(opc, arch_kgdb_ops.gdb_bpt_instr, BREAK_INSTR_SIZE))
+		return -EINVAL;
+	bpt->type = BP_POKE_BREAKPOINT;
+#endif /* CONFIG_DEBUG_RODATA */
+	return err;
+}
+
+int kgdb_arch_remove_breakpoint(struct kgdb_bkpt *bpt)
+{
+#ifdef CONFIG_DEBUG_RODATA
+	int err;
+	char opc[BREAK_INSTR_SIZE];
+
+	if (bpt->type != BP_POKE_BREAKPOINT)
+		goto knl_write;
+	/*
+	 * It is safe to call text_poke() because normal kernel execution
+	 * is stopped on all cores, so long as the text_mutex is not locked.
+	 */
+	if (mutex_is_locked(&text_mutex))
+		goto knl_write;
+	text_poke((void *)bpt->bpt_addr, bpt->saved_instr, BREAK_INSTR_SIZE);
+	err = probe_kernel_read(opc, (char *)bpt->bpt_addr, BREAK_INSTR_SIZE);
+	if (err || memcmp(opc, bpt->saved_instr, BREAK_INSTR_SIZE))
+		goto knl_write;
+	return err;
+knl_write:
+#endif /* CONFIG_DEBUG_RODATA */
+	return probe_kernel_write((char *)bpt->bpt_addr,
+				  (char *)bpt->saved_instr, BREAK_INSTR_SIZE);
+}
+
 struct kgdb_arch arch_kgdb_ops = {
 	/* Breakpoint instruction: */
 	.gdb_bpt_instr		= { 0xcc },
--- a/drivers/misc/kgdbts.c
+++ b/drivers/misc/kgdbts.c
@@ -968,22 +968,6 @@ static void run_singlestep_break_test(vo
 	kgdbts_break_test();
 }
 
-static void test_debug_rodata(void)
-{
-#ifdef CONFIG_DEBUG_RODATA
-	/* Until there is an api to write to read-only text segments, use
-	 * HW breakpoints for the remainder of any tests, else print a
-	 * failure message if hw breakpoints do not work.
-	 */
-	if (!(arch_kgdb_ops.flags & KGDB_HW_BREAKPOINT && hwbreaks_ok)) {
-		eprintk("kgdbts: HW breakpoints BROKEN, ending tests\n");
-		return;
-	}
-	force_hwbrks = 1;
-	v1printk("kgdbts:Using HW breakpoints for SW breakpoint tests\n");
-#endif /* CONFIG_DEBUG_RODATA */
-}
-
 static void kgdbts_run_tests(void)
 {
 	char *ptr;
@@ -1016,7 +1000,6 @@ static void kgdbts_run_tests(void)
 		v1printk("kgdbts:RUN access write breakpoint test\n");
 		run_hw_break_test(0);
 	}
-	test_debug_rodata();
 
 	/* required internal KGDB tests */
 	v1printk("kgdbts:RUN plant and detach test\n");
--- a/include/linux/kgdb.h
+++ b/include/linux/kgdb.h
@@ -63,7 +63,8 @@ enum kgdb_bptype {
 	BP_HARDWARE_BREAKPOINT,
 	BP_WRITE_WATCHPOINT,
 	BP_READ_WATCHPOINT,
-	BP_ACCESS_WATCHPOINT
+	BP_ACCESS_WATCHPOINT,
+	BP_POKE_BREAKPOINT,
 };
 
 enum kgdb_bpstate {

[ 51/78] CIFS: Fix VFS lock usage for oplocked files

[Greg KH]

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

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

From: Pavel Shilovsky <piastry@etersoft.ru>

commit 66189be74ff5f9f3fd6444315b85be210d07cef2 upstream.

We can deadlock if we have a write oplock and two processes
use the same file handle. In this case the first process can't
unlock its lock if the second process blocked on the lock in the
same time.

Fix it by using posix_lock_file rather than posix_lock_file_wait
under cinode->lock_mutex. If we request a blocking lock and
posix_lock_file indicates that there is another lock that prevents
us, wait untill that lock is released and restart our call.

Acked-by: Jeff Layton <jlayton@redhat.com>
Signed-off-by: Pavel Shilovsky <piastry@etersoft.ru>
Signed-off-by: Steve French <sfrench@us.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 fs/cifs/file.c     |   10 +++++++++-
 fs/locks.c         |    3 ++-
 include/linux/fs.h |    5 +++++
 3 files changed, 16 insertions(+), 2 deletions(-)

--- a/fs/cifs/file.c
+++ b/fs/cifs/file.c
@@ -835,13 +835,21 @@ cifs_posix_lock_set(struct file *file, s
 	if ((flock->fl_flags & FL_POSIX) == 0)
 		return rc;
 
+try_again:
 	mutex_lock(&cinode->lock_mutex);
 	if (!cinode->can_cache_brlcks) {
 		mutex_unlock(&cinode->lock_mutex);
 		return rc;
 	}
-	rc = posix_lock_file_wait(file, flock);
+
+	rc = posix_lock_file(file, flock, NULL);
 	mutex_unlock(&cinode->lock_mutex);
+	if (rc == FILE_LOCK_DEFERRED) {
+		rc = wait_event_interruptible(flock->fl_wait, !flock->fl_next);
+		if (!rc)
+			goto try_again;
+		locks_delete_block(flock);
+	}
 	return rc;
 }
 
--- a/fs/locks.c
+++ b/fs/locks.c
@@ -510,12 +510,13 @@ static void __locks_delete_block(struct
 
 /*
  */
-static void locks_delete_block(struct file_lock *waiter)
+void locks_delete_block(struct file_lock *waiter)
 {
 	lock_flocks();
 	__locks_delete_block(waiter);
 	unlock_flocks();
 }
+EXPORT_SYMBOL(locks_delete_block);
 
 /* Insert waiter into blocker's block list.
  * We use a circular list so that processes can be easily woken up in
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -1210,6 +1210,7 @@ extern int vfs_setlease(struct file *, l
 extern int lease_modify(struct file_lock **, int);
 extern int lock_may_read(struct inode *, loff_t start, unsigned long count);
 extern int lock_may_write(struct inode *, loff_t start, unsigned long count);
+extern void locks_delete_block(struct file_lock *waiter);
 extern void lock_flocks(void);
 extern void unlock_flocks(void);
 #else /* !CONFIG_FILE_LOCKING */
@@ -1354,6 +1355,10 @@ static inline int lock_may_write(struct
 	return 1;
 }
 
+static inline void locks_delete_block(struct file_lock *waiter)
+{
+}
+
 static inline void lock_flocks(void)
 {
 }

[ 52/78] USB: ohci-at91: fix vbus_pin_active_low handling

[Greg KH]

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

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

From: Nicolas Ferre <nicolas.ferre@atmel.com>

commit 1e7caf8bcf1b49eae152ad7cf442775472dd587c upstream.

The information is not properly taken into account
for {get|set}_power() functions.

Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Acked-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/usb/host/ohci-at91.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

--- a/drivers/usb/host/ohci-at91.c
+++ b/drivers/usb/host/ohci-at91.c
@@ -245,7 +245,7 @@ static void ohci_at91_usb_set_power(stru
 		return;
 
 	gpio_set_value(pdata->vbus_pin[port],
-		       !pdata->vbus_pin_active_low[port] ^ enable);
+		       pdata->vbus_pin_active_low[port] ^ enable);
 }
 
 static int ohci_at91_usb_get_power(struct at91_usbh_data *pdata, int port)
@@ -257,7 +257,7 @@ static int ohci_at91_usb_get_power(struc
 		return -EINVAL;
 
 	return gpio_get_value(pdata->vbus_pin[port]) ^
-		!pdata->vbus_pin_active_low[port];
+		pdata->vbus_pin_active_low[port];
 }
 
 /*

[ 53/78] ARM: at91/USB host: specify and handle properly vbus_pin_active_low

[Greg KH]

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

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

From: Nicolas Ferre <nicolas.ferre@atmel.com>

commit cca0355a09b1bfe9f8985285199a346e13cacf39 upstream.

Due to an error while handling vbus_pin_active_low in ohci-at91 driver,
the specification of this property was not good in devices/board files.

Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Acked-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 arch/arm/mach-at91/at91sam9263_devices.c |    3 ++-
 arch/arm/mach-at91/at91sam9g45_devices.c |    6 ++++--
 arch/arm/mach-at91/board-sam9263ek.c     |    1 +
 arch/arm/mach-at91/board-sam9m10g45ek.c  |    1 +
 4 files changed, 8 insertions(+), 3 deletions(-)

--- a/arch/arm/mach-at91/at91sam9263_devices.c
+++ b/arch/arm/mach-at91/at91sam9263_devices.c
@@ -71,7 +71,8 @@ void __init at91_add_device_usbh(struct
 	/* Enable VBus control for UHP ports */
 	for (i = 0; i < data->ports; i++) {
 		if (gpio_is_valid(data->vbus_pin[i]))
-			at91_set_gpio_output(data->vbus_pin[i], 0);
+			at91_set_gpio_output(data->vbus_pin[i],
+					     data->vbus_pin_active_low[i]);
 	}
 
 	/* Enable overcurrent notification */
--- a/arch/arm/mach-at91/at91sam9g45_devices.c
+++ b/arch/arm/mach-at91/at91sam9g45_devices.c
@@ -122,7 +122,8 @@ void __init at91_add_device_usbh_ohci(st
 	/* Enable VBus control for UHP ports */
 	for (i = 0; i < data->ports; i++) {
 		if (gpio_is_valid(data->vbus_pin[i]))
-			at91_set_gpio_output(data->vbus_pin[i], 0);
+			at91_set_gpio_output(data->vbus_pin[i],
+					     data->vbus_pin_active_low[i]);
 	}
 
 	/* Enable overcurrent notification */
@@ -183,7 +184,8 @@ void __init at91_add_device_usbh_ehci(st
 	/* Enable VBus control for UHP ports */
 	for (i = 0; i < data->ports; i++) {
 		if (gpio_is_valid(data->vbus_pin[i]))
-			at91_set_gpio_output(data->vbus_pin[i], 0);
+			at91_set_gpio_output(data->vbus_pin[i],
+					     data->vbus_pin_active_low[i]);
 	}
 
 	usbh_ehci_data = *data;
--- a/arch/arm/mach-at91/board-sam9263ek.c
+++ b/arch/arm/mach-at91/board-sam9263ek.c
@@ -74,6 +74,7 @@ static void __init ek_init_early(void)
 static struct at91_usbh_data __initdata ek_usbh_data = {
 	.ports		= 2,
 	.vbus_pin	= { AT91_PIN_PA24, AT91_PIN_PA21 },
+	.vbus_pin_active_low = {1, 1},
 	.overcurrent_pin= {-EINVAL, -EINVAL},
 };
 
--- a/arch/arm/mach-at91/board-sam9m10g45ek.c
+++ b/arch/arm/mach-at91/board-sam9m10g45ek.c
@@ -69,6 +69,7 @@ static void __init ek_init_early(void)
 static struct at91_usbh_data __initdata ek_usbh_hs_data = {
 	.ports		= 2,
 	.vbus_pin	= {AT91_PIN_PD1, AT91_PIN_PD3},
+	.vbus_pin_active_low = {1, 1},
 	.overcurrent_pin= {-EINVAL, -EINVAL},
 };
 

[ 54/78] mmc: sdio: Use empty system suspend/resume callbacks at the bus level

[Greg KH]

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

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

From: "Rafael J. Wysocki" <rjw@sisk.pl>

commit e841a7c69b708eeaf784fd517978006e8319b03a upstream.

Neil Brown reports that commit 35cd133c

   PM: Run the driver callback directly if the subsystem one is not there

breaks suspend for his libertas wifi, because SDIO has a protocol
where the suspend method can return -ENOSYS and this means "There is
no point in suspending, just turn me off".  Moreover, the suspend
methods provided by SDIO drivers are not supposed to be called by
the PM core or bus-level suspend routines (which aren't presend for
SDIO).  Instead, when the SDIO core gets to suspend the device's
ancestor, it calls the device driver's suspend function, catches the
ENOSYS, and turns the device off.

The commit above breaks the SDIO core's assumption that the device
drivers' callbacks won't be executed if it doesn't provide any
bus-level callbacks.  If fact, however, this assumption has never
been really satisfied, because device class or device type suspend
might very well use the driver's callback even without that commit.

The simplest way to address this problem is to make the SDIO core
tell the PM core to ignore driver callbacks, for example by providing
no-operation suspend/resume callbacks at the bus level for it,
which is implemented by this change.

Reported-and-tested-by: Neil Brown <neilb@suse.de>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: Chris Ball <cjb@laptop.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/mmc/core/sdio_bus.c |   12 +++++++++---
 1 file changed, 9 insertions(+), 3 deletions(-)

--- a/drivers/mmc/core/sdio_bus.c
+++ b/drivers/mmc/core/sdio_bus.c
@@ -192,9 +192,15 @@ static int sdio_bus_remove(struct device
 	return ret;
 }
 
-#ifdef CONFIG_PM_RUNTIME
+#ifdef CONFIG_PM
+
+static int pm_no_operation(struct device *dev)
+{
+	return 0;
+}
 
 static const struct dev_pm_ops sdio_bus_pm_ops = {
+	SET_SYSTEM_SLEEP_PM_OPS(pm_no_operation, pm_no_operation)
 	SET_RUNTIME_PM_OPS(
 		pm_generic_runtime_suspend,
 		pm_generic_runtime_resume,
@@ -204,11 +210,11 @@ static const struct dev_pm_ops sdio_bus_
 
 #define SDIO_PM_OPS_PTR	(&sdio_bus_pm_ops)
 
-#else /* !CONFIG_PM_RUNTIME */
+#else /* !CONFIG_PM */
 
 #define SDIO_PM_OPS_PTR	NULL
 
-#endif /* !CONFIG_PM_RUNTIME */
+#endif /* !CONFIG_PM */
 
 static struct bus_type sdio_bus_type = {
 	.name		= "sdio",

[ 55/78] mmc: sdhci-dove: Fix compile error by including module.h

[Greg KH]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 729 bytes --]

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

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

From: Alf Høgemark <alf@i100.no>

commit 8c2fc8e413ecc2c96b696e28d4eb1bc6cee8dc84 upstream.

This patch fixes a compile error in drivers/mmc/host/sdhci-dove.c
by including the linux/module.h file.

Signed-off-by: Alf Høgemark <alf@i100.no>
Signed-off-by: Chris Ball <cjb@laptop.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/mmc/host/sdhci-dove.c |    1 +
 1 file changed, 1 insertion(+)

--- a/drivers/mmc/host/sdhci-dove.c
+++ b/drivers/mmc/host/sdhci-dove.c
@@ -20,6 +20,7 @@
  */
 
 #include <linux/io.h>
+#include <linux/module.h>
 #include <linux/mmc/host.h>
 
 #include "sdhci-pltfm.h"

[ 56/78] mmc: atmel-mci: correct data timeout computation

[Greg KH]

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

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

From: Ludovic Desroches <ludovic.desroches@atmel.com>

commit 66292ad92c6d3f2f1c137a1c826b331ca8595dfd upstream.

The HSMCI operates at a rate of up to Master Clock divided by two.
Moreover previous calculation can cause overflows and so wrong
timeouts.

Signed-off-by: Ludovic Desroches <ludovic.desroches@atmel.com>
Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Signed-off-by: Chris Ball <cjb@laptop.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/mmc/host/atmel-mci.c |    9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

--- a/drivers/mmc/host/atmel-mci.c
+++ b/drivers/mmc/host/atmel-mci.c
@@ -480,7 +480,14 @@ err:
 static inline unsigned int atmci_ns_to_clocks(struct atmel_mci *host,
 					unsigned int ns)
 {
-	return (ns * (host->bus_hz / 1000000) + 999) / 1000;
+	/*
+	 * It is easier here to use us instead of ns for the timeout,
+	 * it prevents from overflows during calculation.
+	 */
+	unsigned int us = DIV_ROUND_UP(ns, 1000);
+
+	/* Maximum clock frequency is host->bus_hz/2 */
+	return us * (DIV_ROUND_UP(host->bus_hz, 2000000));
 }
 
 static void atmci_set_timeout(struct atmel_mci *host,

[ 57/78] tcm_fc: Add abort flag for gracefully handling exchange timeout

[Greg KH]

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

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

From: Mark Rustad <mark.d.rustad@intel.com>

commit e1c4038282c7586c3544542b37872c434669d3ac upstream.

Add abort flag and use it to terminate processing when an exchange
is timed out or is reset. The abort flag is used in place of the
transport_generic_free_cmd function call in the reset and timeout
cases, because calling that function in that context would free
memory that was in use. The aborted flag allows the lifetime to
be managed in a more normal way, while truncating the processing.

This change eliminates a source of memory corruption which
manifested in a variety of ugly ways.

(nab: Drop unused struct fc_exch *ep in ft_recv_seq)

Signed-off-by: Mark Rustad <mark.d.rustad@intel.com>
Acked-by: Kiran Patil <Kiran.patil@intel.com>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/target/tcm_fc/tcm_fc.h  |    1 +
 drivers/target/tcm_fc/tfc_cmd.c |   10 ++++++++--
 drivers/target/tcm_fc/tfc_io.c  |    2 ++
 3 files changed, 11 insertions(+), 2 deletions(-)

--- a/drivers/target/tcm_fc/tcm_fc.h
+++ b/drivers/target/tcm_fc/tcm_fc.h
@@ -124,6 +124,7 @@ struct ft_cmd {
 	/* Local sense buffer */
 	unsigned char ft_sense_buffer[TRANSPORT_SENSE_BUFFER];
 	u32 was_ddp_setup:1;		/* Set only if ddp is setup */
+	u32 aborted:1;			/* Set if aborted by reset or timeout */
 	struct scatterlist *sg;		/* Set only if DDP is setup */
 	u32 sg_cnt;			/* No. of item in scatterlist */
 };
--- a/drivers/target/tcm_fc/tfc_cmd.c
+++ b/drivers/target/tcm_fc/tfc_cmd.c
@@ -126,6 +126,8 @@ int ft_queue_status(struct se_cmd *se_cm
 	struct fc_exch *ep;
 	size_t len;
 
+	if (cmd->aborted)
+		return 0;
 	ft_dump_cmd(cmd, __func__);
 	ep = fc_seq_exch(cmd->seq);
 	lport = ep->lp;
@@ -192,6 +194,8 @@ int ft_write_pending(struct se_cmd *se_c
 
 	ft_dump_cmd(cmd, __func__);
 
+	if (cmd->aborted)
+		return 0;
 	ep = fc_seq_exch(cmd->seq);
 	lport = ep->lp;
 	fp = fc_frame_alloc(lport, sizeof(*txrdy));
@@ -262,10 +266,10 @@ static void ft_recv_seq(struct fc_seq *s
 	struct ft_cmd *cmd = arg;
 	struct fc_frame_header *fh;
 
-	if (IS_ERR(fp)) {
+	if (unlikely(IS_ERR(fp))) {
 		/* XXX need to find cmd if queued */
 		cmd->seq = NULL;
-		transport_generic_free_cmd(&cmd->se_cmd, 0);
+		cmd->aborted = true;
 		return;
 	}
 
@@ -447,6 +451,8 @@ int ft_queue_tm_resp(struct se_cmd *se_c
 	struct se_tmr_req *tmr = se_cmd->se_tmr_req;
 	enum fcp_resp_rsp_codes code;
 
+	if (cmd->aborted)
+		return 0;
 	switch (tmr->response) {
 	case TMR_FUNCTION_COMPLETE:
 		code = FCP_TMF_CMPL;
--- a/drivers/target/tcm_fc/tfc_io.c
+++ b/drivers/target/tcm_fc/tfc_io.c
@@ -81,6 +81,8 @@ int ft_queue_data_in(struct se_cmd *se_c
 	void *from;
 	void *to = NULL;
 
+	if (cmd->aborted)
+		return 0;
 	ep = fc_seq_exch(cmd->seq);
 	lport = ep->lp;
 	cmd->seq = lport->tt.seq_start_next(cmd->seq);

[ 58/78] tcm_fc: Do not free tpg structure during wq allocation failure

[Greg KH]

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

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

From: Mark Rustad <mark.d.rustad@intel.com>

commit 06383f10c49f507220594a455c6491ca6f8c94ab upstream.

Avoid freeing a registered tpg structure if an alloc_workqueue call
fails.  This fixes a bug where the failure was leaking memory associated
with se_portal_group setup during the original core_tpg_register() call.

Signed-off-by: Mark Rustad <mark.d.rustad@intel.com>
Acked-by: Kiran Patil <Kiran.patil@intel.com>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/target/tcm_fc/tfc_conf.c |   13 ++++++++-----
 1 file changed, 8 insertions(+), 5 deletions(-)

--- a/drivers/target/tcm_fc/tfc_conf.c
+++ b/drivers/target/tcm_fc/tfc_conf.c
@@ -300,6 +300,7 @@ static struct se_portal_group *ft_add_tp
 {
 	struct ft_lport_acl *lacl;
 	struct ft_tpg *tpg;
+	struct workqueue_struct *wq;
 	unsigned long index;
 	int ret;
 
@@ -321,18 +322,20 @@ static struct se_portal_group *ft_add_tp
 	tpg->lport_acl = lacl;
 	INIT_LIST_HEAD(&tpg->lun_list);
 
-	ret = core_tpg_register(&ft_configfs->tf_ops, wwn, &tpg->se_tpg,
-				tpg, TRANSPORT_TPG_TYPE_NORMAL);
-	if (ret < 0) {
+	wq = alloc_workqueue("tcm_fc", 0, 1);
+	if (!wq) {
 		kfree(tpg);
 		return NULL;
 	}
 
-	tpg->workqueue = alloc_workqueue("tcm_fc", 0, 1);
-	if (!tpg->workqueue) {
+	ret = core_tpg_register(&ft_configfs->tf_ops, wwn, &tpg->se_tpg,
+				tpg, TRANSPORT_TPG_TYPE_NORMAL);
+	if (ret < 0) {
+		destroy_workqueue(wq);
 		kfree(tpg);
 		return NULL;
 	}
+	tpg->workqueue = wq;
 
 	mutex_lock(&ft_lport_lock);
 	list_add_tail(&tpg->list, &lacl->tpg_list);

[ 59/78] sysctl: fix write access to dmesg_restrict/kptr_restrict

[Greg KH]

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

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

From: Kees Cook <keescook@chromium.org>

commit 620f6e8e855d6d447688a5f67a4e176944a084e8 upstream.

Commit bfdc0b4 adds code to restrict access to dmesg_restrict,
however, it incorrectly alters kptr_restrict rather than
dmesg_restrict.

The original patch from Richard Weinberger
(https://lkml.org/lkml/2011/3/14/362) alters dmesg_restrict as
expected, and so the patch seems to have been misapplied.

This adds the CAP_SYS_ADMIN check to both dmesg_restrict and
kptr_restrict, since both are sensitive.

Reported-by: Phillip Lougher <plougher@redhat.com>
Signed-off-by: Kees Cook <keescook@chromium.org>
Acked-by: Serge Hallyn <serge.hallyn@canonical.com>
Acked-by: Richard Weinberger <richard@nod.at>
Signed-off-by: James Morris <james.l.morris@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 kernel/sysctl.c |    8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

--- a/kernel/sysctl.c
+++ b/kernel/sysctl.c
@@ -166,7 +166,7 @@ static int proc_taint(struct ctl_table *
 #endif
 
 #ifdef CONFIG_PRINTK
-static int proc_dmesg_restrict(struct ctl_table *table, int write,
+static int proc_dointvec_minmax_sysadmin(struct ctl_table *table, int write,
 				void __user *buffer, size_t *lenp, loff_t *ppos);
 #endif
 
@@ -713,7 +713,7 @@ static struct ctl_table kern_table[] = {
 		.data		= &dmesg_restrict,
 		.maxlen		= sizeof(int),
 		.mode		= 0644,
-		.proc_handler	= proc_dointvec_minmax,
+		.proc_handler	= proc_dointvec_minmax_sysadmin,
 		.extra1		= &zero,
 		.extra2		= &one,
 	},
@@ -722,7 +722,7 @@ static struct ctl_table kern_table[] = {
 		.data		= &kptr_restrict,
 		.maxlen		= sizeof(int),
 		.mode		= 0644,
-		.proc_handler	= proc_dmesg_restrict,
+		.proc_handler	= proc_dointvec_minmax_sysadmin,
 		.extra1		= &zero,
 		.extra2		= &two,
 	},
@@ -2431,7 +2431,7 @@ static int proc_taint(struct ctl_table *
 }
 
 #ifdef CONFIG_PRINTK
-static int proc_dmesg_restrict(struct ctl_table *table, int write,
+static int proc_dointvec_minmax_sysadmin(struct ctl_table *table, int write,
 				void __user *buffer, size_t *lenp, loff_t *ppos)
 {
 	if (write && !capable(CAP_SYS_ADMIN))

[ 60/78] regmap: prevent division by zero in rbtree_show

[Greg KH]

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

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

From: Stephen Warren <swarren@nvidia.com>

commit c04c1b9ee8f30c7a3a25e20e406247003f634ebe upstream.

If there are no nodes in the cache, nodes will be 0, so calculating
"registers / nodes" will cause division by zero.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/base/regmap/regcache-rbtree.c |    8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

--- a/drivers/base/regmap/regcache-rbtree.c
+++ b/drivers/base/regmap/regcache-rbtree.c
@@ -137,6 +137,7 @@ static int rbtree_show(struct seq_file *
 	unsigned int base, top;
 	int nodes = 0;
 	int registers = 0;
+	int average;
 
 	mutex_lock(&map->lock);
 
@@ -151,8 +152,13 @@ static int rbtree_show(struct seq_file *
 		registers += top - base + 1;
 	}
 
+	if (nodes)
+		average = registers / nodes;
+	else
+		average = 0;
+
 	seq_printf(s, "%d nodes, %d registers, average %d registers\n",
-		   nodes, registers, registers / nodes);
+		   nodes, registers, average);
 
 	mutex_unlock(&map->lock);
 

[ 61/78] modpost: Fix modpost license checking of vmlinux.o

[Greg KH]

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

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

From: Frank Rowand <frank.rowand@am.sony.com>

commit 258f742635360175564e9470eb060ff4d4b984e7 upstream.

Commit f02e8a6596b7 ("module: Sort exported symbols") sorts symbols
placing each of them in its own elf section.  This sorting and merging
into the canonical sections are done by the linker.

Unfortunately modpost to generate Module.symvers file parses vmlinux.o
(which is not linked yet) and all modules object files (which aren't
linked yet).  These aren't sanitized by the linker yet.  That breaks
modpost that can't detect license properly for modules.

This patch makes modpost aware of the new exported symbols structure.

[ This above is a slightly corrected version of the explanation of the
  problem, copied from commit 62a2635610db ("modpost: Fix modpost's
  license checking V3").  That commit fixed the problem for module
  object files, but not for vmlinux.o.  This patch fixes modpost for
  vmlinux.o. ]

Signed-off-by: Frank Rowand <frank.rowand@am.sony.com>
Signed-off-by: Alessio Igor Bogani <abogani@kernel.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 scripts/mod/modpost.c |    7 +++++--
 scripts/mod/modpost.h |    1 +
 2 files changed, 6 insertions(+), 2 deletions(-)

--- a/scripts/mod/modpost.c
+++ b/scripts/mod/modpost.c
@@ -132,8 +132,10 @@ static struct module *new_module(char *m
 	/* strip trailing .o */
 	s = strrchr(p, '.');
 	if (s != NULL)
-		if (strcmp(s, ".o") == 0)
+		if (strcmp(s, ".o") == 0) {
 			*s = '\0';
+			mod->is_dot_o = 1;
+		}
 
 	/* add to list */
 	mod->name = p;
@@ -587,7 +589,8 @@ static void handle_modversions(struct mo
 	unsigned int crc;
 	enum export export;
 
-	if (!is_vmlinux(mod->name) && strncmp(symname, "__ksymtab", 9) == 0)
+	if ((!is_vmlinux(mod->name) || mod->is_dot_o) &&
+	    strncmp(symname, "__ksymtab", 9) == 0)
 		export = export_from_secname(info, get_secindex(info, sym));
 	else
 		export = export_from_sec(info, get_secindex(info, sym));
--- a/scripts/mod/modpost.h
+++ b/scripts/mod/modpost.h
@@ -113,6 +113,7 @@ struct module {
 	int has_cleanup;
 	struct buffer dev_table_buf;
 	char	     srcversion[25];
+	int is_dot_o;
 };
 
 struct elf_info {

[ 62/78] mfd: Fix section mismatch warning for da9052-spi

[Greg KH]

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

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

From: Axel Lin <axel.lin@gmail.com>

commit e536b62095301271d974983044a011c29fcb2ea2 upstream.

Add __devinit annotation for da9052_spi_probe to fix below build warning:

WARNING: drivers/built-in.o(.text+0x349b4): Section mismatch in reference from the function da9052_spi_probe() to the function .devinit.text:da9052_device_init()
The function da9052_spi_probe() references
the function __devinit da9052_device_init().
This is often because da9052_spi_probe lacks a __devinit
annotation or the annotation of da9052_device_init is wrong.

Also add __devexit annotation for da9052_spi_remove because we have
__devexit_p around it in the remove callback.

Signed-off-by: Axel Lin <axel.lin@gmail.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/mfd/da9052-spi.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

--- a/drivers/mfd/da9052-spi.c
+++ b/drivers/mfd/da9052-spi.c
@@ -21,7 +21,7 @@
 
 #include <linux/mfd/da9052/da9052.h>
 
-static int da9052_spi_probe(struct spi_device *spi)
+static int __devinit da9052_spi_probe(struct spi_device *spi)
 {
 	int ret;
 	const struct spi_device_id *id = spi_get_device_id(spi);
@@ -61,7 +61,7 @@ err:
 	return ret;
 }
 
-static int da9052_spi_remove(struct spi_device *spi)
+static int __devexit da9052_spi_remove(struct spi_device *spi)
 {
 	struct da9052 *da9052 = dev_get_drvdata(&spi->dev);
 

[ 63/78] android, lowmemorykiller: remove task handoff notifier

[Greg KH]

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

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

From: David Rientjes <rientjes@google.com>

commit 83dbbdbb38666e20a75fad2294cf1df77c52f121 upstream.

The task handoff notifier leaks task_struct since it never gets freed
after the callback returns NOTIFY_OK, which means it is responsible for
doing so.

It turns out the lowmemorykiller actually doesn't need this notifier at
all.  It's used to prevent unnecessary killing by waiting for a thread
to exit as a result of lowmem_shrink(), however, it's possible to do
this in the same way the kernel oom killer works by setting TIF_MEMDIE
and avoid killing if we're still waiting for it to exit.

The kernel oom killer will already automatically set TIF_MEMDIE for
threads that are attempting to allocate memory that have a fatal signal.
The thread selected by lowmem_shrink() will have such a signal after the
lowmemorykiller sends it a SIGKILL, so this won't result in an
unnecessary use of memory reserves for the thread to exit.

This has the added benefit that we don't have to rely on
CONFIG_PROFILING to prevent needlessly killing tasks.

Reported-by: Werner Landgraf <w.landgraf@ru.ru>
Signed-off-by: David Rientjes <rientjes@google.com>
Acked-by: Colin Cross <ccross@android.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/staging/android/lowmemorykiller.c |   47 +++---------------------------
 1 file changed, 6 insertions(+), 41 deletions(-)

--- a/drivers/staging/android/lowmemorykiller.c
+++ b/drivers/staging/android/lowmemorykiller.c
@@ -53,7 +53,6 @@ static size_t lowmem_minfree[6] = {
 };
 static int lowmem_minfree_size = 4;
 
-static struct task_struct *lowmem_deathpending;
 static unsigned long lowmem_deathpending_timeout;
 
 #define lowmem_print(level, x...)			\
@@ -62,24 +61,6 @@ static unsigned long lowmem_deathpending
 			printk(x);			\
 	} while (0)
 
-static int
-task_notify_func(struct notifier_block *self, unsigned long val, void *data);
-
-static struct notifier_block task_nb = {
-	.notifier_call	= task_notify_func,
-};
-
-static int
-task_notify_func(struct notifier_block *self, unsigned long val, void *data)
-{
-	struct task_struct *task = data;
-
-	if (task == lowmem_deathpending)
-		lowmem_deathpending = NULL;
-
-	return NOTIFY_OK;
-}
-
 static int lowmem_shrink(struct shrinker *s, struct shrink_control *sc)
 {
 	struct task_struct *p;
@@ -95,19 +76,6 @@ static int lowmem_shrink(struct shrinker
 	int other_file = global_page_state(NR_FILE_PAGES) -
 						global_page_state(NR_SHMEM);
 
-	/*
-	 * If we already have a death outstanding, then
-	 * bail out right away; indicating to vmscan
-	 * that we have nothing further to offer on
-	 * this pass.
-	 *
-	 * Note: Currently you need CONFIG_PROFILING
-	 * for this to work correctly.
-	 */
-	if (lowmem_deathpending &&
-	    time_before_eq(jiffies, lowmem_deathpending_timeout))
-		return 0;
-
 	if (lowmem_adj_size < array_size)
 		array_size = lowmem_adj_size;
 	if (lowmem_minfree_size < array_size)
@@ -140,6 +108,11 @@ static int lowmem_shrink(struct shrinker
 		struct signal_struct *sig;
 		int oom_adj;
 
+		if (test_tsk_thread_flag(p, TIF_MEMDIE) &&
+		    time_before_eq(jiffies, lowmem_deathpending_timeout)) {
+			read_unlock(&tasklist_lock);
+			return 0;
+		}
 		task_lock(p);
 		mm = p->mm;
 		sig = p->signal;
@@ -173,15 +146,9 @@ static int lowmem_shrink(struct shrinker
 		lowmem_print(1, "send sigkill to %d (%s), adj %d, size %d\n",
 			     selected->pid, selected->comm,
 			     selected_oom_adj, selected_tasksize);
-		/*
-		 * If CONFIG_PROFILING is off, then we don't want to stall
-		 * the killer by setting lowmem_deathpending.
-		 */
-#ifdef CONFIG_PROFILING
-		lowmem_deathpending = selected;
 		lowmem_deathpending_timeout = jiffies + HZ;
-#endif
 		force_sig(SIGKILL, selected);
+		set_tsk_thread_flag(selected, TIF_MEMDIE);
 		rem -= selected_tasksize;
 	}
 	lowmem_print(4, "lowmem_shrink %lu, %x, return %d\n",
@@ -197,7 +164,6 @@ static struct shrinker lowmem_shrinker =
 
 static int __init lowmem_init(void)
 {
-	task_handoff_register(&task_nb);
 	register_shrinker(&lowmem_shrinker);
 	return 0;
 }
@@ -205,7 +171,6 @@ static int __init lowmem_init(void)
 static void __exit lowmem_exit(void)
 {
 	unregister_shrinker(&lowmem_shrinker);
-	task_handoff_unregister(&task_nb);
 }
 
 module_param_named(cost, lowmem_shrinker.seeks, int, S_IRUGO | S_IWUSR);

[ 64/78] TOMOYO: Fix mount flags checking order.

[Greg KH]

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

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

From: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>

commit df91e49477a9be15921cb2854e1d12a3bdb5e425 upstream.

Userspace can pass in arbitrary combinations of MS_* flags to mount().

If both MS_BIND and one of MS_SHARED/MS_PRIVATE/MS_SLAVE/MS_UNBINDABLE are
passed, device name which should be checked for MS_BIND was not checked because
MS_SHARED/MS_PRIVATE/MS_SLAVE/MS_UNBINDABLE had higher priority than MS_BIND.

If both one of MS_BIND/MS_MOVE and MS_REMOUNT are passed, device name which
should not be checked for MS_REMOUNT was checked because MS_BIND/MS_MOVE had
higher priority than MS_REMOUNT.

Fix these bugs by changing priority to MS_REMOUNT -> MS_BIND ->
MS_SHARED/MS_PRIVATE/MS_SLAVE/MS_UNBINDABLE -> MS_MOVE as with do_mount() does.

Also, unconditionally return -EINVAL if more than one of
MS_SHARED/MS_PRIVATE/MS_SLAVE/MS_UNBINDABLE is passed so that TOMOYO will not
generate inaccurate audit logs, for commit 7a2e8a8f "VFS: Sanity check mount
flags passed to change_mnt_propagation()" clarified that these flags must be
exclusively passed.

Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Signed-off-by: James Morris <james.l.morris@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 security/tomoyo/mount.c |   38 ++++++++++++++++++++------------------
 1 file changed, 20 insertions(+), 18 deletions(-)

--- a/security/tomoyo/mount.c
+++ b/security/tomoyo/mount.c
@@ -199,30 +199,32 @@ int tomoyo_mount_permission(char *dev_na
 	if (flags & MS_REMOUNT) {
 		type = tomoyo_mounts[TOMOYO_MOUNT_REMOUNT];
 		flags &= ~MS_REMOUNT;
-	}
-	if (flags & MS_MOVE) {
-		type = tomoyo_mounts[TOMOYO_MOUNT_MOVE];
-		flags &= ~MS_MOVE;
-	}
-	if (flags & MS_BIND) {
+	} else if (flags & MS_BIND) {
 		type = tomoyo_mounts[TOMOYO_MOUNT_BIND];
 		flags &= ~MS_BIND;
-	}
-	if (flags & MS_UNBINDABLE) {
-		type = tomoyo_mounts[TOMOYO_MOUNT_MAKE_UNBINDABLE];
-		flags &= ~MS_UNBINDABLE;
-	}
-	if (flags & MS_PRIVATE) {
+	} else if (flags & MS_SHARED) {
+		if (flags & (MS_PRIVATE | MS_SLAVE | MS_UNBINDABLE))
+			return -EINVAL;
+		type = tomoyo_mounts[TOMOYO_MOUNT_MAKE_SHARED];
+		flags &= ~MS_SHARED;
+	} else if (flags & MS_PRIVATE) {
+		if (flags & (MS_SHARED | MS_SLAVE | MS_UNBINDABLE))
+			return -EINVAL;
 		type = tomoyo_mounts[TOMOYO_MOUNT_MAKE_PRIVATE];
 		flags &= ~MS_PRIVATE;
-	}
-	if (flags & MS_SLAVE) {
+	} else if (flags & MS_SLAVE) {
+		if (flags & (MS_SHARED | MS_PRIVATE | MS_UNBINDABLE))
+			return -EINVAL;
 		type = tomoyo_mounts[TOMOYO_MOUNT_MAKE_SLAVE];
 		flags &= ~MS_SLAVE;
-	}
-	if (flags & MS_SHARED) {
-		type = tomoyo_mounts[TOMOYO_MOUNT_MAKE_SHARED];
-		flags &= ~MS_SHARED;
+	} else if (flags & MS_UNBINDABLE) {
+		if (flags & (MS_SHARED | MS_PRIVATE | MS_SLAVE))
+			return -EINVAL;
+		type = tomoyo_mounts[TOMOYO_MOUNT_MAKE_UNBINDABLE];
+		flags &= ~MS_UNBINDABLE;
+	} else if (flags & MS_MOVE) {
+		type = tomoyo_mounts[TOMOYO_MOUNT_MOVE];
+		flags &= ~MS_MOVE;
 	}
 	if (!type)
 		type = "<NULL>";

[ 65/78] iwlegacy: do not nulify il->vif on reset

[Greg KH]

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

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

From: Stanislaw Gruszka <sgruszka@redhat.com>

commit 883a649b737cdbe3ede7e50f3f939fd706ed5c4e upstream.

This il->vif is dereferenced in different part of iwlegacy code, so do
not nullify it. This should fix random crashes observed in companion
with microcode errors i.e. crash in il3945_config_ap().

Additionally this should address also
WARNING: at drivers/net/wireless/iwlegacy/common.c:4656 il_mac_remove_interface
at least one of the possible reasons of that warning.

Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/net/wireless/iwlegacy/3945-mac.c |    1 -
 drivers/net/wireless/iwlegacy/4965-mac.c |    1 -
 drivers/net/wireless/iwlegacy/common.c   |   18 ++++++++++++++++--
 3 files changed, 16 insertions(+), 4 deletions(-)

--- a/drivers/net/wireless/iwlegacy/3945-mac.c
+++ b/drivers/net/wireless/iwlegacy/3945-mac.c
@@ -2684,7 +2684,6 @@ il3945_bg_restart(struct work_struct *da
 
 	if (test_and_clear_bit(S_FW_ERROR, &il->status)) {
 		mutex_lock(&il->mutex);
-		il->ctx.vif = NULL;
 		il->is_open = 0;
 		mutex_unlock(&il->mutex);
 		il3945_down(il);
--- a/drivers/net/wireless/iwlegacy/4965-mac.c
+++ b/drivers/net/wireless/iwlegacy/4965-mac.c
@@ -5381,7 +5381,6 @@ il4965_bg_restart(struct work_struct *da
 
 	if (test_and_clear_bit(S_FW_ERROR, &il->status)) {
 		mutex_lock(&il->mutex);
-		il->ctx.vif = NULL;
 		il->is_open = 0;
 
 		__il4965_down(il);
--- a/drivers/net/wireless/iwlegacy/common.c
+++ b/drivers/net/wireless/iwlegacy/common.c
@@ -4575,6 +4575,7 @@ il_mac_add_interface(struct ieee80211_hw
 	struct il_priv *il = hw->priv;
 	struct il_vif_priv *vif_priv = (void *)vif->drv_priv;
 	int err;
+	bool reset;
 	u32 modes;
 
 	D_MAC80211("enter: type %d, addr %pM\n", vif->type, vif->addr);
@@ -4594,6 +4595,16 @@ il_mac_add_interface(struct ieee80211_hw
 		goto out;
 	}
 
+	/*
+	 * We do not support multiple virtual interfaces, but on hardware reset
+	 * we have to add the same interface again.
+	 */
+	reset = (il->ctx.vif == vif);
+	if (il->ctx.vif && !reset) {
+		err = -EOPNOTSUPP;
+		goto out;
+	}
+
 	modes = il->ctx.interface_modes | il->ctx.exclusive_interface_modes;
 	if (!(modes & BIT(vif->type))) {
 		err = -EOPNOTSUPP;
@@ -4605,8 +4616,11 @@ il_mac_add_interface(struct ieee80211_hw
 
 	err = il_setup_interface(il, &il->ctx);
 	if (err) {
-		il->ctx.vif = NULL;
-		il->iw_mode = NL80211_IFTYPE_STATION;
+		IL_WARN("Fail to set mode %d\n", vif->type);
+		if (!reset) {
+			il->ctx.vif = NULL;
+			il->iw_mode = NL80211_IFTYPE_STATION;
+		}
 	}
 
 out:

[ 66/78] Revert "x86/ioapic: Add register level checks to detect bogus io-apic entries"

[Greg KH]

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

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

This reverts commit a998dc2fa76f496d2944f0602b920d1d10d7467d
[73d63d038ee9f769f5e5b46792d227fe20e442c5 upstream]

It causes problems, so needs to be reverted from 3.2-stable for now.

Reported-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: Jon Dufresne <jon@jondufresne.org>
Cc: Suresh Siddha <suresh.b.siddha@intel.com>
Cc: <yinghai@kernel.org>
Cc: Josh Boyer <jwboyer@redhat.com>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Teck Choon Giam <giamteckchoon@gmail.com>
Cc: Ben Guthro <ben@guthro.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 arch/x86/kernel/apic/io_apic.c |   40 ++++++++--------------------------------
 1 file changed, 8 insertions(+), 32 deletions(-)

--- a/arch/x86/kernel/apic/io_apic.c
+++ b/arch/x86/kernel/apic/io_apic.c
@@ -3967,36 +3967,18 @@ int mp_find_ioapic_pin(int ioapic, u32 g
 static __init int bad_ioapic(unsigned long address)
 {
 	if (nr_ioapics >= MAX_IO_APICS) {
-		pr_warn("WARNING: Max # of I/O APICs (%d) exceeded (found %d), skipping\n",
-			MAX_IO_APICS, nr_ioapics);
+		printk(KERN_WARNING "WARNING: Max # of I/O APICs (%d) exceeded "
+		       "(found %d), skipping\n", MAX_IO_APICS, nr_ioapics);
 		return 1;
 	}
 	if (!address) {
-		pr_warn("WARNING: Bogus (zero) I/O APIC address found in table, skipping!\n");
+		printk(KERN_WARNING "WARNING: Bogus (zero) I/O APIC address"
+		       " found in table, skipping!\n");
 		return 1;
 	}
 	return 0;
 }
 
-static __init int bad_ioapic_register(int idx)
-{
-	union IO_APIC_reg_00 reg_00;
-	union IO_APIC_reg_01 reg_01;
-	union IO_APIC_reg_02 reg_02;
-
-	reg_00.raw = io_apic_read(idx, 0);
-	reg_01.raw = io_apic_read(idx, 1);
-	reg_02.raw = io_apic_read(idx, 2);
-
-	if (reg_00.raw == -1 && reg_01.raw == -1 && reg_02.raw == -1) {
-		pr_warn("I/O APIC 0x%x registers return all ones, skipping!\n",
-			mpc_ioapic_addr(idx));
-		return 1;
-	}
-
-	return 0;
-}
-
 void __init mp_register_ioapic(int id, u32 address, u32 gsi_base)
 {
 	int idx = 0;
@@ -4013,12 +3995,6 @@ void __init mp_register_ioapic(int id, u
 	ioapics[idx].mp_config.apicaddr = address;
 
 	set_fixmap_nocache(FIX_IO_APIC_BASE_0 + idx, address);
-
-	if (bad_ioapic_register(idx)) {
-		clear_fixmap(FIX_IO_APIC_BASE_0 + idx);
-		return;
-	}
-
 	ioapics[idx].mp_config.apicid = io_apic_unique_id(id);
 	ioapics[idx].mp_config.apicver = io_apic_get_version(idx);
 
@@ -4039,10 +4015,10 @@ void __init mp_register_ioapic(int id, u
 	if (gsi_cfg->gsi_end >= gsi_top)
 		gsi_top = gsi_cfg->gsi_end + 1;
 
-	pr_info("IOAPIC[%d]: apic_id %d, version %d, address 0x%x, GSI %d-%d\n",
-		idx, mpc_ioapic_id(idx),
-		mpc_ioapic_ver(idx), mpc_ioapic_addr(idx),
-		gsi_cfg->gsi_base, gsi_cfg->gsi_end);
+	printk(KERN_INFO "IOAPIC[%d]: apic_id %d, version %d, address 0x%x, "
+	       "GSI %d-%d\n", idx, mpc_ioapic_id(idx),
+	       mpc_ioapic_ver(idx), mpc_ioapic_addr(idx),
+	       gsi_cfg->gsi_base, gsi_cfg->gsi_end);
 
 	nr_ioapics++;
 }

[ 67/78] acer-wmi: No wifi rfkill on Sony machines

[Greg KH]

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

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

From: "Lee, Chun-Yi" <joeyli.kernel@gmail.com>

commit 5719b81988f3c24ff694dc3a37e35b35630a3966 upstream.

The wireless rfkill should charged by sony-laptop but not acer-wmi.
So, add Sony's SNY5001 acpi device to blacklist in acer-wmi.

Tested on Sony Vaio

Cc: Carlos Corbacho <carlos@strangeworlds.co.uk>
Cc: Matthew Garrett <mjg@redhat.com>
Cc: Mattia Dongili <malattia@linux.it>
Cc: Dimitris N <ddarlac@gmail.com>
Tested-by: Dimitris N <ddarlac@gmail.com>
Signed-off-by: Lee, Chun-Yi <jlee@suse.com>
Signed-off-by: Matthew Garrett <mjg@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/platform/x86/acer-wmi.c |    1 +
 1 file changed, 1 insertion(+)

--- a/drivers/platform/x86/acer-wmi.c
+++ b/drivers/platform/x86/acer-wmi.c
@@ -692,6 +692,7 @@ static const struct acpi_device_id norfk
 	{ "VPC2004", 0},
 	{ "IBM0068", 0},
 	{ "LEN0068", 0},
+	{ "SNY5001", 0},	/* sony-laptop in charge */
 	{ "", 0},
 };
 

[ 68/78] Fix length of buffer copied in __nfs4_get_acl_uncached

[Greg KH]

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

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

From: Sachin Prabhu <sprabhu@redhat.com>

commit 20e0fa98b751facf9a1101edaefbc19c82616a68 upstream.

_copy_from_pages() used to copy data from the temporary buffer to the
user passed buffer is passed the wrong size parameter when copying
data. res.acl_len contains both the bitmap and acl lenghts while
acl_len contains the acl length after adjusting for the bitmap size.

Signed-off-by: Sachin Prabhu <sprabhu@redhat.com>
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
Cc: Josh Boyer <jwboyer@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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

--- a/fs/nfs/nfs4proc.c
+++ b/fs/nfs/nfs4proc.c
@@ -3625,7 +3625,7 @@ static ssize_t __nfs4_get_acl_uncached(s
 		if (acl_len > buflen)
 			goto out_free;
 		_copy_from_pages(buf, pages, res.acl_data_offset,
-				res.acl_len);
+				acl_len);
 	}
 	ret = acl_len;
 out_free:

[ 69/78] sched/x86: Fix overflow in cyc2ns_offset

[Greg KH]

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

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

From: Salman Qazi <sqazi@google.com>

commit 9993bc635d01a6ee7f6b833b4ee65ce7c06350b1 upstream.

When a machine boots up, the TSC generally gets reset.  However,
when kexec is used to boot into a kernel, the TSC value would be
carried over from the previous kernel.  The computation of
cycns_offset in set_cyc2ns_scale is prone to an overflow, if the
machine has been up more than 208 days prior to the kexec.  The
overflow happens when we multiply *scale, even though there is
enough room to store the final answer.

We fix this issue by decomposing tsc_now into the quotient and
remainder of division by CYC2NS_SCALE_FACTOR and then performing
the multiplication separately on the two components.

Refactor code to share the calculation with the previous
fix in __cycles_2_ns().

Signed-off-by: Salman Qazi <sqazi@google.com>
Acked-by: John Stultz <john.stultz@linaro.org>
Acked-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Paul Turner <pjt@google.com>
Cc: john stultz <johnstul@us.ibm.com>
Link: http://lkml.kernel.org/r/20120310004027.19291.88460.stgit@dungbeetle.mtv.corp.google.com
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Cc: Mike Galbraith <efault@gmx.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 arch/x86/include/asm/timer.h |    8 ++------
 arch/x86/kernel/tsc.c        |    3 ++-
 include/linux/kernel.h       |   13 +++++++++++++
 3 files changed, 17 insertions(+), 7 deletions(-)

--- a/arch/x86/include/asm/timer.h
+++ b/arch/x86/include/asm/timer.h
@@ -57,14 +57,10 @@ DECLARE_PER_CPU(unsigned long long, cyc2
 
 static inline unsigned long long __cycles_2_ns(unsigned long long cyc)
 {
-	unsigned long long quot;
-	unsigned long long rem;
 	int cpu = smp_processor_id();
 	unsigned long long ns = per_cpu(cyc2ns_offset, cpu);
-	quot = (cyc >> CYC2NS_SCALE_FACTOR);
-	rem = cyc & ((1ULL << CYC2NS_SCALE_FACTOR) - 1);
-	ns += quot * per_cpu(cyc2ns, cpu) +
-		((rem * per_cpu(cyc2ns, cpu)) >> CYC2NS_SCALE_FACTOR);
+	ns += mult_frac(cyc, per_cpu(cyc2ns, cpu),
+			(1UL << CYC2NS_SCALE_FACTOR));
 	return ns;
 }
 
--- a/arch/x86/kernel/tsc.c
+++ b/arch/x86/kernel/tsc.c
@@ -620,7 +620,8 @@ static void set_cyc2ns_scale(unsigned lo
 
 	if (cpu_khz) {
 		*scale = (NSEC_PER_MSEC << CYC2NS_SCALE_FACTOR)/cpu_khz;
-		*offset = ns_now - (tsc_now * *scale >> CYC2NS_SCALE_FACTOR);
+		*offset = ns_now - mult_frac(tsc_now, *scale,
+					     (1UL << CYC2NS_SCALE_FACTOR));
 	}
 
 	sched_clock_idle_wakeup_event(0);
--- a/include/linux/kernel.h
+++ b/include/linux/kernel.h
@@ -85,6 +85,19 @@
 }							\
 )
 
+/*
+ * Multiplies an integer by a fraction, while avoiding unnecessary
+ * overflow or loss of precision.
+ */
+#define mult_frac(x, numer, denom)(			\
+{							\
+	typeof(x) quot = (x) / (denom);			\
+	typeof(x) rem  = (x) % (denom);			\
+	(quot * (numer)) + ((rem * (numer)) / (denom));	\
+}							\
+)
+
+
 #define _RET_IP_		(unsigned long)__builtin_return_address(0)
 #define _THIS_IP_  ({ __label__ __here; __here: (unsigned long)&&__here; })
 

[ 70/78] mfd: Clear twl6030 IRQ status register only once

[Greg KH]

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

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

From: Nishanth Menon <nm@ti.com>

commit 3f8349e6e98ba0455437724589072523865eae5e upstream.

TWL6030 family of PMIC use a shadow interrupt status register
while kernel processes the current interrupt event.
However, any write(0 or 1) to register INT_STS_A, INT_STS_B or
INT_STS_C clears all 3 interrupt status registers.

Since clear of the interrupt is done on 32k clk, depending on I2C
bus speed, we could in-adverently clear the status of a interrupt
status pending on shadow register in the current implementation.
This is due to the fact that multi-byte i2c write operation into
three seperate status register could result in multiple load
and clear of status and result in lost interrupts.

Instead, doing a single byte write to INT_STS_A register with 0x0
will clear all three interrupt status registers without the related
risk.

Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/mfd/twl6030-irq.c |   13 +++++++++++--
 1 file changed, 11 insertions(+), 2 deletions(-)

--- a/drivers/mfd/twl6030-irq.c
+++ b/drivers/mfd/twl6030-irq.c
@@ -185,8 +185,17 @@ static int twl6030_irq_thread(void *data
 			}
 		local_irq_enable();
 		}
-		ret = twl_i2c_write(TWL_MODULE_PIH, sts.bytes,
-				REG_INT_STS_A, 3); /* clear INT_STS_A */
+
+		/*
+		 * NOTE:
+		 * Simulation confirms that documentation is wrong w.r.t the
+		 * interrupt status clear operation. A single *byte* write to
+		 * any one of STS_A to STS_C register results in all three
+		 * STS registers being reset. Since it does not matter which
+		 * value is written, all three registers are cleared on a
+		 * single byte write, so we just use 0x0 to clear.
+		 */
+		ret = twl_i2c_write_u8(TWL_MODULE_PIH, 0x00, REG_INT_STS_A);
 		if (ret)
 			pr_warning("twl6030: I2C error in clearing PIH ISR\n");
 

[ 71/78] USB: Add Motorola Rokr E6 Id to the USBNet driver "zaurus"

[Greg KH]

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

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

From: Guan Xin <guanx.bac@gmail.com>

commit a2daf263107ba3eb6db33931881731fa51c95045 upstream.

Added Vendor/Device Id of Motorola Rokr E6 (22b8:6027) so it can be
recognized by the "zaurus" USBNet driver.
Applies to Linux 3.2.13 and 2.6.39.4.
Signed-off-by: Guan Xin <guanx.bac@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/net/usb/zaurus.c |    5 +++++
 1 file changed, 5 insertions(+)

--- a/drivers/net/usb/zaurus.c
+++ b/drivers/net/usb/zaurus.c
@@ -337,6 +337,11 @@ static const struct usb_device_id	produc
 	.driver_info = ZAURUS_PXA_INFO,
 },
 {
+	/* Motorola Rokr E6 */
+	USB_DEVICE_AND_INTERFACE_INFO(0x22b8, 0x6027, USB_CLASS_COMM,
+			USB_CDC_SUBCLASS_MDLM, USB_CDC_PROTO_NONE),
+	.driver_info = (unsigned long) &bogus_mdlm_info,
+}, {
 	/* Motorola MOTOMAGX phones */
 	USB_DEVICE_AND_INTERFACE_INFO(0x22b8, 0x6425, USB_CLASS_COMM,
 			USB_CDC_SUBCLASS_MDLM, USB_CDC_PROTO_NONE),

[ 72/78] ioat: fix size of completion for Xen

[Greg KH]

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

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

From: Dan Williams <dan.j.williams@intel.com>

commit 275029353953c2117941ade84f02a2303912fad1 upstream.

Starting with v3.2 Jonathan reports that Xen crashes loading the ioatdma
driver.  A debug run shows:

  ioatdma 0000:00:16.4: desc[0]: (0x300cc7000->0x300cc7040) cookie: 0 flags: 0x2 ctl: 0x29 (op: 0 int_en: 1 compl: 1)
  ...
  ioatdma 0000:00:16.4: ioat_get_current_completion: phys_complete: 0xcc7000

...which shows that in this environment GFP_KERNEL memory may be backed
by a 64-bit dma address.  This breaks the driver's assumption that an
unsigned long should be able to contain the physical address for
descriptor memory.  Switch to dma_addr_t which beyond being the right
size, is the true type for the data i.e. an io-virtual address
inidicating the engine's last processed descriptor.

Reported-by: Jonathan Nieder <jrnieder@gmail.com>
Reported-by: William Dauchy <wdauchy@gmail.com>
Tested-by: William Dauchy <wdauchy@gmail.com>
Tested-by: Dave Jiang <dave.jiang@intel.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/dma/ioat/dma.c    |   16 ++++++++--------
 drivers/dma/ioat/dma.h    |    6 +++---
 drivers/dma/ioat/dma_v2.c |    8 ++++----
 drivers/dma/ioat/dma_v3.c |    8 ++++----
 4 files changed, 19 insertions(+), 19 deletions(-)

--- a/drivers/dma/ioat/dma.c
+++ b/drivers/dma/ioat/dma.c
@@ -548,9 +548,9 @@ void ioat_dma_unmap(struct ioat_chan_com
 			   PCI_DMA_TODEVICE, flags, 0);
 }
 
-unsigned long ioat_get_current_completion(struct ioat_chan_common *chan)
+dma_addr_t ioat_get_current_completion(struct ioat_chan_common *chan)
 {
-	unsigned long phys_complete;
+	dma_addr_t phys_complete;
 	u64 completion;
 
 	completion = *chan->completion;
@@ -571,7 +571,7 @@ unsigned long ioat_get_current_completio
 }
 
 bool ioat_cleanup_preamble(struct ioat_chan_common *chan,
-			   unsigned long *phys_complete)
+			   dma_addr_t *phys_complete)
 {
 	*phys_complete = ioat_get_current_completion(chan);
 	if (*phys_complete == chan->last_completion)
@@ -582,14 +582,14 @@ bool ioat_cleanup_preamble(struct ioat_c
 	return true;
 }
 
-static void __cleanup(struct ioat_dma_chan *ioat, unsigned long phys_complete)
+static void __cleanup(struct ioat_dma_chan *ioat, dma_addr_t phys_complete)
 {
 	struct ioat_chan_common *chan = &ioat->base;
 	struct list_head *_desc, *n;
 	struct dma_async_tx_descriptor *tx;
 
-	dev_dbg(to_dev(chan), "%s: phys_complete: %lx\n",
-		 __func__, phys_complete);
+	dev_dbg(to_dev(chan), "%s: phys_complete: %llx\n",
+		 __func__, (unsigned long long) phys_complete);
 	list_for_each_safe(_desc, n, &ioat->used_desc) {
 		struct ioat_desc_sw *desc;
 
@@ -655,7 +655,7 @@ static void __cleanup(struct ioat_dma_ch
 static void ioat1_cleanup(struct ioat_dma_chan *ioat)
 {
 	struct ioat_chan_common *chan = &ioat->base;
-	unsigned long phys_complete;
+	dma_addr_t phys_complete;
 
 	prefetch(chan->completion);
 
@@ -701,7 +701,7 @@ static void ioat1_timer_event(unsigned l
 		mod_timer(&chan->timer, jiffies + COMPLETION_TIMEOUT);
 		spin_unlock_bh(&ioat->desc_lock);
 	} else if (test_bit(IOAT_COMPLETION_PENDING, &chan->state)) {
-		unsigned long phys_complete;
+		dma_addr_t phys_complete;
 
 		spin_lock_bh(&ioat->desc_lock);
 		/* if we haven't made progress and we have already
--- a/drivers/dma/ioat/dma.h
+++ b/drivers/dma/ioat/dma.h
@@ -88,7 +88,7 @@ struct ioatdma_device {
 struct ioat_chan_common {
 	struct dma_chan common;
 	void __iomem *reg_base;
-	unsigned long last_completion;
+	dma_addr_t last_completion;
 	spinlock_t cleanup_lock;
 	dma_cookie_t completed_cookie;
 	unsigned long state;
@@ -333,7 +333,7 @@ int __devinit ioat_dma_self_test(struct
 void __devexit ioat_dma_remove(struct ioatdma_device *device);
 struct dca_provider * __devinit ioat_dca_init(struct pci_dev *pdev,
 					      void __iomem *iobase);
-unsigned long ioat_get_current_completion(struct ioat_chan_common *chan);
+dma_addr_t ioat_get_current_completion(struct ioat_chan_common *chan);
 void ioat_init_channel(struct ioatdma_device *device,
 		       struct ioat_chan_common *chan, int idx);
 enum dma_status ioat_dma_tx_status(struct dma_chan *c, dma_cookie_t cookie,
@@ -341,7 +341,7 @@ enum dma_status ioat_dma_tx_status(struc
 void ioat_dma_unmap(struct ioat_chan_common *chan, enum dma_ctrl_flags flags,
 		    size_t len, struct ioat_dma_descriptor *hw);
 bool ioat_cleanup_preamble(struct ioat_chan_common *chan,
-			   unsigned long *phys_complete);
+			   dma_addr_t *phys_complete);
 void ioat_kobject_add(struct ioatdma_device *device, struct kobj_type *type);
 void ioat_kobject_del(struct ioatdma_device *device);
 extern const struct sysfs_ops ioat_sysfs_ops;
--- a/drivers/dma/ioat/dma_v2.c
+++ b/drivers/dma/ioat/dma_v2.c
@@ -126,7 +126,7 @@ static void ioat2_start_null_desc(struct
 	spin_unlock_bh(&ioat->prep_lock);
 }
 
-static void __cleanup(struct ioat2_dma_chan *ioat, unsigned long phys_complete)
+static void __cleanup(struct ioat2_dma_chan *ioat, dma_addr_t phys_complete)
 {
 	struct ioat_chan_common *chan = &ioat->base;
 	struct dma_async_tx_descriptor *tx;
@@ -178,7 +178,7 @@ static void __cleanup(struct ioat2_dma_c
 static void ioat2_cleanup(struct ioat2_dma_chan *ioat)
 {
 	struct ioat_chan_common *chan = &ioat->base;
-	unsigned long phys_complete;
+	dma_addr_t phys_complete;
 
 	spin_lock_bh(&chan->cleanup_lock);
 	if (ioat_cleanup_preamble(chan, &phys_complete))
@@ -259,7 +259,7 @@ int ioat2_reset_sync(struct ioat_chan_co
 static void ioat2_restart_channel(struct ioat2_dma_chan *ioat)
 {
 	struct ioat_chan_common *chan = &ioat->base;
-	unsigned long phys_complete;
+	dma_addr_t phys_complete;
 
 	ioat2_quiesce(chan, 0);
 	if (ioat_cleanup_preamble(chan, &phys_complete))
@@ -274,7 +274,7 @@ void ioat2_timer_event(unsigned long dat
 	struct ioat_chan_common *chan = &ioat->base;
 
 	if (test_bit(IOAT_COMPLETION_PENDING, &chan->state)) {
-		unsigned long phys_complete;
+		dma_addr_t phys_complete;
 		u64 status;
 
 		status = ioat_chansts(chan);
--- a/drivers/dma/ioat/dma_v3.c
+++ b/drivers/dma/ioat/dma_v3.c
@@ -256,7 +256,7 @@ static bool desc_has_ext(struct ioat_rin
  * The difference from the dma_v2.c __cleanup() is that this routine
  * handles extended descriptors and dma-unmapping raid operations.
  */
-static void __cleanup(struct ioat2_dma_chan *ioat, unsigned long phys_complete)
+static void __cleanup(struct ioat2_dma_chan *ioat, dma_addr_t phys_complete)
 {
 	struct ioat_chan_common *chan = &ioat->base;
 	struct ioat_ring_ent *desc;
@@ -314,7 +314,7 @@ static void __cleanup(struct ioat2_dma_c
 static void ioat3_cleanup(struct ioat2_dma_chan *ioat)
 {
 	struct ioat_chan_common *chan = &ioat->base;
-	unsigned long phys_complete;
+	dma_addr_t phys_complete;
 
 	spin_lock_bh(&chan->cleanup_lock);
 	if (ioat_cleanup_preamble(chan, &phys_complete))
@@ -333,7 +333,7 @@ static void ioat3_cleanup_event(unsigned
 static void ioat3_restart_channel(struct ioat2_dma_chan *ioat)
 {
 	struct ioat_chan_common *chan = &ioat->base;
-	unsigned long phys_complete;
+	dma_addr_t phys_complete;
 
 	ioat2_quiesce(chan, 0);
 	if (ioat_cleanup_preamble(chan, &phys_complete))
@@ -348,7 +348,7 @@ static void ioat3_timer_event(unsigned l
 	struct ioat_chan_common *chan = &ioat->base;
 
 	if (test_bit(IOAT_COMPLETION_PENDING, &chan->state)) {
-		unsigned long phys_complete;
+		dma_addr_t phys_complete;
 		u64 status;
 
 		status = ioat_chansts(chan);

[ 73/78] [media] uvcvideo: Fix race-related crash in uvc_video_clock_update()

[Greg KH]

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

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

From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>

commit ed0ee0ce0a3224dab5caa088a5f8b6df25924276 upstream.

The driver frees the clock samples buffer before stopping the video
buffers queue. If a DQBUF call arrives in-between,
uvc_video_clock_update() will be called with a NULL clock samples
buffer, leading to a crash. This occurs very frequently when using the
webcam with the flash browser plugin.

Move clock initialization/cleanup to uvc_video_enable() in order to free
the clock samples buffer after the queue is stopped. Make sure the clock
is reset at resume time to avoid miscalculating timestamps.

Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/media/video/uvc/uvc_video.c |   50 +++++++++++++++++++++++-------------
 1 file changed, 32 insertions(+), 18 deletions(-)

--- a/drivers/media/video/uvc/uvc_video.c
+++ b/drivers/media/video/uvc/uvc_video.c
@@ -468,22 +468,30 @@ uvc_video_clock_decode(struct uvc_stream
 	spin_unlock_irqrestore(&stream->clock.lock, flags);
 }
 
-static int uvc_video_clock_init(struct uvc_streaming *stream)
+static void uvc_video_clock_reset(struct uvc_streaming *stream)
 {
 	struct uvc_clock *clock = &stream->clock;
 
-	spin_lock_init(&clock->lock);
 	clock->head = 0;
 	clock->count = 0;
-	clock->size = 32;
 	clock->last_sof = -1;
 	clock->sof_offset = -1;
+}
+
+static int uvc_video_clock_init(struct uvc_streaming *stream)
+{
+	struct uvc_clock *clock = &stream->clock;
+
+	spin_lock_init(&clock->lock);
+	clock->size = 32;
 
 	clock->samples = kmalloc(clock->size * sizeof(*clock->samples),
 				 GFP_KERNEL);
 	if (clock->samples == NULL)
 		return -ENOMEM;
 
+	uvc_video_clock_reset(stream);
+
 	return 0;
 }
 
@@ -1424,8 +1432,6 @@ static void uvc_uninit_video(struct uvc_
 
 	if (free_buffers)
 		uvc_free_urb_buffers(stream);
-
-	uvc_video_clock_cleanup(stream);
 }
 
 /*
@@ -1555,10 +1561,6 @@ static int uvc_init_video(struct uvc_str
 
 	uvc_video_stats_start(stream);
 
-	ret = uvc_video_clock_init(stream);
-	if (ret < 0)
-		return ret;
-
 	if (intf->num_altsetting > 1) {
 		struct usb_host_endpoint *best_ep = NULL;
 		unsigned int best_psize = 3 * 1024;
@@ -1683,6 +1685,8 @@ int uvc_video_resume(struct uvc_streamin
 
 	stream->frozen = 0;
 
+	uvc_video_clock_reset(stream);
+
 	ret = uvc_commit_video(stream, &stream->ctrl);
 	if (ret < 0) {
 		uvc_queue_enable(&stream->queue, 0);
@@ -1819,25 +1823,35 @@ int uvc_video_enable(struct uvc_streamin
 		uvc_uninit_video(stream, 1);
 		usb_set_interface(stream->dev->udev, stream->intfnum, 0);
 		uvc_queue_enable(&stream->queue, 0);
+		uvc_video_clock_cleanup(stream);
 		return 0;
 	}
 
-	ret = uvc_queue_enable(&stream->queue, 1);
+	ret = uvc_video_clock_init(stream);
 	if (ret < 0)
 		return ret;
 
+	ret = uvc_queue_enable(&stream->queue, 1);
+	if (ret < 0)
+		goto error_queue;
+
 	/* Commit the streaming parameters. */
 	ret = uvc_commit_video(stream, &stream->ctrl);
-	if (ret < 0) {
-		uvc_queue_enable(&stream->queue, 0);
-		return ret;
-	}
+	if (ret < 0)
+		goto error_commit;
 
 	ret = uvc_init_video(stream, GFP_KERNEL);
-	if (ret < 0) {
-		usb_set_interface(stream->dev->udev, stream->intfnum, 0);
-		uvc_queue_enable(&stream->queue, 0);
-	}
+	if (ret < 0)
+		goto error_video;
+
+	return 0;
+
+error_video:
+	usb_set_interface(stream->dev->udev, stream->intfnum, 0);
+error_commit:
+	uvc_queue_enable(&stream->queue, 0);
+error_queue:
+	uvc_video_clock_cleanup(stream);
 
 	return ret;
 }

[ 74/78] ASoC: ak4642: fixup: mute needs +1 step

[Greg KH]

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

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

From: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>

commit 1f99e44cf059d2ed43c5a0724fa738b83800f725 upstream.

ak4642 out_tlv is +12.0dB to -115.0 dB, and it supports mute.
But current settings didn't care +1 step for mute.
This patch adds it

Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 sound/soc/codecs/ak4642.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/sound/soc/codecs/ak4642.c
+++ b/sound/soc/codecs/ak4642.c
@@ -140,7 +140,7 @@
  * min : 0xFE : -115.0 dB
  * mute: 0xFF
  */
-static const DECLARE_TLV_DB_SCALE(out_tlv, -11500, 50, 1);
+static const DECLARE_TLV_DB_SCALE(out_tlv, -11550, 50, 1);
 
 static const struct snd_kcontrol_new ak4642_snd_controls[] = {
 

[ 75/78] ASoC: tegra: fix i2s compilation when !CONFIG_DEBUG_FS

[Greg KH]

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

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

From: Stephen Warren <swarren@nvidia.com>

commit 8abe05c6eb358967f16bce8a02c88d57c82cfbd6 upstream.

Commit d4a2eca "ASoC: Tegra I2S: Remove dependency on pdev->id" changed
the prototype of tegra_i2s_debug_add, but didn't update the dummy inline
used when !CONFIG_DEBUG_FS. Fix that.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 sound/soc/tegra/tegra_i2s.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/sound/soc/tegra/tegra_i2s.c
+++ b/sound/soc/tegra/tegra_i2s.c
@@ -112,7 +112,7 @@ static void tegra_i2s_debug_remove(struc
 		debugfs_remove(i2s->debug);
 }
 #else
-static inline void tegra_i2s_debug_add(struct tegra_i2s *i2s, int id)
+static inline void tegra_i2s_debug_add(struct tegra_i2s *i2s)
 {
 }
 

[ 76/78] media: dvb_frontend: regression fix: userspace ABI broken for xine

[Greg KH]

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

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

From: Chris Rankin <rankincj@yahoo.com>

commit 556a0442e08a8bc8541587a349cbf26ed14ec6de upstream.

The commit e399ce77e6e has broken the DVB ABI for xine:

The problem is that xine is expecting every event after a successful
FE_SET_FRONTEND ioctl to have a non-zero frequency parameter, regardless
of whether the tuning process has LOCKed yet. What used to happen is
that the events inherited the initial tuning parameters from the
FE_SET_FRONTEND call. However, the fepriv->parameters_out struct is now
not initialised until the status contains the FE_HAS_LOCK bit.

You might argue that this behaviour is intentional, except that if an
application other than xine uses the DVB adapter and manages to set the
parameters_out.frequency field to something other than zero, then xine
no longer has any problems until either the adapter is replugged or the
kernel modules reloaded. This can only mean that the
fepriv->parameters_out struct still contains the (stale) tuning
information from the previous application.

Signed-off-by: Chris Rankin <rankincj@yahoo.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/media/dvb/dvb-core/dvb_frontend.c |   10 ++++++++++
 1 file changed, 10 insertions(+)

--- a/drivers/media/dvb/dvb-core/dvb_frontend.c
+++ b/drivers/media/dvb/dvb-core/dvb_frontend.c
@@ -143,6 +143,8 @@ struct dvb_frontend_private {
 static void dvb_frontend_wakeup(struct dvb_frontend *fe);
 static int dtv_get_frontend(struct dvb_frontend *fe,
 			    struct dvb_frontend_parameters *p_out);
+static int dtv_property_legacy_params_sync(struct dvb_frontend *fe,
+					   struct dvb_frontend_parameters *p);
 
 static bool has_get_frontend(struct dvb_frontend *fe)
 {
@@ -695,6 +697,7 @@ restart:
 					fepriv->algo_status |= DVBFE_ALGO_SEARCH_AGAIN;
 					fepriv->delay = HZ / 2;
 				}
+				dtv_property_legacy_params_sync(fe, &fepriv->parameters_out);
 				fe->ops.read_status(fe, &s);
 				if (s != fepriv->status) {
 					dvb_frontend_add_event(fe, s); /* update event list */
@@ -1831,6 +1834,13 @@ static int dtv_set_frontend(struct dvb_f
 		return -EINVAL;
 
 	/*
+	 * Initialize output parameters to match the values given by
+	 * the user. FE_SET_FRONTEND triggers an initial frontend event
+	 * with status = 0, which copies output parameters to userspace.
+	 */
+	dtv_property_legacy_params_sync(fe, &fepriv->parameters_out);
+
+	/*
 	 * Be sure that the bandwidth will be filled for all
 	 * non-satellite systems, as tuners need to know what
 	 * low pass/Nyquist half filter should be applied, in

[ 77/78] media: dvb-core: fix DVBFE_ALGO_HW retune bug

[Greg KH]

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

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

From: Simon Arlott <simon@fire.lp0.eu>

commit 45145b67f5895ff92207cffd74e65460a87920b2 upstream.

Commit 7e07222 breaks DVBFE_ALGO_HW tuning after a retune is requested,
which causes bad tuning on my TBS 6920.

[    0.769091] pci 0000:06:00.0: [14f1:8852] type 0 class 0x000400
[   19.733530] CORE cx23885[0]: subsystem: 6920:8888, board: TurboSight TBS 6920 [card=14,autodetected]
[  762.824912] cx24116_load_firmware: FW version 1.23.86.1

7e0722215a510921cbb73ab4c37477d4dcb91bf8 [media] dvb-core: Don't pass DVBv3 parameters on tune() fops

Although re_tune is set to true when FESTATE_RETUNE occurs, it is never
set back to false which the old code used to do when !FESTATE_RETUNE.

This patch sets re_tune to false if !(state & FESTATE_RETUNE).

$ szap-s2 -a 2 "Channel 5"
reading channels from file '/home/simon/.szap/channels.conf'
zapping to 247 'Channel 5':
delivery DVB-S, modulation QPSK
sat 0, frequency 10964 MHz H, symbolrate 22000000, coderate 5/6, rolloff 0.35
vpid 0x092a, apid 0x092b, sid 0x092d
using '/dev/dvb/adapter2/frontend0' and '/dev/dvb/adapter2/demux0'
status 1f | signal cf40 | snr 0000 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal cf40 | snr eccd | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal cf40 | snr 0000 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal cf40 | snr 0000 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal cf40 | snr eccd | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal cf40 | snr 0000 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal cf40 | snr 0000 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal cf40 | snr eb33 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal cf40 | snr eccd | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal cf40 | snr eccd | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal cf40 | snr 0000 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal cf40 | snr eccd | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal cf40 | snr eccd | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal cf40 | snr 0000 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal cec0 | snr eccd | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal cec0 | snr 0000 | ber 00000000 | unc 00000000 | FE_HAS_LOCK

Signed-off-by: Simon Arlott <simon@fire.lp0.eu>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>

---
 drivers/media/dvb/dvb-core/dvb_frontend.c |    2 ++
 1 file changed, 2 insertions(+)

--- a/drivers/media/dvb/dvb-core/dvb_frontend.c
+++ b/drivers/media/dvb/dvb-core/dvb_frontend.c
@@ -657,6 +657,8 @@ restart:
 					dprintk("%s: Retune requested, FESTATE_RETUNE\n", __func__);
 					re_tune = true;
 					fepriv->state = FESTATE_TUNED;
+				} else {
+					re_tune = false;
 				}
 
 				if (fe->ops.tune)

[ 78/78] cred: copy_process() should clear child->replacement_session_keyring

[Greg KH]

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

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

From: Oleg Nesterov <oleg@redhat.com>

commit 79549c6dfda0603dba9a70a53467ce62d9335c33 upstream.

keyctl_session_to_parent(task) sets ->replacement_session_keyring,
it should be processed and cleared by key_replace_session_keyring().

However, this task can fork before it notices TIF_NOTIFY_RESUME and
the new child gets the bogus ->replacement_session_keyring copied by
dup_task_struct(). This is obviously wrong and, if nothing else, this
leads to put_cred(already_freed_cred).

change copy_creds() to clear this member. If copy_process() fails
before this point the wrong ->replacement_session_keyring doesn't
matter, exit_creds() won't be called.

Signed-off-by: Oleg Nesterov <oleg@redhat.com>
Acked-by: David Howells <dhowells@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 kernel/cred.c |    2 ++
 1 file changed, 2 insertions(+)

--- a/kernel/cred.c
+++ b/kernel/cred.c
@@ -385,6 +385,8 @@ int copy_creds(struct task_struct *p, un
 	struct cred *new;
 	int ret;
 
+	p->replacement_session_keyring = NULL;
+
 	if (
 #ifdef CONFIG_KEYS
 		!p->cred->thread_keyring &&

Re: [ 00/78] 3.3.2-stable review

[Sergio Correia]

SGVsbG8gR3JlZywKCgpPbiBXZWQsIEFwciAxMSwgMjAxMiBhdCA3OjExIFBNLCBHcmVnIEtIIDxn
cmVna2hAbGludXhmb3VuZGF0aW9uLm9yZz4gd3JvdGU6Cj4gVGhpcyBpcyB0aGUgc3RhcnQgb2Yg
dGhlIHN0YWJsZSByZXZpZXcgY3ljbGUgZm9yIHRoZSAzLjMuMiByZWxlYXNlLgo+IFRoZXJlIGFy
ZSA3OCBwYXRjaGVzIGluIHRoaXMgc2VyaWVzLCBhbGwgd2lsbCBiZSBwb3N0ZWQgYXMgYSByZXNw
b25zZQo+IHRvIHRoaXMgb25lLiCgSWYgYW55b25lIGhhcyBhbnkgaXNzdWVzIHdpdGggdGhlc2Ug
YmVpbmcgYXBwbGllZCwgcGxlYXNlCj4gbGV0IG1lIGtub3cuCj4KPiBSZXNwb25zZXMgc2hvdWxk
IGJlIG1hZGUgYnkgRnJpIEFwciAxMyAyMzoxMDoxNiBVVEMgMjAxMi4KPiBBbnl0aGluZyByZWNl
aXZlZCBhZnRlciB0aGF0IHRpbWUgbWlnaHQgYmUgdG9vIGxhdGUuCj4KCmlzIHRoZXJlIGFueSBj
aGFuY2UgZm9yIHRoaXMgb25lIHRvIGJlIGluY2x1ZGVkIGluIHRoaXMgcmV2aWV3IGN5Y2xlPwoK
aHR0cDovL3d3dy5zcGluaWNzLm5ldC9saXN0cy9saW51eC13aXJlbGVzcy9tc2c4Nzk5OS5odG1s
CgpiZXN0IHJlZ2FyZHMsCnNlcmdpbwoKPiBUaGUgd2hvbGUgcGF0Y2ggc2VyaWVzIGNhbiBiZSBm
b3VuZCBpbiBvbmUgcGF0Y2ggYXQ6Cj4goCCgIKAgoGtlcm5lbC5vcmcvcHViL2xpbnV4L2tlcm5l
bC92My4wL3N0YWJsZS1yZXZpZXcvcGF0Y2gtMy4zLjItcmMxLmd6Cj4gYW5kIHRoZSBkaWZmc3Rh
dCBjYW4gYmUgZm91bmQgYmVsb3cuCj4KPiB0aGFua3MsCj4KPiBncmVnIGstaAo+Cj4gLS0tLS0t
LS0tLS0tLQo+IKBNYWtlZmlsZSCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg
IKAgoCB8IKAgoDQgKy0KPiCgYXJjaC9hcm0vbWFjaC1hdDkxL2F0OTFzYW05MjYzX2RldmljZXMu
YyCgIKAgoCCgIKAgfCCgIKAzICstCj4goGFyY2gvYXJtL21hY2gtYXQ5MS9hdDkxc2FtOWc0NV9k
ZXZpY2VzLmMgoCCgIKAgoCCgIHwgoCCgNiArLQo+IKBhcmNoL2FybS9tYWNoLWF0OTEvYm9hcmQt
c2FtOTI2M2VrLmMgoCCgIKAgoCCgIKAgoCB8IKAgoDEgKwo+IKBhcmNoL2FybS9tYWNoLWF0OTEv
Ym9hcmQtc2FtOW0xMGc0NWVrLmMgoCCgIKAgoCCgIKB8IKAgoDEgKwo+IKBhcmNoL202OGsvbWFj
L2NvbmZpZy5jIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCB8IKAgoDMgKwo+IKBhcmNoL3g4
Ni9pbmNsdWRlL2FzbS90aW1lci5oIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCB8IKAgoDggKy0KPiCg
YXJjaC94ODYva2VybmVsL2FwaWMvaW9fYXBpYy5jIKAgoCCgIKAgoCCgIKAgoCCgIKAgfCCgIDQw
ICstLS0tCj4goGFyY2gveDg2L2tlcm5lbC9rZ2RiLmMgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg
oCCgIHwgoCA2MCArKysrKysrKwo+IKBhcmNoL3g4Ni9rZXJuZWwvdHNjLmMgoCCgIKAgoCCgIKAg
oCCgIKAgoCCgIKAgoCCgIKB8IKAgoDMgKy0KPiCgYXJjaC94ODYvbmV0L2JwZl9qaXRfY29tcC5j
IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgfCCgIKAyICstCj4goGRyaXZlcnMvYWNwaS9hY3BpY2Ev
dGJmYWR0LmMgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIHwgoCCgOCArLQo+IKBkcml2ZXJzL2FjcGkv
cHJvY2Vzc29yX3RoZXJtYWwuYyCgIKAgoCCgIKAgoCCgIKAgoCB8IKAgNDUgKysrKystCj4goGRy
aXZlcnMvYmFzZS9maXJtd2FyZV9jbGFzcy5jIKAgoCCgIKAgoCCgIKAgoCCgIKAgoHwgoCA5NiAr
KysrKysrKy0tLS0KPiCgZHJpdmVycy9iYXNlL3Bvd2VyL3J1bnRpbWUuYyCgIKAgoCCgIKAgoCCg
IKAgoCCgIKAgfCCgIKAzICstCj4goGRyaXZlcnMvYmFzZS9yZWdtYXAvcmVnY2FjaGUtcmJ0cmVl
LmMgoCCgIKAgoCCgIKAgoHwgoCCgOCArLQo+IKBkcml2ZXJzL2RtYS9pb2F0L2RtYS5jIKAgoCCg
IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCB8IKAgMTYgKy0KPiCgZHJpdmVycy9kbWEvaW9hdC9kbWEu
aCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgfCCgIKA2ICstCj4goGRyaXZlcnMvZG1hL2lv
YXQvZG1hX3YyLmMgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoHwgoCCgOCArLQo+IKBkcml2ZXJz
L2RtYS9pb2F0L2RtYV92My5jIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKB8IKAgoDggKy0KPiCg
ZHJpdmVycy9ncHUvZHJtL2RybV9mYl9oZWxwZXIuYyCgIKAgoCCgIKAgoCCgIKAgoCCgfCCgIKA4
ICstCj4goGRyaXZlcnMvZ3B1L2RybS9pOTE1L2k5MTVfZHJ2LmMgoCCgIKAgoCCgIKAgoCCgIKAg
oHwgoCCgMiArCj4goGRyaXZlcnMvZ3B1L2RybS9pOTE1L2k5MTVfcmVnLmggoCCgIKAgoCCgIKAg
oCCgIKAgoHwgoCCgMSArCj4goGRyaXZlcnMvZ3B1L2RybS9pOTE1L2ludGVsX2Jpb3MuYyCgIKAg
oCCgIKAgoCCgIKAgoHwgoCAyMyArKy0KPiCgZHJpdmVycy9ncHUvZHJtL2k5MTUvaW50ZWxfZGlz
cGxheS5jIKAgoCCgIKAgoCCgIKAgfCCgIKA2ICsKPiCgZHJpdmVycy9ncHUvZHJtL2k5MTUvaW50
ZWxfbHZkcy5jIKAgoCCgIKAgoCCgIKAgoCCgfCCgIKA4ICsKPiCgZHJpdmVycy9ncHUvZHJtL2k5
MTUvaW50ZWxfc3ByaXRlLmMgoCCgIKAgoCCgIKAgoCCgfCCgIKAzICsKPiCgZHJpdmVycy9ncHUv
ZHJtL3JhZGVvbi9hdG9tLmMgoCCgIKAgoCCgIKAgoCCgIKAgoCCgfCCgIDE1ICstCj4goGRyaXZl
cnMvZ3B1L2RybS9yYWRlb24vYXRvbS5oIKAgoCCgIKAgoCCgIKAgoCCgIKAgoHwgoCCgMSArCj4g
oGRyaXZlcnMvbWVkaWEvZHZiL2R2Yi1jb3JlL2R2Yl9mcm9udGVuZC5jIKAgoCCgIKAgoHwgoCAx
MiArKwo+IKBkcml2ZXJzL21lZGlhL3ZpZGVvL3V2Yy91dmNfdmlkZW8uYyCgIKAgoCCgIKAgoCCg
IKB8IKAgNTAgKysrLS0tCj4goGRyaXZlcnMvbWZkL2RhOTA1Mi1zcGkuYyCgIKAgoCCgIKAgoCCg
IKAgoCCgIKAgoCCgIHwgoCCgNCArLQo+IKBkcml2ZXJzL21mZC90d2w2MDMwLWlycS5jIKAgoCCg
IKAgoCCgIKAgoCCgIKAgoCCgIKB8IKAgMTMgKy0KPiCgZHJpdmVycy9taXNjL2tnZGJ0cy5jIKAg
oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgfCCgMTYwICsrKysrKysrKysrKysrLS0tLS0tCj4g
oGRyaXZlcnMvbW1jL2NvcmUvc2Rpb19idXMuYyCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoHwgoCAx
MiArLQo+IKBkcml2ZXJzL21tYy9ob3N0L2F0bWVsLW1jaS5jIKAgoCCgIKAgoCCgIKAgoCCgIKAg
oCB8IKAgoDkgKy0KPiCgZHJpdmVycy9tbWMvaG9zdC9zZGhjaS1kb3ZlLmMgoCCgIKAgoCCgIKAg
oCCgIKAgoCCgfCCgIKAxICsKPiCgZHJpdmVycy9tdGQvZGV2aWNlcy9ibG9jazJtdGQuYyCgIKAg
oCCgIKAgoCCgIKAgoCCgfCCgIKAxICsKPiCgZHJpdmVycy9tdGQvZGV2aWNlcy9kb2MyMDAwLmMg
oCCgIKAgoCCgIKAgoCCgIKAgoCCgfCCgIKAyICstCj4goGRyaXZlcnMvbXRkL2RldmljZXMvZG9j
MjAwMS5jIKAgoCCgIKAgoCCgIKAgoCCgIKAgoHwgoCCgMiArLQo+IKBkcml2ZXJzL210ZC9kZXZp
Y2VzL2RvYzIwMDFwbHVzLmMgoCCgIKAgoCCgIKAgoCCgIKB8IKAgoDIgKy0KPiCgZHJpdmVycy9t
dGQvZGV2aWNlcy9kb2NnMy5jIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgfCCgIKAyICstCj4goGRy
aXZlcnMvbXRkL2RldmljZXMvbGFydC5jIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIHwgoCCgMSAr
Cj4goGRyaXZlcnMvbXRkL2RldmljZXMvbTI1cDgwLmMgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIHwg
oCCgMSArCj4goGRyaXZlcnMvbXRkL2RldmljZXMvc3N0MjVsLmMgoCCgIKAgoCCgIKAgoCCgIKAg
oCCgIHwgoCCgMSArCj4goGRyaXZlcnMvbXRkL21hcHMvaXhwNHh4LmMgoCCgIKAgoCCgIKAgoCCg
IKAgoCCgIKAgoHwgoCCgNSArLQo+IKBkcml2ZXJzL210ZC9tYXBzL2xhbnRpcS1mbGFzaC5jIKAg
oCCgIKAgoCCgIKAgoCCgIKB8IKAgoDMgKy0KPiCgZHJpdmVycy9tdGQvbmFuZC9ncG1pLW5hbmQv
Z3BtaS1uYW5kLmMgoCCgIKAgoCCgIKAgfCCgIKAyICstCj4goGRyaXZlcnMvbmV0L2V0aGVybmV0
L2Jyb2FkY29tL3RnMy5jIKAgoCCgIKAgoCCgIKAgoHwgoCCgNCArLQo+IKBkcml2ZXJzL25ldC9l
dGhlcm5ldC9mcmVlc2NhbGUvZnNsX3BxX21kaW8uYyCgIKAgoCB8IKAgMTIgKy0KPiCgZHJpdmVy
cy9uZXQvZXRoZXJuZXQvbWFydmVsbC9za3kyLmMgoCCgIKAgoCCgIKAgoCCgfCCgIKA1ICstCj4g
oGRyaXZlcnMvbmV0L2V0aGVybmV0L3ZpYS92aWEtcmhpbmUuYyCgIKAgoCCgIKAgoCCgIHwgoCAx
MiArLQo+IKBkcml2ZXJzL25ldC91c2IvY2RjX2VlbS5jIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg
IKB8IKAgoDEgKwo+IKBkcml2ZXJzL25ldC91c2IvemF1cnVzLmMgoCCgIKAgoCCgIKAgoCCgIKAg
oCCgIKAgoCB8IKAgoDUgKwo+IKBkcml2ZXJzL25ldC93aXJlbGVzcy9hdGgvYXRoOWsvY2FsaWIu
YyCgIKAgoCCgIKAgoCB8IKAgoDUgKy0KPiCgZHJpdmVycy9uZXQvd2lyZWxlc3MvaXdsZWdhY3kv
Mzk0NS1tYWMuYyCgIKAgoCCgIKAgfCCgIKAxIC0KPiCgZHJpdmVycy9uZXQvd2lyZWxlc3MvaXds
ZWdhY3kvNDk2NS1tYWMuYyCgIKAgoCCgIKAgfCCgIKAxIC0KPiCgZHJpdmVycy9uZXQvd2lyZWxl
c3MvaXdsZWdhY3kvY29tbW9uLmMgoCCgIKAgoCCgIKAgfCCgIDE4ICsrLQo+IKBkcml2ZXJzL25l
dC93aXJlbGVzcy9ydGx3aWZpL3J0bDgxOTJjL3BoeV9jb21tb24uYyB8IKAgoDIgKy0KPiCgZHJp
dmVycy9uZXQvd2lyZWxlc3MvcnRsd2lmaS9ydGw4MTkyZGUvcGh5LmMgoCCgIKAgfCCgIKAyICst
Cj4goGRyaXZlcnMvcGxhdGZvcm0veDg2L2FjZXItd21pLmMgoCCgIKAgoCCgIKAgoCCgIKAgoHwg
oCCgMSArCj4goGRyaXZlcnMvcG5wL3BucGFjcGkvY29yZS5jIKAgoCCgIKAgoCCgIKAgoCCgIKAg
oCCgIHwgoCCgNyArLQo+IKBkcml2ZXJzL3N0YWdpbmcvYW5kcm9pZC9sb3dtZW1vcnlraWxsZXIu
YyCgIKAgoCCgIKB8IKAgNDcgKy0tLS0tCj4goGRyaXZlcnMvdGFyZ2V0L3RjbV9mYy90Y21fZmMu
aCCgIKAgoCCgIKAgoCCgIKAgoCCgIHwgoCCgMSArCj4goGRyaXZlcnMvdGFyZ2V0L3RjbV9mYy90
ZmNfY21kLmMgoCCgIKAgoCCgIKAgoCCgIKAgoHwgoCAxMCArLQo+IKBkcml2ZXJzL3RhcmdldC90
Y21fZmMvdGZjX2NvbmYuYyCgIKAgoCCgIKAgoCCgIKAgoCB8IKAgMTMgKy0KPiCgZHJpdmVycy90
YXJnZXQvdGNtX2ZjL3RmY19pby5jIKAgoCCgIKAgoCCgIKAgoCCgIKAgfCCgIKAyICsKPiCgZHJp
dmVycy91c2IvaG9zdC9vaGNpLWF0OTEuYyCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgfCCgIKA0ICst
Cj4goGZzL2NpZnMvZmlsZS5jIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIHwg
oCAxMCArLQo+IKBmcy9sb2Nrcy5jIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg
IKAgoCB8IKAgoDMgKy0KPiCgZnMvbmZzL25mczRwcm9jLmMgoCCgIKAgoCCgIKAgoCCgIKAgoCCg
IKAgoCCgIKAgoCCgfCCgIKAyICstCj4goGluY2x1ZGUvbGludXgvZnMuaCCgIKAgoCCgIKAgoCCg
IKAgoCCgIKAgoCCgIKAgoCCgIHwgoCCgNSArCj4goGluY2x1ZGUvbGludXgva2VybmVsLmggoCCg
IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIHwgoCAxMyArKwo+IKBpbmNsdWRlL2xpbnV4L2tnZGIu
aCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCB8IKAgoDcgKy0KPiCgaW5jbHVkZS9saW51
eC9rbW9kLmggoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgfCCgIDI3ICsrKy0KPiCga2Vy
bmVsL2NyZWQuYyCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgfCCgIKAyICsK
PiCga2VybmVsL2RlYnVnL2RlYnVnX2NvcmUuYyCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgfCCg
IDUzICsrKy0tLS0KPiCga2VybmVsL2lycS9taWdyYXRpb24uYyCgIKAgoCCgIKAgoCCgIKAgoCCg
IKAgoCCgIKAgfCCgIDEwICstCj4goGtlcm5lbC9rbW9kLmMgoCCgIKAgoCCgIKAgoCCgIKAgoCCg
IKAgoCCgIKAgoCCgIKAgoHwgoDExNyArKysrKysrKysrLS0tLQo+IKBrZXJuZWwvcG93ZXIvaGli
ZXJuYXRlLmMgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCB8IKAgMTggKy0tCj4goGtlcm5lbC9w
b3dlci9wcm9jZXNzLmMgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIHwgoCCgOCArCj4goGtl
cm5lbC9wb3dlci9zdXNwZW5kLmMgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIHwgoCCgNyAt
Cj4goGtlcm5lbC9wb3dlci91c2VyLmMgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoHwg
oCAxMCArLQo+IKBrZXJuZWwvc3lzY3RsLmMgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg
oCCgIKB8IKAgoDggKy0KPiCga2VybmVsL3RyYWNlL3RyYWNlLmMgoCCgIKAgoCCgIKAgoCCgIKAg
oCCgIKAgoCCgIKAgfCCgIKA0ICsKPiCga2VybmVsL3RyYWNlL3RyYWNlX2VudHJpZXMuaCCgIKAg
oCCgIKAgoCCgIKAgoCCgIKAgfCCgIDE2ICstCj4goGtlcm5lbC90cmFjZS90cmFjZV9leHBvcnQu
YyCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoHwgoCCgMiArLQo+IKBuZXQvbWFjODAyMTEvYWdnLXJ4
LmMgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKB8IKAgoDMgKy0KPiCgbmV0L3Jvc2Uvcm9z
ZV9kZXYuYyCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgfCCgIKA0ICstCj4goHNjcmlw
dHMvbW9kL21vZHBvc3QuYyCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoHwgoCCgOSArLQo+
IKBzY3JpcHRzL21vZC9tb2Rwb3N0LmggoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKB8IKAg
oDEgKwo+IKBzZWN1cml0eS90b21veW8vbW91bnQuYyCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg
IKB8IKAgMzggKystLS0KPiCgc291bmQvcGNpL2hkYS9wYXRjaF9yZWFsdGVrLmMgoCCgIKAgoCCg
IKAgoCCgIKAgoCCgfCCgIDExICstCj4goHNvdW5kL3NvYy9jb2RlY3MvYWs0NjQyLmMgoCCgIKAg
oCCgIKAgoCCgIKAgoCCgIKAgoHwgoCCgMiArLQo+IKBzb3VuZC9zb2MvY29kZWNzL3dtODk5NC5j
IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKB8IKAgoDIgKy0KPiCgc291bmQvc29jL3RlZ3JhL3Rl
Z3JhX2kycy5jIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgfCCgIKAyICstCj4goDk2IGZpbGVzIGNo
YW5nZWQsIDgxNSBpbnNlcnRpb25zKCspLCA0MTEgZGVsZXRpb25zKC0pCj4KPiAtLQo+IFRvIHVu
c3Vic2NyaWJlIGZyb20gdGhpcyBsaXN0OiBzZW5kIHRoZSBsaW5lICJ1bnN1YnNjcmliZSBsaW51
eC1rZXJuZWwiIGluCj4gdGhlIGJvZHkgb2YgYSBtZXNzYWdlIHRvIG1ham9yZG9tb0B2Z2VyLmtl
cm5lbC5vcmcKPiBNb3JlIG1ham9yZG9tbyBpbmZvIGF0IKBodHRwOi8vdmdlci5rZXJuZWwub3Jn
L21ham9yZG9tby1pbmZvLmh0bWwKPiBQbGVhc2UgcmVhZCB0aGUgRkFRIGF0IKBodHRwOi8vd3d3
LnR1eC5vcmcvbGttbC8K

Re: [ 00/78] 3.3.2-stable review

[Sergio Correia]

Hello Greg,


On Wed, Apr 11, 2012 at 7:11 PM, Greg KH <gregkh@linuxfoundation.org> wrote:
> This is the start of the stable review cycle for the 3.3.2 release.
> There are 78 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Fri Apr 13 23:10:16 UTC 2012.
> Anything received after that time might be too late.
>

is there any chance for this one to be included in this review cycle?

http://www.spinics.net/lists/linux-wireless/msg87999.html

best regards,
sergio

> The whole patch series can be found in one patch at:
>        kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.3.2-rc1.gz
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
>
> -------------
>  Makefile                                           |    4 +-
>  arch/arm/mach-at91/at91sam9263_devices.c           |    3 +-
>  arch/arm/mach-at91/at91sam9g45_devices.c           |    6 +-
>  arch/arm/mach-at91/board-sam9263ek.c               |    1 +
>  arch/arm/mach-at91/board-sam9m10g45ek.c            |    1 +
>  arch/m68k/mac/config.c                             |    3 +
>  arch/x86/include/asm/timer.h                       |    8 +-
>  arch/x86/kernel/apic/io_apic.c                     |   40 +----
>  arch/x86/kernel/kgdb.c                             |   60 ++++++++
>  arch/x86/kernel/tsc.c                              |    3 +-
>  arch/x86/net/bpf_jit_comp.c                        |    2 +-
>  drivers/acpi/acpica/tbfadt.c                       |    8 +-
>  drivers/acpi/processor_thermal.c                   |   45 +++++-
>  drivers/base/firmware_class.c                      |   96 ++++++++----
>  drivers/base/power/runtime.c                       |    3 +-
>  drivers/base/regmap/regcache-rbtree.c              |    8 +-
>  drivers/dma/ioat/dma.c                             |   16 +-
>  drivers/dma/ioat/dma.h                             |    6 +-
>  drivers/dma/ioat/dma_v2.c                          |    8 +-
>  drivers/dma/ioat/dma_v3.c                          |    8 +-
>  drivers/gpu/drm/drm_fb_helper.c                    |    8 +-
>  drivers/gpu/drm/i915/i915_drv.c                    |    2 +
>  drivers/gpu/drm/i915/i915_reg.h                    |    1 +
>  drivers/gpu/drm/i915/intel_bios.c                  |   23 ++-
>  drivers/gpu/drm/i915/intel_display.c               |    6 +
>  drivers/gpu/drm/i915/intel_lvds.c                  |    8 +
>  drivers/gpu/drm/i915/intel_sprite.c                |    3 +
>  drivers/gpu/drm/radeon/atom.c                      |   15 +-
>  drivers/gpu/drm/radeon/atom.h                      |    1 +
>  drivers/media/dvb/dvb-core/dvb_frontend.c          |   12 ++
>  drivers/media/video/uvc/uvc_video.c                |   50 +++---
>  drivers/mfd/da9052-spi.c                           |    4 +-
>  drivers/mfd/twl6030-irq.c                          |   13 +-
>  drivers/misc/kgdbts.c                              |  160 ++++++++++++++------
>  drivers/mmc/core/sdio_bus.c                        |   12 +-
>  drivers/mmc/host/atmel-mci.c                       |    9 +-
>  drivers/mmc/host/sdhci-dove.c                      |    1 +
>  drivers/mtd/devices/block2mtd.c                    |    1 +
>  drivers/mtd/devices/doc2000.c                      |    2 +-
>  drivers/mtd/devices/doc2001.c                      |    2 +-
>  drivers/mtd/devices/doc2001plus.c                  |    2 +-
>  drivers/mtd/devices/docg3.c                        |    2 +-
>  drivers/mtd/devices/lart.c                         |    1 +
>  drivers/mtd/devices/m25p80.c                       |    1 +
>  drivers/mtd/devices/sst25l.c                       |    1 +
>  drivers/mtd/maps/ixp4xx.c                          |    5 +-
>  drivers/mtd/maps/lantiq-flash.c                    |    3 +-
>  drivers/mtd/nand/gpmi-nand/gpmi-nand.c             |    2 +-
>  drivers/net/ethernet/broadcom/tg3.c                |    4 +-
>  drivers/net/ethernet/freescale/fsl_pq_mdio.c       |   12 +-
>  drivers/net/ethernet/marvell/sky2.c                |    5 +-
>  drivers/net/ethernet/via/via-rhine.c               |   12 +-
>  drivers/net/usb/cdc_eem.c                          |    1 +
>  drivers/net/usb/zaurus.c                           |    5 +
>  drivers/net/wireless/ath/ath9k/calib.c             |    5 +-
>  drivers/net/wireless/iwlegacy/3945-mac.c           |    1 -
>  drivers/net/wireless/iwlegacy/4965-mac.c           |    1 -
>  drivers/net/wireless/iwlegacy/common.c             |   18 ++-
>  drivers/net/wireless/rtlwifi/rtl8192c/phy_common.c |    2 +-
>  drivers/net/wireless/rtlwifi/rtl8192de/phy.c       |    2 +-
>  drivers/platform/x86/acer-wmi.c                    |    1 +
>  drivers/pnp/pnpacpi/core.c                         |    7 +-
>  drivers/staging/android/lowmemorykiller.c          |   47 +-----
>  drivers/target/tcm_fc/tcm_fc.h                     |    1 +
>  drivers/target/tcm_fc/tfc_cmd.c                    |   10 +-
>  drivers/target/tcm_fc/tfc_conf.c                   |   13 +-
>  drivers/target/tcm_fc/tfc_io.c                     |    2 +
>  drivers/usb/host/ohci-at91.c                       |    4 +-
>  fs/cifs/file.c                                     |   10 +-
>  fs/locks.c                                         |    3 +-
>  fs/nfs/nfs4proc.c                                  |    2 +-
>  include/linux/fs.h                                 |    5 +
>  include/linux/kernel.h                             |   13 ++
>  include/linux/kgdb.h                               |    7 +-
>  include/linux/kmod.h                               |   27 +++-
>  kernel/cred.c                                      |    2 +
>  kernel/debug/debug_core.c                          |   53 +++----
>  kernel/irq/migration.c                             |   10 +-
>  kernel/kmod.c                                      |  117 ++++++++++----
>  kernel/power/hibernate.c                           |   18 +--
>  kernel/power/process.c                             |    8 +
>  kernel/power/suspend.c                             |    7 -
>  kernel/power/user.c                                |   10 +-
>  kernel/sysctl.c                                    |    8 +-
>  kernel/trace/trace.c                               |    4 +
>  kernel/trace/trace_entries.h                       |   16 +-
>  kernel/trace/trace_export.c                        |    2 +-
>  net/mac80211/agg-rx.c                              |    3 +-
>  net/rose/rose_dev.c                                |    4 +-
>  scripts/mod/modpost.c                              |    9 +-
>  scripts/mod/modpost.h                              |    1 +
>  security/tomoyo/mount.c                            |   38 ++---
>  sound/pci/hda/patch_realtek.c                      |   11 +-
>  sound/soc/codecs/ak4642.c                          |    2 +-
>  sound/soc/codecs/wm8994.c                          |    2 +-
>  sound/soc/tegra/tegra_i2s.c                        |    2 +-
>  96 files changed, 815 insertions(+), 411 deletions(-)
>
> --
> 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/
ÿôèº{.nÇ+‰·Ÿ®‰­†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a­¢f£¢·hšïêÿ‘êçz_è®\x03(­éšŽŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨è­Ú&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥

Re: [ 00/78] 3.3.2-stable review

[Sergio Correia]

Hello Greg,


On Wed, Apr 11, 2012 at 7:11 PM, Greg KH <gregkh@linuxfoundation.org> wrote:
> This is the start of the stable review cycle for the 3.3.2 release.
> There are 78 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Fri Apr 13 23:10:16 UTC 2012.
> Anything received after that time might be too late.
>

is there any chance for this one to be included in this review cycle?

http://www.spinics.net/lists/linux-wireless/msg87999.html

best regards,
sergio

> The whole patch series can be found in one patch at:
>        kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.3.2-rc1.gz
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
>
> -------------
>  Makefile                                           |    4 +-
>  arch/arm/mach-at91/at91sam9263_devices.c           |    3 +-
>  arch/arm/mach-at91/at91sam9g45_devices.c           |    6 +-
>  arch/arm/mach-at91/board-sam9263ek.c               |    1 +
>  arch/arm/mach-at91/board-sam9m10g45ek.c            |    1 +
>  arch/m68k/mac/config.c                             |    3 +
>  arch/x86/include/asm/timer.h                       |    8 +-
>  arch/x86/kernel/apic/io_apic.c                     |   40 +----
>  arch/x86/kernel/kgdb.c                             |   60 ++++++++
>  arch/x86/kernel/tsc.c                              |    3 +-
>  arch/x86/net/bpf_jit_comp.c                        |    2 +-
>  drivers/acpi/acpica/tbfadt.c                       |    8 +-
>  drivers/acpi/processor_thermal.c                   |   45 +++++-
>  drivers/base/firmware_class.c                      |   96 ++++++++----
>  drivers/base/power/runtime.c                       |    3 +-
>  drivers/base/regmap/regcache-rbtree.c              |    8 +-
>  drivers/dma/ioat/dma.c                             |   16 +-
>  drivers/dma/ioat/dma.h                             |    6 +-
>  drivers/dma/ioat/dma_v2.c                          |    8 +-
>  drivers/dma/ioat/dma_v3.c                          |    8 +-
>  drivers/gpu/drm/drm_fb_helper.c                    |    8 +-
>  drivers/gpu/drm/i915/i915_drv.c                    |    2 +
>  drivers/gpu/drm/i915/i915_reg.h                    |    1 +
>  drivers/gpu/drm/i915/intel_bios.c                  |   23 ++-
>  drivers/gpu/drm/i915/intel_display.c               |    6 +
>  drivers/gpu/drm/i915/intel_lvds.c                  |    8 +
>  drivers/gpu/drm/i915/intel_sprite.c                |    3 +
>  drivers/gpu/drm/radeon/atom.c                      |   15 +-
>  drivers/gpu/drm/radeon/atom.h                      |    1 +
>  drivers/media/dvb/dvb-core/dvb_frontend.c          |   12 ++
>  drivers/media/video/uvc/uvc_video.c                |   50 +++---
>  drivers/mfd/da9052-spi.c                           |    4 +-
>  drivers/mfd/twl6030-irq.c                          |   13 +-
>  drivers/misc/kgdbts.c                              |  160 ++++++++++++++------
>  drivers/mmc/core/sdio_bus.c                        |   12 +-
>  drivers/mmc/host/atmel-mci.c                       |    9 +-
>  drivers/mmc/host/sdhci-dove.c                      |    1 +
>  drivers/mtd/devices/block2mtd.c                    |    1 +
>  drivers/mtd/devices/doc2000.c                      |    2 +-
>  drivers/mtd/devices/doc2001.c                      |    2 +-
>  drivers/mtd/devices/doc2001plus.c                  |    2 +-
>  drivers/mtd/devices/docg3.c                        |    2 +-
>  drivers/mtd/devices/lart.c                         |    1 +
>  drivers/mtd/devices/m25p80.c                       |    1 +
>  drivers/mtd/devices/sst25l.c                       |    1 +
>  drivers/mtd/maps/ixp4xx.c                          |    5 +-
>  drivers/mtd/maps/lantiq-flash.c                    |    3 +-
>  drivers/mtd/nand/gpmi-nand/gpmi-nand.c             |    2 +-
>  drivers/net/ethernet/broadcom/tg3.c                |    4 +-
>  drivers/net/ethernet/freescale/fsl_pq_mdio.c       |   12 +-
>  drivers/net/ethernet/marvell/sky2.c                |    5 +-
>  drivers/net/ethernet/via/via-rhine.c               |   12 +-
>  drivers/net/usb/cdc_eem.c                          |    1 +
>  drivers/net/usb/zaurus.c                           |    5 +
>  drivers/net/wireless/ath/ath9k/calib.c             |    5 +-
>  drivers/net/wireless/iwlegacy/3945-mac.c           |    1 -
>  drivers/net/wireless/iwlegacy/4965-mac.c           |    1 -
>  drivers/net/wireless/iwlegacy/common.c             |   18 ++-
>  drivers/net/wireless/rtlwifi/rtl8192c/phy_common.c |    2 +-
>  drivers/net/wireless/rtlwifi/rtl8192de/phy.c       |    2 +-
>  drivers/platform/x86/acer-wmi.c                    |    1 +
>  drivers/pnp/pnpacpi/core.c                         |    7 +-
>  drivers/staging/android/lowmemorykiller.c          |   47 +-----
>  drivers/target/tcm_fc/tcm_fc.h                     |    1 +
>  drivers/target/tcm_fc/tfc_cmd.c                    |   10 +-
>  drivers/target/tcm_fc/tfc_conf.c                   |   13 +-
>  drivers/target/tcm_fc/tfc_io.c                     |    2 +
>  drivers/usb/host/ohci-at91.c                       |    4 +-
>  fs/cifs/file.c                                     |   10 +-
>  fs/locks.c                                         |    3 +-
>  fs/nfs/nfs4proc.c                                  |    2 +-
>  include/linux/fs.h                                 |    5 +
>  include/linux/kernel.h                             |   13 ++
>  include/linux/kgdb.h                               |    7 +-
>  include/linux/kmod.h                               |   27 +++-
>  kernel/cred.c                                      |    2 +
>  kernel/debug/debug_core.c                          |   53 +++----
>  kernel/irq/migration.c                             |   10 +-
>  kernel/kmod.c                                      |  117 ++++++++++----
>  kernel/power/hibernate.c                           |   18 +--
>  kernel/power/process.c                             |    8 +
>  kernel/power/suspend.c                             |    7 -
>  kernel/power/user.c                                |   10 +-
>  kernel/sysctl.c                                    |    8 +-
>  kernel/trace/trace.c                               |    4 +
>  kernel/trace/trace_entries.h                       |   16 +-
>  kernel/trace/trace_export.c                        |    2 +-
>  net/mac80211/agg-rx.c                              |    3 +-
>  net/rose/rose_dev.c                                |    4 +-
>  scripts/mod/modpost.c                              |    9 +-
>  scripts/mod/modpost.h                              |    1 +
>  security/tomoyo/mount.c                            |   38 ++---
>  sound/pci/hda/patch_realtek.c                      |   11 +-
>  sound/soc/codecs/ak4642.c                          |    2 +-
>  sound/soc/codecs/wm8994.c                          |    2 +-
>  sound/soc/tegra/tegra_i2s.c                        |    2 +-
>  96 files changed, 815 insertions(+), 411 deletions(-)
>
> --
> 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/

[ath9k-devel] [ 00/78] 3.3.2-stable review

[Sergio Correia]

Hello Greg,


On Wed, Apr 11, 2012 at 7:11 PM, Greg KH <gregkh@linuxfoundation.org> wrote:
> This is the start of the stable review cycle for the 3.3.2 release.
> There are 78 patches in this series, all will be posted as a response
> to this one. ?If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Fri Apr 13 23:10:16 UTC 2012.
> Anything received after that time might be too late.
>

is there any chance for this one to be included in this review cycle?

http://www.spinics.net/lists/linux-wireless/msg87999.html

best regards,
sergio

> The whole patch series can be found in one patch at:
> ? ? ? ?kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.3.2-rc1.gz
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
>
> -------------
> ?Makefile ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? | ? ?4 +-
> ?arch/arm/mach-at91/at91sam9263_devices.c ? ? ? ? ? | ? ?3 +-
> ?arch/arm/mach-at91/at91sam9g45_devices.c ? ? ? ? ? | ? ?6 +-
> ?arch/arm/mach-at91/board-sam9263ek.c ? ? ? ? ? ? ? | ? ?1 +
> ?arch/arm/mach-at91/board-sam9m10g45ek.c ? ? ? ? ? ?| ? ?1 +
> ?arch/m68k/mac/config.c ? ? ? ? ? ? ? ? ? ? ? ? ? ? | ? ?3 +
> ?arch/x86/include/asm/timer.h ? ? ? ? ? ? ? ? ? ? ? | ? ?8 +-
> ?arch/x86/kernel/apic/io_apic.c ? ? ? ? ? ? ? ? ? ? | ? 40 +----
> ?arch/x86/kernel/kgdb.c ? ? ? ? ? ? ? ? ? ? ? ? ? ? | ? 60 ++++++++
> ?arch/x86/kernel/tsc.c ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?| ? ?3 +-
> ?arch/x86/net/bpf_jit_comp.c ? ? ? ? ? ? ? ? ? ? ? ?| ? ?2 +-
> ?drivers/acpi/acpica/tbfadt.c ? ? ? ? ? ? ? ? ? ? ? | ? ?8 +-
> ?drivers/acpi/processor_thermal.c ? ? ? ? ? ? ? ? ? | ? 45 +++++-
> ?drivers/base/firmware_class.c ? ? ? ? ? ? ? ? ? ? ?| ? 96 ++++++++----
> ?drivers/base/power/runtime.c ? ? ? ? ? ? ? ? ? ? ? | ? ?3 +-
> ?drivers/base/regmap/regcache-rbtree.c ? ? ? ? ? ? ?| ? ?8 +-
> ?drivers/dma/ioat/dma.c ? ? ? ? ? ? ? ? ? ? ? ? ? ? | ? 16 +-
> ?drivers/dma/ioat/dma.h ? ? ? ? ? ? ? ? ? ? ? ? ? ? | ? ?6 +-
> ?drivers/dma/ioat/dma_v2.c ? ? ? ? ? ? ? ? ? ? ? ? ?| ? ?8 +-
> ?drivers/dma/ioat/dma_v3.c ? ? ? ? ? ? ? ? ? ? ? ? ?| ? ?8 +-
> ?drivers/gpu/drm/drm_fb_helper.c ? ? ? ? ? ? ? ? ? ?| ? ?8 +-
> ?drivers/gpu/drm/i915/i915_drv.c ? ? ? ? ? ? ? ? ? ?| ? ?2 +
> ?drivers/gpu/drm/i915/i915_reg.h ? ? ? ? ? ? ? ? ? ?| ? ?1 +
> ?drivers/gpu/drm/i915/intel_bios.c ? ? ? ? ? ? ? ? ?| ? 23 ++-
> ?drivers/gpu/drm/i915/intel_display.c ? ? ? ? ? ? ? | ? ?6 +
> ?drivers/gpu/drm/i915/intel_lvds.c ? ? ? ? ? ? ? ? ?| ? ?8 +
> ?drivers/gpu/drm/i915/intel_sprite.c ? ? ? ? ? ? ? ?| ? ?3 +
> ?drivers/gpu/drm/radeon/atom.c ? ? ? ? ? ? ? ? ? ? ?| ? 15 +-
> ?drivers/gpu/drm/radeon/atom.h ? ? ? ? ? ? ? ? ? ? ?| ? ?1 +
> ?drivers/media/dvb/dvb-core/dvb_frontend.c ? ? ? ? ?| ? 12 ++
> ?drivers/media/video/uvc/uvc_video.c ? ? ? ? ? ? ? ?| ? 50 +++---
> ?drivers/mfd/da9052-spi.c ? ? ? ? ? ? ? ? ? ? ? ? ? | ? ?4 +-
> ?drivers/mfd/twl6030-irq.c ? ? ? ? ? ? ? ? ? ? ? ? ?| ? 13 +-
> ?drivers/misc/kgdbts.c ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?| ?160 ++++++++++++++------
> ?drivers/mmc/core/sdio_bus.c ? ? ? ? ? ? ? ? ? ? ? ?| ? 12 +-
> ?drivers/mmc/host/atmel-mci.c ? ? ? ? ? ? ? ? ? ? ? | ? ?9 +-
> ?drivers/mmc/host/sdhci-dove.c ? ? ? ? ? ? ? ? ? ? ?| ? ?1 +
> ?drivers/mtd/devices/block2mtd.c ? ? ? ? ? ? ? ? ? ?| ? ?1 +
> ?drivers/mtd/devices/doc2000.c ? ? ? ? ? ? ? ? ? ? ?| ? ?2 +-
> ?drivers/mtd/devices/doc2001.c ? ? ? ? ? ? ? ? ? ? ?| ? ?2 +-
> ?drivers/mtd/devices/doc2001plus.c ? ? ? ? ? ? ? ? ?| ? ?2 +-
> ?drivers/mtd/devices/docg3.c ? ? ? ? ? ? ? ? ? ? ? ?| ? ?2 +-
> ?drivers/mtd/devices/lart.c ? ? ? ? ? ? ? ? ? ? ? ? | ? ?1 +
> ?drivers/mtd/devices/m25p80.c ? ? ? ? ? ? ? ? ? ? ? | ? ?1 +
> ?drivers/mtd/devices/sst25l.c ? ? ? ? ? ? ? ? ? ? ? | ? ?1 +
> ?drivers/mtd/maps/ixp4xx.c ? ? ? ? ? ? ? ? ? ? ? ? ?| ? ?5 +-
> ?drivers/mtd/maps/lantiq-flash.c ? ? ? ? ? ? ? ? ? ?| ? ?3 +-
> ?drivers/mtd/nand/gpmi-nand/gpmi-nand.c ? ? ? ? ? ? | ? ?2 +-
> ?drivers/net/ethernet/broadcom/tg3.c ? ? ? ? ? ? ? ?| ? ?4 +-
> ?drivers/net/ethernet/freescale/fsl_pq_mdio.c ? ? ? | ? 12 +-
> ?drivers/net/ethernet/marvell/sky2.c ? ? ? ? ? ? ? ?| ? ?5 +-
> ?drivers/net/ethernet/via/via-rhine.c ? ? ? ? ? ? ? | ? 12 +-
> ?drivers/net/usb/cdc_eem.c ? ? ? ? ? ? ? ? ? ? ? ? ?| ? ?1 +
> ?drivers/net/usb/zaurus.c ? ? ? ? ? ? ? ? ? ? ? ? ? | ? ?5 +
> ?drivers/net/wireless/ath/ath9k/calib.c ? ? ? ? ? ? | ? ?5 +-
> ?drivers/net/wireless/iwlegacy/3945-mac.c ? ? ? ? ? | ? ?1 -
> ?drivers/net/wireless/iwlegacy/4965-mac.c ? ? ? ? ? | ? ?1 -
> ?drivers/net/wireless/iwlegacy/common.c ? ? ? ? ? ? | ? 18 ++-
> ?drivers/net/wireless/rtlwifi/rtl8192c/phy_common.c | ? ?2 +-
> ?drivers/net/wireless/rtlwifi/rtl8192de/phy.c ? ? ? | ? ?2 +-
> ?drivers/platform/x86/acer-wmi.c ? ? ? ? ? ? ? ? ? ?| ? ?1 +
> ?drivers/pnp/pnpacpi/core.c ? ? ? ? ? ? ? ? ? ? ? ? | ? ?7 +-
> ?drivers/staging/android/lowmemorykiller.c ? ? ? ? ?| ? 47 +-----
> ?drivers/target/tcm_fc/tcm_fc.h ? ? ? ? ? ? ? ? ? ? | ? ?1 +
> ?drivers/target/tcm_fc/tfc_cmd.c ? ? ? ? ? ? ? ? ? ?| ? 10 +-
> ?drivers/target/tcm_fc/tfc_conf.c ? ? ? ? ? ? ? ? ? | ? 13 +-
> ?drivers/target/tcm_fc/tfc_io.c ? ? ? ? ? ? ? ? ? ? | ? ?2 +
> ?drivers/usb/host/ohci-at91.c ? ? ? ? ? ? ? ? ? ? ? | ? ?4 +-
> ?fs/cifs/file.c ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? | ? 10 +-
> ?fs/locks.c ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? | ? ?3 +-
> ?fs/nfs/nfs4proc.c ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?| ? ?2 +-
> ?include/linux/fs.h ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? | ? ?5 +
> ?include/linux/kernel.h ? ? ? ? ? ? ? ? ? ? ? ? ? ? | ? 13 ++
> ?include/linux/kgdb.h ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? | ? ?7 +-
> ?include/linux/kmod.h ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? | ? 27 +++-
> ?kernel/cred.c ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?| ? ?2 +
> ?kernel/debug/debug_core.c ? ? ? ? ? ? ? ? ? ? ? ? ?| ? 53 +++----
> ?kernel/irq/migration.c ? ? ? ? ? ? ? ? ? ? ? ? ? ? | ? 10 +-
> ?kernel/kmod.c ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?| ?117 ++++++++++----
> ?kernel/power/hibernate.c ? ? ? ? ? ? ? ? ? ? ? ? ? | ? 18 +--
> ?kernel/power/process.c ? ? ? ? ? ? ? ? ? ? ? ? ? ? | ? ?8 +
> ?kernel/power/suspend.c ? ? ? ? ? ? ? ? ? ? ? ? ? ? | ? ?7 -
> ?kernel/power/user.c ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?| ? 10 +-
> ?kernel/sysctl.c ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?| ? ?8 +-
> ?kernel/trace/trace.c ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? | ? ?4 +
> ?kernel/trace/trace_entries.h ? ? ? ? ? ? ? ? ? ? ? | ? 16 +-
> ?kernel/trace/trace_export.c ? ? ? ? ? ? ? ? ? ? ? ?| ? ?2 +-
> ?net/mac80211/agg-rx.c ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?| ? ?3 +-
> ?net/rose/rose_dev.c ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?| ? ?4 +-
> ?scripts/mod/modpost.c ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?| ? ?9 +-
> ?scripts/mod/modpost.h ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?| ? ?1 +
> ?security/tomoyo/mount.c ? ? ? ? ? ? ? ? ? ? ? ? ? ?| ? 38 ++---
> ?sound/pci/hda/patch_realtek.c ? ? ? ? ? ? ? ? ? ? ?| ? 11 +-
> ?sound/soc/codecs/ak4642.c ? ? ? ? ? ? ? ? ? ? ? ? ?| ? ?2 +-
> ?sound/soc/codecs/wm8994.c ? ? ? ? ? ? ? ? ? ? ? ? ?| ? ?2 +-
> ?sound/soc/tegra/tegra_i2s.c ? ? ? ? ? ? ? ? ? ? ? ?| ? ?2 +-
> ?96 files changed, 815 insertions(+), 411 deletions(-)
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at ?http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at ?http://www.tux.org/lkml/

Re: [ 00/78] 3.3.2-stable review

[Greg KH]

On Wed, Apr 11, 2012 at 07:59:14PM -0400, Sergio Correia wrote:
> Hello Greg,
> 
> 
> On Wed, Apr 11, 2012 at 7:11 PM, Greg KH <gregkh@linuxfoundation.org> wrote:
> > This is the start of the stable review cycle for the 3.3.2 release.
> > There are 78 patches in this series, all will be posted as a response
> > to this one.  If anyone has any issues with these being applied, please
> > let me know.
> >
> > Responses should be made by Fri Apr 13 23:10:16 UTC 2012.
> > Anything received after that time might be too late.
> >
> 
> is there any chance for this one to be included in this review cycle?
> 
> http://www.spinics.net/lists/linux-wireless/msg87999.html

Have you read Documentation/stable_kernel_rules.txt?  Based on that, I
don't think it can, yet, right?

thanks,

greg k-h

Re: [ 00/78] 3.3.2-stable review

[Greg KH]

On Wed, Apr 11, 2012 at 07:59:14PM -0400, Sergio Correia wrote:
> Hello Greg,
> 
> 
> On Wed, Apr 11, 2012 at 7:11 PM, Greg KH <gregkh@linuxfoundation.org> wrote:
> > This is the start of the stable review cycle for the 3.3.2 release.
> > There are 78 patches in this series, all will be posted as a response
> > to this one. �If anyone has any issues with these being applied, please
> > let me know.
> >
> > Responses should be made by Fri Apr 13 23:10:16 UTC 2012.
> > Anything received after that time might be too late.
> >
> 
> is there any chance for this one to be included in this review cycle?
> 
> http://www.spinics.net/lists/linux-wireless/msg87999.html

Have you read Documentation/stable_kernel_rules.txt?  Based on that, I
don't think it can, yet, right?

thanks,

greg k-h

[ath9k-devel] [ 00/78] 3.3.2-stable review

[Greg KH]

On Wed, Apr 11, 2012 at 07:59:14PM -0400, Sergio Correia wrote:
> Hello Greg,
> 
> 
> On Wed, Apr 11, 2012 at 7:11 PM, Greg KH <gregkh@linuxfoundation.org> wrote:
> > This is the start of the stable review cycle for the 3.3.2 release.
> > There are 78 patches in this series, all will be posted as a response
> > to this one. ?If anyone has any issues with these being applied, please
> > let me know.
> >
> > Responses should be made by Fri Apr 13 23:10:16 UTC 2012.
> > Anything received after that time might be too late.
> >
> 
> is there any chance for this one to be included in this review cycle?
> 
> http://www.spinics.net/lists/linux-wireless/msg87999.html

Have you read Documentation/stable_kernel_rules.txt?  Based on that, I
don't think it can, yet, right?

thanks,

greg k-h

Re: [ 00/78] 3.3.2-stable review

[Sergio Correia]

On Wed, Apr 11, 2012 at 8:29 PM, Greg KH <gregkh@linuxfoundation.org> wrote:
> On Wed, Apr 11, 2012 at 07:59:14PM -0400, Sergio Correia wrote:
>> Hello Greg,
>>
>>
>> On Wed, Apr 11, 2012 at 7:11 PM, Greg KH <gregkh@linuxfoundation.org> wrote:
>> > This is the start of the stable review cycle for the 3.3.2 release.
>> > There are 78 patches in this series, all will be posted as a response
>> > to this one.  If anyone has any issues with these being applied, please
>> > let me know.
>> >
>> > Responses should be made by Fri Apr 13 23:10:16 UTC 2012.
>> > Anything received after that time might be too late.
>> >
>>
>> is there any chance for this one to be included in this review cycle?
>>
>> http://www.spinics.net/lists/linux-wireless/msg87999.html
>
> Have you read Documentation/stable_kernel_rules.txt?  Based on that, I
> don't think it can, yet, right?
>

I hadn't, but I have now, thanks for the pointer. And yes, you are right.

thanks,
sergio

> thanks,
>
> greg k-h

Re: [ 00/78] 3.3.2-stable review

[Sergio Correia]

On Wed, Apr 11, 2012 at 8:29 PM, Greg KH <gregkh@linuxfoundation.org> wrote:
> On Wed, Apr 11, 2012 at 07:59:14PM -0400, Sergio Correia wrote:
>> Hello Greg,
>>
>>
>> On Wed, Apr 11, 2012 at 7:11 PM, Greg KH <gregkh@linuxfoundation.org> wrote:
>> > This is the start of the stable review cycle for the 3.3.2 release.
>> > There are 78 patches in this series, all will be posted as a response
>> > to this one. �If anyone has any issues with these being applied, please
>> > let me know.
>> >
>> > Responses should be made by Fri Apr 13 23:10:16 UTC 2012.
>> > Anything received after that time might be too late.
>> >
>>
>> is there any chance for this one to be included in this review cycle?
>>
>> http://www.spinics.net/lists/linux-wireless/msg87999.html
>
> Have you read Documentation/stable_kernel_rules.txt? �Based on that, I
> don't think it can, yet, right?
>

I hadn't, but I have now, thanks for the pointer. And yes, you are right.

thanks,
sergio

> thanks,
>
> greg k-h

[ath9k-devel] [ 00/78] 3.3.2-stable review

[Sergio Correia]

On Wed, Apr 11, 2012 at 8:29 PM, Greg KH <gregkh@linuxfoundation.org> wrote:
> On Wed, Apr 11, 2012 at 07:59:14PM -0400, Sergio Correia wrote:
>> Hello Greg,
>>
>>
>> On Wed, Apr 11, 2012 at 7:11 PM, Greg KH <gregkh@linuxfoundation.org> wrote:
>> > This is the start of the stable review cycle for the 3.3.2 release.
>> > There are 78 patches in this series, all will be posted as a response
>> > to this one. ?If anyone has any issues with these being applied, please
>> > let me know.
>> >
>> > Responses should be made by Fri Apr 13 23:10:16 UTC 2012.
>> > Anything received after that time might be too late.
>> >
>>
>> is there any chance for this one to be included in this review cycle?
>>
>> http://www.spinics.net/lists/linux-wireless/msg87999.html
>
> Have you read Documentation/stable_kernel_rules.txt? ?Based on that, I
> don't think it can, yet, right?
>

I hadn't, but I have now, thanks for the pointer. And yes, you are right.

thanks,
sergio

> thanks,
>
> greg k-h

Re: [ 00/78] 3.3.2-stable review

[Felipe Contreras]

On Thu, Apr 12, 2012 at 3:29 AM, Greg KH <gregkh@linuxfoundation.org> wrote:
> On Wed, Apr 11, 2012 at 07:59:14PM -0400, Sergio Correia wrote:
>> Hello Greg,
>>
>>
>> On Wed, Apr 11, 2012 at 7:11 PM, Greg KH <gregkh@linuxfoundation.org> wrote:
>> > This is the start of the stable review cycle for the 3.3.2 release.
>> > There are 78 patches in this series, all will be posted as a response
>> > to this one.  If anyone has any issues with these being applied, please
>> > let me know.
>> >
>> > Responses should be made by Fri Apr 13 23:10:16 UTC 2012.
>> > Anything received after that time might be too late.
>> >
>>
>> is there any chance for this one to be included in this review cycle?
>>
>> http://www.spinics.net/lists/linux-wireless/msg87999.html

I was going to ask for exactly the same thing. My system is completely
unusable without this patch; not only does the network doesn't work,
but quite often the kernel is stuck consuming 100% of the CPU.

> Have you read Documentation/stable_kernel_rules.txt?  Based on that, I
> don't think it can, yet, right?

Why not? This patch makes the code go back to a previous state, it is
obviously more stable than the current state, and the code already
exists in Linus's tree (in previous releases).

But hey, I guess it's OK that 3.3.x is stuck in and endless loop right
after booting, because rules are more important than fixing obvious
breakage.

-- 
Felipe Contreras

[ath9k-devel] [ 00/78] 3.3.2-stable review

[Felipe Contreras]

On Thu, Apr 12, 2012 at 3:29 AM, Greg KH <gregkh@linuxfoundation.org> wrote:
> On Wed, Apr 11, 2012 at 07:59:14PM -0400, Sergio Correia wrote:
>> Hello Greg,
>>
>>
>> On Wed, Apr 11, 2012 at 7:11 PM, Greg KH <gregkh@linuxfoundation.org> wrote:
>> > This is the start of the stable review cycle for the 3.3.2 release.
>> > There are 78 patches in this series, all will be posted as a response
>> > to this one. ?If anyone has any issues with these being applied, please
>> > let me know.
>> >
>> > Responses should be made by Fri Apr 13 23:10:16 UTC 2012.
>> > Anything received after that time might be too late.
>> >
>>
>> is there any chance for this one to be included in this review cycle?
>>
>> http://www.spinics.net/lists/linux-wireless/msg87999.html

I was going to ask for exactly the same thing. My system is completely
unusable without this patch; not only does the network doesn't work,
but quite often the kernel is stuck consuming 100% of the CPU.

> Have you read Documentation/stable_kernel_rules.txt? ?Based on that, I
> don't think it can, yet, right?

Why not? This patch makes the code go back to a previous state, it is
obviously more stable than the current state, and the code already
exists in Linus's tree (in previous releases).

But hey, I guess it's OK that 3.3.x is stuck in and endless loop right
after booting, because rules are more important than fixing obvious
breakage.

-- 
Felipe Contreras

Re: [ 00/78] 3.3.2-stable review

[Greg KH]

On Thu, Apr 12, 2012 at 04:03:59AM +0300, Felipe Contreras wrote:
> On Thu, Apr 12, 2012 at 3:29 AM, Greg KH <gregkh@linuxfoundation.org> wrote:
> > On Wed, Apr 11, 2012 at 07:59:14PM -0400, Sergio Correia wrote:
> >> Hello Greg,
> >>
> >>
> >> On Wed, Apr 11, 2012 at 7:11 PM, Greg KH <gregkh@linuxfoundation.org> wrote:
> >> > This is the start of the stable review cycle for the 3.3.2 release.
> >> > There are 78 patches in this series, all will be posted as a response
> >> > to this one.  If anyone has any issues with these being applied, please
> >> > let me know.
> >> >
> >> > Responses should be made by Fri Apr 13 23:10:16 UTC 2012.
> >> > Anything received after that time might be too late.
> >> >
> >>
> >> is there any chance for this one to be included in this review cycle?
> >>
> >> http://www.spinics.net/lists/linux-wireless/msg87999.html
> 
> I was going to ask for exactly the same thing. My system is completely
> unusable without this patch; not only does the network doesn't work,
> but quite often the kernel is stuck consuming 100% of the CPU.
> 
> > Have you read Documentation/stable_kernel_rules.txt?  Based on that, I
> > don't think it can, yet, right?
> 
> Why not? This patch makes the code go back to a previous state, it is
> obviously more stable than the current state, and the code already
> exists in Linus's tree (in previous releases).

It does?  What is the git commit id of the patch?  Based in the email
above, I assumed it had not made it to Linus's tree already.

> But hey, I guess it's OK that 3.3.x is stuck in and endless loop right
> after booting, because rules are more important than fixing obvious
> breakage.

What rule did you think I was saying this was not acceptable for?

greg k-h

Re: [ 00/78] 3.3.2-stable review

[Greg KH]

On Thu, Apr 12, 2012 at 04:03:59AM +0300, Felipe Contreras wrote:
> On Thu, Apr 12, 2012 at 3:29 AM, Greg KH <gregkh@linuxfoundation.org> wrote:
> > On Wed, Apr 11, 2012 at 07:59:14PM -0400, Sergio Correia wrote:
> >> Hello Greg,
> >>
> >>
> >> On Wed, Apr 11, 2012 at 7:11 PM, Greg KH <gregkh@linuxfoundation.org> wrote:
> >> > This is the start of the stable review cycle for the 3.3.2 release.
> >> > There are 78 patches in this series, all will be posted as a response
> >> > to this one. �If anyone has any issues with these being applied, please
> >> > let me know.
> >> >
> >> > Responses should be made by Fri Apr 13 23:10:16 UTC 2012.
> >> > Anything received after that time might be too late.
> >> >
> >>
> >> is there any chance for this one to be included in this review cycle?
> >>
> >> http://www.spinics.net/lists/linux-wireless/msg87999.html
> 
> I was going to ask for exactly the same thing. My system is completely
> unusable without this patch; not only does the network doesn't work,
> but quite often the kernel is stuck consuming 100% of the CPU.
> 
> > Have you read Documentation/stable_kernel_rules.txt? �Based on that, I
> > don't think it can, yet, right?
> 
> Why not? This patch makes the code go back to a previous state, it is
> obviously more stable than the current state, and the code already
> exists in Linus's tree (in previous releases).

It does?  What is the git commit id of the patch?  Based in the email
above, I assumed it had not made it to Linus's tree already.

> But hey, I guess it's OK that 3.3.x is stuck in and endless loop right
> after booting, because rules are more important than fixing obvious
> breakage.

What rule did you think I was saying this was not acceptable for?

greg k-h

[ath9k-devel] [ 00/78] 3.3.2-stable review

[Greg KH]

On Thu, Apr 12, 2012 at 04:03:59AM +0300, Felipe Contreras wrote:
> On Thu, Apr 12, 2012 at 3:29 AM, Greg KH <gregkh@linuxfoundation.org> wrote:
> > On Wed, Apr 11, 2012 at 07:59:14PM -0400, Sergio Correia wrote:
> >> Hello Greg,
> >>
> >>
> >> On Wed, Apr 11, 2012 at 7:11 PM, Greg KH <gregkh@linuxfoundation.org> wrote:
> >> > This is the start of the stable review cycle for the 3.3.2 release.
> >> > There are 78 patches in this series, all will be posted as a response
> >> > to this one. ?If anyone has any issues with these being applied, please
> >> > let me know.
> >> >
> >> > Responses should be made by Fri Apr 13 23:10:16 UTC 2012.
> >> > Anything received after that time might be too late.
> >> >
> >>
> >> is there any chance for this one to be included in this review cycle?
> >>
> >> http://www.spinics.net/lists/linux-wireless/msg87999.html
> 
> I was going to ask for exactly the same thing. My system is completely
> unusable without this patch; not only does the network doesn't work,
> but quite often the kernel is stuck consuming 100% of the CPU.
> 
> > Have you read Documentation/stable_kernel_rules.txt? ?Based on that, I
> > don't think it can, yet, right?
> 
> Why not? This patch makes the code go back to a previous state, it is
> obviously more stable than the current state, and the code already
> exists in Linus's tree (in previous releases).

It does?  What is the git commit id of the patch?  Based in the email
above, I assumed it had not made it to Linus's tree already.

> But hey, I guess it's OK that 3.3.x is stuck in and endless loop right
> after booting, because rules are more important than fixing obvious
> breakage.

What rule did you think I was saying this was not acceptable for?

greg k-h

Re: [ 00/78] 3.3.2-stable review

[Heinz Diehl]

On 12.04.2012, Sergio Correia wrote: 

> is there any chance for this one to be included in this review cycle?
> 
> http://www.spinics.net/lists/linux-wireless/msg87999.html

Thanks for pointing this out! This patch fixes my network problems
which forced me to go back to a previous kernel.

[ath9k-devel] [ 00/78] 3.3.2-stable review

[Heinz Diehl]

On 12.04.2012, Sergio Correia wrote: 

> is there any chance for this one to be included in this review cycle?
> 
> http://www.spinics.net/lists/linux-wireless/msg87999.html

Thanks for pointing this out! This patch fixes my network problems
which forced me to go back to a previous kernel.

Re: [ 00/78] 3.3.2-stable review

[Felipe Contreras]

On Thu, Apr 12, 2012 at 4:13 AM, Greg KH <gregkh@linuxfoundation.org> wrote:
> On Thu, Apr 12, 2012 at 04:03:59AM +0300, Felipe Contreras wrote:
>> On Thu, Apr 12, 2012 at 3:29 AM, Greg KH <gregkh@linuxfoundation.org> wrote:
>> > On Wed, Apr 11, 2012 at 07:59:14PM -0400, Sergio Correia wrote:
>> >> Hello Greg,
>> >>
>> >>
>> >> On Wed, Apr 11, 2012 at 7:11 PM, Greg KH <gregkh@linuxfoundation.org> wrote:
>> >> > This is the start of the stable review cycle for the 3.3.2 release.
>> >> > There are 78 patches in this series, all will be posted as a response
>> >> > to this one.  If anyone has any issues with these being applied, please
>> >> > let me know.
>> >> >
>> >> > Responses should be made by Fri Apr 13 23:10:16 UTC 2012.
>> >> > Anything received after that time might be too late.
>> >> >
>> >>
>> >> is there any chance for this one to be included in this review cycle?
>> >>
>> >> http://www.spinics.net/lists/linux-wireless/msg87999.html
>>
>> I was going to ask for exactly the same thing. My system is completely
>> unusable without this patch; not only does the network doesn't work,
>> but quite often the kernel is stuck consuming 100% of the CPU.
>>
>> > Have you read Documentation/stable_kernel_rules.txt?  Based on that, I
>> > don't think it can, yet, right?
>>
>> Why not? This patch makes the code go back to a previous state, it is
>> obviously more stable than the current state, and the code already
>> exists in Linus's tree (in previous releases).
>
> It does?  What is the git commit id of the patch?  Based in the email
> above, I assumed it had not made it to Linus's tree already.

It's a revert of c1afdaff90538ef085b756454f12b29575411214, so so just
take a look at the code in c1afdaff90538ef085b756454f12b29575411214^.

>> But hey, I guess it's OK that 3.3.x is stuck in and endless loop right
>> after booting, because rules are more important than fixing obvious
>> breakage.
>
> What rule did you think I was saying this was not acceptable for?

The fact that the patch as not been applied/reviewed/accepted upstream.

Personally I don't see what is the problem with reverts; we already
know the previous code was working. Sure, in theory it might behave
different due to other changes, but that doesn't seem to be the case
here, plus, it can't be worst than the current situation of staying in
an endless loop.

It appears in 3.4 there are more issues, so the fix there might look
completely different, but regardless, the real issue is that the
proper fix is not yet here.

So the question is do we want 3.3.2 to be completely broken for these
machines, or not?

-- 
Felipe Contreras

[ath9k-devel] [ 00/78] 3.3.2-stable review

[Felipe Contreras]

On Thu, Apr 12, 2012 at 4:13 AM, Greg KH <gregkh@linuxfoundation.org> wrote:
> On Thu, Apr 12, 2012 at 04:03:59AM +0300, Felipe Contreras wrote:
>> On Thu, Apr 12, 2012 at 3:29 AM, Greg KH <gregkh@linuxfoundation.org> wrote:
>> > On Wed, Apr 11, 2012 at 07:59:14PM -0400, Sergio Correia wrote:
>> >> Hello Greg,
>> >>
>> >>
>> >> On Wed, Apr 11, 2012 at 7:11 PM, Greg KH <gregkh@linuxfoundation.org> wrote:
>> >> > This is the start of the stable review cycle for the 3.3.2 release.
>> >> > There are 78 patches in this series, all will be posted as a response
>> >> > to this one. ?If anyone has any issues with these being applied, please
>> >> > let me know.
>> >> >
>> >> > Responses should be made by Fri Apr 13 23:10:16 UTC 2012.
>> >> > Anything received after that time might be too late.
>> >> >
>> >>
>> >> is there any chance for this one to be included in this review cycle?
>> >>
>> >> http://www.spinics.net/lists/linux-wireless/msg87999.html
>>
>> I was going to ask for exactly the same thing. My system is completely
>> unusable without this patch; not only does the network doesn't work,
>> but quite often the kernel is stuck consuming 100% of the CPU.
>>
>> > Have you read Documentation/stable_kernel_rules.txt? ?Based on that, I
>> > don't think it can, yet, right?
>>
>> Why not? This patch makes the code go back to a previous state, it is
>> obviously more stable than the current state, and the code already
>> exists in Linus's tree (in previous releases).
>
> It does? ?What is the git commit id of the patch? ?Based in the email
> above, I assumed it had not made it to Linus's tree already.

It's a revert of c1afdaff90538ef085b756454f12b29575411214, so so just
take a look at the code in c1afdaff90538ef085b756454f12b29575411214^.

>> But hey, I guess it's OK that 3.3.x is stuck in and endless loop right
>> after booting, because rules are more important than fixing obvious
>> breakage.
>
> What rule did you think I was saying this was not acceptable for?

The fact that the patch as not been applied/reviewed/accepted upstream.

Personally I don't see what is the problem with reverts; we already
know the previous code was working. Sure, in theory it might behave
different due to other changes, but that doesn't seem to be the case
here, plus, it can't be worst than the current situation of staying in
an endless loop.

It appears in 3.4 there are more issues, so the fix there might look
completely different, but regardless, the real issue is that the
proper fix is not yet here.

So the question is do we want 3.3.2 to be completely broken for these
machines, or not?

-- 
Felipe Contreras

Re: [ 00/78] 3.3.2-stable review

[Greg KH]

On Thu, Apr 12, 2012 at 04:32:40PM +0300, Felipe Contreras wrote:
> On Thu, Apr 12, 2012 at 4:13 AM, Greg KH <gregkh@linuxfoundation.org> wrote:
> > On Thu, Apr 12, 2012 at 04:03:59AM +0300, Felipe Contreras wrote:
> >> On Thu, Apr 12, 2012 at 3:29 AM, Greg KH <gregkh@linuxfoundation.org> wrote:
> >> > On Wed, Apr 11, 2012 at 07:59:14PM -0400, Sergio Correia wrote:
> >> >> Hello Greg,
> >> >>
> >> >>
> >> >> On Wed, Apr 11, 2012 at 7:11 PM, Greg KH <gregkh@linuxfoundation.org> wrote:
> >> >> > This is the start of the stable review cycle for the 3.3.2 release.
> >> >> > There are 78 patches in this series, all will be posted as a response
> >> >> > to this one.  If anyone has any issues with these being applied, please
> >> >> > let me know.
> >> >> >
> >> >> > Responses should be made by Fri Apr 13 23:10:16 UTC 2012.
> >> >> > Anything received after that time might be too late.
> >> >> >
> >> >>
> >> >> is there any chance for this one to be included in this review cycle?
> >> >>
> >> >> http://www.spinics.net/lists/linux-wireless/msg87999.html
> >>
> >> I was going to ask for exactly the same thing. My system is completely
> >> unusable without this patch; not only does the network doesn't work,
> >> but quite often the kernel is stuck consuming 100% of the CPU.
> >>
> >> > Have you read Documentation/stable_kernel_rules.txt?  Based on that, I
> >> > don't think it can, yet, right?
> >>
> >> Why not? This patch makes the code go back to a previous state, it is
> >> obviously more stable than the current state, and the code already
> >> exists in Linus's tree (in previous releases).
> >
> > It does?  What is the git commit id of the patch?  Based in the email
> > above, I assumed it had not made it to Linus's tree already.
> 
> It's a revert of c1afdaff90538ef085b756454f12b29575411214, so so just
> take a look at the code in c1afdaff90538ef085b756454f12b29575411214^.
> 
> >> But hey, I guess it's OK that 3.3.x is stuck in and endless loop right
> >> after booting, because rules are more important than fixing obvious
> >> breakage.
> >
> > What rule did you think I was saying this was not acceptable for?
> 
> The fact that the patch as not been applied/reviewed/accepted upstream.
> 
> Personally I don't see what is the problem with reverts; we already
> know the previous code was working. Sure, in theory it might behave
> different due to other changes, but that doesn't seem to be the case
> here, plus, it can't be worst than the current situation of staying in
> an endless loop.

A revert is the same as a patch.  It needs to be in Linus's tree before
I can add it to the stable releases.

greg k-h

Re: [ 00/78] 3.3.2-stable review

[Greg KH]

On Thu, Apr 12, 2012 at 04:32:40PM +0300, Felipe Contreras wrote:
> On Thu, Apr 12, 2012 at 4:13 AM, Greg KH <gregkh@linuxfoundation.org> wrote:
> > On Thu, Apr 12, 2012 at 04:03:59AM +0300, Felipe Contreras wrote:
> >> On Thu, Apr 12, 2012 at 3:29 AM, Greg KH <gregkh@linuxfoundation.org> wrote:
> >> > On Wed, Apr 11, 2012 at 07:59:14PM -0400, Sergio Correia wrote:
> >> >> Hello Greg,
> >> >>
> >> >>
> >> >> On Wed, Apr 11, 2012 at 7:11 PM, Greg KH <gregkh@linuxfoundation.org> wrote:
> >> >> > This is the start of the stable review cycle for the 3.3.2 release.
> >> >> > There are 78 patches in this series, all will be posted as a response
> >> >> > to this one. �If anyone has any issues with these being applied, please
> >> >> > let me know.
> >> >> >
> >> >> > Responses should be made by Fri Apr 13 23:10:16 UTC 2012.
> >> >> > Anything received after that time might be too late.
> >> >> >
> >> >>
> >> >> is there any chance for this one to be included in this review cycle?
> >> >>
> >> >> http://www.spinics.net/lists/linux-wireless/msg87999.html
> >>
> >> I was going to ask for exactly the same thing. My system is completely
> >> unusable without this patch; not only does the network doesn't work,
> >> but quite often the kernel is stuck consuming 100% of the CPU.
> >>
> >> > Have you read Documentation/stable_kernel_rules.txt? �Based on that, I
> >> > don't think it can, yet, right?
> >>
> >> Why not? This patch makes the code go back to a previous state, it is
> >> obviously more stable than the current state, and the code already
> >> exists in Linus's tree (in previous releases).
> >
> > It does? �What is the git commit id of the patch? �Based in the email
> > above, I assumed it had not made it to Linus's tree already.
> 
> It's a revert of c1afdaff90538ef085b756454f12b29575411214, so so just
> take a look at the code in c1afdaff90538ef085b756454f12b29575411214^.
> 
> >> But hey, I guess it's OK that 3.3.x is stuck in and endless loop right
> >> after booting, because rules are more important than fixing obvious
> >> breakage.
> >
> > What rule did you think I was saying this was not acceptable for?
> 
> The fact that the patch as not been applied/reviewed/accepted upstream.
> 
> Personally I don't see what is the problem with reverts; we already
> know the previous code was working. Sure, in theory it might behave
> different due to other changes, but that doesn't seem to be the case
> here, plus, it can't be worst than the current situation of staying in
> an endless loop.

A revert is the same as a patch.  It needs to be in Linus's tree before
I can add it to the stable releases.

greg k-h

[ath9k-devel] [ 00/78] 3.3.2-stable review

[Greg KH]

On Thu, Apr 12, 2012 at 04:32:40PM +0300, Felipe Contreras wrote:
> On Thu, Apr 12, 2012 at 4:13 AM, Greg KH <gregkh@linuxfoundation.org> wrote:
> > On Thu, Apr 12, 2012 at 04:03:59AM +0300, Felipe Contreras wrote:
> >> On Thu, Apr 12, 2012 at 3:29 AM, Greg KH <gregkh@linuxfoundation.org> wrote:
> >> > On Wed, Apr 11, 2012 at 07:59:14PM -0400, Sergio Correia wrote:
> >> >> Hello Greg,
> >> >>
> >> >>
> >> >> On Wed, Apr 11, 2012 at 7:11 PM, Greg KH <gregkh@linuxfoundation.org> wrote:
> >> >> > This is the start of the stable review cycle for the 3.3.2 release.
> >> >> > There are 78 patches in this series, all will be posted as a response
> >> >> > to this one. ?If anyone has any issues with these being applied, please
> >> >> > let me know.
> >> >> >
> >> >> > Responses should be made by Fri Apr 13 23:10:16 UTC 2012.
> >> >> > Anything received after that time might be too late.
> >> >> >
> >> >>
> >> >> is there any chance for this one to be included in this review cycle?
> >> >>
> >> >> http://www.spinics.net/lists/linux-wireless/msg87999.html
> >>
> >> I was going to ask for exactly the same thing. My system is completely
> >> unusable without this patch; not only does the network doesn't work,
> >> but quite often the kernel is stuck consuming 100% of the CPU.
> >>
> >> > Have you read Documentation/stable_kernel_rules.txt? ?Based on that, I
> >> > don't think it can, yet, right?
> >>
> >> Why not? This patch makes the code go back to a previous state, it is
> >> obviously more stable than the current state, and the code already
> >> exists in Linus's tree (in previous releases).
> >
> > It does? ?What is the git commit id of the patch? ?Based in the email
> > above, I assumed it had not made it to Linus's tree already.
> 
> It's a revert of c1afdaff90538ef085b756454f12b29575411214, so so just
> take a look at the code in c1afdaff90538ef085b756454f12b29575411214^.
> 
> >> But hey, I guess it's OK that 3.3.x is stuck in and endless loop right
> >> after booting, because rules are more important than fixing obvious
> >> breakage.
> >
> > What rule did you think I was saying this was not acceptable for?
> 
> The fact that the patch as not been applied/reviewed/accepted upstream.
> 
> Personally I don't see what is the problem with reverts; we already
> know the previous code was working. Sure, in theory it might behave
> different due to other changes, but that doesn't seem to be the case
> here, plus, it can't be worst than the current situation of staying in
> an endless loop.

A revert is the same as a patch.  It needs to be in Linus's tree before
I can add it to the stable releases.

greg k-h

Re: [ 00/78] 3.3.2-stable review

[Felipe Contreras]

On Thu, Apr 12, 2012 at 5:46 PM, Greg KH <gregkh@linuxfoundation.org> wrote:
> On Thu, Apr 12, 2012 at 04:32:40PM +0300, Felipe Contreras wrote:
>> On Thu, Apr 12, 2012 at 4:13 AM, Greg KH <gregkh@linuxfoundation.org> wrote:
>> > On Thu, Apr 12, 2012 at 04:03:59AM +0300, Felipe Contreras wrote:
>> >> On Thu, Apr 12, 2012 at 3:29 AM, Greg KH <gregkh@linuxfoundation.org> wrote:
>> >> > On Wed, Apr 11, 2012 at 07:59:14PM -0400, Sergio Correia wrote:
>> >> >> Hello Greg,
>> >> >>
>> >> >>
>> >> >> On Wed, Apr 11, 2012 at 7:11 PM, Greg KH <gregkh@linuxfoundation.org> wrote:
>> >> >> > This is the start of the stable review cycle for the 3.3.2 release.
>> >> >> > There are 78 patches in this series, all will be posted as a response
>> >> >> > to this one.  If anyone has any issues with these being applied, please
>> >> >> > let me know.
>> >> >> >
>> >> >> > Responses should be made by Fri Apr 13 23:10:16 UTC 2012.
>> >> >> > Anything received after that time might be too late.
>> >> >> >
>> >> >>
>> >> >> is there any chance for this one to be included in this review cycle?
>> >> >>
>> >> >> http://www.spinics.net/lists/linux-wireless/msg87999.html
>> >>
>> >> I was going to ask for exactly the same thing. My system is completely
>> >> unusable without this patch; not only does the network doesn't work,
>> >> but quite often the kernel is stuck consuming 100% of the CPU.
>> >>
>> >> > Have you read Documentation/stable_kernel_rules.txt?  Based on that, I
>> >> > don't think it can, yet, right?
>> >>
>> >> Why not? This patch makes the code go back to a previous state, it is
>> >> obviously more stable than the current state, and the code already
>> >> exists in Linus's tree (in previous releases).
>> >
>> > It does?  What is the git commit id of the patch?  Based in the email
>> > above, I assumed it had not made it to Linus's tree already.
>>
>> It's a revert of c1afdaff90538ef085b756454f12b29575411214, so so just
>> take a look at the code in c1afdaff90538ef085b756454f12b29575411214^.
>>
>> >> But hey, I guess it's OK that 3.3.x is stuck in and endless loop right
>> >> after booting, because rules are more important than fixing obvious
>> >> breakage.
>> >
>> > What rule did you think I was saying this was not acceptable for?
>>
>> The fact that the patch as not been applied/reviewed/accepted upstream.
>>
>> Personally I don't see what is the problem with reverts; we already
>> know the previous code was working. Sure, in theory it might behave
>> different due to other changes, but that doesn't seem to be the case
>> here, plus, it can't be worst than the current situation of staying in
>> an endless loop.
>
> A revert is the same as a patch.  It needs to be in Linus's tree before
> I can add it to the stable releases.

Right, because otherwise people's systems would actually work.

But hey, as I said, following rules is more important, regardless of
what the rules are, and why they are there. The rules that actually
triggered this issue in v3.3.1, as this is not in v3.3.

You could just accept that the patch should have never landed in
v3.3.1 in the first place, but it's much easier to arbitrarily keep
stacking patches without thinking too much about them.

I guess I'll better use Linus's releases for now and go to v3.3.

-- 
Felipe Contreras

[ath9k-devel] [ 00/78] 3.3.2-stable review

[Felipe Contreras]

On Thu, Apr 12, 2012 at 5:46 PM, Greg KH <gregkh@linuxfoundation.org> wrote:
> On Thu, Apr 12, 2012 at 04:32:40PM +0300, Felipe Contreras wrote:
>> On Thu, Apr 12, 2012 at 4:13 AM, Greg KH <gregkh@linuxfoundation.org> wrote:
>> > On Thu, Apr 12, 2012 at 04:03:59AM +0300, Felipe Contreras wrote:
>> >> On Thu, Apr 12, 2012 at 3:29 AM, Greg KH <gregkh@linuxfoundation.org> wrote:
>> >> > On Wed, Apr 11, 2012 at 07:59:14PM -0400, Sergio Correia wrote:
>> >> >> Hello Greg,
>> >> >>
>> >> >>
>> >> >> On Wed, Apr 11, 2012 at 7:11 PM, Greg KH <gregkh@linuxfoundation.org> wrote:
>> >> >> > This is the start of the stable review cycle for the 3.3.2 release.
>> >> >> > There are 78 patches in this series, all will be posted as a response
>> >> >> > to this one. ?If anyone has any issues with these being applied, please
>> >> >> > let me know.
>> >> >> >
>> >> >> > Responses should be made by Fri Apr 13 23:10:16 UTC 2012.
>> >> >> > Anything received after that time might be too late.
>> >> >> >
>> >> >>
>> >> >> is there any chance for this one to be included in this review cycle?
>> >> >>
>> >> >> http://www.spinics.net/lists/linux-wireless/msg87999.html
>> >>
>> >> I was going to ask for exactly the same thing. My system is completely
>> >> unusable without this patch; not only does the network doesn't work,
>> >> but quite often the kernel is stuck consuming 100% of the CPU.
>> >>
>> >> > Have you read Documentation/stable_kernel_rules.txt? ?Based on that, I
>> >> > don't think it can, yet, right?
>> >>
>> >> Why not? This patch makes the code go back to a previous state, it is
>> >> obviously more stable than the current state, and the code already
>> >> exists in Linus's tree (in previous releases).
>> >
>> > It does? ?What is the git commit id of the patch? ?Based in the email
>> > above, I assumed it had not made it to Linus's tree already.
>>
>> It's a revert of c1afdaff90538ef085b756454f12b29575411214, so so just
>> take a look at the code in c1afdaff90538ef085b756454f12b29575411214^.
>>
>> >> But hey, I guess it's OK that 3.3.x is stuck in and endless loop right
>> >> after booting, because rules are more important than fixing obvious
>> >> breakage.
>> >
>> > What rule did you think I was saying this was not acceptable for?
>>
>> The fact that the patch as not been applied/reviewed/accepted upstream.
>>
>> Personally I don't see what is the problem with reverts; we already
>> know the previous code was working. Sure, in theory it might behave
>> different due to other changes, but that doesn't seem to be the case
>> here, plus, it can't be worst than the current situation of staying in
>> an endless loop.
>
> A revert is the same as a patch. ?It needs to be in Linus's tree before
> I can add it to the stable releases.

Right, because otherwise people's systems would actually work.

But hey, as I said, following rules is more important, regardless of
what the rules are, and why they are there. The rules that actually
triggered this issue in v3.3.1, as this is not in v3.3.

You could just accept that the patch should have never landed in
v3.3.1 in the first place, but it's much easier to arbitrarily keep
stacking patches without thinking too much about them.

I guess I'll better use Linus's releases for now and go to v3.3.

-- 
Felipe Contreras

Re: [ 00/78] 3.3.2-stable review

[Adrian Chadd]

On 12 April 2012 09:49, Felipe Contreras <felipe.contreras@gmail.com> wrote:

>>
>> A revert is the same as a patch.  It needs to be in Linus's tree before
>> I can add it to the stable releases.
>
> Right, because otherwise people's systems would actually work.
>
> But hey, as I said, following rules is more important, regardless of
> what the rules are, and why they are there. The rules that actually
> triggered this issue in v3.3.1, as this is not in v3.3.
>
> You could just accept that the patch should have never landed in
> v3.3.1 in the first place, but it's much easier to arbitrarily keep
> stacking patches without thinking too much about them.

Greg is doing the right thing here. We face the same deal in FreeBSD -
people want fixes to go into a release branch first, but if you do
that you break the development flow - which is "stuff goes into -HEAD
and is then backported to the release branches."

If you don't do this, you risk having people do (more, all)
development and testing on a release branch and never test -HEAD (or
"upstream linux" here). Once you open that particular flood gate, it's
hard to close.

We had this problem with Squid. People ran and developed on Squid-2.4.
The head version of Squid-2 was stable, but that isn't what people ran
in production. They wanted features and bugfixes against Squid-2.2,
squid-2.4, and not Squid-2.STABLE (which at the time was
Squid-2.6/Sqiud-2.7.) That .. didn't work. Things diverged quite
quickly and it got very ugly.

So I applaud Greg for sticking to correct stable release engineering
here. We over in the BSD world know just how painful that is. :)


Adrian

Re: [ 00/78] 3.3.2-stable review

[Adrian Chadd]

On 12 April 2012 09:49, Felipe Contreras <felipe.contreras@gmail.com> wrote:

>>
>> A revert is the same as a patch. �It needs to be in Linus's tree before
>> I can add it to the stable releases.
>
> Right, because otherwise people's systems would actually work.
>
> But hey, as I said, following rules is more important, regardless of
> what the rules are, and why they are there. The rules that actually
> triggered this issue in v3.3.1, as this is not in v3.3.
>
> You could just accept that the patch should have never landed in
> v3.3.1 in the first place, but it's much easier to arbitrarily keep
> stacking patches without thinking too much about them.

Greg is doing the right thing here. We face the same deal in FreeBSD -
people want fixes to go into a release branch first, but if you do
that you break the development flow - which is "stuff goes into -HEAD
and is then backported to the release branches."

If you don't do this, you risk having people do (more, all)
development and testing on a release branch and never test -HEAD (or
"upstream linux" here). Once you open that particular flood gate, it's
hard to close.

We had this problem with Squid. People ran and developed on Squid-2.4.
The head version of Squid-2 was stable, but that isn't what people ran
in production. They wanted features and bugfixes against Squid-2.2,
squid-2.4, and not Squid-2.STABLE (which at the time was
Squid-2.6/Sqiud-2.7.) That .. didn't work. Things diverged quite
quickly and it got very ugly.

So I applaud Greg for sticking to correct stable release engineering
here. We over in the BSD world know just how painful that is. :)


Adrian

[ath9k-devel] [ 00/78] 3.3.2-stable review

[Adrian Chadd]

On 12 April 2012 09:49, Felipe Contreras <felipe.contreras@gmail.com> wrote:

>>
>> A revert is the same as a patch. ?It needs to be in Linus's tree before
>> I can add it to the stable releases.
>
> Right, because otherwise people's systems would actually work.
>
> But hey, as I said, following rules is more important, regardless of
> what the rules are, and why they are there. The rules that actually
> triggered this issue in v3.3.1, as this is not in v3.3.
>
> You could just accept that the patch should have never landed in
> v3.3.1 in the first place, but it's much easier to arbitrarily keep
> stacking patches without thinking too much about them.

Greg is doing the right thing here. We face the same deal in FreeBSD -
people want fixes to go into a release branch first, but if you do
that you break the development flow - which is "stuff goes into -HEAD
and is then backported to the release branches."

If you don't do this, you risk having people do (more, all)
development and testing on a release branch and never test -HEAD (or
"upstream linux" here). Once you open that particular flood gate, it's
hard to close.

We had this problem with Squid. People ran and developed on Squid-2.4.
The head version of Squid-2 was stable, but that isn't what people ran
in production. They wanted features and bugfixes against Squid-2.2,
squid-2.4, and not Squid-2.STABLE (which at the time was
Squid-2.6/Sqiud-2.7.) That .. didn't work. Things diverged quite
quickly and it got very ugly.

So I applaud Greg for sticking to correct stable release engineering
here. We over in the BSD world know just how painful that is. :)


Adrian

Re: [ 00/78] 3.3.2-stable review

[Willy Tarreau]

On Thu, Apr 12, 2012 at 07:49:34PM +0300, Felipe Contreras wrote:
> On Thu, Apr 12, 2012 at 5:46 PM, Greg KH <gregkh@linuxfoundation.org> wrote:
> > A revert is the same as a patch.  It needs to be in Linus's tree before
> > I can add it to the stable releases.
> 
> Right, because otherwise people's systems would actually work.
> 
> But hey, as I said, following rules is more important, regardless of
> what the rules are, and why they are there. The rules that actually
> triggered this issue in v3.3.1, as this is not in v3.3.
> 
> You could just accept that the patch should have never landed in
> v3.3.1 in the first place, but it's much easier to arbitrarily keep
> stacking patches without thinking too much about them.
> 
> I guess I'll better use Linus's releases for now and go to v3.3.

Felipe, you're unfair to Greg. You're saying this because you don't know
what it's like to be on the side of the guy who has to decide whether
to apply a patch or not, which basically means whether to risk breaking
systems or to leave broken systems as they are.

Most stable users will switch from a stable version to another one
in a next release, and these users do not want any regression. This
means that we absolutely don't want to risk that a stable version
has a fix that is missing from a newer version. Yes this is a crappy
and annoying process but it's the only way to ensure that fixes don't
get lost during an upgrade.

BTW, it works because if we're discussing this here, it's because
this final fix or revert appears to be missing from mainline. After
the discussion I'm sure it will be there.

Last point is that stable maintainers are not your slaves. If you know
how to patch your mainline kernel to apply a stable patch, you also
know how to apply the patch you're pointing to. It's quite easy and
many of us do that. *All* the kernels I'm using are stable + a few
local patches and I don't see where the problem is. So please be a bit
more constructive. Make your job by ensuring that the fix you want is
in mainline then pass the commit ID to Greg so that he can merge it in
next release. You'll feel relieved and everyone will be glad to benefit
from this fix.

Willy

Re: [ 00/78] 3.3.2-stable review

[Willy Tarreau]

On Thu, Apr 12, 2012 at 07:49:34PM +0300, Felipe Contreras wrote:
> On Thu, Apr 12, 2012 at 5:46 PM, Greg KH <gregkh@linuxfoundation.org> wrote:
> > A revert is the same as a patch. �It needs to be in Linus's tree before
> > I can add it to the stable releases.
> 
> Right, because otherwise people's systems would actually work.
> 
> But hey, as I said, following rules is more important, regardless of
> what the rules are, and why they are there. The rules that actually
> triggered this issue in v3.3.1, as this is not in v3.3.
> 
> You could just accept that the patch should have never landed in
> v3.3.1 in the first place, but it's much easier to arbitrarily keep
> stacking patches without thinking too much about them.
> 
> I guess I'll better use Linus's releases for now and go to v3.3.

Felipe, you're unfair to Greg. You're saying this because you don't know
what it's like to be on the side of the guy who has to decide whether
to apply a patch or not, which basically means whether to risk breaking
systems or to leave broken systems as they are.

Most stable users will switch from a stable version to another one
in a next release, and these users do not want any regression. This
means that we absolutely don't want to risk that a stable version
has a fix that is missing from a newer version. Yes this is a crappy
and annoying process but it's the only way to ensure that fixes don't
get lost during an upgrade.

BTW, it works because if we're discussing this here, it's because
this final fix or revert appears to be missing from mainline. After
the discussion I'm sure it will be there.

Last point is that stable maintainers are not your slaves. If you know
how to patch your mainline kernel to apply a stable patch, you also
know how to apply the patch you're pointing to. It's quite easy and
many of us do that. *All* the kernels I'm using are stable + a few
local patches and I don't see where the problem is. So please be a bit
more constructive. Make your job by ensuring that the fix you want is
in mainline then pass the commit ID to Greg so that he can merge it in
next release. You'll feel relieved and everyone will be glad to benefit
from this fix.

Willy

[ath9k-devel] [ 00/78] 3.3.2-stable review

[Willy Tarreau]

On Thu, Apr 12, 2012 at 07:49:34PM +0300, Felipe Contreras wrote:
> On Thu, Apr 12, 2012 at 5:46 PM, Greg KH <gregkh@linuxfoundation.org> wrote:
> > A revert is the same as a patch. ?It needs to be in Linus's tree before
> > I can add it to the stable releases.
> 
> Right, because otherwise people's systems would actually work.
> 
> But hey, as I said, following rules is more important, regardless of
> what the rules are, and why they are there. The rules that actually
> triggered this issue in v3.3.1, as this is not in v3.3.
> 
> You could just accept that the patch should have never landed in
> v3.3.1 in the first place, but it's much easier to arbitrarily keep
> stacking patches without thinking too much about them.
> 
> I guess I'll better use Linus's releases for now and go to v3.3.

Felipe, you're unfair to Greg. You're saying this because you don't know
what it's like to be on the side of the guy who has to decide whether
to apply a patch or not, which basically means whether to risk breaking
systems or to leave broken systems as they are.

Most stable users will switch from a stable version to another one
in a next release, and these users do not want any regression. This
means that we absolutely don't want to risk that a stable version
has a fix that is missing from a newer version. Yes this is a crappy
and annoying process but it's the only way to ensure that fixes don't
get lost during an upgrade.

BTW, it works because if we're discussing this here, it's because
this final fix or revert appears to be missing from mainline. After
the discussion I'm sure it will be there.

Last point is that stable maintainers are not your slaves. If you know
how to patch your mainline kernel to apply a stable patch, you also
know how to apply the patch you're pointing to. It's quite easy and
many of us do that. *All* the kernels I'm using are stable + a few
local patches and I don't see where the problem is. So please be a bit
more constructive. Make your job by ensuring that the fix you want is
in mainline then pass the commit ID to Greg so that he can merge it in
next release. You'll feel relieved and everyone will be glad to benefit
from this fix.

Willy

Re: [ 00/78] 3.3.2-stable review

[Felipe Contreras]

On Thu, Apr 12, 2012 at 8:24 PM, Adrian Chadd <adrian@freebsd.org> wrote:
> On 12 April 2012 09:49, Felipe Contreras <felipe.contreras@gmail.com> wrote:
>
>>>
>>> A revert is the same as a patch.  It needs to be in Linus's tree before
>>> I can add it to the stable releases.
>>
>> Right, because otherwise people's systems would actually work.
>>
>> But hey, as I said, following rules is more important, regardless of
>> what the rules are, and why they are there. The rules that actually
>> triggered this issue in v3.3.1, as this is not in v3.3.
>>
>> You could just accept that the patch should have never landed in
>> v3.3.1 in the first place, but it's much easier to arbitrarily keep
>> stacking patches without thinking too much about them.
>
> Greg is doing the right thing here. We face the same deal in FreeBSD -
> people want fixes to go into a release branch first, but if you do
> that you break the development flow - which is "stuff goes into -HEAD
> and is then backported to the release branches."
>
> If you don't do this, you risk having people do (more, all)
> development and testing on a release branch and never test -HEAD (or
> "upstream linux" here). Once you open that particular flood gate, it's
> hard to close.

But this is exactly the opposite; the patch that broke things is in
the 'release branch' (3.3.1); it's not in upstream (3.3). Sure, it's
also on a later upstream, which is also broken.

But then are you saying that if upstream is broken (3.4-rc2), then
stable should be broken as well (3.3.1), and remain broken until
upstream is fixed? I fail to see what would be the point of that.

> We had this problem with Squid. People ran and developed on Squid-2.4.
> The head version of Squid-2 was stable, but that isn't what people ran
> in production. They wanted features and bugfixes against Squid-2.2,
> squid-2.4, and not Squid-2.STABLE (which at the time was
> Squid-2.6/Sqiud-2.7.) That .. didn't work. Things diverged quite
> quickly and it got very ugly.

And why do you think the same would happen here if *one patch* is applied?

Plus, git is developed this way; and yes, you might say the gates are
opened when there's a new non-maintenance release, but the same
happens in Linux.  It's not the rule of 'first on X' branch that keeps
the gates safe; it's the amount of patches.

> So I applaud Greg for sticking to correct stable release engineering
> here. We over in the BSD world know just how painful that is. :)

So, in your mind "correct" is "never ever do an exception", even if
this strictness leads to less stability. If the objective is not
stability, I would call this the 'backports' tree then, which might or
might not lead to stability.

Rules are not perfect, why not add a new rule "It reverts an earlier
patch to 'stable'.", then you would be both following the rules, and
ensuring more stability :)

Cheers.

-- 
Felipe Contreras

[ath9k-devel] [ 00/78] 3.3.2-stable review

[Felipe Contreras]

On Thu, Apr 12, 2012 at 8:24 PM, Adrian Chadd <adrian@freebsd.org> wrote:
> On 12 April 2012 09:49, Felipe Contreras <felipe.contreras@gmail.com> wrote:
>
>>>
>>> A revert is the same as a patch. ?It needs to be in Linus's tree before
>>> I can add it to the stable releases.
>>
>> Right, because otherwise people's systems would actually work.
>>
>> But hey, as I said, following rules is more important, regardless of
>> what the rules are, and why they are there. The rules that actually
>> triggered this issue in v3.3.1, as this is not in v3.3.
>>
>> You could just accept that the patch should have never landed in
>> v3.3.1 in the first place, but it's much easier to arbitrarily keep
>> stacking patches without thinking too much about them.
>
> Greg is doing the right thing here. We face the same deal in FreeBSD -
> people want fixes to go into a release branch first, but if you do
> that you break the development flow - which is "stuff goes into -HEAD
> and is then backported to the release branches."
>
> If you don't do this, you risk having people do (more, all)
> development and testing on a release branch and never test -HEAD (or
> "upstream linux" here). Once you open that particular flood gate, it's
> hard to close.

But this is exactly the opposite; the patch that broke things is in
the 'release branch' (3.3.1); it's not in upstream (3.3). Sure, it's
also on a later upstream, which is also broken.

But then are you saying that if upstream is broken (3.4-rc2), then
stable should be broken as well (3.3.1), and remain broken until
upstream is fixed? I fail to see what would be the point of that.

> We had this problem with Squid. People ran and developed on Squid-2.4.
> The head version of Squid-2 was stable, but that isn't what people ran
> in production. They wanted features and bugfixes against Squid-2.2,
> squid-2.4, and not Squid-2.STABLE (which at the time was
> Squid-2.6/Sqiud-2.7.) That .. didn't work. Things diverged quite
> quickly and it got very ugly.

And why do you think the same would happen here if *one patch* is applied?

Plus, git is developed this way; and yes, you might say the gates are
opened when there's a new non-maintenance release, but the same
happens in Linux.  It's not the rule of 'first on X' branch that keeps
the gates safe; it's the amount of patches.

> So I applaud Greg for sticking to correct stable release engineering
> here. We over in the BSD world know just how painful that is. :)

So, in your mind "correct" is "never ever do an exception", even if
this strictness leads to less stability. If the objective is not
stability, I would call this the 'backports' tree then, which might or
might not lead to stability.

Rules are not perfect, why not add a new rule "It reverts an earlier
patch to 'stable'.", then you would be both following the rules, and
ensuring more stability :)

Cheers.

-- 
Felipe Contreras

Re: [ 00/78] 3.3.2-stable review

[Jonathan Nieder]

Felipe Contreras wrote:

> But then are you saying that if upstream is broken (3.4-rc2), then
> stable should be broken as well (3.3.1), and remain broken until
> upstream is fixed? I fail to see what would be the point of that.

No, he's saying that when upstream is broken for the same reason as
stable is, it seems wise to:

 - report upstream
 - fix your local system
 - fix any systems you are responsible for
 - fix upstream
 - only then fix stable.

That way, the user doesn't get the disconcerting experience of getting
and then losing the fix when upgrading first to the next stable
version, then to the next upstream version.

Makes sense?

Hope that helps,
Jonathan

[ath9k-devel] [ 00/78] 3.3.2-stable review

[Jonathan Nieder]

Felipe Contreras wrote:

> But then are you saying that if upstream is broken (3.4-rc2), then
> stable should be broken as well (3.3.1), and remain broken until
> upstream is fixed? I fail to see what would be the point of that.

No, he's saying that when upstream is broken for the same reason as
stable is, it seems wise to:

 - report upstream
 - fix your local system
 - fix any systems you are responsible for
 - fix upstream
 - only then fix stable.

That way, the user doesn't get the disconcerting experience of getting
and then losing the fix when upgrading first to the next stable
version, then to the next upstream version.

Makes sense?

Hope that helps,
Jonathan

Re: [ 00/78] 3.3.2-stable review

[Linus Torvalds]

On Thu, Apr 12, 2012 at 9:49 AM, Felipe Contreras
<felipe.contreras@gmail.com> wrote:
>>
>> A revert is the same as a patch.  It needs to be in Linus's tree before
>> I can add it to the stable releases.
>
> Right, because otherwise people's systems would actually work.

There are rules for a damn good reason.

The rule for -stable is that the changes *have* to be in upstream, for
a very simple reason: otherwise bugs get re-introduced.

If -stable starts revertign things that aren't reverted up-stream,
what do you think happens to the *next* kernel version?

We have those -stable rules for a very good reason - we used to not
have them, and the above "oops, we fixed it in stable, but the fix
never made it upstream" happened *all*the*time*.

I don't think you realize how well kernel development has worked over
the last few years. And the stable rules are part of it.

So stop complaining. Reverts really *are* just patches, Greg is 100%
right, and you are simply wrong.

And the revert is now apparently in John's tree, and will make it to
David and then me shortly. It will get reverted in stable too once
that happens. In the meantime, your complaints are  to Greg only shows
that you don't understand why the rules exist, and the fact that you
*continue* to complain just makes you look stupid.

                           Linus

Re: [ 00/78] 3.3.2-stable review

[Linus Torvalds]

On Thu, Apr 12, 2012 at 9:49 AM, Felipe Contreras
<felipe.contreras@gmail.com> wrote:
>>
>> A revert is the same as a patch. �It needs to be in Linus's tree before
>> I can add it to the stable releases.
>
> Right, because otherwise people's systems would actually work.

There are rules for a damn good reason.

The rule for -stable is that the changes *have* to be in upstream, for
a very simple reason: otherwise bugs get re-introduced.

If -stable starts revertign things that aren't reverted up-stream,
what do you think happens to the *next* kernel version?

We have those -stable rules for a very good reason - we used to not
have them, and the above "oops, we fixed it in stable, but the fix
never made it upstream" happened *all*the*time*.

I don't think you realize how well kernel development has worked over
the last few years. And the stable rules are part of it.

So stop complaining. Reverts really *are* just patches, Greg is 100%
right, and you are simply wrong.

And the revert is now apparently in John's tree, and will make it to
David and then me shortly. It will get reverted in stable too once
that happens. In the meantime, your complaints are  to Greg only shows
that you don't understand why the rules exist, and the fact that you
*continue* to complain just makes you look stupid.

                           Linus

[ath9k-devel] [ 00/78] 3.3.2-stable review

[Linus Torvalds]

On Thu, Apr 12, 2012 at 9:49 AM, Felipe Contreras
<felipe.contreras@gmail.com> wrote:
>>
>> A revert is the same as a patch. ?It needs to be in Linus's tree before
>> I can add it to the stable releases.
>
> Right, because otherwise people's systems would actually work.

There are rules for a damn good reason.

The rule for -stable is that the changes *have* to be in upstream, for
a very simple reason: otherwise bugs get re-introduced.

If -stable starts revertign things that aren't reverted up-stream,
what do you think happens to the *next* kernel version?

We have those -stable rules for a very good reason - we used to not
have them, and the above "oops, we fixed it in stable, but the fix
never made it upstream" happened *all*the*time*.

I don't think you realize how well kernel development has worked over
the last few years. And the stable rules are part of it.

So stop complaining. Reverts really *are* just patches, Greg is 100%
right, and you are simply wrong.

And the revert is now apparently in John's tree, and will make it to
David and then me shortly. It will get reverted in stable too once
that happens. In the meantime, your complaints are  to Greg only shows
that you don't understand why the rules exist, and the fact that you
*continue* to complain just makes you look stupid.

                           Linus

Re: [ 00/78] 3.3.2-stable review

[Alexander Holler]

Hello,

Am 12.04.2012 02:29, schrieb Greg KH:

>> is there any chance for this one to be included in this review cycle?
>>
>> http://www.spinics.net/lists/linux-wireless/msg87999.html
>
> Have you read Documentation/stable_kernel_rules.txt?  Based on that, I
> don't think it can, yet, right?

Hmm, after reading that, I think the text could need an update about how 
to submit patches written by others (which can already be found in the 
upstream tree).

At least for me the text reads like only the authors can request 
inclusion of a patch into the stable tree.

Regards,

Alexander

[ath9k-devel] [ 00/78] 3.3.2-stable review

[Alexander Holler]

Hello,

Am 12.04.2012 02:29, schrieb Greg KH:

>> is there any chance for this one to be included in this review cycle?
>>
>> http://www.spinics.net/lists/linux-wireless/msg87999.html
>
> Have you read Documentation/stable_kernel_rules.txt?  Based on that, I
> don't think it can, yet, right?

Hmm, after reading that, I think the text could need an update about how 
to submit patches written by others (which can already be found in the 
upstream tree).

At least for me the text reads like only the authors can request 
inclusion of a patch into the stable tree.

Regards,

Alexander

Re: [ 00/78] 3.3.2-stable review

[Greg KH]

On Thu, Apr 12, 2012 at 09:57:53PM +0200, Alexander Holler wrote:
> Hello,
> 
> Am 12.04.2012 02:29, schrieb Greg KH:
> 
> >>is there any chance for this one to be included in this review cycle?
> >>
> >>http://www.spinics.net/lists/linux-wireless/msg87999.html
> >
> >Have you read Documentation/stable_kernel_rules.txt?  Based on that, I
> >don't think it can, yet, right?
> 
> Hmm, after reading that, I think the text could need an update about
> how to submit patches written by others (which can already be found
> in the upstream tree).
> 
> At least for me the text reads like only the authors can request
> inclusion of a patch into the stable tree.

Patches are always welcome, but I think you will find the file already
describes this (hint, the first '-' line for the Procedure section
handles it).

greg k-h

[ath9k-devel] [ 00/78] 3.3.2-stable review

[Greg KH]

On Thu, Apr 12, 2012 at 09:57:53PM +0200, Alexander Holler wrote:
> Hello,
> 
> Am 12.04.2012 02:29, schrieb Greg KH:
> 
> >>is there any chance for this one to be included in this review cycle?
> >>
> >>http://www.spinics.net/lists/linux-wireless/msg87999.html
> >
> >Have you read Documentation/stable_kernel_rules.txt?  Based on that, I
> >don't think it can, yet, right?
> 
> Hmm, after reading that, I think the text could need an update about
> how to submit patches written by others (which can already be found
> in the upstream tree).
> 
> At least for me the text reads like only the authors can request
> inclusion of a patch into the stable tree.

Patches are always welcome, but I think you will find the file already
describes this (hint, the first '-' line for the Procedure section
handles it).

greg k-h

Re: [ 00/78] 3.3.2-stable review

[Greg KH]

On Thu, Apr 12, 2012 at 09:43:33PM +0300, Felipe Contreras wrote:
> On Thu, Apr 12, 2012 at 8:24 PM, Adrian Chadd <adrian@freebsd.org> wrote:
> > On 12 April 2012 09:49, Felipe Contreras <felipe.contreras@gmail.com> wrote:
> >
> >>>
> >>> A revert is the same as a patch.  It needs to be in Linus's tree before
> >>> I can add it to the stable releases.
> >>
> >> Right, because otherwise people's systems would actually work.
> >>
> >> But hey, as I said, following rules is more important, regardless of
> >> what the rules are, and why they are there. The rules that actually
> >> triggered this issue in v3.3.1, as this is not in v3.3.
> >>
> >> You could just accept that the patch should have never landed in
> >> v3.3.1 in the first place, but it's much easier to arbitrarily keep
> >> stacking patches without thinking too much about them.
> >
> > Greg is doing the right thing here. We face the same deal in FreeBSD -
> > people want fixes to go into a release branch first, but if you do
> > that you break the development flow - which is "stuff goes into -HEAD
> > and is then backported to the release branches."
> >
> > If you don't do this, you risk having people do (more, all)
> > development and testing on a release branch and never test -HEAD (or
> > "upstream linux" here). Once you open that particular flood gate, it's
> > hard to close.
> 
> But this is exactly the opposite; the patch that broke things is in
> the 'release branch' (3.3.1); it's not in upstream (3.3). Sure, it's
> also on a later upstream, which is also broken.

What is the git commit id of the patch in 3.3.1 that caused this to
break?  This is the first time I have heard that 3.3 worked and 3.3.1
did not work.  Someone needs to tell me these things...

greg k-h

Re: [ 00/78] 3.3.2-stable review

[Greg KH]

On Thu, Apr 12, 2012 at 09:43:33PM +0300, Felipe Contreras wrote:
> On Thu, Apr 12, 2012 at 8:24 PM, Adrian Chadd <adrian@freebsd.org> wrote:
> > On 12 April 2012 09:49, Felipe Contreras <felipe.contreras@gmail.com> wrote:
> >
> >>>
> >>> A revert is the same as a patch. �It needs to be in Linus's tree before
> >>> I can add it to the stable releases.
> >>
> >> Right, because otherwise people's systems would actually work.
> >>
> >> But hey, as I said, following rules is more important, regardless of
> >> what the rules are, and why they are there. The rules that actually
> >> triggered this issue in v3.3.1, as this is not in v3.3.
> >>
> >> You could just accept that the patch should have never landed in
> >> v3.3.1 in the first place, but it's much easier to arbitrarily keep
> >> stacking patches without thinking too much about them.
> >
> > Greg is doing the right thing here. We face the same deal in FreeBSD -
> > people want fixes to go into a release branch first, but if you do
> > that you break the development flow - which is "stuff goes into -HEAD
> > and is then backported to the release branches."
> >
> > If you don't do this, you risk having people do (more, all)
> > development and testing on a release branch and never test -HEAD (or
> > "upstream linux" here). Once you open that particular flood gate, it's
> > hard to close.
> 
> But this is exactly the opposite; the patch that broke things is in
> the 'release branch' (3.3.1); it's not in upstream (3.3). Sure, it's
> also on a later upstream, which is also broken.

What is the git commit id of the patch in 3.3.1 that caused this to
break?  This is the first time I have heard that 3.3 worked and 3.3.1
did not work.  Someone needs to tell me these things...

greg k-h

[ath9k-devel] [ 00/78] 3.3.2-stable review

[Greg KH]

On Thu, Apr 12, 2012 at 09:43:33PM +0300, Felipe Contreras wrote:
> On Thu, Apr 12, 2012 at 8:24 PM, Adrian Chadd <adrian@freebsd.org> wrote:
> > On 12 April 2012 09:49, Felipe Contreras <felipe.contreras@gmail.com> wrote:
> >
> >>>
> >>> A revert is the same as a patch. ?It needs to be in Linus's tree before
> >>> I can add it to the stable releases.
> >>
> >> Right, because otherwise people's systems would actually work.
> >>
> >> But hey, as I said, following rules is more important, regardless of
> >> what the rules are, and why they are there. The rules that actually
> >> triggered this issue in v3.3.1, as this is not in v3.3.
> >>
> >> You could just accept that the patch should have never landed in
> >> v3.3.1 in the first place, but it's much easier to arbitrarily keep
> >> stacking patches without thinking too much about them.
> >
> > Greg is doing the right thing here. We face the same deal in FreeBSD -
> > people want fixes to go into a release branch first, but if you do
> > that you break the development flow - which is "stuff goes into -HEAD
> > and is then backported to the release branches."
> >
> > If you don't do this, you risk having people do (more, all)
> > development and testing on a release branch and never test -HEAD (or
> > "upstream linux" here). Once you open that particular flood gate, it's
> > hard to close.
> 
> But this is exactly the opposite; the patch that broke things is in
> the 'release branch' (3.3.1); it's not in upstream (3.3). Sure, it's
> also on a later upstream, which is also broken.

What is the git commit id of the patch in 3.3.1 that caused this to
break?  This is the first time I have heard that 3.3 worked and 3.3.1
did not work.  Someone needs to tell me these things...

greg k-h

Re: [ 00/78] 3.3.2-stable review

[Alexander Holler]

Am 12.04.2012 22:06, schrieb Greg KH:
> On Thu, Apr 12, 2012 at 09:57:53PM +0200, Alexander Holler wrote:
>> Hello,
>>
>> Am 12.04.2012 02:29, schrieb Greg KH:
>>
>>>> is there any chance for this one to be included in this review cycle?
>>>>
>>>> http://www.spinics.net/lists/linux-wireless/msg87999.html
>>>
>>> Have you read Documentation/stable_kernel_rules.txt?  Based on that, I
>>> don't think it can, yet, right?
>>
>> Hmm, after reading that, I think the text could need an update about
>> how to submit patches written by others (which can already be found
>> in the upstream tree).
>>
>> At least for me the text reads like only the authors can request
>> inclusion of a patch into the stable tree.
>
> Patches are always welcome, but I think you will find the file already
> describes this (hint, the first '-' line for the Procedure section
> handles it).

That reads:

"- Send the patch, after verifying that it follows the above rules, to
    stable@vger.kernel.org.  You must note the upstream commit ID in the
    changelog of your submission, as well as the kernel version you wish
    it to be applied to."

Maybe I'm a bit dumb, but what would be my changelog if the patch was 
written by someone else (and e.g. fixes something the author wasn't 
aware of or hasn't described)?

Sorry, but I don't understand "changelog" in that context. Should I 
modify the (description of the) patch?

Regards,

Alexander

[ath9k-devel] [ 00/78] 3.3.2-stable review

[Alexander Holler]

Am 12.04.2012 22:06, schrieb Greg KH:
> On Thu, Apr 12, 2012 at 09:57:53PM +0200, Alexander Holler wrote:
>> Hello,
>>
>> Am 12.04.2012 02:29, schrieb Greg KH:
>>
>>>> is there any chance for this one to be included in this review cycle?
>>>>
>>>> http://www.spinics.net/lists/linux-wireless/msg87999.html
>>>
>>> Have you read Documentation/stable_kernel_rules.txt?  Based on that, I
>>> don't think it can, yet, right?
>>
>> Hmm, after reading that, I think the text could need an update about
>> how to submit patches written by others (which can already be found
>> in the upstream tree).
>>
>> At least for me the text reads like only the authors can request
>> inclusion of a patch into the stable tree.
>
> Patches are always welcome, but I think you will find the file already
> describes this (hint, the first '-' line for the Procedure section
> handles it).

That reads:

"- Send the patch, after verifying that it follows the above rules, to
    stable at vger.kernel.org.  You must note the upstream commit ID in the
    changelog of your submission, as well as the kernel version you wish
    it to be applied to."

Maybe I'm a bit dumb, but what would be my changelog if the patch was 
written by someone else (and e.g. fixes something the author wasn't 
aware of or hasn't described)?

Sorry, but I don't understand "changelog" in that context. Should I 
modify the (description of the) patch?

Regards,

Alexander

Re: [ 00/78] 3.3.2-stable review

[Sven-Haegar Koch]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 2117 bytes --]

On Thu, 12 Apr 2012, Greg KH wrote:

> On Thu, Apr 12, 2012 at 09:43:33PM +0300, Felipe Contreras wrote:
> > On Thu, Apr 12, 2012 at 8:24 PM, Adrian Chadd <adrian@freebsd.org> wrote:
> > > On 12 April 2012 09:49, Felipe Contreras <felipe.contreras@gmail.com> wrote:
> > >
> > >>>
> > >>> A revert is the same as a patch.  It needs to be in Linus's tree before
> > >>> I can add it to the stable releases.
> > >>
> > >> Right, because otherwise people's systems would actually work.
> > >>
> > >> But hey, as I said, following rules is more important, regardless of
> > >> what the rules are, and why they are there. The rules that actually
> > >> triggered this issue in v3.3.1, as this is not in v3.3.
> > >>
> > >> You could just accept that the patch should have never landed in
> > >> v3.3.1 in the first place, but it's much easier to arbitrarily keep
> > >> stacking patches without thinking too much about them.
> > >
> > > Greg is doing the right thing here. We face the same deal in FreeBSD -
> > > people want fixes to go into a release branch first, but if you do
> > > that you break the development flow - which is "stuff goes into -HEAD
> > > and is then backported to the release branches."
> > >
> > > If you don't do this, you risk having people do (more, all)
> > > development and testing on a release branch and never test -HEAD (or
> > > "upstream linux" here). Once you open that particular flood gate, it's
> > > hard to close.
> > 
> > But this is exactly the opposite; the patch that broke things is in
> > the 'release branch' (3.3.1); it's not in upstream (3.3). Sure, it's
> > also on a later upstream, which is also broken.
> 
> What is the git commit id of the patch in 3.3.1 that caused this to
> break?  This is the first time I have heard that 3.3 worked and 3.3.1
> did not work.  Someone needs to tell me these things...

Should be

db6a6a78d8602964c9dfb1d8ce18daefd92da0a7 in stable/linux-3.3.y
c1afdaff90538ef085b756454f12b29575411214 in linux/master

c'ya
sven-haegar

-- 
Three may keep a secret, if two of them are dead.
- Ben F.

[ath9k-devel] [ 00/78] 3.3.2-stable review

[Sven-Haegar Koch]

On Thu, 12 Apr 2012, Greg KH wrote:

> On Thu, Apr 12, 2012 at 09:43:33PM +0300, Felipe Contreras wrote:
> > On Thu, Apr 12, 2012 at 8:24 PM, Adrian Chadd <adrian@freebsd.org> wrote:
> > > On 12 April 2012 09:49, Felipe Contreras <felipe.contreras@gmail.com> wrote:
> > >
> > >>>
> > >>> A revert is the same as a patch. ?It needs to be in Linus's tree before
> > >>> I can add it to the stable releases.
> > >>
> > >> Right, because otherwise people's systems would actually work.
> > >>
> > >> But hey, as I said, following rules is more important, regardless of
> > >> what the rules are, and why they are there. The rules that actually
> > >> triggered this issue in v3.3.1, as this is not in v3.3.
> > >>
> > >> You could just accept that the patch should have never landed in
> > >> v3.3.1 in the first place, but it's much easier to arbitrarily keep
> > >> stacking patches without thinking too much about them.
> > >
> > > Greg is doing the right thing here. We face the same deal in FreeBSD -
> > > people want fixes to go into a release branch first, but if you do
> > > that you break the development flow - which is "stuff goes into -HEAD
> > > and is then backported to the release branches."
> > >
> > > If you don't do this, you risk having people do (more, all)
> > > development and testing on a release branch and never test -HEAD (or
> > > "upstream linux" here). Once you open that particular flood gate, it's
> > > hard to close.
> > 
> > But this is exactly the opposite; the patch that broke things is in
> > the 'release branch' (3.3.1); it's not in upstream (3.3). Sure, it's
> > also on a later upstream, which is also broken.
> 
> What is the git commit id of the patch in 3.3.1 that caused this to
> break?  This is the first time I have heard that 3.3 worked and 3.3.1
> did not work.  Someone needs to tell me these things...

Should be

db6a6a78d8602964c9dfb1d8ce18daefd92da0a7 in stable/linux-3.3.y
c1afdaff90538ef085b756454f12b29575411214 in linux/master

c'ya
sven-haegar

-- 
Three may keep a secret, if two of them are dead.
- Ben F.

Re: [ 00/78] 3.3.2-stable review

[Felipe Contreras]

On Thu, Apr 12, 2012 at 10:05 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> On Thu, Apr 12, 2012 at 9:49 AM, Felipe Contreras
> <felipe.contreras@gmail.com> wrote:
>>>
>>> A revert is the same as a patch.  It needs to be in Linus's tree before
>>> I can add it to the stable releases.
>>
>> Right, because otherwise people's systems would actually work.
>
> There are rules for a damn good reason.
>
> The rule for -stable is that the changes *have* to be in upstream, for
> a very simple reason: otherwise bugs get re-introduced.
>
> If -stable starts revertign things that aren't reverted up-stream,
> what do you think happens to the *next* kernel version?

Which is why nobody is trying to change the rules regarding that.

And your same argument applies to the all the thousands of commits on
the next kernel version; what would happen on the next kernel version?

The relevant patch, like the thousands of patches in v3.4-rc*, did not
exist in v3.3, so if you add one on v3.3.1, and remove it on v3.3.2
would be *exactly* the same as if you had not added it at all to the
stable series.

> I don't think you realize how well kernel development has worked over
> the last few years. And the stable rules are part of it.

I do understand how well the development works, which is why I often
use it as an example and guideline, but that doesn't mean it's
perfect.

> So stop complaining. Reverts really *are* just patches, Greg is 100%
> right, and you are simply wrong.

I could argue in favor of exceptions, but I don't think you realize
the fact that this change does not affect your tree *at all*. Adding
and removing a patch in the stable tree is a no-op.

> And the revert is now apparently in John's tree, and will make it to
> David and then me shortly. It will get reverted in stable too once
> that happens. In the meantime, your complaints are  to Greg only shows
> that you don't understand why the rules exist, and the fact that you
> *continue* to complain just makes you look stupid.

Is that going to happen before Friday? If not, then v3.3.2 will still
be broken *for no reason*.

-- 
Felipe Contreras

[ath9k-devel] [ 00/78] 3.3.2-stable review

[Felipe Contreras]

On Thu, Apr 12, 2012 at 10:05 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> On Thu, Apr 12, 2012 at 9:49 AM, Felipe Contreras
> <felipe.contreras@gmail.com> wrote:
>>>
>>> A revert is the same as a patch. ?It needs to be in Linus's tree before
>>> I can add it to the stable releases.
>>
>> Right, because otherwise people's systems would actually work.
>
> There are rules for a damn good reason.
>
> The rule for -stable is that the changes *have* to be in upstream, for
> a very simple reason: otherwise bugs get re-introduced.
>
> If -stable starts revertign things that aren't reverted up-stream,
> what do you think happens to the *next* kernel version?

Which is why nobody is trying to change the rules regarding that.

And your same argument applies to the all the thousands of commits on
the next kernel version; what would happen on the next kernel version?

The relevant patch, like the thousands of patches in v3.4-rc*, did not
exist in v3.3, so if you add one on v3.3.1, and remove it on v3.3.2
would be *exactly* the same as if you had not added it at all to the
stable series.

> I don't think you realize how well kernel development has worked over
> the last few years. And the stable rules are part of it.

I do understand how well the development works, which is why I often
use it as an example and guideline, but that doesn't mean it's
perfect.

> So stop complaining. Reverts really *are* just patches, Greg is 100%
> right, and you are simply wrong.

I could argue in favor of exceptions, but I don't think you realize
the fact that this change does not affect your tree *at all*. Adding
and removing a patch in the stable tree is a no-op.

> And the revert is now apparently in John's tree, and will make it to
> David and then me shortly. It will get reverted in stable too once
> that happens. In the meantime, your complaints are ?to Greg only shows
> that you don't understand why the rules exist, and the fact that you
> *continue* to complain just makes you look stupid.

Is that going to happen before Friday? If not, then v3.3.2 will still
be broken *for no reason*.

-- 
Felipe Contreras

Re: [ 00/78] 3.3.2-stable review

[Linus Torvalds]

On Thu, Apr 12, 2012 at 2:20 PM, Felipe Contreras
<felipe.contreras@gmail.com> wrote:
>
> I could argue in favor of exceptions, but I don't think you realize
> the fact that this change does not affect your tree *at all*. Adding
> and removing a patch in the stable tree is a no-op.

You're a fucking moron.

It's not a no-op at all, and you don't seem to understand it.

It's *information*.

It's "that patch didn't work". That's not a no-op. That's actual
useful and worthwhile knowledge.

To quote Thomas Edison: "I have not failed. I've just found 10,000
ways that won't work."

So just reverting it from stable, *WITHOUT LEARNING THE LESSON*, is
not a no-op at all, it's a sign of being a f*cking moron.

I'm stupider for just reading your email. Go away.

                    Linus

[ath9k-devel] [ 00/78] 3.3.2-stable review

[Linus Torvalds]

On Thu, Apr 12, 2012 at 2:20 PM, Felipe Contreras
<felipe.contreras@gmail.com> wrote:
>
> I could argue in favor of exceptions, but I don't think you realize
> the fact that this change does not affect your tree *at all*. Adding
> and removing a patch in the stable tree is a no-op.

You're a fucking moron.

It's not a no-op at all, and you don't seem to understand it.

It's *information*.

It's "that patch didn't work". That's not a no-op. That's actual
useful and worthwhile knowledge.

To quote Thomas Edison: "I have not failed. I've just found 10,000
ways that won't work."

So just reverting it from stable, *WITHOUT LEARNING THE LESSON*, is
not a no-op at all, it's a sign of being a f*cking moron.

I'm stupider for just reading your email. Go away.

                    Linus

Re: [ 00/78] 3.3.2-stable review

[Felipe Contreras]

On Thu, Apr 12, 2012 at 9:56 PM, Jonathan Nieder <jrnieder@gmail.com> wrote:
> Felipe Contreras wrote:
>
>> But then are you saying that if upstream is broken (3.4-rc2), then
>> stable should be broken as well (3.3.1), and remain broken until
>> upstream is fixed? I fail to see what would be the point of that.
>
> No, he's saying that when upstream is broken for the same reason as
> stable is, it seems wise to:
>
>  - report upstream
>  - fix your local system
>  - fix any systems you are responsible for
>  - fix upstream
>  - only then fix stable.

I'm not sure those steps were followed for this particular patch on
v3.3.1, but lets assume they where. Now what happens when:

 - you realize the fix made matters worst, in fact, so worst that the
whole thing is unusable in some systems

Presumably we are now in the next round of:

 - fix upstream

But v.3.3.2 is due Friday, which makes it very likely that the fix
won't get in. And what did we gain? If you simplify the situation to
what you explained above, it seems very reasonable, but that's not the
whole picture.

-- 
Felipe Contreras

[ath9k-devel] [ 00/78] 3.3.2-stable review

[Felipe Contreras]

On Thu, Apr 12, 2012 at 9:56 PM, Jonathan Nieder <jrnieder@gmail.com> wrote:
> Felipe Contreras wrote:
>
>> But then are you saying that if upstream is broken (3.4-rc2), then
>> stable should be broken as well (3.3.1), and remain broken until
>> upstream is fixed? I fail to see what would be the point of that.
>
> No, he's saying that when upstream is broken for the same reason as
> stable is, it seems wise to:
>
> ?- report upstream
> ?- fix your local system
> ?- fix any systems you are responsible for
> ?- fix upstream
> ?- only then fix stable.

I'm not sure those steps were followed for this particular patch on
v3.3.1, but lets assume they where. Now what happens when:

 - you realize the fix made matters worst, in fact, so worst that the
whole thing is unusable in some systems

Presumably we are now in the next round of:

 - fix upstream

But v.3.3.2 is due Friday, which makes it very likely that the fix
won't get in. And what did we gain? If you simplify the situation to
what you explained above, it seems very reasonable, but that's not the
whole picture.

-- 
Felipe Contreras

Re: [ 00/78] 3.3.2-stable review

[Willy Tarreau]

On Fri, Apr 13, 2012 at 12:20:20AM +0300, Felipe Contreras wrote:
> The relevant patch, like the thousands of patches in v3.4-rc*, did not
> exist in v3.3, so if you add one on v3.3.1, and remove it on v3.3.2
> would be *exactly* the same as if you had not added it at all to the
> stable series.

Except that thanks to its addition in 3.3.1 we know it has broken some
setups. Now we know they're broken, there is a good reason to *ensure*
it is removed in 3.4-rc too. If you revert it from 3.3.2 and forget about
3.4-rc, you'll end up with the faulty patch present again in 3.4. It is
*very* important that -stable reflects what next should look like.

The only frustration from you that I can understand comes from the
multi-hop that the patch has to pass through before hitting Linus,
but for the same reason you want every intermediary maintainer to
ensure that his own tree is fixed so that the patch is not reintroduced
in a future batch.

Again, why don't you apply it into your tree ? Better, fork 3.3-stable
and announce 3.3.2-fc which has this patch. It will help other users too.
Let's just see how long you keep up with out-of-sync fixes.

Regards,
Willy

[ath9k-devel] [ 00/78] 3.3.2-stable review

[Willy Tarreau]

On Fri, Apr 13, 2012 at 12:20:20AM +0300, Felipe Contreras wrote:
> The relevant patch, like the thousands of patches in v3.4-rc*, did not
> exist in v3.3, so if you add one on v3.3.1, and remove it on v3.3.2
> would be *exactly* the same as if you had not added it at all to the
> stable series.

Except that thanks to its addition in 3.3.1 we know it has broken some
setups. Now we know they're broken, there is a good reason to *ensure*
it is removed in 3.4-rc too. If you revert it from 3.3.2 and forget about
3.4-rc, you'll end up with the faulty patch present again in 3.4. It is
*very* important that -stable reflects what next should look like.

The only frustration from you that I can understand comes from the
multi-hop that the patch has to pass through before hitting Linus,
but for the same reason you want every intermediary maintainer to
ensure that his own tree is fixed so that the patch is not reintroduced
in a future batch.

Again, why don't you apply it into your tree ? Better, fork 3.3-stable
and announce 3.3.2-fc which has this patch. It will help other users too.
Let's just see how long you keep up with out-of-sync fixes.

Regards,
Willy

Re: [ 00/78] 3.3.2-stable review

[Willy Tarreau]

On Fri, Apr 13, 2012 at 12:34:59AM +0300, Felipe Contreras wrote:
> Now what happens when:
> 
>  - you realize the fix made matters worst, in fact, so worst that the
> whole thing is unusable in some systems
> 
> Presumably we are now in the next round of:
> 
>  - fix upstream
> 
> But v.3.3.2 is due Friday, which makes it very likely that the fix
> won't get in. And what did we gain? If you simplify the situation to
> what you explained above, it seems very reasonable, but that's not the
> whole picture.

BTW, if you're so in need for critical fixes, why do you jump to the latest
version ? It's known and accepted that stable versions stabilize over time
with a few random hiccups during their early stage. You could have chosen
3.0 instead which generally holds some fixes that cooked longer before being
merged.

There's a cost at living on the bleeding edge. It's fun and sometimes it
hurts but that should not be that dramatic that you spend so many emails
telling how stable releases should be maintained.

Willy

[ath9k-devel] [ 00/78] 3.3.2-stable review

[Willy Tarreau]

On Fri, Apr 13, 2012 at 12:34:59AM +0300, Felipe Contreras wrote:
> Now what happens when:
> 
>  - you realize the fix made matters worst, in fact, so worst that the
> whole thing is unusable in some systems
> 
> Presumably we are now in the next round of:
> 
>  - fix upstream
> 
> But v.3.3.2 is due Friday, which makes it very likely that the fix
> won't get in. And what did we gain? If you simplify the situation to
> what you explained above, it seems very reasonable, but that's not the
> whole picture.

BTW, if you're so in need for critical fixes, why do you jump to the latest
version ? It's known and accepted that stable versions stabilize over time
with a few random hiccups during their early stage. You could have chosen
3.0 instead which generally holds some fixes that cooked longer before being
merged.

There's a cost at living on the bleeding edge. It's fun and sometimes it
hurts but that should not be that dramatic that you spend so many emails
telling how stable releases should be maintained.

Willy

Re: [ 00/78] 3.3.2-stable review

[Linus Torvalds]

On Thu, Apr 12, 2012 at 2:34 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> So just reverting it from stable, *WITHOUT LEARNING THE LESSON*, is
> not a no-op at all, it's a sign of being a f*cking moron.

Btw, the revert is now in my tree (commit 011afa1ed8c4), and marked
for stable. So *now* Greg can revert it from stable too.

But the important lesson to everybody should be that "we don't lose
fixes from -stable". If a problem was found in stable, it needs to be
fixed upstream. In fact, quite often people *do* find problems in
stable, because it tends to have more users more quickly than
mainline. That makes it really really important to make sure that
those problems get fixed upstream, and not hidden in stable due to
some kind of dieseased "it's a no-op to revert it" thinking.

End of story.

                    Linus

[ath9k-devel] [ 00/78] 3.3.2-stable review

[Linus Torvalds]

On Thu, Apr 12, 2012 at 2:34 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> So just reverting it from stable, *WITHOUT LEARNING THE LESSON*, is
> not a no-op at all, it's a sign of being a f*cking moron.

Btw, the revert is now in my tree (commit 011afa1ed8c4), and marked
for stable. So *now* Greg can revert it from stable too.

But the important lesson to everybody should be that "we don't lose
fixes from -stable". If a problem was found in stable, it needs to be
fixed upstream. In fact, quite often people *do* find problems in
stable, because it tends to have more users more quickly than
mainline. That makes it really really important to make sure that
those problems get fixed upstream, and not hidden in stable due to
some kind of dieseased "it's a no-op to revert it" thinking.

End of story.

                    Linus

Re: [ 00/78] 3.3.2-stable review

[Jesper Juhl]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 3709 bytes --]

On Fri, 13 Apr 2012, Felipe Contreras wrote:

> On Thu, Apr 12, 2012 at 10:05 PM, Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
> > On Thu, Apr 12, 2012 at 9:49 AM, Felipe Contreras
> > <felipe.contreras@gmail.com> wrote:
> >>>
> >>> A revert is the same as a patch.  It needs to be in Linus's tree before
> >>> I can add it to the stable releases.
> >>
> >> Right, because otherwise people's systems would actually work.
> >
> > There are rules for a damn good reason.
> >
> > The rule for -stable is that the changes *have* to be in upstream, for
> > a very simple reason: otherwise bugs get re-introduced.
> >
> > If -stable starts revertign things that aren't reverted up-stream,
> > what do you think happens to the *next* kernel version?
> 
> Which is why nobody is trying to change the rules regarding that.
> 
> And your same argument applies to the all the thousands of commits on
> the next kernel version; what would happen on the next kernel version?
> 
> The relevant patch, like the thousands of patches in v3.4-rc*, did not
> exist in v3.3, so if you add one on v3.3.1, and remove it on v3.3.2
> would be *exactly* the same as if you had not added it at all to the
> stable series.
> 
> > I don't think you realize how well kernel development has worked over
> > the last few years. And the stable rules are part of it.
> 
> I do understand how well the development works, which is why I often
> use it as an example and guideline, but that doesn't mean it's
> perfect.
> 
> > So stop complaining. Reverts really *are* just patches, Greg is 100%
> > right, and you are simply wrong.
> 
> I could argue in favor of exceptions, but I don't think you realize
> the fact that this change does not affect your tree *at all*. Adding
> and removing a patch in the stable tree is a no-op.
> 
> > And the revert is now apparently in John's tree, and will make it to
> > David and then me shortly. It will get reverted in stable too once
> > that happens. In the meantime, your complaints are  to Greg only shows
> > that you don't understand why the rules exist, and the fact that you
> > *continue* to complain just makes you look stupid.
> 
> Is that going to happen before Friday? If not, then v3.3.2 will still
> be broken *for no reason*.
> 
> 

Ok, -stable got broken because a bad patch was backported from mainline to 
stable - obviously that's not good.

But, just reverting that broken patch from stable is *not* good enough. 
Then we still have a broken mainline.

The rule that only commits which are in mainline get applied to -stable 
makes really, Really, REALLY good sense. It helps ensure that we don't 
miss fixes going forward.

Imagine that bad patch xyz got added to mainline and backported to stable 
and that the only people that get bitten by it are conservative types that 
only run -stable kernels. Then we revert the patch from stable since it 
broke stuff and now everyone are happy - but *mainline is still broken* 
and there's noone pushing for the problem to get fixed in mainline since 
noone affected by the problem run that kernel :-(

By insisting that only patches in mainline get backported to -stable we 
ensure that both mainline and stable get fixed (and thus also the *next* 
stable kernel that'll be cut from mainline in the future).

Yes it's a pain that -stable has to suffer a broken commit for a while - 
but sometimes that's just the little pain you have to accept. The greater 
good is that with the current rules both mainline, current -stable and 
future -stable will get fixed.

-- 
Jesper Juhl <jj@chaosbits.net>       http://www.chaosbits.net/
Don't top-post http://www.catb.org/jargon/html/T/top-post.html
Plain text mails only, please.

[ath9k-devel] [ 00/78] 3.3.2-stable review

[Jesper Juhl]

On Fri, 13 Apr 2012, Felipe Contreras wrote:

> On Thu, Apr 12, 2012 at 10:05 PM, Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
> > On Thu, Apr 12, 2012 at 9:49 AM, Felipe Contreras
> > <felipe.contreras@gmail.com> wrote:
> >>>
> >>> A revert is the same as a patch. ?It needs to be in Linus's tree before
> >>> I can add it to the stable releases.
> >>
> >> Right, because otherwise people's systems would actually work.
> >
> > There are rules for a damn good reason.
> >
> > The rule for -stable is that the changes *have* to be in upstream, for
> > a very simple reason: otherwise bugs get re-introduced.
> >
> > If -stable starts revertign things that aren't reverted up-stream,
> > what do you think happens to the *next* kernel version?
> 
> Which is why nobody is trying to change the rules regarding that.
> 
> And your same argument applies to the all the thousands of commits on
> the next kernel version; what would happen on the next kernel version?
> 
> The relevant patch, like the thousands of patches in v3.4-rc*, did not
> exist in v3.3, so if you add one on v3.3.1, and remove it on v3.3.2
> would be *exactly* the same as if you had not added it at all to the
> stable series.
> 
> > I don't think you realize how well kernel development has worked over
> > the last few years. And the stable rules are part of it.
> 
> I do understand how well the development works, which is why I often
> use it as an example and guideline, but that doesn't mean it's
> perfect.
> 
> > So stop complaining. Reverts really *are* just patches, Greg is 100%
> > right, and you are simply wrong.
> 
> I could argue in favor of exceptions, but I don't think you realize
> the fact that this change does not affect your tree *at all*. Adding
> and removing a patch in the stable tree is a no-op.
> 
> > And the revert is now apparently in John's tree, and will make it to
> > David and then me shortly. It will get reverted in stable too once
> > that happens. In the meantime, your complaints are ?to Greg only shows
> > that you don't understand why the rules exist, and the fact that you
> > *continue* to complain just makes you look stupid.
> 
> Is that going to happen before Friday? If not, then v3.3.2 will still
> be broken *for no reason*.
> 
> 

Ok, -stable got broken because a bad patch was backported from mainline to 
stable - obviously that's not good.

But, just reverting that broken patch from stable is *not* good enough. 
Then we still have a broken mainline.

The rule that only commits which are in mainline get applied to -stable 
makes really, Really, REALLY good sense. It helps ensure that we don't 
miss fixes going forward.

Imagine that bad patch xyz got added to mainline and backported to stable 
and that the only people that get bitten by it are conservative types that 
only run -stable kernels. Then we revert the patch from stable since it 
broke stuff and now everyone are happy - but *mainline is still broken* 
and there's noone pushing for the problem to get fixed in mainline since 
noone affected by the problem run that kernel :-(

By insisting that only patches in mainline get backported to -stable we 
ensure that both mainline and stable get fixed (and thus also the *next* 
stable kernel that'll be cut from mainline in the future).

Yes it's a pain that -stable has to suffer a broken commit for a while - 
but sometimes that's just the little pain you have to accept. The greater 
good is that with the current rules both mainline, current -stable and 
future -stable will get fixed.

-- 
Jesper Juhl <jj@chaosbits.net>       http://www.chaosbits.net/
Don't top-post http://www.catb.org/jargon/html/T/top-post.html
Plain text mails only, please.

Re: [ath9k-devel] [ 00/78] 3.3.2-stable review

[Luis R. Rodriguez]

On Thu, Apr 12, 2012 at 2:44 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> On Thu, Apr 12, 2012 at 2:34 PM, Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
>>
>> So just reverting it from stable, *WITHOUT LEARNING THE LESSON*, is
>> not a no-op at all, it's a sign of being a f*cking moron.
>
> Btw, the revert is now in my tree (commit 011afa1ed8c4), and marked
> for stable. So *now* Greg can revert it from stable too.
>
> But the important lesson to everybody should be that "we don't lose
> fixes from -stable". If a problem was found in stable, it needs to be
> fixed upstream. In fact, quite often people *do* find problems in
> stable, because it tends to have more users more quickly than
> mainline. That makes it really really important to make sure that
> those problems get fixed upstream, and not hidden in stable due to
> some kind of dieseased "it's a no-op to revert it" thinking.
>
> End of story.

FWIW if people want stable fixes propagated faster (before Linus sucks
it in or Greg sucks it in after Linus) things like compat-wireless (to
be renamed to compat-drivers) allows us to get these out, but we label
them properly [0]. We in fact have a place holder for even other type
of non-upstream patches that any PHB may come up with as required but
-- the key is to

1) help categorize these properly
2) keep metrics of them
3) prioritize upstream first

The pending-stable/ patches get patches out to the community faster
than Linus / Greg can apply them or before we even get the community
to test them. We get these sucked out by looking for the Cc:
stable@vger.kernel.org The linux-next-cherry-pick/ allows you suck out
non-stable patches and I gladly accept such patches so long as they
are in linux-next and I can suck them out automatically if you Cc:
stable@orbit-lab.org. There are similar tricks for the other types of
patches.

[0] http://wireless.kernel.org/en/users/Download/stable/#Additional_patches_to_stable_releases

  Luis

[ath9k-devel] [ 00/78] 3.3.2-stable review

[Luis R. Rodriguez]

On Thu, Apr 12, 2012 at 2:44 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> On Thu, Apr 12, 2012 at 2:34 PM, Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
>>
>> So just reverting it from stable, *WITHOUT LEARNING THE LESSON*, is
>> not a no-op at all, it's a sign of being a f*cking moron.
>
> Btw, the revert is now in my tree (commit 011afa1ed8c4), and marked
> for stable. So *now* Greg can revert it from stable too.
>
> But the important lesson to everybody should be that "we don't lose
> fixes from -stable". If a problem was found in stable, it needs to be
> fixed upstream. In fact, quite often people *do* find problems in
> stable, because it tends to have more users more quickly than
> mainline. That makes it really really important to make sure that
> those problems get fixed upstream, and not hidden in stable due to
> some kind of dieseased "it's a no-op to revert it" thinking.
>
> End of story.

FWIW if people want stable fixes propagated faster (before Linus sucks
it in or Greg sucks it in after Linus) things like compat-wireless (to
be renamed to compat-drivers) allows us to get these out, but we label
them properly [0]. We in fact have a place holder for even other type
of non-upstream patches that any PHB may come up with as required but
-- the key is to

1) help categorize these properly
2) keep metrics of them
3) prioritize upstream first

The pending-stable/ patches get patches out to the community faster
than Linus / Greg can apply them or before we even get the community
to test them. We get these sucked out by looking for the Cc:
stable at vger.kernel.org The linux-next-cherry-pick/ allows you suck out
non-stable patches and I gladly accept such patches so long as they
are in linux-next and I can suck them out automatically if you Cc:
stable at orbit-lab.org. There are similar tricks for the other types of
patches.

[0] http://wireless.kernel.org/en/users/Download/stable/#Additional_patches_to_stable_releases

  Luis

Re: [ 00/78] 3.3.2-stable review

[Felipe Contreras]

On Fri, Apr 13, 2012 at 12:34 AM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> On Thu, Apr 12, 2012 at 2:20 PM, Felipe Contreras
> <felipe.contreras@gmail.com> wrote:
>>
>> I could argue in favor of exceptions, but I don't think you realize
>> the fact that this change does not affect your tree *at all*. Adding
>> and removing a patch in the stable tree is a no-op.
>
> You're a fucking moron.
>
> It's not a no-op at all, and you don't seem to understand it.
>
> It's *information*.
>
> It's "that patch didn't work". That's not a no-op. That's actual
> useful and worthwhile knowledge.

Sure, but removing that patch from the stable tree is not going the
change that information; we already know the patch is wrong.

Let's say somebody finds something wrong with one of the patches
proposed for 3.3.2 today, which is still a possibility. The patch
would be dropped, even though it's already in upstream (as all stable
patches are), and development in upstream will continue as usual, and
a proper fix will come later--there's lots of stuff broken there,
which is why not all the patches make it to 3.3.2.

But if somebody finds a problem on Saturday, after the 3.3.2 release,
well, it's too late now, the patch has been tagged and cannot be
removed for 3.3.3, now we have to wait to see what upstream does.

Wrong is wrong, before or after the 3.3.1 tag, this patch is not
'stable' material, and removing it does not affect upstream at all.

-- 
Felipe Contreras

[ath9k-devel] [ 00/78] 3.3.2-stable review

[Felipe Contreras]

On Fri, Apr 13, 2012 at 12:34 AM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> On Thu, Apr 12, 2012 at 2:20 PM, Felipe Contreras
> <felipe.contreras@gmail.com> wrote:
>>
>> I could argue in favor of exceptions, but I don't think you realize
>> the fact that this change does not affect your tree *at all*. Adding
>> and removing a patch in the stable tree is a no-op.
>
> You're a fucking moron.
>
> It's not a no-op at all, and you don't seem to understand it.
>
> It's *information*.
>
> It's "that patch didn't work". That's not a no-op. That's actual
> useful and worthwhile knowledge.

Sure, but removing that patch from the stable tree is not going the
change that information; we already know the patch is wrong.

Let's say somebody finds something wrong with one of the patches
proposed for 3.3.2 today, which is still a possibility. The patch
would be dropped, even though it's already in upstream (as all stable
patches are), and development in upstream will continue as usual, and
a proper fix will come later--there's lots of stuff broken there,
which is why not all the patches make it to 3.3.2.

But if somebody finds a problem on Saturday, after the 3.3.2 release,
well, it's too late now, the patch has been tagged and cannot be
removed for 3.3.3, now we have to wait to see what upstream does.

Wrong is wrong, before or after the 3.3.1 tag, this patch is not
'stable' material, and removing it does not affect upstream at all.

-- 
Felipe Contreras

Re: [ 00/78] 3.3.2-stable review

[Linus Torvalds]

On Thu, Apr 12, 2012 at 3:04 PM, Felipe Contreras
<felipe.contreras@gmail.com> wrote:
>
> Sure, but removing that patch from the stable tree is not going the
> change that information; we already know the patch is wrong.

.. and we wait until it has been fixed in mainline so that we *know*
that information doesn't get lost.

Exactly like any other patch. Exactly like the rules for -stable says we should.

Stop the idiotic arguing already.

              Linus

[ath9k-devel] [ 00/78] 3.3.2-stable review

[Linus Torvalds]

On Thu, Apr 12, 2012 at 3:04 PM, Felipe Contreras
<felipe.contreras@gmail.com> wrote:
>
> Sure, but removing that patch from the stable tree is not going the
> change that information; we already know the patch is wrong.

.. and we wait until it has been fixed in mainline so that we *know*
that information doesn't get lost.

Exactly like any other patch. Exactly like the rules for -stable says we should.

Stop the idiotic arguing already.

              Linus

Re: [ 00/78] 3.3.2-stable review

[David Miller]

From: Felipe Contreras <felipe.contreras@gmail.com>
Date: Fri, 13 Apr 2012 01:04:42 +0300

> Wrong is wrong, before or after the 3.3.1 tag, this patch is not
> 'stable' material, and removing it does not affect upstream at all.

What you don't understand is that bug fixes will get lost if you only
fix them in -stable, it doesn't matter HOW THEY GOT into -stable.

In fact IT HAS FUCKING HAPPENED that we didn't fix something upstream
that got fixed in -stable a time long ago when we didn't have the
policy we're using now which you're going so unreasonably ape-shit
about.

And we didn't notice the discrepency until much later.

So the issues are real, there's proven precendence, and you're just
so wrong it's not even funny.

[ath9k-devel] [ 00/78] 3.3.2-stable review

[David Miller]

From: Felipe Contreras <felipe.contreras@gmail.com>
Date: Fri, 13 Apr 2012 01:04:42 +0300

> Wrong is wrong, before or after the 3.3.1 tag, this patch is not
> 'stable' material, and removing it does not affect upstream at all.

What you don't understand is that bug fixes will get lost if you only
fix them in -stable, it doesn't matter HOW THEY GOT into -stable.

In fact IT HAS FUCKING HAPPENED that we didn't fix something upstream
that got fixed in -stable a time long ago when we didn't have the
policy we're using now which you're going so unreasonably ape-shit
about.

And we didn't notice the discrepency until much later.

So the issues are real, there's proven precendence, and you're just
so wrong it's not even funny.

Re: [ 00/78] 3.3.2-stable review

[Felipe Contreras]

On Fri, Apr 13, 2012 at 1:07 AM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> On Thu, Apr 12, 2012 at 3:04 PM, Felipe Contreras
> <felipe.contreras@gmail.com> wrote:
>>
>> Sure, but removing that patch from the stable tree is not going the
>> change that information; we already know the patch is wrong.
>
> .. and we wait until it has been fixed in mainline so that we *know*
> that information doesn't get lost.

So why don't we pick potentially dangerous patches that might benefit
from some testing, put them in 'stable', and if there are problems,
make sure they get fixed in upstream first? Or for that matter totally
broken patches we want to make sure they get fixed in upstream.

Because the priority of the 'stable' tree is *stability*. Is it not?

But what you are saying is: *before* the final review, even a hint
that the patch might cause problems is reason enough to drop it from
stable, but *after* the review, if we know the patch is totally
broken, then it's the opposite; we really want it in.

-- 
Felipe Contreras

[ath9k-devel] [ 00/78] 3.3.2-stable review

[Felipe Contreras]

On Fri, Apr 13, 2012 at 1:07 AM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> On Thu, Apr 12, 2012 at 3:04 PM, Felipe Contreras
> <felipe.contreras@gmail.com> wrote:
>>
>> Sure, but removing that patch from the stable tree is not going the
>> change that information; we already know the patch is wrong.
>
> .. and we wait until it has been fixed in mainline so that we *know*
> that information doesn't get lost.

So why don't we pick potentially dangerous patches that might benefit
from some testing, put them in 'stable', and if there are problems,
make sure they get fixed in upstream first? Or for that matter totally
broken patches we want to make sure they get fixed in upstream.

Because the priority of the 'stable' tree is *stability*. Is it not?

But what you are saying is: *before* the final review, even a hint
that the patch might cause problems is reason enough to drop it from
stable, but *after* the review, if we know the patch is totally
broken, then it's the opposite; we really want it in.

-- 
Felipe Contreras

Re: [ 00/78] 3.3.2-stable review

[Greg KH]

On Thu, Apr 12, 2012 at 10:30:21PM +0200, Alexander Holler wrote:
> Am 12.04.2012 22:06, schrieb Greg KH:
> >On Thu, Apr 12, 2012 at 09:57:53PM +0200, Alexander Holler wrote:
> >>Hello,
> >>
> >>Am 12.04.2012 02:29, schrieb Greg KH:
> >>
> >>>>is there any chance for this one to be included in this review cycle?
> >>>>
> >>>>http://www.spinics.net/lists/linux-wireless/msg87999.html
> >>>
> >>>Have you read Documentation/stable_kernel_rules.txt?  Based on that, I
> >>>don't think it can, yet, right?
> >>
> >>Hmm, after reading that, I think the text could need an update about
> >>how to submit patches written by others (which can already be found
> >>in the upstream tree).
> >>
> >>At least for me the text reads like only the authors can request
> >>inclusion of a patch into the stable tree.
> >
> >Patches are always welcome, but I think you will find the file already
> >describes this (hint, the first '-' line for the Procedure section
> >handles it).
> 
> That reads:
> 
> "- Send the patch, after verifying that it follows the above rules, to
>    stable@vger.kernel.org.  You must note the upstream commit ID in the
>    changelog of your submission, as well as the kernel version you wish
>    it to be applied to."
> 
> Maybe I'm a bit dumb, but what would be my changelog if the patch
> was written by someone else (and e.g. fixes something the author
> wasn't aware of or hasn't described)?

It would be identical to what is in Linus's tree today.

Export the patch from git, add the needed information to the comment
area (i.e. the git commit id and what kernel to apply it to) and send it
to that email address.

Or, even easier, just email the stable@ address the git commit id, and
the kernel version you want it applied to, and cc: the authors of the
patch and maintainers (on the signed-off-by: path).

Hope this helps,

greg k-h

[ath9k-devel] [ 00/78] 3.3.2-stable review

[Greg KH]

On Thu, Apr 12, 2012 at 10:30:21PM +0200, Alexander Holler wrote:
> Am 12.04.2012 22:06, schrieb Greg KH:
> >On Thu, Apr 12, 2012 at 09:57:53PM +0200, Alexander Holler wrote:
> >>Hello,
> >>
> >>Am 12.04.2012 02:29, schrieb Greg KH:
> >>
> >>>>is there any chance for this one to be included in this review cycle?
> >>>>
> >>>>http://www.spinics.net/lists/linux-wireless/msg87999.html
> >>>
> >>>Have you read Documentation/stable_kernel_rules.txt?  Based on that, I
> >>>don't think it can, yet, right?
> >>
> >>Hmm, after reading that, I think the text could need an update about
> >>how to submit patches written by others (which can already be found
> >>in the upstream tree).
> >>
> >>At least for me the text reads like only the authors can request
> >>inclusion of a patch into the stable tree.
> >
> >Patches are always welcome, but I think you will find the file already
> >describes this (hint, the first '-' line for the Procedure section
> >handles it).
> 
> That reads:
> 
> "- Send the patch, after verifying that it follows the above rules, to
>    stable at vger.kernel.org.  You must note the upstream commit ID in the
>    changelog of your submission, as well as the kernel version you wish
>    it to be applied to."
> 
> Maybe I'm a bit dumb, but what would be my changelog if the patch
> was written by someone else (and e.g. fixes something the author
> wasn't aware of or hasn't described)?

It would be identical to what is in Linus's tree today.

Export the patch from git, add the needed information to the comment
area (i.e. the git commit id and what kernel to apply it to) and send it
to that email address.

Or, even easier, just email the stable@ address the git commit id, and
the kernel version you want it applied to, and cc: the authors of the
patch and maintainers (on the signed-off-by: path).

Hope this helps,

greg k-h

Re: [ 00/78] 3.3.2-stable review

[Felipe Contreras]

On Fri, Apr 13, 2012 at 1:12 AM, David Miller <davem@davemloft.net> wrote:
> From: Felipe Contreras <felipe.contreras@gmail.com>
> Date: Fri, 13 Apr 2012 01:04:42 +0300
>
>> Wrong is wrong, before or after the 3.3.1 tag, this patch is not
>> 'stable' material, and removing it does not affect upstream at all.
>
> What you don't understand is that bug fixes will get lost if you only
> fix them in -stable, it doesn't matter HOW THEY GOT into -stable.

Let's suppose that c1afdaf was never back-ported from v3.4-rc1, how
would you have fond out there was an issue with it? There's 10000
patches in v3.4-rc2, how do you expect to find issues in them?

People found out this issue on v3.4-rc1, so the fix would not have
been lost, but lets assume it would, v3.3.1 had the issue, the patch
as reverted in v3.3.2, and v3.4 still had the issue. So what? There's
already 10000 patches that would never make it to 3.3.x, and many will
have issues, which is why there would be v3.4.x.

> In fact IT HAS FUCKING HAPPENED that we didn't fix something upstream
> that got fixed in -stable a time long ago when we didn't have the
> policy we're using now which you're going so unreasonably ape-shit
> about.

I see how a *fix* on stable could get lost, but this is not a fix.

A lost fix would be like:

v3.3 (bad), v3.3.1 (good), v3.4 (bad)

But the worst-case scenario here would be:

v3.3 (good), v3.3.1 (bad), v3.3.2 (good), v3.4 (bad)

You said this has happened in the past, I challenge you to find a
single instance of this case: a patch is applied and reverted in
'stable', and the issue triggered by the patches was not fixed in the
next version.

-- 
Felipe Contreras

[ath9k-devel] [ 00/78] 3.3.2-stable review

[Felipe Contreras]

On Fri, Apr 13, 2012 at 1:12 AM, David Miller <davem@davemloft.net> wrote:
> From: Felipe Contreras <felipe.contreras@gmail.com>
> Date: Fri, 13 Apr 2012 01:04:42 +0300
>
>> Wrong is wrong, before or after the 3.3.1 tag, this patch is not
>> 'stable' material, and removing it does not affect upstream at all.
>
> What you don't understand is that bug fixes will get lost if you only
> fix them in -stable, it doesn't matter HOW THEY GOT into -stable.

Let's suppose that c1afdaf was never back-ported from v3.4-rc1, how
would you have fond out there was an issue with it? There's 10000
patches in v3.4-rc2, how do you expect to find issues in them?

People found out this issue on v3.4-rc1, so the fix would not have
been lost, but lets assume it would, v3.3.1 had the issue, the patch
as reverted in v3.3.2, and v3.4 still had the issue. So what? There's
already 10000 patches that would never make it to 3.3.x, and many will
have issues, which is why there would be v3.4.x.

> In fact IT HAS FUCKING HAPPENED that we didn't fix something upstream
> that got fixed in -stable a time long ago when we didn't have the
> policy we're using now which you're going so unreasonably ape-shit
> about.

I see how a *fix* on stable could get lost, but this is not a fix.

A lost fix would be like:

v3.3 (bad), v3.3.1 (good), v3.4 (bad)

But the worst-case scenario here would be:

v3.3 (good), v3.3.1 (bad), v3.3.2 (good), v3.4 (bad)

You said this has happened in the past, I challenge you to find a
single instance of this case: a patch is applied and reverted in
'stable', and the issue triggered by the patches was not fixed in the
next version.

-- 
Felipe Contreras

Re: [ 00/78] 3.3.2-stable review

[Willy Tarreau]

On Fri, Apr 13, 2012 at 01:58:10AM +0300, Felipe Contreras wrote:
> On Fri, Apr 13, 2012 at 1:12 AM, David Miller <davem@davemloft.net> wrote:
> > From: Felipe Contreras <felipe.contreras@gmail.com>
> > Date: Fri, 13 Apr 2012 01:04:42 +0300
> >
> >> Wrong is wrong, before or after the 3.3.1 tag, this patch is not
> >> 'stable' material, and removing it does not affect upstream at all.
> >
> > What you don't understand is that bug fixes will get lost if you only
> > fix them in -stable, it doesn't matter HOW THEY GOT into -stable.
> 
> Let's suppose that c1afdaf was never back-ported from v3.4-rc1, how
> would you have fond out there was an issue with it? There's 10000
> patches in v3.4-rc2, how do you expect to find issues in them?
> 
> People found out this issue on v3.4-rc1, so the fix would not have
> been lost, but lets assume it would, v3.3.1 had the issue, the patch
> as reverted in v3.3.2, and v3.4 still had the issue. So what? There's
> already 10000 patches that would never make it to 3.3.x, and many will
> have issues, which is why there would be v3.4.x.
> 
> > In fact IT HAS FUCKING HAPPENED that we didn't fix something upstream
> > that got fixed in -stable a time long ago when we didn't have the
> > policy we're using now which you're going so unreasonably ape-shit
> > about.
> 
> I see how a *fix* on stable could get lost, but this is not a fix.

Felipe, you don't seem to get it : there are many bugs in each new release.
Given the number of fixes Greg merges into a longterm branch, I'd say that
there are around 1500 bugs waiting to be discovered and fixed in a new
release. Does this mean we need to fix them all at once ? No, because we
don't know about them yet.

The process you're criticizing consists in ensuring that once a bug is known,
it gets fixed in mainline so that it never appears there again. The way the
bug is discovered doesn't matter, even if it's discovered that a fix caused
the bug and that it must be reverted. The fact is mainline is buggy and we
know this because stable is too. So mainline must be fixed first. This
process works because stable users are pressuring developers to push their
fixes to Linus in order to get them. What happened with this bug prooved
the process is working fine.

Another point is that you don't want stable to merge, revert, merge again,
revert again etc... This happened a little bit during 2.6.32 because some
fixes were not really obvious. It's common for some fixes to have to be
adapted for stable branches, and to have side effects, hence the review
cycle. We need to limit these random issues as much as possible if we
don't want users to lose trust in the stable branches. This is extremely
important. So picking random fixes that have not been qualified by all
interested parties in stable is inappropriate. Reverting without evaluating
impacts is one form of picking a random fix.

What you should have done would have been to reply to Greg saying "wait a
minute, we still have an issue with patch XX, I'm trying to get it reverted
in upstream and will send you the commit ID, it would be nice to have it in
3.3.2". It wastes less time for everyone and achieves the same result.

Once again, if you think that the stable branch you're using is not stable
enough for you, pick another one. Greg maintains multiple branches so that
everyone is satisfied. The risk of bugs over time probably looks like
(cos(t)+1)/t. Find an older branch with a much smaller risk of regressions
and be done with it.

Last point, you should note that you're the only one here who doesn't
understand the process. That doesn't make you a fool, but it should tell you
that you probably need to think a bit further before telling people how they
should work, especially when all other ones agree on the benefits of the
process, including Arnd explaining that FreeBSD had been facing the exact
same trouble and now applies the same process. It is not just a small band
of nerds doing this for fun right here, but seems to be more generalized.

Regards
Willy

[ath9k-devel] [ 00/78] 3.3.2-stable review

[Willy Tarreau]

On Fri, Apr 13, 2012 at 01:58:10AM +0300, Felipe Contreras wrote:
> On Fri, Apr 13, 2012 at 1:12 AM, David Miller <davem@davemloft.net> wrote:
> > From: Felipe Contreras <felipe.contreras@gmail.com>
> > Date: Fri, 13 Apr 2012 01:04:42 +0300
> >
> >> Wrong is wrong, before or after the 3.3.1 tag, this patch is not
> >> 'stable' material, and removing it does not affect upstream at all.
> >
> > What you don't understand is that bug fixes will get lost if you only
> > fix them in -stable, it doesn't matter HOW THEY GOT into -stable.
> 
> Let's suppose that c1afdaf was never back-ported from v3.4-rc1, how
> would you have fond out there was an issue with it? There's 10000
> patches in v3.4-rc2, how do you expect to find issues in them?
> 
> People found out this issue on v3.4-rc1, so the fix would not have
> been lost, but lets assume it would, v3.3.1 had the issue, the patch
> as reverted in v3.3.2, and v3.4 still had the issue. So what? There's
> already 10000 patches that would never make it to 3.3.x, and many will
> have issues, which is why there would be v3.4.x.
> 
> > In fact IT HAS FUCKING HAPPENED that we didn't fix something upstream
> > that got fixed in -stable a time long ago when we didn't have the
> > policy we're using now which you're going so unreasonably ape-shit
> > about.
> 
> I see how a *fix* on stable could get lost, but this is not a fix.

Felipe, you don't seem to get it : there are many bugs in each new release.
Given the number of fixes Greg merges into a longterm branch, I'd say that
there are around 1500 bugs waiting to be discovered and fixed in a new
release. Does this mean we need to fix them all at once ? No, because we
don't know about them yet.

The process you're criticizing consists in ensuring that once a bug is known,
it gets fixed in mainline so that it never appears there again. The way the
bug is discovered doesn't matter, even if it's discovered that a fix caused
the bug and that it must be reverted. The fact is mainline is buggy and we
know this because stable is too. So mainline must be fixed first. This
process works because stable users are pressuring developers to push their
fixes to Linus in order to get them. What happened with this bug prooved
the process is working fine.

Another point is that you don't want stable to merge, revert, merge again,
revert again etc... This happened a little bit during 2.6.32 because some
fixes were not really obvious. It's common for some fixes to have to be
adapted for stable branches, and to have side effects, hence the review
cycle. We need to limit these random issues as much as possible if we
don't want users to lose trust in the stable branches. This is extremely
important. So picking random fixes that have not been qualified by all
interested parties in stable is inappropriate. Reverting without evaluating
impacts is one form of picking a random fix.

What you should have done would have been to reply to Greg saying "wait a
minute, we still have an issue with patch XX, I'm trying to get it reverted
in upstream and will send you the commit ID, it would be nice to have it in
3.3.2". It wastes less time for everyone and achieves the same result.

Once again, if you think that the stable branch you're using is not stable
enough for you, pick another one. Greg maintains multiple branches so that
everyone is satisfied. The risk of bugs over time probably looks like
(cos(t)+1)/t. Find an older branch with a much smaller risk of regressions
and be done with it.

Last point, you should note that you're the only one here who doesn't
understand the process. That doesn't make you a fool, but it should tell you
that you probably need to think a bit further before telling people how they
should work, especially when all other ones agree on the benefits of the
process, including Arnd explaining that FreeBSD had been facing the exact
same trouble and now applies the same process. It is not just a small band
of nerds doing this for fun right here, but seems to be more generalized.

Regards
Willy

Re: [ 00/78] 3.3.2-stable review

[Stefan Richter]

On Apr 12 Felipe Contreras wrote:
> But this is exactly the opposite; the patch that broke things is in
> the 'release branch' (3.3.1); it's not in upstream (3.3). Sure, it's
> also on a later upstream, which is also broken.
            ^^^^^
No, upstream /earlier/ than 3.3.1 contains the defect.

v3.4-rc1 is older than v3.3.1.

3.3 is not 3.3.y's upstream.  3.3 is the branch point from where 3.3.y
began.

torvalds/linux.git #HEAD is 3.3.y's upstream.
A git snapshot shortly before v3.4-rc1 was v3.3.1's upstream.

Furthermore, consider this:  You as user of the 3.3.y series are using a
temporary, dead-end side branch.  Its maintenance will stop at some point,
and you will be left looking for a different, maintained series to migrate
to.  You will be most interested in that series /not/ containing any
regressions that you suffered already through the 3.3.y lifetime.

That other 3.3+n.y kernel to which you will be wanting to migrate to
should obviously be based on a branch point which does not lack any of the
fixes which your last 3.3.y already had.

I.e. you require that stable kernels are branched off of good branch
points.  Mainline releases, i.e. releases of branch points, happen on a
time-based scheme (as opposed to a feature-based scheme).  So a rule whose
purpose is to ensure that future stable branch points contain all fixes
that earlier stable branches had already must necessarily be a time-based
rule.  This time-based rule is "fix mainline before stable".

The rule is there to protect you, as a user of the stable series, from
repeated regressions.
-- 
Stefan Richter
-=====-===-- -=-- -==-=
http://arcgraph.de/sr/

[ath9k-devel] [ 00/78] 3.3.2-stable review

[Stefan Richter]

On Apr 12 Felipe Contreras wrote:
> But this is exactly the opposite; the patch that broke things is in
> the 'release branch' (3.3.1); it's not in upstream (3.3). Sure, it's
> also on a later upstream, which is also broken.
            ^^^^^
No, upstream /earlier/ than 3.3.1 contains the defect.

v3.4-rc1 is older than v3.3.1.

3.3 is not 3.3.y's upstream.  3.3 is the branch point from where 3.3.y
began.

torvalds/linux.git #HEAD is 3.3.y's upstream.
A git snapshot shortly before v3.4-rc1 was v3.3.1's upstream.

Furthermore, consider this:  You as user of the 3.3.y series are using a
temporary, dead-end side branch.  Its maintenance will stop at some point,
and you will be left looking for a different, maintained series to migrate
to.  You will be most interested in that series /not/ containing any
regressions that you suffered already through the 3.3.y lifetime.

That other 3.3+n.y kernel to which you will be wanting to migrate to
should obviously be based on a branch point which does not lack any of the
fixes which your last 3.3.y already had.

I.e. you require that stable kernels are branched off of good branch
points.  Mainline releases, i.e. releases of branch points, happen on a
time-based scheme (as opposed to a feature-based scheme).  So a rule whose
purpose is to ensure that future stable branch points contain all fixes
that earlier stable branches had already must necessarily be a time-based
rule.  This time-based rule is "fix mainline before stable".

The rule is there to protect you, as a user of the stable series, from
repeated regressions.
-- 
Stefan Richter
-=====-===-- -=-- -==-=
http://arcgraph.de/sr/

Re: [ 00/78] 3.3.2-stable review

[Felipe Contreras]

On Fri, Apr 13, 2012 at 8:34 AM, Willy Tarreau <w@1wt.eu> wrote:
> On Fri, Apr 13, 2012 at 01:58:10AM +0300, Felipe Contreras wrote:
>> On Fri, Apr 13, 2012 at 1:12 AM, David Miller <davem@davemloft.net> wrote:
>> > From: Felipe Contreras <felipe.contreras@gmail.com>
>> > Date: Fri, 13 Apr 2012 01:04:42 +0300
>> >
>> >> Wrong is wrong, before or after the 3.3.1 tag, this patch is not
>> >> 'stable' material, and removing it does not affect upstream at all.
>> >
>> > What you don't understand is that bug fixes will get lost if you only
>> > fix them in -stable, it doesn't matter HOW THEY GOT into -stable.
>>
>> Let's suppose that c1afdaf was never back-ported from v3.4-rc1, how
>> would you have fond out there was an issue with it? There's 10000
>> patches in v3.4-rc2, how do you expect to find issues in them?
>>
>> People found out this issue on v3.4-rc1, so the fix would not have
>> been lost, but lets assume it would, v3.3.1 had the issue, the patch
>> as reverted in v3.3.2, and v3.4 still had the issue. So what? There's
>> already 10000 patches that would never make it to 3.3.x, and many will
>> have issues, which is why there would be v3.4.x.
>>
>> > In fact IT HAS FUCKING HAPPENED that we didn't fix something upstream
>> > that got fixed in -stable a time long ago when we didn't have the
>> > policy we're using now which you're going so unreasonably ape-shit
>> > about.
>>
>> I see how a *fix* on stable could get lost, but this is not a fix.
>
> Felipe, you don't seem to get it : there are many bugs in each new release.
> Given the number of fixes Greg merges into a longterm branch, I'd say that
> there are around 1500 bugs waiting to be discovered and fixed in a new
> release. Does this mean we need to fix them all at once ? No, because we
> don't know about them yet.
>
> The process you're criticizing consists in ensuring that once a bug is known,
> it gets fixed in mainline so that it never appears there again. The way the
> bug is discovered doesn't matter, even if it's discovered that a fix caused
> the bug and that it must be reverted. The fact is mainline is buggy and we
> know this because stable is too. So mainline must be fixed first. This
> process works because stable users are pressuring developers to push their
> fixes to Linus in order to get them. What happened with this bug prooved
> the process is working fine.

Let's list the scenarios:

a) normal patch

v3.3 (good), v3.4 (+) (good)

b) normal stable patch

v3.3 (good), v3.3.1 (+) (good), v3.4 (+) (good)

c) regression patch

v3.3 (good), v3.4 (+) (bad)

d) regression patch, fixed

v3.3 (good), v3.4 (good)

e) stable regression patch

v3.3 (good), v3.3.1 (+) (bad), v3.4 (+) (bad)

e.1) stable regression patch, normal fix

v3.3 (good), v3.3.1 (+) (bad), v3.3.2 (good), v3.4 (good)

e.2) stable regression patch, lost fix

v3.3 (good), v3.3.1 (+) (bad), v3.3.2 (good), v3.4 (+) (bad)

As you can see, even in the worst-case scenarios, there's no
difference between (c) and (e.2). But what you are saying is that it
doesn't matter at which point the issue with the patch is found, (e.2)
has to be avoided *at all costs*, but you don't explain _why_. What is
so different between (c) and (e.2)?

And this is the worst-case scenario, I keep hearing people that this
has happened in the past, but I don' think so, I think what has
happened is:

f) stable patch fix, lost

v3.3 (bad), v3.3.1 (+) (good), v3.4 (bad)

That I can see happening, and the current rules ensure that would not
happen, but (e.2)? I yet have to see any evidence of this happening in
the past.

But lets be realistic; most likely the issue would be and fixed in
upstream (d), so it doesn't matter what happens in stable, the end
result would be the same (e.1). In fact in this particular patch
people found problems in v3.4-rc1, so all evidence points out that we
would have ended up in (e.1), not (e.2).

So, if we expand the possibilities in the current situation, we have:

0) v3.3 (good), v3.3.1 (good), v3.3.2 (good), v3.3.3 (good), v3.4 (+)
(bad), v3.4.1 (good)
1) v3.3 (good), v3.3.1 (+) (bad), v3.3.2 (good), v3.3.3 (good), v3.4
(good), v3.4.1 (good)
2) v3.3 (good), v3.3.1 (+) (bad), v3.3.2 (+) (bad), v3.3.3 (good),
v3.4 (good), v3.4.1 (good)
3) v3.3 (good), v3.3.1 (+) (bad), v3.3.2 (good), v3.3.3 (good), v3.4
(+) (bad), v3.4.1 (good) #unlikely
4) v3.3 (good), v3.3.1 (+) (bad), v3.3.2 (+) (bad), v3.3.3 (+) (bad),
v3.4 (+) (bad), v3.4.1 (good) #unlikely

It looks like the patch is going both to upstream and stable (1),
which is ideal, but when faced with the option between (2) and (3),
you say (3) must absolutely be avoided even though it's basically the
same as (0), which is the norm for thousands of patches that don't get
back-ported to stable (and it's also unlikely to happen).

Why?

Plus, (1) (2) (3) (4) are already bad situations, and should be
avoided at all costs; patches to stable are not supposed to be
potentially dangerous, they are not meant be breaking things.

> Another point is that you don't want stable to merge, revert, merge again,
> revert again etc... This happened a little bit during 2.6.32 because some
> fixes were not really obvious. It's common for some fixes to have to be
> adapted for stable branches, and to have side effects, hence the review
> cycle. We need to limit these random issues as much as possible if we
> don't want users to lose trust in the stable branches. This is extremely
> important. So picking random fixes that have not been qualified by all
> interested parties in stable is inappropriate. Reverting without evaluating
> impacts is one form of picking a random fix.

Yeah, but that is not the case here, the options are clear; (a) go
back to a previous state where power management doesn't work
correctly, (b) stay in the current state where the system goes to a
completely unusable state.

> What you should have done would have been to reply to Greg saying "wait a
> minute, we still have an issue with patch XX, I'm trying to get it reverted
> in upstream and will send you the commit ID, it would be nice to have it in
> 3.3.2". It wastes less time for everyone and achieves the same result.

There's a lot of people affected by this issue, and a lot of noise.
Personally I didn't receive the revert patch, so I could not comment
on it. I think this patch should have been sent to LKML, but one
cannot expect everyone to do the perfect thing all the time.

> Once again, if you think that the stable branch you're using is not stable
> enough for you, pick another one. Greg maintains multiple branches so that
> everyone is satisfied. The risk of bugs over time probably looks like
> (cos(t)+1)/t. Find an older branch with a much smaller risk of regressions
> and be done with it.

I'm not sure I would want to use 'stable' anymore, because clearly,
the main goal doesn't seem to be *stability* as I thought. Apparently
it's supposed to be a testing ground for patches queued for the next
release.

> Last point, you should note that you're the only one here who doesn't
> understand the process. That doesn't make you a fool, but it should tell you
> that you probably need to think a bit further before telling people how they
> should work, especially when all other ones agree on the benefits of the
> process, including Arnd explaining that FreeBSD had been facing the exact
> same trouble and now applies the same process. It is not just a small band
> of nerds doing this for fun right here, but seems to be more generalized.

Ad populum.

The fact that I'm questioning the process doesn't mean I don't
understand it. But if you are not open to criticism, fine.

Cheers.

-- 
Felipe Contreras

[ath9k-devel] [ 00/78] 3.3.2-stable review

[Felipe Contreras]

On Fri, Apr 13, 2012 at 8:34 AM, Willy Tarreau <w@1wt.eu> wrote:
> On Fri, Apr 13, 2012 at 01:58:10AM +0300, Felipe Contreras wrote:
>> On Fri, Apr 13, 2012 at 1:12 AM, David Miller <davem@davemloft.net> wrote:
>> > From: Felipe Contreras <felipe.contreras@gmail.com>
>> > Date: Fri, 13 Apr 2012 01:04:42 +0300
>> >
>> >> Wrong is wrong, before or after the 3.3.1 tag, this patch is not
>> >> 'stable' material, and removing it does not affect upstream at all.
>> >
>> > What you don't understand is that bug fixes will get lost if you only
>> > fix them in -stable, it doesn't matter HOW THEY GOT into -stable.
>>
>> Let's suppose that c1afdaf was never back-ported from v3.4-rc1, how
>> would you have fond out there was an issue with it? There's 10000
>> patches in v3.4-rc2, how do you expect to find issues in them?
>>
>> People found out this issue on v3.4-rc1, so the fix would not have
>> been lost, but lets assume it would, v3.3.1 had the issue, the patch
>> as reverted in v3.3.2, and v3.4 still had the issue. So what? There's
>> already 10000 patches that would never make it to 3.3.x, and many will
>> have issues, which is why there would be v3.4.x.
>>
>> > In fact IT HAS FUCKING HAPPENED that we didn't fix something upstream
>> > that got fixed in -stable a time long ago when we didn't have the
>> > policy we're using now which you're going so unreasonably ape-shit
>> > about.
>>
>> I see how a *fix* on stable could get lost, but this is not a fix.
>
> Felipe, you don't seem to get it : there are many bugs in each new release.
> Given the number of fixes Greg merges into a longterm branch, I'd say that
> there are around 1500 bugs waiting to be discovered and fixed in a new
> release. Does this mean we need to fix them all at once ? No, because we
> don't know about them yet.
>
> The process you're criticizing consists in ensuring that once a bug is known,
> it gets fixed in mainline so that it never appears there again. The way the
> bug is discovered doesn't matter, even if it's discovered that a fix caused
> the bug and that it must be reverted. The fact is mainline is buggy and we
> know this because stable is too. So mainline must be fixed first. This
> process works because stable users are pressuring developers to push their
> fixes to Linus in order to get them. What happened with this bug prooved
> the process is working fine.

Let's list the scenarios:

a) normal patch

v3.3 (good), v3.4 (+) (good)

b) normal stable patch

v3.3 (good), v3.3.1 (+) (good), v3.4 (+) (good)

c) regression patch

v3.3 (good), v3.4 (+) (bad)

d) regression patch, fixed

v3.3 (good), v3.4 (good)

e) stable regression patch

v3.3 (good), v3.3.1 (+) (bad), v3.4 (+) (bad)

e.1) stable regression patch, normal fix

v3.3 (good), v3.3.1 (+) (bad), v3.3.2 (good), v3.4 (good)

e.2) stable regression patch, lost fix

v3.3 (good), v3.3.1 (+) (bad), v3.3.2 (good), v3.4 (+) (bad)

As you can see, even in the worst-case scenarios, there's no
difference between (c) and (e.2). But what you are saying is that it
doesn't matter at which point the issue with the patch is found, (e.2)
has to be avoided *at all costs*, but you don't explain _why_. What is
so different between (c) and (e.2)?

And this is the worst-case scenario, I keep hearing people that this
has happened in the past, but I don' think so, I think what has
happened is:

f) stable patch fix, lost

v3.3 (bad), v3.3.1 (+) (good), v3.4 (bad)

That I can see happening, and the current rules ensure that would not
happen, but (e.2)? I yet have to see any evidence of this happening in
the past.

But lets be realistic; most likely the issue would be and fixed in
upstream (d), so it doesn't matter what happens in stable, the end
result would be the same (e.1). In fact in this particular patch
people found problems in v3.4-rc1, so all evidence points out that we
would have ended up in (e.1), not (e.2).

So, if we expand the possibilities in the current situation, we have:

0) v3.3 (good), v3.3.1 (good), v3.3.2 (good), v3.3.3 (good), v3.4 (+)
(bad), v3.4.1 (good)
1) v3.3 (good), v3.3.1 (+) (bad), v3.3.2 (good), v3.3.3 (good), v3.4
(good), v3.4.1 (good)
2) v3.3 (good), v3.3.1 (+) (bad), v3.3.2 (+) (bad), v3.3.3 (good),
v3.4 (good), v3.4.1 (good)
3) v3.3 (good), v3.3.1 (+) (bad), v3.3.2 (good), v3.3.3 (good), v3.4
(+) (bad), v3.4.1 (good) #unlikely
4) v3.3 (good), v3.3.1 (+) (bad), v3.3.2 (+) (bad), v3.3.3 (+) (bad),
v3.4 (+) (bad), v3.4.1 (good) #unlikely

It looks like the patch is going both to upstream and stable (1),
which is ideal, but when faced with the option between (2) and (3),
you say (3) must absolutely be avoided even though it's basically the
same as (0), which is the norm for thousands of patches that don't get
back-ported to stable (and it's also unlikely to happen).

Why?

Plus, (1) (2) (3) (4) are already bad situations, and should be
avoided at all costs; patches to stable are not supposed to be
potentially dangerous, they are not meant be breaking things.

> Another point is that you don't want stable to merge, revert, merge again,
> revert again etc... This happened a little bit during 2.6.32 because some
> fixes were not really obvious. It's common for some fixes to have to be
> adapted for stable branches, and to have side effects, hence the review
> cycle. We need to limit these random issues as much as possible if we
> don't want users to lose trust in the stable branches. This is extremely
> important. So picking random fixes that have not been qualified by all
> interested parties in stable is inappropriate. Reverting without evaluating
> impacts is one form of picking a random fix.

Yeah, but that is not the case here, the options are clear; (a) go
back to a previous state where power management doesn't work
correctly, (b) stay in the current state where the system goes to a
completely unusable state.

> What you should have done would have been to reply to Greg saying "wait a
> minute, we still have an issue with patch XX, I'm trying to get it reverted
> in upstream and will send you the commit ID, it would be nice to have it in
> 3.3.2". It wastes less time for everyone and achieves the same result.

There's a lot of people affected by this issue, and a lot of noise.
Personally I didn't receive the revert patch, so I could not comment
on it. I think this patch should have been sent to LKML, but one
cannot expect everyone to do the perfect thing all the time.

> Once again, if you think that the stable branch you're using is not stable
> enough for you, pick another one. Greg maintains multiple branches so that
> everyone is satisfied. The risk of bugs over time probably looks like
> (cos(t)+1)/t. Find an older branch with a much smaller risk of regressions
> and be done with it.

I'm not sure I would want to use 'stable' anymore, because clearly,
the main goal doesn't seem to be *stability* as I thought. Apparently
it's supposed to be a testing ground for patches queued for the next
release.

> Last point, you should note that you're the only one here who doesn't
> understand the process. That doesn't make you a fool, but it should tell you
> that you probably need to think a bit further before telling people how they
> should work, especially when all other ones agree on the benefits of the
> process, including Arnd explaining that FreeBSD had been facing the exact
> same trouble and now applies the same process. It is not just a small band
> of nerds doing this for fun right here, but seems to be more generalized.

Ad populum.

The fact that I'm questioning the process doesn't mean I don't
understand it. But if you are not open to criticism, fine.

Cheers.

-- 
Felipe Contreras

Re: [ 00/78] 3.3.2-stable review

[Felipe Contreras]

On Fri, Apr 13, 2012 at 11:57 AM, Stefan Richter
<stefanr@s5r6.in-berlin.de> wrote:
> On Apr 12 Felipe Contreras wrote:
>> But this is exactly the opposite; the patch that broke things is in
>> the 'release branch' (3.3.1); it's not in upstream (3.3). Sure, it's
>> also on a later upstream, which is also broken.
>            ^^^^^
> No, upstream /earlier/ than 3.3.1 contains the defect.

Time is not relevant for the point being made, but fine:

But this is exactly the opposite; the patch that broke things is in
the 'release branch' (3.3.1); it's not in the upstream release from
where stable began (3.3). Sure, it's also on upstream, which is also
broken.

> Furthermore, consider this:  You as user of the 3.3.y series are using a
> temporary, dead-end side branch.  Its maintenance will stop at some point,
> and you will be left looking for a different, maintained series to migrate
> to.  You will be most interested in that series /not/ containing any
> regressions that you suffered already through the 3.3.y lifetime.

Of course, I will be interested in that, although most likely I would
be switching to another stable release (v3.4.1), not the upstream
release (v3.4), and most distros would do the same. Even in the
unlikely event that v3.4 is broken, most likely v3.4.1 would contain
the fix. But I'm also interested in v3.3.2 working.

So you are saying that:

a) v3.3.1 (bad), v3.3.2 (bad), v3.4 (good)
b) v3.3.1 (bad), v3.3.2 (good), v3.4 (bad)
c) v3.3.1 (bad), v3.3.2 (good), v3.4 (good)

b) is clearly better than a). Well, I don't see how; both situations
have the same number of releases broken, plus b) is very unlikely
anyway and we would end up with c). Plus, in all situation v3.4.1
would most likely contain the fix anyway.

> The rule is there to protect you, as a user of the stable series, from
> repeated regressions.

So in order to avoid b), you would rather go into a), than c)? Sorry,
I most definitely don't *need* that "protection". I guess I should
avoid the "stable" series then.

Cheers.

-- 
Felipe Contreras

[ath9k-devel] [ 00/78] 3.3.2-stable review

[Felipe Contreras]

On Fri, Apr 13, 2012 at 11:57 AM, Stefan Richter
<stefanr@s5r6.in-berlin.de> wrote:
> On Apr 12 Felipe Contreras wrote:
>> But this is exactly the opposite; the patch that broke things is in
>> the 'release branch' (3.3.1); it's not in upstream (3.3). Sure, it's
>> also on a later upstream, which is also broken.
> ? ? ? ? ? ?^^^^^
> No, upstream /earlier/ than 3.3.1 contains the defect.

Time is not relevant for the point being made, but fine:

But this is exactly the opposite; the patch that broke things is in
the 'release branch' (3.3.1); it's not in the upstream release from
where stable began (3.3). Sure, it's also on upstream, which is also
broken.

> Furthermore, consider this: ?You as user of the 3.3.y series are using a
> temporary, dead-end side branch. ?Its maintenance will stop at some point,
> and you will be left looking for a different, maintained series to migrate
> to. ?You will be most interested in that series /not/ containing any
> regressions that you suffered already through the 3.3.y lifetime.

Of course, I will be interested in that, although most likely I would
be switching to another stable release (v3.4.1), not the upstream
release (v3.4), and most distros would do the same. Even in the
unlikely event that v3.4 is broken, most likely v3.4.1 would contain
the fix. But I'm also interested in v3.3.2 working.

So you are saying that:

a) v3.3.1 (bad), v3.3.2 (bad), v3.4 (good)
b) v3.3.1 (bad), v3.3.2 (good), v3.4 (bad)
c) v3.3.1 (bad), v3.3.2 (good), v3.4 (good)

b) is clearly better than a). Well, I don't see how; both situations
have the same number of releases broken, plus b) is very unlikely
anyway and we would end up with c). Plus, in all situation v3.4.1
would most likely contain the fix anyway.

> The rule is there to protect you, as a user of the stable series, from
> repeated regressions.

So in order to avoid b), you would rather go into a), than c)? Sorry,
I most definitely don't *need* that "protection". I guess I should
avoid the "stable" series then.

Cheers.

-- 
Felipe Contreras

Re: [ 00/78] 3.3.2-stable review

[Stefan Richter]

On Apr 13 Felipe Contreras wrote:
> On Fri, Apr 13, 2012 at 11:57 AM, Stefan Richter
> <stefanr@s5r6.in-berlin.de> wrote:
> > On Apr 12 Felipe Contreras wrote:
> >> But this is exactly the opposite; the patch that broke things is in
> >> the 'release branch' (3.3.1); it's not in upstream (3.3). Sure, it's
> >> also on a later upstream, which is also broken.
> >            ^^^^^
> > No, upstream /earlier/ than 3.3.1 contains the defect.
> 
> Time is not relevant for the point being made, but fine:

Time of occurrence of a regression in mainline and stable is indeed
irrelevant, as there can only be two kinds of regressions in stable:

  A) First the regression was introduced into mainline, and accidentally it
     was carried over from there into stable.

  B) The regression only happened in stable because a backport from
     mainline to stable went wrong, e.g. a prerequisite to the backport
     was forgotten to be backported beforehand.

AFAIU we are talking about a regression of type A.

It seems you are arguing that stable candidate patches which fix
regressions of type A should be treated differently from other stable
candidate patches.

> But this is exactly the opposite; the patch that broke things is in
> the 'release branch' (3.3.1); it's not in the upstream release from
> where stable began (3.3). Sure, it's also on upstream, which is also
> broken.

(To what is this the opposite?)

So the defect is present in two kernel branches:  Linus'es and Greg's.
The fix needs eventually go into both branches.  For reasons which have
been enumerated many times in this thread already, Greg takes the fix from
Linus, not the other way around.

If you do not like to wait for Linus and Greg, you simply have to derive
an own kernel which additionally contains your preferred fixes.

The reasons for the Linus->Greg order of maintaining the stable series 100%
apply to fixes for type A regressions as well.

> > Furthermore, consider this:  You as user of the 3.3.y series are using a
> > temporary, dead-end side branch.  Its maintenance will stop at some point,
> > and you will be left looking for a different, maintained series to migrate
> > to.  You will be most interested in that series /not/ containing any
> > regressions that you suffered already through the 3.3.y lifetime.
> 
> Of course, I will be interested in that, although most likely I would
> be switching to another stable release (v3.4.1), not the upstream
> release (v3.4), and most distros would do the same.

Indeed.

> Even in the unlikely event that v3.4 is broken, most likely v3.4.1
> would contain the fix.

That would only happen if the upstream fix was published after v3.4 but
before Greg finished cherry-picking from Linus' post-3.4 git head.

> But I'm also interested in v3.3.2 working.

It's obviously a bit late for that, but v3.3.3 seems likely to bring the
fix.

> So you are saying that:
> 
> a) v3.3.1 (bad), v3.3.2 (bad), v3.4 (good)
> b) v3.3.1 (bad), v3.3.2 (good), v3.4 (bad)
> c) v3.3.1 (bad), v3.3.2 (good), v3.4 (good)
[...]

Not exactly.

I and others are saying that procedures must ensure that if e.g. v3.3.3
was "good", then v3.4 and hence v3.4.y must be "good" too.  ("Good" here
meaning "contains fix xyzabc".)

Furthermore I was saying that due to the time-based instead of
feature-based release schedule, the procedure which gives above guarantee
is a time-based procedure:  Greg takes fixes *if* they were published by
Linus == *after* they were published by Linus.

I add:  The second reason for this procedure is that v3.x.y is a successor
of v3.x but not of v3.x-1.y.  Forward-porting from v3.x-1.y to v3.x.y is
not in scope of the stable series.  The reasons why there is no
forward-porting done in stable series, again, have been mentioned several
times in this thread.
-- 
Stefan Richter
-=====-===-- -=-- -==-=
http://arcgraph.de/sr/

[ath9k-devel] [ 00/78] 3.3.2-stable review

[Stefan Richter]

On Apr 13 Felipe Contreras wrote:
> On Fri, Apr 13, 2012 at 11:57 AM, Stefan Richter
> <stefanr@s5r6.in-berlin.de> wrote:
> > On Apr 12 Felipe Contreras wrote:
> >> But this is exactly the opposite; the patch that broke things is in
> >> the 'release branch' (3.3.1); it's not in upstream (3.3). Sure, it's
> >> also on a later upstream, which is also broken.
> > ? ? ? ? ? ?^^^^^
> > No, upstream /earlier/ than 3.3.1 contains the defect.
> 
> Time is not relevant for the point being made, but fine:

Time of occurrence of a regression in mainline and stable is indeed
irrelevant, as there can only be two kinds of regressions in stable:

  A) First the regression was introduced into mainline, and accidentally it
     was carried over from there into stable.

  B) The regression only happened in stable because a backport from
     mainline to stable went wrong, e.g. a prerequisite to the backport
     was forgotten to be backported beforehand.

AFAIU we are talking about a regression of type A.

It seems you are arguing that stable candidate patches which fix
regressions of type A should be treated differently from other stable
candidate patches.

> But this is exactly the opposite; the patch that broke things is in
> the 'release branch' (3.3.1); it's not in the upstream release from
> where stable began (3.3). Sure, it's also on upstream, which is also
> broken.

(To what is this the opposite?)

So the defect is present in two kernel branches:  Linus'es and Greg's.
The fix needs eventually go into both branches.  For reasons which have
been enumerated many times in this thread already, Greg takes the fix from
Linus, not the other way around.

If you do not like to wait for Linus and Greg, you simply have to derive
an own kernel which additionally contains your preferred fixes.

The reasons for the Linus->Greg order of maintaining the stable series 100%
apply to fixes for type A regressions as well.

> > Furthermore, consider this: ?You as user of the 3.3.y series are using a
> > temporary, dead-end side branch. ?Its maintenance will stop at some point,
> > and you will be left looking for a different, maintained series to migrate
> > to. ?You will be most interested in that series /not/ containing any
> > regressions that you suffered already through the 3.3.y lifetime.
> 
> Of course, I will be interested in that, although most likely I would
> be switching to another stable release (v3.4.1), not the upstream
> release (v3.4), and most distros would do the same.

Indeed.

> Even in the unlikely event that v3.4 is broken, most likely v3.4.1
> would contain the fix.

That would only happen if the upstream fix was published after v3.4 but
before Greg finished cherry-picking from Linus' post-3.4 git head.

> But I'm also interested in v3.3.2 working.

It's obviously a bit late for that, but v3.3.3 seems likely to bring the
fix.

> So you are saying that:
> 
> a) v3.3.1 (bad), v3.3.2 (bad), v3.4 (good)
> b) v3.3.1 (bad), v3.3.2 (good), v3.4 (bad)
> c) v3.3.1 (bad), v3.3.2 (good), v3.4 (good)
[...]

Not exactly.

I and others are saying that procedures must ensure that if e.g. v3.3.3
was "good", then v3.4 and hence v3.4.y must be "good" too.  ("Good" here
meaning "contains fix xyzabc".)

Furthermore I was saying that due to the time-based instead of
feature-based release schedule, the procedure which gives above guarantee
is a time-based procedure:  Greg takes fixes *if* they were published by
Linus == *after* they were published by Linus.

I add:  The second reason for this procedure is that v3.x.y is a successor
of v3.x but not of v3.x-1.y.  Forward-porting from v3.x-1.y to v3.x.y is
not in scope of the stable series.  The reasons why there is no
forward-porting done in stable series, again, have been mentioned several
times in this thread.
-- 
Stefan Richter
-=====-===-- -=-- -==-=
http://arcgraph.de/sr/

Re: [ 00/78] 3.3.2-stable review

[Stefan Richter]

On Apr 13 Stefan Richter wrote:
> there can only be two kinds of regressions in stable:
> 
>   A) First the regression was introduced into mainline, and accidentally it
>      was carried over from there into stable.
> 
>   B) The regression only happened in stable because a backport from
>      mainline to stable went wrong, e.g. a prerequisite to the backport
>      was forgotten to be backported beforehand.
> 
> AFAIU we are talking about a regression of type A.
> 
> It seems you are arguing that stable candidate patches which fix
> regressions of type A should be treated differently from other stable
> candidate patches.

Correction to the last sentence:
Type A has two subtypes:  A.1) The regression occurred in mainline between
the branch points v3.M and v3.N and resulted in a regression from v3.M.y
to v3.N.y.  A.2) The regression occurred in mainline after branch point
v3.N and resulted in a regression from v3.N to v3.N.y.

   A.1) Mainline and stable may be affected.
   A.2) Mainline and stable may be affected.
   B)   Stable is affected, mainline is not.

You seem to be arguing that best practices to fix A.1 issues somehow do
not apply to how to fix A.2 issues.  (They do apply though.)
-- 
Stefan Richter
-=====-===-- -=-- -==-=
http://arcgraph.de/sr/

[ath9k-devel] [ 00/78] 3.3.2-stable review

[Stefan Richter]

On Apr 13 Stefan Richter wrote:
> there can only be two kinds of regressions in stable:
> 
>   A) First the regression was introduced into mainline, and accidentally it
>      was carried over from there into stable.
> 
>   B) The regression only happened in stable because a backport from
>      mainline to stable went wrong, e.g. a prerequisite to the backport
>      was forgotten to be backported beforehand.
> 
> AFAIU we are talking about a regression of type A.
> 
> It seems you are arguing that stable candidate patches which fix
> regressions of type A should be treated differently from other stable
> candidate patches.

Correction to the last sentence:
Type A has two subtypes:  A.1) The regression occurred in mainline between
the branch points v3.M and v3.N and resulted in a regression from v3.M.y
to v3.N.y.  A.2) The regression occurred in mainline after branch point
v3.N and resulted in a regression from v3.N to v3.N.y.

   A.1) Mainline and stable may be affected.
   A.2) Mainline and stable may be affected.
   B)   Stable is affected, mainline is not.

You seem to be arguing that best practices to fix A.1 issues somehow do
not apply to how to fix A.2 issues.  (They do apply though.)
-- 
Stefan Richter
-=====-===-- -=-- -==-=
http://arcgraph.de/sr/

Re: [ath9k-devel] [ 00/78] 3.3.2-stable review

[Peter Stuge]

Felipe Contreras wrote:
> I guess I should avoid the "stable" series then.

I wish you had understood this much much sooner so that this nonsense
thread could have been avoided.

If you want the very latest fixes then *obviously* you need to use
the most bleeding edge repo. (Linus')


//Peter

[ath9k-devel] [ 00/78] 3.3.2-stable review

[Peter Stuge]

Felipe Contreras wrote:
> I guess I should avoid the "stable" series then.

I wish you had understood this much much sooner so that this nonsense
thread could have been avoided.

If you want the very latest fixes then *obviously* you need to use
the most bleeding edge repo. (Linus')


//Peter

Re: [ 00/78] 3.3.2-stable review

[Felipe Contreras]

On Fri, Apr 13, 2012 at 4:42 PM, Stefan Richter
<stefanr@s5r6.in-berlin.de> wrote:
> On Apr 13 Felipe Contreras wrote:
>> On Fri, Apr 13, 2012 at 11:57 AM, Stefan Richter
>> <stefanr@s5r6.in-berlin.de> wrote:
>> > On Apr 12 Felipe Contreras wrote:
>> >> But this is exactly the opposite; the patch that broke things is in
>> >> the 'release branch' (3.3.1); it's not in upstream (3.3). Sure, it's
>> >> also on a later upstream, which is also broken.
>> >            ^^^^^
>> > No, upstream /earlier/ than 3.3.1 contains the defect.
>>
>> Time is not relevant for the point being made, but fine:
>
> Time of occurrence of a regression in mainline and stable is indeed
> irrelevant, as there can only be two kinds of regressions in stable:

No. First of all, all regressions will happen first on mainline, and
then on stable. Maybe it's possible that a 3.3.x stable release
happens before a 3.4-rcx release that contains the patch, but which is
tagged first is irrelevant.

My point was that the patch is in 3.3.1, and 3.4-rc1, but not on 3.3.
The timing of these releases is irrelevant.

>  A) First the regression was introduced into mainline, and accidentally it
>     was carried over from there into stable.
>
>  B) The regression only happened in stable because a backport from
>     mainline to stable went wrong, e.g. a prerequisite to the backport
>     was forgotten to be backported beforehand.
>
> AFAIU we are talking about a regression of type A.
>
> It seems you are arguing that stable candidate patches which fix
> regressions of type A should be treated differently from other stable
> candidate patches.

No, I'm not arguing that.

I am arguing that *any* patch in stable should be droppable, even
after it has been tagged.

>> But this is exactly the opposite; the patch that broke things is in
>> the 'release branch' (3.3.1); it's not in the upstream release from
>> where stable began (3.3). Sure, it's also on upstream, which is also
>> broken.
>
> (To what is this the opposite?)
>
> So the defect is present in two kernel branches:  Linus'es and Greg's.
> The fix needs eventually go into both branches.  For reasons which have
> been enumerated many times in this thread already, Greg takes the fix from
> Linus, not the other way around.

You can enumerate the reasons as many times as you want, that doesn't
make them any more valid.

I explain below how you are providing reasons for a different situation.

> If you do not like to wait for Linus and Greg, you simply have to derive
> an own kernel which additionally contains your preferred fixes.

Yes, because clearly everybody thinks the process is perfect, and
criticizing it is heresy.

> The reasons for the Linus->Greg order of maintaining the stable series 100%
> apply to fixes for type A regressions as well.

Why? Because it does. IOW; dogma.

>> So you are saying that:
>>
>> a) v3.3.1 (bad), v3.3.2 (bad), v3.4 (good)
>> b) v3.3.1 (bad), v3.3.2 (good), v3.4 (bad)
>> c) v3.3.1 (bad), v3.3.2 (good), v3.4 (good)
> [...]
>
> Not exactly.
>
> I and others are saying that procedures must ensure that if e.g. v3.3.3
> was "good", then v3.4 and hence v3.4.y must be "good" too.  ("Good" here
> meaning "contains fix xyzabc".)

That's exactly what I said: if you are saying v3.4 *must* be good, you
are saying that b) *must* be avoided at all costs. Even if we end up
in a).

> Furthermore I was saying that due to the time-based instead of
> feature-based release schedule, the procedure which gives above guarantee
> is a time-based procedure:  Greg takes fixes *if* they were published by
> Linus == *after* they were published by Linus.
>
> I add:  The second reason for this procedure is that v3.x.y is a successor
> of v3.x but not of v3.x-1.y.  Forward-porting from v3.x-1.y to v3.x.y is
> not in scope of the stable series.  The reasons why there is no
> forward-porting done in stable series, again, have been mentioned several
> times in this thread.

Again, you can repeat the same thing as much as you want, it still
doesn't answer what I have asked.

>> a) v3.3.1 (bad), v3.3.2 (bad), v3.4 (good)
>> b) v3.3.1 (bad), v3.3.2 (good), v3.4 (bad)
>> c) v3.3.1 (bad), v3.3.2 (good), v3.4 (good)

Why is b) so much worst than c)?
Where is the evidence of that happening ever?

The truth is that b) is very unlikely to happen anyway, but you still
prefer a) to c), just to make sure that b) never *ever* happens, no
matter how unlikely.

The "reasons" explained are for an entirely different situation:

a') v3.3 (bad), v3.3.1 (bad), v3.3.2 (bad), v3.4 (good)
b') v3.3 (bad), v3.3.1 (bad), v3.3.2 (good), v3.4 (bad)
c') v3.3 (bad), v3.3.1 (bad), v3.3.2 (good), v3.4 (good)

You are providing the obvious answer, but to a question nobody asked.
I'm not talking about a', b', c', I'm talking about a, b, c, they are
*very* different.

I already exemplified how they are very different, but here it goes
again. The patch "drm/i915: Add lock on drm_helper_resume_force_mode"
was just tagged in 3.3.2, if I had said yesterday "this patch breaks
things on my machine", then that patch would have been dropped for
3.3.2 even though it's still on mainline--why? Because we know it's
broken, and broken patches are not supposed to land to stable. But
today, one day later, we have to wait until it's fixed in master
first. Why?

What makes a patch droppable yesterday, but dependent on mainline today?

This of course, has *not* been explained.

-- 
Felipe Contreras

[ath9k-devel] [ 00/78] 3.3.2-stable review

[Felipe Contreras]

On Fri, Apr 13, 2012 at 4:42 PM, Stefan Richter
<stefanr@s5r6.in-berlin.de> wrote:
> On Apr 13 Felipe Contreras wrote:
>> On Fri, Apr 13, 2012 at 11:57 AM, Stefan Richter
>> <stefanr@s5r6.in-berlin.de> wrote:
>> > On Apr 12 Felipe Contreras wrote:
>> >> But this is exactly the opposite; the patch that broke things is in
>> >> the 'release branch' (3.3.1); it's not in upstream (3.3). Sure, it's
>> >> also on a later upstream, which is also broken.
>> > ? ? ? ? ? ?^^^^^
>> > No, upstream /earlier/ than 3.3.1 contains the defect.
>>
>> Time is not relevant for the point being made, but fine:
>
> Time of occurrence of a regression in mainline and stable is indeed
> irrelevant, as there can only be two kinds of regressions in stable:

No. First of all, all regressions will happen first on mainline, and
then on stable. Maybe it's possible that a 3.3.x stable release
happens before a 3.4-rcx release that contains the patch, but which is
tagged first is irrelevant.

My point was that the patch is in 3.3.1, and 3.4-rc1, but not on 3.3.
The timing of these releases is irrelevant.

> ?A) First the regression was introduced into mainline, and accidentally it
> ? ? was carried over from there into stable.
>
> ?B) The regression only happened in stable because a backport from
> ? ? mainline to stable went wrong, e.g. a prerequisite to the backport
> ? ? was forgotten to be backported beforehand.
>
> AFAIU we are talking about a regression of type A.
>
> It seems you are arguing that stable candidate patches which fix
> regressions of type A should be treated differently from other stable
> candidate patches.

No, I'm not arguing that.

I am arguing that *any* patch in stable should be droppable, even
after it has been tagged.

>> But this is exactly the opposite; the patch that broke things is in
>> the 'release branch' (3.3.1); it's not in the upstream release from
>> where stable began (3.3). Sure, it's also on upstream, which is also
>> broken.
>
> (To what is this the opposite?)
>
> So the defect is present in two kernel branches: ?Linus'es and Greg's.
> The fix needs eventually go into both branches. ?For reasons which have
> been enumerated many times in this thread already, Greg takes the fix from
> Linus, not the other way around.

You can enumerate the reasons as many times as you want, that doesn't
make them any more valid.

I explain below how you are providing reasons for a different situation.

> If you do not like to wait for Linus and Greg, you simply have to derive
> an own kernel which additionally contains your preferred fixes.

Yes, because clearly everybody thinks the process is perfect, and
criticizing it is heresy.

> The reasons for the Linus->Greg order of maintaining the stable series 100%
> apply to fixes for type A regressions as well.

Why? Because it does. IOW; dogma.

>> So you are saying that:
>>
>> a) v3.3.1 (bad), v3.3.2 (bad), v3.4 (good)
>> b) v3.3.1 (bad), v3.3.2 (good), v3.4 (bad)
>> c) v3.3.1 (bad), v3.3.2 (good), v3.4 (good)
> [...]
>
> Not exactly.
>
> I and others are saying that procedures must ensure that if e.g. v3.3.3
> was "good", then v3.4 and hence v3.4.y must be "good" too. ?("Good" here
> meaning "contains fix xyzabc".)

That's exactly what I said: if you are saying v3.4 *must* be good, you
are saying that b) *must* be avoided at all costs. Even if we end up
in a).

> Furthermore I was saying that due to the time-based instead of
> feature-based release schedule, the procedure which gives above guarantee
> is a time-based procedure: ?Greg takes fixes *if* they were published by
> Linus == *after* they were published by Linus.
>
> I add: ?The second reason for this procedure is that v3.x.y is a successor
> of v3.x but not of v3.x-1.y. ?Forward-porting from v3.x-1.y to v3.x.y is
> not in scope of the stable series. ?The reasons why there is no
> forward-porting done in stable series, again, have been mentioned several
> times in this thread.

Again, you can repeat the same thing as much as you want, it still
doesn't answer what I have asked.

>> a) v3.3.1 (bad), v3.3.2 (bad), v3.4 (good)
>> b) v3.3.1 (bad), v3.3.2 (good), v3.4 (bad)
>> c) v3.3.1 (bad), v3.3.2 (good), v3.4 (good)

Why is b) so much worst than c)?
Where is the evidence of that happening ever?

The truth is that b) is very unlikely to happen anyway, but you still
prefer a) to c), just to make sure that b) never *ever* happens, no
matter how unlikely.

The "reasons" explained are for an entirely different situation:

a') v3.3 (bad), v3.3.1 (bad), v3.3.2 (bad), v3.4 (good)
b') v3.3 (bad), v3.3.1 (bad), v3.3.2 (good), v3.4 (bad)
c') v3.3 (bad), v3.3.1 (bad), v3.3.2 (good), v3.4 (good)

You are providing the obvious answer, but to a question nobody asked.
I'm not talking about a', b', c', I'm talking about a, b, c, they are
*very* different.

I already exemplified how they are very different, but here it goes
again. The patch "drm/i915: Add lock on drm_helper_resume_force_mode"
was just tagged in 3.3.2, if I had said yesterday "this patch breaks
things on my machine", then that patch would have been dropped for
3.3.2 even though it's still on mainline--why? Because we know it's
broken, and broken patches are not supposed to land to stable. But
today, one day later, we have to wait until it's fixed in master
first. Why?

What makes a patch droppable yesterday, but dependent on mainline today?

This of course, has *not* been explained.

-- 
Felipe Contreras

Re: [ath9k-devel] [ 00/78] 3.3.2-stable review

[Felipe Contreras]

On Fri, Apr 13, 2012 at 10:08 PM, Peter Stuge <peter@stuge.se> wrote:
> Felipe Contreras wrote:
>> I guess I should avoid the "stable" series then.
>
> I wish you had understood this much much sooner so that this nonsense
> thread could have been avoided.
>
> If you want the very latest fixes then *obviously* you need to use
> the most bleeding edge repo. (Linus')

No, I don't want the latest fixes, I want the latest *stable* kernel.

v3.3 is stable, v3.4-rcx are not. v3.4 would take months to cook,
there will be several release candidates, and it won't be released
until the known issues decrease to a reasonable level.

v3.3.x on the other hand are *not* stable. They contain patches
backported from v3.4, but nobody guarantees they will work. There was
no v3.3.1-rc1, so the first time the patches compromising v3.3.1 were
generally tested together is in v3.3.1, at which point if somebody
finds issues, it's too late; bad patches are *not* going to be removed
in v3.3.2. Once a tag is made, all the patches in it are dependent on
the pace of the development of mainline (v3.4-rcx), which is
definitely not stable, specially in the first release candidates.

IOW, the "stable" branch tries to be stable up to a point, then, it
becomes a testing ground for mainline, and a tracking device for
certain mainline issues.

-- 
Felipe Contreras

[ath9k-devel] [ 00/78] 3.3.2-stable review

[Felipe Contreras]

On Fri, Apr 13, 2012 at 10:08 PM, Peter Stuge <peter@stuge.se> wrote:
> Felipe Contreras wrote:
>> I guess I should avoid the "stable" series then.
>
> I wish you had understood this much much sooner so that this nonsense
> thread could have been avoided.
>
> If you want the very latest fixes then *obviously* you need to use
> the most bleeding edge repo. (Linus')

No, I don't want the latest fixes, I want the latest *stable* kernel.

v3.3 is stable, v3.4-rcx are not. v3.4 would take months to cook,
there will be several release candidates, and it won't be released
until the known issues decrease to a reasonable level.

v3.3.x on the other hand are *not* stable. They contain patches
backported from v3.4, but nobody guarantees they will work. There was
no v3.3.1-rc1, so the first time the patches compromising v3.3.1 were
generally tested together is in v3.3.1, at which point if somebody
finds issues, it's too late; bad patches are *not* going to be removed
in v3.3.2. Once a tag is made, all the patches in it are dependent on
the pace of the development of mainline (v3.4-rcx), which is
definitely not stable, specially in the first release candidates.

IOW, the "stable" branch tries to be stable up to a point, then, it
becomes a testing ground for mainline, and a tracking device for
certain mainline issues.

-- 
Felipe Contreras

Re: [ 00/78] 3.3.2-stable review

[Jonathan Nieder]

Felipe Contreras wrote:
> On Fri, Apr 13, 2012 at 4:42 PM, Stefan Richter wrote:

>> If you do not like to wait for Linus and Greg, you simply have to derive
>> an own kernel which additionally contains your preferred fixes.
>
> Yes, because clearly everybody thinks the process is perfect, and
> criticizing it is heresy.

Close.  Not everyone.  For example, you do not think the process is
perfect.

I don't think Stefan meant the above as tongue-in-cheek, for what it's
worth.  Another stable kernel with different rules really would be an
interesting exercise, and would probably fulfill a need for a certain
audience.

It's not like nobody does that already, anyway.  For example, I hear
Fedora has a kernel that they maintain well for a different audience,
using different rules.

Ciao,
Jonathan

[ath9k-devel] [ 00/78] 3.3.2-stable review

[Jonathan Nieder]

Felipe Contreras wrote:
> On Fri, Apr 13, 2012 at 4:42 PM, Stefan Richter wrote:

>> If you do not like to wait for Linus and Greg, you simply have to derive
>> an own kernel which additionally contains your preferred fixes.
>
> Yes, because clearly everybody thinks the process is perfect, and
> criticizing it is heresy.

Close.  Not everyone.  For example, you do not think the process is
perfect.

I don't think Stefan meant the above as tongue-in-cheek, for what it's
worth.  Another stable kernel with different rules really would be an
interesting exercise, and would probably fulfill a need for a certain
audience.

It's not like nobody does that already, anyway.  For example, I hear
Fedora has a kernel that they maintain well for a different audience,
using different rules.

Ciao,
Jonathan

Re: [ 00/78] 3.3.2-stable review

[Felipe Contreras]

On Sat, Apr 14, 2012 at 2:05 AM, Jonathan Nieder <jrnieder@gmail.com> wrote:
> Felipe Contreras wrote:
>> On Fri, Apr 13, 2012 at 4:42 PM, Stefan Richter wrote:
>
>>> If you do not like to wait for Linus and Greg, you simply have to derive
>>> an own kernel which additionally contains your preferred fixes.
>>
>> Yes, because clearly everybody thinks the process is perfect, and
>> criticizing it is heresy.
>
> Close.  Not everyone.  For example, you do not think the process is
> perfect.

So you think the process is *perfect*? I would have expected
reasonable people to know that nothing is perfect, realize the
sarcasm, and meditate for a second. But it seems expecting somebody to
agree the process is not perfect is too much to ask.

> I don't think Stefan meant the above as tongue-in-cheek, for what it's
> worth.  Another stable kernel with different rules really would be an
> interesting exercise, and would probably fulfill a need for a certain
> audience.
>
> It's not like nobody does that already, anyway.  For example, I hear
> Fedora has a kernel that they maintain well for a different audience,
> using different rules.

Of course, although the difference with the stable kernel would be
very small if the only thing added is an extra rule for acceptance:
"It reverts an earlier
patch to 'stable'."

But "we do this, and if you don't like it you can do whatever you
want" is not a valid argument in favor of the status quo, even though
it's used a lot in open source, and it's true, and there's nothing
wrong with that... I yet have to see an answer to my arguments, and
not a regurgitated answer for something nobody is proposing.

Cheers.

-- 
Felipe Contreras

[ath9k-devel] [ 00/78] 3.3.2-stable review

[Felipe Contreras]

On Sat, Apr 14, 2012 at 2:05 AM, Jonathan Nieder <jrnieder@gmail.com> wrote:
> Felipe Contreras wrote:
>> On Fri, Apr 13, 2012 at 4:42 PM, Stefan Richter wrote:
>
>>> If you do not like to wait for Linus and Greg, you simply have to derive
>>> an own kernel which additionally contains your preferred fixes.
>>
>> Yes, because clearly everybody thinks the process is perfect, and
>> criticizing it is heresy.
>
> Close. ?Not everyone. ?For example, you do not think the process is
> perfect.

So you think the process is *perfect*? I would have expected
reasonable people to know that nothing is perfect, realize the
sarcasm, and meditate for a second. But it seems expecting somebody to
agree the process is not perfect is too much to ask.

> I don't think Stefan meant the above as tongue-in-cheek, for what it's
> worth. ?Another stable kernel with different rules really would be an
> interesting exercise, and would probably fulfill a need for a certain
> audience.
>
> It's not like nobody does that already, anyway. ?For example, I hear
> Fedora has a kernel that they maintain well for a different audience,
> using different rules.

Of course, although the difference with the stable kernel would be
very small if the only thing added is an extra rule for acceptance:
"It reverts an earlier
patch to 'stable'."

But "we do this, and if you don't like it you can do whatever you
want" is not a valid argument in favor of the status quo, even though
it's used a lot in open source, and it's true, and there's nothing
wrong with that... I yet have to see an answer to my arguments, and
not a regurgitated answer for something nobody is proposing.

Cheers.

-- 
Felipe Contreras

Re: [ 42/78] PM / Runtime: dont forget to wake up waitqueue on failure

[Ben Hutchings]

[-- Attachment #1.1: Type: text/plain, Size: 1065 bytes --]

On Wed, 2012-04-11 at 16:11 -0700, Greg KH wrote:
> 3.3-stable review patch.  If anyone has any objections, please let me know.
> 
> ------------------
> 
> From: Alan Stern <stern@rowland.harvard.edu>
> 
> commit f2791d733a2f06997b573d1a3cfde21e6f529826 upstream.
> 
> This patch (as1535) fixes a bug in the runtime PM core.  When a
> runtime suspend attempt completes, whether successfully or not, the
> device's power.wait_queue is supposed to be signalled.  But this
> doesn't happen in the failure pathway of rpm_suspend() when another
> autosuspend attempt is rescheduled.  As a result, a task can get stuck
> indefinitely on the wait queue (I have seen this happen in testing).
> 
> The patch fixes the problem by moving the wake_up_all() call up near
> the start of the failure code.
[...]

It looks like this is also relevant to 3.2, but the code got moved
around a bit between 3.2 and 3.3.  Attaching my (untested) backport.

Ben.

-- 
Ben Hutchings
It is easier to change the specification to fit the program than vice versa.

[-- Attachment #1.2: 0001-PM-Runtime-don-t-forget-to-wake-up-waitqueue-on-fail.patch --]
[-- Type: text/x-patch, Size: 1840 bytes --]

From 3853eee3a7aae2eda1bb8f9f0c9b8226cbba4bfb Mon Sep 17 00:00:00 2001
From: Alan Stern <stern@rowland.harvard.edu>
Date: Mon, 26 Mar 2012 22:46:52 +0200
Subject: [PATCH] PM / Runtime: don't forget to wake up waitqueue on failure

commit f2791d733a2f06997b573d1a3cfde21e6f529826 upstream.

This patch (as1535) fixes a bug in the runtime PM core.  When a
runtime suspend attempt completes, whether successfully or not, the
device's power.wait_queue is supposed to be signalled.  But this
doesn't happen in the failure pathway of rpm_suspend() when another
autosuspend attempt is rescheduled.  As a result, a task can get stuck
indefinitely on the wait queue (I have seen this happen in testing).

The patch fixes the problem by moving the wake_up_all() call up near
the start of the failure code.

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
[bwh: Backported to 3.2: adjust context and indentation]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
---
 drivers/base/power/runtime.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/base/power/runtime.c b/drivers/base/power/runtime.c
index 8c78443..2424be5 100644
--- a/drivers/base/power/runtime.c
+++ b/drivers/base/power/runtime.c
@@ -417,6 +417,8 @@ static int rpm_suspend(struct device *dev, int rpmflags)
 	if (retval) {
 		__update_runtime_status(dev, RPM_ACTIVE);
 		dev->power.deferred_resume = false;
+		wake_up_all(&dev->power.wait_queue);
+
 		if (retval == -EAGAIN || retval == -EBUSY) {
 			dev->power.runtime_error = 0;
 
@@ -432,7 +434,6 @@ static int rpm_suspend(struct device *dev, int rpmflags)
 		} else {
 			pm_runtime_cancel_pending(dev);
 		}
-		wake_up_all(&dev->power.wait_queue);
 		goto out;
 	}
  no_callback:
-- 
1.7.9.5


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

Re: [ 31/78] ath9k: fix max noise floor threshold

[Ben Hutchings]

[-- Attachment #1.1: Type: text/plain, Size: 1147 bytes --]

On Wed, 2012-04-11 at 16:10 -0700, Greg KH wrote:
> 3.3-stable review patch.  If anyone has any objections, please let me know.
> 
> ------------------
> 
> From: Rajkumar Manoharan <rmanohar@qca.qualcomm.com>
> 
> commit 2ee0a07028d2cde6e131b73f029dae2b93c50f3a upstream.
> 
> Currently the maximum noise floor limit is set as too high (-60dB). The
> assumption of having a higher threshold limit is that it would help
> de-sensitize the receiver (reduce phy errors) from continuous
> interference. But when we have a bursty interference where there are
> collisions and then free air time and if the receiver is desensitized too
> much, it will miss the normal packets too. Lets make use of chips
> specific min, nom and max limits always. This patch helps to improve the
> connection stability in congested networks.
[...]

It looks like this is also applicable to 3.0 and 3.2, but the debug
logging statement changed between 3.2 and 3.3 and stopped this from
applying directly.  Attaching an (untested) backport.

Ben.

-- 
Ben Hutchings
It is easier to change the specification to fit the program than vice versa.

[-- Attachment #1.2: 0001-ath9k-fix-max-noise-floor-threshold.patch --]
[-- Type: text/x-patch, Size: 2193 bytes --]

From 6d19cb7b3325e6c460db0f07f178793f4500783a Mon Sep 17 00:00:00 2001
From: Rajkumar Manoharan <rmanohar@qca.qualcomm.com>
Date: Thu, 15 Mar 2012 06:08:04 +0530
Subject: [PATCH] ath9k: fix max noise floor threshold

commit 2ee0a07028d2cde6e131b73f029dae2b93c50f3a upstream.

Currently the maximum noise floor limit is set as too high (-60dB). The
assumption of having a higher threshold limit is that it would help
de-sensitize the receiver (reduce phy errors) from continuous
interference. But when we have a bursty interference where there are
collisions and then free air time and if the receiver is desensitized too
much, it will miss the normal packets too. Lets make use of chips
specific min, nom and max limits always. This patch helps to improve the
connection stability in congested networks.

Cc: Paul Stewart <pstew@google.com>
Tested-by: Gary Morain <gmorain@google.com>
Signed-off-by: Madhan Jaganathan <madhanj@qca.qualcomm.com>
Signed-off-by: Rajkumar Manoharan <rmanohar@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
[bwh: Backported to 3.0/3.2: adjust context]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
---
 drivers/net/wireless/ath/ath9k/calib.c |    5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/net/wireless/ath/ath9k/calib.c b/drivers/net/wireless/ath/ath9k/calib.c
index 8ddef3e..d771de5 100644
--- a/drivers/net/wireless/ath/ath9k/calib.c
+++ b/drivers/net/wireless/ath/ath9k/calib.c
@@ -20,7 +20,6 @@
 
 /* Common calibration code */
 
-#define ATH9K_NF_TOO_HIGH	-60
 
 static int16_t ath9k_hw_get_nf_hist_mid(int16_t *nfCalBuffer)
 {
@@ -348,10 +347,10 @@ static void ath9k_hw_nf_sanitize(struct ath_hw *ah, s16 *nf)
 			"NF calibrated [%s] [chain %d] is %d\n",
 			(i >= 3 ? "ext" : "ctl"), i % 3, nf[i]);
 
-		if (nf[i] > ATH9K_NF_TOO_HIGH) {
+		if (nf[i] > limit->max) {
 			ath_dbg(common, ATH_DBG_CALIBRATE,
 				"NF[%d] (%d) > MAX (%d), correcting to MAX\n",
-				i, nf[i], ATH9K_NF_TOO_HIGH);
+				i, nf[i], limit->max);
 			nf[i] = limit->max;
 		} else if (nf[i] < limit->min) {
 			ath_dbg(common, ATH_DBG_CALIBRATE,
-- 
1.7.9.5


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

Re: [ 00/78] 3.3.2-stable review

[Willy Tarreau]

On Sat, Apr 14, 2012 at 02:18:33AM +0300, Felipe Contreras wrote:
> On Sat, Apr 14, 2012 at 2:05 AM, Jonathan Nieder <jrnieder@gmail.com> wrote:
> > Felipe Contreras wrote:
> >> On Fri, Apr 13, 2012 at 4:42 PM, Stefan Richter wrote:
> >
> >>> If you do not like to wait for Linus and Greg, you simply have to derive
> >>> an own kernel which additionally contains your preferred fixes.
> >>
> >> Yes, because clearly everybody thinks the process is perfect, and
> >> criticizing it is heresy.
> >
> > Close.  Not everyone.  For example, you do not think the process is
> > perfect.
> 
> So you think the process is *perfect*? I would have expected
> reasonable people to know that nothing is perfect, realize the
> sarcasm, and meditate for a second. But it seems expecting somebody to
> agree the process is not perfect is too much to ask.

Nobody has said it's perfect. Jonathan said it's "close" to perfect. I
personally think it's the best tradeoff we could find between a perfectly
stable branch and a perfect mainline. We manage to converge towards the
best quality in both branches by accepting a small delay in -stable.

The problem is that *you* don't accept to wait as soon as you know there's
a bug, and *you* don't want to make the necessary efforts to make things
move on. The process is clear and easy and has been explained to you several
times. If *you* want a fix, *you* just have to ask the fix's author to push
it to mainline and ask Greg to include it. There will always be a delay
between the moment a fix is written and the moment it boots on your host
anyway.

How would you have acted with 2.6.32 when there was this bug preventing
machines from living more than 208 days ? You think that just complaining
loudly that it's unacceptable to have this bug would have made things go
better ? Very few people were experiencing it and even fewer people were
able to understand it. Fortunately some users deployed a lot of efforts in
providing traces, configs, etc to narrow the bug down and it eventually got
fixed something like one year after the first report, thanks to everyone's
involvment. Linux is not only Linus or Greg's job, it's everyone's. You
have to take your part when you feel concerned about something. If you
don't want to participate, that's fine. Use a vendor's distro and file
a bug report, they'll do this job themselves and in the mean time they'll
probably provide you with the fix.

> > I don't think Stefan meant the above as tongue-in-cheek, for what it's
> > worth.  Another stable kernel with different rules really would be an
> > interesting exercise, and would probably fulfill a need for a certain
> > audience.

BTW this has been done a lot in the 2.4 era, by Alan, Andrew, Andrea, MCP,
myself. Yes it's interesting and useful. Experience shows that this ends
at one point because it requires a lot of work. And at this time there were
no such rules and it was very common to see that -ac or -aa kernels were
more stable than mainline for some workloads, which was a bit problematic,
especially when these kernels had to be rebased onto newer versions and
some patches had to be dropped at the risk of losing some stability fixes.

> > It's not like nobody does that already, anyway.  For example, I hear
> > Fedora has a kernel that they maintain well for a different audience,
> > using different rules.
> 
> Of course, although the difference with the stable kernel would be
> very small if the only thing added is an extra rule for acceptance:
> "It reverts an earlier patch to 'stable'."

Reverting patches that were not appropriate for -stable happens from
time to time, but only when the issue is specific to -stable (eg: build
issues). Here what you don't seem to understand is that the bug was
not specific to -stable but was present everywhere. So we had a bug
in mainline that we put in -stable, and we want mainline to be fixed
and we use -stable as a guarantee that mainline will be fixed. And it
works and has never failed yet. That's not hard to understand I think.

> But "we do this, and if you don't like it you can do whatever you
> want" is not a valid argument in favor of the status quo, even though
> it's used a lot in open source, and it's true, and there's nothing
> wrong with that... I yet have to see an answer to my arguments, and
> not a regurgitated answer for something nobody is proposing.

You've had many answers but you seem to selectively filter them. What you're
doing looks to me like "grep agree-with-me /dev/urandom && echo I was right".
Can take some time but it will eventually succeed. But please if you don't
want to listen to what people explain to you, at least stop polluting their
mailboxes with your looping arguments.

Willy

Re: [ 00/78] 3.3.2-stable review

[Willy Tarreau]

On Sat, Apr 14, 2012 at 02:18:33AM +0300, Felipe Contreras wrote:
> On Sat, Apr 14, 2012 at 2:05 AM, Jonathan Nieder <jrnieder@gmail.com> wrote:
> > Felipe Contreras wrote:
> >> On Fri, Apr 13, 2012 at 4:42 PM, Stefan Richter wrote:
> >
> >>> If you do not like to wait for Linus and Greg, you simply have to derive
> >>> an own kernel which additionally contains your preferred fixes.
> >>
> >> Yes, because clearly everybody thinks the process is perfect, and
> >> criticizing it is heresy.
> >
> > Close. �Not everyone. �For example, you do not think the process is
> > perfect.
> 
> So you think the process is *perfect*? I would have expected
> reasonable people to know that nothing is perfect, realize the
> sarcasm, and meditate for a second. But it seems expecting somebody to
> agree the process is not perfect is too much to ask.

Nobody has said it's perfect. Jonathan said it's "close" to perfect. I
personally think it's the best tradeoff we could find between a perfectly
stable branch and a perfect mainline. We manage to converge towards the
best quality in both branches by accepting a small delay in -stable.

The problem is that *you* don't accept to wait as soon as you know there's
a bug, and *you* don't want to make the necessary efforts to make things
move on. The process is clear and easy and has been explained to you several
times. If *you* want a fix, *you* just have to ask the fix's author to push
it to mainline and ask Greg to include it. There will always be a delay
between the moment a fix is written and the moment it boots on your host
anyway.

How would you have acted with 2.6.32 when there was this bug preventing
machines from living more than 208 days ? You think that just complaining
loudly that it's unacceptable to have this bug would have made things go
better ? Very few people were experiencing it and even fewer people were
able to understand it. Fortunately some users deployed a lot of efforts in
providing traces, configs, etc to narrow the bug down and it eventually got
fixed something like one year after the first report, thanks to everyone's
involvment. Linux is not only Linus or Greg's job, it's everyone's. You
have to take your part when you feel concerned about something. If you
don't want to participate, that's fine. Use a vendor's distro and file
a bug report, they'll do this job themselves and in the mean time they'll
probably provide you with the fix.

> > I don't think Stefan meant the above as tongue-in-cheek, for what it's
> > worth. �Another stable kernel with different rules really would be an
> > interesting exercise, and would probably fulfill a need for a certain
> > audience.

BTW this has been done a lot in the 2.4 era, by Alan, Andrew, Andrea, MCP,
myself. Yes it's interesting and useful. Experience shows that this ends
at one point because it requires a lot of work. And at this time there were
no such rules and it was very common to see that -ac or -aa kernels were
more stable than mainline for some workloads, which was a bit problematic,
especially when these kernels had to be rebased onto newer versions and
some patches had to be dropped at the risk of losing some stability fixes.

> > It's not like nobody does that already, anyway. �For example, I hear
> > Fedora has a kernel that they maintain well for a different audience,
> > using different rules.
> 
> Of course, although the difference with the stable kernel would be
> very small if the only thing added is an extra rule for acceptance:
> "It reverts an earlier patch to 'stable'."

Reverting patches that were not appropriate for -stable happens from
time to time, but only when the issue is specific to -stable (eg: build
issues). Here what you don't seem to understand is that the bug was
not specific to -stable but was present everywhere. So we had a bug
in mainline that we put in -stable, and we want mainline to be fixed
and we use -stable as a guarantee that mainline will be fixed. And it
works and has never failed yet. That's not hard to understand I think.

> But "we do this, and if you don't like it you can do whatever you
> want" is not a valid argument in favor of the status quo, even though
> it's used a lot in open source, and it's true, and there's nothing
> wrong with that... I yet have to see an answer to my arguments, and
> not a regurgitated answer for something nobody is proposing.

You've had many answers but you seem to selectively filter them. What you're
doing looks to me like "grep agree-with-me /dev/urandom && echo I was right".
Can take some time but it will eventually succeed. But please if you don't
want to listen to what people explain to you, at least stop polluting their
mailboxes with your looping arguments.

Willy

[ath9k-devel] [ 00/78] 3.3.2-stable review

[Willy Tarreau]

On Sat, Apr 14, 2012 at 02:18:33AM +0300, Felipe Contreras wrote:
> On Sat, Apr 14, 2012 at 2:05 AM, Jonathan Nieder <jrnieder@gmail.com> wrote:
> > Felipe Contreras wrote:
> >> On Fri, Apr 13, 2012 at 4:42 PM, Stefan Richter wrote:
> >
> >>> If you do not like to wait for Linus and Greg, you simply have to derive
> >>> an own kernel which additionally contains your preferred fixes.
> >>
> >> Yes, because clearly everybody thinks the process is perfect, and
> >> criticizing it is heresy.
> >
> > Close. ?Not everyone. ?For example, you do not think the process is
> > perfect.
> 
> So you think the process is *perfect*? I would have expected
> reasonable people to know that nothing is perfect, realize the
> sarcasm, and meditate for a second. But it seems expecting somebody to
> agree the process is not perfect is too much to ask.

Nobody has said it's perfect. Jonathan said it's "close" to perfect. I
personally think it's the best tradeoff we could find between a perfectly
stable branch and a perfect mainline. We manage to converge towards the
best quality in both branches by accepting a small delay in -stable.

The problem is that *you* don't accept to wait as soon as you know there's
a bug, and *you* don't want to make the necessary efforts to make things
move on. The process is clear and easy and has been explained to you several
times. If *you* want a fix, *you* just have to ask the fix's author to push
it to mainline and ask Greg to include it. There will always be a delay
between the moment a fix is written and the moment it boots on your host
anyway.

How would you have acted with 2.6.32 when there was this bug preventing
machines from living more than 208 days ? You think that just complaining
loudly that it's unacceptable to have this bug would have made things go
better ? Very few people were experiencing it and even fewer people were
able to understand it. Fortunately some users deployed a lot of efforts in
providing traces, configs, etc to narrow the bug down and it eventually got
fixed something like one year after the first report, thanks to everyone's
involvment. Linux is not only Linus or Greg's job, it's everyone's. You
have to take your part when you feel concerned about something. If you
don't want to participate, that's fine. Use a vendor's distro and file
a bug report, they'll do this job themselves and in the mean time they'll
probably provide you with the fix.

> > I don't think Stefan meant the above as tongue-in-cheek, for what it's
> > worth. ?Another stable kernel with different rules really would be an
> > interesting exercise, and would probably fulfill a need for a certain
> > audience.

BTW this has been done a lot in the 2.4 era, by Alan, Andrew, Andrea, MCP,
myself. Yes it's interesting and useful. Experience shows that this ends
at one point because it requires a lot of work. And at this time there were
no such rules and it was very common to see that -ac or -aa kernels were
more stable than mainline for some workloads, which was a bit problematic,
especially when these kernels had to be rebased onto newer versions and
some patches had to be dropped at the risk of losing some stability fixes.

> > It's not like nobody does that already, anyway. ?For example, I hear
> > Fedora has a kernel that they maintain well for a different audience,
> > using different rules.
> 
> Of course, although the difference with the stable kernel would be
> very small if the only thing added is an extra rule for acceptance:
> "It reverts an earlier patch to 'stable'."

Reverting patches that were not appropriate for -stable happens from
time to time, but only when the issue is specific to -stable (eg: build
issues). Here what you don't seem to understand is that the bug was
not specific to -stable but was present everywhere. So we had a bug
in mainline that we put in -stable, and we want mainline to be fixed
and we use -stable as a guarantee that mainline will be fixed. And it
works and has never failed yet. That's not hard to understand I think.

> But "we do this, and if you don't like it you can do whatever you
> want" is not a valid argument in favor of the status quo, even though
> it's used a lot in open source, and it's true, and there's nothing
> wrong with that... I yet have to see an answer to my arguments, and
> not a regurgitated answer for something nobody is proposing.

You've had many answers but you seem to selectively filter them. What you're
doing looks to me like "grep agree-with-me /dev/urandom && echo I was right".
Can take some time but it will eventually succeed. But please if you don't
want to listen to what people explain to you, at least stop polluting their
mailboxes with your looping arguments.

Willy

Re: [ath9k-devel] [ 00/78] 3.3.2-stable review

[Willy Tarreau]

On Sat, Apr 14, 2012 at 01:53:22AM +0300, Felipe Contreras wrote:
> No, I don't want the latest fixes, I want the latest *stable* kernel.

You have it, it's 3.3.2.

> v3.3 is stable, v3.4-rcx are not.

v3.3 *aims to be stable*. That's the big difference. A kernel starts
unstable and converges to something more stable over the time. 2.4 was
still experiencing minor issues that we didn't have in 2.6 when I did
the last release. There were even some security issues we decided not
to fix and to document instead. Still for its users it was considered
much more stable than 2.6 or 3.x.

> v3.4 would take months to cook,
> there will be several release candidates, and it won't be released
> until the known issues decrease to a reasonable level.
> 
> v3.3.x on the other hand are *not* stable.

Nobody said they *are* stable as per the definition of this word.
"stable" is the name of the branch which defines the longterm goal
which is achieved as releases are issued. It's the same with longterm
kernels. They try to maintain even less bugs and try to to introduce
new ones, eventhough this happens from time to time, development is
not an exact science.

> They contain patches
> backported from v3.4, but nobody guarantees they will work. There was
> no v3.3.1-rc1,

Few people test rc, and not all bugs or regressions can be detected by
just a build and a boot.

> so the first time the patches compromising v3.3.1 were
> generally tested together is in v3.3.1, at which point if somebody
> finds issues, it's too late; bad patches are *not* going to be removed
> in v3.3.2.

They would have been if the issue was specific to the backport, which it
was not.

> Once a tag is made, all the patches in it are dependent on
> the pace of the development of mainline (v3.4-rcx), which is
> definitely not stable, specially in the first release candidates.
> 
> IOW, the "stable" branch tries to be stable up to a point, then, it
> becomes a testing ground for mainline, and a tracking device for
> certain mainline issues.

No it's the opposite, it tries to be stable past one point. It's well
known that first stable releases still have a number of bugs, and it's
the reason why Greg takes time to maintain multiple branches in parallel.
Please stop playing the fool, everybody understands this and you make it
appear like bugs are put in stable on purpose, your reasoning really does
not make sense.

Please fork the kernel and maintain your own "morestable" branch, it will
be useful, really, because it will mean that whatever you have in your
branch that is not in stable has to be fixed in mainline, so it will hold
the information Linus wants not to lose. This is a lot of work but you'll
get it done without asking anyone else to do it. I'm not kidding, I'd
probably use it if it's maintained long enough.

Willy

[ath9k-devel] [ 00/78] 3.3.2-stable review

[Willy Tarreau]

On Sat, Apr 14, 2012 at 01:53:22AM +0300, Felipe Contreras wrote:
> No, I don't want the latest fixes, I want the latest *stable* kernel.

You have it, it's 3.3.2.

> v3.3 is stable, v3.4-rcx are not.

v3.3 *aims to be stable*. That's the big difference. A kernel starts
unstable and converges to something more stable over the time. 2.4 was
still experiencing minor issues that we didn't have in 2.6 when I did
the last release. There were even some security issues we decided not
to fix and to document instead. Still for its users it was considered
much more stable than 2.6 or 3.x.

> v3.4 would take months to cook,
> there will be several release candidates, and it won't be released
> until the known issues decrease to a reasonable level.
> 
> v3.3.x on the other hand are *not* stable.

Nobody said they *are* stable as per the definition of this word.
"stable" is the name of the branch which defines the longterm goal
which is achieved as releases are issued. It's the same with longterm
kernels. They try to maintain even less bugs and try to to introduce
new ones, eventhough this happens from time to time, development is
not an exact science.

> They contain patches
> backported from v3.4, but nobody guarantees they will work. There was
> no v3.3.1-rc1,

Few people test rc, and not all bugs or regressions can be detected by
just a build and a boot.

> so the first time the patches compromising v3.3.1 were
> generally tested together is in v3.3.1, at which point if somebody
> finds issues, it's too late; bad patches are *not* going to be removed
> in v3.3.2.

They would have been if the issue was specific to the backport, which it
was not.

> Once a tag is made, all the patches in it are dependent on
> the pace of the development of mainline (v3.4-rcx), which is
> definitely not stable, specially in the first release candidates.
> 
> IOW, the "stable" branch tries to be stable up to a point, then, it
> becomes a testing ground for mainline, and a tracking device for
> certain mainline issues.

No it's the opposite, it tries to be stable past one point. It's well
known that first stable releases still have a number of bugs, and it's
the reason why Greg takes time to maintain multiple branches in parallel.
Please stop playing the fool, everybody understands this and you make it
appear like bugs are put in stable on purpose, your reasoning really does
not make sense.

Please fork the kernel and maintain your own "morestable" branch, it will
be useful, really, because it will mean that whatever you have in your
branch that is not in stable has to be fixed in mainline, so it will hold
the information Linus wants not to lose. This is a lot of work but you'll
get it done without asking anyone else to do it. I'm not kidding, I'd
probably use it if it's maintained long enough.

Willy

Re: [ 31/78] ath9k: fix max noise floor threshold

[Rajkumar Manoharan]

On Sat, Apr 14, 2012 at 06:36:12AM +0100, Ben Hutchings wrote:
> On Wed, 2012-04-11 at 16:10 -0700, Greg KH wrote:
> > 3.3-stable review patch.  If anyone has any objections, please let me know.
> > 
> > ------------------
> > 
> > From: Rajkumar Manoharan <rmanohar@qca.qualcomm.com>
> > 
> > commit 2ee0a07028d2cde6e131b73f029dae2b93c50f3a upstream.
> > 
> > Currently the maximum noise floor limit is set as too high (-60dB). The
> > assumption of having a higher threshold limit is that it would help
> > de-sensitize the receiver (reduce phy errors) from continuous
> > interference. But when we have a bursty interference where there are
> > collisions and then free air time and if the receiver is desensitized too
> > much, it will miss the normal packets too. Lets make use of chips
> > specific min, nom and max limits always. This patch helps to improve the
> > connection stability in congested networks.
> [...]
> 
> It looks like this is also applicable to 3.0 and 3.2, but the debug
> logging statement changed between 3.2 and 3.3 and stopped this from
> applying directly.  Attaching an (untested) backport.
> 
Thanks a lot Ben. looks fine.

-Rajkumar
> 
> -- 
> Ben Hutchings
> It is easier to change the specification to fit the program than vice versa.

> From 6d19cb7b3325e6c460db0f07f178793f4500783a Mon Sep 17 00:00:00 2001
> From: Rajkumar Manoharan <rmanohar@qca.qualcomm.com>
> Date: Thu, 15 Mar 2012 06:08:04 +0530
> Subject: [PATCH] ath9k: fix max noise floor threshold
> 
> commit 2ee0a07028d2cde6e131b73f029dae2b93c50f3a upstream.
> 
> Currently the maximum noise floor limit is set as too high (-60dB). The
> assumption of having a higher threshold limit is that it would help
> de-sensitize the receiver (reduce phy errors) from continuous
> interference. But when we have a bursty interference where there are
> collisions and then free air time and if the receiver is desensitized too
> much, it will miss the normal packets too. Lets make use of chips
> specific min, nom and max limits always. This patch helps to improve the
> connection stability in congested networks.
> 
> Cc: Paul Stewart <pstew@google.com>
> Tested-by: Gary Morain <gmorain@google.com>
> Signed-off-by: Madhan Jaganathan <madhanj@qca.qualcomm.com>
> Signed-off-by: Rajkumar Manoharan <rmanohar@qca.qualcomm.com>
> Signed-off-by: John W. Linville <linville@tuxdriver.com>
> [bwh: Backported to 3.0/3.2: adjust context]
> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
> ---
>  drivers/net/wireless/ath/ath9k/calib.c |    5 ++---
>  1 file changed, 2 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/net/wireless/ath/ath9k/calib.c b/drivers/net/wireless/ath/ath9k/calib.c
> index 8ddef3e..d771de5 100644
> --- a/drivers/net/wireless/ath/ath9k/calib.c
> +++ b/drivers/net/wireless/ath/ath9k/calib.c
> @@ -20,7 +20,6 @@
>  
>  /* Common calibration code */
>  
> -#define ATH9K_NF_TOO_HIGH	-60
>  
>  static int16_t ath9k_hw_get_nf_hist_mid(int16_t *nfCalBuffer)
>  {
> @@ -348,10 +347,10 @@ static void ath9k_hw_nf_sanitize(struct ath_hw *ah, s16 *nf)
>  			"NF calibrated [%s] [chain %d] is %d\n",
>  			(i >= 3 ? "ext" : "ctl"), i % 3, nf[i]);
>  
> -		if (nf[i] > ATH9K_NF_TOO_HIGH) {
> +		if (nf[i] > limit->max) {
>  			ath_dbg(common, ATH_DBG_CALIBRATE,
>  				"NF[%d] (%d) > MAX (%d), correcting to MAX\n",
> -				i, nf[i], ATH9K_NF_TOO_HIGH);
> +				i, nf[i], limit->max);
>  			nf[i] = limit->max;
>  		} else if (nf[i] < limit->min) {
>  			ath_dbg(common, ATH_DBG_CALIBRATE,
> -- 
> 1.7.9.5
> 

Re: [ 00/78] 3.3.2-stable review

[Stefan Richter]

On Apr 14 Felipe Contreras wrote:
> I already exemplified how they are very different, but here it goes
> again. The patch "drm/i915: Add lock on drm_helper_resume_force_mode"
> was just tagged in 3.3.2, if I had said yesterday "this patch breaks
> things on my machine", then that patch would have been dropped for
> 3.3.2 even though it's still on mainline--why? Because we know it's
> broken, and broken patches are not supposed to land to stable. But
> today, one day later, we have to wait until it's fixed in master
> first. Why?
> 
> What makes a patch droppable yesterday, but dependent on mainline today?

Huh?

Because "yesterday" was a review before stable release:
  - A buggy mainline release exists.
  - No buggy stable release exists.
whereas "today" is after stable release:
  - A buggy mainline release exists.
  - A buggy stable release exists.

(The WLAN breakage wich is being talked about was reported after
release, not during review, right?)

[quote re-ordered]
> Again, you can repeat the same thing as much as you want, it still
> doesn't answer what I have asked.

Yeah, sorry for that.  All the time I thought you asked why a *revert*
which is applicable to mainline and stable first happens in stable.

But your question was actually what the difference between
  - dropping a patch from a queue of candidate patches versus
  - adding a reverting patch to repair a defect from a previous release
is.

The former is still part of the decision whether a changeset which
exists in mainline should be backported into stable.  Somebody initially
thought it should be, but others should have a look too and amend that
decision if need be.  Somebody reports that the change would introduce a
regression.  Usually, this disqualifies a patch from being applied to
stable right away, without further work having to be done in stable.

"Drop a stable candidate before release" is a form of "decline a
submission to stable", happening late in the preparations of a stable
release.

The latter is when damage was done; it is now about bug fixing.  This
involves debugging of the regression, finding a right approach to
fix it (e.g. revert), write + review + test + commit the fix, port the fix
to all relevant other kernel branches, review + test + commit those ports
too.

"Add a reverting fix" is a form of "add a fix".

You are indeed pointing to a procedural flaw here.  In "add a fix" cases,
stable release procedures ensure that if 3.3.3 included the revert, 3.4
will include it to, by the Linus->Greg order of commiting patches. But in
the "drop a candidate before release" case, Greg and the stable reviewers
do not have a similarly fool-proof procedure to ensure that the next branch
point will be free of the regression.  Now they need to watch closely that
a fix gets into mainline ideally before the next branch point is going to
be released.

So there is indeed a difficulty involved with dropping patches from the
candidate queue.  Fortunately, it is not necessary to subject post-release
reverts to the same difficulty.

> This of course, has *not* been explained.

Others had discussed "not adding a changeset" versus "amending an already
released changeset by another changeset on top of it" already.  Now I did
too and apologize to everybody else for redundancy.
-- 
Stefan Richter
-=====-===-- -=-- -===-
http://arcgraph.de/sr/

[ath9k-devel] [ 00/78] 3.3.2-stable review

[Stefan Richter]

On Apr 14 Felipe Contreras wrote:
> I already exemplified how they are very different, but here it goes
> again. The patch "drm/i915: Add lock on drm_helper_resume_force_mode"
> was just tagged in 3.3.2, if I had said yesterday "this patch breaks
> things on my machine", then that patch would have been dropped for
> 3.3.2 even though it's still on mainline--why? Because we know it's
> broken, and broken patches are not supposed to land to stable. But
> today, one day later, we have to wait until it's fixed in master
> first. Why?
> 
> What makes a patch droppable yesterday, but dependent on mainline today?

Huh?

Because "yesterday" was a review before stable release:
  - A buggy mainline release exists.
  - No buggy stable release exists.
whereas "today" is after stable release:
  - A buggy mainline release exists.
  - A buggy stable release exists.

(The WLAN breakage wich is being talked about was reported after
release, not during review, right?)

[quote re-ordered]
> Again, you can repeat the same thing as much as you want, it still
> doesn't answer what I have asked.

Yeah, sorry for that.  All the time I thought you asked why a *revert*
which is applicable to mainline and stable first happens in stable.

But your question was actually what the difference between
  - dropping a patch from a queue of candidate patches versus
  - adding a reverting patch to repair a defect from a previous release
is.

The former is still part of the decision whether a changeset which
exists in mainline should be backported into stable.  Somebody initially
thought it should be, but others should have a look too and amend that
decision if need be.  Somebody reports that the change would introduce a
regression.  Usually, this disqualifies a patch from being applied to
stable right away, without further work having to be done in stable.

"Drop a stable candidate before release" is a form of "decline a
submission to stable", happening late in the preparations of a stable
release.

The latter is when damage was done; it is now about bug fixing.  This
involves debugging of the regression, finding a right approach to
fix it (e.g. revert), write + review + test + commit the fix, port the fix
to all relevant other kernel branches, review + test + commit those ports
too.

"Add a reverting fix" is a form of "add a fix".

You are indeed pointing to a procedural flaw here.  In "add a fix" cases,
stable release procedures ensure that if 3.3.3 included the revert, 3.4
will include it to, by the Linus->Greg order of commiting patches. But in
the "drop a candidate before release" case, Greg and the stable reviewers
do not have a similarly fool-proof procedure to ensure that the next branch
point will be free of the regression.  Now they need to watch closely that
a fix gets into mainline ideally before the next branch point is going to
be released.

So there is indeed a difficulty involved with dropping patches from the
candidate queue.  Fortunately, it is not necessary to subject post-release
reverts to the same difficulty.

> This of course, has *not* been explained.

Others had discussed "not adding a changeset" versus "amending an already
released changeset by another changeset on top of it" already.  Now I did
too and apologize to everybody else for redundancy.
-- 
Stefan Richter
-=====-===-- -=-- -===-
http://arcgraph.de/sr/

Re: [ 00/78] 3.3.2-stable review

[Stefan Richter]

On Apr 14 Felipe Contreras wrote:
> On Sat, Apr 14, 2012 at 2:05 AM, Jonathan Nieder <jrnieder@gmail.com> wrote:
> > I don't think Stefan meant the above as tongue-in-cheek, for what it's
> > worth.  Another stable kernel with different rules really would be an
> > interesting exercise, and would probably fulfill a need for a certain
> > audience.
> >
> > It's not like nobody does that already, anyway.  For example, I hear
> > Fedora has a kernel that they maintain well for a different audience,
> > using different rules.
> 
> Of course, although the difference with the stable kernel would be
> very small if the only thing added is an extra rule for acceptance:
> "It reverts an earlier
> patch to 'stable'."

It looks like a small difference on the surface, but it isn't.  It would
mean "yes, we /do/ forward ports in -stable too in some cases".

In face of the frequent and predictable rate of mainline releases and the
very frequent stable releases, the problems associated with forward ports
very much appear to outweigh the benefits.

So the folks who do the actual work appear to be content with stable =
backports only, and it seems you can't convince them to do forward ports.
Which means that if you really want forward ports, you need to find
somebody else who does forward ports (e.g. a suitable distributor) or do
them yourself.

> But "we do this, and if you don't like it you can do whatever you
> want" is not a valid argument in favor of the status quo,

That would not be a valid argument, no.  But it has been mentioned /why/
only backports are done in stable, i.e. what the problems with forward
ports are:

  - First of all more work.  (Could be compensated by longer periods
    between stable releases, which would be an obvious downside too,
    and actually defeat much of the purpose of the stable series of
    getting out fixes to people.)

  - Backports are already risky, which is why only /small/ backports are
    allowed into stable.  Forward ports bring their own set of risks.
    Inevitably, users of the kernel called "stable" will get even
    more reason to wonder why this series is not "stable" in a sense of
    "absolutely free of regressions".

    For example, merging subsystem development trees into the mainline is
    actually a forward port.  The mainline is at risk not only because
    that subsystem tree hasn't had as much exposure to hardware and
    workloads as the mainline will have, but additionally because the
    merge result is different from the subsystem tree head.  (The result
    is a forward port.)  Mainline development uses for example the
    linux-next tree in order to reduce a subset of these forward porting
    risks, those associated with conflicting developments in different
    subsystems and cross-tree development.  Which kinds of tools should
    stable use if it were to accept forward ports?

    So, rather than managing the risk of forward ports in stable, those
    risks are systematically avoided by not ever doing forward ports, not
    even small ones.

  - The mainline would not immediately benefit from the work put into
    forward ports in stable.  Worse, fixes in those forward ports might
    not ever make it into the mainline.  That would be detrimental to all
    mainline users, and thus to all stable users.  (Stable users are
    mainline users because stable is branched off of mainline every 2.5
    months.)

These downsides have been mentioned in the thread; please consider them.
It is not about "we¹ do this because we are set in our ways".  The stable
rules have pragmatic reasons which are for example founded on lessons
learned from the 2.4/2.5/2.6 history of development, maintenance, and
distribution.

So there are arguments for the status quo, the arguments have been
mentioned several times, and I can't see what would invalidate any of
these arguments.

--------
¹) Greg, if you are still reading this thread:  Excuse the 'we', I do not
mean to speak for you.

Besides, Greg, thank you for the work.  As a driver maintainer and when
supporting end users, I benefit from it since distributor kernels do not
deviate much from mainline these days, among else thanks to your stable
and longterm series.  And it is an important way for me to get certain
driver fixes delivered to users conveniently and timely.
-- 
Stefan Richter
-=====-===-- -=-- -===-
http://arcgraph.de/sr/

[ath9k-devel] [ 00/78] 3.3.2-stable review

[Stefan Richter]

On Apr 14 Felipe Contreras wrote:
> On Sat, Apr 14, 2012 at 2:05 AM, Jonathan Nieder <jrnieder@gmail.com> wrote:
> > I don't think Stefan meant the above as tongue-in-cheek, for what it's
> > worth. ?Another stable kernel with different rules really would be an
> > interesting exercise, and would probably fulfill a need for a certain
> > audience.
> >
> > It's not like nobody does that already, anyway. ?For example, I hear
> > Fedora has a kernel that they maintain well for a different audience,
> > using different rules.
> 
> Of course, although the difference with the stable kernel would be
> very small if the only thing added is an extra rule for acceptance:
> "It reverts an earlier
> patch to 'stable'."

It looks like a small difference on the surface, but it isn't.  It would
mean "yes, we /do/ forward ports in -stable too in some cases".

In face of the frequent and predictable rate of mainline releases and the
very frequent stable releases, the problems associated with forward ports
very much appear to outweigh the benefits.

So the folks who do the actual work appear to be content with stable =
backports only, and it seems you can't convince them to do forward ports.
Which means that if you really want forward ports, you need to find
somebody else who does forward ports (e.g. a suitable distributor) or do
them yourself.

> But "we do this, and if you don't like it you can do whatever you
> want" is not a valid argument in favor of the status quo,

That would not be a valid argument, no.  But it has been mentioned /why/
only backports are done in stable, i.e. what the problems with forward
ports are:

  - First of all more work.  (Could be compensated by longer periods
    between stable releases, which would be an obvious downside too,
    and actually defeat much of the purpose of the stable series of
    getting out fixes to people.)

  - Backports are already risky, which is why only /small/ backports are
    allowed into stable.  Forward ports bring their own set of risks.
    Inevitably, users of the kernel called "stable" will get even
    more reason to wonder why this series is not "stable" in a sense of
    "absolutely free of regressions".

    For example, merging subsystem development trees into the mainline is
    actually a forward port.  The mainline is at risk not only because
    that subsystem tree hasn't had as much exposure to hardware and
    workloads as the mainline will have, but additionally because the
    merge result is different from the subsystem tree head.  (The result
    is a forward port.)  Mainline development uses for example the
    linux-next tree in order to reduce a subset of these forward porting
    risks, those associated with conflicting developments in different
    subsystems and cross-tree development.  Which kinds of tools should
    stable use if it were to accept forward ports?

    So, rather than managing the risk of forward ports in stable, those
    risks are systematically avoided by not ever doing forward ports, not
    even small ones.

  - The mainline would not immediately benefit from the work put into
    forward ports in stable.  Worse, fixes in those forward ports might
    not ever make it into the mainline.  That would be detrimental to all
    mainline users, and thus to all stable users.  (Stable users are
    mainline users because stable is branched off of mainline every 2.5
    months.)

These downsides have been mentioned in the thread; please consider them.
It is not about "we? do this because we are set in our ways".  The stable
rules have pragmatic reasons which are for example founded on lessons
learned from the 2.4/2.5/2.6 history of development, maintenance, and
distribution.

So there are arguments for the status quo, the arguments have been
mentioned several times, and I can't see what would invalidate any of
these arguments.

--------
?) Greg, if you are still reading this thread:  Excuse the 'we', I do not
mean to speak for you.

Besides, Greg, thank you for the work.  As a driver maintainer and when
supporting end users, I benefit from it since distributor kernels do not
deviate much from mainline these days, among else thanks to your stable
and longterm series.  And it is an important way for me to get certain
driver fixes delivered to users conveniently and timely.
-- 
Stefan Richter
-=====-===-- -=-- -===-
http://arcgraph.de/sr/

Re: [ 00/78] 3.3.2-stable review

[Ingo Molnar]

* Felipe Contreras <felipe.contreras@gmail.com> wrote:

> On Fri, Apr 13, 2012 at 1:07 AM, Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
> > On Thu, Apr 12, 2012 at 3:04 PM, Felipe Contreras
> > <felipe.contreras@gmail.com> wrote:
> >>
> >> Sure, but removing that patch from the stable tree is not 
> >> going the change that information; we already know the 
> >> patch is wrong.
> >
> > .. and we wait until it has been fixed in mainline so that 
> > we *know* that information doesn't get lost.
> 
> So why don't we pick potentially dangerous patches that might 
> benefit from some testing, put them in 'stable', and if there 
> are problems, make sure they get fixed in upstream first?
>
> Or for that matter totally broken patches we want to make sure 
> they get fixed in upstream.
> 
> Because the priority of the 'stable' tree is *stability*. Is 
> it not?
> 
> But what you are saying is: *before* the final review, even a 
> hint that the patch might cause problems is reason enough to 
> drop it from stable, but *after* the review, if we know the 
> patch is totally broken, then it's the opposite; we really 
> want it in.

What you don't seem to understand is that there are good reasons 
why we first fix bugs upstream, then in -stable. Greg explained 
it to you, Linus explained it to you and so did many others.

Having an order of patches *necessarily* means that the 
development tree will get fixes sooner than the stable tree. In 
other words, this *necessarily* means that the stable tree - and 
its users - will have to wait a little bit more to have the fix. 
In the worst-case this 'have to wait a little bit longer' might 
span the time between two minor stable kernel releases.

You seem to equate this 'have to wait a little bit longer to get 
the fix' property of the maintenance model with 'we don't care 
about stable tree users' - that claim is obviously idiotic and 
most of your arguments in this thread are idiotic as well.

Thanks,

	Ingo

[ath9k-devel] [ 00/78] 3.3.2-stable review

[Ingo Molnar]

* Felipe Contreras <felipe.contreras@gmail.com> wrote:

> On Fri, Apr 13, 2012 at 1:07 AM, Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
> > On Thu, Apr 12, 2012 at 3:04 PM, Felipe Contreras
> > <felipe.contreras@gmail.com> wrote:
> >>
> >> Sure, but removing that patch from the stable tree is not 
> >> going the change that information; we already know the 
> >> patch is wrong.
> >
> > .. and we wait until it has been fixed in mainline so that 
> > we *know* that information doesn't get lost.
> 
> So why don't we pick potentially dangerous patches that might 
> benefit from some testing, put them in 'stable', and if there 
> are problems, make sure they get fixed in upstream first?
>
> Or for that matter totally broken patches we want to make sure 
> they get fixed in upstream.
> 
> Because the priority of the 'stable' tree is *stability*. Is 
> it not?
> 
> But what you are saying is: *before* the final review, even a 
> hint that the patch might cause problems is reason enough to 
> drop it from stable, but *after* the review, if we know the 
> patch is totally broken, then it's the opposite; we really 
> want it in.

What you don't seem to understand is that there are good reasons 
why we first fix bugs upstream, then in -stable. Greg explained 
it to you, Linus explained it to you and so did many others.

Having an order of patches *necessarily* means that the 
development tree will get fixes sooner than the stable tree. In 
other words, this *necessarily* means that the stable tree - and 
its users - will have to wait a little bit more to have the fix. 
In the worst-case this 'have to wait a little bit longer' might 
span the time between two minor stable kernel releases.

You seem to equate this 'have to wait a little bit longer to get 
the fix' property of the maintenance model with 'we don't care 
about stable tree users' - that claim is obviously idiotic and 
most of your arguments in this thread are idiotic as well.

Thanks,

	Ingo

Re: [ 00/78] 3.3.2-stable review

[Felipe Contreras]

On Sat, Apr 14, 2012 at 10:41 AM, Stefan Richter
<stefanr@s5r6.in-berlin.de> wrote:
> On Apr 14 Felipe Contreras wrote:
>> I already exemplified how they are very different, but here it goes
>> again. The patch "drm/i915: Add lock on drm_helper_resume_force_mode"
>> was just tagged in 3.3.2, if I had said yesterday "this patch breaks
>> things on my machine", then that patch would have been dropped for
>> 3.3.2 even though it's still on mainline--why? Because we know it's
>> broken, and broken patches are not supposed to land to stable. But
>> today, one day later, we have to wait until it's fixed in master
>> first. Why?
>>
>> What makes a patch droppable yesterday, but dependent on mainline today?
>
> Huh?
>
> Because "yesterday" was a review before stable release:
>  - A buggy mainline release exists.
>  - No buggy stable release exists.
> whereas "today" is after stable release:
>  - A buggy mainline release exists.
>  - A buggy stable release exists.

IOW; a tag makes undroppable.

But *why*? You say you *really* need to problem to fixed in mainline,
that's why it cannot be dropped, but that applies also to patches in
the queue *before* the tag is made, doesn't it? If you find a patch in
the stable review queue causes problems, why don't you leave it there?
You *really* need to problem fixed in mainline, don't you?

So yesterday the priority is stability > 'upstream first', but today
it's 'upstream first' > stability. Nobody has put forward an argument
for this shift in priorities--"a tag was made" is not argument.

> (The WLAN breakage wich is being talked about was reported after
> release, not during review, right?)

Yeah, this is a hypothetical thought experiment to demonstrate the
shift in priorities.

> [quote re-ordered]
>> Again, you can repeat the same thing as much as you want, it still
>> doesn't answer what I have asked.
>
> Yeah, sorry for that.  All the time I thought you asked why a *revert*
> which is applicable to mainline and stable first happens in stable.
>
> But your question was actually what the difference between
>  - dropping a patch from a queue of candidate patches versus
>  - adding a reverting patch to repair a defect from a previous release
> is.

Yes, that is one of my arguments.

> The former is still part of the decision whether a changeset which
> exists in mainline should be backported into stable.  Somebody initially
> thought it should be, but others should have a look too and amend that
> decision if need be.  Somebody reports that the change would introduce a
> regression.  Usually, this disqualifies a patch from being applied to
> stable right away, without further work having to be done in stable.
>
> "Drop a stable candidate before release" is a form of "decline a
> submission to stable", happening late in the preparations of a stable
> release.
>
> The latter is when damage was done; it is now about bug fixing.  This
> involves debugging of the regression, finding a right approach to
> fix it (e.g. revert), write + review + test + commit the fix, port the fix
> to all relevant other kernel branches, review + test + commit those ports
> too.

Really? So if the patch doesn't make it to stable you don't need to do
any of that? IOW; if the patch doesn't make it to stable, it's OK to
leave it broken for v3.4? There's 10000 patches in v3.4-rc* that are
all about bug fixing, they don't need to go into stable to be fixed,
do they? If a non-stable patch needs to be reverted in mainline, it
gets reverted in mainline, regardless of weather or not it made it to
stable or not.

So, the hypothetical patch that was dropped in the stable review queue
yesterday has to be fixed in mainline too, just like the hypothetical
patch that made it to stable and was found problematic today has to be
fixed in mainline.

Again, what makes a released patch undroppable? It's not the bug
fixing; weather or not it gets into stable, it still has to be fixed
in mainline.

> "Add a reverting fix" is a form of "add a fix".
>
> You are indeed pointing to a procedural flaw here.  In "add a fix" cases,
> stable release procedures ensure that if 3.3.3 included the revert, 3.4
> will include it to, by the Linus->Greg order of commiting patches. But in
> the "drop a candidate before release" case, Greg and the stable reviewers
> do not have a similarly fool-proof procedure to ensure that the next branch
> point will be free of the regression.  Now they need to watch closely that
> a fix gets into mainline ideally before the next branch point is going to
> be released.

I don't see the procedural flaw here. There's 10000 patches that never
go through the stable review process, and they don't need to. Somehow
v3.4 will be relatively OK. So the dropped patches from the stable
review queue will just receive the same treatment as any other patch.

Just by going through the stable review process the patch already
received more eyes to make the bugs more shallow. There might be a lot
of trees out there where people pick patches from mainline, and they
don't *need* to follow the "upstream first" rule, by reviewing the
patch, and maybe even testing it, and then reporting the problem, they
are helping getting it fixed for v3.4.

You don't *need* to keep the patch in the stable review queue, you
don't *need* to make a stable release with it in order to ensure that
it will fixed in mainline, the information about the patch problems is
not lost.

Seems to me you are abusing the 'stable' branch as a bug tracking
system for certain patches for the next release.

> So there is indeed a difficulty involved with dropping patches from the
> candidate queue.  Fortunately, it is not necessary to subject post-release
> reverts to the same difficulty.

It's the other way around.

-- 
Felipe Contreras

[ath9k-devel] [ 00/78] 3.3.2-stable review

[Felipe Contreras]

On Sat, Apr 14, 2012 at 10:41 AM, Stefan Richter
<stefanr@s5r6.in-berlin.de> wrote:
> On Apr 14 Felipe Contreras wrote:
>> I already exemplified how they are very different, but here it goes
>> again. The patch "drm/i915: Add lock on drm_helper_resume_force_mode"
>> was just tagged in 3.3.2, if I had said yesterday "this patch breaks
>> things on my machine", then that patch would have been dropped for
>> 3.3.2 even though it's still on mainline--why? Because we know it's
>> broken, and broken patches are not supposed to land to stable. But
>> today, one day later, we have to wait until it's fixed in master
>> first. Why?
>>
>> What makes a patch droppable yesterday, but dependent on mainline today?
>
> Huh?
>
> Because "yesterday" was a review before stable release:
> ?- A buggy mainline release exists.
> ?- No buggy stable release exists.
> whereas "today" is after stable release:
> ?- A buggy mainline release exists.
> ?- A buggy stable release exists.

IOW; a tag makes undroppable.

But *why*? You say you *really* need to problem to fixed in mainline,
that's why it cannot be dropped, but that applies also to patches in
the queue *before* the tag is made, doesn't it? If you find a patch in
the stable review queue causes problems, why don't you leave it there?
You *really* need to problem fixed in mainline, don't you?

So yesterday the priority is stability > 'upstream first', but today
it's 'upstream first' > stability. Nobody has put forward an argument
for this shift in priorities--"a tag was made" is not argument.

> (The WLAN breakage wich is being talked about was reported after
> release, not during review, right?)

Yeah, this is a hypothetical thought experiment to demonstrate the
shift in priorities.

> [quote re-ordered]
>> Again, you can repeat the same thing as much as you want, it still
>> doesn't answer what I have asked.
>
> Yeah, sorry for that. ?All the time I thought you asked why a *revert*
> which is applicable to mainline and stable first happens in stable.
>
> But your question was actually what the difference between
> ?- dropping a patch from a queue of candidate patches versus
> ?- adding a reverting patch to repair a defect from a previous release
> is.

Yes, that is one of my arguments.

> The former is still part of the decision whether a changeset which
> exists in mainline should be backported into stable. ?Somebody initially
> thought it should be, but others should have a look too and amend that
> decision if need be. ?Somebody reports that the change would introduce a
> regression. ?Usually, this disqualifies a patch from being applied to
> stable right away, without further work having to be done in stable.
>
> "Drop a stable candidate before release" is a form of "decline a
> submission to stable", happening late in the preparations of a stable
> release.
>
> The latter is when damage was done; it is now about bug fixing. ?This
> involves debugging of the regression, finding a right approach to
> fix it (e.g. revert), write + review + test + commit the fix, port the fix
> to all relevant other kernel branches, review + test + commit those ports
> too.

Really? So if the patch doesn't make it to stable you don't need to do
any of that? IOW; if the patch doesn't make it to stable, it's OK to
leave it broken for v3.4? There's 10000 patches in v3.4-rc* that are
all about bug fixing, they don't need to go into stable to be fixed,
do they? If a non-stable patch needs to be reverted in mainline, it
gets reverted in mainline, regardless of weather or not it made it to
stable or not.

So, the hypothetical patch that was dropped in the stable review queue
yesterday has to be fixed in mainline too, just like the hypothetical
patch that made it to stable and was found problematic today has to be
fixed in mainline.

Again, what makes a released patch undroppable? It's not the bug
fixing; weather or not it gets into stable, it still has to be fixed
in mainline.

> "Add a reverting fix" is a form of "add a fix".
>
> You are indeed pointing to a procedural flaw here. ?In "add a fix" cases,
> stable release procedures ensure that if 3.3.3 included the revert, 3.4
> will include it to, by the Linus->Greg order of commiting patches. But in
> the "drop a candidate before release" case, Greg and the stable reviewers
> do not have a similarly fool-proof procedure to ensure that the next branch
> point will be free of the regression. ?Now they need to watch closely that
> a fix gets into mainline ideally before the next branch point is going to
> be released.

I don't see the procedural flaw here. There's 10000 patches that never
go through the stable review process, and they don't need to. Somehow
v3.4 will be relatively OK. So the dropped patches from the stable
review queue will just receive the same treatment as any other patch.

Just by going through the stable review process the patch already
received more eyes to make the bugs more shallow. There might be a lot
of trees out there where people pick patches from mainline, and they
don't *need* to follow the "upstream first" rule, by reviewing the
patch, and maybe even testing it, and then reporting the problem, they
are helping getting it fixed for v3.4.

You don't *need* to keep the patch in the stable review queue, you
don't *need* to make a stable release with it in order to ensure that
it will fixed in mainline, the information about the patch problems is
not lost.

Seems to me you are abusing the 'stable' branch as a bug tracking
system for certain patches for the next release.

> So there is indeed a difficulty involved with dropping patches from the
> candidate queue. ?Fortunately, it is not necessary to subject post-release
> reverts to the same difficulty.

It's the other way around.

-- 
Felipe Contreras

Re: [ 00/78] 3.3.2-stable review

[Felipe Contreras]

On Sat, Apr 14, 2012 at 8:44 AM, Willy Tarreau <w@1wt.eu> wrote:

> Nobody has said it's perfect. Jonathan said it's "close" to perfect. I
> personally think it's the best tradeoff we could find between a perfectly
> stable branch and a perfect mainline. We manage to converge towards the
> best quality in both branches by accepting a small delay in -stable.

You are saying the same thing; it cannot be improved.

> The problem is that *you* don't accept to wait as soon as you know there's
> a bug,

I'm going to stop right here. You are making an eloquent argument for
something nobody is saying.

This is pure straw man argumentation, see the reply from Stefan
Richter, who seems to be the only person who is actually following the
argument I'm making.

> Reverting patches that were not appropriate for -stable happens from
> time to time, but only when the issue is specific to -stable (eg: build
> issues). Here what you don't seem to understand is that the bug was
> not specific to -stable but was present everywhere. So we had a bug
> in mainline that we put in -stable, and we want mainline to be fixed
> and we use -stable as a guarantee that mainline will be fixed. And it
> works and has never failed yet. That's not hard to understand I think.

I understand you use 'stable' as guarantee, and I know it works, but
do you *need* this guarantee?

And before you go on why you need this guarantee to avoid fixes to be
lost, this is an *entirely different thing*; we are not talking about
fixes in 'stable' that don't exist in mainline--for which there is
evidence that those caused problems in the past, we are talking about
reverting patches from 'stable' that are not part of the upstream
release from where the 'stable' branch was forked--*nobody* has showed
any evidence that this has happened before and caused issues.

Only Stefan Richter is trying to tackle this argument.

Cheers.

-- 
Felipe Contreras

[ath9k-devel] [ 00/78] 3.3.2-stable review

[Felipe Contreras]

On Sat, Apr 14, 2012 at 8:44 AM, Willy Tarreau <w@1wt.eu> wrote:

> Nobody has said it's perfect. Jonathan said it's "close" to perfect. I
> personally think it's the best tradeoff we could find between a perfectly
> stable branch and a perfect mainline. We manage to converge towards the
> best quality in both branches by accepting a small delay in -stable.

You are saying the same thing; it cannot be improved.

> The problem is that *you* don't accept to wait as soon as you know there's
> a bug,

I'm going to stop right here. You are making an eloquent argument for
something nobody is saying.

This is pure straw man argumentation, see the reply from Stefan
Richter, who seems to be the only person who is actually following the
argument I'm making.

> Reverting patches that were not appropriate for -stable happens from
> time to time, but only when the issue is specific to -stable (eg: build
> issues). Here what you don't seem to understand is that the bug was
> not specific to -stable but was present everywhere. So we had a bug
> in mainline that we put in -stable, and we want mainline to be fixed
> and we use -stable as a guarantee that mainline will be fixed. And it
> works and has never failed yet. That's not hard to understand I think.

I understand you use 'stable' as guarantee, and I know it works, but
do you *need* this guarantee?

And before you go on why you need this guarantee to avoid fixes to be
lost, this is an *entirely different thing*; we are not talking about
fixes in 'stable' that don't exist in mainline--for which there is
evidence that those caused problems in the past, we are talking about
reverting patches from 'stable' that are not part of the upstream
release from where the 'stable' branch was forked--*nobody* has showed
any evidence that this has happened before and caused issues.

Only Stefan Richter is trying to tackle this argument.

Cheers.

-- 
Felipe Contreras

Re: [ 00/78] 3.3.2-stable review

[Felipe Contreras]

On Sat, Apr 14, 2012 at 12:10 PM, Stefan Richter
<stefanr@s5r6.in-berlin.de> wrote:
> On Apr 14 Felipe Contreras wrote:

>> Of course, although the difference with the stable kernel would be
>> very small if the only thing added is an extra rule for acceptance:
>> "It reverts an earlier patch to 'stable'."
>
> It looks like a small difference on the surface, but it isn't.  It would
> mean "yes, we /do/ forward ports in -stable too in some cases".

How? There's a lot reverts in mainline, where do they come from? Are
they forward ports from some ghost trees?

If you drop a patch from the stable review queue before it gets into a
stable release, and then that patch is reverted from mainline, is that
also a "forward port"?

-- 
Felipe Contreras

[ath9k-devel] [ 00/78] 3.3.2-stable review

[Felipe Contreras]

On Sat, Apr 14, 2012 at 12:10 PM, Stefan Richter
<stefanr@s5r6.in-berlin.de> wrote:
> On Apr 14 Felipe Contreras wrote:

>> Of course, although the difference with the stable kernel would be
>> very small if the only thing added is an extra rule for acceptance:
>> "It reverts an earlier patch to 'stable'."
>
> It looks like a small difference on the surface, but it isn't. ?It would
> mean "yes, we /do/ forward ports in -stable too in some cases".

How? There's a lot reverts in mainline, where do they come from? Are
they forward ports from some ghost trees?

If you drop a patch from the stable review queue before it gets into a
stable release, and then that patch is reverted from mainline, is that
also a "forward port"?

-- 
Felipe Contreras

Re: [ 00/78] 3.3.2-stable review

[Willy Tarreau]

On Sat, Apr 14, 2012 at 06:29:54PM +0300, Felipe Contreras wrote:
> So, the hypothetical patch that was dropped in the stable review queue
> yesterday has to be fixed in mainline too, just like the hypothetical
> patch that made it to stable and was found problematic today has to be
> fixed in mainline.

Patches are not always dropped from the stable queue if we know they're
causing issues, sometimes they're left pending in the queue. This is how
Greg is able to ping developers from time to time.

> Again, what makes a released patch undroppable?

Being applied, in other words, having a commit ID in the branch.

(...)
> Just by going through the stable review process the patch already
> received more eyes to make the bugs more shallow. There might be a lot
> of trees out there where people pick patches from mainline, and they
> don't *need* to follow the "upstream first" rule, by reviewing the
> patch, and maybe even testing it, and then reporting the problem, they
> are helping getting it fixed for v3.4.

They do what they want with their trees. I have a number of patches in my
trees that are not worth pushing to mainline and that's fine. However the
rule is that the official stable tree has to hold patches that come from
mainline.

> You don't *need* to keep the patch in the stable review queue, you
> don't *need* to make a stable release with it in order to ensure that
> it will fixed in mainline, the information about the patch problems is
> not lost.

It's lost since nobody cares once their kernel is fixed. For instance, I
have an issue with 3.0.x on my netbook which I haven't had time to bisect
(no resume from s2r). But 3.2 works. If I find that the issue was introduced
in any stable backport, we'll have to ensure that mainline has the fix,
because the bug might simply be hidden in 3.2 but still present. If we'd
just revert the fix from 3.0, what would motivate anyone to fix mainline
if it appears to work ?

> Seems to me you are abusing the 'stable' branch as a bug tracking
> system for certain patches for the next release.

The most reliable bug tracking system are the end users. They're the only
one who remind you to get their fix merged. And you did this yourself,
quite louder than the average I'd say, but it worked perfectly again.

Willy

[ath9k-devel] [ 00/78] 3.3.2-stable review

[Willy Tarreau]

On Sat, Apr 14, 2012 at 06:29:54PM +0300, Felipe Contreras wrote:
> So, the hypothetical patch that was dropped in the stable review queue
> yesterday has to be fixed in mainline too, just like the hypothetical
> patch that made it to stable and was found problematic today has to be
> fixed in mainline.

Patches are not always dropped from the stable queue if we know they're
causing issues, sometimes they're left pending in the queue. This is how
Greg is able to ping developers from time to time.

> Again, what makes a released patch undroppable?

Being applied, in other words, having a commit ID in the branch.

(...)
> Just by going through the stable review process the patch already
> received more eyes to make the bugs more shallow. There might be a lot
> of trees out there where people pick patches from mainline, and they
> don't *need* to follow the "upstream first" rule, by reviewing the
> patch, and maybe even testing it, and then reporting the problem, they
> are helping getting it fixed for v3.4.

They do what they want with their trees. I have a number of patches in my
trees that are not worth pushing to mainline and that's fine. However the
rule is that the official stable tree has to hold patches that come from
mainline.

> You don't *need* to keep the patch in the stable review queue, you
> don't *need* to make a stable release with it in order to ensure that
> it will fixed in mainline, the information about the patch problems is
> not lost.

It's lost since nobody cares once their kernel is fixed. For instance, I
have an issue with 3.0.x on my netbook which I haven't had time to bisect
(no resume from s2r). But 3.2 works. If I find that the issue was introduced
in any stable backport, we'll have to ensure that mainline has the fix,
because the bug might simply be hidden in 3.2 but still present. If we'd
just revert the fix from 3.0, what would motivate anyone to fix mainline
if it appears to work ?

> Seems to me you are abusing the 'stable' branch as a bug tracking
> system for certain patches for the next release.

The most reliable bug tracking system are the end users. They're the only
one who remind you to get their fix merged. And you did this yourself,
quite louder than the average I'd say, but it worked perfectly again.

Willy

Re: [ 00/78] 3.3.2-stable review

[Felipe Contreras]

On Sat, Apr 14, 2012 at 1:47 PM, Ingo Molnar <mingo@kernel.org> wrote:
>
> * Felipe Contreras <felipe.contreras@gmail.com> wrote:
>
>> On Fri, Apr 13, 2012 at 1:07 AM, Linus Torvalds
>> <torvalds@linux-foundation.org> wrote:
>> > On Thu, Apr 12, 2012 at 3:04 PM, Felipe Contreras
>> > <felipe.contreras@gmail.com> wrote:
>> >>
>> >> Sure, but removing that patch from the stable tree is not
>> >> going the change that information; we already know the
>> >> patch is wrong.
>> >
>> > .. and we wait until it has been fixed in mainline so that
>> > we *know* that information doesn't get lost.
>>
>> So why don't we pick potentially dangerous patches that might
>> benefit from some testing, put them in 'stable', and if there
>> are problems, make sure they get fixed in upstream first?
>>
>> Or for that matter totally broken patches we want to make sure
>> they get fixed in upstream.
>>
>> Because the priority of the 'stable' tree is *stability*. Is
>> it not?
>>
>> But what you are saying is: *before* the final review, even a
>> hint that the patch might cause problems is reason enough to
>> drop it from stable, but *after* the review, if we know the
>> patch is totally broken, then it's the opposite; we really
>> want it in.
>
> What you don't seem to understand is that there are good reasons
> why we first fix bugs upstream, then in -stable. Greg explained
> it to you, Linus explained it to you and so did many others.
>
> Having an order of patches *necessarily* means that the
> development tree will get fixes sooner than the stable tree. In
> other words, this *necessarily* means that the stable tree - and
> its users - will have to wait a little bit more to have the fix.
> In the worst-case this 'have to wait a little bit longer' might
> span the time between two minor stable kernel releases.
>
> You seem to equate this 'have to wait a little bit longer to get
> the fix' property of the maintenance model with 'we don't care
> about stable tree users' - that claim is obviously idiotic and
> most of your arguments in this thread are idiotic as well.

This is a straw man again. Again; we are not talking about fixes in
'stable' that don't exist in mainline, we are talking about reverting
patches from 'stable' that are not part of the upstream release from
where the 'stable' branch was forked.

You are avoiding the argument you replying to; yesterday a patch was
droppable from the stable review queue, but today, after the release,
now we *need* it to stay there until it's fixed in the mainline. What
changed?

What makes a patch droppable yesterday, but dependent on mainline today?

-- 
Felipe Contreras

[ath9k-devel] [ 00/78] 3.3.2-stable review

[Felipe Contreras]

On Sat, Apr 14, 2012 at 1:47 PM, Ingo Molnar <mingo@kernel.org> wrote:
>
> * Felipe Contreras <felipe.contreras@gmail.com> wrote:
>
>> On Fri, Apr 13, 2012 at 1:07 AM, Linus Torvalds
>> <torvalds@linux-foundation.org> wrote:
>> > On Thu, Apr 12, 2012 at 3:04 PM, Felipe Contreras
>> > <felipe.contreras@gmail.com> wrote:
>> >>
>> >> Sure, but removing that patch from the stable tree is not
>> >> going the change that information; we already know the
>> >> patch is wrong.
>> >
>> > .. and we wait until it has been fixed in mainline so that
>> > we *know* that information doesn't get lost.
>>
>> So why don't we pick potentially dangerous patches that might
>> benefit from some testing, put them in 'stable', and if there
>> are problems, make sure they get fixed in upstream first?
>>
>> Or for that matter totally broken patches we want to make sure
>> they get fixed in upstream.
>>
>> Because the priority of the 'stable' tree is *stability*. Is
>> it not?
>>
>> But what you are saying is: *before* the final review, even a
>> hint that the patch might cause problems is reason enough to
>> drop it from stable, but *after* the review, if we know the
>> patch is totally broken, then it's the opposite; we really
>> want it in.
>
> What you don't seem to understand is that there are good reasons
> why we first fix bugs upstream, then in -stable. Greg explained
> it to you, Linus explained it to you and so did many others.
>
> Having an order of patches *necessarily* means that the
> development tree will get fixes sooner than the stable tree. In
> other words, this *necessarily* means that the stable tree - and
> its users - will have to wait a little bit more to have the fix.
> In the worst-case this 'have to wait a little bit longer' might
> span the time between two minor stable kernel releases.
>
> You seem to equate this 'have to wait a little bit longer to get
> the fix' property of the maintenance model with 'we don't care
> about stable tree users' - that claim is obviously idiotic and
> most of your arguments in this thread are idiotic as well.

This is a straw man again. Again; we are not talking about fixes in
'stable' that don't exist in mainline, we are talking about reverting
patches from 'stable' that are not part of the upstream release from
where the 'stable' branch was forked.

You are avoiding the argument you replying to; yesterday a patch was
droppable from the stable review queue, but today, after the release,
now we *need* it to stay there until it's fixed in the mainline. What
changed?

What makes a patch droppable yesterday, but dependent on mainline today?

-- 
Felipe Contreras

Re: [ 00/78] 3.3.2-stable review

[Willy Tarreau]

On Sat, Apr 14, 2012 at 06:43:06PM +0300, Felipe Contreras wrote:
> I understand you use 'stable' as guarantee, and I know it works, but
> do you *need* this guarantee?
> 
> And before you go on why you need this guarantee to avoid fixes to be
> lost, this is an *entirely different thing*; we are not talking about
> fixes in 'stable' that don't exist in mainline--for which there is
> evidence that those caused problems in the past, we are talking about
> reverting patches from 'stable' that are not part of the upstream
> release from where the 'stable' branch was forked--*nobody* has showed
> any evidence that this has happened before and caused issues.

Why make a special case for the version from which stable was derived ?
That doesn't make sense at all to me since by definition, *all* patches
that are in stable were not in this version !

Take it simpler if you want : *all* patches in stable need an upstream
commit ID, whether they're backports or reverts. You don't revert a
patch from stable, you backport a revert from upstream.

Willy

[ath9k-devel] [ 00/78] 3.3.2-stable review

[Willy Tarreau]

On Sat, Apr 14, 2012 at 06:43:06PM +0300, Felipe Contreras wrote:
> I understand you use 'stable' as guarantee, and I know it works, but
> do you *need* this guarantee?
> 
> And before you go on why you need this guarantee to avoid fixes to be
> lost, this is an *entirely different thing*; we are not talking about
> fixes in 'stable' that don't exist in mainline--for which there is
> evidence that those caused problems in the past, we are talking about
> reverting patches from 'stable' that are not part of the upstream
> release from where the 'stable' branch was forked--*nobody* has showed
> any evidence that this has happened before and caused issues.

Why make a special case for the version from which stable was derived ?
That doesn't make sense at all to me since by definition, *all* patches
that are in stable were not in this version !

Take it simpler if you want : *all* patches in stable need an upstream
commit ID, whether they're backports or reverts. You don't revert a
patch from stable, you backport a revert from upstream.

Willy

Re: [ 00/78] 3.3.2-stable review

[Stefan Richter]

On Apr 14 Felipe Contreras wrote:
> On Sat, Apr 14, 2012 at 10:41 AM, Stefan Richter
> <stefanr@s5r6.in-berlin.de> wrote:
> > On Apr 14 Felipe Contreras wrote:
> >> I already exemplified how they are very different, but here it goes
> >> again. The patch "drm/i915: Add lock on drm_helper_resume_force_mode"
> >> was just tagged in 3.3.2, if I had said yesterday "this patch breaks
> >> things on my machine", then that patch would have been dropped for
> >> 3.3.2 even though it's still on mainline--why? Because we know it's
> >> broken, and broken patches are not supposed to land to stable. But
> >> today, one day later, we have to wait until it's fixed in master
> >> first. Why?
> >>
> >> What makes a patch droppable yesterday, but dependent on mainline today?
> >
> > Huh?
> >
> > Because "yesterday" was a review before stable release:
> >  - A buggy mainline release exists.
> >  - No buggy stable release exists.
> > whereas "today" is after stable release:
> >  - A buggy mainline release exists.
> >  - A buggy stable release exists.
> 
> IOW; a tag makes undroppable.

Generally, "commit + push out" makes it undroppable.  In case of -stable,
commit/ push out/ tag are close and virtually identical.

After a change was pushed out, the choice narrows down to add a reverting
change for a subsequent release or to rebase to a point before the
defective commit.  The latter is not done to -stable, obviously.  (3.3.2
is not being restarted from 3.3 if a regression from 3.3 to 3.3.1 was
discovered.)

> But *why*? You say you *really* need to problem to fixed in mainline,
> that's why it cannot be dropped, but that applies also to patches in
> the queue *before* the tag is made, doesn't it? If you find a patch in
> the stable review queue causes problems, why don't you leave it there?

As Willy wrote, that's actually what is done sometimes.  I didn't know
that.

> You *really* need to problem fixed in mainline, don't you?
> 
> So yesterday the priority is stability > 'upstream first', but today
> it's 'upstream first' > stability. Nobody has put forward an argument
> for this shift in priorities--

Yesterday, folks cared about mainline too.

> "a tag was made" is not argument.

"A faulty commit was pushed out" means that a defective release was made
and a fix needs to be created and released.  This is obviously something
different from rejecting to commit a submitted change after negative
review.

Sure, negative review of a stable submission consequently means that
mainline needs to be checked whether it requires a fix, and if yes, stable
users will be interested in getting that fix really into the mainline
rather sooner than later.  So suddenly they have to track a mainline bug.
Still /one/ bug though.

So that is when a stable submission was dropped "yesterday".  Now what
about if a defective change was not dropped but released, and now requires
a fix (e.g. revert) "today:  There are now /two/ bugs:  In the mainline
and in a stable kernel.

If you could convince stable to fix their bug before mainline does, then
you would have to track that other mainline bug too.  (You don't wan the
next branch point for stable to be faulty.)  Plus, either the fix from
stable needs to be forward-ported to mainline, or worse, two independent
fixes need to be developed.

What is actually done is simpler and less error prone:
  - Develop a fix for mainline.
  - Mark that fix Cc: stable.
  - Have that fix backported into stable.

[...]
> > "Drop a stable candidate before release" is a form of "decline a
> > submission to stable", happening late in the preparations of a stable
> > release.
> >
> > The latter is when damage was done; it is now about bug fixing.  This
> > involves debugging of the regression, finding a right approach to
> > fix it (e.g. revert), write + review + test + commit the fix, port the fix
> > to all relevant other kernel branches, review + test + commit those ports
> > too.
> 
> Really? So if the patch doesn't make it to stable you don't need to do
> any of that?

If the bug dosn't go into stable, you don't have to track and fix two
bugs.  You still have to track and fix a bug, but it is only one bug
instead of two.

> IOW; if the patch doesn't make it to stable, it's OK to
> leave it broken for v3.4? There's 10000 patches in v3.4-rc* that are
> all about bug fixing, they don't need to go into stable to be fixed,
> do they? If a non-stable patch needs to be reverted in mainline, it
> gets reverted in mainline, regardless of weather or not it made it to
> stable or not.
> 
> So, the hypothetical patch that was dropped in the stable review queue
> yesterday has to be fixed in mainline too,

I count one bug.

> just like the hypothetical
> patch that made it to stable and was found problematic today has to be
> fixed in mainline.

I count two bugs.

> Again, what makes a released patch undroppable? It's not the bug
> fixing; weather or not it gets into stable, it still has to be fixed
> in mainline.

If it is released, you can't drop, only revert or rebase to an older
origin.  (Well, to rebase onto older origin actually means to drop, though
not just that one commit but also all its successors.)

[...]
> Seems to me you are abusing the 'stable' branch as a bug tracking
> system for certain patches for the next release.

There is no abuse.

If a regression happens in stable, you always need to figure out whether
this is only a problem in stable or also in mainline (because mainline
will become the origin of a new stable series eventually, and the problem
should not reappear int the new stable series).  If the problem is only a
stable problem, just fix it in stable.  If it is also a mainline problem,
you want to have it fixed both in stable and in mainline (because their
mainline will become your stable in a new series).

Now there are three choices:
  - Develop a mainline fix, backport it to stable.
  - Develop a stable fix, forward-port it to mainline.
  - Develop the two fixes independently.

A variation of the second and third choice:  Develop a stable fix, leave
mainline unfixed for now, forward-port the stable fix from 3.M.y to 3.N.y,
until mainline is receiving the forward-port too or got an independently
developed fix.

Distributors routinely do any of the three choices.  Greg does only the
first one in stable:  No forward-ports, only backports.  I wrote about the
downsides of forward-ports in the other post.

There is an obvious downside to backports-only too:  The stable fix is
delayed until after mainline fix.  This one downside seems to have
inspired this huge mailinglist thread...  But you as a user of stable can
compensate for this delay in some ways:  You could switch back to a stable
release before the regression, you could apply a fix locally on top of the
regressed stable, or you could find a third party kernel which contains
such local fixes.

Sure, any of these options is a nuisance.  But these nuisances for end
users will still probably not change how stable is maintained.  Instead,
that forward-ports are out of scope of stable is one reason why you are
getting so frequent stable releases.  So you typically don't have to wait
for a regression fix in stable for unbearingly long.  No forward-ports in
stable also means lower likelyhood of stable-only regressions.
-- 
Stefan Richter
-=====-===-- -=-- -===-
http://arcgraph.de/sr/

[ath9k-devel] [ 00/78] 3.3.2-stable review

[Stefan Richter]

On Apr 14 Felipe Contreras wrote:
> On Sat, Apr 14, 2012 at 10:41 AM, Stefan Richter
> <stefanr@s5r6.in-berlin.de> wrote:
> > On Apr 14 Felipe Contreras wrote:
> >> I already exemplified how they are very different, but here it goes
> >> again. The patch "drm/i915: Add lock on drm_helper_resume_force_mode"
> >> was just tagged in 3.3.2, if I had said yesterday "this patch breaks
> >> things on my machine", then that patch would have been dropped for
> >> 3.3.2 even though it's still on mainline--why? Because we know it's
> >> broken, and broken patches are not supposed to land to stable. But
> >> today, one day later, we have to wait until it's fixed in master
> >> first. Why?
> >>
> >> What makes a patch droppable yesterday, but dependent on mainline today?
> >
> > Huh?
> >
> > Because "yesterday" was a review before stable release:
> > ?- A buggy mainline release exists.
> > ?- No buggy stable release exists.
> > whereas "today" is after stable release:
> > ?- A buggy mainline release exists.
> > ?- A buggy stable release exists.
> 
> IOW; a tag makes undroppable.

Generally, "commit + push out" makes it undroppable.  In case of -stable,
commit/ push out/ tag are close and virtually identical.

After a change was pushed out, the choice narrows down to add a reverting
change for a subsequent release or to rebase to a point before the
defective commit.  The latter is not done to -stable, obviously.  (3.3.2
is not being restarted from 3.3 if a regression from 3.3 to 3.3.1 was
discovered.)

> But *why*? You say you *really* need to problem to fixed in mainline,
> that's why it cannot be dropped, but that applies also to patches in
> the queue *before* the tag is made, doesn't it? If you find a patch in
> the stable review queue causes problems, why don't you leave it there?

As Willy wrote, that's actually what is done sometimes.  I didn't know
that.

> You *really* need to problem fixed in mainline, don't you?
> 
> So yesterday the priority is stability > 'upstream first', but today
> it's 'upstream first' > stability. Nobody has put forward an argument
> for this shift in priorities--

Yesterday, folks cared about mainline too.

> "a tag was made" is not argument.

"A faulty commit was pushed out" means that a defective release was made
and a fix needs to be created and released.  This is obviously something
different from rejecting to commit a submitted change after negative
review.

Sure, negative review of a stable submission consequently means that
mainline needs to be checked whether it requires a fix, and if yes, stable
users will be interested in getting that fix really into the mainline
rather sooner than later.  So suddenly they have to track a mainline bug.
Still /one/ bug though.

So that is when a stable submission was dropped "yesterday".  Now what
about if a defective change was not dropped but released, and now requires
a fix (e.g. revert) "today:  There are now /two/ bugs:  In the mainline
and in a stable kernel.

If you could convince stable to fix their bug before mainline does, then
you would have to track that other mainline bug too.  (You don't wan the
next branch point for stable to be faulty.)  Plus, either the fix from
stable needs to be forward-ported to mainline, or worse, two independent
fixes need to be developed.

What is actually done is simpler and less error prone:
  - Develop a fix for mainline.
  - Mark that fix Cc: stable.
  - Have that fix backported into stable.

[...]
> > "Drop a stable candidate before release" is a form of "decline a
> > submission to stable", happening late in the preparations of a stable
> > release.
> >
> > The latter is when damage was done; it is now about bug fixing. ?This
> > involves debugging of the regression, finding a right approach to
> > fix it (e.g. revert), write + review + test + commit the fix, port the fix
> > to all relevant other kernel branches, review + test + commit those ports
> > too.
> 
> Really? So if the patch doesn't make it to stable you don't need to do
> any of that?

If the bug dosn't go into stable, you don't have to track and fix two
bugs.  You still have to track and fix a bug, but it is only one bug
instead of two.

> IOW; if the patch doesn't make it to stable, it's OK to
> leave it broken for v3.4? There's 10000 patches in v3.4-rc* that are
> all about bug fixing, they don't need to go into stable to be fixed,
> do they? If a non-stable patch needs to be reverted in mainline, it
> gets reverted in mainline, regardless of weather or not it made it to
> stable or not.
> 
> So, the hypothetical patch that was dropped in the stable review queue
> yesterday has to be fixed in mainline too,

I count one bug.

> just like the hypothetical
> patch that made it to stable and was found problematic today has to be
> fixed in mainline.

I count two bugs.

> Again, what makes a released patch undroppable? It's not the bug
> fixing; weather or not it gets into stable, it still has to be fixed
> in mainline.

If it is released, you can't drop, only revert or rebase to an older
origin.  (Well, to rebase onto older origin actually means to drop, though
not just that one commit but also all its successors.)

[...]
> Seems to me you are abusing the 'stable' branch as a bug tracking
> system for certain patches for the next release.

There is no abuse.

If a regression happens in stable, you always need to figure out whether
this is only a problem in stable or also in mainline (because mainline
will become the origin of a new stable series eventually, and the problem
should not reappear int the new stable series).  If the problem is only a
stable problem, just fix it in stable.  If it is also a mainline problem,
you want to have it fixed both in stable and in mainline (because their
mainline will become your stable in a new series).

Now there are three choices:
  - Develop a mainline fix, backport it to stable.
  - Develop a stable fix, forward-port it to mainline.
  - Develop the two fixes independently.

A variation of the second and third choice:  Develop a stable fix, leave
mainline unfixed for now, forward-port the stable fix from 3.M.y to 3.N.y,
until mainline is receiving the forward-port too or got an independently
developed fix.

Distributors routinely do any of the three choices.  Greg does only the
first one in stable:  No forward-ports, only backports.  I wrote about the
downsides of forward-ports in the other post.

There is an obvious downside to backports-only too:  The stable fix is
delayed until after mainline fix.  This one downside seems to have
inspired this huge mailinglist thread...  But you as a user of stable can
compensate for this delay in some ways:  You could switch back to a stable
release before the regression, you could apply a fix locally on top of the
regressed stable, or you could find a third party kernel which contains
such local fixes.

Sure, any of these options is a nuisance.  But these nuisances for end
users will still probably not change how stable is maintained.  Instead,
that forward-ports are out of scope of stable is one reason why you are
getting so frequent stable releases.  So you typically don't have to wait
for a regression fix in stable for unbearingly long.  No forward-ports in
stable also means lower likelyhood of stable-only regressions.
-- 
Stefan Richter
-=====-===-- -=-- -===-
http://arcgraph.de/sr/

Re: [ 00/78] 3.3.2-stable review

[Stefan Richter]

On Apr 14 Felipe Contreras wrote:
> On Sat, Apr 14, 2012 at 12:10 PM, Stefan Richter
> <stefanr@s5r6.in-berlin.de> wrote:
> > On Apr 14 Felipe Contreras wrote:
> 
> >> Of course, although the difference with the stable kernel would be
> >> very small if the only thing added is an extra rule for acceptance:
> >> "It reverts an earlier patch to 'stable'."
> >
> > It looks like a small difference on the surface, but it isn't.  It would
> > mean "yes, we /do/ forward ports in -stable too in some cases".
> 
> How? There's a lot reverts in mainline, where do they come from? Are
> they forward ports from some ghost trees?

Indeed, reverts that go into mainline can often be called forward-ports:
A subsystem developer applied the revert to his subsystem tree, Linus
merges that tree, and the merge result is technically a forward-port
(except if the pull resulted in a fast-forward instead of a merge).

However, "fix it in stable before mainline" requires to allow forward-ports
in stable for a different reason:  If the fix in mainline gets delayed
until after stable's next branch point, the stable fix needs to be
forward-ported from 3.M.y to 3.N.y.

> If you drop a patch from the stable review queue before it gets into a
> stable release, and then that patch is reverted from mainline, is that
> also a "forward port"?

There is just one fix of one bug, not a fix plus a port of the fix to a
similarly buggy tree.
-- 
Stefan Richter
-=====-===-- -=-- -===-
http://arcgraph.de/sr/

[ath9k-devel] [ 00/78] 3.3.2-stable review

[Stefan Richter]

On Apr 14 Felipe Contreras wrote:
> On Sat, Apr 14, 2012 at 12:10 PM, Stefan Richter
> <stefanr@s5r6.in-berlin.de> wrote:
> > On Apr 14 Felipe Contreras wrote:
> 
> >> Of course, although the difference with the stable kernel would be
> >> very small if the only thing added is an extra rule for acceptance:
> >> "It reverts an earlier patch to 'stable'."
> >
> > It looks like a small difference on the surface, but it isn't. ?It would
> > mean "yes, we /do/ forward ports in -stable too in some cases".
> 
> How? There's a lot reverts in mainline, where do they come from? Are
> they forward ports from some ghost trees?

Indeed, reverts that go into mainline can often be called forward-ports:
A subsystem developer applied the revert to his subsystem tree, Linus
merges that tree, and the merge result is technically a forward-port
(except if the pull resulted in a fast-forward instead of a merge).

However, "fix it in stable before mainline" requires to allow forward-ports
in stable for a different reason:  If the fix in mainline gets delayed
until after stable's next branch point, the stable fix needs to be
forward-ported from 3.M.y to 3.N.y.

> If you drop a patch from the stable review queue before it gets into a
> stable release, and then that patch is reverted from mainline, is that
> also a "forward port"?

There is just one fix of one bug, not a fix plus a port of the fix to a
similarly buggy tree.
-- 
Stefan Richter
-=====-===-- -=-- -===-
http://arcgraph.de/sr/

Re: [ 00/78] 3.3.2-stable review

[Felipe Contreras]

On Sat, Apr 14, 2012 at 8:55 PM, Stefan Richter
<stefanr@s5r6.in-berlin.de> wrote:
> On Apr 14 Felipe Contreras wrote:
>> On Sat, Apr 14, 2012 at 10:41 AM, Stefan Richter
>> <stefanr@s5r6.in-berlin.de> wrote:
>> > On Apr 14 Felipe Contreras wrote:
>> >> I already exemplified how they are very different, but here it goes
>> >> again. The patch "drm/i915: Add lock on drm_helper_resume_force_mode"
>> >> was just tagged in 3.3.2, if I had said yesterday "this patch breaks
>> >> things on my machine", then that patch would have been dropped for
>> >> 3.3.2 even though it's still on mainline--why? Because we know it's
>> >> broken, and broken patches are not supposed to land to stable. But
>> >> today, one day later, we have to wait until it's fixed in master
>> >> first. Why?
>> >>
>> >> What makes a patch droppable yesterday, but dependent on mainline today?
>> >
>> > Huh?
>> >
>> > Because "yesterday" was a review before stable release:
>> >  - A buggy mainline release exists.
>> >  - No buggy stable release exists.
>> > whereas "today" is after stable release:
>> >  - A buggy mainline release exists.
>> >  - A buggy stable release exists.
>>
>> IOW; a tag makes undroppable.
>
> Generally, "commit + push out" makes it undroppable.  In case of -stable,
> commit/ push out/ tag are close and virtually identical.
>
> After a change was pushed out, the choice narrows down to add a reverting
> change for a subsequent release or to rebase to a point before the
> defective commit.  The latter is not done to -stable, obviously.  (3.3.2
> is not being restarted from 3.3 if a regression from 3.3 to 3.3.1 was
> discovered.)

That's irrelevant; whether you rebase and drop the patch, or you
revert it, the resulting code is *exactly* the same. It's also the
same if Greg drops it from his quilt queue before pushing (assuming
that's what he uses).

Let's avoid this semantic red herring, by undroppable I mean
unrevertable, or undiscardable, or anything that effectively makes the
patch not be there.

>> But *why*? You say you *really* need to problem to fixed in mainline,
>> that's why it cannot be dropped, but that applies also to patches in
>> the queue *before* the tag is made, doesn't it? If you find a patch in
>> the stable review queue causes problems, why don't you leave it there?
>
> As Willy wrote, that's actually what is done sometimes.  I didn't know
> that.

Don't avoid the question.

I don't mean just leave it in the queue, I mean leave it so it gets
tagged in the release.

>> You *really* need to problem fixed in mainline, don't you?
>>
>> So yesterday the priority is stability > 'upstream first', but today
>> it's 'upstream first' > stability. Nobody has put forward an argument
>> for this shift in priorities--
>
> Yesterday, folks cared about mainline too.

Who suggested otherwise? Being priority #2 doesn't mean you don't
care. We always care about mainline, even for patches that are not
proposed for 'stable'.

But if we found yesterday that the patch would break things, it would
not make it to the stable release.

You are again avoiding the argument.

>> "a tag was made" is not argument.
>
> "A faulty commit was pushed out" means that a defective release was made
> and a fix needs to be created and released.  This is obviously something
> different from rejecting to commit a submitted change after negative
> review.
>
> Sure, negative review of a stable submission consequently means that
> mainline needs to be checked whether it requires a fix, and if yes, stable
> users will be interested in getting that fix really into the mainline
> rather sooner than later.  So suddenly they have to track a mainline bug.
> Still /one/ bug though.

Yes.

> So that is when a stable submission was dropped "yesterday".  Now what
> about if a defective change was not dropped but released, and now requires
> a fix (e.g. revert) "today:  There are now /two/ bugs:  In the mainline
> and in a stable kernel.

What?! So, if an issue has been in the kernel for the last 10 years,
and it's just fixed, that means we suddenly have hundreds of bugs?

You are playing with words; it's *one* bug that is present in multiple releases.

a) if there's a bug in an internal tree, say linux-nokia; it's sill *one* bug
b) if the bug gets propagated to linux-omap; it's still *one* bug
c) if the bug gets into Linus's 'master' branch (before a tag); it's
still *one* bug
d) if it gets tagged into v3.5-rc1; it's still *one* bug
e) if it gets into Greg's stable queue; it's still *one* bug
f) and if it gets into v3.4.1; it's still *one* bug.

This is an unseasoned assertion, and the rest of your comments assume
it is true, so I'm not going to reply to them.

By saying it's "two bugs", you are still avoiding the question of why
they are different. *Why* are they two bugs? What is so different
between e) and f) that makes bad patches undroppable?

I appreciate you are exploring this discussion, but I wonder if you
accept the possibility that there's actually no good reason for this
change in priorities, or if you accept that even a change in
priorities is taking place.

Cheers.

-- 
Felipe Contreras

[ath9k-devel] [ 00/78] 3.3.2-stable review

[Felipe Contreras]

On Sat, Apr 14, 2012 at 8:55 PM, Stefan Richter
<stefanr@s5r6.in-berlin.de> wrote:
> On Apr 14 Felipe Contreras wrote:
>> On Sat, Apr 14, 2012 at 10:41 AM, Stefan Richter
>> <stefanr@s5r6.in-berlin.de> wrote:
>> > On Apr 14 Felipe Contreras wrote:
>> >> I already exemplified how they are very different, but here it goes
>> >> again. The patch "drm/i915: Add lock on drm_helper_resume_force_mode"
>> >> was just tagged in 3.3.2, if I had said yesterday "this patch breaks
>> >> things on my machine", then that patch would have been dropped for
>> >> 3.3.2 even though it's still on mainline--why? Because we know it's
>> >> broken, and broken patches are not supposed to land to stable. But
>> >> today, one day later, we have to wait until it's fixed in master
>> >> first. Why?
>> >>
>> >> What makes a patch droppable yesterday, but dependent on mainline today?
>> >
>> > Huh?
>> >
>> > Because "yesterday" was a review before stable release:
>> > ?- A buggy mainline release exists.
>> > ?- No buggy stable release exists.
>> > whereas "today" is after stable release:
>> > ?- A buggy mainline release exists.
>> > ?- A buggy stable release exists.
>>
>> IOW; a tag makes undroppable.
>
> Generally, "commit + push out" makes it undroppable. ?In case of -stable,
> commit/ push out/ tag are close and virtually identical.
>
> After a change was pushed out, the choice narrows down to add a reverting
> change for a subsequent release or to rebase to a point before the
> defective commit. ?The latter is not done to -stable, obviously. ?(3.3.2
> is not being restarted from 3.3 if a regression from 3.3 to 3.3.1 was
> discovered.)

That's irrelevant; whether you rebase and drop the patch, or you
revert it, the resulting code is *exactly* the same. It's also the
same if Greg drops it from his quilt queue before pushing (assuming
that's what he uses).

Let's avoid this semantic red herring, by undroppable I mean
unrevertable, or undiscardable, or anything that effectively makes the
patch not be there.

>> But *why*? You say you *really* need to problem to fixed in mainline,
>> that's why it cannot be dropped, but that applies also to patches in
>> the queue *before* the tag is made, doesn't it? If you find a patch in
>> the stable review queue causes problems, why don't you leave it there?
>
> As Willy wrote, that's actually what is done sometimes. ?I didn't know
> that.

Don't avoid the question.

I don't mean just leave it in the queue, I mean leave it so it gets
tagged in the release.

>> You *really* need to problem fixed in mainline, don't you?
>>
>> So yesterday the priority is stability > 'upstream first', but today
>> it's 'upstream first' > stability. Nobody has put forward an argument
>> for this shift in priorities--
>
> Yesterday, folks cared about mainline too.

Who suggested otherwise? Being priority #2 doesn't mean you don't
care. We always care about mainline, even for patches that are not
proposed for 'stable'.

But if we found yesterday that the patch would break things, it would
not make it to the stable release.

You are again avoiding the argument.

>> "a tag was made" is not argument.
>
> "A faulty commit was pushed out" means that a defective release was made
> and a fix needs to be created and released. ?This is obviously something
> different from rejecting to commit a submitted change after negative
> review.
>
> Sure, negative review of a stable submission consequently means that
> mainline needs to be checked whether it requires a fix, and if yes, stable
> users will be interested in getting that fix really into the mainline
> rather sooner than later. ?So suddenly they have to track a mainline bug.
> Still /one/ bug though.

Yes.

> So that is when a stable submission was dropped "yesterday". ?Now what
> about if a defective change was not dropped but released, and now requires
> a fix (e.g. revert) "today: ?There are now /two/ bugs: ?In the mainline
> and in a stable kernel.

What?! So, if an issue has been in the kernel for the last 10 years,
and it's just fixed, that means we suddenly have hundreds of bugs?

You are playing with words; it's *one* bug that is present in multiple releases.

a) if there's a bug in an internal tree, say linux-nokia; it's sill *one* bug
b) if the bug gets propagated to linux-omap; it's still *one* bug
c) if the bug gets into Linus's 'master' branch (before a tag); it's
still *one* bug
d) if it gets tagged into v3.5-rc1; it's still *one* bug
e) if it gets into Greg's stable queue; it's still *one* bug
f) and if it gets into v3.4.1; it's still *one* bug.

This is an unseasoned assertion, and the rest of your comments assume
it is true, so I'm not going to reply to them.

By saying it's "two bugs", you are still avoiding the question of why
they are different. *Why* are they two bugs? What is so different
between e) and f) that makes bad patches undroppable?

I appreciate you are exploring this discussion, but I wonder if you
accept the possibility that there's actually no good reason for this
change in priorities, or if you accept that even a change in
priorities is taking place.

Cheers.

-- 
Felipe Contreras

Re: [ 00/78] 3.3.2-stable review

[Felipe Contreras]

On Sat, Apr 14, 2012 at 6:57 PM, Willy Tarreau <w@1wt.eu> wrote:
> On Sat, Apr 14, 2012 at 06:29:54PM +0300, Felipe Contreras wrote:
>> So, the hypothetical patch that was dropped in the stable review queue
>> yesterday has to be fixed in mainline too, just like the hypothetical
>> patch that made it to stable and was found problematic today has to be
>> fixed in mainline.
>
> Patches are not always dropped from the stable queue if we know they're
> causing issues, sometimes they're left pending in the queue. This is how
> Greg is able to ping developers from time to time.

That's news to me, but the important point remains; they don't make it
into the stable release, correct? Yet, we still expect them to be
fixed in mainline, correct?

>> Again, what makes a released patch undroppable?
>
> Being applied, in other words, having a commit ID in the branch.

Seriously? That's your reason?

Hey, thousands of users out there; the reason why we pushed a patch
that is known to be broken in v3.3.x is because it already has a
commit ID.

If that's your idea of a good reason then I don't see any point in
discussing with you any more. No offense intended.

Cheers.

-- 
Felipe Contreras

[ath9k-devel] [ 00/78] 3.3.2-stable review

[Felipe Contreras]

On Sat, Apr 14, 2012 at 6:57 PM, Willy Tarreau <w@1wt.eu> wrote:
> On Sat, Apr 14, 2012 at 06:29:54PM +0300, Felipe Contreras wrote:
>> So, the hypothetical patch that was dropped in the stable review queue
>> yesterday has to be fixed in mainline too, just like the hypothetical
>> patch that made it to stable and was found problematic today has to be
>> fixed in mainline.
>
> Patches are not always dropped from the stable queue if we know they're
> causing issues, sometimes they're left pending in the queue. This is how
> Greg is able to ping developers from time to time.

That's news to me, but the important point remains; they don't make it
into the stable release, correct? Yet, we still expect them to be
fixed in mainline, correct?

>> Again, what makes a released patch undroppable?
>
> Being applied, in other words, having a commit ID in the branch.

Seriously? That's your reason?

Hey, thousands of users out there; the reason why we pushed a patch
that is known to be broken in v3.3.x is because it already has a
commit ID.

If that's your idea of a good reason then I don't see any point in
discussing with you any more. No offense intended.

Cheers.

-- 
Felipe Contreras

Re: [ 00/78] 3.3.2-stable review

[Willy Tarreau]

On Sat, Apr 14, 2012 at 10:33:59PM +0300, Felipe Contreras wrote:
> >> Again, what makes a released patch undroppable?
> >
> > Being applied, in other words, having a commit ID in the branch.
> 
> Seriously? That's your reason?
> 
> Hey, thousands of users out there; the reason why we pushed a patch
> that is known to be broken in v3.3.x is because it already has a
> commit ID.

I think you have a real problem with logics in general as it's not the
first time you're reverting cause and consequence in people's arguments.

I'm basically saying that we don't revert patches any other way than
by backporting the revert and you're saying that every patch has to
be backported. Come on, this discussion makes no sense at all. You're
wasting everyone's time for nothing, just because you want to be right
even after everyone explained you the same thing. You got me bored.

Willy

[ath9k-devel] [ 00/78] 3.3.2-stable review

[Willy Tarreau]

On Sat, Apr 14, 2012 at 10:33:59PM +0300, Felipe Contreras wrote:
> >> Again, what makes a released patch undroppable?
> >
> > Being applied, in other words, having a commit ID in the branch.
> 
> Seriously? That's your reason?
> 
> Hey, thousands of users out there; the reason why we pushed a patch
> that is known to be broken in v3.3.x is because it already has a
> commit ID.

I think you have a real problem with logics in general as it's not the
first time you're reverting cause and consequence in people's arguments.

I'm basically saying that we don't revert patches any other way than
by backporting the revert and you're saying that every patch has to
be backported. Come on, this discussion makes no sense at all. You're
wasting everyone's time for nothing, just because you want to be right
even after everyone explained you the same thing. You got me bored.

Willy

Re: [ 00/78] 3.3.2-stable review

[Stefan Richter]

On Apr 14 Felipe Contreras wrote:
> On Sat, Apr 14, 2012 at 8:55 PM, Stefan Richter
> <stefanr@s5r6.in-berlin.de> wrote:
> > Generally, "commit + push out" makes it undroppable.  In case of -stable,
> > commit/ push out/ tag are close and virtually identical.
> >
> > After a change was pushed out, the choice narrows down to add a reverting
> > change for a subsequent release or to rebase to a point before the
> > defective commit.  The latter is not done to -stable, obviously.  (3.3.2
> > is not being restarted from 3.3 if a regression from 3.3 to 3.3.1 was
> > discovered.)
> 
> That's irrelevant; whether you rebase and drop the patch, or you
> revert it, the resulting code is *exactly* the same. It's also the
> same if Greg drops it from his quilt queue before pushing (assuming
> that's what he uses).

The result may be the same (sometimes it actually isn't), but the way to
get there is not.

> Let's avoid this semantic red herring, by undroppable I mean
> unrevertable, or undiscardable, or anything that effectively makes the
> patch not be there.

How do you "make it not be there"?  By adding a reverting patch.

The reverting patch needs to come from somewhere, and the only
disagreement is basically through which channels the patch should be
allowed to come, or which qualifications this reverting patch should
fulfill.

> >> But *why*? You say you *really* need to problem to fixed in mainline,
> >> that's why it cannot be dropped, but that applies also to patches in
> >> the queue *before* the tag is made, doesn't it? If you find a patch in
> >> the stable review queue causes problems, why don't you leave it there?
> >
> > As Willy wrote, that's actually what is done sometimes.  I didn't know
> > that.
> 
> Don't avoid the question.

Willy answered that, hence I didn't think I have to.  The patch can in
fact be kept in the stable queue as a reminder, it just should not be
applied to stable as long as there is no resolution for mainline.

> I don't mean just leave it in the queue, I mean leave it so it gets
> tagged in the release.

That would be even sillier than the discussion which we are having.

> >> You *really* need to problem fixed in mainline, don't you?
> >>
> >> So yesterday the priority is stability > 'upstream first', but today
> >> it's 'upstream first' > stability. Nobody has put forward an argument
> >> for this shift in priorities--
> >
> > Yesterday, folks cared about mainline too.
> 
> Who suggested otherwise? Being priority #2 doesn't mean you don't
> care. We always care about mainline, even for patches that are not
> proposed for 'stable'.
> 
> But if we found yesterday that the patch would break things, it would
> not make it to the stable release.
> 
> You are again avoiding the argument.

The priorities argument is bogus.  The procedure of receiving stable
patches only as backports from mainline is exactly about stabilization,
nothing else.

[...]
> > if a defective change was not dropped but released, and now requires
> > a fix (e.g. revert) "today:  There are now /two/ bugs:  In the mainline
> > and in a stable kernel.
> 
> What?! So, if an issue has been in the kernel for the last 10 years,
> and it's just fixed, that means we suddenly have hundreds of bugs?

You would have fixed hundreds of bugs if you released fixes into hundreds
of kernel branches.

> You are playing with words; it's *one* bug that is present in multiple releases.

Count it as a single bug if you prefer.  The fact is, the bugs or bug
needs fixes in each affected maintained kernel branch.  So even if you
count one bug, there are still more than one bug resolutions to be done.

> e) if it gets into Greg's stable queue; it's still *one* bug
> f) and if it gets into v3.4.1; it's still *one* bug.
[...]
> By saying it's "two bugs", you are still avoiding the question of why
> they are different. *Why* are they two bugs? What is so different
> between e) and f)

e) requires a fix to be published in the mainline.  f) requires a fix to
be published in the mainline and another fix to be published in stable.

> that makes bad patches undroppable?

f) makes stable require a reverting patch.

> I appreciate you are exploring this discussion, but I wonder if you
> accept the possibility that there's actually no good reason for this
> change in priorities, or if you accept that even a change in
> priorities is taking place.

Stabilization is the only priority.  There is nothing else.

I stated one reason for the procedure in case of f):

Fixing mainline first and then backporting to stable is always easier and
safer than fixing stable first and only then start to think about how
mainline can be fixed.  I and others also explained a bit more why it is
easier and safer.

I realise that this is not a good enough reason in your opinion, at least
as far as revert-type fixes are concerned.  Some of the folks who are
unfortunate enough to be Cc'd on this discussion have quite a bit of
experience with varying kernel maintenance models though, so I find their
opinions in these matters well worth thinking about.
-- 
Stefan Richter
-=====-===-- -=-- -===-
http://arcgraph.de/sr/

[ath9k-devel] [ 00/78] 3.3.2-stable review

[Stefan Richter]

On Apr 14 Felipe Contreras wrote:
> On Sat, Apr 14, 2012 at 8:55 PM, Stefan Richter
> <stefanr@s5r6.in-berlin.de> wrote:
> > Generally, "commit + push out" makes it undroppable. ?In case of -stable,
> > commit/ push out/ tag are close and virtually identical.
> >
> > After a change was pushed out, the choice narrows down to add a reverting
> > change for a subsequent release or to rebase to a point before the
> > defective commit. ?The latter is not done to -stable, obviously. ?(3.3.2
> > is not being restarted from 3.3 if a regression from 3.3 to 3.3.1 was
> > discovered.)
> 
> That's irrelevant; whether you rebase and drop the patch, or you
> revert it, the resulting code is *exactly* the same. It's also the
> same if Greg drops it from his quilt queue before pushing (assuming
> that's what he uses).

The result may be the same (sometimes it actually isn't), but the way to
get there is not.

> Let's avoid this semantic red herring, by undroppable I mean
> unrevertable, or undiscardable, or anything that effectively makes the
> patch not be there.

How do you "make it not be there"?  By adding a reverting patch.

The reverting patch needs to come from somewhere, and the only
disagreement is basically through which channels the patch should be
allowed to come, or which qualifications this reverting patch should
fulfill.

> >> But *why*? You say you *really* need to problem to fixed in mainline,
> >> that's why it cannot be dropped, but that applies also to patches in
> >> the queue *before* the tag is made, doesn't it? If you find a patch in
> >> the stable review queue causes problems, why don't you leave it there?
> >
> > As Willy wrote, that's actually what is done sometimes. ?I didn't know
> > that.
> 
> Don't avoid the question.

Willy answered that, hence I didn't think I have to.  The patch can in
fact be kept in the stable queue as a reminder, it just should not be
applied to stable as long as there is no resolution for mainline.

> I don't mean just leave it in the queue, I mean leave it so it gets
> tagged in the release.

That would be even sillier than the discussion which we are having.

> >> You *really* need to problem fixed in mainline, don't you?
> >>
> >> So yesterday the priority is stability > 'upstream first', but today
> >> it's 'upstream first' > stability. Nobody has put forward an argument
> >> for this shift in priorities--
> >
> > Yesterday, folks cared about mainline too.
> 
> Who suggested otherwise? Being priority #2 doesn't mean you don't
> care. We always care about mainline, even for patches that are not
> proposed for 'stable'.
> 
> But if we found yesterday that the patch would break things, it would
> not make it to the stable release.
> 
> You are again avoiding the argument.

The priorities argument is bogus.  The procedure of receiving stable
patches only as backports from mainline is exactly about stabilization,
nothing else.

[...]
> > if a defective change was not dropped but released, and now requires
> > a fix (e.g. revert) "today: ?There are now /two/ bugs: ?In the mainline
> > and in a stable kernel.
> 
> What?! So, if an issue has been in the kernel for the last 10 years,
> and it's just fixed, that means we suddenly have hundreds of bugs?

You would have fixed hundreds of bugs if you released fixes into hundreds
of kernel branches.

> You are playing with words; it's *one* bug that is present in multiple releases.

Count it as a single bug if you prefer.  The fact is, the bugs or bug
needs fixes in each affected maintained kernel branch.  So even if you
count one bug, there are still more than one bug resolutions to be done.

> e) if it gets into Greg's stable queue; it's still *one* bug
> f) and if it gets into v3.4.1; it's still *one* bug.
[...]
> By saying it's "two bugs", you are still avoiding the question of why
> they are different. *Why* are they two bugs? What is so different
> between e) and f)

e) requires a fix to be published in the mainline.  f) requires a fix to
be published in the mainline and another fix to be published in stable.

> that makes bad patches undroppable?

f) makes stable require a reverting patch.

> I appreciate you are exploring this discussion, but I wonder if you
> accept the possibility that there's actually no good reason for this
> change in priorities, or if you accept that even a change in
> priorities is taking place.

Stabilization is the only priority.  There is nothing else.

I stated one reason for the procedure in case of f):

Fixing mainline first and then backporting to stable is always easier and
safer than fixing stable first and only then start to think about how
mainline can be fixed.  I and others also explained a bit more why it is
easier and safer.

I realise that this is not a good enough reason in your opinion, at least
as far as revert-type fixes are concerned.  Some of the folks who are
unfortunate enough to be Cc'd on this discussion have quite a bit of
experience with varying kernel maintenance models though, so I find their
opinions in these matters well worth thinking about.
-- 
Stefan Richter
-=====-===-- -=-- -===-
http://arcgraph.de/sr/

Re: [ 00/78] 3.3.2-stable review

[Felipe Contreras]

On Sun, Apr 15, 2012 at 12:21 AM, Stefan Richter
<stefanr@s5r6.in-berlin.de> wrote:
> On Apr 14 Felipe Contreras wrote:
>> On Sat, Apr 14, 2012 at 8:55 PM, Stefan Richter
>> <stefanr@s5r6.in-berlin.de> wrote:
>> > Generally, "commit + push out" makes it undroppable.  In case of -stable,
>> > commit/ push out/ tag are close and virtually identical.
>> >
>> > After a change was pushed out, the choice narrows down to add a reverting
>> > change for a subsequent release or to rebase to a point before the
>> > defective commit.  The latter is not done to -stable, obviously.  (3.3.2
>> > is not being restarted from 3.3 if a regression from 3.3 to 3.3.1 was
>> > discovered.)
>>
>> That's irrelevant; whether you rebase and drop the patch, or you
>> revert it, the resulting code is *exactly* the same. It's also the
>> same if Greg drops it from his quilt queue before pushing (assuming
>> that's what he uses).
>
> The result may be the same (sometimes it actually isn't),

If the result is not the same, then that's a different situation; I'm
talking about true reverts/drops in which the result is *exactly* the
same. OK?

>> Let's avoid this semantic red herring, by undroppable I mean
>> unrevertable, or undiscardable, or anything that effectively makes the
>> patch not be there.
>
> How do you "make it not be there"?  By adding a reverting patch.
>
> The reverting patch needs to come from somewhere, and the only
> disagreement is basically through which channels the patch should be
> allowed to come, or which qualifications this reverting patch should
> fulfill.

If the patch was tagged in a release, yes, but if the patch was in the
queue, but never tagged, it can be dropped.

The question that has not been answered is what makes them different, and why.

>> >> But *why*? You say you *really* need to problem to fixed in mainline,
>> >> that's why it cannot be dropped, but that applies also to patches in
>> >> the queue *before* the tag is made, doesn't it? If you find a patch in
>> >> the stable review queue causes problems, why don't you leave it there?
>> >
>> > As Willy wrote, that's actually what is done sometimes.  I didn't know
>> > that.
>>
>> Don't avoid the question.
>
> Willy answered that, hence I didn't think I have to.  The patch can in
> fact be kept in the stable queue as a reminder, it just should not be
> applied to stable as long as there is no resolution for mainline.

>> I don't mean just leave it in the queue, I mean leave it so it gets
>> tagged in the release.
>
> That would be even sillier than the discussion which we are having.

Exactly!

I'm glad you see it's silly to put bad patches in the stable release
just so they get properly tracked for mainline, but that's exactly
what you arguing for.

Now all you have to do is explain why it's silly before the tag, but not after.

-- 
Felipe Contreras

[ath9k-devel] [ 00/78] 3.3.2-stable review

[Felipe Contreras]

On Sun, Apr 15, 2012 at 12:21 AM, Stefan Richter
<stefanr@s5r6.in-berlin.de> wrote:
> On Apr 14 Felipe Contreras wrote:
>> On Sat, Apr 14, 2012 at 8:55 PM, Stefan Richter
>> <stefanr@s5r6.in-berlin.de> wrote:
>> > Generally, "commit + push out" makes it undroppable. ?In case of -stable,
>> > commit/ push out/ tag are close and virtually identical.
>> >
>> > After a change was pushed out, the choice narrows down to add a reverting
>> > change for a subsequent release or to rebase to a point before the
>> > defective commit. ?The latter is not done to -stable, obviously. ?(3.3.2
>> > is not being restarted from 3.3 if a regression from 3.3 to 3.3.1 was
>> > discovered.)
>>
>> That's irrelevant; whether you rebase and drop the patch, or you
>> revert it, the resulting code is *exactly* the same. It's also the
>> same if Greg drops it from his quilt queue before pushing (assuming
>> that's what he uses).
>
> The result may be the same (sometimes it actually isn't),

If the result is not the same, then that's a different situation; I'm
talking about true reverts/drops in which the result is *exactly* the
same. OK?

>> Let's avoid this semantic red herring, by undroppable I mean
>> unrevertable, or undiscardable, or anything that effectively makes the
>> patch not be there.
>
> How do you "make it not be there"? ?By adding a reverting patch.
>
> The reverting patch needs to come from somewhere, and the only
> disagreement is basically through which channels the patch should be
> allowed to come, or which qualifications this reverting patch should
> fulfill.

If the patch was tagged in a release, yes, but if the patch was in the
queue, but never tagged, it can be dropped.

The question that has not been answered is what makes them different, and why.

>> >> But *why*? You say you *really* need to problem to fixed in mainline,
>> >> that's why it cannot be dropped, but that applies also to patches in
>> >> the queue *before* the tag is made, doesn't it? If you find a patch in
>> >> the stable review queue causes problems, why don't you leave it there?
>> >
>> > As Willy wrote, that's actually what is done sometimes. ?I didn't know
>> > that.
>>
>> Don't avoid the question.
>
> Willy answered that, hence I didn't think I have to. ?The patch can in
> fact be kept in the stable queue as a reminder, it just should not be
> applied to stable as long as there is no resolution for mainline.

>> I don't mean just leave it in the queue, I mean leave it so it gets
>> tagged in the release.
>
> That would be even sillier than the discussion which we are having.

Exactly!

I'm glad you see it's silly to put bad patches in the stable release
just so they get properly tracked for mainline, but that's exactly
what you arguing for.

Now all you have to do is explain why it's silly before the tag, but not after.

-- 
Felipe Contreras

Re: [ 00/78] 3.3.2-stable review

[Stefan Richter]

On Apr 15 Felipe Contreras wrote:
> The question that has not been answered is what makes them different,

It was answered in the grandparent post and in posts before it.

> I'm glad you see it's silly to put bad patches in the stable release
> just so they get properly tracked for mainline, but that's exactly
> what you arguing for.

I am not arguing for anything remotely like that.
-- 
Stefan Richter
-=====-===-- -=-- -====
http://arcgraph.de/sr/

[ath9k-devel] [ 00/78] 3.3.2-stable review

[Stefan Richter]

On Apr 15 Felipe Contreras wrote:
> The question that has not been answered is what makes them different,

It was answered in the grandparent post and in posts before it.

> I'm glad you see it's silly to put bad patches in the stable release
> just so they get properly tracked for mainline, but that's exactly
> what you arguing for.

I am not arguing for anything remotely like that.
-- 
Stefan Richter
-=====-===-- -=-- -====
http://arcgraph.de/sr/

Re: [ 00/78] 3.3.2-stable review

[Felipe Contreras]

On Sun, Apr 15, 2012 at 1:47 AM, Stefan Richter
<stefanr@s5r6.in-berlin.de> wrote:
> On Apr 15 Felipe Contreras wrote:
>> The question that has not been answered is what makes them different,
>
> It was answered in the grandparent post and in posts before it.

Nope.

>> I'm glad you see it's silly to put bad patches in the stable release
>> just so they get properly tracked for mainline, but that's exactly
>> what you arguing for.
>
> I am not arguing for anything remotely like that.

Please, do explain why that is silly then.

-- 
Felipe Contreras

[ath9k-devel] [ 00/78] 3.3.2-stable review

[Felipe Contreras]

On Sun, Apr 15, 2012 at 1:47 AM, Stefan Richter
<stefanr@s5r6.in-berlin.de> wrote:
> On Apr 15 Felipe Contreras wrote:
>> The question that has not been answered is what makes them different,
>
> It was answered in the grandparent post and in posts before it.

Nope.

>> I'm glad you see it's silly to put bad patches in the stable release
>> just so they get properly tracked for mainline, but that's exactly
>> what you arguing for.
>
> I am not arguing for anything remotely like that.

Please, do explain why that is silly then.

-- 
Felipe Contreras

Re: [ 00/78] 3.3.2-stable review

[Adrian Chadd]

Look, this is getting ridiculous.

I think you're completely wrapped up in the "git" way of thinking about things.

The patch can't be "dropped". It can't be "reverted". It can't be
"removed". All that Linus can do is apply a reversed patch. Then Greg
can sync up however he does it.

You seem completely wrapped up in some misguided notion that the patch
can be dropped from some series of patches. This isn't OpenWRT - you
don't have a directory of a hundred-odd patches. It's a source
revision system, complete with history. You don't remove a patch from
an existing repository - you commit a fix. That may be a reversed
version of the actual commit - but the effect is the same, the change
is "reverted". It just isn't removed from the history.

I think this is done and dusted. :-)


Adrian

[ath9k-devel] [ 00/78] 3.3.2-stable review

[Adrian Chadd]

Look, this is getting ridiculous.

I think you're completely wrapped up in the "git" way of thinking about things.

The patch can't be "dropped". It can't be "reverted". It can't be
"removed". All that Linus can do is apply a reversed patch. Then Greg
can sync up however he does it.

You seem completely wrapped up in some misguided notion that the patch
can be dropped from some series of patches. This isn't OpenWRT - you
don't have a directory of a hundred-odd patches. It's a source
revision system, complete with history. You don't remove a patch from
an existing repository - you commit a fix. That may be a reversed
version of the actual commit - but the effect is the same, the change
is "reverted". It just isn't removed from the history.

I think this is done and dusted. :-)


Adrian

Re: [ 00/78] 3.3.2-stable review

[Ingo Molnar]

* Felipe Contreras <felipe.contreras@gmail.com> wrote:

> On Sat, Apr 14, 2012 at 1:47 PM, Ingo Molnar <mingo@kernel.org> wrote:
> >
> > * Felipe Contreras <felipe.contreras@gmail.com> wrote:
> >
> >> On Fri, Apr 13, 2012 at 1:07 AM, Linus Torvalds
> >> <torvalds@linux-foundation.org> wrote:
> >> > On Thu, Apr 12, 2012 at 3:04 PM, Felipe Contreras
> >> > <felipe.contreras@gmail.com> wrote:
> >> >>
> >> >> Sure, but removing that patch from the stable tree is not
> >> >> going the change that information; we already know the
> >> >> patch is wrong.
> >> >
> >> > .. and we wait until it has been fixed in mainline so that
> >> > we *know* that information doesn't get lost.
> >>
> >> So why don't we pick potentially dangerous patches that might
> >> benefit from some testing, put them in 'stable', and if there
> >> are problems, make sure they get fixed in upstream first?
> >>
> >> Or for that matter totally broken patches we want to make sure
> >> they get fixed in upstream.
> >>
> >> Because the priority of the 'stable' tree is *stability*. Is
> >> it not?
> >>
> >> But what you are saying is: *before* the final review, even a
> >> hint that the patch might cause problems is reason enough to
> >> drop it from stable, but *after* the review, if we know the
> >> patch is totally broken, then it's the opposite; we really
> >> want it in.
> >
> > What you don't seem to understand is that there are good reasons
> > why we first fix bugs upstream, then in -stable. Greg explained
> > it to you, Linus explained it to you and so did many others.
> >
> > Having an order of patches *necessarily* means that the
> > development tree will get fixes sooner than the stable tree. In
> > other words, this *necessarily* means that the stable tree - and
> > its users - will have to wait a little bit more to have the fix.
> > In the worst-case this 'have to wait a little bit longer' might
> > span the time between two minor stable kernel releases.
> >
> > You seem to equate this 'have to wait a little bit longer to get
> > the fix' property of the maintenance model with 'we don't care
> > about stable tree users' - that claim is obviously idiotic and
> > most of your arguments in this thread are idiotic as well.
> 
> This is a straw man again. Again; we are not talking about 
> fixes in 'stable' that don't exist in mainline, we are talking 
> about reverting patches from 'stable' that are not part of the 
> upstream release from where the 'stable' branch was forked.

You are misunderstanding the Linux kernel development process 
again:

> You are avoiding the argument you replying to; yesterday a 
> patch was droppable from the stable review queue, but today, 
> after the release, now we *need* it to stay there until it's 
> fixed in the mainline. What changed?

What changed: the stable kernel was released and a new cycle 
started. If something is broken in -stable it needs to be 
reverted upstream. Full stop.

There is a minor engineering process that if a -stable commit 
does not even apply or does not even boot on Greg's box or on 
the handful of boxes that test stable release candidates then it 
obviously cannot become part of the -stable queue. That kind of 
very short term, memory-less integration testing should not be 
confused with the much broader, state-ful, Git commit backed 
testing that the upstream kernel gets.

There's a new stable cycle every 7 days on average, there's a 
new upstream kernel every 7 days on average, and there's very 
good reasons for the stable queue to be memory-less and to not 
do your 'drop a patch from the previous stable version but don't 
bother dropping it from upstream first' kind of messy operation 
on it.

> What makes a patch droppable yesterday, but dependent on 
> mainline today?

Time and version release engineering: once a stable kernel is 
released any temporary integration testing results are flushed - 
the upstream kernel is where we maintain the information of 
which patch is broken and which not.

This memory-less process, amongst other things, helps the *next* 
major stable kernel become more robust, as it removes the 
possibility for version skew between stable and upstream.

If you want a revert you either need to report your problem fast 
enough to be caught in -stable integration testing, or you need 
to work with upstream to push the fix through properly.

People explained this to you, again and again, you refused to 
listen, repeatedly, again and again. There does not appear to be 
any rational set of arguments that will make you admit that you 
were wrong about this.

Anyway, in this discussion you have demonstrated it again why 
you are one of the very few commenters I had to permanently 
block on G+ ...

Thanks,

	Ingo

[ath9k-devel] [ 00/78] 3.3.2-stable review

[Ingo Molnar]

* Felipe Contreras <felipe.contreras@gmail.com> wrote:

> On Sat, Apr 14, 2012 at 1:47 PM, Ingo Molnar <mingo@kernel.org> wrote:
> >
> > * Felipe Contreras <felipe.contreras@gmail.com> wrote:
> >
> >> On Fri, Apr 13, 2012 at 1:07 AM, Linus Torvalds
> >> <torvalds@linux-foundation.org> wrote:
> >> > On Thu, Apr 12, 2012 at 3:04 PM, Felipe Contreras
> >> > <felipe.contreras@gmail.com> wrote:
> >> >>
> >> >> Sure, but removing that patch from the stable tree is not
> >> >> going the change that information; we already know the
> >> >> patch is wrong.
> >> >
> >> > .. and we wait until it has been fixed in mainline so that
> >> > we *know* that information doesn't get lost.
> >>
> >> So why don't we pick potentially dangerous patches that might
> >> benefit from some testing, put them in 'stable', and if there
> >> are problems, make sure they get fixed in upstream first?
> >>
> >> Or for that matter totally broken patches we want to make sure
> >> they get fixed in upstream.
> >>
> >> Because the priority of the 'stable' tree is *stability*. Is
> >> it not?
> >>
> >> But what you are saying is: *before* the final review, even a
> >> hint that the patch might cause problems is reason enough to
> >> drop it from stable, but *after* the review, if we know the
> >> patch is totally broken, then it's the opposite; we really
> >> want it in.
> >
> > What you don't seem to understand is that there are good reasons
> > why we first fix bugs upstream, then in -stable. Greg explained
> > it to you, Linus explained it to you and so did many others.
> >
> > Having an order of patches *necessarily* means that the
> > development tree will get fixes sooner than the stable tree. In
> > other words, this *necessarily* means that the stable tree - and
> > its users - will have to wait a little bit more to have the fix.
> > In the worst-case this 'have to wait a little bit longer' might
> > span the time between two minor stable kernel releases.
> >
> > You seem to equate this 'have to wait a little bit longer to get
> > the fix' property of the maintenance model with 'we don't care
> > about stable tree users' - that claim is obviously idiotic and
> > most of your arguments in this thread are idiotic as well.
> 
> This is a straw man again. Again; we are not talking about 
> fixes in 'stable' that don't exist in mainline, we are talking 
> about reverting patches from 'stable' that are not part of the 
> upstream release from where the 'stable' branch was forked.

You are misunderstanding the Linux kernel development process 
again:

> You are avoiding the argument you replying to; yesterday a 
> patch was droppable from the stable review queue, but today, 
> after the release, now we *need* it to stay there until it's 
> fixed in the mainline. What changed?

What changed: the stable kernel was released and a new cycle 
started. If something is broken in -stable it needs to be 
reverted upstream. Full stop.

There is a minor engineering process that if a -stable commit 
does not even apply or does not even boot on Greg's box or on 
the handful of boxes that test stable release candidates then it 
obviously cannot become part of the -stable queue. That kind of 
very short term, memory-less integration testing should not be 
confused with the much broader, state-ful, Git commit backed 
testing that the upstream kernel gets.

There's a new stable cycle every 7 days on average, there's a 
new upstream kernel every 7 days on average, and there's very 
good reasons for the stable queue to be memory-less and to not 
do your 'drop a patch from the previous stable version but don't 
bother dropping it from upstream first' kind of messy operation 
on it.

> What makes a patch droppable yesterday, but dependent on 
> mainline today?

Time and version release engineering: once a stable kernel is 
released any temporary integration testing results are flushed - 
the upstream kernel is where we maintain the information of 
which patch is broken and which not.

This memory-less process, amongst other things, helps the *next* 
major stable kernel become more robust, as it removes the 
possibility for version skew between stable and upstream.

If you want a revert you either need to report your problem fast 
enough to be caught in -stable integration testing, or you need 
to work with upstream to push the fix through properly.

People explained this to you, again and again, you refused to 
listen, repeatedly, again and again. There does not appear to be 
any rational set of arguments that will make you admit that you 
were wrong about this.

Anyway, in this discussion you have demonstrated it again why 
you are one of the very few commenters I had to permanently 
block on G+ ...

Thanks,

	Ingo

Re: [ 00/78] 3.3.2-stable review

[Felipe Contreras]

On Sun, Apr 15, 2012 at 9:51 AM, Ingo Molnar <mingo@kernel.org> wrote:
>
> * Felipe Contreras <felipe.contreras@gmail.com> wrote:

>> You are avoiding the argument you replying to; yesterday a
>> patch was droppable from the stable review queue, but today,
>> after the release, now we *need* it to stay there until it's
>> fixed in the mainline. What changed?
>
> What changed: the stable kernel was released and a new cycle
> started.

This is not a reason, this is just stating what happens without
explaining *why*.

Q: What changes when a tag is made?
A: A tag is made

> If something is broken in -stable it needs to be reverted upstream. Full stop.

And now you are describing the rule, without explaining the reason.

>> What makes a patch droppable yesterday, but dependent on
>> mainline today?
>
> Time and version release engineering: once a stable kernel is
> released any temporary integration testing results are flushed -

Yeah, but *why*? *Why* flush the testing results?

> the upstream kernel is where we maintain the information of
> which patch is broken and which not.

Sure, but that has nothing to do with the difference between today and
yesterday; both patches come from upstream. In both cases upstream
needs to be fixed.

> This memory-less process, amongst other things, helps the *next*
> major stable kernel become more robust, as it removes the
> possibility for version skew between stable and upstream.

If you keep the broken patch from yesterday (which is also from
upstream) and push it into the release, wouldn't that reduce the
version skew between stable and upstream as well?

Why is it that the patch from yesterday doesn't reduce the version
skew, but the patch from today does? You are not explaining *why*.

> If you want a revert you either need to report your problem fast
> enough to be caught in -stable integration testing, or you need
> to work with upstream to push the fix through properly.

And now you are assuming your assumption is right, and go right onto
the conclusion.

> People explained this to you, again and again, you refused to
> listen, repeatedly, again and again. There does not appear to be
> any rational set of arguments that will make you admit that you
> were wrong about this.

I'm sure if I try to argue rationally why hunting is bad with hunters,
they'll say I've refused to listen to all their rational set of
arguments. It's impossible that you are not explaining the *reason*
(there is none), it's impossible that you are being affected by herd
mentality, overconfidence, and confirmation bias. No, it cannot be any
of those things.

> Anyway, in this discussion you have demonstrated it again why
> you are one of the very few commenters I had to permanently
> block on G+ ...

Please, I provided irrefutable evidence for my argument, and I said I
would stop if you wanted me to, nobody forced you to continue the
discussion. You still blocked me even though you could have asked me
not to reply.

I can stop the discussion, I told so to Linus Torvalds on G+, if I'm told so.

I guess that would make you happy, but that doesn't mean you are
right. You are tip-toeing around the question and *never* giving a
real reason for why the patch from yesterday is different from the one
today.

It's like I'm asking why the freezer area is different from the normal
refrigerator area, and you are saying; well it's colder, it's usually
smaller, and it makes all food taste better. So you are either just
describing the differences without explaining the reason (being colder
helps for some foods), or you are providing an unsubstantiated claim;
you go from a) it's colder, to b) it makes all food taste better. And
when asked *why* again, you repeat, well, because it's colder. And
then you immediately go to the conclusion; therefore you should put as
much food in the freezer as possible.

Of course you would think all your answers are obvious and reasonable,
what else would you think? You, like everybody else (including me),
has a bias blind spot.

The fact of the matter is that there's *no reason* why the patch from
yesterday can be dropped, and the patch today can't. A tag was made,
but it doesn't change the nature of the patch; either way the patch is
bad, either way the patch is still in upstream.

You assume (correctly) that by keeping it in the stable branch, it
would guarantee it will be fixed in upstream sooner, but do we *need*
this guarantee? Would you buy a total guarantee for your house, if it
costs as much as the house itself? No, you need to look at the costs,
and the likelihood of the event you are guaranteeing against
happening, not just go "Oh!, guarantee! gimme!". The fact is that
without this guarantee, the fix will happen in a reasonable time in
upstream anyway. People have explained that in the past there have
been situations where fixes are lost, but that's an entirely different
situation (..v3.3), we are talking about stable reverts
(v3.3...v3.3.1), I challenged David Miller to find evidence for this
*ever* happening, and of course I didn't receive any answer. So no,
there's no evidence for that happening, you just think it will, let
alone how often will that be. You are making these patches guilty by
association. Plus, as I argued, somehow the 10000 of patches in queue
for the next stable release don't need this guarantee, so what's so
bad about making the patch from today one more of them?

And even more, even supposing we want this guarantee for the patch
from today, that doesn't explain why we don't want it from the patch
from yesterday. Again, this difference has *never* been explained. You
keep explaining why we want the guarantee, but never explain we why
don't want/need it for the patch from yesterday.

So you say bad patch should obviously not make it into stable:
Ingo: "if a -stable commit does not even apply or does not even boot
on Greg's box or on the handful of boxes that test stable release
candidates then it obviously cannot become part of the -stable queue."

And when asking why not get the same guarantee for the bad patch from yesterday:
Stefan: "That would be even sillier than the discussion which we are having."

When pressed about why it's sillier for the yesterday patch, but not
from today, Stefan Richter didn't reply, of course.

You are backed into a corner, you can't provide a good reason why you
treat them differently, so you are either going to keep describing the
difference, or you are going to keep explaining why the guarantee is
good, but not why B needs it, and A doesn't; because you don't have a
reason.

And when backed into a corner you are going to do what everybody does,
not stop for a second, and think deeply about the difference, but you
are going to use your bias blind spot, and assume that of course you
are right, and of course you are being reasonable, and of course your
arguments are flawless, and there's no more reason to discuss.
Accepting the possibility that there's no good reason for the
different treatment is not an option, of course, that would mean you
were wrong, and you can't.

FTR. I accept I might be wrong, and there's a good reason for this
different treatment, but I haven't seen any.

Cheers.

-- 
Felipe Contreras

[ath9k-devel] [ 00/78] 3.3.2-stable review

[Felipe Contreras]

On Sun, Apr 15, 2012 at 9:51 AM, Ingo Molnar <mingo@kernel.org> wrote:
>
> * Felipe Contreras <felipe.contreras@gmail.com> wrote:

>> You are avoiding the argument you replying to; yesterday a
>> patch was droppable from the stable review queue, but today,
>> after the release, now we *need* it to stay there until it's
>> fixed in the mainline. What changed?
>
> What changed: the stable kernel was released and a new cycle
> started.

This is not a reason, this is just stating what happens without
explaining *why*.

Q: What changes when a tag is made?
A: A tag is made

> If something is broken in -stable it needs to be reverted upstream. Full stop.

And now you are describing the rule, without explaining the reason.

>> What makes a patch droppable yesterday, but dependent on
>> mainline today?
>
> Time and version release engineering: once a stable kernel is
> released any temporary integration testing results are flushed -

Yeah, but *why*? *Why* flush the testing results?

> the upstream kernel is where we maintain the information of
> which patch is broken and which not.

Sure, but that has nothing to do with the difference between today and
yesterday; both patches come from upstream. In both cases upstream
needs to be fixed.

> This memory-less process, amongst other things, helps the *next*
> major stable kernel become more robust, as it removes the
> possibility for version skew between stable and upstream.

If you keep the broken patch from yesterday (which is also from
upstream) and push it into the release, wouldn't that reduce the
version skew between stable and upstream as well?

Why is it that the patch from yesterday doesn't reduce the version
skew, but the patch from today does? You are not explaining *why*.

> If you want a revert you either need to report your problem fast
> enough to be caught in -stable integration testing, or you need
> to work with upstream to push the fix through properly.

And now you are assuming your assumption is right, and go right onto
the conclusion.

> People explained this to you, again and again, you refused to
> listen, repeatedly, again and again. There does not appear to be
> any rational set of arguments that will make you admit that you
> were wrong about this.

I'm sure if I try to argue rationally why hunting is bad with hunters,
they'll say I've refused to listen to all their rational set of
arguments. It's impossible that you are not explaining the *reason*
(there is none), it's impossible that you are being affected by herd
mentality, overconfidence, and confirmation bias. No, it cannot be any
of those things.

> Anyway, in this discussion you have demonstrated it again why
> you are one of the very few commenters I had to permanently
> block on G+ ...

Please, I provided irrefutable evidence for my argument, and I said I
would stop if you wanted me to, nobody forced you to continue the
discussion. You still blocked me even though you could have asked me
not to reply.

I can stop the discussion, I told so to Linus Torvalds on G+, if I'm told so.

I guess that would make you happy, but that doesn't mean you are
right. You are tip-toeing around the question and *never* giving a
real reason for why the patch from yesterday is different from the one
today.

It's like I'm asking why the freezer area is different from the normal
refrigerator area, and you are saying; well it's colder, it's usually
smaller, and it makes all food taste better. So you are either just
describing the differences without explaining the reason (being colder
helps for some foods), or you are providing an unsubstantiated claim;
you go from a) it's colder, to b) it makes all food taste better. And
when asked *why* again, you repeat, well, because it's colder. And
then you immediately go to the conclusion; therefore you should put as
much food in the freezer as possible.

Of course you would think all your answers are obvious and reasonable,
what else would you think? You, like everybody else (including me),
has a bias blind spot.

The fact of the matter is that there's *no reason* why the patch from
yesterday can be dropped, and the patch today can't. A tag was made,
but it doesn't change the nature of the patch; either way the patch is
bad, either way the patch is still in upstream.

You assume (correctly) that by keeping it in the stable branch, it
would guarantee it will be fixed in upstream sooner, but do we *need*
this guarantee? Would you buy a total guarantee for your house, if it
costs as much as the house itself? No, you need to look at the costs,
and the likelihood of the event you are guaranteeing against
happening, not just go "Oh!, guarantee! gimme!". The fact is that
without this guarantee, the fix will happen in a reasonable time in
upstream anyway. People have explained that in the past there have
been situations where fixes are lost, but that's an entirely different
situation (..v3.3), we are talking about stable reverts
(v3.3...v3.3.1), I challenged David Miller to find evidence for this
*ever* happening, and of course I didn't receive any answer. So no,
there's no evidence for that happening, you just think it will, let
alone how often will that be. You are making these patches guilty by
association. Plus, as I argued, somehow the 10000 of patches in queue
for the next stable release don't need this guarantee, so what's so
bad about making the patch from today one more of them?

And even more, even supposing we want this guarantee for the patch
from today, that doesn't explain why we don't want it from the patch
from yesterday. Again, this difference has *never* been explained. You
keep explaining why we want the guarantee, but never explain we why
don't want/need it for the patch from yesterday.

So you say bad patch should obviously not make it into stable:
Ingo: "if a -stable commit does not even apply or does not even boot
on Greg's box or on the handful of boxes that test stable release
candidates then it obviously cannot become part of the -stable queue."

And when asking why not get the same guarantee for the bad patch from yesterday:
Stefan: "That would be even sillier than the discussion which we are having."

When pressed about why it's sillier for the yesterday patch, but not
from today, Stefan Richter didn't reply, of course.

You are backed into a corner, you can't provide a good reason why you
treat them differently, so you are either going to keep describing the
difference, or you are going to keep explaining why the guarantee is
good, but not why B needs it, and A doesn't; because you don't have a
reason.

And when backed into a corner you are going to do what everybody does,
not stop for a second, and think deeply about the difference, but you
are going to use your bias blind spot, and assume that of course you
are right, and of course you are being reasonable, and of course your
arguments are flawless, and there's no more reason to discuss.
Accepting the possibility that there's no good reason for the
different treatment is not an option, of course, that would mean you
were wrong, and you can't.

FTR. I accept I might be wrong, and there's a good reason for this
different treatment, but I haven't seen any.

Cheers.

-- 
Felipe Contreras

Re: [ 00/78] 3.3.2-stable review

[Willy Tarreau]

Felipe,

On Sun, Apr 15, 2012 at 08:15:23PM +0300, Felipe Contreras wrote:
(...)
> Why is it that the patch from yesterday doesn't reduce the version
> skew, but the patch from today does? You are not explaining *why*.

Severl of us have explained to you multiple times *why*. Either you're
having a parsing problem, or you don't understand anything to versionning
but in all cases you should try to educate yourself a minimum before
repeating the same question in loops.

> It's like I'm asking why the freezer area is different from the normal
> refrigerator area, and you are saying; well it's colder, it's usually
> smaller, and it makes all food taste better. So you are either just
> describing the differences without explaining the reason (being colder
> helps for some foods), or you are providing an unsubstantiated claim;
> you go from a) it's colder, to b) it makes all food taste better. And
> when asked *why* again, you repeat, well, because it's colder. And
> then you immediately go to the conclusion; therefore you should put as
> much food in the freezer as possible.

No, it's quite the opposite, almost everyone in this thread explained to
you that bacteria don't develop in cold and that's the reason it's better
to keep food. But you deliberately (or maybe inconsciously because you
don't know what bacteria are) wipe out these explanations and pretend
nobody explained the reason to you. 

Please re-read all responses, everything is there. I thought my explanation
was detailed enough to understand why it works that way, and Ingo explained
it in great details again. So please now make an effort to try to read what
people explain and stop pretending they refuse to respond, that's getting
really irritating.

The fact that you're the only one to ask this in loops should ring a bell,
it seems like many people managed to understand, either before this thread
or during this thread. It's up to you, I don't think that insisting on
people to explain the same things to you in many different ways will solve
your problems, really.

Regards,
Willy

[ath9k-devel] [ 00/78] 3.3.2-stable review

[Willy Tarreau]

Felipe,

On Sun, Apr 15, 2012 at 08:15:23PM +0300, Felipe Contreras wrote:
(...)
> Why is it that the patch from yesterday doesn't reduce the version
> skew, but the patch from today does? You are not explaining *why*.

Severl of us have explained to you multiple times *why*. Either you're
having a parsing problem, or you don't understand anything to versionning
but in all cases you should try to educate yourself a minimum before
repeating the same question in loops.

> It's like I'm asking why the freezer area is different from the normal
> refrigerator area, and you are saying; well it's colder, it's usually
> smaller, and it makes all food taste better. So you are either just
> describing the differences without explaining the reason (being colder
> helps for some foods), or you are providing an unsubstantiated claim;
> you go from a) it's colder, to b) it makes all food taste better. And
> when asked *why* again, you repeat, well, because it's colder. And
> then you immediately go to the conclusion; therefore you should put as
> much food in the freezer as possible.

No, it's quite the opposite, almost everyone in this thread explained to
you that bacteria don't develop in cold and that's the reason it's better
to keep food. But you deliberately (or maybe inconsciously because you
don't know what bacteria are) wipe out these explanations and pretend
nobody explained the reason to you. 

Please re-read all responses, everything is there. I thought my explanation
was detailed enough to understand why it works that way, and Ingo explained
it in great details again. So please now make an effort to try to read what
people explain and stop pretending they refuse to respond, that's getting
really irritating.

The fact that you're the only one to ask this in loops should ring a bell,
it seems like many people managed to understand, either before this thread
or during this thread. It's up to you, I don't think that insisting on
people to explain the same things to you in many different ways will solve
your problems, really.

Regards,
Willy

Re: [ 00/78] 3.3.2-stable review

[Linus Torvalds]

On Sun, Apr 15, 2012 at 10:15 AM, Felipe Contreras
<felipe.contreras@gmail.com> wrote:
>
> This is not a reason, this is just stating what happens without
> explaining *why*.
>
> Q: What changes when a tag is made?
> A: A tag is made

I'll make one more try at explaining to you, but then I'll just set my
mail reader to ignore you, because judging by past performance (not
just in this thread) you will just continue to argue.

I'll explain two things. None of those two things are actually about
"tags", although I will start with the issue that is at least
"coincidental" with tags, namely the fundamental nature of reality.

At no point is the "tag" at all important. You are bringing up all
these red herrings, and trying to actively confuse the issue.

The only thing that matters is "it's been made available to others".
That's fundamentally what a release is. If you know physics, think of
a release (and the tag is associated with it) as "collapsing the wave
function". Before that, the outside world doesn't know the exact state
of your tree (they may have good guesses based on the patches they've
seen) - after that, it's "done". You cannot change it. And more
importantly, other people can see the state, and measure it, and
depend on it.

This true regardless of git, btw, but git actually makes that "it's
been available to others" be a real technical distinction, since the
identity of something cannot be changed (so "availability" ends up
meaning "identity" - something is absolutely fixed in stone - you
can't change it, because what you made available is fixed and outside
of your control).

So once some release has been made, you can't change it. If Greg has
made a 3.3.2 release (the tag is not the important part, although the
tag is *coincidental* with the release, of course), then that is what
it is. You cannot change history. You cannot say "oh, we can go back
in time and undo things". There is no change that is a no-op.

THAT is important. And it seems to be something that you don't
understand. The past is immutable. A "tag" has no real other meaning
than as a particular marker of a particular past state. But the tag
itself is not what makes the past immutable. REALITY is what makes the
past immutable.

And reverting a patch DOES NOT CHANGE HISTORY.  It does not magically
go back in time and say "nothing happened". Every time you say that
"reverting a pacth is a no-op", you look more and more stupid, because
you don't seem to understand this fundamental fact.

A revert is nothing but another change. A revert is *exactly* the same
thing as a patch that doesn't revert, but instead fixes. If you cannot
understand that, you're not worth talking to.

And the reason we don't do reverts in stable releases without having
the revert upstream is *EXACTLY* the same reason we don't make other
changes in stable releases without making that change upstream first.

And another really fundamental thing that you don't seem to understand
is that the most important part of "stability" is not actually "bug
free" (which is something we can never attain in any project that is
non-trivial and still evolving), but "reliability". Not even of a
single release, but in *time*. We want to make fundamental and
*reliable* forward progress. And that is why we have the whole "we
don't make changes to the stable tree without having those changes in
upstream first".

And the thing is, it's not just 3.3.3 that follows 3.3.2. It's 3.4.1
too. The reason we have the "no stable fixes before it's been
upstreamed" (and again: a "revert" is *nothing* but another name for a
fix, that gives some additional information about *how* we fixed
something too) is because we want to make nice plodding reliable
forward progress. Mistakes (== bugs) will happen, but the stable rules
are there to make sure that those mistakes get fixed, and don't have
long-term impact. THAT is the "stable" part of the stable series.
Things are monotonic in the big picture, even if we may have some
non-monotonic noise in the details.

If you think that "stable" means "bug free", you are fundamentally
confused about software engineering.

If you think you can go back in time and "undo" things, you are even
more fundamentally confused about reality.

And if you cannot understand what tens of people have tried to explain
to you, you are just f*cking stupid.

                     Linus

[ath9k-devel] [ 00/78] 3.3.2-stable review

[Linus Torvalds]

On Sun, Apr 15, 2012 at 10:15 AM, Felipe Contreras
<felipe.contreras@gmail.com> wrote:
>
> This is not a reason, this is just stating what happens without
> explaining *why*.
>
> Q: What changes when a tag is made?
> A: A tag is made

I'll make one more try at explaining to you, but then I'll just set my
mail reader to ignore you, because judging by past performance (not
just in this thread) you will just continue to argue.

I'll explain two things. None of those two things are actually about
"tags", although I will start with the issue that is at least
"coincidental" with tags, namely the fundamental nature of reality.

At no point is the "tag" at all important. You are bringing up all
these red herrings, and trying to actively confuse the issue.

The only thing that matters is "it's been made available to others".
That's fundamentally what a release is. If you know physics, think of
a release (and the tag is associated with it) as "collapsing the wave
function". Before that, the outside world doesn't know the exact state
of your tree (they may have good guesses based on the patches they've
seen) - after that, it's "done". You cannot change it. And more
importantly, other people can see the state, and measure it, and
depend on it.

This true regardless of git, btw, but git actually makes that "it's
been available to others" be a real technical distinction, since the
identity of something cannot be changed (so "availability" ends up
meaning "identity" - something is absolutely fixed in stone - you
can't change it, because what you made available is fixed and outside
of your control).

So once some release has been made, you can't change it. If Greg has
made a 3.3.2 release (the tag is not the important part, although the
tag is *coincidental* with the release, of course), then that is what
it is. You cannot change history. You cannot say "oh, we can go back
in time and undo things". There is no change that is a no-op.

THAT is important. And it seems to be something that you don't
understand. The past is immutable. A "tag" has no real other meaning
than as a particular marker of a particular past state. But the tag
itself is not what makes the past immutable. REALITY is what makes the
past immutable.

And reverting a patch DOES NOT CHANGE HISTORY.  It does not magically
go back in time and say "nothing happened". Every time you say that
"reverting a pacth is a no-op", you look more and more stupid, because
you don't seem to understand this fundamental fact.

A revert is nothing but another change. A revert is *exactly* the same
thing as a patch that doesn't revert, but instead fixes. If you cannot
understand that, you're not worth talking to.

And the reason we don't do reverts in stable releases without having
the revert upstream is *EXACTLY* the same reason we don't make other
changes in stable releases without making that change upstream first.

And another really fundamental thing that you don't seem to understand
is that the most important part of "stability" is not actually "bug
free" (which is something we can never attain in any project that is
non-trivial and still evolving), but "reliability". Not even of a
single release, but in *time*. We want to make fundamental and
*reliable* forward progress. And that is why we have the whole "we
don't make changes to the stable tree without having those changes in
upstream first".

And the thing is, it's not just 3.3.3 that follows 3.3.2. It's 3.4.1
too. The reason we have the "no stable fixes before it's been
upstreamed" (and again: a "revert" is *nothing* but another name for a
fix, that gives some additional information about *how* we fixed
something too) is because we want to make nice plodding reliable
forward progress. Mistakes (== bugs) will happen, but the stable rules
are there to make sure that those mistakes get fixed, and don't have
long-term impact. THAT is the "stable" part of the stable series.
Things are monotonic in the big picture, even if we may have some
non-monotonic noise in the details.

If you think that "stable" means "bug free", you are fundamentally
confused about software engineering.

If you think you can go back in time and "undo" things, you are even
more fundamentally confused about reality.

And if you cannot understand what tens of people have tried to explain
to you, you are just f*cking stupid.

                     Linus

Re: [ 00/78] 3.3.2-stable review

[Felipe Contreras]

On Sun, Apr 15, 2012 at 8:49 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> On Sun, Apr 15, 2012 at 10:15 AM, Felipe Contreras
> <felipe.contreras@gmail.com> wrote:
>>
>> This is not a reason, this is just stating what happens without
>> explaining *why*.
>>
>> Q: What changes when a tag is made?
>> A: A tag is made

[...]

> The only thing that matters is "it's been made available to others".

Exactly! Now *this* is a reason. After sending that mail I tried to
think of one since nobody else came up with it. This is in fact, a
good reason, but it implies something I'll explain below.

[...]

I do agree with all what you said above.

> And the thing is, it's not just 3.3.3 that follows 3.3.2. It's 3.4.1
> too. The reason we have the "no stable fixes before it's been
> upstreamed" (and again: a "revert" is *nothing* but another name for a
> fix, that gives some additional information about *how* we fixed
> something too) is because we want to make nice plodding reliable
> forward progress. Mistakes (== bugs) will happen, but the stable rules
> are there to make sure that those mistakes get fixed, and don't have
> long-term impact. THAT is the "stable" part of the stable series.
> Things are monotonic in the big picture, even if we may have some
> non-monotonic noise in the details.

I'm not going to argue the semantics of what is a revert, but I am
going to show the difference between the two situations:

a) v3.0* (good), v3.1* (good), v3.2* (good), v3.3 (good), v3.3.1
(bad), v3.3.2 (good), v3.4 (bad)
b) v3.0* (bad), v3.1* (bad), v3.2* (bad), v3.3 (bad), v3.3.1 (good), v3.4 (bad)

Maybe they are the same from certain point of view, but you just
argued that what *others* see is what makes the patch unrevertable,
well, it's obvious that from the point of view of the users the two
situations are clearly different. I believe it was you who said that
breaking user experience is the absolute no-no any project could
make[1]--so from that point of view a) is *much* worst.

But what is done is done, and as you said, you can't change the past,
now the important thing is what to do next. And here are the two
options' worst-case scenarios:

a.1) v3.0* (good), ... v3.3 (good), v3.3.1 (bad), v3.3.2 (bad), v3.3.3
(bad), v3.3.4 (bad), v3.3.5 (bad), v3.4 (good)
a.2) v3.0* (good), ... v3.3 (good), v3.3.1 (bad), v3.3.2 (good),
v3.3.3 (good), v3.3.4 (good), v3.3.5 (good), v3.4 (bad)

These two scenarios are unlikely, but either way, in order to
guarantee that you don't end up with a.2) You are willing to risk
going into a.1)

So, *obviously* v3.4 is more important than v3.3.x. I could argue that
the users out there would prefer a.1) any day, because it's unlikely
anyway (v3.4 would be good), but I won't.

All I want now is to agree on a reason, you have finally pointed out
that the reason for this different treatment is the user's visibility,
but that still doesn't explain why the rules for b) automatically
apply to a), since it's clearly different from the users's point of
view; if you agree that v3.4 is more important than v3.3.x, I believe
we have the reason right there.

Cheers.

[1] http://www.youtube.com/watch?v=kzKzUBLEzwk

-- 
Felipe Contreras

[ath9k-devel] [ 00/78] 3.3.2-stable review

[Felipe Contreras]

On Sun, Apr 15, 2012 at 8:49 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> On Sun, Apr 15, 2012 at 10:15 AM, Felipe Contreras
> <felipe.contreras@gmail.com> wrote:
>>
>> This is not a reason, this is just stating what happens without
>> explaining *why*.
>>
>> Q: What changes when a tag is made?
>> A: A tag is made

[...]

> The only thing that matters is "it's been made available to others".

Exactly! Now *this* is a reason. After sending that mail I tried to
think of one since nobody else came up with it. This is in fact, a
good reason, but it implies something I'll explain below.

[...]

I do agree with all what you said above.

> And the thing is, it's not just 3.3.3 that follows 3.3.2. It's 3.4.1
> too. The reason we have the "no stable fixes before it's been
> upstreamed" (and again: a "revert" is *nothing* but another name for a
> fix, that gives some additional information about *how* we fixed
> something too) is because we want to make nice plodding reliable
> forward progress. Mistakes (== bugs) will happen, but the stable rules
> are there to make sure that those mistakes get fixed, and don't have
> long-term impact. THAT is the "stable" part of the stable series.
> Things are monotonic in the big picture, even if we may have some
> non-monotonic noise in the details.

I'm not going to argue the semantics of what is a revert, but I am
going to show the difference between the two situations:

a) v3.0* (good), v3.1* (good), v3.2* (good), v3.3 (good), v3.3.1
(bad), v3.3.2 (good), v3.4 (bad)
b) v3.0* (bad), v3.1* (bad), v3.2* (bad), v3.3 (bad), v3.3.1 (good), v3.4 (bad)

Maybe they are the same from certain point of view, but you just
argued that what *others* see is what makes the patch unrevertable,
well, it's obvious that from the point of view of the users the two
situations are clearly different. I believe it was you who said that
breaking user experience is the absolute no-no any project could
make[1]--so from that point of view a) is *much* worst.

But what is done is done, and as you said, you can't change the past,
now the important thing is what to do next. And here are the two
options' worst-case scenarios:

a.1) v3.0* (good), ... v3.3 (good), v3.3.1 (bad), v3.3.2 (bad), v3.3.3
(bad), v3.3.4 (bad), v3.3.5 (bad), v3.4 (good)
a.2) v3.0* (good), ... v3.3 (good), v3.3.1 (bad), v3.3.2 (good),
v3.3.3 (good), v3.3.4 (good), v3.3.5 (good), v3.4 (bad)

These two scenarios are unlikely, but either way, in order to
guarantee that you don't end up with a.2) You are willing to risk
going into a.1)

So, *obviously* v3.4 is more important than v3.3.x. I could argue that
the users out there would prefer a.1) any day, because it's unlikely
anyway (v3.4 would be good), but I won't.

All I want now is to agree on a reason, you have finally pointed out
that the reason for this different treatment is the user's visibility,
but that still doesn't explain why the rules for b) automatically
apply to a), since it's clearly different from the users's point of
view; if you agree that v3.4 is more important than v3.3.x, I believe
we have the reason right there.

Cheers.

[1] http://www.youtube.com/watch?v=kzKzUBLEzwk

-- 
Felipe Contreras

Re: [ 00/78] 3.3.2-stable review

[Ingo Molnar]

* Felipe Contreras <felipe.contreras@gmail.com> wrote:

> On Sun, Apr 15, 2012 at 8:49 PM, Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
> > On Sun, Apr 15, 2012 at 10:15 AM, Felipe Contreras
> > <felipe.contreras@gmail.com> wrote:
> >>
> >> This is not a reason, this is just stating what happens without
> >> explaining *why*.
> >>
> >> Q: What changes when a tag is made?
> >> A: A tag is made
> 
> [...]
> 
> > The only thing that matters is "it's been made available to others".
> 
> Exactly! Now *this* is a reason. [...]

Erm, many people referred to that in this discussion explicitly 
and implicitly - beyond its well-known technical meaning it's 
also the English meaning of the word 'release':

   http://www.merriam-webster.com/dictionary/releasing

  : [...] to make available to the public [...]

So stop pretending that this is somehow the mistake of *others* 
explaining it to you wrong ...

Just admit it already that you were trivially and dead wrong all 
along, and that you were pretty difficult and obnoxious about 
handling a discussion that went against you.

Being wrong is normal and it happens all the time - and a big 
part of the picture is how you handle such situations, to not 
try to wriggle out of the responsibility of being wrong and to 
not waste other people's time with such self-gratifying mental 
obfuscation.

Such as:

> I'm not going to argue the semantics of what is a revert, 
> [...]

You should not argue about the semantics about a revert not 
because somehow it's not important (it is), but because you've 
been wrong about this issue too. You should learn and improve.

Thanks,

	Ingo

[ath9k-devel] [ 00/78] 3.3.2-stable review

[Ingo Molnar]

* Felipe Contreras <felipe.contreras@gmail.com> wrote:

> On Sun, Apr 15, 2012 at 8:49 PM, Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
> > On Sun, Apr 15, 2012 at 10:15 AM, Felipe Contreras
> > <felipe.contreras@gmail.com> wrote:
> >>
> >> This is not a reason, this is just stating what happens without
> >> explaining *why*.
> >>
> >> Q: What changes when a tag is made?
> >> A: A tag is made
> 
> [...]
> 
> > The only thing that matters is "it's been made available to others".
> 
> Exactly! Now *this* is a reason. [...]

Erm, many people referred to that in this discussion explicitly 
and implicitly - beyond its well-known technical meaning it's 
also the English meaning of the word 'release':

   http://www.merriam-webster.com/dictionary/releasing

  : [...] to make available to the public [...]

So stop pretending that this is somehow the mistake of *others* 
explaining it to you wrong ...

Just admit it already that you were trivially and dead wrong all 
along, and that you were pretty difficult and obnoxious about 
handling a discussion that went against you.

Being wrong is normal and it happens all the time - and a big 
part of the picture is how you handle such situations, to not 
try to wriggle out of the responsibility of being wrong and to 
not waste other people's time with such self-gratifying mental 
obfuscation.

Such as:

> I'm not going to argue the semantics of what is a revert, 
> [...]

You should not argue about the semantics about a revert not 
because somehow it's not important (it is), but because you've 
been wrong about this issue too. You should learn and improve.

Thanks,

	Ingo

Re: [ 00/78] 3.3.2-stable review

[Willy Tarreau]

On Mon, Apr 16, 2012 at 01:12:48AM +0300, Felipe Contreras wrote:
> I'm not going to argue the semantics of what is a revert, but I am
> going to show the difference between the two situations:
> 
> a) v3.0* (good), v3.1* (good), v3.2* (good), v3.3 (good), v3.3.1
> (bad), v3.3.2 (good), v3.4 (bad)

This situation is not possible thanks to the process : if v3.3.2 has
a fix that was not in 3.3.1, then this fix is also in 3.4.

> b) v3.0* (bad), v3.1* (bad), v3.2* (bad), v3.3 (bad), v3.3.1 (good), v3.4 (bad)

Same here.

> Maybe they are the same from certain point of view, but you just
> argued that what *others* see is what makes the patch unrevertable,
> well, it's obvious that from the point of view of the users the two
> situations are clearly different. I believe it was you who said that
> breaking user experience is the absolute no-no any project could
> make[1]--so from that point of view a) is *much* worst.
> 
> But what is done is done, and as you said, you can't change the past,
> now the important thing is what to do next. And here are the two
> options' worst-case scenarios:
> 
> a.1) v3.0* (good), ... v3.3 (good), v3.3.1 (bad), v3.3.2 (bad), v3.3.3
> (bad), v3.3.4 (bad), v3.3.5 (bad), v3.4 (good)

This situation is stupid as it means we'd refuse to fix the issue.

> a.2) v3.0* (good), ... v3.3 (good), v3.3.1 (bad), v3.3.2 (good),
> v3.3.3 (good), v3.3.4 (good), v3.3.5 (good), v3.4 (bad)

Not possible.

> These two scenarios are unlikely, but either way, in order to
> guarantee that you don't end up with a.2) You are willing to risk
> going into a.1)

You don't seem to understand that 3.4 is not *after* 3.3.x, but in parallel.
This is more like this :

  3.2 ----- 3.3 --------- 3.4-rc* ------------- 3.4 ----- 3.5-rc* --------
               \                                    \
                \                                    `--- 3.4.1 ---- 3.4.2 --
                 \
                  `--- 3.3.1 ----- 3.3.2 ---- 3.3.3 ---- 3.3.4 --- 3.3.5 ---

Here you clearly see why everything in 3.3.x must come from upstream and
why it's important that 3.4 has every fix that 3.3 has.

> So, *obviously* v3.4 is more important than v3.3.x. I could argue that
> the users out there would prefer a.1) any day, because it's unlikely
> anyway (v3.4 would be good), but I won't.

No because for them it would mean end of support at one point when 3.3 dies,
with no ability to upgrade.

> All I want now is to agree on a reason, you have finally pointed out
> that the reason for this different treatment is the user's visibility,

It's not the user's visibility, it's published code. Once code is published,
you cannot magically fix it without emitting a new patch for this code and
announcing so that users apply it. These patches are called stable releases.
Users want a good reason to apply these patches, rebuild and reboot, and
that's one reason we absolutely want to have the commit descriptions from
upstream which detail the exact reason for the patch (even if it's a revert).

> but that still doesn't explain why the rules for b) automatically
> apply to a), since it's clearly different from the users's point of
> view; if you agree that v3.4 is more important than v3.3.x, I believe
> we have the reason right there.

It's not "more important", it's important for long-term stability. For
3.3 users, 3.3.x is more important that 3.4. However one thing is certain:
3.4 users are not going to push fixes into 3.3.x, but thanks to the process
we have, 3.3.x users are going to ask for a fix to be pushed upstream. So
users pressure ensure long-term stability.

Willy

[ath9k-devel] [ 00/78] 3.3.2-stable review

[Willy Tarreau]

On Mon, Apr 16, 2012 at 01:12:48AM +0300, Felipe Contreras wrote:
> I'm not going to argue the semantics of what is a revert, but I am
> going to show the difference between the two situations:
> 
> a) v3.0* (good), v3.1* (good), v3.2* (good), v3.3 (good), v3.3.1
> (bad), v3.3.2 (good), v3.4 (bad)

This situation is not possible thanks to the process : if v3.3.2 has
a fix that was not in 3.3.1, then this fix is also in 3.4.

> b) v3.0* (bad), v3.1* (bad), v3.2* (bad), v3.3 (bad), v3.3.1 (good), v3.4 (bad)

Same here.

> Maybe they are the same from certain point of view, but you just
> argued that what *others* see is what makes the patch unrevertable,
> well, it's obvious that from the point of view of the users the two
> situations are clearly different. I believe it was you who said that
> breaking user experience is the absolute no-no any project could
> make[1]--so from that point of view a) is *much* worst.
> 
> But what is done is done, and as you said, you can't change the past,
> now the important thing is what to do next. And here are the two
> options' worst-case scenarios:
> 
> a.1) v3.0* (good), ... v3.3 (good), v3.3.1 (bad), v3.3.2 (bad), v3.3.3
> (bad), v3.3.4 (bad), v3.3.5 (bad), v3.4 (good)

This situation is stupid as it means we'd refuse to fix the issue.

> a.2) v3.0* (good), ... v3.3 (good), v3.3.1 (bad), v3.3.2 (good),
> v3.3.3 (good), v3.3.4 (good), v3.3.5 (good), v3.4 (bad)

Not possible.

> These two scenarios are unlikely, but either way, in order to
> guarantee that you don't end up with a.2) You are willing to risk
> going into a.1)

You don't seem to understand that 3.4 is not *after* 3.3.x, but in parallel.
This is more like this :

  3.2 ----- 3.3 --------- 3.4-rc* ------------- 3.4 ----- 3.5-rc* --------
               \                                    \
                \                                    `--- 3.4.1 ---- 3.4.2 --
                 \
                  `--- 3.3.1 ----- 3.3.2 ---- 3.3.3 ---- 3.3.4 --- 3.3.5 ---

Here you clearly see why everything in 3.3.x must come from upstream and
why it's important that 3.4 has every fix that 3.3 has.

> So, *obviously* v3.4 is more important than v3.3.x. I could argue that
> the users out there would prefer a.1) any day, because it's unlikely
> anyway (v3.4 would be good), but I won't.

No because for them it would mean end of support at one point when 3.3 dies,
with no ability to upgrade.

> All I want now is to agree on a reason, you have finally pointed out
> that the reason for this different treatment is the user's visibility,

It's not the user's visibility, it's published code. Once code is published,
you cannot magically fix it without emitting a new patch for this code and
announcing so that users apply it. These patches are called stable releases.
Users want a good reason to apply these patches, rebuild and reboot, and
that's one reason we absolutely want to have the commit descriptions from
upstream which detail the exact reason for the patch (even if it's a revert).

> but that still doesn't explain why the rules for b) automatically
> apply to a), since it's clearly different from the users's point of
> view; if you agree that v3.4 is more important than v3.3.x, I believe
> we have the reason right there.

It's not "more important", it's important for long-term stability. For
3.3 users, 3.3.x is more important that 3.4. However one thing is certain:
3.4 users are not going to push fixes into 3.3.x, but thanks to the process
we have, 3.3.x users are going to ask for a fix to be pushed upstream. So
users pressure ensure long-term stability.

Willy

Re: [ 00/78] 3.3.2-stable review

[Ingo Molnar]

* Willy Tarreau <w@1wt.eu> wrote:

> It's not the user's visibility, it's published code. Once code 
> is published, you cannot magically fix it without emitting a 
> new patch for this code and announcing so that users apply it. 
> These patches are called stable releases. Users want a good 
> reason to apply these patches, rebuild and reboot, and that's 
> one reason we absolutely want to have the commit descriptions 
> from upstream which detail the exact reason for the patch 
> (even if it's a revert).

Let me also outline why reverts are important and why they are 
not just 'a patch removed'.

A revert carries valuable information: we revert a broken commit 
not just with the terse description that it's broken, but with 
an exact description about *why* it's broken and how that 
breakage relates to the original patch.

In the limited 'patch space' nothing happened: a patch was done, 
then undone.

In the Git 'commit space' the picture is very different: we have 
a commit that does a change with a justification and we have 
*another* commit that undoes the code modification with 
*another* justification.

We got richer by two justifications and the kernel got
*more stable* in the process even though no actual code
changed:

 - We very likely won't repeat this mistake again, it's 
   documented for eternity to any developer touching this
   code in the future. See Linus's arguments about 'monotonic 
   progress'. Git hashes force the causality of the real 
   physical world on us, which is *especially* useful when we 
   make mistakes and would like to use a digital time machine 
   that whitewashes our shades of grey history.

 - In practice developers tend to be more careful with code that
   sees an above average ration of reverts. It's a red flag - it 
   shows that the code, the hardware or the development process 
   maintaining that code is somehow non-obvious and fragile for 
   one reason or another.

 - In most cases a change+revert also spurs further development: 
   the original justification is likely valid and people want to
   achieve that advantage but via some other, non-broken means. 
   In that sense the revert is a persistent TODO entry as well, 
   for developers.

If the bug was just a report somewhere in a mailing list archive 
on the web then it would bitrot quickly and people would not 
have a way to find it and react to it in an organized way.

By making it a Git commit; the change, the fix and all the 
justifications around it become a permanent part of Linux - 
which is more than just 15 million lines of code ...

Thanks,

	Ingo

[ath9k-devel] [ 00/78] 3.3.2-stable review

[Ingo Molnar]

* Willy Tarreau <w@1wt.eu> wrote:

> It's not the user's visibility, it's published code. Once code 
> is published, you cannot magically fix it without emitting a 
> new patch for this code and announcing so that users apply it. 
> These patches are called stable releases. Users want a good 
> reason to apply these patches, rebuild and reboot, and that's 
> one reason we absolutely want to have the commit descriptions 
> from upstream which detail the exact reason for the patch 
> (even if it's a revert).

Let me also outline why reverts are important and why they are 
not just 'a patch removed'.

A revert carries valuable information: we revert a broken commit 
not just with the terse description that it's broken, but with 
an exact description about *why* it's broken and how that 
breakage relates to the original patch.

In the limited 'patch space' nothing happened: a patch was done, 
then undone.

In the Git 'commit space' the picture is very different: we have 
a commit that does a change with a justification and we have 
*another* commit that undoes the code modification with 
*another* justification.

We got richer by two justifications and the kernel got
*more stable* in the process even though no actual code
changed:

 - We very likely won't repeat this mistake again, it's 
   documented for eternity to any developer touching this
   code in the future. See Linus's arguments about 'monotonic 
   progress'. Git hashes force the causality of the real 
   physical world on us, which is *especially* useful when we 
   make mistakes and would like to use a digital time machine 
   that whitewashes our shades of grey history.

 - In practice developers tend to be more careful with code that
   sees an above average ration of reverts. It's a red flag - it 
   shows that the code, the hardware or the development process 
   maintaining that code is somehow non-obvious and fragile for 
   one reason or another.

 - In most cases a change+revert also spurs further development: 
   the original justification is likely valid and people want to
   achieve that advantage but via some other, non-broken means. 
   In that sense the revert is a persistent TODO entry as well, 
   for developers.

If the bug was just a report somewhere in a mailing list archive 
on the web then it would bitrot quickly and people would not 
have a way to find it and react to it in an organized way.

By making it a Git commit; the change, the fix and all the 
justifications around it become a permanent part of Linux - 
which is more than just 15 million lines of code ...

Thanks,

	Ingo

Re: [ath9k-devel] [ 00/78] 3.3.2-stable review

[Greg KH]

Just one minor correction in this looney email thread:

On Sat, Apr 14, 2012 at 01:53:22AM +0300, Felipe Contreras wrote:
> v3.3.x on the other hand are *not* stable. They contain patches
> backported from v3.4, but nobody guarantees they will work. There was
> no v3.3.1-rc1, so the first time the patches compromising v3.3.1 were
> generally tested together is in v3.3.1, at which point if somebody
> finds issues, it's too late; bad patches are *not* going to be removed
> in v3.3.2.

Of course there was a 3.3.1-rc1, see the linux-kernel archives for the
announcemen and the individual patches.  kernel.org has the large patch
itself if you like that format instead.

greg k-h

[ath9k-devel] [ 00/78] 3.3.2-stable review

[Greg KH]

Just one minor correction in this looney email thread:

On Sat, Apr 14, 2012 at 01:53:22AM +0300, Felipe Contreras wrote:
> v3.3.x on the other hand are *not* stable. They contain patches
> backported from v3.4, but nobody guarantees they will work. There was
> no v3.3.1-rc1, so the first time the patches compromising v3.3.1 were
> generally tested together is in v3.3.1, at which point if somebody
> finds issues, it's too late; bad patches are *not* going to be removed
> in v3.3.2.

Of course there was a 3.3.1-rc1, see the linux-kernel archives for the
announcemen and the individual patches.  kernel.org has the large patch
itself if you like that format instead.

greg k-h

Re: [ath9k-devel] [ 00/78] 3.3.2-stable review

[Felipe Contreras]

On Mon, Apr 16, 2012 at 7:27 PM, Greg KH <gregkh@linuxfoundation.org> wrote:
> Just one minor correction in this looney email thread:
>
> On Sat, Apr 14, 2012 at 01:53:22AM +0300, Felipe Contreras wrote:
>> v3.3.x on the other hand are *not* stable. They contain patches
>> backported from v3.4, but nobody guarantees they will work. There was
>> no v3.3.1-rc1, so the first time the patches compromising v3.3.1 were
>> generally tested together is in v3.3.1, at which point if somebody
>> finds issues, it's too late; bad patches are *not* going to be removed
>> in v3.3.2.
>
> Of course there was a 3.3.1-rc1, see the linux-kernel archives for the
> announcemen and the individual patches.  kernel.org has the large patch
> itself if you like that format instead.

I don't see it here:
http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=tags

If you really want people to try it, why not tag it?

-- 
Felipe Contreras

[ath9k-devel] [ 00/78] 3.3.2-stable review

[Felipe Contreras]

On Mon, Apr 16, 2012 at 7:27 PM, Greg KH <gregkh@linuxfoundation.org> wrote:
> Just one minor correction in this looney email thread:
>
> On Sat, Apr 14, 2012 at 01:53:22AM +0300, Felipe Contreras wrote:
>> v3.3.x on the other hand are *not* stable. They contain patches
>> backported from v3.4, but nobody guarantees they will work. There was
>> no v3.3.1-rc1, so the first time the patches compromising v3.3.1 were
>> generally tested together is in v3.3.1, at which point if somebody
>> finds issues, it's too late; bad patches are *not* going to be removed
>> in v3.3.2.
>
> Of course there was a 3.3.1-rc1, see the linux-kernel archives for the
> announcemen and the individual patches. ?kernel.org has the large patch
> itself if you like that format instead.

I don't see it here:
http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=tags

If you really want people to try it, why not tag it?

-- 
Felipe Contreras

Re: [ 00/78] 3.3.2-stable review

[Felipe Contreras]

On Mon, Apr 16, 2012 at 8:32 AM, Ingo Molnar <mingo@kernel.org> wrote:
>
> * Felipe Contreras <felipe.contreras@gmail.com> wrote:
>
>> On Sun, Apr 15, 2012 at 8:49 PM, Linus Torvalds
>> <torvalds@linux-foundation.org> wrote:

>> > The only thing that matters is "it's been made available to others".
>>
>> Exactly! Now *this* is a reason. [...]
>
> Erm, many people referred to that in this discussion explicitly
> and implicitly - beyond its well-known technical meaning it's
> also the English meaning of the word 'release':
>
>   http://www.merriam-webster.com/dictionary/releasing

Releasing implies many things. There is this notion called theory of
mind, which children learn at a very young age, that helps us see the
world through the eyes of other people. If you think people *must* see
the word "release" and think *exactly* the same thing as  you do, and
apologize when they don't, well, I'd say you are missing a very
valuable skill.

But fine, lets suppose I should have thought exactly the same thing as
you did, and fine, lets say I was wrong in not doing so. That still
doesn't help one iota in this discussion. Linus Torvalds pointed the
exact reason, which allowed us to move forward, because of my
incompetence, or whatever.

The next logical question has still not been answered; does the
undroppability come from the fact that v3.4 is more important that
v3.3.1? This time I promise to think at least one day for all the
possible meanings of each key word you say.

-- 
Felipe Contreras

[ath9k-devel] [ 00/78] 3.3.2-stable review

[Felipe Contreras]

On Mon, Apr 16, 2012 at 8:32 AM, Ingo Molnar <mingo@kernel.org> wrote:
>
> * Felipe Contreras <felipe.contreras@gmail.com> wrote:
>
>> On Sun, Apr 15, 2012 at 8:49 PM, Linus Torvalds
>> <torvalds@linux-foundation.org> wrote:

>> > The only thing that matters is "it's been made available to others".
>>
>> Exactly! Now *this* is a reason. [...]
>
> Erm, many people referred to that in this discussion explicitly
> and implicitly - beyond its well-known technical meaning it's
> also the English meaning of the word 'release':
>
> ? http://www.merriam-webster.com/dictionary/releasing

Releasing implies many things. There is this notion called theory of
mind, which children learn at a very young age, that helps us see the
world through the eyes of other people. If you think people *must* see
the word "release" and think *exactly* the same thing as  you do, and
apologize when they don't, well, I'd say you are missing a very
valuable skill.

But fine, lets suppose I should have thought exactly the same thing as
you did, and fine, lets say I was wrong in not doing so. That still
doesn't help one iota in this discussion. Linus Torvalds pointed the
exact reason, which allowed us to move forward, because of my
incompetence, or whatever.

The next logical question has still not been answered; does the
undroppability come from the fact that v3.4 is more important that
v3.3.1? This time I promise to think at least one day for all the
possible meanings of each key word you say.

-- 
Felipe Contreras

Re: [ath9k-devel] [ 00/78] 3.3.2-stable review

[Greg KH]

On Mon, Apr 16, 2012 at 11:11:05PM +0300, Felipe Contreras wrote:
> On Mon, Apr 16, 2012 at 7:27 PM, Greg KH <gregkh@linuxfoundation.org> wrote:
> > Just one minor correction in this looney email thread:
> >
> > On Sat, Apr 14, 2012 at 01:53:22AM +0300, Felipe Contreras wrote:
> >> v3.3.x on the other hand are *not* stable. They contain patches
> >> backported from v3.4, but nobody guarantees they will work. There was
> >> no v3.3.1-rc1, so the first time the patches compromising v3.3.1 were
> >> generally tested together is in v3.3.1, at which point if somebody
> >> finds issues, it's too late; bad patches are *not* going to be removed
> >> in v3.3.2.
> >
> > Of course there was a 3.3.1-rc1, see the linux-kernel archives for the
> > announcemen and the individual patches.  kernel.org has the large patch
> > itself if you like that format instead.
> 
> I don't see it here:
> http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=tags
> 
> If you really want people to try it, why not tag it?

That would be because I don't keep it in that tree.  It is in a quilt
tree you can find in the stable-queue.git repo, and I have never tagged
-rc1 releases there.  No one has ever asked for it before, so in the
past 6 years of stable releases, I guess no one ever needed it.

ketchup and tarballs seem to work well for others, perhaps you can use
that as well (hint, ketchup on top of the linux-stable tree works just
fine for testing this.)

greg k-h

Re: [ath9k-devel] [ 00/78] 3.3.2-stable review

[Greg KH]

On Mon, Apr 16, 2012 at 11:11:05PM +0300, Felipe Contreras wrote:
> On Mon, Apr 16, 2012 at 7:27 PM, Greg KH <gregkh@linuxfoundation.org> wrote:
> > Just one minor correction in this looney email thread:
> >
> > On Sat, Apr 14, 2012 at 01:53:22AM +0300, Felipe Contreras wrote:
> >> v3.3.x on the other hand are *not* stable. They contain patches
> >> backported from v3.4, but nobody guarantees they will work. There was
> >> no v3.3.1-rc1, so the first time the patches compromising v3.3.1 were
> >> generally tested together is in v3.3.1, at which point if somebody
> >> finds issues, it's too late; bad patches are *not* going to be removed
> >> in v3.3.2.
> >
> > Of course there was a 3.3.1-rc1, see the linux-kernel archives for the
> > announcemen and the individual patches. �kernel.org has the large patch
> > itself if you like that format instead.
> 
> I don't see it here:
> http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=tags
> 
> If you really want people to try it, why not tag it?

That would be because I don't keep it in that tree.  It is in a quilt
tree you can find in the stable-queue.git repo, and I have never tagged
-rc1 releases there.  No one has ever asked for it before, so in the
past 6 years of stable releases, I guess no one ever needed it.

ketchup and tarballs seem to work well for others, perhaps you can use
that as well (hint, ketchup on top of the linux-stable tree works just
fine for testing this.)

greg k-h

[ath9k-devel] [ 00/78] 3.3.2-stable review

[Greg KH]

On Mon, Apr 16, 2012 at 11:11:05PM +0300, Felipe Contreras wrote:
> On Mon, Apr 16, 2012 at 7:27 PM, Greg KH <gregkh@linuxfoundation.org> wrote:
> > Just one minor correction in this looney email thread:
> >
> > On Sat, Apr 14, 2012 at 01:53:22AM +0300, Felipe Contreras wrote:
> >> v3.3.x on the other hand are *not* stable. They contain patches
> >> backported from v3.4, but nobody guarantees they will work. There was
> >> no v3.3.1-rc1, so the first time the patches compromising v3.3.1 were
> >> generally tested together is in v3.3.1, at which point if somebody
> >> finds issues, it's too late; bad patches are *not* going to be removed
> >> in v3.3.2.
> >
> > Of course there was a 3.3.1-rc1, see the linux-kernel archives for the
> > announcemen and the individual patches. ?kernel.org has the large patch
> > itself if you like that format instead.
> 
> I don't see it here:
> http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=tags
> 
> If you really want people to try it, why not tag it?

That would be because I don't keep it in that tree.  It is in a quilt
tree you can find in the stable-queue.git repo, and I have never tagged
-rc1 releases there.  No one has ever asked for it before, so in the
past 6 years of stable releases, I guess no one ever needed it.

ketchup and tarballs seem to work well for others, perhaps you can use
that as well (hint, ketchup on top of the linux-stable tree works just
fine for testing this.)

greg k-h

Re: [ 00/78] 3.3.2-stable review

[Arend van Spriel]

On 04/16/2012 10:25 PM, Felipe Contreras wrote:
> Releasing implies many things. There is this notion called theory of
> mind, which children learn at a very young age, that helps us see the
> world through the eyes of other people. If you think people *must* see
> the word "release" and think *exactly* the same thing as  you do, and
> apologize when they don't, well, I'd say you are missing a very
> valuable skill.

Maybe we are all a bit autistic then.

> But fine, lets suppose I should have thought exactly the same thing as
> you did, and fine, lets say I was wrong in not doing so. That still
> doesn't help one iota in this discussion. Linus Torvalds pointed the
> exact reason, which allowed us to move forward, because of my
> incompetence, or whatever.

I think this thread has been going on long enough and a fair number of 
people tried to explain the process and why it is set up as such. How 
long do you want to rephrase and stick to your "theory of mind". Email 
filters will probably be created rather sooner than later. Does 
Contreras have the same linguistic origin as "contrary"? Sorry, could 
not think of anything constructive here.

> The next logical question has still not been answered; does the
> undroppability come from the fact that v3.4 is more important that
> v3.3.1? This time I promise to think at least one day for all the
> possible meanings of each key word you say.

3.4 is not most important, but upstream is and currently those are the 
3.4-rcN releases. Every patch has to go upstream first as it was, is, 
and will be our past, present, and future.

The only thing I can think of in favor of your arguments is that the 
name 'stable' imply that they are without issues, ie. stable. However, 
with a bit of ToM you may see that they are maintenance releases.

Gr. AvS

[ath9k-devel] [ 00/78] 3.3.2-stable review

[Arend van Spriel]

On 04/16/2012 10:25 PM, Felipe Contreras wrote:
> Releasing implies many things. There is this notion called theory of
> mind, which children learn at a very young age, that helps us see the
> world through the eyes of other people. If you think people *must* see
> the word "release" and think *exactly* the same thing as  you do, and
> apologize when they don't, well, I'd say you are missing a very
> valuable skill.

Maybe we are all a bit autistic then.

> But fine, lets suppose I should have thought exactly the same thing as
> you did, and fine, lets say I was wrong in not doing so. That still
> doesn't help one iota in this discussion. Linus Torvalds pointed the
> exact reason, which allowed us to move forward, because of my
> incompetence, or whatever.

I think this thread has been going on long enough and a fair number of 
people tried to explain the process and why it is set up as such. How 
long do you want to rephrase and stick to your "theory of mind". Email 
filters will probably be created rather sooner than later. Does 
Contreras have the same linguistic origin as "contrary"? Sorry, could 
not think of anything constructive here.

> The next logical question has still not been answered; does the
> undroppability come from the fact that v3.4 is more important that
> v3.3.1? This time I promise to think at least one day for all the
> possible meanings of each key word you say.

3.4 is not most important, but upstream is and currently those are the 
3.4-rcN releases. Every patch has to go upstream first as it was, is, 
and will be our past, present, and future.

The only thing I can think of in favor of your arguments is that the 
name 'stable' imply that they are without issues, ie. stable. However, 
with a bit of ToM you may see that they are maintenance releases.

Gr. AvS

Re: [ath9k-devel] [ 00/78] 3.3.2-stable review

[Felipe Contreras]

On Mon, Apr 16, 2012 at 11:58 PM, Greg KH <gregkh@linuxfoundation.org> wrote:
> On Mon, Apr 16, 2012 at 11:11:05PM +0300, Felipe Contreras wrote:
>> On Mon, Apr 16, 2012 at 7:27 PM, Greg KH <gregkh@linuxfoundation.org> wrote:
>> > Just one minor correction in this looney email thread:
>> >
>> > On Sat, Apr 14, 2012 at 01:53:22AM +0300, Felipe Contreras wrote:
>> >> v3.3.x on the other hand are *not* stable. They contain patches
>> >> backported from v3.4, but nobody guarantees they will work. There was
>> >> no v3.3.1-rc1, so the first time the patches compromising v3.3.1 were
>> >> generally tested together is in v3.3.1, at which point if somebody
>> >> finds issues, it's too late; bad patches are *not* going to be removed
>> >> in v3.3.2.
>> >
>> > Of course there was a 3.3.1-rc1, see the linux-kernel archives for the
>> > announcemen and the individual patches.  kernel.org has the large patch
>> > itself if you like that format instead.
>>
>> I don't see it here:
>> http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=tags
>>
>> If you really want people to try it, why not tag it?
>
> That would be because I don't keep it in that tree.  It is in a quilt
> tree you can find in the stable-queue.git repo, and I have never tagged
> -rc1 releases there.  No one has ever asked for it before, so in the
> past 6 years of stable releases, I guess no one ever needed it.
>
> ketchup and tarballs seem to work well for others, perhaps you can use
> that as well (hint, ketchup on top of the linux-stable tree works just
> fine for testing this.)

Perhaps the current process will be continue to be OK, but I do
believe a tagged v3.3.1-rc1 would have catched the ath9k issue.
Hopefully that would mean it could have been dropped/reverted for
v3.3.1.

I used to compile my own kernels and use your stable tree, but this a
new laptop and I was using Arch Linux which automatically updated to
v3.3.1, and with no network I had no way to revert to v3.2.x.
Fortunately I had the kernel sources available, but I wonder how many
people were completely stuck.

If some other 3.x.1 release get broken this way, I would seriously
consider tagging v3.x.1-rc1 as well. It works for Linus' tree.

Cheers.

-- 
Felipe Contreras

[ath9k-devel] [ 00/78] 3.3.2-stable review

[Felipe Contreras]

On Mon, Apr 16, 2012 at 11:58 PM, Greg KH <gregkh@linuxfoundation.org> wrote:
> On Mon, Apr 16, 2012 at 11:11:05PM +0300, Felipe Contreras wrote:
>> On Mon, Apr 16, 2012 at 7:27 PM, Greg KH <gregkh@linuxfoundation.org> wrote:
>> > Just one minor correction in this looney email thread:
>> >
>> > On Sat, Apr 14, 2012 at 01:53:22AM +0300, Felipe Contreras wrote:
>> >> v3.3.x on the other hand are *not* stable. They contain patches
>> >> backported from v3.4, but nobody guarantees they will work. There was
>> >> no v3.3.1-rc1, so the first time the patches compromising v3.3.1 were
>> >> generally tested together is in v3.3.1, at which point if somebody
>> >> finds issues, it's too late; bad patches are *not* going to be removed
>> >> in v3.3.2.
>> >
>> > Of course there was a 3.3.1-rc1, see the linux-kernel archives for the
>> > announcemen and the individual patches. ?kernel.org has the large patch
>> > itself if you like that format instead.
>>
>> I don't see it here:
>> http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=tags
>>
>> If you really want people to try it, why not tag it?
>
> That would be because I don't keep it in that tree. ?It is in a quilt
> tree you can find in the stable-queue.git repo, and I have never tagged
> -rc1 releases there. ?No one has ever asked for it before, so in the
> past 6 years of stable releases, I guess no one ever needed it.
>
> ketchup and tarballs seem to work well for others, perhaps you can use
> that as well (hint, ketchup on top of the linux-stable tree works just
> fine for testing this.)

Perhaps the current process will be continue to be OK, but I do
believe a tagged v3.3.1-rc1 would have catched the ath9k issue.
Hopefully that would mean it could have been dropped/reverted for
v3.3.1.

I used to compile my own kernels and use your stable tree, but this a
new laptop and I was using Arch Linux which automatically updated to
v3.3.1, and with no network I had no way to revert to v3.2.x.
Fortunately I had the kernel sources available, but I wonder how many
people were completely stuck.

If some other 3.x.1 release get broken this way, I would seriously
consider tagging v3.x.1-rc1 as well. It works for Linus' tree.

Cheers.

-- 
Felipe Contreras

Re: [ath9k-devel] [ 00/78] 3.3.2-stable review

[Greg KH]

On Tue, Apr 17, 2012 at 12:18:13AM +0300, Felipe Contreras wrote:
> On Mon, Apr 16, 2012 at 11:58 PM, Greg KH <gregkh@linuxfoundation.org> wrote:
> > On Mon, Apr 16, 2012 at 11:11:05PM +0300, Felipe Contreras wrote:
> >> On Mon, Apr 16, 2012 at 7:27 PM, Greg KH <gregkh@linuxfoundation.org> wrote:
> >> > Just one minor correction in this looney email thread:
> >> >
> >> > On Sat, Apr 14, 2012 at 01:53:22AM +0300, Felipe Contreras wrote:
> >> >> v3.3.x on the other hand are *not* stable. They contain patches
> >> >> backported from v3.4, but nobody guarantees they will work. There was
> >> >> no v3.3.1-rc1, so the first time the patches compromising v3.3.1 were
> >> >> generally tested together is in v3.3.1, at which point if somebody
> >> >> finds issues, it's too late; bad patches are *not* going to be removed
> >> >> in v3.3.2.
> >> >
> >> > Of course there was a 3.3.1-rc1, see the linux-kernel archives for the
> >> > announcemen and the individual patches.  kernel.org has the large patch
> >> > itself if you like that format instead.
> >>
> >> I don't see it here:
> >> http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=tags
> >>
> >> If you really want people to try it, why not tag it?
> >
> > That would be because I don't keep it in that tree.  It is in a quilt
> > tree you can find in the stable-queue.git repo, and I have never tagged
> > -rc1 releases there.  No one has ever asked for it before, so in the
> > past 6 years of stable releases, I guess no one ever needed it.
> >
> > ketchup and tarballs seem to work well for others, perhaps you can use
> > that as well (hint, ketchup on top of the linux-stable tree works just
> > fine for testing this.)
> 
> Perhaps the current process will be continue to be OK, but I do
> believe a tagged v3.3.1-rc1 would have catched the ath9k issue.

How exactly would that have helped here?

You point out:

> I used to compile my own kernels and use your stable tree, but this a
> new laptop and I was using Arch Linux which automatically updated to
> v3.3.1, and with no network I had no way to revert to v3.2.x.
> Fortunately I had the kernel sources available, but I wonder how many
> people were completely stuck.

Arch wouldn't have included a -rc in their kernel (unless they are
crazy), so this would not have helped your situation at all.

So, no, sorry, I'm not going to put -rc kernels in the linux-stable git
tree, they don't fit with our current development flow at this point in
time.

Again, if you want to, you can use ketchup and linux-stable together
quite easily, if you wish to help us with testing.

> If some other 3.x.1 release get broken this way, I would seriously
> consider tagging v3.x.1-rc1 as well. It works for Linus' tree.

"this way" was for a very tiny subset of hardware, so odds are, if this
happens again, it wouldn't be caught this way either.  That subset just
happened to show up in your machine, but, for example, not in the wide
range of hardware I test with here, nor the machines that others test
with.

This thread has gone on long enough, this is it from me, sorry.

greg k-h

Re: [ath9k-devel] [ 00/78] 3.3.2-stable review

[Greg KH]

On Tue, Apr 17, 2012 at 12:18:13AM +0300, Felipe Contreras wrote:
> On Mon, Apr 16, 2012 at 11:58 PM, Greg KH <gregkh@linuxfoundation.org> wrote:
> > On Mon, Apr 16, 2012 at 11:11:05PM +0300, Felipe Contreras wrote:
> >> On Mon, Apr 16, 2012 at 7:27 PM, Greg KH <gregkh@linuxfoundation.org> wrote:
> >> > Just one minor correction in this looney email thread:
> >> >
> >> > On Sat, Apr 14, 2012 at 01:53:22AM +0300, Felipe Contreras wrote:
> >> >> v3.3.x on the other hand are *not* stable. They contain patches
> >> >> backported from v3.4, but nobody guarantees they will work. There was
> >> >> no v3.3.1-rc1, so the first time the patches compromising v3.3.1 were
> >> >> generally tested together is in v3.3.1, at which point if somebody
> >> >> finds issues, it's too late; bad patches are *not* going to be removed
> >> >> in v3.3.2.
> >> >
> >> > Of course there was a 3.3.1-rc1, see the linux-kernel archives for the
> >> > announcemen and the individual patches. �kernel.org has the large patch
> >> > itself if you like that format instead.
> >>
> >> I don't see it here:
> >> http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=tags
> >>
> >> If you really want people to try it, why not tag it?
> >
> > That would be because I don't keep it in that tree. �It is in a quilt
> > tree you can find in the stable-queue.git repo, and I have never tagged
> > -rc1 releases there. �No one has ever asked for it before, so in the
> > past 6 years of stable releases, I guess no one ever needed it.
> >
> > ketchup and tarballs seem to work well for others, perhaps you can use
> > that as well (hint, ketchup on top of the linux-stable tree works just
> > fine for testing this.)
> 
> Perhaps the current process will be continue to be OK, but I do
> believe a tagged v3.3.1-rc1 would have catched the ath9k issue.

How exactly would that have helped here?

You point out:

> I used to compile my own kernels and use your stable tree, but this a
> new laptop and I was using Arch Linux which automatically updated to
> v3.3.1, and with no network I had no way to revert to v3.2.x.
> Fortunately I had the kernel sources available, but I wonder how many
> people were completely stuck.

Arch wouldn't have included a -rc in their kernel (unless they are
crazy), so this would not have helped your situation at all.

So, no, sorry, I'm not going to put -rc kernels in the linux-stable git
tree, they don't fit with our current development flow at this point in
time.

Again, if you want to, you can use ketchup and linux-stable together
quite easily, if you wish to help us with testing.

> If some other 3.x.1 release get broken this way, I would seriously
> consider tagging v3.x.1-rc1 as well. It works for Linus' tree.

"this way" was for a very tiny subset of hardware, so odds are, if this
happens again, it wouldn't be caught this way either.  That subset just
happened to show up in your machine, but, for example, not in the wide
range of hardware I test with here, nor the machines that others test
with.

This thread has gone on long enough, this is it from me, sorry.

greg k-h

[ath9k-devel] [ 00/78] 3.3.2-stable review

[Greg KH]

On Tue, Apr 17, 2012 at 12:18:13AM +0300, Felipe Contreras wrote:
> On Mon, Apr 16, 2012 at 11:58 PM, Greg KH <gregkh@linuxfoundation.org> wrote:
> > On Mon, Apr 16, 2012 at 11:11:05PM +0300, Felipe Contreras wrote:
> >> On Mon, Apr 16, 2012 at 7:27 PM, Greg KH <gregkh@linuxfoundation.org> wrote:
> >> > Just one minor correction in this looney email thread:
> >> >
> >> > On Sat, Apr 14, 2012 at 01:53:22AM +0300, Felipe Contreras wrote:
> >> >> v3.3.x on the other hand are *not* stable. They contain patches
> >> >> backported from v3.4, but nobody guarantees they will work. There was
> >> >> no v3.3.1-rc1, so the first time the patches compromising v3.3.1 were
> >> >> generally tested together is in v3.3.1, at which point if somebody
> >> >> finds issues, it's too late; bad patches are *not* going to be removed
> >> >> in v3.3.2.
> >> >
> >> > Of course there was a 3.3.1-rc1, see the linux-kernel archives for the
> >> > announcemen and the individual patches. ?kernel.org has the large patch
> >> > itself if you like that format instead.
> >>
> >> I don't see it here:
> >> http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=tags
> >>
> >> If you really want people to try it, why not tag it?
> >
> > That would be because I don't keep it in that tree. ?It is in a quilt
> > tree you can find in the stable-queue.git repo, and I have never tagged
> > -rc1 releases there. ?No one has ever asked for it before, so in the
> > past 6 years of stable releases, I guess no one ever needed it.
> >
> > ketchup and tarballs seem to work well for others, perhaps you can use
> > that as well (hint, ketchup on top of the linux-stable tree works just
> > fine for testing this.)
> 
> Perhaps the current process will be continue to be OK, but I do
> believe a tagged v3.3.1-rc1 would have catched the ath9k issue.

How exactly would that have helped here?

You point out:

> I used to compile my own kernels and use your stable tree, but this a
> new laptop and I was using Arch Linux which automatically updated to
> v3.3.1, and with no network I had no way to revert to v3.2.x.
> Fortunately I had the kernel sources available, but I wonder how many
> people were completely stuck.

Arch wouldn't have included a -rc in their kernel (unless they are
crazy), so this would not have helped your situation at all.

So, no, sorry, I'm not going to put -rc kernels in the linux-stable git
tree, they don't fit with our current development flow at this point in
time.

Again, if you want to, you can use ketchup and linux-stable together
quite easily, if you wish to help us with testing.

> If some other 3.x.1 release get broken this way, I would seriously
> consider tagging v3.x.1-rc1 as well. It works for Linus' tree.

"this way" was for a very tiny subset of hardware, so odds are, if this
happens again, it wouldn't be caught this way either.  That subset just
happened to show up in your machine, but, for example, not in the wide
range of hardware I test with here, nor the machines that others test
with.

This thread has gone on long enough, this is it from me, sorry.

greg k-h

Re: [ath9k-devel] [ 00/78] 3.3.2-stable review

[Don deJuan]

On 04/16/2012 02:18 PM, Felipe Contreras wrote:
> On Mon, Apr 16, 2012 at 11:58 PM, Greg KH<gregkh@linuxfoundation.org>  wrote:
>> On Mon, Apr 16, 2012 at 11:11:05PM +0300, Felipe Contreras wrote:
>>> On Mon, Apr 16, 2012 at 7:27 PM, Greg KH<gregkh@linuxfoundation.org>  wrote:
>>>> Just one minor correction in this looney email thread:
>>>>
>>>> On Sat, Apr 14, 2012 at 01:53:22AM +0300, Felipe Contreras wrote:
>>>>> v3.3.x on the other hand are *not* stable. They contain patches
>>>>> backported from v3.4, but nobody guarantees they will work. There was
>>>>> no v3.3.1-rc1, so the first time the patches compromising v3.3.1 were
>>>>> generally tested together is in v3.3.1, at which point if somebody
>>>>> finds issues, it's too late; bad patches are *not* going to be removed
>>>>> in v3.3.2.
>>>>
>>>> Of course there was a 3.3.1-rc1, see the linux-kernel archives for the
>>>> announcemen and the individual patches.  kernel.org has the large patch
>>>> itself if you like that format instead.
>>>
>>> I don't see it here:
>>> http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=tags
>>>
>>> If you really want people to try it, why not tag it?
>>
>> That would be because I don't keep it in that tree.  It is in a quilt
>> tree you can find in the stable-queue.git repo, and I have never tagged
>> -rc1 releases there.  No one has ever asked for it before, so in the
>> past 6 years of stable releases, I guess no one ever needed it.
>>
>> ketchup and tarballs seem to work well for others, perhaps you can use
>> that as well (hint, ketchup on top of the linux-stable tree works just
>> fine for testing this.)
>
> Perhaps the current process will be continue to be OK, but I do
> believe a tagged v3.3.1-rc1 would have catched the ath9k issue.
> Hopefully that would mean it could have been dropped/reverted for
> v3.3.1.
>
> I used to compile my own kernels and use your stable tree, but this a
> new laptop and I was using Arch Linux which automatically updated to
> v3.3.1, and with no network I had no way to revert to v3.2.x.

For an Arch user I am shocked you are able to keep things going on your 
setup. Why are you not spending this much effort complaining to Arch 
Dev's for not properly testing 3.3.1 before pushing it. I know they did 
not put it into testing and was just put through the mailing list for 
people to test, with only a few ack's showing up on the list, before 
pushing about a day later.

Also how did you not have something to roll back to? Why was there not a 
package left in your /var/cache/pacman/pkg cache? Unless you clean out 
your cache way to often you should have more than one kernel you could 
have "rolled back" with a simple pacman -U linux-version-that-last-worked.

This much effort and bitching on your part to people who had nothing to 
do with you getting a bad push from Arch, Arch should have done further 
testing of it OR you should have waited a day before updating to see if 
anything on your shiny new laptop would have been effected.

> Fortunately I had the kernel sources available, but I wonder how many
> people were completely stuck.

On arch no one should have been stuck if they would have read the wiki's 
and been more aware of their systems. Stable or not you are living on 
the bleeding edge or as close to it as possible when on Arch, read their 
philosophy and methods and their wiki. Then if you have issues with 
something Arch pushes to you, would it not be better to spend your 
efforts on the distro you are running?

>
> If some other 3.x.1 release get broken this way, I would seriously
> consider tagging v3.x.1-rc1 as well. It works for Linus' tree.
>
> Cheers.
>


Just my .02 from someone not involved in any of this who is just fed up 
with you twisting crap around to fit your gripes with something that is 
not related to the trees or methods at hand. YOU got a package from YOUR 
distro of choice and because YOU were not aware of things when updating 
your distro YOU broke it. Not Linus or Greg, but Arch and you not 
understanding the kernel did NOT go through the normal testing repo. I 
have a system that would have broke in the same manner as yours, running 
Arch, but because I am aware I have a few things that are getting lots 
of work in the kernel, I need to be aware of the updates, especially 
kernel's just being tested through the mailing list. Also why did you 
not have at least the LTS as a backup on your Arch install, if you are 
clearing out your cache so frequently to not have at least one version 
to "roll back"?
Learn your hardware and how it interacts with the distro you choose and 
you can better help yourself and ALL these efforts would not just end up 
making you seem like a ranting loon!

[ath9k-devel] [ 00/78] 3.3.2-stable review

[Don deJuan]

On 04/16/2012 02:18 PM, Felipe Contreras wrote:
> On Mon, Apr 16, 2012 at 11:58 PM, Greg KH<gregkh@linuxfoundation.org>  wrote:
>> On Mon, Apr 16, 2012 at 11:11:05PM +0300, Felipe Contreras wrote:
>>> On Mon, Apr 16, 2012 at 7:27 PM, Greg KH<gregkh@linuxfoundation.org>  wrote:
>>>> Just one minor correction in this looney email thread:
>>>>
>>>> On Sat, Apr 14, 2012 at 01:53:22AM +0300, Felipe Contreras wrote:
>>>>> v3.3.x on the other hand are *not* stable. They contain patches
>>>>> backported from v3.4, but nobody guarantees they will work. There was
>>>>> no v3.3.1-rc1, so the first time the patches compromising v3.3.1 were
>>>>> generally tested together is in v3.3.1, at which point if somebody
>>>>> finds issues, it's too late; bad patches are *not* going to be removed
>>>>> in v3.3.2.
>>>>
>>>> Of course there was a 3.3.1-rc1, see the linux-kernel archives for the
>>>> announcemen and the individual patches.  kernel.org has the large patch
>>>> itself if you like that format instead.
>>>
>>> I don't see it here:
>>> http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=tags
>>>
>>> If you really want people to try it, why not tag it?
>>
>> That would be because I don't keep it in that tree.  It is in a quilt
>> tree you can find in the stable-queue.git repo, and I have never tagged
>> -rc1 releases there.  No one has ever asked for it before, so in the
>> past 6 years of stable releases, I guess no one ever needed it.
>>
>> ketchup and tarballs seem to work well for others, perhaps you can use
>> that as well (hint, ketchup on top of the linux-stable tree works just
>> fine for testing this.)
>
> Perhaps the current process will be continue to be OK, but I do
> believe a tagged v3.3.1-rc1 would have catched the ath9k issue.
> Hopefully that would mean it could have been dropped/reverted for
> v3.3.1.
>
> I used to compile my own kernels and use your stable tree, but this a
> new laptop and I was using Arch Linux which automatically updated to
> v3.3.1, and with no network I had no way to revert to v3.2.x.

For an Arch user I am shocked you are able to keep things going on your 
setup. Why are you not spending this much effort complaining to Arch 
Dev's for not properly testing 3.3.1 before pushing it. I know they did 
not put it into testing and was just put through the mailing list for 
people to test, with only a few ack's showing up on the list, before 
pushing about a day later.

Also how did you not have something to roll back to? Why was there not a 
package left in your /var/cache/pacman/pkg cache? Unless you clean out 
your cache way to often you should have more than one kernel you could 
have "rolled back" with a simple pacman -U linux-version-that-last-worked.

This much effort and bitching on your part to people who had nothing to 
do with you getting a bad push from Arch, Arch should have done further 
testing of it OR you should have waited a day before updating to see if 
anything on your shiny new laptop would have been effected.

> Fortunately I had the kernel sources available, but I wonder how many
> people were completely stuck.

On arch no one should have been stuck if they would have read the wiki's 
and been more aware of their systems. Stable or not you are living on 
the bleeding edge or as close to it as possible when on Arch, read their 
philosophy and methods and their wiki. Then if you have issues with 
something Arch pushes to you, would it not be better to spend your 
efforts on the distro you are running?

>
> If some other 3.x.1 release get broken this way, I would seriously
> consider tagging v3.x.1-rc1 as well. It works for Linus' tree.
>
> Cheers.
>


Just my .02 from someone not involved in any of this who is just fed up 
with you twisting crap around to fit your gripes with something that is 
not related to the trees or methods at hand. YOU got a package from YOUR 
distro of choice and because YOU were not aware of things when updating 
your distro YOU broke it. Not Linus or Greg, but Arch and you not 
understanding the kernel did NOT go through the normal testing repo. I 
have a system that would have broke in the same manner as yours, running 
Arch, but because I am aware I have a few things that are getting lots 
of work in the kernel, I need to be aware of the updates, especially 
kernel's just being tested through the mailing list. Also why did you 
not have at least the LTS as a backup on your Arch install, if you are 
clearing out your cache so frequently to not have at least one version 
to "roll back"?
Learn your hardware and how it interacts with the distro you choose and 
you can better help yourself and ALL these efforts would not just end up 
making you seem like a ranting loon!

Re: [ath9k-devel] [ 00/78] 3.3.2-stable review

[Felipe Contreras]

On Tue, Apr 17, 2012 at 12:27 AM, Greg KH <gregkh@linuxfoundation.org> wrote:
> On Tue, Apr 17, 2012 at 12:18:13AM +0300, Felipe Contreras wrote:
>> On Mon, Apr 16, 2012 at 11:58 PM, Greg KH <gregkh@linuxfoundation.org> wrote:
>> > On Mon, Apr 16, 2012 at 11:11:05PM +0300, Felipe Contreras wrote:
>> >> On Mon, Apr 16, 2012 at 7:27 PM, Greg KH <gregkh@linuxfoundation.org> wrote:
>> >> > Just one minor correction in this looney email thread:
>> >> >
>> >> > On Sat, Apr 14, 2012 at 01:53:22AM +0300, Felipe Contreras wrote:
>> >> >> v3.3.x on the other hand are *not* stable. They contain patches
>> >> >> backported from v3.4, but nobody guarantees they will work. There was
>> >> >> no v3.3.1-rc1, so the first time the patches compromising v3.3.1 were
>> >> >> generally tested together is in v3.3.1, at which point if somebody
>> >> >> finds issues, it's too late; bad patches are *not* going to be removed
>> >> >> in v3.3.2.
>> >> >
>> >> > Of course there was a 3.3.1-rc1, see the linux-kernel archives for the
>> >> > announcemen and the individual patches.  kernel.org has the large patch
>> >> > itself if you like that format instead.
>> >>
>> >> I don't see it here:
>> >> http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=tags
>> >>
>> >> If you really want people to try it, why not tag it?
>> >
>> > That would be because I don't keep it in that tree.  It is in a quilt
>> > tree you can find in the stable-queue.git repo, and I have never tagged
>> > -rc1 releases there.  No one has ever asked for it before, so in the
>> > past 6 years of stable releases, I guess no one ever needed it.
>> >
>> > ketchup and tarballs seem to work well for others, perhaps you can use
>> > that as well (hint, ketchup on top of the linux-stable tree works just
>> > fine for testing this.)
>>
>> Perhaps the current process will be continue to be OK, but I do
>> believe a tagged v3.3.1-rc1 would have catched the ath9k issue.
>
> How exactly would that have helped here?

More people would have given it a try. Not that many people read the
mailing list, and the ones that do certainly might want to avoid
applying a big series of patches; even if their mail client makes it
easy (mine (Gmail) doesn't). A tag, and an announcement to give a try
would make it *much* easier.

> You point out:
>
>> I used to compile my own kernels and use your stable tree, but this a
>> new laptop and I was using Arch Linux which automatically updated to
>> v3.3.1, and with no network I had no way to revert to v3.2.x.
>> Fortunately I had the kernel sources available, but I wonder how many
>> people were completely stuck.
>
> Arch wouldn't have included a -rc in their kernel (unless they are
> crazy), so this would not have helped your situation at all.

There's *a lot* of people that got affected by the 3.3.1 release; we
don't need to break a lot of boxes to figure out there's an issue,
only a few would suffice, even one.

>> If some other 3.x.1 release get broken this way, I would seriously
>> consider tagging v3.x.1-rc1 as well. It works for Linus' tree.
>
> "this way" was for a very tiny subset of hardware, so odds are, if this
> happens again, it wouldn't be caught this way either.  That subset just
> happened to show up in your machine, but, for example, not in the wide
> range of hardware I test with here, nor the machines that others test
> with.

It was certainly not just me. I have seen a lot of people mentioning
"their wifi is broken", a lot of them using Arch Linux,
coincidentally.

These issues would most likely not be caught before v3.x.1, and which
point it's too late, they cannot be reverted to v3.x.2 just like that;
they have to wait for upstream. Hopefully and probably everything
would go smooth like this time, but maybe not, we'll have to wait and
see. With more people using Arch Linux and thus the latest "stable"
release, I'd say we might see an increase in these kinds of issues.

Cheers.

-- 
Felipe Contreras

[ath9k-devel] [ 00/78] 3.3.2-stable review

[Felipe Contreras]

On Tue, Apr 17, 2012 at 12:27 AM, Greg KH <gregkh@linuxfoundation.org> wrote:
> On Tue, Apr 17, 2012 at 12:18:13AM +0300, Felipe Contreras wrote:
>> On Mon, Apr 16, 2012 at 11:58 PM, Greg KH <gregkh@linuxfoundation.org> wrote:
>> > On Mon, Apr 16, 2012 at 11:11:05PM +0300, Felipe Contreras wrote:
>> >> On Mon, Apr 16, 2012 at 7:27 PM, Greg KH <gregkh@linuxfoundation.org> wrote:
>> >> > Just one minor correction in this looney email thread:
>> >> >
>> >> > On Sat, Apr 14, 2012 at 01:53:22AM +0300, Felipe Contreras wrote:
>> >> >> v3.3.x on the other hand are *not* stable. They contain patches
>> >> >> backported from v3.4, but nobody guarantees they will work. There was
>> >> >> no v3.3.1-rc1, so the first time the patches compromising v3.3.1 were
>> >> >> generally tested together is in v3.3.1, at which point if somebody
>> >> >> finds issues, it's too late; bad patches are *not* going to be removed
>> >> >> in v3.3.2.
>> >> >
>> >> > Of course there was a 3.3.1-rc1, see the linux-kernel archives for the
>> >> > announcemen and the individual patches. ?kernel.org has the large patch
>> >> > itself if you like that format instead.
>> >>
>> >> I don't see it here:
>> >> http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=tags
>> >>
>> >> If you really want people to try it, why not tag it?
>> >
>> > That would be because I don't keep it in that tree. ?It is in a quilt
>> > tree you can find in the stable-queue.git repo, and I have never tagged
>> > -rc1 releases there. ?No one has ever asked for it before, so in the
>> > past 6 years of stable releases, I guess no one ever needed it.
>> >
>> > ketchup and tarballs seem to work well for others, perhaps you can use
>> > that as well (hint, ketchup on top of the linux-stable tree works just
>> > fine for testing this.)
>>
>> Perhaps the current process will be continue to be OK, but I do
>> believe a tagged v3.3.1-rc1 would have catched the ath9k issue.
>
> How exactly would that have helped here?

More people would have given it a try. Not that many people read the
mailing list, and the ones that do certainly might want to avoid
applying a big series of patches; even if their mail client makes it
easy (mine (Gmail) doesn't). A tag, and an announcement to give a try
would make it *much* easier.

> You point out:
>
>> I used to compile my own kernels and use your stable tree, but this a
>> new laptop and I was using Arch Linux which automatically updated to
>> v3.3.1, and with no network I had no way to revert to v3.2.x.
>> Fortunately I had the kernel sources available, but I wonder how many
>> people were completely stuck.
>
> Arch wouldn't have included a -rc in their kernel (unless they are
> crazy), so this would not have helped your situation at all.

There's *a lot* of people that got affected by the 3.3.1 release; we
don't need to break a lot of boxes to figure out there's an issue,
only a few would suffice, even one.

>> If some other 3.x.1 release get broken this way, I would seriously
>> consider tagging v3.x.1-rc1 as well. It works for Linus' tree.
>
> "this way" was for a very tiny subset of hardware, so odds are, if this
> happens again, it wouldn't be caught this way either. ?That subset just
> happened to show up in your machine, but, for example, not in the wide
> range of hardware I test with here, nor the machines that others test
> with.

It was certainly not just me. I have seen a lot of people mentioning
"their wifi is broken", a lot of them using Arch Linux,
coincidentally.

These issues would most likely not be caught before v3.x.1, and which
point it's too late, they cannot be reverted to v3.x.2 just like that;
they have to wait for upstream. Hopefully and probably everything
would go smooth like this time, but maybe not, we'll have to wait and
see. With more people using Arch Linux and thus the latest "stable"
release, I'd say we might see an increase in these kinds of issues.

Cheers.

-- 
Felipe Contreras

Re: [ath9k-devel] [ 00/78] 3.3.2-stable review

[Felipe Contreras]

On Tue, Apr 17, 2012 at 12:27 AM, Greg KH <gregkh@linuxfoundation.org> wrote:
> On Tue, Apr 17, 2012 at 12:18:13AM +0300, Felipe Contreras wrote:
>> On Mon, Apr 16, 2012 at 11:58 PM, Greg KH <gregkh@linuxfoundation.org> wrote:
>> > On Mon, Apr 16, 2012 at 11:11:05PM +0300, Felipe Contreras wrote:
>> >> On Mon, Apr 16, 2012 at 7:27 PM, Greg KH <gregkh@linuxfoundation.org> wrote:
>> >> > Just one minor correction in this looney email thread:
>> >> >
>> >> > On Sat, Apr 14, 2012 at 01:53:22AM +0300, Felipe Contreras wrote:
>> >> >> v3.3.x on the other hand are *not* stable. They contain patches
>> >> >> backported from v3.4, but nobody guarantees they will work. There was
>> >> >> no v3.3.1-rc1, so the first time the patches compromising v3.3.1 were
>> >> >> generally tested together is in v3.3.1, at which point if somebody
>> >> >> finds issues, it's too late; bad patches are *not* going to be removed
>> >> >> in v3.3.2.
>> >> >
>> >> > Of course there was a 3.3.1-rc1, see the linux-kernel archives for the
>> >> > announcemen and the individual patches.  kernel.org has the large patch
>> >> > itself if you like that format instead.
>> >>
>> >> I don't see it here:
>> >> http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=tags
>> >>
>> >> If you really want people to try it, why not tag it?
>> >
>> > That would be because I don't keep it in that tree.  It is in a quilt
>> > tree you can find in the stable-queue.git repo, and I have never tagged
>> > -rc1 releases there.  No one has ever asked for it before, so in the
>> > past 6 years of stable releases, I guess no one ever needed it.
>> >
>> > ketchup and tarballs seem to work well for others, perhaps you can use
>> > that as well (hint, ketchup on top of the linux-stable tree works just
>> > fine for testing this.)
>>
>> Perhaps the current process will be continue to be OK, but I do
>> believe a tagged v3.3.1-rc1 would have catched the ath9k issue.
>
> How exactly would that have helped here?

More people would have given it a try. Not that many people read the
mailing list, and the ones that do certainly might want to avoid
applying a big series of patches; even if their mail client makes it
easy (mine (Gmail) doesn't). A tag, and an announcement to give a try
would make it *much* easier.

> You point out:
>
>> I used to compile my own kernels and use your stable tree, but this a
>> new laptop and I was using Arch Linux which automatically updated to
>> v3.3.1, and with no network I had no way to revert to v3.2.x.
>> Fortunately I had the kernel sources available, but I wonder how many
>> people were completely stuck.
>
> Arch wouldn't have included a -rc in their kernel (unless they are
> crazy), so this would not have helped your situation at all.

There's *a lot* of people that got affected by the 3.3.1 release; we
don't need to break a lot of boxes to figure out there's an issue,
only a few would suffice, even one.

>> If some other 3.x.1 release get broken this way, I would seriously
>> consider tagging v3.x.1-rc1 as well. It works for Linus' tree.
>
> "this way" was for a very tiny subset of hardware, so odds are, if this
> happens again, it wouldn't be caught this way either.  That subset just
> happened to show up in your machine, but, for example, not in the wide
> range of hardware I test with here, nor the machines that others test
> with.

It was certainly not just me. I have seen a lot of people mentioning
"their wifi is broken", a lot of them using Arch Linux,
coincidentally.

These issues would most likely not be caught before v3.x.1, and which
point it's too late, they cannot be reverted to v3.x.2 just like that;
they have to wait for upstream. Hopefully and probably everything
would go smooth like this time, but maybe not, we'll have to wait and
see. With more people using Arch Linux and thus the latest "stable"
release, I'd say we might see an increase in these kinds of issues.

Cheers.

-- 
Felipe Contreras

[ath9k-devel] [ 00/78] 3.3.2-stable review

[Felipe Contreras]

On Tue, Apr 17, 2012 at 12:27 AM, Greg KH <gregkh@linuxfoundation.org> wrote:
> On Tue, Apr 17, 2012 at 12:18:13AM +0300, Felipe Contreras wrote:
>> On Mon, Apr 16, 2012 at 11:58 PM, Greg KH <gregkh@linuxfoundation.org> wrote:
>> > On Mon, Apr 16, 2012 at 11:11:05PM +0300, Felipe Contreras wrote:
>> >> On Mon, Apr 16, 2012 at 7:27 PM, Greg KH <gregkh@linuxfoundation.org> wrote:
>> >> > Just one minor correction in this looney email thread:
>> >> >
>> >> > On Sat, Apr 14, 2012 at 01:53:22AM +0300, Felipe Contreras wrote:
>> >> >> v3.3.x on the other hand are *not* stable. They contain patches
>> >> >> backported from v3.4, but nobody guarantees they will work. There was
>> >> >> no v3.3.1-rc1, so the first time the patches compromising v3.3.1 were
>> >> >> generally tested together is in v3.3.1, at which point if somebody
>> >> >> finds issues, it's too late; bad patches are *not* going to be removed
>> >> >> in v3.3.2.
>> >> >
>> >> > Of course there was a 3.3.1-rc1, see the linux-kernel archives for the
>> >> > announcemen and the individual patches. ?kernel.org has the large patch
>> >> > itself if you like that format instead.
>> >>
>> >> I don't see it here:
>> >> http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=tags
>> >>
>> >> If you really want people to try it, why not tag it?
>> >
>> > That would be because I don't keep it in that tree. ?It is in a quilt
>> > tree you can find in the stable-queue.git repo, and I have never tagged
>> > -rc1 releases there. ?No one has ever asked for it before, so in the
>> > past 6 years of stable releases, I guess no one ever needed it.
>> >
>> > ketchup and tarballs seem to work well for others, perhaps you can use
>> > that as well (hint, ketchup on top of the linux-stable tree works just
>> > fine for testing this.)
>>
>> Perhaps the current process will be continue to be OK, but I do
>> believe a tagged v3.3.1-rc1 would have catched the ath9k issue.
>
> How exactly would that have helped here?

More people would have given it a try. Not that many people read the
mailing list, and the ones that do certainly might want to avoid
applying a big series of patches; even if their mail client makes it
easy (mine (Gmail) doesn't). A tag, and an announcement to give a try
would make it *much* easier.

> You point out:
>
>> I used to compile my own kernels and use your stable tree, but this a
>> new laptop and I was using Arch Linux which automatically updated to
>> v3.3.1, and with no network I had no way to revert to v3.2.x.
>> Fortunately I had the kernel sources available, but I wonder how many
>> people were completely stuck.
>
> Arch wouldn't have included a -rc in their kernel (unless they are
> crazy), so this would not have helped your situation at all.

There's *a lot* of people that got affected by the 3.3.1 release; we
don't need to break a lot of boxes to figure out there's an issue,
only a few would suffice, even one.

>> If some other 3.x.1 release get broken this way, I would seriously
>> consider tagging v3.x.1-rc1 as well. It works for Linus' tree.
>
> "this way" was for a very tiny subset of hardware, so odds are, if this
> happens again, it wouldn't be caught this way either. ?That subset just
> happened to show up in your machine, but, for example, not in the wide
> range of hardware I test with here, nor the machines that others test
> with.

It was certainly not just me. I have seen a lot of people mentioning
"their wifi is broken", a lot of them using Arch Linux,
coincidentally.

These issues would most likely not be caught before v3.x.1, and which
point it's too late, they cannot be reverted to v3.x.2 just like that;
they have to wait for upstream. Hopefully and probably everything
would go smooth like this time, but maybe not, we'll have to wait and
see. With more people using Arch Linux and thus the latest "stable"
release, I'd say we might see an increase in these kinds of issues.

Cheers.

-- 
Felipe Contreras

Re: [ath9k-devel] [ 00/78] 3.3.2-stable review

[Don deJuan]

On 04/16/2012 02:50 PM, Felipe Contreras wrote:
> On Tue, Apr 17, 2012 at 12:27 AM, Greg KH<gregkh@linuxfoundation.org>  wrote:
>> On Tue, Apr 17, 2012 at 12:18:13AM +0300, Felipe Contreras wrote:
>>> On Mon, Apr 16, 2012 at 11:58 PM, Greg KH<gregkh@linuxfoundation.org>  wrote:
>>>> On Mon, Apr 16, 2012 at 11:11:05PM +0300, Felipe Contreras wrote:
>>>>> On Mon, Apr 16, 2012 at 7:27 PM, Greg KH<gregkh@linuxfoundation.org>  wrote:
>>>>>> Just one minor correction in this looney email thread:
>>>>>>
>>>>>> On Sat, Apr 14, 2012 at 01:53:22AM +0300, Felipe Contreras wrote:
>>>>>>> v3.3.x on the other hand are *not* stable. They contain patches
>>>>>>> backported from v3.4, but nobody guarantees they will work. There was
>>>>>>> no v3.3.1-rc1, so the first time the patches compromising v3.3.1 were
>>>>>>> generally tested together is in v3.3.1, at which point if somebody
>>>>>>> finds issues, it's too late; bad patches are *not* going to be removed
>>>>>>> in v3.3.2.
>>>>>>
>>>>>> Of course there was a 3.3.1-rc1, see the linux-kernel archives for the
>>>>>> announcemen and the individual patches.  kernel.org has the large patch
>>>>>> itself if you like that format instead.
>>>>>
>>>>> I don't see it here:
>>>>> http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=tags
>>>>>
>>>>> If you really want people to try it, why not tag it?
>>>>
>>>> That would be because I don't keep it in that tree.  It is in a quilt
>>>> tree you can find in the stable-queue.git repo, and I have never tagged
>>>> -rc1 releases there.  No one has ever asked for it before, so in the
>>>> past 6 years of stable releases, I guess no one ever needed it.
>>>>
>>>> ketchup and tarballs seem to work well for others, perhaps you can use
>>>> that as well (hint, ketchup on top of the linux-stable tree works just
>>>> fine for testing this.)
>>>
>>> Perhaps the current process will be continue to be OK, but I do
>>> believe a tagged v3.3.1-rc1 would have catched the ath9k issue.
>>
>> How exactly would that have helped here?
>
> More people would have given it a try. Not that many people read the
> mailing list, and the ones that do certainly might want to avoid
> applying a big series of patches; even if their mail client makes it
> easy (mine (Gmail) doesn't). A tag, and an announcement to give a try
> would make it *much* easier.
>
>> You point out:
>>
>>> I used to compile my own kernels and use your stable tree, but this a
>>> new laptop and I was using Arch Linux which automatically updated to
>>> v3.3.1, and with no network I had no way to revert to v3.2.x.
>>> Fortunately I had the kernel sources available, but I wonder how many
>>> people were completely stuck.
>>
>> Arch wouldn't have included a -rc in their kernel (unless they are
>> crazy), so this would not have helped your situation at all.
>
> There's *a lot* of people that got affected by the 3.3.1 release; we
> don't need to break a lot of boxes to figure out there's an issue,
> only a few would suffice, even one.
>
>>> If some other 3.x.1 release get broken this way, I would seriously
>>> consider tagging v3.x.1-rc1 as well. It works for Linus' tree.
>>
>> "this way" was for a very tiny subset of hardware, so odds are, if this
>> happens again, it wouldn't be caught this way either.  That subset just
>> happened to show up in your machine, but, for example, not in the wide
>> range of hardware I test with here, nor the machines that others test
>> with.
>
> It was certainly not just me. I have seen a lot of people mentioning
> "their wifi is broken", a lot of them using Arch Linux,
> coincidentally.

Because it was only "tested" through the mailing list on Arch-general. 
Like I stated your issue was related to you and not understanding Arch 
AND how that kernel was tested before being pushed to the repo's


>
> These issues would most likely not be caught before v3.x.1, and which
> point it's too late, they cannot be reverted to v3.x.2 just like that;
> they have to wait for upstream. Hopefully and probably everything
> would go smooth like this time, but maybe not, we'll have to wait and
> see. With more people using Arch Linux and thus the latest "stable"
> release, I'd say we might see an increase in these kinds of issues.
>
> Cheers.
>

Learn the distro you are using better.

[ath9k-devel] [ 00/78] 3.3.2-stable review

[Don deJuan]

On 04/16/2012 02:50 PM, Felipe Contreras wrote:
> On Tue, Apr 17, 2012 at 12:27 AM, Greg KH<gregkh@linuxfoundation.org>  wrote:
>> On Tue, Apr 17, 2012 at 12:18:13AM +0300, Felipe Contreras wrote:
>>> On Mon, Apr 16, 2012 at 11:58 PM, Greg KH<gregkh@linuxfoundation.org>  wrote:
>>>> On Mon, Apr 16, 2012 at 11:11:05PM +0300, Felipe Contreras wrote:
>>>>> On Mon, Apr 16, 2012 at 7:27 PM, Greg KH<gregkh@linuxfoundation.org>  wrote:
>>>>>> Just one minor correction in this looney email thread:
>>>>>>
>>>>>> On Sat, Apr 14, 2012 at 01:53:22AM +0300, Felipe Contreras wrote:
>>>>>>> v3.3.x on the other hand are *not* stable. They contain patches
>>>>>>> backported from v3.4, but nobody guarantees they will work. There was
>>>>>>> no v3.3.1-rc1, so the first time the patches compromising v3.3.1 were
>>>>>>> generally tested together is in v3.3.1, at which point if somebody
>>>>>>> finds issues, it's too late; bad patches are *not* going to be removed
>>>>>>> in v3.3.2.
>>>>>>
>>>>>> Of course there was a 3.3.1-rc1, see the linux-kernel archives for the
>>>>>> announcemen and the individual patches.  kernel.org has the large patch
>>>>>> itself if you like that format instead.
>>>>>
>>>>> I don't see it here:
>>>>> http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=tags
>>>>>
>>>>> If you really want people to try it, why not tag it?
>>>>
>>>> That would be because I don't keep it in that tree.  It is in a quilt
>>>> tree you can find in the stable-queue.git repo, and I have never tagged
>>>> -rc1 releases there.  No one has ever asked for it before, so in the
>>>> past 6 years of stable releases, I guess no one ever needed it.
>>>>
>>>> ketchup and tarballs seem to work well for others, perhaps you can use
>>>> that as well (hint, ketchup on top of the linux-stable tree works just
>>>> fine for testing this.)
>>>
>>> Perhaps the current process will be continue to be OK, but I do
>>> believe a tagged v3.3.1-rc1 would have catched the ath9k issue.
>>
>> How exactly would that have helped here?
>
> More people would have given it a try. Not that many people read the
> mailing list, and the ones that do certainly might want to avoid
> applying a big series of patches; even if their mail client makes it
> easy (mine (Gmail) doesn't). A tag, and an announcement to give a try
> would make it *much* easier.
>
>> You point out:
>>
>>> I used to compile my own kernels and use your stable tree, but this a
>>> new laptop and I was using Arch Linux which automatically updated to
>>> v3.3.1, and with no network I had no way to revert to v3.2.x.
>>> Fortunately I had the kernel sources available, but I wonder how many
>>> people were completely stuck.
>>
>> Arch wouldn't have included a -rc in their kernel (unless they are
>> crazy), so this would not have helped your situation at all.
>
> There's *a lot* of people that got affected by the 3.3.1 release; we
> don't need to break a lot of boxes to figure out there's an issue,
> only a few would suffice, even one.
>
>>> If some other 3.x.1 release get broken this way, I would seriously
>>> consider tagging v3.x.1-rc1 as well. It works for Linus' tree.
>>
>> "this way" was for a very tiny subset of hardware, so odds are, if this
>> happens again, it wouldn't be caught this way either.  That subset just
>> happened to show up in your machine, but, for example, not in the wide
>> range of hardware I test with here, nor the machines that others test
>> with.
>
> It was certainly not just me. I have seen a lot of people mentioning
> "their wifi is broken", a lot of them using Arch Linux,
> coincidentally.

Because it was only "tested" through the mailing list on Arch-general. 
Like I stated your issue was related to you and not understanding Arch 
AND how that kernel was tested before being pushed to the repo's


>
> These issues would most likely not be caught before v3.x.1, and which
> point it's too late, they cannot be reverted to v3.x.2 just like that;
> they have to wait for upstream. Hopefully and probably everything
> would go smooth like this time, but maybe not, we'll have to wait and
> see. With more people using Arch Linux and thus the latest "stable"
> release, I'd say we might see an increase in these kinds of issues.
>
> Cheers.
>

Learn the distro you are using better.

Re: [ath9k-devel] [ 00/78] 3.3.2-stable review

[Don deJuan]

On 04/16/2012 02:50 PM, Felipe Contreras wrote:
> On Tue, Apr 17, 2012 at 12:27 AM, Greg KH<gregkh@linuxfoundation.org>  wrote:
>> On Tue, Apr 17, 2012 at 12:18:13AM +0300, Felipe Contreras wrote:
>>> On Mon, Apr 16, 2012 at 11:58 PM, Greg KH<gregkh@linuxfoundation.org>  wrote:
>>>> On Mon, Apr 16, 2012 at 11:11:05PM +0300, Felipe Contreras wrote:
>>>>> On Mon, Apr 16, 2012 at 7:27 PM, Greg KH<gregkh@linuxfoundation.org>  wrote:
>>>>>> Just one minor correction in this looney email thread:
>>>>>>
>>>>>> On Sat, Apr 14, 2012 at 01:53:22AM +0300, Felipe Contreras wrote:
>>>>>>> v3.3.x on the other hand are *not* stable. They contain patches
>>>>>>> backported from v3.4, but nobody guarantees they will work. There was
>>>>>>> no v3.3.1-rc1, so the first time the patches compromising v3.3.1 were
>>>>>>> generally tested together is in v3.3.1, at which point if somebody
>>>>>>> finds issues, it's too late; bad patches are *not* going to be removed
>>>>>>> in v3.3.2.
>>>>>>
>>>>>> Of course there was a 3.3.1-rc1, see the linux-kernel archives for the
>>>>>> announcemen and the individual patches.  kernel.org has the large patch
>>>>>> itself if you like that format instead.
>>>>>
>>>>> I don't see it here:
>>>>> http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=tags
>>>>>
>>>>> If you really want people to try it, why not tag it?
>>>>
>>>> That would be because I don't keep it in that tree.  It is in a quilt
>>>> tree you can find in the stable-queue.git repo, and I have never tagged
>>>> -rc1 releases there.  No one has ever asked for it before, so in the
>>>> past 6 years of stable releases, I guess no one ever needed it.
>>>>
>>>> ketchup and tarballs seem to work well for others, perhaps you can use
>>>> that as well (hint, ketchup on top of the linux-stable tree works just
>>>> fine for testing this.)
>>>
>>> Perhaps the current process will be continue to be OK, but I do
>>> believe a tagged v3.3.1-rc1 would have catched the ath9k issue.
>>
>> How exactly would that have helped here?
>
> More people would have given it a try. Not that many people read the
> mailing list, and the ones that do certainly might want to avoid
> applying a big series of patches; even if their mail client makes it
> easy (mine (Gmail) doesn't). A tag, and an announcement to give a try
> would make it *much* easier.
>
>> You point out:
>>
>>> I used to compile my own kernels and use your stable tree, but this a
>>> new laptop and I was using Arch Linux which automatically updated to
>>> v3.3.1, and with no network I had no way to revert to v3.2.x.
>>> Fortunately I had the kernel sources available, but I wonder how many
>>> people were completely stuck.
>>
>> Arch wouldn't have included a -rc in their kernel (unless they are
>> crazy), so this would not have helped your situation at all.
>
> There's *a lot* of people that got affected by the 3.3.1 release; we
> don't need to break a lot of boxes to figure out there's an issue,
> only a few would suffice, even one.
>
>>> If some other 3.x.1 release get broken this way, I would seriously
>>> consider tagging v3.x.1-rc1 as well. It works for Linus' tree.
>>
>> "this way" was for a very tiny subset of hardware, so odds are, if this
>> happens again, it wouldn't be caught this way either.  That subset just
>> happened to show up in your machine, but, for example, not in the wide
>> range of hardware I test with here, nor the machines that others test
>> with.
>
> It was certainly not just me. I have seen a lot of people mentioning
> "their wifi is broken", a lot of them using Arch Linux,
> coincidentally.
>
> These issues would most likely not be caught before v3.x.1, and which
> point it's too late, they cannot be reverted to v3.x.2 just like that;
> they have to wait for upstream. Hopefully and probably everything
> would go smooth like this time, but maybe not, we'll have to wait and
> see. With more people using Arch Linux and thus the latest "stable"
> release, I'd say we might see an increase in these kinds of issues.
>
> Cheers.
>


on an arch install only a couple months old with one cache cleaning in 
the beginning. the results of packages I could go back to on a bad update.

/var/cache/pacman/pkg $  ls -1 /var/cache/pacman/pkg/linux-*
/var/cache/pacman/pkg/linux-3.2.11-1-x86_64.pkg.tar.xz
/var/cache/pacman/pkg/linux-3.2.1-1-x86_64.pkg.tar.xz
/var/cache/pacman/pkg/linux-3.2.12-1-x86_64.pkg.tar.xz
/var/cache/pacman/pkg/linux-3.2.1-2-x86_64.pkg.tar.xz
/var/cache/pacman/pkg/linux-3.2.13-1-x86_64.pkg.tar.xz
/var/cache/pacman/pkg/linux-3.2.14-1-x86_64.pkg.tar.xz
/var/cache/pacman/pkg/linux-3.2.2-1-x86_64.pkg.tar.xz
/var/cache/pacman/pkg/linux-3.2.4-1-x86_64.pkg.tar.xz
/var/cache/pacman/pkg/linux-3.2.5-1-x86_64.pkg.tar.xz
/var/cache/pacman/pkg/linux-3.2.6-2-x86_64.pkg.tar.xz
/var/cache/pacman/pkg/linux-3.2.7-1-x86_64.pkg.tar.xz
/var/cache/pacman/pkg/linux-3.2.8-1-x86_64.pkg.tar.xz
/var/cache/pacman/pkg/linux-3.2.9-1-x86_64.pkg.tar.xz
/var/cache/pacman/pkg/linux-3.3.1-1-x86_64.pkg.tar.xz
/var/cache/pacman/pkg/linux-3.3.2-1-x86_64.pkg.tar.xz
/var/cache/pacman/pkg/linux-api-headers-3.1.6-1-x86_64.pkg.tar.xz
/var/cache/pacman/pkg/linux-api-headers-3.3-1-x86_64.pkg.tar.xz
/var/cache/pacman/pkg/linux-docs-3.2.11-1-x86_64.pkg.tar.xz
/var/cache/pacman/pkg/linux-docs-3.2.1-1-x86_64.pkg.tar.xz
/var/cache/pacman/pkg/linux-docs-3.2.12-1-x86_64.pkg.tar.xz
/var/cache/pacman/pkg/linux-docs-3.2.1-2-x86_64.pkg.tar.xz
/var/cache/pacman/pkg/linux-docs-3.2.13-1-x86_64.pkg.tar.xz
/var/cache/pacman/pkg/linux-docs-3.2.14-1-x86_64.pkg.tar.xz
/var/cache/pacman/pkg/linux-docs-3.2.2-1-x86_64.pkg.tar.xz
/var/cache/pacman/pkg/linux-docs-3.2.4-1-x86_64.pkg.tar.xz
/var/cache/pacman/pkg/linux-docs-3.2.5-1-x86_64.pkg.tar.xz
/var/cache/pacman/pkg/linux-docs-3.2.6-2-x86_64.pkg.tar.xz
/var/cache/pacman/pkg/linux-docs-3.2.7-1-x86_64.pkg.tar.xz
/var/cache/pacman/pkg/linux-docs-3.2.8-1-x86_64.pkg.tar.xz
/var/cache/pacman/pkg/linux-docs-3.2.9-1-x86_64.pkg.tar.xz
/var/cache/pacman/pkg/linux-docs-3.3.1-1-x86_64.pkg.tar.xz
/var/cache/pacman/pkg/linux-docs-3.3.2-1-x86_64.pkg.tar.xz
/var/cache/pacman/pkg/linux-firmware-20111101-1-any.pkg.tar.xz
/var/cache/pacman/pkg/linux-firmware-20120205-1-any.pkg.tar.xz
/var/cache/pacman/pkg/linux-firmware-20120227-1-any.pkg.tar.xz
/var/cache/pacman/pkg/linux-headers-3.2.11-1-x86_64.pkg.tar.xz
/var/cache/pacman/pkg/linux-headers-3.2.1-1-x86_64.pkg.tar.xz
/var/cache/pacman/pkg/linux-headers-3.2.12-1-x86_64.pkg.tar.xz
/var/cache/pacman/pkg/linux-headers-3.2.1-2-x86_64.pkg.tar.xz
/var/cache/pacman/pkg/linux-headers-3.2.13-1-x86_64.pkg.tar.xz
/var/cache/pacman/pkg/linux-headers-3.2.14-1-x86_64.pkg.tar.xz
/var/cache/pacman/pkg/linux-headers-3.2.2-1-x86_64.pkg.tar.xz
/var/cache/pacman/pkg/linux-headers-3.2.4-1-x86_64.pkg.tar.xz
/var/cache/pacman/pkg/linux-headers-3.2.5-1-x86_64.pkg.tar.xz
/var/cache/pacman/pkg/linux-headers-3.2.6-2-x86_64.pkg.tar.xz
/var/cache/pacman/pkg/linux-headers-3.2.7-1-x86_64.pkg.tar.xz
/var/cache/pacman/pkg/linux-headers-3.2.8-1-x86_64.pkg.tar.xz
/var/cache/pacman/pkg/linux-headers-3.2.9-1-x86_64.pkg.tar.xz
/var/cache/pacman/pkg/linux-headers-3.3.1-1-x86_64.pkg.tar.xz
/var/cache/pacman/pkg/linux-headers-3.3.2-1-x86_64.pkg.tar.xz
/var/cache/pacman/pkg/linux-lts-3.0.17-1-x86_64.pkg.tar.xz
/var/cache/pacman/pkg/linux-lts-3.0.17-2-x86_64.pkg.tar.xz
/var/cache/pacman/pkg/linux-lts-3.0.19-1-x86_64.pkg.tar.xz
/var/cache/pacman/pkg/linux-lts-3.0.20-1-x86_64.pkg.tar.xz
/var/cache/pacman/pkg/linux-lts-3.0.27-1-x86_64.pkg.tar.xz
/var/cache/pacman/pkg/linux-lts-headers-3.0.27-1-x86_64.pkg.tar.xz

yes this lists non relavent packages but shows that it is YOU who does 
not know your distro well enough.

Give up. I am done.. and Felipe NO MORE PRIVATE EMAILS! keep your 
conversations public unless someone asks you to contact them off list

[ath9k-devel] [ 00/78] 3.3.2-stable review

[Don deJuan]

On 04/16/2012 02:50 PM, Felipe Contreras wrote:
> On Tue, Apr 17, 2012 at 12:27 AM, Greg KH<gregkh@linuxfoundation.org>  wrote:
>> On Tue, Apr 17, 2012 at 12:18:13AM +0300, Felipe Contreras wrote:
>>> On Mon, Apr 16, 2012 at 11:58 PM, Greg KH<gregkh@linuxfoundation.org>  wrote:
>>>> On Mon, Apr 16, 2012 at 11:11:05PM +0300, Felipe Contreras wrote:
>>>>> On Mon, Apr 16, 2012 at 7:27 PM, Greg KH<gregkh@linuxfoundation.org>  wrote:
>>>>>> Just one minor correction in this looney email thread:
>>>>>>
>>>>>> On Sat, Apr 14, 2012 at 01:53:22AM +0300, Felipe Contreras wrote:
>>>>>>> v3.3.x on the other hand are *not* stable. They contain patches
>>>>>>> backported from v3.4, but nobody guarantees they will work. There was
>>>>>>> no v3.3.1-rc1, so the first time the patches compromising v3.3.1 were
>>>>>>> generally tested together is in v3.3.1, at which point if somebody
>>>>>>> finds issues, it's too late; bad patches are *not* going to be removed
>>>>>>> in v3.3.2.
>>>>>>
>>>>>> Of course there was a 3.3.1-rc1, see the linux-kernel archives for the
>>>>>> announcemen and the individual patches.  kernel.org has the large patch
>>>>>> itself if you like that format instead.
>>>>>
>>>>> I don't see it here:
>>>>> http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=tags
>>>>>
>>>>> If you really want people to try it, why not tag it?
>>>>
>>>> That would be because I don't keep it in that tree.  It is in a quilt
>>>> tree you can find in the stable-queue.git repo, and I have never tagged
>>>> -rc1 releases there.  No one has ever asked for it before, so in the
>>>> past 6 years of stable releases, I guess no one ever needed it.
>>>>
>>>> ketchup and tarballs seem to work well for others, perhaps you can use
>>>> that as well (hint, ketchup on top of the linux-stable tree works just
>>>> fine for testing this.)
>>>
>>> Perhaps the current process will be continue to be OK, but I do
>>> believe a tagged v3.3.1-rc1 would have catched the ath9k issue.
>>
>> How exactly would that have helped here?
>
> More people would have given it a try. Not that many people read the
> mailing list, and the ones that do certainly might want to avoid
> applying a big series of patches; even if their mail client makes it
> easy (mine (Gmail) doesn't). A tag, and an announcement to give a try
> would make it *much* easier.
>
>> You point out:
>>
>>> I used to compile my own kernels and use your stable tree, but this a
>>> new laptop and I was using Arch Linux which automatically updated to
>>> v3.3.1, and with no network I had no way to revert to v3.2.x.
>>> Fortunately I had the kernel sources available, but I wonder how many
>>> people were completely stuck.
>>
>> Arch wouldn't have included a -rc in their kernel (unless they are
>> crazy), so this would not have helped your situation at all.
>
> There's *a lot* of people that got affected by the 3.3.1 release; we
> don't need to break a lot of boxes to figure out there's an issue,
> only a few would suffice, even one.
>
>>> If some other 3.x.1 release get broken this way, I would seriously
>>> consider tagging v3.x.1-rc1 as well. It works for Linus' tree.
>>
>> "this way" was for a very tiny subset of hardware, so odds are, if this
>> happens again, it wouldn't be caught this way either.  That subset just
>> happened to show up in your machine, but, for example, not in the wide
>> range of hardware I test with here, nor the machines that others test
>> with.
>
> It was certainly not just me. I have seen a lot of people mentioning
> "their wifi is broken", a lot of them using Arch Linux,
> coincidentally.
>
> These issues would most likely not be caught before v3.x.1, and which
> point it's too late, they cannot be reverted to v3.x.2 just like that;
> they have to wait for upstream. Hopefully and probably everything
> would go smooth like this time, but maybe not, we'll have to wait and
> see. With more people using Arch Linux and thus the latest "stable"
> release, I'd say we might see an increase in these kinds of issues.
>
> Cheers.
>


on an arch install only a couple months old with one cache cleaning in 
the beginning. the results of packages I could go back to on a bad update.

/var/cache/pacman/pkg $  ls -1 /var/cache/pacman/pkg/linux-*
/var/cache/pacman/pkg/linux-3.2.11-1-x86_64.pkg.tar.xz
/var/cache/pacman/pkg/linux-3.2.1-1-x86_64.pkg.tar.xz
/var/cache/pacman/pkg/linux-3.2.12-1-x86_64.pkg.tar.xz
/var/cache/pacman/pkg/linux-3.2.1-2-x86_64.pkg.tar.xz
/var/cache/pacman/pkg/linux-3.2.13-1-x86_64.pkg.tar.xz
/var/cache/pacman/pkg/linux-3.2.14-1-x86_64.pkg.tar.xz
/var/cache/pacman/pkg/linux-3.2.2-1-x86_64.pkg.tar.xz
/var/cache/pacman/pkg/linux-3.2.4-1-x86_64.pkg.tar.xz
/var/cache/pacman/pkg/linux-3.2.5-1-x86_64.pkg.tar.xz
/var/cache/pacman/pkg/linux-3.2.6-2-x86_64.pkg.tar.xz
/var/cache/pacman/pkg/linux-3.2.7-1-x86_64.pkg.tar.xz
/var/cache/pacman/pkg/linux-3.2.8-1-x86_64.pkg.tar.xz
/var/cache/pacman/pkg/linux-3.2.9-1-x86_64.pkg.tar.xz
/var/cache/pacman/pkg/linux-3.3.1-1-x86_64.pkg.tar.xz
/var/cache/pacman/pkg/linux-3.3.2-1-x86_64.pkg.tar.xz
/var/cache/pacman/pkg/linux-api-headers-3.1.6-1-x86_64.pkg.tar.xz
/var/cache/pacman/pkg/linux-api-headers-3.3-1-x86_64.pkg.tar.xz
/var/cache/pacman/pkg/linux-docs-3.2.11-1-x86_64.pkg.tar.xz
/var/cache/pacman/pkg/linux-docs-3.2.1-1-x86_64.pkg.tar.xz
/var/cache/pacman/pkg/linux-docs-3.2.12-1-x86_64.pkg.tar.xz
/var/cache/pacman/pkg/linux-docs-3.2.1-2-x86_64.pkg.tar.xz
/var/cache/pacman/pkg/linux-docs-3.2.13-1-x86_64.pkg.tar.xz
/var/cache/pacman/pkg/linux-docs-3.2.14-1-x86_64.pkg.tar.xz
/var/cache/pacman/pkg/linux-docs-3.2.2-1-x86_64.pkg.tar.xz
/var/cache/pacman/pkg/linux-docs-3.2.4-1-x86_64.pkg.tar.xz
/var/cache/pacman/pkg/linux-docs-3.2.5-1-x86_64.pkg.tar.xz
/var/cache/pacman/pkg/linux-docs-3.2.6-2-x86_64.pkg.tar.xz
/var/cache/pacman/pkg/linux-docs-3.2.7-1-x86_64.pkg.tar.xz
/var/cache/pacman/pkg/linux-docs-3.2.8-1-x86_64.pkg.tar.xz
/var/cache/pacman/pkg/linux-docs-3.2.9-1-x86_64.pkg.tar.xz
/var/cache/pacman/pkg/linux-docs-3.3.1-1-x86_64.pkg.tar.xz
/var/cache/pacman/pkg/linux-docs-3.3.2-1-x86_64.pkg.tar.xz
/var/cache/pacman/pkg/linux-firmware-20111101-1-any.pkg.tar.xz
/var/cache/pacman/pkg/linux-firmware-20120205-1-any.pkg.tar.xz
/var/cache/pacman/pkg/linux-firmware-20120227-1-any.pkg.tar.xz
/var/cache/pacman/pkg/linux-headers-3.2.11-1-x86_64.pkg.tar.xz
/var/cache/pacman/pkg/linux-headers-3.2.1-1-x86_64.pkg.tar.xz
/var/cache/pacman/pkg/linux-headers-3.2.12-1-x86_64.pkg.tar.xz
/var/cache/pacman/pkg/linux-headers-3.2.1-2-x86_64.pkg.tar.xz
/var/cache/pacman/pkg/linux-headers-3.2.13-1-x86_64.pkg.tar.xz
/var/cache/pacman/pkg/linux-headers-3.2.14-1-x86_64.pkg.tar.xz
/var/cache/pacman/pkg/linux-headers-3.2.2-1-x86_64.pkg.tar.xz
/var/cache/pacman/pkg/linux-headers-3.2.4-1-x86_64.pkg.tar.xz
/var/cache/pacman/pkg/linux-headers-3.2.5-1-x86_64.pkg.tar.xz
/var/cache/pacman/pkg/linux-headers-3.2.6-2-x86_64.pkg.tar.xz
/var/cache/pacman/pkg/linux-headers-3.2.7-1-x86_64.pkg.tar.xz
/var/cache/pacman/pkg/linux-headers-3.2.8-1-x86_64.pkg.tar.xz
/var/cache/pacman/pkg/linux-headers-3.2.9-1-x86_64.pkg.tar.xz
/var/cache/pacman/pkg/linux-headers-3.3.1-1-x86_64.pkg.tar.xz
/var/cache/pacman/pkg/linux-headers-3.3.2-1-x86_64.pkg.tar.xz
/var/cache/pacman/pkg/linux-lts-3.0.17-1-x86_64.pkg.tar.xz
/var/cache/pacman/pkg/linux-lts-3.0.17-2-x86_64.pkg.tar.xz
/var/cache/pacman/pkg/linux-lts-3.0.19-1-x86_64.pkg.tar.xz
/var/cache/pacman/pkg/linux-lts-3.0.20-1-x86_64.pkg.tar.xz
/var/cache/pacman/pkg/linux-lts-3.0.27-1-x86_64.pkg.tar.xz
/var/cache/pacman/pkg/linux-lts-headers-3.0.27-1-x86_64.pkg.tar.xz

yes this lists non relavent packages but shows that it is YOU who does 
not know your distro well enough.

Give up. I am done.. and Felipe NO MORE PRIVATE EMAILS! keep your 
conversations public unless someone asks you to contact them off list

Re: [ath9k-devel] [ 00/78] 3.3.2-stable review

[Peter Stuge]

Felipe Contreras wrote:
> With more people using Arch Linux and thus the latest "stable"
> release, I'd say we might see an increase in these kinds of issues.

You touch on an important point. Arch has it's own support channels,
and after a few of these kinds of issues perhaps Arch will decide to
push a different kernel to their users.

None of the Arch users I know (though only a few) would have had a
critical problem without wifi.

What kernel to push to users is anyway a distribution problem, so if
you must discuss then please discuss within the Arch community the
pros and cons of the various available kernel trees. Maybe they will
prefer another one than they currently do, after your reasoning.

I personally don't care about what any distribution does; I just use
Linus' tree, and I might merge some other trees if they have
important changes which I want before Linus takes them. When I did
this the first time is btw the time where I really learned to
appreciate just how powerful git is.


//Peter

[ath9k-devel] [ 00/78] 3.3.2-stable review

[Peter Stuge]

Felipe Contreras wrote:
> With more people using Arch Linux and thus the latest "stable"
> release, I'd say we might see an increase in these kinds of issues.

You touch on an important point. Arch has it's own support channels,
and after a few of these kinds of issues perhaps Arch will decide to
push a different kernel to their users.

None of the Arch users I know (though only a few) would have had a
critical problem without wifi.

What kernel to push to users is anyway a distribution problem, so if
you must discuss then please discuss within the Arch community the
pros and cons of the various available kernel trees. Maybe they will
prefer another one than they currently do, after your reasoning.

I personally don't care about what any distribution does; I just use
Linus' tree, and I might merge some other trees if they have
important changes which I want before Linus takes them. When I did
this the first time is btw the time where I really learned to
appreciate just how powerful git is.


//Peter

Re: [ath9k-devel] [ 00/78] 3.3.2-stable review

[Willy Tarreau]

On Tue, Apr 17, 2012 at 12:44:25AM +0300, Felipe Contreras wrote:
> >> Perhaps the current process will be continue to be OK, but I do
> >> believe a tagged v3.3.1-rc1 would have catched the ath9k issue.
> >
> > How exactly would that have helped here?
> 
> More people would have given it a try. Not that many people read the
> mailing list, and the ones that do certainly might want to avoid
> applying a big series of patches; even if their mail client makes it
> easy (mine (Gmail) doesn't). A tag, and an announcement to give a try
> would make it *much* easier.

That's totally unrelated. A tag means that these changes would have been
committed (with history etc...). This would not have changed anything of
the running/broken code. It would have failed similarly without any way
for you to revert. The rc1 was announced and was available on kernel.org.
A tag would not have changed anything here, except by making the release
process much more complex by basically having to revert every unsuitable
patch instead of dropping it. It would mean that rc1 would in fact have
been 3.3.1 and that 3.3.1 would have been 3.3.2. You just shift the release
by one number and don't bring any value here.

> >> I used to compile my own kernels and use your stable tree, but this a
> >> new laptop and I was using Arch Linux which automatically updated to
> >> v3.3.1, and with no network I had no way to revert to v3.2.x.
> >> Fortunately I had the kernel sources available, but I wonder how many
> >> people were completely stuck.
> >
> > Arch wouldn't have included a -rc in their kernel (unless they are
> > crazy), so this would not have helped your situation at all.
> 
> There's *a lot* of people that got affected by the 3.3.1 release; we
> don't need to break a lot of boxes to figure out there's an issue,
> only a few would suffice, even one.

I'm sorry, but I don't buy this. There are *always* regressions caused by
kernel updates, and even the beginners I know are used to keep a working
kernel on their systems precisely because they know they can be left with
something which does not boot anymore. So if you upgrade your *only* kernel
without keeping a safe one, it's not a mistake, it's a fault, your fault. A
beginner wouldn't have done this. You wouldn't have recovered from a hanging
boot, a panic or a SATA timeout either. Drivers issues are the worst ones
because nobody can exhaustively test them all, not even your distro vendor.
The solution is always to keep a working kernel as an alternate boot.

> >> If some other 3.x.1 release get broken this way, I would seriously
> >> consider tagging v3.x.1-rc1 as well. It works for Linus' tree.
> >
> > "this way" was for a very tiny subset of hardware, so odds are, if this
> > happens again, it wouldn't be caught this way either.  That subset just
> > happened to show up in your machine, but, for example, not in the wide
> > range of hardware I test with here, nor the machines that others test
> > with.
> 
> It was certainly not just me. I have seen a lot of people mentioning
> "their wifi is broken", a lot of them using Arch Linux,
> coincidentally.

Maybe because these are people you know and you taught to blindly update
without keep a safe boot option ?

Now it becomes a lot clearer that you want a user fault to be covered by
a development process. That will never ever work because the only way it
will solve your behavioral issue is to release 100% safe and 100% compatible
kernels each time, which by definition is not possible if anything changes.

Willy

Re: [ath9k-devel] [ 00/78] 3.3.2-stable review

[Willy Tarreau]

On Tue, Apr 17, 2012 at 12:44:25AM +0300, Felipe Contreras wrote:
> >> Perhaps the current process will be continue to be OK, but I do
> >> believe a tagged v3.3.1-rc1 would have catched the ath9k issue.
> >
> > How exactly would that have helped here?
> 
> More people would have given it a try. Not that many people read the
> mailing list, and the ones that do certainly might want to avoid
> applying a big series of patches; even if their mail client makes it
> easy (mine (Gmail) doesn't). A tag, and an announcement to give a try
> would make it *much* easier.

That's totally unrelated. A tag means that these changes would have been
committed (with history etc...). This would not have changed anything of
the running/broken code. It would have failed similarly without any way
for you to revert. The rc1 was announced and was available on kernel.org.
A tag would not have changed anything here, except by making the release
process much more complex by basically having to revert every unsuitable
patch instead of dropping it. It would mean that rc1 would in fact have
been 3.3.1 and that 3.3.1 would have been 3.3.2. You just shift the release
by one number and don't bring any value here.

> >> I used to compile my own kernels and use your stable tree, but this a
> >> new laptop and I was using Arch Linux which automatically updated to
> >> v3.3.1, and with no network I had no way to revert to v3.2.x.
> >> Fortunately I had the kernel sources available, but I wonder how many
> >> people were completely stuck.
> >
> > Arch wouldn't have included a -rc in their kernel (unless they are
> > crazy), so this would not have helped your situation at all.
> 
> There's *a lot* of people that got affected by the 3.3.1 release; we
> don't need to break a lot of boxes to figure out there's an issue,
> only a few would suffice, even one.

I'm sorry, but I don't buy this. There are *always* regressions caused by
kernel updates, and even the beginners I know are used to keep a working
kernel on their systems precisely because they know they can be left with
something which does not boot anymore. So if you upgrade your *only* kernel
without keeping a safe one, it's not a mistake, it's a fault, your fault. A
beginner wouldn't have done this. You wouldn't have recovered from a hanging
boot, a panic or a SATA timeout either. Drivers issues are the worst ones
because nobody can exhaustively test them all, not even your distro vendor.
The solution is always to keep a working kernel as an alternate boot.

> >> If some other 3.x.1 release get broken this way, I would seriously
> >> consider tagging v3.x.1-rc1 as well. It works for Linus' tree.
> >
> > "this way" was for a very tiny subset of hardware, so odds are, if this
> > happens again, it wouldn't be caught this way either. �That subset just
> > happened to show up in your machine, but, for example, not in the wide
> > range of hardware I test with here, nor the machines that others test
> > with.
> 
> It was certainly not just me. I have seen a lot of people mentioning
> "their wifi is broken", a lot of them using Arch Linux,
> coincidentally.

Maybe because these are people you know and you taught to blindly update
without keep a safe boot option ?

Now it becomes a lot clearer that you want a user fault to be covered by
a development process. That will never ever work because the only way it
will solve your behavioral issue is to release 100% safe and 100% compatible
kernels each time, which by definition is not possible if anything changes.

Willy

[ath9k-devel] [ 00/78] 3.3.2-stable review

[Willy Tarreau]

On Tue, Apr 17, 2012 at 12:44:25AM +0300, Felipe Contreras wrote:
> >> Perhaps the current process will be continue to be OK, but I do
> >> believe a tagged v3.3.1-rc1 would have catched the ath9k issue.
> >
> > How exactly would that have helped here?
> 
> More people would have given it a try. Not that many people read the
> mailing list, and the ones that do certainly might want to avoid
> applying a big series of patches; even if their mail client makes it
> easy (mine (Gmail) doesn't). A tag, and an announcement to give a try
> would make it *much* easier.

That's totally unrelated. A tag means that these changes would have been
committed (with history etc...). This would not have changed anything of
the running/broken code. It would have failed similarly without any way
for you to revert. The rc1 was announced and was available on kernel.org.
A tag would not have changed anything here, except by making the release
process much more complex by basically having to revert every unsuitable
patch instead of dropping it. It would mean that rc1 would in fact have
been 3.3.1 and that 3.3.1 would have been 3.3.2. You just shift the release
by one number and don't bring any value here.

> >> I used to compile my own kernels and use your stable tree, but this a
> >> new laptop and I was using Arch Linux which automatically updated to
> >> v3.3.1, and with no network I had no way to revert to v3.2.x.
> >> Fortunately I had the kernel sources available, but I wonder how many
> >> people were completely stuck.
> >
> > Arch wouldn't have included a -rc in their kernel (unless they are
> > crazy), so this would not have helped your situation at all.
> 
> There's *a lot* of people that got affected by the 3.3.1 release; we
> don't need to break a lot of boxes to figure out there's an issue,
> only a few would suffice, even one.

I'm sorry, but I don't buy this. There are *always* regressions caused by
kernel updates, and even the beginners I know are used to keep a working
kernel on their systems precisely because they know they can be left with
something which does not boot anymore. So if you upgrade your *only* kernel
without keeping a safe one, it's not a mistake, it's a fault, your fault. A
beginner wouldn't have done this. You wouldn't have recovered from a hanging
boot, a panic or a SATA timeout either. Drivers issues are the worst ones
because nobody can exhaustively test them all, not even your distro vendor.
The solution is always to keep a working kernel as an alternate boot.

> >> If some other 3.x.1 release get broken this way, I would seriously
> >> consider tagging v3.x.1-rc1 as well. It works for Linus' tree.
> >
> > "this way" was for a very tiny subset of hardware, so odds are, if this
> > happens again, it wouldn't be caught this way either. ?That subset just
> > happened to show up in your machine, but, for example, not in the wide
> > range of hardware I test with here, nor the machines that others test
> > with.
> 
> It was certainly not just me. I have seen a lot of people mentioning
> "their wifi is broken", a lot of them using Arch Linux,
> coincidentally.

Maybe because these are people you know and you taught to blindly update
without keep a safe boot option ?

Now it becomes a lot clearer that you want a user fault to be covered by
a development process. That will never ever work because the only way it
will solve your behavioral issue is to release 100% safe and 100% compatible
kernels each time, which by definition is not possible if anything changes.

Willy