3.3.2-stable review
Subsystems (67)
Greg KH
maintainercover 3.3.2-stable review
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(-)
Greg KH
maintainerPATCH 1/78 x86 bpf_jit: fix a bug in emitting the 16-bit immediate operand of AND
3.3-stable review patch. If anyone has any objections, please let me know.
------------------
From: Feiran Zhuang <[email protected]>
[ 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().
--- arch/x86/net/bpf_jit_comp.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
arch/x86/net/bpf_jit_comp.c +1 -1
@@ -289,7 +289,7 @@ void bpf_jit_compile(struct sk_filter *fEMIT2 (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 */ }
Greg KH
maintainerPATCH 2/78 via-rhine: fix wait-bit inversion.
In reply to Greg KH3.3-stable review patch. If anyone has any objections, please let me know.
------------------
From: Andreas Mohr <[email protected]>
[ Upstream commit 3f8c91a7398b9266fbe7abcbe4bd5dffef907643 ]
Bug appeared in a384a33bb1c9ec2d99db2046b41f57023fa7d77b ("via-rhine: RHINE_WAIT_FOR macro removal). It can be noticed during suspend/resume.
--- drivers/net/ethernet/via/via-rhine.c | 12 +++++++----- 1 file changed, 7 insertions(+), 5 deletions(-)
drivers/net/ethernet/via/via-rhine.c +7 -5
@@ -503,30 +503,32 @@ static int rhine_vlan_rx_add_vid(structstatic 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)
Greg KH
maintainerPATCH 3/78 tg3: Fix 5717 serdes powerdown problem
In reply to Greg KH3.3-stable review patch. If anyone has any objections, please let me know.
------------------
From: Matt Carlson <[email protected]>
[ 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.
--- drivers/net/ethernet/broadcom/tg3.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
drivers/net/ethernet/broadcom/tg3.c +3 -1
@@ -2771,7 +2771,9 @@ static void tg3_power_down_phy(struct tgif (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 ||
Greg KH
maintainerPATCH 4/78 sky2: dont overwrite settings for PHY Quick link
In reply to Greg KH3.3-stable review patch. If anyone has any objections, please let me know.
------------------
From: Lino Sanfilippo <[email protected]>
[ 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.
--- drivers/net/ethernet/marvell/sky2.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)
drivers/net/ethernet/marvell/sky2.c +3 -2
@@ -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 );
Greg KH
maintainerPATCH 5/78 rose_dev: fix memcpy-bug in rose_set_mac_address
In reply to Greg KH3.3-stable review patch. If anyone has any objections, please let me know.
------------------
From: "[email protected]" <[email protected]>
[ 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.
--- net/rose/rose_dev.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
net/rose/rose_dev.c +2 -2
@@ -96,11 +96,11 @@ static int rose_set_mac_address(struct nstruct 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;
Greg KH
maintainerPATCH 6/78 net: usb: cdc_eem: fix mtu
In reply to Greg KH3.3-stable review patch. If anyone has any objections, please let me know.
------------------
From: Rabin Vincent <[email protected]>
[ 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.
--- drivers/net/usb/cdc_eem.c | 1 + 1 file changed, 1 insertion(+)
drivers/net/usb/cdc_eem.c +1 -0
@@ -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 ; }
Greg KH
maintainerPATCH 7/78 Fix non TBI PHY access; a bad merge undid bug fix in a previous commit.
In reply to Greg KH3.3-stable review patch. If anyone has any objections, please let me know.
------------------
From: Kenth Eriksson <[email protected]>
[ 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.
--- drivers/net/ethernet/freescale/fsl_pq_mdio.c | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-)
drivers/net/ethernet/freescale/fsl_pq_mdio.c +6 -6
@@ -356,13 +356,13 @@ static int fsl_pq_mdio_probe(struct platif (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);
Greg KH
maintainerPATCH 8/78 ALSA: hda/realtek - Fix ADC assignment with a shared HP/Mic pin
In reply to Greg KH3.3-stable review patch. If anyone has any objections, please let me know.
------------------
From: Takashi Iwai <[email protected]>
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
--- sound/pci/hda/patch_realtek.c | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-)
sound/pci/hda/patch_realtek.c +7 -4
@@ -2709,9 +2709,6 @@ static int alc_auto_fill_adc_caps(structint 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 */ }
Greg KH
maintainerPATCH 9/78 ASoC: wm8994: Update WM8994 DCS calibration
In reply to Greg KH3.3-stable review patch. If anyone has any objections, please let me know.
------------------
From: Mark Brown <[email protected]>
commit e16605855d58803fe0608417150c7a618b4f8243 upstream.
Based on latest production information.
--- sound/soc/codecs/wm8994.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
sound/soc/codecs/wm8994.c +1 -1
@@ -3427,7 +3427,7 @@ static int wm8994_codec_probe(struct sndcase 2 :case 3 : wm8994->hubs.dcs_codes_l =-9 ; - wm8994->hubs.dcs_codes_r =-5 ; + wm8994->hubs.dcs_codes_r =-7 ;break ;default :break ;
Greg KH
maintainerPATCH 10/78 mtd: ixp4xx: oops in ixp4xx_flash_probe
In reply to Greg KH3.3-stable review patch. If anyone has any objections, please let me know.
------------------
From: Marc Kleine-Budde <[email protected]>
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()".
--- drivers/mtd/maps/ixp4xx.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)
drivers/mtd/maps/ixp4xx.c +4 -1
@@ -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" );
Greg KH
maintainerPATCH 11/78 mtd: mips: lantiq: reintroduce support for cmdline partitions
In reply to Greg KH3.3-stable review patch. If anyone has any objections, please let me know.
------------------
From: Daniel Schwierzeck <[email protected]>
commit bf011f2ed53d587fdd8148c173c4f09ed77bdf1a upstream.
Since commit ca97dec2ab5c87e9fbdf7e882e1820004a3966fa the command line parsing of MTD partitions does not work anymore.
--- drivers/mtd/maps/lantiq-flash.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
drivers/mtd/maps/lantiq-flash.c +2 -1
@@ -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" );
Greg KH
maintainerPATCH 12/78 mtd: nand: gpmi: use correct member for checking NAND_BBT_USE_FLASH
In reply to Greg KH3.3-stable review patch. If anyone has any objections, please let me know.
------------------
From: Wolfram Sang <[email protected]>
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
--- drivers/mtd/nand/gpmi-nand/gpmi-nand.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/mtd/nand/gpmi-nand/gpmi-nand.c +1 -1
@@ -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);
Greg KH
maintainerPATCH 13/78 mtd: sst25l: initialize writebufsize
In reply to Greg KH3.3-stable review patch. If anyone has any objections, please let me know.
------------------
From: Artem Bityutskiy <[email protected]>
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.
--- drivers/mtd/devices/sst25l.c | 1 + 1 file changed, 1 insertion(+)
drivers/mtd/devices/sst25l.c +1 -0
@@ -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;
Greg KH
maintainerPATCH 14/78 mtd: doc2001plus: initialize writebufsize
In reply to Greg KH3.3-stable review patch. If anyone has any objections, please let me know.
------------------
From: Artem Bityutskiy <[email protected]>
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.
--- drivers/mtd/devices/doc2001plus.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/mtd/devices/doc2001plus.c +1 -1
@@ -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;
Greg KH
maintainerPATCH 15/78 mtd: doc2000: initialize writebufsize
In reply to Greg KH3.3-stable review patch. If anyone has any objections, please let me know.
------------------
From: Artem Bityutskiy <[email protected]>
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.
--- drivers/mtd/devices/doc2000.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/mtd/devices/doc2000.c +1 -1
@@ -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;
Greg KH
maintainerPATCH 16/78 mtd: doc2001: initialize writebufsize
In reply to Greg KH3.3-stable review patch. If anyone has any objections, please let me know.
------------------
From: Artem Bityutskiy <[email protected]>
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.
--- drivers/mtd/devices/doc2001.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/mtd/devices/doc2001.c +1 -1
@@ -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;
Greg KH
maintainerPATCH 17/78 mtd: docg3: initialize writebufsize
In reply to Greg KH3.3-stable review patch. If anyone has any objections, please let me know.
------------------
From: Artem Bityutskiy <[email protected]>
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.
--- drivers/mtd/devices/docg3.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/mtd/devices/docg3.c +1 -1
@@ -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;
Greg KH
maintainerPATCH 18/78 mtd: block2mtd: initialize writebufsize
In reply to Greg KH3.3-stable review patch. If anyone has any objections, please let me know.
------------------
From: Artem Bityutskiy <[email protected]>
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.
--- drivers/mtd/devices/block2mtd.c | 1 + 1 file changed, 1 insertion(+)
drivers/mtd/devices/block2mtd.c +1 -0
@@ -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;
Greg KH
maintainerPATCH 19/78 mtd: lart: initialize writebufsize
In reply to Greg KH3.3-stable review patch. If anyone has any objections, please let me know.
------------------
From: Artem Bityutskiy <[email protected]>
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.
--- drivers/mtd/devices/lart.c | 1 + 1 file changed, 1 insertion(+)
drivers/mtd/devices/lart.c +1 -0
@@ -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 ;
Greg KH
maintainerPATCH 20/78 mtd: m25p80: set writebufsize
In reply to Greg KH3.3-stable review patch. If anyone has any objections, please let me know.
------------------
From: Brian Norris <[email protected]>
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?
--- drivers/mtd/devices/m25p80.c | 1 + 1 file changed, 1 insertion(+)
drivers/mtd/devices/m25p80.c +1 -0
@@ -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;
Greg KH
maintainerPATCH 21/78 ACPI: Do cpufreq clamping for throttling per package v2
In reply to Greg KH3.3-stable review patch. If anyone has any objections, please let me know.
------------------
From: Andi Kleen <[email protected]>
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
--- drivers/acpi/processor_thermal.c | 45 ++++++++++++++++++++++++++++++++------- 1 file changed, 37 insertions(+), 8 deletions(-)
drivers/acpi/processor_thermal.c +37 -8
@@ -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(unsigneif (!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)
Greg KH
maintainerPATCH 22/78 PNPACPI: Fix device ref leaking in acpi_pnp_match
In reply to Greg KH3.3-stable review patch. If anyone has any objections, please let me know.
------------------
From: Yinghai Lu <[email protected]>
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.
--- drivers/pnp/pnpacpi/core.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-)
drivers/pnp/pnpacpi/core.c +6 -1
@@ -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)); }
Greg KH
maintainerPATCH 23/78 ACPICA: Fix regression in FADT revision checks
In reply to Greg KH3.3-stable review patch. If anyone has any objections, please let me know.
------------------
From: Julian Anastasov <[email protected]>
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 noticecst_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
--- drivers/acpi/acpica/tbfadt.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-)
drivers/acpi/acpica/tbfadt.c +4 -4
@@ -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
Greg KH
maintainerPATCH 24/78 modpost: fix ALL_INIT_DATA_SECTIONS
In reply to Greg KH3.3-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jan Beulich <[email protected]>
commit 9aaf440f8fabcebf9ea79a62ccf4c212e6544b49 upstream.
This was lacking a comma between two supposed to be separate strings.
--- scripts/mod/modpost.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
scripts/mod/modpost.c +1 -1
@@ -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$"
Greg KH
maintainerPATCH 25/78 genirq: Adjust irq thread affinity on IRQ_SET_MASK_OK_NOCOPY return value
In reply to Greg KH3.3-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jiang Liu <[email protected]>
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.
--- kernel/irq/migration.c | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-)
kernel/irq/migration.c +7 -3
@@ -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); }
Greg KH
maintainerPATCH 26/78 tracing: Fix ftrace stack trace entries
In reply to Greg KH3.3-stable review patch. If anyone has any objections, please let me know.
------------------
From: Wolfgang Mauerer <[email protected]>
commit 01de982abf8c9e10fc3089e10585cd2cc914bdab upstream.
8 hex characters tell only half the tale for 64 bit CPUs, so use the appropriate length.
--- kernel/trace/trace_entries.h | 16 ++++++++++++---- kernel/trace/trace_export.c | 2 +- 2 files changed, 13 insertions(+), 5 deletions(-)
kernel/trace/trace_entries.h +12 -4
@@ -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 ])
kernel/trace/trace_export.c +1 -1
@@ -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) \
Greg KH
maintainerPATCH 27/78 tracing: Fix ent_size in trace output
In reply to Greg KH3.3-stable review patch. If anyone has any objections, please let me know.
------------------
From: Steven Rostedt <[email protected]>
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.
--- kernel/trace/trace.c | 4 ++++ 1 file changed, 4 insertions(+)
kernel/trace/trace.c +4 -0
@@ -1644,6 +1644,7 @@ __find_next_entry(struct trace_iteratorint 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;
Greg KH
maintainerPATCH 28/78 m68k/mac: Add missing platform check before registering platform devices
In reply to Greg KH3.3-stable review patch. If anyone has any objections, please let me know.
------------------
From: Geert Uytterhoeven <[email protected]>
commit 6cfeba53911d6d2f17ebbd1246893557d5ff5aeb upstream.
On multi-platform kernels, the Mac platform devices should be registered when running on Mac only. Else it may crash later.
--- arch/m68k/mac/config.c | 3 +++ 1 file changed, 3 insertions(+)
arch/m68k/mac/config.c +3 -0
@@ -981,6 +981,9 @@ int __init mac_platform_init(void) {u8 *swim_base; +if (!MACH_IS_MAC ) +return -ENODEV ; +/* * Serial devices */
Greg KH
maintainerPATCH 29/78 mac80211: fix possible tid_rx->reorder_timer use after free
In reply to Greg KH3.3-stable review patch. If anyone has any objections, please let me know.
------------------
From: Stanislaw Gruszka <[email protected]>
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
--- net/mac80211/agg-rx.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
net/mac80211/agg-rx.c +2 -1
@@ -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); }
Greg KH
maintainerPATCH 30/78 rtlwifi: rtl8192ce: rtl8192cu: rtl8192de: Fix low-gain setting when scanning
In reply to Greg KH3.3-stable review patch. If anyone has any objections, please let me know.
------------------
From: Larry Finger <[email protected]>
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.
--- drivers/net/wireless/rtlwifi/rtl8192c/phy_common.c | 2 +- drivers/net/wireless/rtlwifi/rtl8192de/phy.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-)
drivers/net/wireless/rtlwifi/rtl8192c/phy_common.c +1 -1
@@ -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 :
drivers/net/wireless/rtlwifi/rtl8192de/phy.c +1 -1
@@ -3192,7 +3192,7 @@ static void rtl92d_phy_set_io(struct ieebreak ;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 :
Greg KH
maintainerPATCH 31/78 ath9k: fix max noise floor threshold
In reply to Greg KH3.3-stable review patch. If anyone has any objections, please let me know.
------------------
From: Rajkumar Manoharan <[email protected]>
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.
--- drivers/net/wireless/ath/ath9k/calib.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-)
drivers/net/wireless/ath/ath9k/calib.c +2 -3
@@ -20,7 +20,6 @@/* Common calibration code */ -#define ATH9K_NF_TOO_HIGH -60static 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,
Re: [ 31/78] ath9k: fix max noise floor threshold
Quoted 8 lines · Greg KH
3.3-stable review patch. If anyone has any objections, please let me know.
------------------
From: Rajkumar Manoharan <[email protected]>
commit
2ee0a07028d2cde6e131b73f029dae2b93c50f3aupstream.
Quoted 8 lines
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.
Signature · 2 lines
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 <[email protected]>
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.
--- drivers/net/wireless/ath/ath9k/calib.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-)
drivers/net/wireless/ath/ath9k/calib.c +2 -3
@@ -20,7 +20,6 @@/* Common calibration code */ -#define ATH9K_NF_TOO_HIGH -60static 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,
Signature · 1 line
1.7.9.5
Re: [ 31/78] ath9k: fix max noise floor threshold
Quoted 17 lines · Ben Hutchings
Quoted 8 lines · Greg KH
3.3-stable review patch. If anyone has any objections, please let me know.
------------------
From: Rajkumar Manoharan <[email protected]>
commit
2ee0a07028d2cde6e131b73f029dae2b93c50f3aupstream.Quoted 8 lines
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.
Quoted 6 lines
[...]
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
Quoted 60 lines
Signature · 30 lines
-- 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 <[email protected]> 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 <[email protected]> Tested-by: Gary Morain <[email protected]> Signed-off-by: Madhan Jaganathan <[email protected]> Signed-off-by: Rajkumar Manoharan <[email protected]> Signed-off-by: John W. Linville <[email protected]> [bwh: Backported to 3.0/3.2: adjust context] Signed-off-by: Ben Hutchings <[email protected]> --- drivers/net/wireless/ath/ath9k/calib.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-)drivers/net/wireless/ath/ath9k/calib.c +2
-3@@ -20,7 +20,6 @@/* Common calibration code */ -#define ATH9K_NF_TOO_HIGH -60static 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,Signature · 1 line
1.7.9.5
Greg KH
maintainerPATCH 32/78 drm: Validate requested virtual size against allocated fb size
In reply to Greg KH3.3-stable review patch. If anyone has any objections, please let me know.
------------------
From: Chris Wilson <[email protected]>
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
--- drivers/gpu/drm/drm_fb_helper.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-)
drivers/gpu/drm/drm_fb_helper.c +6 -2
@@ -617,9 +617,13 @@ int drm_fb_helper_check_var(struct fb_vareturn -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 ; }
Greg KH
maintainerPATCH 33/78 drm/radeon/kms: fix fans after resume
In reply to Greg KH3.3-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alex Deucher <[email protected]>
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
--- drivers/gpu/drm/radeon/atom.c | 15 ++++++++++++++- drivers/gpu/drm/radeon/atom.h | 1 + 2 files changed, 15 insertions(+), 1 deletion(-)
drivers/gpu/drm/radeon/atom.c +14 -1
@@ -1306,8 +1306,11 @@ struct atom_context *atom_parse(struct cint 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)
drivers/gpu/drm/radeon/atom.h +1 -0
@@ -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
Greg KH
maintainerPATCH 34/78 drm/i915: no-lvds quirk on MSI DC500
In reply to Greg KH3.3-stable review patch. If anyone has any objections, please let me know.
------------------
From: Anisse Astier <[email protected]>
commit 97effadb65ed08809e1720c8d3ee80b73a93665c upstream.
This hardware doesn't have an LVDS, it's a desktop box. Fix incorrect LVDS detection.
--- drivers/gpu/drm/i915/intel_lvds.c | 8 ++++++++ 1 file changed, 8 insertions(+)
drivers/gpu/drm/i915/intel_lvds.c +8 -0
@@ -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 */ };
Greg KH
maintainerPATCH 35/78 drm/i915: treat src w & h as fixed point in sprite handling code
In reply to Greg KH3.3-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jesse Barnes <[email protected]>
commit b4db1e35ac59c144965f517bc575a0d75b60b03f upstream.
This was missed when we converted the source values to 16.16 fixed point.
--- drivers/gpu/drm/i915/intel_sprite.c | 3 +++ 1 file changed, 3 insertions(+)
drivers/gpu/drm/i915/intel_sprite.c +3 -0
@@ -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 ;
Greg KH
maintainerPATCH 36/78 drm/i915: Sanitize BIOS debugging bits from PIPECONF
In reply to Greg KH3.3-stable review patch. If anyone has any objections, please let me know.
------------------
From: Chris Wilson <[email protected]>
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
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=43012
--- drivers/gpu/drm/i915/i915_reg.h | 1 + drivers/gpu/drm/i915/intel_display.c | 6 ++++++ 2 files changed, 7 insertions(+)
drivers/gpu/drm/i915/i915_reg.h +1 -0
@@ -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)
drivers/gpu/drm/i915/intel_display.c +6 -0
@@ -7497,6 +7497,12 @@ static void intel_sanitize_modesetting(sstruct 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 ;
Greg KH
maintainerPATCH 37/78 drm/i915: Add lock on drm_helper_resume_force_mode
In reply to Greg KH3.3-stable review patch. If anyone has any objections, please let me know.
------------------
From: Sean Paul <[email protected]>
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.
--- drivers/gpu/drm/i915/i915_drv.c | 2 ++ 1 file changed, 2 insertions(+)
drivers/gpu/drm/i915/i915_drv.c +2 -0
@@ -508,7 +508,9 @@ static int i915_drm_thaw(struct drm_devidrm_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);
Greg KH
maintainerPATCH 38/78 drm/i915: quirk away broken OpRegion VBT
In reply to Greg KH3.3-stable review patch. If anyone has any objections, please let me know.
------------------
From: Daniel Vetter <[email protected]>
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.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=28812
--- drivers/gpu/drm/i915/intel_bios.c | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-)
drivers/gpu/drm/i915/intel_bios.c +22 -1
@@ -24,6 +24,7 @@* Eric Anholt <[email protected]> * */ +#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",
Greg KH
maintainerPATCH 39/78 firmware_class: Rework usermodehelper check
In reply to Greg KH3.3-stable review patch. If anyone has any objections, please let me know.
------------------
From: "Rafael J. Wysocki" <[email protected]>
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.
--- drivers/base/firmware_class.c | 11 +++++------ include/linux/kmod.h | 5 ++--- kernel/kmod.c | 24 +++++++++++------------- 3 files changed, 18 insertions(+), 22 deletions(-)
drivers/base/firmware_class.c +5 -6
@@ -533,12 +533,10 @@ static int _request_firmware(const strucreturn 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 strucfw_destroy_instance (fw_priv); out: -read_unlock_usermodehelper (); +usermodehelper_read_unlock (); +out_nolock:if (retval) {release_firmware (firmware); *firmware_p =NULL ;
include/linux/kmod.h +2 -3
@@ -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__ */
kernel/kmod.c +11 -13
@@ -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);
Greg KH
maintainerPATCH 40/78 firmware_class: Split _request_firmware() into three functions, v2
In reply to Greg KH3.3-stable review patch. If anyone has any objections, please let me know.
------------------
From: "Rafael J. Wysocki" <[email protected]>
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.
--- drivers/base/firmware_class.c | 58 +++++++++++++++++++++++++++++------------- 1 file changed, 41 insertions(+), 17 deletions(-)
drivers/base/firmware_class.c +41 -17
@@ -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 fdevice_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 strucreturn 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(voreturn 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);
Greg KH
maintainerPATCH 41/78 firmware_class: Do not warn that system is not ready from async loads
In reply to Greg KH3.3-stable review patch. If anyone has any objections, please let me know.
------------------
From: "Rafael J. Wysocki" <[email protected]>
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().
--- drivers/base/firmware_class.c | 51 +++++++++++++++++++++--------------- include/linux/kmod.h | 1 kernel/kmod.c | 58 ++++++++++++++++++++++++++++++++---------- 3 files changed, 76 insertions(+), 34 deletions(-)
drivers/base/firmware_class.c +30 -21
@@ -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(costatic 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 strucmutex_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(voif (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);
include/linux/kmod.h +1 -0
@@ -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__ */
kernel/kmod.c +45 -13
85 lines not on this page · raw message
Greg KH
maintainerPATCH 42/78 PM / Runtime: dont forget to wake up waitqueue on failure
In reply to Greg KH3.3-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alan Stern <[email protected]>
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.
--- drivers/base/power/runtime.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
drivers/base/power/runtime.c +2 -1
@@ -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; }
Re: [ 42/78] PM / Runtime: dont forget to wake up waitqueue on failure
Quoted 15 lines · Greg KH
3.3-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alan Stern <[email protected]>
commit
f2791d733a2f06997b573d1a3cfde21e6f529826upstream.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).
Quoted 2 lines
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.
Signature · 2 lines
Ben Hutchings It is easier to change the specification to fit the program than vice versa.
From 3853eee3a7aae2eda1bb8f9f0c9b8226cbba4bfb Mon Sep 17 00:00:00 2001
From: Alan Stern <[email protected]>
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.
--- drivers/base/power/runtime.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
drivers/base/power/runtime.c +2 -1
@@ -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:
Signature · 1 line
1.7.9.5
Greg KH
maintainerPATCH 43/78 PM / Hibernate: Disable usermode helpers right before freezing tasks
In reply to Greg KH3.3-stable review patch. If anyone has any objections, please let me know.
------------------
From: "Rafael J. Wysocki" <[email protected]>
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.
--- kernel/power/hibernate.c | 23 ++++++++++------------- 1 file changed, 10 insertions(+), 13 deletions(-)
kernel/power/hibernate.c +10 -13
@@ -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 ();
Greg KH
maintainerPATCH 44/78 PM / Sleep: Move disabling of usermode helpers to the freezer
In reply to Greg KH3.3-stable review patch. If anyone has any objections, please let me know.
------------------
From: "Rafael J. Wysocki" <[email protected]>
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.
--- 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(-)
kernel/power/hibernate.c +0 -11
@@ -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 );
kernel/power/process.c +7 -0
@@ -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" ); }
kernel/power/suspend.c +0 -7
@@ -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_ststatic void suspend_finish (void ) {suspend_thaw_processes (); -usermodehelper_enable ();pm_notifier_call_chain (PM_POST_SUSPEND );pm_restore_console (); }
kernel/power/user.c +1 -9
@@ -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 ;
Greg KH
maintainerPATCH 45/78 PM / Sleep: Mitigate race between the freezer and request_firmware()
In reply to Greg KH3.3-stable review patch. If anyone has any objections, please let me know.
------------------
From: "Rafael J. Wysocki" <[email protected]>
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.]
--- include/linux/kmod.h | 21 +++++++++++++++++++-- kernel/kmod.c | 47 +++++++++++++++++++++++++++++++++++++---------- kernel/power/process.c | 3 ++- 3 files changed, 58 insertions(+), 13 deletions(-)
include/linux/kmod.h +19 -2
@@ -112,10 +112,27 @@ call_usermodehelper(char *path, char **aextern 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 );
kernel/kmod.c +37 -10
89 lines not on this page · raw message
kernel/power/process.c +2 -1
@@ -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" );
Greg KH
maintainerPATCH 46/78 kgdb,debug_core: pass the breakpoint struct instead of address and memory
In reply to Greg KH3.3-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jason Wessel <[email protected]>
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.
--- include/linux/kgdb.h | 4 +-- kernel/debug/debug_core.c | 53 ++++++++++++++++++++-------------------------- 2 files changed, 26 insertions(+), 31 deletions(-)
include/linux/kgdb.h +2 -2
@@ -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.
kernel/debug/debug_core.c +24 -29
125 lines not on this page · raw message
Greg KH
maintainerPATCH 47/78 kgdbts: Fix kernel oops with CONFIG_DEBUG_RODATA
In reply to Greg KH3.3-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jason Wessel <[email protected]>
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.
--- drivers/misc/kgdbts.c | 52 ++++++++++++++++++++++++++------------------------ 1 file changed, 28 insertions(+), 24 deletions(-)
drivers/misc/kgdbts.c +28 -24
@@ -885,6 +885,22 @@ static void run_singlestep_break_test(vokgdbts_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.
Greg KH
maintainerPATCH 48/78 kgdbts: (1 of 2) fix single step awareness to work correctly with SMP
In reply to Greg KH3.3-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jason Wessel <[email protected]>
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
--- drivers/misc/kgdbts.c | 54 +++++++++++++++++++++++++++++++++++++++----------- 1 file changed, 43 insertions(+), 11 deletions(-)
drivers/misc/kgdbts.c +43 -11
@@ -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 *aif (!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_sgdb_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, charstatic 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_brestatic 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 */
Greg KH
maintainerPATCH 49/78 kgdbts: (2 of 2) fix single step awareness to work correctly with SMP
In reply to Greg KH3.3-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jason Wessel <[email protected]>
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.
--- drivers/misc/kgdbts.c | 73 ++++++++++++++++++++++++++++++++++++++++++-------- 1 file changed, 62 insertions(+), 11 deletions(-)
drivers/misc/kgdbts.c +62 -11
@@ -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 *putif (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 *putstatic 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_sv2printk ("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, charreturn 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 ;
Greg KH
maintainerPATCH 50/78 x86,kgdb: Fix DEBUG_RODATA limitation using text_poke()
In reply to Greg KH3.3-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jason Wessel <[email protected]>
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.
--- arch/x86/kernel/kgdb.c | 60 +++++++++++++++++++++++++++++++++++++++++++++++++ drivers/misc/kgdbts.c | 17 ------------- include/linux/kgdb.h | 3 +- 3 files changed, 62 insertions(+), 18 deletions(-)
arch/x86/kernel/kgdb.c +60 -0
@@ -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 },
drivers/misc/kgdbts.c +0 -17
@@ -968,22 +968,6 @@ static void run_singlestep_break_test(vokgdbts_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" );
include/linux/kgdb.h +2 -1
@@ -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 {
Greg KH
maintainerPATCH 51/78 CIFS: Fix VFS lock usage for oplocked files
In reply to Greg KH3.3-stable review patch. If anyone has any objections, please let me know.
------------------
From: Pavel Shilovsky <[email protected]>
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.
--- fs/cifs/file.c | 10 +++++++++- fs/locks.c | 3 ++- include/linux/fs.h | 5 +++++ 3 files changed, 16 insertions(+), 2 deletions(-)
fs/cifs/file.c +9 -1
@@ -835,13 +835,21 @@ cifs_posix_lock_set(struct file *file, sif ((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; }
fs/locks.c +2 -1
@@ -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
include/linux/fs.h +5 -0
@@ -1210,6 +1210,7 @@ extern int vfs_setlease(struct file *, lextern 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(structreturn 1 ; } +static inline void locks_delete_block (struct file_lock *waiter) +{ +} +static inline void lock_flocks (void ) { }
Greg KH
maintainerPATCH 52/78 USB: ohci-at91: fix vbus_pin_active_low handling
In reply to Greg KH3.3-stable review patch. If anyone has any objections, please let me know.
------------------
From: Nicolas Ferre <[email protected]>
commit 1e7caf8bcf1b49eae152ad7cf442775472dd587c upstream.
The information is not properly taken into account for {get|set}_power() functions.
--- drivers/usb/host/ohci-at91.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/usb/host/ohci-at91.c +2 -2
@@ -245,7 +245,7 @@ static void ohci_at91_usb_set_power(strureturn ;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(strucreturn -EINVAL ;return gpio_get_value (pdata->vbus_pin[port]) ^ - !pdata->vbus_pin_active_low[port]; + pdata->vbus_pin_active_low[port]; }/*
Greg KH
maintainerPATCH 53/78 ARM: at91/USB host: specify and handle properly vbus_pin_active_low
In reply to Greg KH3.3-stable review patch. If anyone has any objections, please let me know.
------------------
From: Nicolas Ferre <[email protected]>
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.
--- 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(-)
arch/arm/mach-at91/at91sam9263_devices.c +2 -1
@@ -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 */
arch/arm/mach-at91/at91sam9g45_devices.c +4 -2
@@ -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;
arch/arm/mach-at91/board-sam9263ek.c +1 -0
@@ -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 }, };
arch/arm/mach-at91/board-sam9m10g45ek.c +1 -0
@@ -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 }, };
Greg KH
maintainerPATCH 54/78 mmc: sdio: Use empty system suspend/resume callbacks at the bus level
In reply to Greg KH3.3-stable review patch. If anyone has any objections, please let me know.
------------------
From: "Rafael J. Wysocki" <[email protected]>
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.
--- drivers/mmc/core/sdio_bus.c | 12 +++++++++--- 1 file changed, 9 insertions(+), 3 deletions(-)
drivers/mmc/core/sdio_bus.c +9 -3
@@ -192,9 +192,15 @@ static int sdio_bus_remove(struct devicereturn 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" ,
Greg KH
maintainerPATCH 55/78 mmc: sdhci-dove: Fix compile error by including module.h
In reply to Greg KH3.3-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alf Høgemark <[email protected]>
commit 8c2fc8e413ecc2c96b696e28d4eb1bc6cee8dc84 upstream.
This patch fixes a compile error in drivers/mmc/host/sdhci-dove.c by including the linux/module.h file.
--- drivers/mmc/host/sdhci-dove.c | 1 + 1 file changed, 1 insertion(+)
drivers/mmc/host/sdhci-dove.c +1 -0
@@ -20,6 +20,7 @@*/ #include <linux/io.h> +#include <linux/module.h> #include <linux/mmc/host.h> #include "sdhci-pltfm.h"
Greg KH
maintainerPATCH 56/78 mmc: atmel-mci: correct data timeout computation
In reply to Greg KH3.3-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ludovic Desroches <[email protected]>
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.
--- drivers/mmc/host/atmel-mci.c | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-)
drivers/mmc/host/atmel-mci.c +8 -1
@@ -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,
Greg KH
maintainerPATCH 57/78 tcm_fc: Add abort flag for gracefully handling exchange timeout
In reply to Greg KH3.3-stable review patch. If anyone has any objections, please let me know.
------------------
From: Mark Rustad <[email protected]>
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)
--- 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(-)
drivers/target/tcm_fc/tcm_fc.h +1 -0
@@ -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 */ };
drivers/target/tcm_fc/tfc_cmd.c +8 -2
@@ -126,6 +126,8 @@ int ft_queue_status(struct se_cmd *se_cmstruct 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_cft_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 *sstruct 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_cstruct 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 ;
drivers/target/tcm_fc/tfc_io.c +2 -0
@@ -81,6 +81,8 @@ int ft_queue_data_in(struct se_cmd *se_cvoid *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);
Greg KH
maintainerPATCH 58/78 tcm_fc: Do not free tpg structure during wq allocation failure
In reply to Greg KH3.3-stable review patch. If anyone has any objections, please let me know.
------------------
From: Mark Rustad <[email protected]>
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.
--- drivers/target/tcm_fc/tfc_conf.c | 13 ++++++++----- 1 file changed, 8 insertions(+), 5 deletions(-)
drivers/target/tcm_fc/tfc_conf.c +8 -5
@@ -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);
Greg KH
maintainerPATCH 59/78 sysctl: fix write access to dmesg_restrict/kptr_restrict
In reply to Greg KH3.3-stable review patch. If anyone has any objections, please let me know.
------------------
From: Kees Cook <[email protected]>
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.
--- kernel/sysctl.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-)
kernel/sysctl.c +4 -4
@@ -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 ))
Greg KH
maintainerPATCH 60/78 regmap: prevent division by zero in rbtree_show
In reply to Greg KH3.3-stable review patch. If anyone has any objections, please let me know.
------------------
From: Stephen Warren <[email protected]>
commit c04c1b9ee8f30c7a3a25e20e406247003f634ebe upstream.
If there are no nodes in the cache, nodes will be 0, so calculating "registers / nodes" will cause division by zero.
--- drivers/base/regmap/regcache-rbtree.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-)
drivers/base/regmap/regcache-rbtree.c +7 -1
@@ -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);
Greg KH
maintainerPATCH 61/78 modpost: Fix modpost license checking of vmlinux.o
In reply to Greg KH3.3-stable review patch. If anyone has any objections, please let me know.
------------------
From: Frank Rowand <[email protected]>
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. ]
--- scripts/mod/modpost.c | 7 +++++-- scripts/mod/modpost.h | 1 + 2 files changed, 6 insertions(+), 2 deletions(-)
scripts/mod/modpost.c +5 -2
@@ -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 mounsigned 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));
scripts/mod/modpost.h +1 -0
@@ -113,6 +113,7 @@ struct module {int has_cleanup;struct buffer dev_table_buf;char srcversion[25 ]; +int is_dot_o; };struct elf_info {
Greg KH
maintainerPATCH 62/78 mfd: Fix section mismatch warning for da9052-spi
In reply to Greg KH3.3-stable review patch. If anyone has any objections, please let me know.
------------------
From: Axel Lin <[email protected]>
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.
--- drivers/mfd/da9052-spi.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/mfd/da9052-spi.c +2 -2
@@ -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);
Greg KH
maintainerPATCH 63/78 android, lowmemorykiller: remove task handoff notifier
In reply to Greg KH3.3-stable review patch. If anyone has any objections, please let me know.
------------------
From: David Rientjes <[email protected]>
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.
--- drivers/staging/android/lowmemorykiller.c | 47 +++--------------------------- 1 file changed, 6 insertions(+), 41 deletions(-)
drivers/staging/android/lowmemorykiller.c +6 -41
@@ -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_deathpendingprintk (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 shrinkerint 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 shrinkerstruct 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 shrinkerlowmem_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 );
Greg KH
maintainerPATCH 64/78 TOMOYO: Fix mount flags checking order.
In reply to Greg KH3.3-stable review patch. If anyone has any objections, please let me know.
------------------
From: Tetsuo Handa <[email protected]>
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.
--- security/tomoyo/mount.c | 38 ++++++++++++++++++++------------------ 1 file changed, 20 insertions(+), 18 deletions(-)
security/tomoyo/mount.c +20 -18
@@ -199,30 +199,32 @@ int tomoyo_mount_permission(char *dev_naif (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>" ;
Greg KH
maintainerPATCH 65/78 iwlegacy: do not nulify il->vif on reset
In reply to Greg KH3.3-stable review patch. If anyone has any objections, please let me know.
------------------
From: Stanislaw Gruszka <[email protected]>
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.
--- 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(-)
drivers/net/wireless/iwlegacy/3945-mac.c +0 -1
@@ -2684,7 +2684,6 @@ il3945_bg_restart(struct work_struct *daif (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);
drivers/net/wireless/iwlegacy/4965-mac.c +0 -1
@@ -5381,7 +5381,6 @@ il4965_bg_restart(struct work_struct *daif (test_and_clear_bit (S_FW_ERROR , &il->status)) {mutex_lock (&il->mutex); - il->ctx.vif =NULL ; il->is_open =0 ;__il4965_down (il);
drivers/net/wireless/iwlegacy/common.c +16 -2
@@ -4575,6 +4575,7 @@ il_mac_add_interface(struct ieee80211_hwstruct 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:
Greg KH
maintainerPATCH 66/78 Revert "x86/ioapic: Add register level checks to detect bogus io-apic entries"
In reply to Greg KH3.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.
--- arch/x86/kernel/apic/io_apic.c | 40 ++++++++-------------------------------- 1 file changed, 8 insertions(+), 32 deletions(-)
arch/x86/kernel/apic/io_apic.c +8 -32
@@ -3967,36 +3967,18 @@ int mp_find_ioapic_pin(int ioapic, u32 gstatic __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, uif (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++; }
Greg KH
maintainerPATCH 67/78 acer-wmi: No wifi rfkill on Sony machines
In reply to Greg KH3.3-stable review patch. If anyone has any objections, please let me know.
------------------
From: "Lee, Chun-Yi" <[email protected]>
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
--- drivers/platform/x86/acer-wmi.c | 1 + 1 file changed, 1 insertion(+)
drivers/platform/x86/acer-wmi.c +1 -0
@@ -692,6 +692,7 @@ static const struct acpi_device_id norfk { "VPC2004", 0}, { "IBM0068", 0}, { "LEN0068", 0}, + { "SNY5001", 0}, /* sony-laptop in charge */ { "", 0}, };
Greg KH
maintainerPATCH 68/78 Fix length of buffer copied in __nfs4_get_acl_uncached
In reply to Greg KH3.3-stable review patch. If anyone has any objections, please let me know.
------------------
From: Sachin Prabhu <[email protected]>
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.
--- fs/nfs/nfs4proc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
fs/nfs/nfs4proc.c +1 -1
@@ -3625,7 +3625,7 @@ static ssize_t __nfs4_get_acl_uncached(sif (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:
Greg KH
maintainerPATCH 69/78 sched/x86: Fix overflow in cyc2ns_offset
In reply to Greg KH3.3-stable review patch. If anyone has any objections, please let me know.
------------------
From: Salman Qazi <[email protected]>
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().
--- 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(-)
arch/x86/include/asm/timer.h +2 -6
@@ -57,14 +57,10 @@ DECLARE_PER_CPU(unsigned long long, cyc2static 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; }
arch/x86/kernel/tsc.c +2 -1
@@ -620,7 +620,8 @@ static void set_cyc2ns_scale(unsigned loif (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 );
include/linux/kernel.h +13 -0
@@ -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; })
Greg KH
maintainerPATCH 70/78 mfd: Clear twl6030 IRQ status register only once
In reply to Greg KH3.3-stable review patch. If anyone has any objections, please let me know.
------------------
From: Nishanth Menon <[email protected]>
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.
--- drivers/mfd/twl6030-irq.c | 13 +++++++++++-- 1 file changed, 11 insertions(+), 2 deletions(-)
drivers/mfd/twl6030-irq.c +11 -2
@@ -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" );
Greg KH
maintainerPATCH 71/78 USB: Add Motorola Rokr E6 Id to the USBNet driver "zaurus"
In reply to Greg KH3.3-stable review patch. If anyone has any objections, please let me know.
------------------
From: Guan Xin <[email protected]>
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.
--- drivers/net/usb/zaurus.c | 5 +++++ 1 file changed, 5 insertions(+)
drivers/net/usb/zaurus.c +5 -0
@@ -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),
Greg KH
maintainerPATCH 72/78 ioat: fix size of completion for Xen
In reply to Greg KH3.3-stable review patch. If anyone has any objections, please let me know.
------------------
From: Dan Williams <[email protected]>
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.
--- 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(-)
drivers/dma/ioat/dma.c +8 -8
@@ -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_creturn 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_chstatic 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 lmod_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
drivers/dma/ioat/dma.h +3 -3
@@ -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(strucvoid 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;
drivers/dma/ioat/dma_v2.c +4 -4
@@ -126,7 +126,7 @@ static void ioat2_start_null_desc(structspin_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_cstatic 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_costatic 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 datstruct 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);
drivers/dma/ioat/dma_v3.c +4 -4
@@ -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_cstatic 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(unsignedstatic 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 lstruct 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);
Greg KH
maintainerPATCH 73/78 uvcvideo: Fix race-related crash in uvc_video_clock_update()
In reply to Greg KH3.3-stable review patch. If anyone has any objections, please let me know.
------------------
From: Laurent Pinchart <[email protected]>
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.
--- drivers/media/video/uvc/uvc_video.c | 50 +++++++++++++++++++++++------------- 1 file changed, 32 insertions(+), 18 deletions(-)
drivers/media/video/uvc/uvc_video.c +32 -18
@@ -468,22 +468,30 @@ uvc_video_clock_decode(struct uvc_streamspin_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_struvc_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_streaminuvc_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; }
Greg KH
maintainerPATCH 74/78 ASoC: ak4642: fixup: mute needs +1 step
In reply to Greg KH3.3-stable review patch. If anyone has any objections, please let me know.
------------------
From: Kuninori Morimoto <[email protected]>
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
--- sound/soc/codecs/ak4642.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
sound/soc/codecs/ak4642.c +1 -1
@@ -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[] = {
Greg KH
maintainerPATCH 75/78 ASoC: tegra: fix i2s compilation when !CONFIG_DEBUG_FS
In reply to Greg KH3.3-stable review patch. If anyone has any objections, please let me know.
------------------
From: Stephen Warren <[email protected]>
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.
--- sound/soc/tegra/tegra_i2s.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
sound/soc/tegra/tegra_i2s.c +1 -1
@@ -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) { }
Greg KH
maintainerPATCH 76/78 media: dvb_frontend: regression fix: userspace ABI broken for xine
In reply to Greg KH3.3-stable review patch. If anyone has any objections, please let me know.
------------------
From: Chris Rankin <[email protected]>
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.
--- drivers/media/dvb/dvb-core/dvb_frontend.c | 10 ++++++++++ 1 file changed, 10 insertions(+)
drivers/media/dvb/dvb-core/dvb_frontend.c +10 -0
@@ -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_freturn -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
Greg KH
maintainerPATCH 77/78 media: dvb-core: fix DVBFE_ALGO_HW retune bug
In reply to Greg KH3.3-stable review patch. If anyone has any objections, please let me know.
------------------
From: Simon Arlott <[email protected]>
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
--- drivers/media/dvb/dvb-core/dvb_frontend.c | 2 ++ 1 file changed, 2 insertions(+)
drivers/media/dvb/dvb-core/dvb_frontend.c +2 -0
@@ -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)
Greg KH
maintainerPATCH 78/78 cred: copy_process() should clear child->replacement_session_keyring
In reply to Greg KH3.3-stable review patch. If anyone has any objections, please let me know.
------------------
From: Oleg Nesterov <[email protected]>
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.
--- kernel/cred.c | 2 ++ 1 file changed, 2 insertions(+)
kernel/cred.c +2 -0
@@ -385,6 +385,8 @@ int copy_creds(struct task_struct *p, unstruct cred *new;int ret; + p->replacement_session_keyring =NULL ; + if (#ifdef CONFIG_KEYS !p->cred->thread_keyring &&
Hello Greg,
Quoted 8 lines · 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.
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
Quoted 112 lines
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/
Greg KH
maintainerQuoted 9 lines · Sergio Correia
Hello Greg,
Quoted 5 lines · 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.
Quoted 7 lines
Quoted 3 lines
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?
Have you read Documentation/stable_kernel_rules.txt? Based on that, I don't think it can, yet, right?
thanks,
greg k-h
Quoted 14 lines · Greg KH
Quoted 13 lines · Sergio Correia
Hello Greg,
Quoted 8 lines · 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.
Quoted 7 lines
Quoted 3 lines
is there any chance for this one to be included in this review cycle?
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
Quoted 3 lines
thanks,
greg k-h
Quoted 10 lines · Greg KH
Quoted 9 lines · Sergio Correia
Hello Greg,
Quoted 5 lines · 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.
Quoted 7 lines
Quoted 7 lines
Quoted 3 lines
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?
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.
Quoted 2 lines
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.
Signature · 1 line
Felipe Contreras
Greg KH
maintainerQuoted 23 lines · Felipe Contreras
Quoted 10 lines · Greg KH
Quoted 9 lines · Sergio Correia
Hello Greg,
Quoted 5 lines · 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.
Quoted 7 lines
Quoted 7 lines
Quoted 3 lines
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?
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.
Quoted 6 lines
Quoted 2 lines
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.
Quoted 3 lines
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
Quoted 27 lines · Greg KH
Quoted 26 lines · Felipe Contreras
Quoted 10 lines · Greg KH
Quoted 9 lines · Sergio Correia
Hello Greg,
Quoted 5 lines · 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.
Quoted 7 lines
Quoted 7 lines
Quoted 3 lines
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?
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.
Quoted 2 lines
Have you read
Documentation/stable_kernel_rules.txt? ?Based on that, I don't think it can, yet, right?
Quoted 6 lines
Quoted 3 lines
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^.
Quoted 5 lines
Quoted 3 lines
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?
Signature · 1 line
Felipe Contreras
Greg KH
maintainerQuoted 44 lines · Felipe Contreras
Quoted 27 lines · Greg KH
Quoted 26 lines · Felipe Contreras
Quoted 10 lines · Greg KH
Quoted 9 lines · Sergio Correia
Hello Greg,
Quoted 5 lines · 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.
Quoted 7 lines
Quoted 7 lines
Quoted 3 lines
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?
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.
Quoted 2 lines
Have you read
Documentation/stable_kernel_rules.txt? ?Based on that, I don't think it can, yet, right?Quoted 6 lines
Quoted 3 lines
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^.Quoted 5 lines
Quoted 3 lines
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?
Quoted 7 lines
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
Quoted 47 lines · Greg KH
Quoted 46 lines · Felipe Contreras
Quoted 27 lines · Greg KH
Quoted 26 lines · Felipe Contreras
Quoted 10 lines · Greg KH
Quoted 9 lines · Sergio Correia
Hello Greg,
Quoted 5 lines · 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.
Quoted 7 lines
Quoted 7 lines
Quoted 3 lines
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?
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.
Quoted 2 lines
Have you read
Documentation/stable_kernel_rules.txt? ?Based on that, I don't think it can, yet, right?Quoted 6 lines
Quoted 3 lines
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^.Quoted 5 lines
Quoted 3 lines
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.
Quoted 8 lines
Quoted 5 lines
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.
Signature · 1 line
Felipe Contreras
Quoted 6 lines · Felipe Contreras
Quoted 3 lines
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.
Quoted 7 lines
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
Quoted 21 lines · Adrian Chadd
Quoted 6 lines · Felipe Contreras
Quoted 3 lines
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.
Quoted 7 lines
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."
Quoted 4 lines
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.
Quoted 6 lines
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.
Quoted 2 lines
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.
Signature · 1 line
Felipe Contreras
Quoted 3 lines · Felipe Contreras
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
Quoted 6 lines · Jonathan Nieder
Quoted 3 lines · Felipe Contreras
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.
Quoted 8 lines
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.
Signature · 1 line
Felipe Contreras
Quoted 5 lines · Felipe Contreras
Now what happens when:
- you realize the fix made matters worst, in fact, so worst that the
whole thing is unusable in some systems
Quoted 8 lines
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
Greg KH
maintainerQuoted 22 lines · Felipe Contreras
Quoted 21 lines · Adrian Chadd
Quoted 6 lines · Felipe Contreras
Quoted 3 lines
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.
Quoted 7 lines
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."
Quoted 8 lines
Quoted 4 lines
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
Quoted 28 lines · Greg KH
Quoted 27 lines · Felipe Contreras
Quoted 25 lines · Adrian Chadd
Quoted 6 lines · Felipe Contreras
Quoted 3 lines
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.
Quoted 7 lines
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.
Quoted 7 lines
Quoted 3 lines
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
Signature · 2 lines
Three may keep a secret, if two of them are dead. - Ben F.
Quoted 3 lines · 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.
Signature · 3 lines
Stefan Richter -=====-===-- -=-- -==-= http://arcgraph.de/sr/
Quoted 6 lines · Stefan Richter
Quoted 3 lines · 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.
Quoted 5 lines
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.
Quoted 2 lines
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.
Signature · 1 line
Felipe Contreras
Quoted 10 lines · On Apr 13 Felipe Contreras wrote:
Quoted 6 lines · Stefan Richter
Quoted 3 lines · 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.
Quoted 4 lines
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.
Quoted 9 lines
Quoted 5 lines
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.
Quoted 2 lines
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.
Quoted 1 line
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.
Quoted 5 lines
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.
Signature · 3 lines
Stefan Richter -=====-===-- -=-- -==-= http://arcgraph.de/sr/
Quoted 9 lines · 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.
Quoted 5 lines
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.)
Signature · 3 lines
Stefan Richter -=====-===-- -=-- -==-= http://arcgraph.de/sr/
Quoted 7 lines · Stefan Richter
Quoted 6 lines · On Apr 13 Felipe Contreras wrote:
Quoted 4 lines · Stefan Richter
Quoted 3 lines · 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.
Quoted 7 lines
Quoted 4 lines
Quoted 2 lines
? ? ? ? ? ?^^^^^
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.
Quoted 7 lines
?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.
Quoted 5 lines
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.
Quoted 11 lines
Quoted 4 lines
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.
Quoted 2 lines
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.
Quoted 2 lines
The reasons for the
Linus->Gregorder of maintaining the stable series 100% apply to fixes for type A regressions as well.
Why? Because it does. IOW; dogma.
Quoted 5 lines
Quoted 5 lines
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)
Quoted 7 lines
[...]
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).
Quoted 10 lines
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.
Quoted 3 lines
Quoted 3 lines
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.
Signature · 1 line
Felipe Contreras
Quoted 7 lines · Felipe Contreras
Quoted 2 lines · Stefan Richter
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
Quoted 11 lines · Jonathan Nieder
Quoted 7 lines · Felipe Contreras
Quoted 2 lines · Stefan Richter
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.
Quoted 8 lines
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.
Signature · 1 line
Felipe Contreras
Quoted 10 lines · Felipe Contreras
Quoted 9 lines · Jonathan Nieder
Quoted 7 lines · Felipe Contreras
Quoted 2 lines · Stefan Richter
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.
Quoted 7 lines
Quoted 2 lines
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.
Quoted 4 lines
Quoted 4 lines
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.
Quoted 7 lines
Quoted 3 lines
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.
Quoted 5 lines
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
Quoted 4 lines · Willy Tarreau
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.
Quoted 2 lines
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.
Quoted 7 lines
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.
Signature · 1 line
Felipe Contreras
Quoted 10 lines · Felipe Contreras
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
Quoted 6 lines · On Apr 14 Felipe Contreras wrote:
Quoted 5 lines · Jonathan Nieder
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.
Quoted 8 lines
Quoted 3 lines
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.
Quoted 2 lines
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.
Signature · 3 lines
Stefan Richter -=====-===-- -=-- -===- http://arcgraph.de/sr/
Quoted 8 lines · Stefan Richter
Quoted 3 lines · 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"?
Signature · 1 line
Felipe Contreras
Quoted 8 lines · On Apr 14 Felipe Contreras wrote:
Quoted 6 lines · Stefan Richter
Quoted 3 lines · 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'."
Quoted 5 lines
Quoted 2 lines
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.
Quoted 3 lines
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.
Signature · 3 lines
Stefan Richter -=====-===-- -=-- -===- http://arcgraph.de/sr/
Quoted 10 lines · 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]
Quoted 2 lines
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.
Quoted 1 line
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.
Signature · 3 lines
Stefan Richter -=====-===-- -=-- -===- http://arcgraph.de/sr/
Quoted 12 lines · Stefan Richter
Quoted 10 lines · 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?
Quoted 8 lines
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.
Quoted 2 lines
(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.
Quoted 11 lines
[quote re-ordered]
Quoted 2 lines
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.
Quoted 11 lines
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.
Quoted 5 lines
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.
Quoted 10 lines
"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->Gregorder 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.
Quoted 3 lines
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.
Signature · 1 line
Felipe Contreras
Quoted 4 lines · Felipe Contreras
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.
Quoted 1 line
Again, what makes a released patch undroppable?
Being applied, in other words, having a commit ID in the branch.
(...)
Quoted 6 lines
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.
Quoted 4 lines
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 ?
Quoted 2 lines
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
Quoted 9 lines · Willy Tarreau
Quoted 4 lines · Felipe Contreras
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?
Quoted 3 lines
Quoted 1 line
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.
Signature · 1 line
Felipe Contreras
Quoted 9 lines · Felipe Contreras
Quoted 3 lines
Quoted 1 line
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
Quoted 16 lines · On Apr 14 Felipe Contreras wrote:
Quoted 14 lines · Stefan Richter
Quoted 10 lines · 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?
Quoted 8 lines
Quoted 6 lines
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.)
Quoted 4 lines
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.
Quoted 5 lines
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.
Quoted 1 line
"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.
[...]
Quoted 4 lines
Quoted 4 lines
"Drop a stable candidate before release" is a form of "decline a submission to stable", happening late in the preparations of a stable release.
Quoted 8 lines
Quoted 5 lines
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.
Quoted 9 lines
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.
Quoted 3 lines
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.
Quoted 3 lines
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.)
[...]
Quoted 2 lines
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.
Signature · 3 lines
Stefan Richter -=====-===-- -=-- -===- http://arcgraph.de/sr/
Quoted 26 lines · Stefan Richter
Quoted 16 lines · On Apr 14 Felipe Contreras wrote:
Quoted 14 lines · Stefan Richter
Quoted 10 lines · 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?
Quoted 8 lines
Quoted 6 lines
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.
Quoted 8 lines
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.
Quoted 7 lines
Quoted 4 lines
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.
Quoted 7 lines
Quoted 5 lines
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.
Quoted 7 lines
Quoted 1 line
"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.
Quoted 5 lines
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.
Quoted 4 lines
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.
Signature · 1 line
Felipe Contreras
Quoted 11 lines · On Apr 14 Felipe Contreras wrote:
Quoted 8 lines · Stefan Richter
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.)
Quoted 4 lines
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.
Quoted 3 lines
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.
Quoted 9 lines
Quoted 7 lines
Quoted 4 lines
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.
Quoted 2 lines
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.
Quoted 8 lines
Quoted 7 lines
Quoted 5 lines
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.
Quoted 8 lines
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.
[...]
Quoted 6 lines
Quoted 3 lines
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.
Quoted 1 line
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.
Quoted 2 lines
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.
[...]
Quoted 3 lines
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.
Quoted 1 line
that makes bad patches undroppable?
f) makes stable require a reverting patch.
Quoted 4 lines
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.
Signature · 3 lines
Stefan Richter -=====-===-- -=-- -===- http://arcgraph.de/sr/
Quoted 12 lines · Stefan Richter
Quoted 11 lines · On Apr 14 Felipe Contreras wrote:
Quoted 8 lines · Stefan Richter
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.)
Quoted 6 lines
Quoted 4 lines
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?
Quoted 10 lines
Quoted 3 lines
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.
Quoted 10 lines
Quoted 9 lines
Quoted 7 lines
Quoted 4 lines
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.
Quoted 8 lines
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.
Quoted 2 lines
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.
Signature · 1 line
Felipe Contreras
Quoted 1 line · 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.
Quoted 3 lines
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.
Signature · 3 lines
Stefan Richter -=====-===-- -=-- -==== http://arcgraph.de/sr/
Quoted 4 lines · Stefan Richter
Quoted 1 line · 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.
Quoted 5 lines
Quoted 3 lines
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.
Signature · 1 line
Felipe Contreras
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
Quoted 1 line · Felipe Contreras
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
Quoted 8 lines · Peter Stuge
Quoted 1 line · Felipe Contreras
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.
Signature · 1 line
Felipe Contreras
Quoted 1 line · Felipe Contreras
No, I don't want the latest fixes, I want the latest *stable* kernel.
You have it, it's 3.3.2.
Quoted 1 line
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.
Quoted 5 lines
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.
Quoted 3 lines
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.
Quoted 4 lines
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.
Quoted 7 lines
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
Greg KH
maintainerJust one minor correction in this looney email thread:
Quoted 6 lines · Felipe Contreras
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
Quoted 10 lines · Greg KH
Just one minor correction in this looney email thread:
Quoted 6 lines · Felipe Contreras
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.
Quoted 3 lines
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?
Signature · 1 line
Felipe Contreras
Greg KH
maintainerQuoted 11 lines · Felipe Contreras
Quoted 10 lines · Greg KH
Just one minor correction in this looney email thread:
Quoted 6 lines · Felipe Contreras
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.
Quoted 8 lines
Quoted 3 lines
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=tagsIf 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
Quoted 21 lines · Greg KH
Quoted 11 lines · Felipe Contreras
Quoted 10 lines · Greg KH
Just one minor correction in this looney email thread:
Quoted 6 lines · Felipe Contreras
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.
Quoted 8 lines
Quoted 3 lines
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=tagsIf you really want people to try it, why not tag it?
Quoted 8 lines
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.
Signature · 1 line
Felipe Contreras
Greg KH
maintainerQuoted 27 lines · Felipe Contreras
Quoted 26 lines · Greg KH
Quoted 11 lines · Felipe Contreras
Quoted 10 lines · Greg KH
Just one minor correction in this looney email thread:
Quoted 6 lines · Felipe Contreras
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.
Quoted 8 lines
Quoted 3 lines
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=tagsIf 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.
Quoted 6 lines
Quoted 3 lines
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:
Quoted 5 lines
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.
Quoted 2 lines
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
Quoted 28 lines · Greg KH
Quoted 27 lines · Felipe Contreras
Quoted 26 lines · Greg KH
Quoted 11 lines · Felipe Contreras
Quoted 10 lines · Greg KH
Just one minor correction in this looney email thread:
Quoted 6 lines · Felipe Contreras
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.
Quoted 8 lines
Quoted 3 lines
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=tagsIf 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.
Quoted 8 lines
Quoted 6 lines
Quoted 3 lines
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.
Quoted 10 lines
You point out:
Quoted 5 lines
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.
Quoted 8 lines
Quoted 2 lines
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.
Signature · 1 line
Felipe Contreras
Quoted 2 lines · Felipe Contreras
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
Quoted 10 lines · Felipe Contreras
Quoted 4 lines
Quoted 2 lines
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.
Quoted 6 lines
Quoted 6 lines
Quoted 5 lines
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.
Quoted 6 lines
Quoted 2 lines
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.
Quoted 9 lines
Quoted 8 lines
Quoted 2 lines
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.
Quoted 3 lines
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
Quoted 28 lines · Greg KH
Quoted 27 lines · Felipe Contreras
Quoted 26 lines · Greg KH
Quoted 11 lines · Felipe Contreras
Quoted 10 lines · Greg KH
Just one minor correction in this looney email thread:
Quoted 6 lines · Felipe Contreras
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.
Quoted 8 lines
Quoted 3 lines
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=tagsIf 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.
Quoted 8 lines
Quoted 6 lines
Quoted 3 lines
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.
Quoted 10 lines
You point out:
Quoted 5 lines
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.
Quoted 8 lines
Quoted 2 lines
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.
Signature · 1 line
Felipe Contreras
Quoted 68 lines · Felipe Contreras
Quoted 28 lines · Greg KH
Quoted 27 lines · Felipe Contreras
Quoted 26 lines · Greg KH
Quoted 11 lines · Felipe Contreras
Quoted 10 lines · Greg KH
Just one minor correction in this looney email thread:
Quoted 6 lines · Felipe Contreras
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.
Quoted 8 lines
Quoted 3 lines
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=tagsIf 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.
Quoted 8 lines
Quoted 6 lines
Quoted 3 lines
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.
Quoted 10 lines
You point out:
Quoted 5 lines
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.
Quoted 8 lines
Quoted 2 lines
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.
Quoted 3 lines
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
Quoted 10 lines
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.
Quoted 72 lines · Felipe Contreras
Quoted 28 lines · Greg KH
Quoted 27 lines · Felipe Contreras
Quoted 26 lines · Greg KH
Quoted 11 lines · Felipe Contreras
Quoted 10 lines · Greg KH
Just one minor correction in this looney email thread:
Quoted 6 lines · Felipe Contreras
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.
Quoted 8 lines
Quoted 3 lines
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=tagsIf 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.
Quoted 8 lines
Quoted 6 lines
Quoted 3 lines
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.
Quoted 10 lines
You point out:
Quoted 5 lines
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.
Quoted 8 lines
Quoted 2 lines
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.
Quoted 9 lines
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
Quoted 31 lines · Felipe Contreras
Quoted 21 lines · Greg KH
Quoted 11 lines · Felipe Contreras
Quoted 10 lines · Greg KH
Just one minor correction in this looney email thread:
Quoted 6 lines · Felipe Contreras
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.
Quoted 8 lines
Quoted 3 lines
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=tagsIf you really want people to try it, why not tag it?
Quoted 8 lines
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.)
Quoted 8 lines
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.
Quoted 2 lines
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?
Quoted 6 lines
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!
Quoted 10 lines · Felipe Contreras
Quoted 2 lines · Greg KH
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.
Quoted 5 lines
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
Quoted 5 lines · Felipe Contreras
Quoted 3 lines
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
Quoted 8 lines · Linus Torvalds
Quoted 5 lines · Felipe Contreras
Quoted 3 lines
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.
Quoted 7 lines
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.
Quoted 2 lines
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.
Quoted 2 lines
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.
Quoted 5 lines
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*.
Signature · 1 line
Felipe Contreras
Quoted 4 lines · Felipe Contreras
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
Quoted 3 lines · Linus Torvalds
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
Quoted 17 lines · Linus Torvalds
Quoted 3 lines · Linus Torvalds
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.
Quoted 1 line
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
Quoted 7 lines · Linus Torvalds
Quoted 4 lines · Felipe Contreras
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.
Quoted 8 lines
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.
Signature · 1 line
Felipe Contreras
Quoted 3 lines · Felipe Contreras
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
Quoted 8 lines · Linus Torvalds
Quoted 3 lines · Felipe Contreras
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.
Signature · 1 line
Felipe Contreras
Quoted 19 lines · Felipe Contreras
Quoted 9 lines · Linus Torvalds
Quoted 4 lines · Felipe Contreras
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.
Quoted 8 lines
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
Quoted 42 lines · Ingo Molnar
Quoted 19 lines · Felipe Contreras
Quoted 9 lines · Linus Torvalds
Quoted 4 lines · Felipe Contreras
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.
Quoted 8 lines
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.
Quoted 4 lines
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?
Signature · 1 line
Felipe Contreras
Quoted 48 lines · Felipe Contreras
Quoted 42 lines · Ingo Molnar
Quoted 19 lines · Felipe Contreras
Quoted 9 lines · Linus Torvalds
Quoted 4 lines · Felipe Contreras
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.
Quoted 8 lines
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.
Quoted 4 lines
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.
Quoted 4 lines
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:
Quoted 4 lines
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.
Quoted 2 lines
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
Quoted 10 lines · Ingo Molnar
Quoted 4 lines · Felipe Contreras
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
Quoted 1 line
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.
Quoted 5 lines
Quoted 2 lines
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?
Quoted 2 lines
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.
Quoted 3 lines
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*.
Quoted 3 lines
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.
Quoted 4 lines
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.
Quoted 3 lines
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.
Signature · 1 line
Felipe Contreras
Felipe,
On Sun, Apr 15, 2012 at 08:15:23PM +0300, Felipe Contreras wrote:
(...)
Quoted 2 lines
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.
Quoted 9 lines
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
Quoted 6 lines · Felipe Contreras
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
Quoted 8 lines · Linus Torvalds
Quoted 6 lines · Felipe Contreras
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
[...]
Quoted 1 line
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.
Quoted 10 lines
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
Signature · 1 line
Felipe Contreras
Quoted 8 lines · Felipe Contreras
Quoted 6 lines · Linus Torvalds
Quoted 4 lines · Felipe Contreras
This is not a reason, this is just stating what happens without explaining *why*.
Quoted 8 lines
Quoted 2 lines
Quoted 2 lines
Q: What changes when a tag is made?
A: A tag is made[...]
Quoted 1 line
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:
Quoted 2 lines
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
Quoted 8 lines · Ingo Molnar
Quoted 5 lines · Felipe Contreras
Quoted 1 line · Linus Torvalds
The only thing that matters is "it's been made available to others".
Quoted 7 lines
Quoted 1 line
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':
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.
Signature · 1 line
Felipe Contreras
Quoted 6 lines · Felipe Contreras
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.
Quoted 5 lines
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.
Quoted 4 lines
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
Quoted 5 lines · Felipe Contreras
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.
Quoted 1 line
b) v3.0* (bad), v3.1* (bad), v3.2* (bad), v3.3 (bad), v3.3.1 (good), v3.4 (bad)
Same here.
Quoted 7 lines
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.
Quoted 6 lines
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.
Quoted 2 lines
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.
Quoted 3 lines
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.
Quoted 3 lines
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.
Quoted 2 lines
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).
Quoted 4 lines
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
Quoted 8 lines · Willy Tarreau
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
David Miller
maintainerFrom: Felipe Contreras <[email protected]>
Date: Fri, 13 Apr 2012 01:04:42 +0300
Quoted 2 lines
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.
Quoted 8 lines · David Miller
From: Felipe Contreras <[email protected]>
Date: Fri, 13 Apr 2012 01:04:42 +0300Quoted 2 lines
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.
Quoted 4 lines
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.
Signature · 1 line
Felipe Contreras
Quoted 20 lines · Felipe Contreras
Quoted 8 lines · David Miller
From: Felipe Contreras <[email protected]>
Date: Fri, 13 Apr 2012 01:04:42 +0300Quoted 2 lines
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.
Quoted 6 lines
Quoted 4 lines
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
Quoted 34 lines · Willy Tarreau
Quoted 20 lines · Felipe Contreras
Quoted 8 lines · David Miller
From: Felipe Contreras <[email protected]>
Date: Fri, 13 Apr 2012 01:04:42 +0300Quoted 2 lines
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.
Quoted 6 lines
Quoted 4 lines
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.
Quoted 8 lines
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.
Quoted 9 lines
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.
Quoted 4 lines
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.
Quoted 5 lines
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.
Quoted 7 lines
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.
Signature · 1 line
Felipe Contreras
Quoted 4 lines · Felipe Contreras
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
Quoted 42 lines · Felipe Contreras
Quoted 8 lines · Linus Torvalds
Quoted 5 lines · Felipe Contreras
Quoted 3 lines
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.
Quoted 7 lines
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.
Quoted 2 lines
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.
Quoted 2 lines
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.
Quoted 10 lines
Quoted 5 lines
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.
Signature · 3 lines
Jesper Juhl <[email protected]> http://www.chaosbits.net/ Don't top-post http://www.catb.org/jargon/html/T/top-post.html Plain text mails only, please.
Hello,
Am 12.04.2012 02:29, schrieb Greg KH:
Quoted 6 lines
Quoted 3 lines
is there any chance for this one to be included in this review cycle?
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
Greg KH
maintainerQuoted 11 lines · Alexander Holler
Hello,
Am 12.04.2012 02:29, schrieb Greg KH:
Quoted 6 lines
Quoted 3 lines
is there any chance for this one to be included in this review cycle?
Have you read
Documentation/stable_kernel_rules.txt? Based on that, I don't think it can, yet, right?
Quoted 6 lines
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
Am 12.04.2012 22:06, schrieb Greg KH:
Quoted 16 lines · Alexander Holler
Quoted 15 lines
Hello,
Am 12.04.2012 02:29, schrieb Greg KH:
Quoted 6 lines
Quoted 3 lines
is there any chance for this one to be included in this review cycle?
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).
Quoted 6 lines
Quoted 2 lines
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
Greg KH
maintainerQuoted 26 lines · Alexander Holler
Am 12.04.2012 22:06, schrieb Greg KH:
Quoted 16 lines · Alexander Holler
Quoted 15 lines
Hello,
Am 12.04.2012 02:29, schrieb Greg KH:
Quoted 6 lines
Quoted 3 lines
is there any chance for this one to be included in this review cycle?
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).
Quoted 6 lines
Quoted 2 lines
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:
Quoted 8 lines
"- 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
Quoted 3 lines · Sergio Correia
is there any chance for this one to be included in this review cycle?
Thanks for pointing this out! This patch fixes my network problems which forced me to go back to a previous kernel.