2.6.25.6 -stable review
Subsystems (37)
cover 2.6.25.6 -stable review
This is the start of the stable review cycle for the 2.6.25.6 release. There are 50 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 us know. If anyone is a maintainer of the proper subsystem, and wants to add a Signed-off-by: line to the patch, please respond with it.
These patches are sent out with a number of different people on the
Cc: line. If you wish to be a reviewer, please email [email protected] to add your name to the list. If you want to be off the reviewer list, also email us.
Responses should be made by Mon, Jun 9 01:00 UTC. 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/v2.6/stable-review/patch-2.6.25.6-rc1.gz
and the diffstat can be found below.
thanks,
the -stable release team
Signature · 62 lines
Makefile | 2 +- arch/powerpc/kernel/smp.c | 2 + arch/powerpc/mm/slb.c | 21 +++-- arch/x86/kernel/apic_64.c | 2 +- arch/x86/kernel/cpu/cpufreq/acpi-cpufreq.c | 10 ++ arch/x86/kernel/irq_32.c | 2 +- arch/x86/kernel/process_32.c | 5 +- arch/x86/kernel/process_64.c | 5 +- arch/x86/kernel/ptrace.c | 7 +- arch/x86/kernel/tsc_32.c | 38 ++++---- arch/x86/kernel/tsc_64.c | 5 +- arch/x86/pci/common.c | 17 ---- block/genhd.c | 9 ++- drivers/ata/libata-core.c | 12 +++ drivers/block/brd.c | 1 + drivers/cpufreq/cpufreq.c | 4 +- drivers/hid/hid-input.c | 5 +- drivers/hid/usbhid/hid-quirks.c | 38 ++++---- drivers/i2c/busses/i2c-nforce2.c | 28 +++++- drivers/i2c/chips/max6875.c | 3 - drivers/infiniband/ulp/ipoib/ipoib_multicast.c | 6 ++ drivers/md/md.c | 2 +- drivers/md/raid5.c | 10 ++- drivers/net/atl1/atl1_main.c | 1 + drivers/net/ps3_gelic_wireless.c | 2 + drivers/usb/class/cdc-acm.c | 3 + drivers/usb/host/ohci-omap.c | 3 +- drivers/usb/host/ohci-sm501.c | 3 +- drivers/usb/misc/ldusb.c | 4 - drivers/usb/serial/ftdi_sio.c | 1 + drivers/usb/serial/ftdi_sio.h | 6 ++ drivers/usb/serial/option.c | 9 ++- drivers/usb/serial/pl2303.c | 1 - drivers/usb/serial/pl2303.h | 1 - drivers/usb/storage/unusual_devs.h | 10 ++ fs/cifs/inode.c | 15 +++- fs/ecryptfs/ecryptfs_kernel.h | 2 - fs/ecryptfs/read_write.c | 22 ----- fs/ext3/xattr.c | 5 + fs/ext4/xattr.c | 5 + fs/proc/array.c | 2 +- fs/proc/base.c | 33 ++++++-- fs/proc/task_mmu.c | 28 ++---- fs/xfs/linux-2.6/xfs_buf.c | 24 ++++- fs/xfs/linux-2.6/xfs_buf.h | 19 ++++ include/asm-x86/tlbflush.h | 13 +++- include/linux/capability.h | 29 +++++-- include/linux/genhd.h | 4 +- include/linux/hid.h | 1 + include/linux/types.h | 4 +- init/do_mounts.c | 27 ++++++- kernel/capability.c | 111 ++++++++++++++++-------- kernel/cgroup.c | 2 +- mm/memory_hotplug.c | 78 ++++++++-------- mm/mmap.c | 8 ++- mm/page_alloc.c | 3 +- net/ipv6/netfilter/nf_conntrack_reasm.c | 8 +- net/netfilter/nf_conntrack_expect.c | 4 +- net/netfilter/xt_connlimit.c | 3 +- net/netfilter/xt_iprange.c | 2 + security/smack/smack_lsm.c | 12 +++ 61 files changed, 483 insertions(+), 259 deletions(-)
PATCH 1/50 block: do_mounts - accept root=<non-existant partition>
-stable review patch. If anyone has any objections, please let us know.
---------------------
From: Kay Sievers <[email protected]>
commit 30f2f0eb4bd2c43d10a8b0d872c6e5ad8f31c9a0 upstream
Some devices, like md, may create partitions only at first access, so allow root= to be set to a valid non-existant partition of an existing disk. This applies only to non-initramfs root mounting.
This fixes a regression from 2.6.24 which did allow this to happen and broke some users machines :(
--- block/genhd.c | 9 ++++++--- include/linux/genhd.h | 4 ++-- init/do_mounts.c | 27 ++++++++++++++++++++++++++- 3 files changed, 34 insertions(+), 6 deletions(-)
block/genhd.c +6 -3
@@ -645,7 +645,7 @@ void genhd_media_change_notify(struct geEXPORT_SYMBOL_GPL (genhd_media_change_notify);#endif /* 0 */ -dev_t blk_lookup_devt (const char *name) +dev_t blk_lookup_devt (const char *name,int part) {struct device *dev;dev_t devt =MKDEV (0 ,0 );
@@ -653,7 +653,11 @@ dev_t blk_lookup_devt(const char *name)mutex_lock (&block_class_lock);list_for_each_entry (dev, &block_class.devices, node) {if (strcmp (dev->bus_id, name) ==0 ) { - devt = dev->devt; +struct gendisk *disk =dev_to_disk (dev); + +if (part < disk->minors) + devt =MKDEV (MAJOR (dev->devt), +MINOR (dev->devt) + part);break ; } }
@@ -661,7 +665,6 @@ dev_t blk_lookup_devt(const char *name)return devt; } -EXPORT_SYMBOL (blk_lookup_devt);struct gendisk *alloc_disk (int minors)
include/linux/genhd.h +2 -2
@@ -524,7 +524,7 @@ struct unixware_disklabel {#define ADDPART_FLAG_RAID 1#define ADDPART_FLAG_WHOLEDISK 2 -extern dev_t blk_lookup_devt (const char *name); +extern dev_t blk_lookup_devt (const char *name,int part);extern char *disk_name (struct gendisk *hd,int part,char *buf);extern int rescan_partitions (struct gendisk *disk,struct block_device *bdev);
@@ -552,7 +552,7 @@ static inline struct block_device *bdgetstatic inline void printk_all_partitions (void ) { } -static inline dev_t blk_lookup_devt (const char *name) +static inline dev_t blk_lookup_devt (const char *name,int part) {dev_t devt =MKDEV (0 ,0 );return devt;
init/do_mounts.c +26 -1
@@ -76,6 +76,7 @@ dev_t name_to_dev_t(char *name)char s[32 ];char *p;dev_t res =0 ; +int part;if (strncmp (name,"/dev/" ,5 ) !=0 ) {unsigned maj, min;
@@ -106,7 +107,31 @@ dev_t name_to_dev_t(char *name)for (p = s; *p; p++)if (*p =='/' ) *p ='!' ; - res =blk_lookup_devt (s); + res =blk_lookup_devt (s,0 ); +if (res) + goto done; + +/* +* try non-existant, but valid partition, which may only exist +* after revalidating the disk, like partitioned md devices +*/ +while (p > s &&isdigit (p[-1 ])) + p--; +if (p == s || !*p || *p =='0' ) + goto fail; + +/* try disk name without <part number> */ + part =simple_strtoul (p,NULL ,10 ); + *p ='\0' ; + res =blk_lookup_devt (s, part); +if (res) + goto done; + +/* try disk name without p<part number> */ +if (p < s +2 || !isdigit (p[-2 ]) || p[-1 ] !='p' ) + goto fail; + p[-1 ] ='\0' ; + res =blk_lookup_devt (s, part);if (res) goto done;
Re: [patch 01/50] block: do_mounts - accept root=<non-existant partition>
We have reports from two different people running into problems that are exposed by this patch.
Although it's unclear what's actually going wrong this patch is IMHO not -stable fodder until that's sorted out.
cu
Adrian
Signature · 4 lines
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon SeedRe: [patch 01/50] block: do_mounts - accept root=<non-existant partition>
Quoted 2 lines · * Adrian Bunk ([email protected]) wrote:
We have reports from two different people running into problems that are exposed by this patch.
Thanks, pulled. We can add back (plus Linus' fix) once everything is settled.
thanks,
-chris
PATCH 2/50 POWERPC Bolt in SLB entry for kernel stack on secondary cpus
In reply to Chris Wright-stable review patch. If anyone has any objections, please let us know.
---------------------
From: Paul Mackerras <[email protected]>
This is upstream as commit 3b5750644b2ffa2a76fdfe7b4e00e4af2ecf3539.
This fixes a regression reported by Kamalesh Bulabel where a POWER4 machine would crash because of an SLB miss at a point where the SLB miss exception was unrecoverable. This regression is tracked at:
http://bugzilla.kernel.org/show_bug.cgi?id=10082
SLB misses at such points shouldn't happen because the kernel stack is the only memory accessed other than things in the first segment of the linear mapping (which is mapped at all times by entry 0 of the SLB). The context switch code ensures that SLB entry 2 covers the kernel stack, if it is not already covered by entry 0. None of entries 0 to 2 are ever replaced by the SLB miss handler.
Where this went wrong is that the context switch code assumes it doesn't have to write to SLB entry 2 if the new kernel stack is in the same segment as the old kernel stack, since entry 2 should already be correct. However, when we start up a secondary cpu, it calls slb_initialize, which doesn't set up entry 2. This is correct for the boot cpu, where we will be using a stack in the kernel BSS at this point (i.e. init_thread_union), but not necessarily for secondary cpus, whose initial stack can be allocated anywhere. This doesn't cause any immediate problem since the SLB miss handler will just create an SLB entry somewhere else to cover the initial stack.
In fact it's possible for the cpu to go quite a long time without SLB entry 2 being valid. Eventually, though, the entry created by the SLB miss handler will get overwritten by some other entry, and if the next access to the stack is at an unrecoverable point, we get the crash.
This fixes the problem by making slb_initialize create a suitable entry for the kernel stack, if we are on a secondary cpu and the stack isn't covered by SLB entry 0. This requires initializing the get_paca()->kstack field earlier, so I do that in smp_create_idle where the current field is initialized. This also abstracts a bit of the computation that mk_esid_data in slb.c does so that it can be used in slb_initialize.
--- arch/powerpc/kernel/smp.c | 2 ++ arch/powerpc/mm/slb.c | 21 +++++++++++++-------- 2 files changed, 15 insertions(+), 8 deletions(-)
arch/powerpc/kernel/smp.c +2 -0
@@ -386,6 +386,8 @@ static void __init smp_create_idle(unsigpanic ("failed fork for CPU %u: %li" , cpu,PTR_ERR (p));#ifdef CONFIG_PPC64 paca[cpu].__current = p; + paca[cpu].kstack = (unsigned long )task_thread_info (p) + +THREAD_SIZE -STACK_FRAME_OVERHEAD ;#endif current_set[cpu] =task_thread_info (p);task_thread_info (p)->cpu = cpu;
arch/powerpc/mm/slb.c +13 -8
@@ -44,13 +44,13 @@ static void slb_allocate(unsigned long eslb_allocate_realmode (ea); } +#define slb_esid_mask (ssize) \ + (((ssize) == MMU_SEGSIZE_256M)? ESID_MASK: ESID_MASK_1T) +static inline unsigned long mk_esid_data (unsigned long ea,int ssize,unsigned long slot) { -unsigned long mask; - - mask = (ssize ==MMU_SEGSIZE_256M )?ESID_MASK :ESID_MASK_1T ; -return (ea & mask) |SLB_ESID_V | slot; +return (ea &slb_esid_mask (ssize)) |SLB_ESID_V | slot; }#define slb_vsid_shift (ssize) \
@@ -301,11 +301,16 @@ void slb_initialize(void)create_shadowed_slbe (VMALLOC_START , mmu_kernel_ssize, vflags,1 ); +/* For the boot cpu, we're running on the stack in init_thread_union, +* which is in the first segment of the linear mapping, and also +* get_paca()->kstack hasn't been initialized yet. +* For secondary cpus, we need to bolt the kernel stack entry now. +*/ slb_shadow_clear (2 ); +if (raw_smp_processor_id () != boot_cpuid && + (get_paca ()->kstack &slb_esid_mask (mmu_kernel_ssize)) >PAGE_OFFSET ) +create_shadowed_slbe (get_paca ()->kstack, + mmu_kernel_ssize, lflags,2 ); -/* We don't bolt the stack for the time being - we're in boot, -* so the stack is in the bolted segment. By the time it goes -* elsewhere, we'll call _switch() which will bolt in the new -* one. */ asmvolatile ("isync" :::"memory" ); }
PATCH 3/50 USB: remove PICDEM FS USB demo (04d8:000c) device from ldusb
In reply to Chris Wright-stable review patch. If anyone has any objections, please let us know.
---------------------
From: Xiaofan Chen <[email protected]>
commit 5fc89390f74ac42165db477793fb30f6a200e79c upstream
Date: Tue, 13 May 2008 21:52:00 +0800
Subject: [patch 03/50] USB: remove PICDEM FS USB demo (04d8:000c) device from ldusb
Microchip has changed the PICDEM FS USB demo device (0x04d8:000c) to use bulk transfer and not interrupt transfer. So I've updated the libusb based program here (Post #31).
http://forum.microchip.com/tm.aspx?m=106426&mpage=2
So I believe that the in-kernel ldusb driver will no longer work with the demo firmware. It should be removed.
--- drivers/usb/misc/ldusb.c | 4 ---- 1 file changed, 4 deletions(-)
drivers/usb/misc/ldusb.c +0 -4
@@ -63,9 +63,6 @@#define USB_DEVICE_ID_VERNIER_CYCLOPS 0x0004#define USB_DEVICE_ID_VERNIER_LCSPEC 0x0006 -#define USB_VENDOR_ID_MICROCHIP 0x04d8 -#define USB_DEVICE_ID_PICDEM 0x000c -#ifdef CONFIG_USB_DYNAMIC_MINORS #define USB_LD_MINOR_BASE 0#else
@@ -92,7 +89,6 @@ static struct usb_device_id ld_usb_table { USB_DEVICE(USB_VENDOR_ID_VERNIER, USB_DEVICE_ID_VERNIER_GOTEMP) }, { USB_DEVICE(USB_VENDOR_ID_VERNIER, USB_DEVICE_ID_VERNIER_SKIP) }, { USB_DEVICE(USB_VENDOR_ID_VERNIER, USB_DEVICE_ID_VERNIER_CYCLOPS) }, - { USB_DEVICE(USB_VENDOR_ID_MICROCHIP, USB_DEVICE_ID_PICDEM) }, { USB_DEVICE(USB_VENDOR_ID_VERNIER, USB_DEVICE_ID_VERNIER_LCSPEC) }, { } /* Terminating entry */ };
PATCH 4/50 USB: unusual_devs: Add support for GI 0401 SD-Card interface
In reply to Chris Wright-stable review patch. If anyone has any objections, please let us know.
---------------------
From: Filip Aben <[email protected]>
commit e7c6f80fd733218aa1e79efa5d9ece9f76966160 upstream
Enables the SD-Card interface on the GI 0401 HSUPA card from Option.
The unusual_devs.h entry is necessary because the device descriptor is vendor-specific. That prevents usb-storage from binding to it as an interface driver.
This revised patch adds a small comment explaining why and reduces the rev range.
T: Bus=02 Lev=01 Prnt=01 Port=06 Cnt=01 Dev#= 3 Spd=480 MxCh= 0 D: Ver= 2.00 Cls=ff(vend.) Sub=ff Prot=ff MxPS=64 #Cfgs= 1 P: Vendor=0af0 ProdID=7401 Rev= 0.00 S: Manufacturer=Option N.V. S: Product=Globetrotter HSUPA Modem C:* #Ifs=10 Cfg#= 1 Atr=80 MxPwr=500mA I:* If#= 0 Alt= 0 #EPs= 0 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none) I: If#= 0 Alt= 1 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none) E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms I:* If#= 1 Alt= 0 #EPs= 0 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none) I: If#= 1 Alt= 1 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none) E: Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms I:* If#= 2 Alt= 0 #EPs= 0 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none) I: If#= 2 Alt= 1 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none) E: Ad=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms I:* If#= 3 Alt= 0 #EPs= 0 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none) I: If#= 3 Alt= 1 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none) E: Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms I:* If#= 4 Alt= 0 #EPs= 0 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none) I: If#= 4 Alt= 1 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none) E: Ad=85(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms I:* If#= 5 Alt= 0 #EPs= 0 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none) I: If#= 5 Alt= 1 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none) E: Ad=86(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=06(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms I:* If#= 6 Alt= 0 #EPs= 0 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none) I: If#= 6 Alt= 1 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none) E: Ad=87(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=07(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms I:* If#= 7 Alt= 0 #EPs= 0 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none) I: If#= 7 Alt= 1 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none) E: Ad=88(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=08(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms I:* If#= 8 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none) E: Ad=89(I) Atr=03(Int.) MxPS= 64 Ivl=2ms E: Ad=8a(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=09(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms I:* If#= 9 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage E: Ad=0a(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=8b(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
--- drivers/usb/storage/unusual_devs.h | 10 ++++++++++ 1 file changed, 10 insertions(+)
drivers/usb/storage/unusual_devs.h +10 -0
@@ -1285,6 +1285,16 @@ UNUSUAL_DEV( 0x0ace, 0x20ff, 0x0101, 0x0 US_SC_DEVICE, US_PR_DEVICE, NULL, US_FL_IGNORE_DEVICE ), +/* Reported by F. Aben <[email protected]> +* This device (wrongly) has a vendor-specific device descriptor. +* The entry is needed so usb-storage can bind to it's mass-storage +* interface as an interface driver */ +UNUSUAL_DEV( 0x0af0, 0x7401, 0x0000, 0x0000, + "Option", + "GI 0401 SD-Card", + US_SC_DEVICE, US_PR_DEVICE, NULL, + 0 ), +#ifdef CONFIG_USB_STORAGE_ISD200 UNUSUAL_DEV( 0x0bf6, 0xa001, 0x0100, 0x0110, "ATI",
PATCH 5/50 USB: option: add new Dell 5520 HSDPA variant
In reply to Chris Wright-stable review patch. If anyone has any objections, please let us know.
---------------------
From: Dan Williams <[email protected]>
commit 96cb15cf977356d9d3117dd88f3fe187d6024f4b upstream
New variant of the 5520 found by Luke Sheldrick.
--- drivers/usb/serial/option.c | 1 + 1 file changed, 1 insertion(+)
drivers/usb/serial/option.c +1 -0
@@ -293,6 +293,7 @@ static struct usb_device_id option_ids[] { USB_DEVICE(DELL_VENDOR_ID, 0x8133) }, /* Dell Wireless 5720 == Novatel EV620 CDMA/EV-DO */ { USB_DEVICE(DELL_VENDOR_ID, 0x8136) }, /* Dell Wireless HSDPA 5520 == Novatel Expedite EU860D */ { USB_DEVICE(DELL_VENDOR_ID, 0x8137) }, /* Dell Wireless HSDPA 5520 */ + { USB_DEVICE(DELL_VENDOR_ID, 0x8138) }, /* Dell Wireless 5520 Voda I Mobile Broadband (3G HSDPA) Minicard */ { USB_DEVICE(ANYDATA_VENDOR_ID, ANYDATA_PRODUCT_ADU_E100A) }, { USB_DEVICE(ANYDATA_VENDOR_ID, ANYDATA_PRODUCT_ADU_500A) }, { USB_DEVICE(AXESSTEL_VENDOR_ID, AXESSTEL_PRODUCT_MV110H) },
PATCH 6/50 USB: add Zoom Telephonics Model 3095F V.92 USB Mini External modem to cdc-acm
In reply to Chris Wright-stable review patch. If anyone has any objections, please let us know.
---------------------
From: Iain McFarlane <[email protected]>
commit 6149ed5e3a6207595bd7362af7724d64f44af216 upstream
The patch below is a necessary workaround to support the Zoom Telephonics Model 3095F V.92 USB Mini External modem, which fails to initialise properly during normal probing thus:
May 3 22:53:00 imcfarla kernel: drivers/usb/class/cdc-acm.c: Zero length descriptor references May 3 22:53:00 imcfarla kernel: cdc_acm: probe of 5-2:1.0 failed with error -22
Adding the patch below causes the probing section to be skipped, and the modem then initialises correctly.
--- drivers/usb/class/cdc-acm.c | 3 +++ 1 file changed, 3 insertions(+)
drivers/usb/class/cdc-acm.c +3 -0
@@ -1242,6 +1242,9 @@ static struct usb_device_id acm_ids[] = { USB_DEVICE(0x22b8, 0x7000), /* Motorola Q Phone */ .driver_info =NO_UNION_NORMAL ,/* has no union descriptor */ }, + { USB_DEVICE(0x0803, 0x3095), /* Zoom Telephonics Model 3095F USB MODEM */ + .driver_info = NO_UNION_NORMAL, /* has no union descriptor */ + }, /* control interfaces with various AT-command sets */ { USB_INTERFACE_INFO(USB_CLASS_COMM, USB_CDC_SUBCLASS_ACM,
PATCH 7/50 USB: do not handle device 1410:5010 in option driver
In reply to Chris Wright-stable review patch. If anyone has any objections, please let us know.
---------------------
From: Eugeniy Meshcheryakov <[email protected]>
commit cdafc37a7b727b75ced65e31e47dafbd8b70f97f upstream
This device is not a serial port, but a virtual CD-ROM device. For example with my Novatel MC950D:
lsusb -v -d 1410:5010 | grep InterfaceClass
bInterfaceClass 8 Mass Storage
After some time (ca. 5min) or if virtual CD is ejected, device id changes to 1410:4400:
% lsusb -v -d 1410:4400 | grep InterfaceClass
bInterfaceClass 255 Vendor Specific Class
bInterfaceClass 255 Vendor Specific Class
Variable name says that 0x5010 is a Novatel U727, but searching in internet shows, that this device also provides virtual CD that should be ejected before use. Product id for serial port in this case is 0x4100.
--- drivers/usb/serial/option.c | 3 --- 1 file changed, 3 deletions(-)
drivers/usb/serial/option.c +0 -3
@@ -154,8 +154,6 @@ static int option_send_setup(struct usb#define NOVATELWIRELESS_PRODUCT_MC727 0x4100#define NOVATELWIRELESS_PRODUCT_MC950D 0x4400 -#define NOVATELWIRELESS_PRODUCT_U727 0x5010 -/* FUTURE NOVATEL PRODUCTS */ #define NOVATELWIRELESS_PRODUCT_EVDO_1 0x6000#define NOVATELWIRELESS_PRODUCT_HSPA_1 0x7000
@@ -269,7 +267,6 @@ static struct usb_device_id option_ids[] { USB_DEVICE(NOVATELWIRELESS_VENDOR_ID, NOVATELWIRELESS_PRODUCT_EU870D) }, /* Novatel EU850D/EU860D/EU870D */ { USB_DEVICE(NOVATELWIRELESS_VENDOR_ID, NOVATELWIRELESS_PRODUCT_MC950D) }, /* Novatel MC930D/MC950D */ { USB_DEVICE(NOVATELWIRELESS_VENDOR_ID, NOVATELWIRELESS_PRODUCT_MC727) }, /* Novatel MC727/U727/USB727 */ - { USB_DEVICE(NOVATELWIRELESS_VENDOR_ID, NOVATELWIRELESS_PRODUCT_U727) }, /* Novatel U727 */ { USB_DEVICE(NOVATELWIRELESS_VENDOR_ID, NOVATELWIRELESS_PRODUCT_EVDO_1) }, /* Novatel EVDO product */ { USB_DEVICE(NOVATELWIRELESS_VENDOR_ID, NOVATELWIRELESS_PRODUCT_HSPA_1) }, /* Novatel HSPA product */ { USB_DEVICE(NOVATELWIRELESS_VENDOR_ID, NOVATELWIRELESS_PRODUCT_EMBEDDED_1) }, /* Novatel Embedded product */
PATCH 8/50 USB: add Telstra NextG CDMA id to option driver
In reply to Chris Wright-stable review patch. If anyone has any objections, please let us know.
---------------------
From: Greg Kroah-Hartman <[email protected]>
commit 23cacd65f65956426bbca25964a68c174db83a31 upstream
As reported by Magnus Boman <[email protected]>
--- drivers/usb/serial/option.c | 1 + 1 file changed, 1 insertion(+)
drivers/usb/serial/option.c +1 -0
@@ -299,6 +299,7 @@ static struct usb_device_id option_ids[] { USB_DEVICE(KYOCERA_VENDOR_ID, KYOCERA_PRODUCT_KPC680) }, { USB_DEVICE(QUALCOMM_VENDOR_ID, 0x6613)}, /* Onda H600/ZTE MF330 */ { USB_DEVICE(MAXON_VENDOR_ID, 0x6280) }, /* BP3-USB & BP3-EXT HSDPA */ + { USB_DEVICE(0x19d2, 0x0001) }, /* Telstra NextG CDMA */ { } /* Terminating entry */ };MODULE_DEVICE_TABLE (usb, option_ids);
PATCH 9/50 ext3/4: fix uninitialized bs in ext3/4_xattr_set_handle()
In reply to Chris Wright-stable review patch. If anyone has any objections, please let us know.
---------------------
From: Tiger Yang <[email protected]>
commit 7e01c8e5420b6c7f9d85d34c15d8c7a15c9fc720 upstream
This fix the uninitialized bs when we try to replace a xattr entry in ibody with the new value which require more than free space.
This situation only happens we format ext3/4 with inode size more than 128 and we have put xattr entries both in ibody and block. The consequences about this bug is we will lost the xattr block which pointed by i_file_acl with all xattr entires in it. We will alloc a new xattr block and put that large value entry in it. The old xattr block will become orphan block.
--- fs/ext3/xattr.c | 5 +++++ fs/ext4/xattr.c | 5 +++++ 2 files changed, 10 insertions(+)
fs/ext3/xattr.c +5 -0
@@ -1000,6 +1000,11 @@ ext3_xattr_set_handle(handle_t *handle, i.value =NULL ; error =ext3_xattr_block_set (handle, inode, &i, &bs); }else if (error == -ENOSPC ) { +if (EXT3_I (inode)->i_file_acl && !bs.s.base) { + error =ext3_xattr_block_find (inode, &i, &bs); +if (error) + goto cleanup; + } error =ext3_xattr_block_set (handle, inode, &i, &bs);if (error) goto cleanup;
fs/ext4/xattr.c +5 -0
@@ -1011,6 +1011,11 @@ ext4_xattr_set_handle(handle_t *handle, i.value =NULL ; error =ext4_xattr_block_set (handle, inode, &i, &bs); }else if (error == -ENOSPC ) { +if (EXT4_I (inode)->i_file_acl && !bs.s.base) { + error =ext4_xattr_block_find (inode, &i, &bs); +if (error) + goto cleanup; + } error =ext4_xattr_block_set (handle, inode, &i, &bs);if (error) goto cleanup;
PATCH 10/50 libata: force hardreset if link is in powersave mode
In reply to Chris Wright-stable review patch. If anyone has any objections, please let us know.
---------------------
From: Tejun Heo <[email protected]>
Inhibiting link PM mode doesn't bring the link back online if it's already in powersave mode. If SRST is used in these cases, libata EH thinks that the link is offline and fails detection. Force hardreset if link is in powersave mode.
--- drivers/ata/libata-core.c | 12 ++++++++++++ 1 file changed, 12 insertions(+)
drivers/ata/libata-core.c +12 -0
@@ -3947,6 +3947,7 @@ int ata_std_prereset(struct ata_link *listruct ata_port *ap = link->ap;struct ata_eh_context *ehc = &link->eh_context;const unsigned long *timing =sata_ehc_deb_timing (ehc); +u32 sstatus;int rc;/* handle link resume */
@@ -3960,6 +3961,17 @@ int ata_std_prereset(struct ata_link *liif (ap->flags &ATA_FLAG_PMP ) ehc->i.action |=ATA_EH_HARDRESET ; +/* if link powersave is on, force hardreset */ +if (sata_scr_read (link,SCR_STATUS , &sstatus) ==0 ) { +u8 ipm = sstatus >>8 ; + +if (ipm ==2 || ipm ==6 ) { +ata_link_printk (link,KERN_INFO ,"link in powersave " +"mode (ipm=%d), forcing hardreset\n" , ipm); + ehc->i.action |=ATA_EH_HARDRESET ; + } + } +/* if we're about to do hardreset, nothing more to do */ if (ehc->i.action &ATA_EH_HARDRESET )return 0 ;
Re: [patch 10/50] libata: force hardreset if link is in powersave mode
Quoted 10 lines · Chris Wright
-stable review patch. If anyone has any objections, please let us know.
---------------------From: Tejun Heo <[email protected]>
Inhibiting link PM mode doesn't bring the link back online if it's already in powersave mode. If SRST is used in these cases, libata EH thinks that the link is offline and fails detection. Force hardreset if link is in powersave mode.
This isn't upstream. Maybe there's some reason it's not needed upstream, but it would be nice to know.
Linus
Re: [stable] [patch 10/50] libata: force hardreset if link is in powersave mode
Quoted 9 lines · Linus Torvalds
Quoted 6 lines · Chris Wright
-stable review patch. If anyone has any objections, please let us know.
---------------------From: Tejun Heo <[email protected]>
Quoted 7 lines
Quoted 4 lines
Inhibiting link PM mode doesn't bring the link back online if it's already in powersave mode. If SRST is used in these cases, libata EH thinks that the link is offline and fails detection. Force hardreset if link is in powersave mode.
This isn't upstream. Maybe there's some reason it's not needed upstream, but it would be nice to know.
To quote Tejun when he sent this patch:
---
Patch for -stable only. Devel branch now uses hardreset by default so this type of promotion logic isn't necessary anymore.
thanks,
greg k-h
Re: [stable] [patch 10/50] libata: force hardreset if link is in powersave mode
Quoted 8 lines · Greg KH
Quoted 3 lines
This isn't upstream. Maybe there's some reason it's not needed upstream, but it would be nice to know.
To quote Tejun when he sent this patch:
---
Patch for -stable only. Devel branch now uses hardreset by default so this type of promotion logic isn't necessary anymore.
Ok, thanks,
Linus
Re: [patch 10/50] libata: force hardreset if link is in powersave mode
In reply to Linus TorvaldsQuoted 5 lines · Linus Torvalds
Quoted 3 lines · Chris Wright
-stable review patch. If anyone has any objections, please let us know.
---------------------
Quoted 8 lines
Quoted 6 lines
From: Tejun Heo <[email protected]>
Inhibiting link PM mode doesn't bring the link back online if it's already in powersave mode. If SRST is used in these cases, libata EH thinks that the link is offline and fails detection. Force hardreset if link is in powersave mode.
This isn't upstream. Maybe there's some reason it's not needed upstream, but it would be nice to know.
We do hard reset by default...
Jeff
PATCH 11/50 memory_hotplug: always initialize pageblock bitmap
In reply to Chris Wright-stable review patch. If anyone has any objections, please let us know.
---------------------
From: Heiko Carstens <[email protected]>
commit 76cdd58e558669366adfaded436fda01b30cce3e upstream
Trying to online a new memory section that was added via memory hotplug sometimes results in crashes when the new pages are added via __free_page.
Reason for that is that the pageblock bitmap isn't initialized and hence
contains random stuff. That means that get_pageblock_migratetype() returns also random stuff and therefore
list_add(&page->lru, &zone->free_area[order].free_list[migratetype]);
in __free_one_page() tries to do a list_add to something that isn't even necessarily a list.
This happens since 86051ca5eaf5e560113ec7673462804c54284456 ("mm: fix usemap initialization") which makes sure that the pageblock bitmap gets only initialized for pages present in a zone. Unfortunately for hot-added memory the zones "grow" after the memmap and the pageblock memmap have been initialized. Which means that the new pages have an unitialized bitmap. To solve this the calls to grow_zone_span() and grow_pgdat_span() are moved to __add_zone() just before the initialization happens.
The patch also moves the two functions since __add_zone() is the only caller and I didn't want to add a forward declaration.
--- mm/memory_hotplug.c | 78 ++++++++++++++++++++++++++-------------------------- mm/page_alloc.c | 3 -- 2 files changed, 40 insertions(+), 41 deletions(-)
mm/memory_hotplug.c +39 -39
@@ -58,23 +58,59 @@ static void release_memory_resource(strureturn ; } -#ifdef CONFIG_MEMORY_HOTPLUG_SPARSE +static void grow_zone_span (struct zone *zone,unsigned long start_pfn, +unsigned long end_pfn) +{ +unsigned long old_zone_end_pfn; + +zone_span_writelock (zone); + + old_zone_end_pfn = zone->zone_start_pfn + zone->spanned_pages; +if (start_pfn < zone->zone_start_pfn) + zone->zone_start_pfn = start_pfn; + + zone->spanned_pages =max (old_zone_end_pfn, end_pfn) - + zone->zone_start_pfn; + +zone_span_writeunlock (zone); +} + +static void grow_pgdat_span (struct pglist_data *pgdat,unsigned long start_pfn, +unsigned long end_pfn) +{ +unsigned long old_pgdat_end_pfn = + pgdat->node_start_pfn + pgdat->node_spanned_pages; + +if (start_pfn < pgdat->node_start_pfn) + pgdat->node_start_pfn = start_pfn; + + pgdat->node_spanned_pages =max (old_pgdat_end_pfn, end_pfn) - + pgdat->node_start_pfn; +} +static int __add_zone (struct zone *zone,unsigned long phys_start_pfn) {struct pglist_data *pgdat = zone->zone_pgdat;int nr_pages =PAGES_PER_SECTION ;int nid = pgdat->node_id;int zone_type; +unsigned long flags; zone_type = zone - pgdat->node_zones;if (!zone->wait_table) { -int ret =0 ; +int ret; + ret =init_currently_empty_zone (zone, phys_start_pfn, nr_pages,MEMMAP_HOTPLUG ); -if (ret <0 ) +if (ret)return ret; } +pgdat_resize_lock (zone->zone_pgdat, &flags); +grow_zone_span (zone, phys_start_pfn, phys_start_pfn + nr_pages); +grow_pgdat_span (zone->zone_pgdat, phys_start_pfn, + phys_start_pfn + nr_pages); +pgdat_resize_unlock (zone->zone_pgdat, &flags);memmap_init_zone (nr_pages, nid, zone_type, phys_start_pfn,MEMMAP_HOTPLUG );return 0 ;
@@ -134,36 +170,6 @@ int __add_pages(struct zone *zone, unsig }EXPORT_SYMBOL_GPL (__add_pages); -static void grow_zone_span (struct zone *zone, -unsigned long start_pfn,unsigned long end_pfn) -{ -unsigned long old_zone_end_pfn; - -zone_span_writelock (zone); - - old_zone_end_pfn = zone->zone_start_pfn + zone->spanned_pages; -if (start_pfn < zone->zone_start_pfn) - zone->zone_start_pfn = start_pfn; - - zone->spanned_pages =max (old_zone_end_pfn, end_pfn) - - zone->zone_start_pfn; - -zone_span_writeunlock (zone); -} - -static void grow_pgdat_span (struct pglist_data *pgdat, -unsigned long start_pfn,unsigned long end_pfn) -{ -unsigned long old_pgdat_end_pfn = - pgdat->node_start_pfn + pgdat->node_spanned_pages; - -if (start_pfn < pgdat->node_start_pfn) - pgdat->node_start_pfn = start_pfn; - - pgdat->node_spanned_pages =max (old_pgdat_end_pfn, end_pfn) - - pgdat->node_start_pfn; -} -static int online_pages_range (unsigned long start_pfn,unsigned long nr_pages,void *arg) {
@@ -183,7 +189,6 @@ static int online_pages_range(unsigned lint online_pages (unsigned long pfn,unsigned long nr_pages) { -unsigned long flags;unsigned long onlined_pages =0 ;struct zone *zone;int need_zonelists_rebuild =0 ;
@@ -211,11 +216,6 @@ int online_pages(unsigned long pfn, unsi* memory_block->state_sem. */ zone =page_zone (pfn_to_page (pfn)); -pgdat_resize_lock (zone->zone_pgdat, &flags); -grow_zone_span (zone, pfn, pfn + nr_pages); -grow_pgdat_span (zone->zone_pgdat, pfn, pfn + nr_pages); -pgdat_resize_unlock (zone->zone_pgdat, &flags); -/* * If this zone is not populated, then it is not in zonelist. * This means the page allocator ignores this zone.
mm/page_alloc.c +1 -2
@@ -2837,8 +2837,6 @@ __meminit int init_currently_empty_zone( zone->zone_start_pfn = zone_start_pfn; -memmap_init (size, pgdat->node_id,zone_idx (zone), zone_start_pfn); -zone_init_free_lists (zone);return 0 ;
@@ -3408,6 +3406,7 @@ static void __paginginit free_area_init_ ret =init_currently_empty_zone (zone, zone_start_pfn, size,MEMMAP_EARLY );BUG_ON (ret); +memmap_init (size, nid, j, zone_start_pfn); zone_start_pfn += size; } }
PATCH 12/50 USB: fix build errors in ohci-omap.c and ohci-sm501.c
In reply to Chris Wright-stable review patch. If anyone has any objections, please let us know.
---------------------
From: Greg Kroah-Hartman <[email protected]>
This fixes the build errors previously caused by 45fa78357eab3287b5c39f2d983b91150b3f4bd8
This makes the code mirror what went into Linus's tree previously.
--- drivers/usb/host/ohci-omap.c | 3 ++- drivers/usb/host/ohci-sm501.c | 3 ++- 2 files changed, 4 insertions(+), 2 deletions(-)
drivers/usb/host/ohci-omap.c +2 -1
@@ -511,7 +511,8 @@ static int ohci_omap_suspend(struct platstatic int ohci_omap_resume (struct platform_device *dev) { -struct ohci_hcd *ohci =hcd_to_ohci (platform_get_drvdata (dev)); +struct usb_hcd *hcd =platform_get_drvdata (dev); +struct ohci_hcd *ohci =hcd_to_ohci (hcd);if (time_before (jiffies, ohci->next_statechange))msleep (5 );
drivers/usb/host/ohci-sm501.c +2 -1
@@ -231,7 +231,8 @@ static int ohci_sm501_suspend(struct plastatic int ohci_sm501_resume (struct platform_device *pdev) {struct device *dev = &pdev->dev; -struct ohci_hcd *ohci =hcd_to_ohci (platform_get_drvdata (pdev)); +struct usb_hcd *hcd =platform_get_drvdata (pdev); +struct ohci_hcd *ohci =hcd_to_ohci (hcd);if (time_before (jiffies, ohci->next_statechange))msleep (5 );
PATCH 13/50 i2c-nforce2: Disable the second SMBus channel on the DFI Lanparty NF4 Expert
In reply to Chris Wright-stable review patch. If anyone has any objections, please let us know.
---------------------
From: Jean Delvare <[email protected]>
commit 08851d6eb4eeb0894f4d095dfdf8ab61c435ad57 in upstream
There is a strange chip at 0x2e on the second SMBus channel of the DFI Lanparty NF4 Expert motherboard. Accessing the chip reboots the system. As there's nothing interesting on this SMBus channel, the easiest and safest thing to do is to disable it on that board.
This is a better fix to bug #5889 than the it87 driver update that was done originally:
http://bugzilla.kernel.org/show_bug.cgi?id=5889
--- drivers/i2c/busses/i2c-nforce2.c | 28 ++++++++++++++++++++++++---- 1 file changed, 24 insertions(+), 4 deletions(-)
drivers/i2c/busses/i2c-nforce2.c +24 -4
@@ -50,6 +50,7 @@#include <linux/init.h> #include <linux/i2c.h> #include <linux/delay.h> +#include <linux/dmi.h> #include <asm/io.h> MODULE_LICENSE ("GPL" );
@@ -109,6 +110,18 @@ struct nforce2_smbus {/* Misc definitions */ #define MAX_TIMEOUT 100 +/* We disable the second SMBus channel on these boards */ +static struct dmi_system_id __devinitdata nforce2_dmi_blacklist2[] = { + { + .ident ="DFI Lanparty NF4 Expert" , + .matches = { +DMI_MATCH (DMI_BOARD_VENDOR ,"DFI Corp,LTD" ), +DMI_MATCH (DMI_BOARD_NAME ,"LP UT NF4 Expert" ), + }, + }, + { } +}; +static struct pci_driver nforce2_driver;static void nforce2_abort (struct i2c_adapter *adap)
@@ -367,10 +380,17 @@ static int __devinit nforce2_probe(struc smbuses[0 ].base =0 ;/* to have a check value */ }/* SMBus adapter 2 */ - res2 =nforce2_probe_smb (dev,5 ,NFORCE_PCI_SMB2 , &smbuses[1 ],"SMB2" ); -if (res2 <0 ) { -dev_err (&dev->dev,"Error probing SMB2.\n" ); - smbuses[1 ].base =0 ;/* to have a check value */ +if (dmi_check_system (nforce2_dmi_blacklist2)) { +dev_err (&dev->dev,"Disabling SMB2 for safety reasons.\n" ); + res2 = -EPERM ; + smbuses[1 ].base =0 ; + }else { + res2 =nforce2_probe_smb (dev,5 ,NFORCE_PCI_SMB2 , &smbuses[1 ], +"SMB2" ); +if (res2 <0 ) { +dev_err (&dev->dev,"Error probing SMB2.\n" ); + smbuses[1 ].base =0 ;/* to have a check value */ + } }if ((res1 <0 ) && (res2 <0 )) {/* we did not find even one of the SMBuses, so we give up */
PATCH 14/50 i2c/max6875: Really prevent 24RF08 corruption
In reply to Chris Wright-stable review patch. If anyone has any objections, please let us know.
---------------------
From: Jean Delvare <[email protected]>
commit 70455e790391dac85d9b483a9e286a40df1ecc7f in upstream
i2c-core takes care of the possible corruption of 24RF08 chips for quite some times, so device drivers no longer need to do it. And they really should not, as applying the prevention twice voids it.
I thought that I had fixed all drivers long ago but apparently I had missed that one.
--- drivers/i2c/chips/max6875.c | 3 --- 1 file changed, 3 deletions(-)
drivers/i2c/chips/max6875.c +0 -3
@@ -207,9 +207,6 @@ static int max6875_detect(struct i2c_ada fake_client->flags =0 ;strlcpy (fake_client->name,"max6875 subclient" ,I2C_NAME_SIZE ); -/* Prevent 24RF08 corruption (in case of user error) */ -i2c_smbus_write_quick (real_client,0 ); -if ((err =i2c_attach_client (real_client)) !=0 ) goto exit_kfree2;
PATCH 15/50 x86: user_regset_view table fix for ia32 on 64-bit
In reply to Chris Wright-stable review patch. If anyone has any objections, please let us know.
---------------------
From: Roland McGrath <[email protected]>
commit 1f465f4e475454b8bb590846c50a9d16e8046f3d upstream
The user_regset_view table for the 32-bit regsets on the 64-bit build had the wrong sizes for the FP regsets. This bug had no user-visible effect (just on kernel modules using the user_regset interfaces and the like). But the fix is trivial and risk-free.
--- arch/x86/kernel/ptrace.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-)
arch/x86/kernel/ptrace.c +5 -2
@@ -1382,6 +1382,9 @@ static const struct user_regset_view use#define genregs32_get genregs_get#define genregs32_set genregs_set +#define user_i387_ia32_struct user_i387_struct +#define user32_fxsr_struct user_fxsr_struct +#endif /* CONFIG_X86_64 */ #if definedCONFIG_X86_32 || definedCONFIG_IA32_EMULATION
@@ -1394,13 +1397,13 @@ static const struct user_regset x86_32_r }, [REGSET_FP] = { .core_note_type = NT_PRFPREG, - .n = sizeof(struct user_i387_struct) / sizeof(u32), + .n = sizeof(struct user_i387_ia32_struct) / sizeof(u32), .size = sizeof(u32), .align = sizeof(u32), .active = fpregs_active, .get = fpregs_get, .set = fpregs_set }, [REGSET_XFP] = { .core_note_type = NT_PRXFPREG, - .n = sizeof(struct user_i387_struct) / sizeof(u32), + .n = sizeof(struct user32_fxsr_struct) / sizeof(u32), .size = sizeof(u32), .align = sizeof(u32), .active = xfpregs_active, .get = xfpregs_get, .set = xfpregs_set },
PATCH 16/50 i386: fix asm constraint in do_IRQ()
In reply to Chris Wright-stable review patch. If anyone has any objections, please let us know.
---------------------
From: Jan Beulich <[email protected]>
upstream commit: 5065dbafc299507f16731434e95b91dadff03006
i386: fix asm constraint in do_IRQ()
Two prior changes resulted in the "ecx" clobber being lost.
--- arch/x86/kernel/irq_32.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
arch/x86/kernel/irq_32.c +1 -1
@@ -134,7 +134,7 @@ unsigned int do_IRQ(struct pt_regs *regs : "=a" (arg1), "=d" (arg2), "=b" (bx) : "0" (irq), "1" (desc), "2" (isp), "D" (desc->handle_irq) - : "memory", "cc" + : "memory", "cc", "ecx" ); } else#endif
PATCH 17/50 CIFS: Fix UNC path prefix on QueryUnixPathInfo to have correct slash
In reply to Chris Wright-stable review patch. If anyone has any objections, please let us know.
---------------------
From: Steve French <[email protected]>
upstream commit: 076d8423a98659a92837b07aa494cb74bfefe77c
When a share was in DFS and the server was Unix/Linux, we were sending paths of the form
\\server\share/dir/file
rather than
//server/share/dir/file
There was some discussion between me and jra over whether we should use
/server/share/dir/file
as MS sometimes says - but the documentation for this claims it should be doubleslash for this type of UNC-like path format and that works, so leaving it as doubleslash but converting the \ to / in the the //server/share portion.
This gets Samba to now correctly return STATUS_PATH_NOT_COVERED when it is supposed to (Windows already did since the direction of the slash was not an issue for them). Still need another minor change to fully enable DFS (need to finish some chages to SMBGetDFSRefer
--- fs/cifs/inode.c | 15 +++++++++++---- 1 file changed, 11 insertions(+), 4 deletions(-)
fs/cifs/inode.c +11 -4
@@ -161,12 +161,14 @@ static void cifs_unix_info_to_inode(struspin_unlock (&inode->i_lock); } -static const unsigned char *cifs_get_search_path (struct cifsTconInfo *pTcon, -const char *search_path) +static const unsigned char *cifs_get_search_path (struct cifs_sb_info *cifs_sb, +const char *search_path) {int tree_len;int path_len; +int i;char *tmp_path; +struct cifsTconInfo *pTcon = cifs_sb->tcon;if (!(pTcon->Flags &SMB_SHARE_IS_IN_DFS ))return search_path;
@@ -180,6 +182,11 @@ static const unsigned char *cifs_get_seareturn search_path;strncpy (tmp_path, pTcon->treeName, tree_len); +if (cifs_sb->mnt_cifs_flags &CIFS_MOUNT_POSIX_PATHS ) +for (i =0 ; i < tree_len; i++) { +if (tmp_path[i] =='\\' ) + tmp_path[i] ='/' ; + }strncpy (tmp_path+tree_len, search_path, path_len); tmp_path[tree_len+path_len] =0 ;return tmp_path;
@@ -199,7 +206,7 @@ int cifs_get_inode_info_unix(struct inod pTcon = cifs_sb->tcon;cFYI (1 , ("Getting info on %s" , search_path)); - full_path =cifs_get_search_path (pTcon, search_path); + full_path =cifs_get_search_path (cifs_sb, search_path); try_again_CIFSSMBUnixQPathInfo:/* could have done a find first instead but this returns more info */
@@ -402,7 +409,7 @@ int cifs_get_inode_info(struct inode **preturn -ENOMEM ; pfindData = (FILE_ALL_INFO *)buf; - full_path =cifs_get_search_path (pTcon, search_path); + full_path =cifs_get_search_path (cifs_sb, search_path); try_again_CIFSSMBQPathInfo:/* could do find first instead but this returns more info */
PATCH 18/50 USB: add TELIT HDSPA UC864-E modem to option driver
In reply to Chris Wright-stable review patch. If anyone has any objections, please let us know.
---------------------
From: Greg Kroah-Hartman <[email protected]>
upstream commit: ee53b0ca0153b4f944cb142b5e65c96a1860d765
This adds the Telit UC864-E HDSPA modem support to the option driver. This lets their customers comply with the GPL instead of having to use a binary driver from the manufacturer.
--- drivers/usb/serial/option.c | 4 ++++ 1 file changed, 4 insertions(+)
drivers/usb/serial/option.c +4 -0
@@ -193,6 +193,9 @@ static int option_send_setup(struct usb#define MAXON_VENDOR_ID 0x16d8 +#define TELIT_VENDOR_ID 0x1bc7 +#define TELIT_PRODUCT_UC864E 0x1003 +static struct usb_device_id option_ids[] = { {USB_DEVICE (OPTION_VENDOR_ID ,OPTION_PRODUCT_COLT ) }, {USB_DEVICE (OPTION_VENDOR_ID ,OPTION_PRODUCT_RICOLA ) },
@@ -300,6 +303,7 @@ static struct usb_device_id option_ids[] { USB_DEVICE(QUALCOMM_VENDOR_ID, 0x6613)}, /* Onda H600/ZTE MF330 */ { USB_DEVICE(MAXON_VENDOR_ID, 0x6280) }, /* BP3-USB & BP3-EXT HSDPA */ { USB_DEVICE(0x19d2, 0x0001) }, /* Telstra NextG CDMA */ + { USB_DEVICE(TELIT_VENDOR_ID, TELIT_PRODUCT_UC864E) }, { } /* Terminating entry */ };MODULE_DEVICE_TABLE (usb, option_ids);
PATCH 19/50 usb-serial: Use ftdi_sio driver for RATOC REX-USB60F
In reply to Chris Wright-stable review patch. If anyone has any objections, please let us know.
---------------------
From: Atsushi Nemoto <[email protected]>
upstream commit: 26ab705396b65a469233a8327ecb51b8aebb6be0
This patch reverts 57833ea6b95a3995149f1f6d1a8d8862ab7a0ba2 ("usb-serial: pl2303: add support for RATOC REX-USB60F") and adds support for the device to ftdi_sio driver.
--- drivers/usb/serial/ftdi_sio.c | 1 + drivers/usb/serial/ftdi_sio.h | 6 ++++++ drivers/usb/serial/pl2303.c | 1 - drivers/usb/serial/pl2303.h | 1 - 4 files changed, 7 insertions(+), 2 deletions(-)
drivers/usb/serial/ftdi_sio.c +1 -0
@@ -366,6 +366,7 @@ static struct usb_device_id id_table_com .driver_info = (kernel_ulong_t)&ftdi_jtag_quirk }, { USB_DEVICE(FTDI_VID, FTDI_OOCDLINK_PID), .driver_info = (kernel_ulong_t)&ftdi_jtag_quirk }, + { USB_DEVICE(RATOC_VENDOR_ID, RATOC_PRODUCT_ID_USB60F) }, { }, /* Optional parameter entry */ { }/* Terminating entry */ };
drivers/usb/serial/ftdi_sio.h +6 -0
@@ -581,6 +581,12 @@#define FIC_NEO1973_DEBUG_PID 0x5118/* +* RATOC REX-USB60F +*/ +#define RATOC_VENDOR_ID 0x0584 +#define RATOC_PRODUCT_ID_USB60F 0xb020 + +/* * BmRequestType: 1100 0000b * bRequest: FTDI_E2_READ * wValue: 0
drivers/usb/serial/pl2303.c +0 -1
@@ -66,7 +66,6 @@ static struct usb_device_id id_table [] { USB_DEVICE(ITEGNO_VENDOR_ID, ITEGNO_PRODUCT_ID_2080) }, { USB_DEVICE(MA620_VENDOR_ID, MA620_PRODUCT_ID) }, { USB_DEVICE(RATOC_VENDOR_ID, RATOC_PRODUCT_ID) }, - { USB_DEVICE(RATOC_VENDOR_ID, RATOC_PRODUCT_ID_USB60F) }, { USB_DEVICE(TRIPP_VENDOR_ID, TRIPP_PRODUCT_ID) }, { USB_DEVICE(RADIOSHACK_VENDOR_ID, RADIOSHACK_PRODUCT_ID) }, { USB_DEVICE(DCU10_VENDOR_ID, DCU10_PRODUCT_ID) },
drivers/usb/serial/pl2303.h +0 -1
@@ -36,7 +36,6 @@#define RATOC_VENDOR_ID 0x0584#define RATOC_PRODUCT_ID 0xb000 -#define RATOC_PRODUCT_ID_USB60F 0xb020#define TRIPP_VENDOR_ID 0x2478#define TRIPP_PRODUCT_ID 0x2008
PATCH 20/50 cgroups: remove node_ prefix_from ns subsystem
In reply to Chris Wright-stable review patch. If anyone has any objections, please let us know.
---------------------
From: Cedric Le Goater <[email protected]>
upstream commit: 5c02b575780d0d785815a1e7b79a98edddee895a
This is a slight change in the namespace cgroup subsystem api.
The change is that previously when cgroup_clone() was called (currently only from the unshare path in ns_proxy cgroup, you'd get a new group named "node_$pid" whereas now you'll get a group named after just your pid.)
The only users who would notice it are those who are using the ns_proxy cgroup subsystem to auto-create cgroups when namespaces are unshared - something of an experimental feature, which I think really needs more complete container/namespace support in order to be useful. I suspect the only users are Cedric and Serge, or maybe a few others on [email protected]. And in fact it would only be noticed by the users who make the assumption about how the name is generated, rather than getting it from the /proc/<pid>/cgroups file for the process in question.
Whether the change is actually needed or not I'm fairly agnostic on, but I guess it is more elegant to just use the pid as the new group name rather than adding a fairly arbitrary "node_" prefix on the front.
--- kernel/cgroup.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
kernel/cgroup.c +1 -1
@@ -2808,7 +2808,7 @@ int cgroup_clone(struct task_struct *tsk cg = tsk->cgroups; parent =task_cgroup (tsk, subsys->subsys_id); -snprintf (nodename,MAX_CGROUP_TYPE_NAMELEN ,"node_%d" , tsk->pid); +snprintf (nodename,MAX_CGROUP_TYPE_NAMELEN ,"%d" , tsk->pid);/* Pin the hierarchy */ atomic_inc (&parent->root->sb->s_active);
PATCH 21/50 brd: dont show ramdisks in /proc/partitions
In reply to Chris Wright-stable review patch. If anyone has any objections, please let us know.
---------------------
From: Marcin Krol <[email protected]>
upstream commit: 53978d0a7a27eb036b9bf33c4caa06257a9dbed7
In 2.6.25, ramdisk devices show up in /proc/partitions, which is a behaviour change from the old rd.c. Add GENHD_FL_SUPPRESS_PARTITION_INFO, which was present in rd.c.
All kernels prior to 2.6.25 weren't displaying ramdisks in /proc/partitions. Since there are many userspace tools using information from /proc/partitions some of them may now behave incorrectly (I didn't tested any though). For example before 2.6.25 /proc/partitions was empty if no block devices like hard disks and such were detected by kernel. Now all 16 ramdisks are always visible there. Some software may rely on such information (I mean, on empty /proc/partitions).
There was quite similar situation back in 2004, and ramdisks were excluded back from displaying. Thats why I called this a regression (maybe a bit unfortunate). See this patch for info:
http://kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.3-rc2/2.6.3-rc2-mm1/broken-out/nbd-proc-partitions-fix.patch
I also think that someone somewhere (long time ago) excluded ramdisks from /proc/partitions for good reasons. It is possible that now such new "feature" is harmless, but I think there are more chances that someone will say "hey, /proc/partitions has changed, now my software doesn't work" then "hey where did my new 2.6.25 feature go". nbd devices are also excluded, maybe for very same (unknown to me) reasons.
--- drivers/block/brd.c | 1 + 1 file changed, 1 insertion(+)
drivers/block/brd.c +1 -0
@@ -442,6 +442,7 @@ static struct brd_device *brd_alloc(int disk->fops = &brd_fops; disk->private_data = brd; disk->queue = brd->brd_queue; + disk->flags |=GENHD_FL_SUPPRESS_PARTITION_INFO ;sprintf (disk->disk_name,"ram%d" , i);set_capacity (disk, rd_size *2 );
Re: [patch 21/50] brd: dont show ramdisks in /proc/partitions
Quoted 8 lines · Chris Wright
From: Marcin Krol <[email protected]>
I also think that someone somewhere (long time ago) excluded ramdisks from
/proc/partitionsfor good reasons. It is possible that now such new "feature" is harmless, but I think there are more chances that someone will say "hey,/proc/partitionshas changed, now my software doesn't work" then "hey where did my new 2.6.25 feature go". nbd devices are also excluded, maybe for very same (unknown to me) reasons.
This seems a bit like cargo cult programming to me. If there isn't a known, good, reason to revert this behaviour change, I would consider it a bugfix, not a regression.
-hpa
Re: [stable] [patch 21/50] brd: dont show ramdisks in /proc/partitions
Quoted 3 lines · * H. Peter Anvin ([email protected]) wrote:
This seems a bit like cargo cult programming to me. If there isn't a known, good, reason to revert this behaviour change, I would consider it a bugfix, not a regression.
We have one /proc/partitions parser that got broken (never saw details on how). I don't care for this change either (esp. since nbd is still left out...it's inconsistent).
This is now the upstream behaviour (obvious since it's a -stable candidate), and the change was introduced in 2.6.25...I'd actually prefer to drop this patch, but there's no good reason to deviate if upstream keeps this one. I can defer while upstream gets revisited, can you revisit this upstream?
thanks,
-chris
Re: [stable] [patch 21/50] brd: dont show ramdisks in /proc/partitions
Quoted 8 lines · Chris Wright
Quoted 3 lines · * H. Peter Anvin ([email protected]) wrote:
This seems a bit like cargo cult programming to me. If there isn't a known, good, reason to revert this behaviour change, I would consider it a bugfix, not a regression.
We have one
/proc/partitionsparser that got broken (never saw details on how). I don't care for this change either (esp. since nbd is still left out...it's inconsistent).
I also had one of my old install scripts proposing me to choose between 16 ramdisks to install to. Quite bothering in fact. I'm not sure we really can consider ramdisks as partitions. Also, all of them are listed, whether they are initialized or not.
In fact, I was glad to see this "fixed" with this patch.
Regards,
willy
H. Peter Anvin
reviewerRe: [stable] [patch 21/50] brd: dont show ramdisks in /proc/partitions
In reply to Chris WrightQuoted 7 lines · Chris Wright
Quoted 1 line · * H. Peter Anvin ([email protected]) wrote:
This seems a bit like cargo cult programming to me. If there isn't a known, good, reason to revert this behaviour change, I would consider it a bugfix, not a regression.
We have one
/proc/partitionsparser that got broken (never saw details on how). I don't care for this change either (esp. since nbd is still left out...it's inconsistent).
Quoted 5 lines
This is now the upstream behaviour (obvious since it's a -stable candidate), and the change was introduced in 2.6.25...I'd actually prefer to drop this patch, but there's no good reason to deviate if upstream keeps this one. I can defer while upstream gets revisited, can you revisit this upstream?
I had to ask Chris offline what he meant with this... basically, he and I both agree that absent hard evidence of malfunction, we should revert to 2.6.25 behaviour.
-hpa
PATCH 22/50 types.h: dont expose struct ustat to userspace
In reply to Chris Wright-stable review patch. If anyone has any objections, please let us know.
---------------------
From: maximilian attems <[email protected]>
upstream commit: 6c7c6afbb8c0e60d32a563cae7c6889211e9d9d8
<linux/types.h> can't be used together with <sys/ustat.h> because they both define struct ustat:
$ cat test.c
#include <sys/ustat.h>
#include <linux/types.h>
$ gcc -c test.c
In file included from test.c:2:
/usr/include/linux/types.h:165: error: redefinition of 'struct ustat'has been reported a while ago to debian, but seems to have been lost in cat fighting: http://bugs.debian.org/429064
--- include/linux/types.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
include/linux/types.h +2 -2
@@ -197,8 +197,6 @@ typedef u64 resource_size_t;typedef u32 resource_size_t ;#endif -#endif /* __KERNEL__ */ -struct ustat {__kernel_daddr_t f_tfree;__kernel_ino_t f_tinode;
@@ -206,4 +204,6 @@ struct ustat {char f_fpack[6 ]; }; +#endif /* __KERNEL__ */ +#endif /* _LINUX_TYPES_H */
PATCH 23/50 x86: dont read maxlvt before checking if APIC is mapped
In reply to Chris Wright-stable review patch. If anyone has any objections, please let us know.
---------------------
From: Chuck Ebbert <[email protected]>
upstream commit: 2584a82deed7196f48066f1b1a7fad4ec5bea961
A check for unmapped apic was added before reading maxlvt but the early read of maxlvt wasn't removed.
--- arch/x86/kernel/apic_64.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
arch/x86/kernel/apic_64.c +1 -1
@@ -524,7 +524,7 @@ int setup_profiling_timer(unsigned int m*/ void clear_local_APIC (void ) { -int maxlvt =lapic_get_maxlvt (); +int maxlvt;u32 v;/* APIC hasn't been mapped yet */
PATCH 24/50 IPoIB: Test for NULL broadcast object in ipiob_mcast_join_finish()
In reply to Chris Wright-stable review patch. If anyone has any objections, please let us know.
---------------------
From: Jack Morgenstein <[email protected]>
upstream commit: e1d50dce5af77cb6d33555af70e2b8748dd84009
We saw a kernel oops in our regression testing when a multicast "join finish" occurred just after the interface was -- this is
<https://bugs.openfabrics.org/show_bug.cgi?id=1040>. The test randomly causes the HCA physical port to go down then up.
The cause of this is that ipoib_mcast_join_finish() processing happen just after ipoib_mcast_dev_flush() was invoked (in which case the broadcast pointer is NULL). This patch tests for and handles the case where priv->broadcast is NULL.
--- drivers/infiniband/ulp/ipoib/ipoib_multicast.c | 6 ++++++ 1 file changed, 6 insertions(+)
drivers/infiniband/ulp/ipoib/ipoib_multicast.c +6 -0
@@ -194,7 +194,13 @@ static int ipoib_mcast_join_finish(struc/* Set the cached Q_Key before we attach if it's the broadcast group */ if (!memcmp (mcast->mcmember.mgid.raw, priv->dev->broadcast +4 ,sizeof (union ib_gid ))) { +spin_lock_irq (&priv->lock); +if (!priv->broadcast) { +spin_unlock_irq (&priv->lock); +return -EAGAIN ; + } priv->qkey =be32_to_cpu (priv->broadcast->mcmember.qkey); +spin_unlock_irq (&priv->lock); priv->tx_wr.wr.ud.remote_qkey = priv->qkey; }
PATCH 25/50 x86: fix setup of cyc2ns in tsc_64.c
In reply to Chris Wright-stable review patch. If anyone has any objections, please let us know.
---------------------
From: Thomas Gleixner <[email protected]>
upstream commit: b6db80ee1331e7beaeb91b4b3d946dd16c72e388
When the TSC is calibrated against the PIT due to the nonavailability of PMTIMER/HPET or due to SMI interference then the setup of the per CPU cyc2ns variables is skipped. This is unlikely to happen but it would definitely render sched_clock() unusable.
This was introduced with commit 53d517cdbaac704352b3d0c10fecb99e0b54572e
x86: scale cyc_2_nsec according to CPU frequency
Update the per CPU cyc2ns variables in all exit pathes of tsc_calibrate.
--- arch/x86/kernel/tsc_64.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)
arch/x86/kernel/tsc_64.c +3 -2
@@ -227,14 +227,14 @@ void __init tsc_calibrate(void)/* hpet or pmtimer available ? */ if (!hpet && !pm1 && !pm2) {printk (KERN_INFO "TSC calibrated against PIT\n" ); -return ; + goto out; }/* Check, whether the sampling was disturbed by an SMI */ if (tsc1 ==ULONG_MAX || tsc2 ==ULONG_MAX ) {printk (KERN_WARNING "TSC calibration disturbed by SMI, " "using PIT calibration result\n" ); -return ; + goto out; } tsc2 = (tsc2 - tsc1) *1000000L ;
@@ -255,6 +255,7 @@ void __init tsc_calibrate(void) tsc_khz = tsc2 / tsc1; +out:for_each_possible_cpu (cpu)set_cyc2ns_scale (tsc_khz, cpu); }
PATCH 26/50 x86: if we cannot calibrate the TSC, we panic.
In reply to Chris Wright-stable review patch. If anyone has any objections, please let us know.
---------------------
From: Rusty Russell <[email protected]>
upstream commit: 3c2047cd32b1a8c782d7efab72707e7daa251625
The current tsc_init() clears the TSC feature bit if the TSC khz cannot be calculated, causing us to panic in arch/x86/kernel/cpu/bugs.c check_config(). We should simply mark it unstable.
Frankly, someone should take an axe to this code. mark_tsc_unstable() not only marks it unstable, but sets tsc_enabled to 0, which seems redundant but is actually important here because means it won't be used by sched_clock() either. Perhaps a tristate enum "UNUSABLE, UNSTABLE, OK" would be clearer, and separate mark_tsc_unstable() and mark_tsc_broken() functions?
--- arch/x86/kernel/tsc_32.c | 13 +++++-------- 1 file changed, 5 insertions(+), 8 deletions(-)
arch/x86/kernel/tsc_32.c +5 -8
@@ -392,13 +392,15 @@ void __init tsc_init(void)int cpu;if (!cpu_has_tsc) - goto out_no_tsc; +return ; cpu_khz =calculate_cpu_khz (); tsc_khz = cpu_khz; -if (!cpu_khz) - goto out_no_tsc; +if (!cpu_khz) { +mark_tsc_unstable ("could not calculate TSC khz" ); +return ; + } printk("Detected %lu.%03lu MHz processor.\n", (unsigned long)cpu_khz / 1000,
@@ -431,9 +433,4 @@ void __init tsc_init(void) tsc_enabled =1 ;clocksource_register (&clocksource_tsc); - -return ; - -out_no_tsc: -setup_clear_cpu_cap (X86_FEATURE_TSC ); }
PATCH 27/50 x86: distangle user disabled TSC from unstable
In reply to Chris Wright-stable review patch. If anyone has any objections, please let us know.
---------------------
From: Thomas Gleixner <[email protected]>
upstream commit: 9ccc906c97e34fd91dc6aaf5b69b52d824386910
tsc_enabled is set to 0 from the command line switch "notsc" and from the mark_tsc_unstable code. Seperate those functionalities and replace tsc_enable with tsc_disable. This makes also the native_sched_clock() decision when to use TSC understandable.
Preparatory patch to solve the sched_clock() issue on 32 bit.
--- arch/x86/kernel/tsc_32.c | 20 ++++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-)
arch/x86/kernel/tsc_32.c +10 -10
@@ -14,7 +14,7 @@#include "mach_timer.h" -static int tsc_enabled; +static int tsc_disabled;/* * On some systems the TSC frequency does not
@@ -28,8 +28,8 @@ EXPORT_SYMBOL_GPL(tsc_khz);static int __init tsc_setup (char *str) {printk (KERN_WARNING "notsc: Kernel compiled with CONFIG_X86_TSC, " -"cannot disable TSC completely.\n" ); -mark_tsc_unstable ("user disabled TSC" ); +"cannot disable TSC completely.\n" ); + tsc_disabled =1 ;return 1 ; }#else
@@ -121,7 +121,7 @@ unsigned long long native_sched_clock(vo* very important for it to be as fast as the platform * can achive it. ) */ -if (unlikely (!tsc_enabled && !tsc_unstable)) +if (unlikely (tsc_disabled))/* No locking but a rare wrong value is not a big deal: */ return (jiffies_64 -INITIAL_JIFFIES ) * (1000000000 /HZ );
@@ -310,7 +310,6 @@ void mark_tsc_unstable(char *reason) {if (!tsc_unstable) { tsc_unstable =1 ; - tsc_enabled =0 ;printk ("Marking TSC unstable due to: %s.\n" , reason);/* Can be called before registration */ if (clocksource_tsc.mult)
@@ -324,7 +323,7 @@ EXPORT_SYMBOL_GPL(mark_tsc_unstable);static int __init dmi_mark_tsc_unstable (const struct dmi_system_id *d) {printk (KERN_NOTICE "%s detected: marking TSC unstable.\n" , - d->ident); + d->ident); tsc_unstable =1 ;return 0 ; }
@@ -391,8 +390,11 @@ void __init tsc_init(void) {int cpu; -if (!cpu_has_tsc) +if (!cpu_has_tsc || tsc_disabled) { +/* Disable the TSC in case of !cpu_has_tsc */ + tsc_disabled =1 ;return ; + } cpu_khz =calculate_cpu_khz (); tsc_khz = cpu_khz;
@@ -429,8 +431,6 @@ void __init tsc_init(void)if (check_tsc_unstable ()) { clocksource_tsc.rating =0 ; clocksource_tsc.flags &= ~CLOCK_SOURCE_IS_CONTINUOUS ; - }else - tsc_enabled =1 ; - + }clocksource_register (&clocksource_tsc); }
PATCH 28/50 x86: disable TSC for sched_clock() when calibration failed
In reply to Chris Wright-stable review patch. If anyone has any objections, please let us know.
---------------------
From: Thomas Gleixner <[email protected]>
upstream commit: 74dc51a3de06aa516e3b9fdc4017b2aeb38bf44b
When the TSC calibration fails then TSC is still used in sched_clock(). Disable it completely in that case.
--- arch/x86/kernel/tsc_32.c | 5 +++++ 1 file changed, 5 insertions(+)
arch/x86/kernel/tsc_32.c +5 -0
@@ -401,6 +401,11 @@ void __init tsc_init(void)if (!cpu_khz) {mark_tsc_unstable ("could not calculate TSC khz" ); +/* +* We need to disable the TSC completely in this case +* to prevent sched_clock() from using it. +*/ + tsc_disabled =1 ;return ; }
PATCH 29/50 XFS: Fix memory corruption with small buffer reads
In reply to Chris Wright-stable review patch. If anyone has any objections, please let us know.
---------------------
From: Christoph Hellwig <[email protected]>
upstream commit: 6ab455eeaff6893cd06da33843e840d888cdc04a
When we have multiple buffers in a single page for a blocksize == pagesize filesystem we might overwrite the page contents if two callers hit it shortly after each other. To prevent that we need to keep the page locked until I/O is completed and the page marked uptodate.
Thanks to Eric Sandeen for triaging this bug and finding a reproducible testcase and Dave Chinner for additional advice.
This should fix kernel.org bz #10421.
SGI-PV: 981813
SGI-Modid: xfs-linux-melb:xfs-kern:31173a
--- fs/xfs/linux-2.6/xfs_buf.c | 24 ++++++++++++++++++++---- fs/xfs/linux-2.6/xfs_buf.h | 19 +++++++++++++++++++ 2 files changed, 39 insertions(+), 4 deletions(-)
fs/xfs/linux-2.6/xfs_buf.c +20 -4
@@ -387,6 +387,8 @@ _xfs_buf_lookup_pages(if (unlikely (page ==NULL )) {if (flags &XBF_READ_AHEAD ) { bp->b_page_count = i; +for (i =0 ; i < bp->b_page_count; i++) +unlock_page (bp->b_pages[i]);return -ENOMEM ; }
@@ -416,17 +418,24 @@ _xfs_buf_lookup_pages(ASSERT (!PagePrivate (page));if (!PageUptodate (page)) { page_count--; -if (blocksize <PAGE_CACHE_SIZE && !PagePrivate (page)) { +if (blocksize >=PAGE_CACHE_SIZE ) { +if (flags &XBF_READ ) + bp->b_flags |= _XBF_PAGE_LOCKED; + }else if (!PagePrivate (page)) {if (test_page_region (page, offset, nbytes)) page_count++; } } -unlock_page (page); bp->b_pages[i] = page; offset =0 ; } +if (!(bp->b_flags & _XBF_PAGE_LOCKED)) { +for (i =0 ; i < bp->b_page_count; i++) +unlock_page (bp->b_pages[i]); + } +if (page_count == bp->b_page_count) bp->b_flags |=XBF_DONE ;
@@ -746,6 +755,7 @@ xfs_buf_associate_memory( bp->b_count_desired = len; bp->b_buffer_length = buflen; bp->b_flags |=XBF_MAPPED ; + bp->b_flags &= ~_XBF_PAGE_LOCKED;return 0 ; }
@@ -1093,8 +1103,10 @@ _xfs_buf_ioend( xfs_buf_t *bp, int schedule) { -if (atomic_dec_and_test (&bp->b_io_remaining) ==1 ) +if (atomic_dec_and_test (&bp->b_io_remaining) ==1 ) { + bp->b_flags &= ~_XBF_PAGE_LOCKED;xfs_buf_ioend (bp, schedule); + } }STATIC void
@@ -1125,6 +1137,9 @@ xfs_buf_bio_end_io(if (--bvec >= bio->bi_io_vec)prefetchw (&bvec->bv_page->flags); + +if (bp->b_flags & _XBF_PAGE_LOCKED) +unlock_page (page); }while (bvec >= bio->bi_io_vec);_xfs_buf_ioend (bp,1 );
@@ -1163,7 +1178,8 @@ _xfs_buf_ioapply(* filesystem block size is not smaller than the page size. */ if ((bp->b_buffer_length <PAGE_CACHE_SIZE ) && - (bp->b_flags &XBF_READ ) && + ((bp->b_flags & (XBF_READ |_XBF_PAGE_LOCKED)) == + (XBF_READ |_XBF_PAGE_LOCKED)) && (blocksize >=PAGE_CACHE_SIZE )) { bio =bio_alloc (GFP_NOIO ,1 );
fs/xfs/linux-2.6/xfs_buf.h +19 -0
@@ -66,6 +66,25 @@ typedef enum { _XBF_PAGES = (1 <<18 ),/* backed by refcounted pages */ _XBF_RUN_QUEUES = (1 <<19 ),/* run block device task queue */ _XBF_DELWRI_Q = (1 <<21 ),/* buffer on delwri queue */ + +/* +* Special flag for supporting metadata blocks smaller than a FSB. +* +* In this case we can have multiple xfs_buf_t on a single page and +* need to lock out concurrent xfs_buf_t readers as they only +* serialise access to the buffer. +* +* If the FSB size >= PAGE_CACHE_SIZE case, we have no serialisation +* between reads of the page. Hence we can have one thread read the +* page and modify it, but then race with another thread that thinks +* the page is not up-to-date and hence reads it again. +* +* The result is that the first modifcation to the page is lost. +* This sort of AGF/AGI reading race can happen when unlinking inodes +* that require truncation and results in the AGI unlinked list +* modifications being lost. +*/ + _XBF_PAGE_LOCKED = (1 <<22 ), } xfs_buf_flags_t; typedef enum {
PATCH 30/50 x86: prevent PGE flush from interruption/preemption
In reply to Chris Wright-stable review patch. If anyone has any objections, please let us know.
---------------------
From: Ingo Molnar <[email protected]>
upstream commit: b1979a5fda7869a790f4fd83fb06c78498d26ba1
CR4 manipulation is not protected against interrupts and preemption, but KVM uses smp_function_call to manipulate the X86_CR4_VMXE bit either from the CPU hotplug code or from the kvm_init call.
We need to protect the CR4 manipulation from both interrupts and preemption.
Original bug report: http://lkml.org/lkml/2008/5/7/48
Bugzilla entry: http://bugzilla.kernel.org/show_bug.cgi?id=10642
This is not a regression from 2.6.25, it's a long standing and hard to trigger bug.
--- include/asm-x86/tlbflush.h | 13 ++++++++++++- 1 file changed, 12 insertions(+), 1 deletion(-)
include/asm-x86/tlbflush.h +12 -1
@@ -22,12 +22,23 @@ static inline void __native_flush_tlb(vostatic inline void __native_flush_tlb_global (void ) { -unsigned long cr4 =read_cr4 (); +unsigned long flags; +unsigned long cr4; +/* +* Read-modify-write to CR4 - protect it from preemption and +* from interrupts. (Use the raw variant because this code can +* be called from deep inside debugging code.) +*/ +raw_local_irq_save (flags); + + cr4 =read_cr4 ();/* clear PGE */ write_cr4 (cr4 & ~X86_CR4_PGE );/* write old PGE again and flush TLBs */ write_cr4 (cr4); + +raw_local_irq_restore (flags); }static inline void __native_flush_tlb_single (unsigned long addr)
PATCH 31/50 Revert "PCI: remove default PCI expansion ROM memory allocation"
In reply to Chris Wright-stable review patch. If anyone has any objections, please let us know.
---------------------
From: Linus Torvalds <[email protected]>
upstream commit: 8d539108560ec121d59eee05160236488266221c
This reverts commit 9f8daccaa05c14e5643bdd4faf5aed9cc8e6f11e, which was reported to break X startup (xf86-video-ati-6.8.0). See
http://bugs.freedesktop.org/show_bug.cgi?id=15523
for details.
--- arch/x86/pci/common.c | 17 ----------------- 1 file changed, 17 deletions(-)
arch/x86/pci/common.c +0 -17
@@ -130,19 +130,6 @@ static void __devinit pcibios_fixup_ghos } } -static void __devinit pcibios_fixup_device_resources (struct pci_dev *dev) -{ -struct resource *rom_r = &dev->resource[PCI_ROM_RESOURCE ]; - -if (rom_r->parent) -return ; -if (rom_r->start) -/* we deal with BIOS assigned ROM later */ -return ; -if (!(pci_probe &PCI_ASSIGN_ROMS )) - rom_r->start = rom_r->end = rom_r->flags =0 ; -} -/* * Called after each bus is probed, but before its children * are examined.
@@ -150,12 +137,8 @@ static void __devinit pcibios_fixup_devivoid __devinit pcibios_fixup_bus (struct pci_bus *b) { -struct pci_dev *dev; -pcibios_fixup_ghosts (b);pci_read_bridge_bases (b); -list_for_each_entry (dev, &b->devices, bus_list) -pcibios_fixup_device_resources (dev); }/*
PATCH 32/50 PS3: gelic: fix memory leak
In reply to Chris Wright-stable review patch. If anyone has any objections, please let us know.
---------------------
From: Masakazu Mokuno <[email protected]>
upstream commit: 6fc7431dc0775f21ad7a7a39c2ad0290291a56ea
This fixes the bug that the I/O buffer is not freed at the driver removal.
--- drivers/net/ps3_gelic_wireless.c | 2 ++ 1 file changed, 2 insertions(+)
drivers/net/ps3_gelic_wireless.c +2 -0
@@ -2474,6 +2474,8 @@ static void gelic_wl_free(struct gelic_wpr_debug ("%s: <-\n" , __func__); +free_page ((unsigned long )wl->buf); +pr_debug ("%s: destroy queues\n" , __func__);destroy_workqueue (wl->eurus_cmd_queue);destroy_workqueue (wl->event_queue);
PATCH 33/50 netfilter: xt_iprange: module aliases for xt_iprange
In reply to Chris Wright-stable review patch. If anyone has any objections, please let us know.
---------------------
From: Phil Oester <[email protected]>
upstream commit: 01b7a314291b2ef56ad718ee1374a1bac4768b29
Using iptables 1.3.8 with kernel 2.6.25, rules which include '-m iprange' don't automatically pull in xt_iprange module. Below patch adds module aliases to fix that. Patch against latest -git, but seems like a good candidate for -stable also.
--- net/netfilter/xt_iprange.c | 2 ++ 1 file changed, 2 insertions(+)
net/netfilter/xt_iprange.c +2 -0
@@ -179,3 +179,5 @@ module_exit(iprange_mt_exit);MODULE_LICENSE ("GPL" );MODULE_AUTHOR ("Jozsef Kadlecsik <[email protected]>, Jan Engelhardt <[email protected]>" );MODULE_DESCRIPTION ("Xtables: arbitrary IPv4 range matching" ); +MODULE_ALIAS ("ipt_iprange" ); +MODULE_ALIAS ("ip6t_iprange" );
PATCH 34/50 HID: split Numlock emulation quirk from HID_QUIRK_APPLE_HAS_FN.
In reply to Chris Wright-stable review patch. If anyone has any objections, please let us know.
---------------------
From: Diego 'Flameeyes' Petteno <[email protected]>
upstream commit: 6e7045990f35ef9250804b3fd85e855b8c2aaeb6.
[[email protected]: Needed to fix apple aluminium keyboard regression]
Since 2.6.25 the HID_QUIRK_APPLE_HAS_FN quirk is enabled even for non-laptop Apple keyboards of the Aluminium series. The USB version of these don't need Numlock emulation, like the laptop (and Aluminium Wireless) do, as they have a proper keypad.
This patch splits the Numlock emulation for Apple keyboards in a different quirk flag, so that it can be enabled for all the keyboards but the Aluminium USB ones.
If the Numlock emulation is enabled for Aluminium USB keyboards, the JKL and UIO keys become the numeric pad, and the rest of the keyboard is disabled, included the key used to disable Numlock.
Additionally, these keyboard should not have a Numlock at all, as the Numlock key is instead replaced by the 'Clear' key as usual for Apple USB keyboards.
--- drivers/hid/hid-input.c | 5 +++-- drivers/hid/usbhid/hid-quirks.c | 38 +++++++++++++++++++------------------- include/linux/hid.h | 1 + 3 files changed, 23 insertions(+), 21 deletions(-)
drivers/hid/hid-input.c +3 -2
@@ -218,8 +218,9 @@ int hidinput_apple_event(struct hid_devi } } -if (test_bit (usage->code, hid->pb_pressed_numlock) || -test_bit (LED_NUML , input->led)) { +if (hid->quirks &HID_QUIRK_APPLE_NUMLOCK_EMULATION && ( +test_bit (usage->code, hid->pb_pressed_numlock) || +test_bit (LED_NUML , input->led))) { trans =find_translation (powerbook_numlock_keys, usage->code);if (trans) {
drivers/hid/usbhid/hid-quirks.c +19 -19
@@ -613,28 +613,28 @@ static const struct hid_blacklist { { USB_VENDOR_ID_WISEGROUP_LTD, USB_DEVICE_ID_SMARTJOY_DUAL_PLUS, HID_QUIRK_NOGET | HID_QUIRK_MULTI_INPUT }, - { USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_FOUNTAIN_ANSI, HID_QUIRK_APPLE_HAS_FN | HID_QUIRK_IGNORE_MOUSE }, - { USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_FOUNTAIN_ISO, HID_QUIRK_APPLE_HAS_FN | HID_QUIRK_IGNORE_MOUSE }, - { USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_GEYSER_ANSI, HID_QUIRK_APPLE_HAS_FN | HID_QUIRK_IGNORE_MOUSE }, - { USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_GEYSER_ISO, HID_QUIRK_APPLE_HAS_FN | HID_QUIRK_IGNORE_MOUSE | HID_QUIRK_APPLE_ISO_KEYBOARD}, - { USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_GEYSER_JIS, HID_QUIRK_APPLE_HAS_FN | HID_QUIRK_IGNORE_MOUSE }, - { USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_GEYSER3_ANSI, HID_QUIRK_APPLE_HAS_FN | HID_QUIRK_IGNORE_MOUSE }, - { USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_GEYSER3_ISO, HID_QUIRK_APPLE_HAS_FN | HID_QUIRK_IGNORE_MOUSE | HID_QUIRK_APPLE_ISO_KEYBOARD}, - { USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_GEYSER3_JIS, HID_QUIRK_APPLE_HAS_FN | HID_QUIRK_IGNORE_MOUSE }, - { USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_GEYSER4_ANSI, HID_QUIRK_APPLE_HAS_FN | HID_QUIRK_IGNORE_MOUSE }, - { USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_GEYSER4_ISO, HID_QUIRK_APPLE_HAS_FN | HID_QUIRK_IGNORE_MOUSE | HID_QUIRK_APPLE_ISO_KEYBOARD}, - { USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_GEYSER4_JIS, HID_QUIRK_APPLE_HAS_FN | HID_QUIRK_IGNORE_MOUSE }, + { USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_FOUNTAIN_ANSI, HID_QUIRK_APPLE_NUMLOCK_EMULATION | HID_QUIRK_APPLE_HAS_FN | HID_QUIRK_IGNORE_MOUSE }, + { USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_FOUNTAIN_ISO, HID_QUIRK_APPLE_NUMLOCK_EMULATION | HID_QUIRK_APPLE_HAS_FN | HID_QUIRK_IGNORE_MOUSE }, + { USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_GEYSER_ANSI, HID_QUIRK_APPLE_NUMLOCK_EMULATION | HID_QUIRK_APPLE_HAS_FN | HID_QUIRK_IGNORE_MOUSE }, + { USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_GEYSER_ISO, HID_QUIRK_APPLE_NUMLOCK_EMULATION | HID_QUIRK_APPLE_HAS_FN | HID_QUIRK_IGNORE_MOUSE | HID_QUIRK_APPLE_ISO_KEYBOARD}, + { USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_GEYSER_JIS, HID_QUIRK_APPLE_NUMLOCK_EMULATION | HID_QUIRK_APPLE_HAS_FN | HID_QUIRK_IGNORE_MOUSE }, + { USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_GEYSER3_ANSI, HID_QUIRK_APPLE_NUMLOCK_EMULATION | HID_QUIRK_APPLE_HAS_FN | HID_QUIRK_IGNORE_MOUSE }, + { USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_GEYSER3_ISO, HID_QUIRK_APPLE_NUMLOCK_EMULATION | HID_QUIRK_APPLE_HAS_FN | HID_QUIRK_IGNORE_MOUSE | HID_QUIRK_APPLE_ISO_KEYBOARD}, + { USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_GEYSER3_JIS, HID_QUIRK_APPLE_NUMLOCK_EMULATION | HID_QUIRK_APPLE_HAS_FN | HID_QUIRK_IGNORE_MOUSE }, + { USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_GEYSER4_ANSI, HID_QUIRK_APPLE_NUMLOCK_EMULATION | HID_QUIRK_APPLE_HAS_FN | HID_QUIRK_IGNORE_MOUSE }, + { USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_GEYSER4_ISO, HID_QUIRK_APPLE_NUMLOCK_EMULATION | HID_QUIRK_APPLE_HAS_FN | HID_QUIRK_IGNORE_MOUSE | HID_QUIRK_APPLE_ISO_KEYBOARD}, + { USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_GEYSER4_JIS, HID_QUIRK_APPLE_NUMLOCK_EMULATION | HID_QUIRK_APPLE_HAS_FN | HID_QUIRK_IGNORE_MOUSE }, { USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_ALU_ANSI, HID_QUIRK_APPLE_HAS_FN }, { USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_ALU_ISO, HID_QUIRK_APPLE_HAS_FN | HID_QUIRK_APPLE_ISO_KEYBOARD }, { USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_ALU_JIS, HID_QUIRK_APPLE_HAS_FN }, - { USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_GEYSER4_HF_ANSI, HID_QUIRK_APPLE_HAS_FN | HID_QUIRK_IGNORE_MOUSE }, - { USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_GEYSER4_HF_ISO, HID_QUIRK_APPLE_HAS_FN | HID_QUIRK_IGNORE_MOUSE }, - { USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_GEYSER4_HF_JIS, HID_QUIRK_APPLE_HAS_FN | HID_QUIRK_IGNORE_MOUSE }, - { USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_ALU_WIRELESS_ANSI, HID_QUIRK_APPLE_HAS_FN }, - { USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_ALU_WIRELESS_ISO, HID_QUIRK_APPLE_HAS_FN | HID_QUIRK_APPLE_ISO_KEYBOARD }, - { USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_ALU_WIRELESS_JIS, HID_QUIRK_APPLE_HAS_FN }, - { USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_FOUNTAIN_TP_ONLY, HID_QUIRK_APPLE_HAS_FN | HID_QUIRK_IGNORE_MOUSE }, - { USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_GEYSER1_TP_ONLY, HID_QUIRK_APPLE_HAS_FN | HID_QUIRK_IGNORE_MOUSE }, + { USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_GEYSER4_HF_ANSI, HID_QUIRK_APPLE_NUMLOCK_EMULATION | HID_QUIRK_APPLE_HAS_FN | HID_QUIRK_IGNORE_MOUSE }, + { USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_GEYSER4_HF_ISO, HID_QUIRK_APPLE_NUMLOCK_EMULATION | HID_QUIRK_APPLE_HAS_FN | HID_QUIRK_IGNORE_MOUSE }, + { USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_GEYSER4_HF_JIS, HID_QUIRK_APPLE_NUMLOCK_EMULATION | HID_QUIRK_APPLE_HAS_FN | HID_QUIRK_IGNORE_MOUSE }, + { USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_ALU_WIRELESS_ANSI, HID_QUIRK_APPLE_NUMLOCK_EMULATION | HID_QUIRK_APPLE_HAS_FN }, + { USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_ALU_WIRELESS_ISO, HID_QUIRK_APPLE_NUMLOCK_EMULATION | HID_QUIRK_APPLE_HAS_FN | HID_QUIRK_APPLE_ISO_KEYBOARD }, + { USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_ALU_WIRELESS_JIS, HID_QUIRK_APPLE_NUMLOCK_EMULATION | HID_QUIRK_APPLE_HAS_FN }, + { USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_FOUNTAIN_TP_ONLY, HID_QUIRK_APPLE_NUMLOCK_EMULATION | HID_QUIRK_APPLE_HAS_FN | HID_QUIRK_IGNORE_MOUSE }, + { USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_GEYSER1_TP_ONLY, HID_QUIRK_APPLE_NUMLOCK_EMULATION | HID_QUIRK_APPLE_HAS_FN | HID_QUIRK_IGNORE_MOUSE }, { USB_VENDOR_ID_DELL, USB_DEVICE_ID_DELL_W7658, HID_QUIRK_RESET_LEDS }, { USB_VENDOR_ID_LOGITECH, USB_DEVICE_ID_LOGITECH_KBD, HID_QUIRK_RESET_LEDS },
include/linux/hid.h +1 -0
@@ -284,6 +284,7 @@ struct hid_item {#define HID_QUIRK_2WHEEL_MOUSE_HACK_B8 0x02000000#define HID_QUIRK_HWHEEL_WHEEL_INVERT 0x04000000#define HID_QUIRK_MICROSOFT_KEYS 0x08000000 +#define HID_QUIRK_APPLE_NUMLOCK_EMULATION 0x10000000/* * Separate quirks for runtime report descriptor fixup
PATCH 35/50 CPUFREQ: Make acpi-cpufreq more robust against BIOS freq changes behind our back.
In reply to Chris Wright-stable review patch. If anyone has any objections, please let us know.
---------------------
From: Venkatesh Pallipadi <[email protected]>
upstream commit: e56a727b023d40d1adf660168883f30f2e6abe0a
We checked the hardware freq with OS cached freq value in get_cur_freqon_cpu().
--- arch/x86/kernel/cpu/cpufreq/acpi-cpufreq.c | 10 ++++++++++ 1 file changed, 10 insertions(+)
arch/x86/kernel/cpu/cpufreq/acpi-cpufreq.c +10 -0
@@ -339,6 +339,7 @@ static unsigned int get_cur_freq_on_cpu( {struct acpi_cpufreq_data *data =per_cpu (drv_data, cpu);unsigned int freq; +unsigned int cached_freq;dprintk ("get_cur_freq_on_cpu (%d)\n" , cpu);
@@ -347,7 +348,16 @@ static unsigned int get_cur_freq_on_cpu(return 0 ; } + cached_freq = data->freq_table[data->acpi_data->state].frequency; freq =extract_freq (get_cur_val (cpumask_of_cpu (cpu)), data); +if (freq != cached_freq) { +/* +* The dreaded BIOS frequency change behind our back. +* Force set the frequency on next target call. +*/ + data->resume =1 ; + } +dprintk ("cur freq = %u\n" , freq);return freq;
PATCH 36/50 x86, fpu: fix CONFIG_PREEMPT=y corruption of applications FPU stack
In reply to Chris Wright-stable review patch. If anyone has any objections, please let us know.
---------------------
From: Suresh Siddha <[email protected]>
upstream commit: 870568b39064cab2dd971fe57969916036982862
Jürgen Mell reported an FPU state corruption bug under CONFIG_PREEMPT, and bisected it to commit v2.6.19-1363-gacc2076, "i386: add sleazy FPU optimization".
Add tsk_used_math() checks to prevent calling math_state_restore() which can sleep in the case of !tsk_used_math(). This prevents making a blocking call in __switch_to().
Apparently "fpu_counter > 5" check is not enough, as in some signal handling and fork/exec scenarios, fpu_counter > 5 and !tsk_used_math() is possible.
It's a side effect though. This is the failing scenario:
process 'A' in save_i387_ia32() just after clear_used_math()
Got an interrupt and pre-empted out.
At the next context switch to process 'A' again, kernel tries to restore the math state proactively and sees a fpu_counter > 0 and !tsk_used_math()
This results in init_fpu() during the __switch_to()'s math_state_restore()
And resulting in fpu corruption which will be saved/restored (save_i387_fxsave and restore_i387_fxsave) during the remaining part of the signal handling after the context switch.
--- arch/x86/kernel/process_32.c | 5 ++++- arch/x86/kernel/process_64.c | 5 ++++- 2 files changed, 8 insertions(+), 2 deletions(-)
arch/x86/kernel/process_32.c +4 -1
@@ -710,8 +710,11 @@ struct task_struct * __switch_to(struct/* If the task has used fpu the last 5 timeslices, just do a full * restore of the math state immediately to avoid the trap; the * chances of needing FPU soon are obviously high now +* +* tsk_used_math() checks prevent calling math_state_restore(), +* which can sleep in the case of !tsk_used_math() */ -if (next_p->fpu_counter >5 ) +if (tsk_used_math (next_p) && next_p->fpu_counter >5 )math_state_restore ();/*
arch/x86/kernel/process_64.c +4 -1
@@ -696,8 +696,11 @@ __switch_to(struct task_struct *prev_p,/* If the task has used fpu the last 5 timeslices, just do a full * restore of the math state immediately to avoid the trap; the * chances of needing FPU soon are obviously high now +* +* tsk_used_math() checks prevent calling math_state_restore(), +* which can sleep in the case of !tsk_used_math() */ -if (next_p->fpu_counter>5 ) +if (tsk_used_math (next_p) && next_p->fpu_counter >5 )math_state_restore ();return prev_p; }
PATCH 37/50 netfilter: nf_conntrack_expect: fix error path unwind in nf_conntrack_expect_init()
In reply to Chris Wright-stable review patch. If anyone has any objections, please let us know.
---------------------
From: Patrick McHardy <[email protected]>
upstream commit: 12293bf91126ad253a25e2840b307fdc7c2754c3
---
net/netfilter/nf_conntrack_expect.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
net/netfilter/nf_conntrack_expect.c +2 -2
@@ -550,10 +550,10 @@ int __init nf_conntrack_expect_init(voidreturn 0 ; err3: +kmem_cache_destroy (nf_ct_expect_cachep); +err2:nf_ct_free_hashtable (nf_ct_expect_hash, nf_ct_expect_vmalloc, nf_ct_expect_hsize); -err2: -kmem_cache_destroy (nf_ct_expect_cachep); err1:return err; }
PATCH 38/50 netfilter: xt_connlimit: fix accouning when receive RST packet in ESTABLISHED state
In reply to Chris Wright-stable review patch. If anyone has any objections, please let us know.
---------------------
From: Patrick McHardy <[email protected]>
upstream commit: d2ee3f2c4b1db1320c1efb4dcaceeaf6c7e6c2d3
In xt_connlimit match module, the counter of an IP is decreased when the TCP packet is go through the chain with ip_conntrack state TW. Well, it's very natural that the server and client close the socket with FIN packet. But when the client/server close the socket with RST packet(using so_linger), the counter for this connection still exsit. The following patch can fix it which is based on linux-2.6.25.4
---
net/netfilter/xt_connlimit.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
net/netfilter/xt_connlimit.c +2 -1
@@ -75,7 +75,8 @@ static inline bool already_closed(constu_int16_t proto = conn->tuplehash[0 ].tuple.dst.protonum;if (proto ==IPPROTO_TCP ) -return conn->proto.tcp.state ==TCP_CONNTRACK_TIME_WAIT ; +return conn->proto.tcp.state ==TCP_CONNTRACK_TIME_WAIT || + conn->proto.tcp.state ==TCP_CONNTRACK_CLOSE ;else return 0 ; }
PATCH 39/50 netfilter: nf_conntrack_ipv6: fix inconsistent lock state in nf_ct_frag6_gather()
In reply to Chris Wright-stable review patch. If anyone has any objections, please let us know.
---------------------
From: Patrick McHardy <[email protected]>
upstream commit: b9c698964614f71b9c8afeca163a945b4c2e2d20
[ 63.531438] =================================
[ 63.531520] [ INFO: inconsistent lock state ]
[ 63.531520] 2.6.26-rc4 #7
[ 63.531520] ---------------------------------
[ 63.531520] inconsistent {softirq-on-W} -> {in-softirq-W} usage.
[ 63.531520] tcpsic6/3864 [HC0[0]:SC1[1]:HE1:SE0] takes:
[ 63.531520] (&q->lock#2){-+..}, at: [<c07175b0>] ipv6_frag_rcv+0xd0/0xbd0
[ 63.531520] {softirq-on-W} state was registered at:
[ 63.531520] [<c0143bba>] __lock_acquire+0x3aa/0x1080
[ 63.531520] [<c0144906>] lock_acquire+0x76/0xa0
[ 63.531520] [<c07a8f0b>] _spin_lock+0x2b/0x40
[ 63.531520] [<c0727636>] nf_ct_frag6_gather+0x3f6/0x910
...According to this and another similar lockdep report inet_fragment locks are taken from nf_ct_frag6_gather() with softirqs enabled, but these locks are mainly used in softirq context, so disabling BHs is necessary.
---
net/ipv6/netfilter/nf_conntrack_reasm.c | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-)
net/ipv6/netfilter/nf_conntrack_reasm.c +5 -3
@@ -209,7 +209,9 @@ fq_find(__be32 id, struct in6_addr *src, arg.dst = dst; hash =ip6qhashfn (id, src, dst); +local_bh_disable (); q =inet_frag_find (&nf_init_frags, &nf_frags, &arg, hash); +local_bh_enable ();if (q ==NULL ) goto oom;
@@ -638,10 +640,10 @@ struct sk_buff *nf_ct_frag6_gather(struc goto ret_orig; } -spin_lock (&fq->q.lock); +spin_lock_bh (&fq->q.lock);if (nf_ct_frag6_queue (fq, clone, fhdr, nhoff) <0 ) { -spin_unlock (&fq->q.lock); +spin_unlock_bh (&fq->q.lock);pr_debug ("Can't insert skb to queue\n" );fq_put (fq); goto ret_orig;
@@ -652,7 +654,7 @@ struct sk_buff *nf_ct_frag6_gather(strucif (ret_skb ==NULL )pr_debug ("Can't reassemble fragmented packets\n" ); } -spin_unlock (&fq->q.lock); +spin_unlock_bh (&fq->q.lock);fq_put (fq);return ret_skb;
PATCH 40/50 atl1: fix 4G memory corruption bug
In reply to Chris Wright-stable review patch. If anyone has any objections, please let us know.
---------------------
From: Alexey Dobriyan <[email protected]>
upstream commit: aefdbf1a3b832a580a50cf3d1dcbb717be7cbdbe
When using 4+ GB RAM and SWIOTLB is active, the driver corrupts memory by writing an skb after the relevant DMA page has been unmapped. Although this doesn't happen when *not* using bounce buffers, clearing the pointer to the DMA page after unmapping it fixes the problem.
http://marc.info/?t=120861317000005&r=2&w=2
--- drivers/net/atl1/atl1_main.c | 1 + 1 file changed, 1 insertion(+)
drivers/net/atl1/atl1_main.c +1 -0
@@ -1334,6 +1334,7 @@ rrd_ok:/* Good Receive */ pci_unmap_page (adapter->pdev, buffer_info->dma, buffer_info->length,PCI_DMA_FROMDEVICE ); + buffer_info->dma =0 ; skb = buffer_info->skb; length =le16_to_cpu (rrd->xsz.xsum_sz.pkt_size);
PATCH 41/50 Smack: fuse mount hang fix
In reply to Chris Wright-stable review patch. If anyone has any objections, please let us know.
---------------------
From: Casey Schaufler <[email protected]>
upstream commit: e97dcb0eadbb821eccd549d4987b653cf61e2374
The d_instantiate hook for Smack can hang on the root inode of a filesystem if the file system code has not really done all the set-up. Fuse is known to encounter this problem.
This change detects an attempt to instantiate a root inode and addresses it early in the processing, before any attempt is made to do something that might hang.
--- security/smack/smack_lsm.c | 12 ++++++++++++ 1 file changed, 12 insertions(+)
security/smack/smack_lsm.c +12 -0
@@ -1865,6 +1865,18 @@ static void smack_d_instantiate(struct d final = sbsp->smk_default;/* +* If this is the root inode the superblock +* may be in the process of initialization. +* If that is the case use the root value out +* of the superblock. +*/ +if (opt_dentry->d_parent == opt_dentry) { + isp->smk_inode = sbsp->smk_root; + isp->smk_flags |=SMK_INODE_INSTANT ; + goto unlockandout; + } + +/* * This is pretty hackish. * Casey says that we shouldn't have to do * file system specific code, but it does help
PATCH 42/50 proc: calculate the correct /proc/<pid> link count
In reply to Chris Wright-stable review patch. If anyone has any objections, please let us know.
---------------------
From: Vegard Nossum <[email protected]>
upstream commit: aed5417593ad125283f35513573282139a8664b5
This patch:
commit e9720acd728a46cb40daa52c99a979f7c4ff195c
Author: Pavel Emelyanov <[email protected]>
Date: Fri Mar 7 11:08:40 2008 -0800
[NET]: Make /proc/net a symlink on /proc/self/net (v3)
introduced a /proc/self/net directory without bumping the corresponding link count for /proc/self.
This patch replaces the static link count initializations with a call that counts the number of directory entries in the given pid_entry table whenever it is instantiated, and thus relieves the burden of manually keeping the two in sync.
--- fs/proc/base.c | 33 +++++++++++++++++++++++++-------- 1 file changed, 25 insertions(+), 8 deletions(-)
fs/proc/base.c +25 -8
@@ -126,6 +126,25 @@ struct pid_entry { NULL, &proc_single_file_operations, \ { .proc_show = &proc_##OTYPE } ) +/* +* Count the number of hardlinks for the pid_entry table, excluding the . +* and .. links. +*/ +static unsigned int pid_entry_count_dirs (const struct pid_entry *entries, +unsigned int n) +{ +unsigned int i; +unsigned int count; + + count =0 ; +for (i =0 ; i < n; ++i) { +if (S_ISDIR (entries[i].mode)) + ++count; + } + +return count; +} +int maps_protect;EXPORT_SYMBOL (maps_protect);
@@ -2483,10 +2502,9 @@ static struct dentry *proc_pid_instantia inode->i_op = &proc_tgid_base_inode_operations; inode->i_fop = &proc_tgid_base_operations; inode->i_flags|=S_IMMUTABLE ; - inode->i_nlink =5 ; -#ifdef CONFIG_SECURITY - inode->i_nlink +=1 ; -#endif + + inode->i_nlink =2 +pid_entry_count_dirs (tgid_base_stuff, +ARRAY_SIZE (tgid_base_stuff)); dentry->d_op = &pid_dentry_operations;
@@ -2713,10 +2731,9 @@ static struct dentry *proc_task_instanti inode->i_op = &proc_tid_base_inode_operations; inode->i_fop = &proc_tid_base_operations; inode->i_flags|=S_IMMUTABLE ; - inode->i_nlink =4 ; -#ifdef CONFIG_SECURITY - inode->i_nlink +=1 ; -#endif + + inode->i_nlink =2 +pid_entry_count_dirs (tid_base_stuff, +ARRAY_SIZE (tid_base_stuff)); dentry->d_op = &pid_dentry_operations;
PATCH 43/50 pagemap: fix bug in add_to_pagemap, require aligned-length reads of /proc/pid/pagemap
In reply to Chris Wright-stable review patch. If anyone has any objections, please let us know.
---------------------
From: Thomas Tuttle <[email protected]>
upstream commit: aae8679b0ebcaa92f99c1c3cb0cd651594a43915
Fix a bug in add_to_pagemap. Previously, since pm->out was a char *, put_user was only copying 1 byte of every PFN, resulting in the top 7 bytes of each PFN not being copied. By requiring that reads be a multiple of 8 bytes, I can make pm->out and pm->end u64*s instead of char*s, which makes put_user work properly, and also simplifies the logic in add_to_pagemap a bit.
--- fs/proc/task_mmu.c | 28 +++++++++------------------- 1 file changed, 9 insertions(+), 19 deletions(-)
fs/proc/task_mmu.c +9 -19
@@ -524,7 +524,7 @@ const struct file_operations proc_clear_ };struct pagemapread { -char __user *out, *end; +u64 __user *out, *end; };#define PM_ENTRY_BYTES sizeof(u64)
@@ -547,21 +547,11 @@ struct pagemapread {static int add_to_pagemap (unsigned long addr,u64 pfn,struct pagemapread *pm) { -/* -* Make sure there's room in the buffer for an -* entire entry. Otherwise, only copy part of -* the pfn. -*/ -if (pm->out +PM_ENTRY_BYTES >= pm->end) { -if (copy_to_user (pm->out, &pfn, pm->end - pm->out)) -return -EFAULT ; - pm->out = pm->end; -return PM_END_OF_BUFFER ; - } -if (put_user (pfn, pm->out))return -EFAULT ; - pm->out +=PM_ENTRY_BYTES ; + pm->out++; +if (pm->out >= pm->end) +return PM_END_OF_BUFFER ;return 0 ; }
@@ -662,7 +652,7 @@ static ssize_t pagemap_read(struct file ret = -EINVAL ;/* file position must be aligned */ -if (*ppos %PM_ENTRY_BYTES ) +if ((*ppos %PM_ENTRY_BYTES ) || (count %PM_ENTRY_BYTES )) goto out_task; ret =0 ;
@@ -692,8 +682,8 @@ static ssize_t pagemap_read(struct file goto out_pages; } - pm.out = buf; - pm.end = buf + count; + pm.out = (u64 *)buf; + pm.end = (u64 *)(buf + count);if (!ptrace_may_attach (task)) { ret = -EIO ;
@@ -718,9 +708,9 @@ static ssize_t pagemap_read(struct fileif (ret ==PM_END_OF_BUFFER ) ret =0 ;/* don't need mmap_sem for these, but this looks cleaner */ - *ppos += pm.out - buf; + *ppos += (char *)pm.out - buf;if (!ret) - ret = pm.out - buf; + ret = (char *)pm.out - buf; } out_pages:
PATCH 44/50 brk: make sys_brk() honor COMPAT_BRK when computing lower bound
In reply to Chris Wright-stable review patch. If anyone has any objections, please let us know.
---------------------
From: Jiri Kosina <[email protected]>
upstream commit: a5b4592cf77b973c29e7c9695873a26052b58951
Fix a regression introduced by
commit 4cc6028d4040f95cdb590a87db478b42b8be0508
Author: Jiri Kosina <[email protected]> Date: Wed Feb 6 22:39:44 2008 +0100
brk: check the lower bound properly
The check in sys_brk() on minimum value the brk might have must take CONFIG_COMPAT_BRK setting into account. When this option is turned on (i.e. we support ancient legacy binaries, e.g. libc5-linked stuff), the lower bound on brk value is mm->end_code, otherwise the brk start is allowed to be arbitrarily shifted.
--- mm/mmap.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-)
mm/mmap.c +7 -1
@@ -242,10 +242,16 @@ asmlinkage unsigned long sys_brk(unsigneunsigned long rlim, retval;unsigned long newbrk, oldbrk;struct mm_struct *mm = current->mm; +unsigned long min_brk;down_write (&mm->mmap_sem); -if (brk < mm->start_brk) +#ifdef CONFIG_COMPAT_BRK + min_brk = mm->end_code; +#else + min_brk = mm->start_brk; +#endif +if (brk < min_brk) goto out;/*
PATCH 45/50 eCryptfs: remove unnecessary page decrypt call
In reply to Chris Wright-stable review patch. If anyone has any objections, please let us know.
---------------------
From: Michael Halcrow <[email protected]>
upstream commit: d3e49afbb66109613c3474f2273f5830ac2dcb09
The page decrypt calls in ecryptfs_write() are both pointless and buggy. Pointless because ecryptfs_get_locked_page() has already brought the page up to date, and buggy because prior mmap writes will just be blown away by the decrypt call.
This patch also removes the declaration of a now-nonexistent function ecryptfs_write_zeros().
Thanks to Eric Sandeen and David Kleikamp for helping to track this down.
Eric said:
fsx w/ mmap dies quickly ( < 100 ops) without this, and survives nicely (to millions of ops+) with it in place.
--- fs/ecryptfs/ecryptfs_kernel.h | 2 -- fs/ecryptfs/read_write.c | 22 ---------------------- 2 files changed, 24 deletions(-)
fs/ecryptfs/ecryptfs_kernel.h +0 -2
@@ -626,8 +626,6 @@ int ecryptfs_get_tfm_and_mutex_for_cipheint ecryptfs_keyring_auth_tok_for_sig (struct key **auth_tok_key,struct ecryptfs_auth_tok **auth_tok,char *sig); -int ecryptfs_write_zeros (struct file *file,pgoff_t index,int start, -int num_zeros);int ecryptfs_write_lower (struct inode *ecryptfs_inode,char *data,loff_t offset,size_t size); int ecryptfs_write_lower_page_segment(struct inode *ecryptfs_inode,
fs/ecryptfs/read_write.c +0 -22
@@ -157,20 +157,6 @@ int ecryptfs_write(struct file *ecryptfs ecryptfs_page_idx, rc); goto out; } -if (start_offset_in_page) { -/* Read in the page from the lower -* into the eCryptfs inode page cache, -* decrypting */ - rc =ecryptfs_decrypt_page (ecryptfs_page); -if (rc) { -printk (KERN_ERR "%s: Error decrypting " -"page; rc = [%d]\n" , - __FUNCTION__, rc); -ClearPageUptodate (ecryptfs_page); -page_cache_release (ecryptfs_page); - goto out; - } - } ecryptfs_page_virt =kmap_atomic (ecryptfs_page,KM_USER0 );/*
@@ -349,14 +335,6 @@ int ecryptfs_read(char *data, loff_t off ecryptfs_page_idx, rc); goto out; } - rc =ecryptfs_decrypt_page (ecryptfs_page); -if (rc) { -printk (KERN_ERR "%s: Error decrypting " -"page; rc = [%d]\n" , __FUNCTION__, rc); -ClearPageUptodate (ecryptfs_page); -page_cache_release (ecryptfs_page); - goto out; - } ecryptfs_page_virt =kmap_atomic (ecryptfs_page,KM_USER0 ); memcpy((data + data_offset), ((char *)ecryptfs_page_virt + start_offset_in_page),
PATCH 46/50 md: do not compute parity unless it is on a failed drive
In reply to Chris Wright-stable review patch. If anyone has any objections, please let us know.
---------------------
From: Dan Williams <[email protected]>
upstream commit: c337869d95011495fa181536786e74aa2d7ff031
If a block is computed (rather than read) then a check/repair operation may be lead to believe that the data on disk is correct, when infact it isn't. So only compute blocks for failed devices.
This issue has been around since at least 2.6.12, but has become harder to hit in recent kernels since most reads bypass the cache.
echo repair > /sys/block/mdN/md/sync_action will set the parity blocks to the correct state.
--- drivers/md/raid5.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)
drivers/md/raid5.c +4 -1
@@ -1984,6 +1984,7 @@ static int __handle_issuing_new_read_req* have quiesced. */ if ((s->uptodate == disks -1 ) && + (s->failed && disk_idx == s->failed_num) && !test_bit (STRIPE_OP_CHECK , &sh->ops.pending)) {set_bit (STRIPE_OP_COMPUTE_BLK , &sh->ops.pending);set_bit (R5_Wantcompute, &dev->flags);
@@ -2069,7 +2070,9 @@ static void handle_issuing_new_read_requ/* we would like to get this block, possibly * by computing it, but we might not be able to */ -if (s->uptodate == disks-1 ) { +if ((s->uptodate == disks -1 ) && + (s->failed && (i == r6s->failed_num[0 ] || + i == r6s->failed_num[1 ]))) {pr_debug ("Computing stripe %llu block %d\n" , (unsigned long long )sh->sector, i);compute_block_1 (sh, i,0 );
PATCH 47/50 md: fix uninitialized use of mddev->recovery_wait
In reply to Chris Wright-stable review patch. If anyone has any objections, please let us know.
---------------------
From: Dan Williams <[email protected]>
upstream commit: a6d8113a986c66aeb379a26b6e0062488b3e59e1
If an array was created with --assume-clean we will oops when trying to set ->resync_max.
Fix this by initializing ->recovery_wait in mddev_find.
--- drivers/md/md.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/md/md.c +1 -1
@@ -274,6 +274,7 @@ static mddev_t * mddev_find(dev_t unit)atomic_set (&new->active,1 );spin_lock_init (&new->write_lock);init_waitqueue_head (&new->sb_wait); +init_waitqueue_head (&new->recovery_wait); new->reshape_position = MaxSector; new->resync_max = MaxSector;
@@ -5559,7 +5560,6 @@ void md_do_sync(mddev_t *mddev) window/2,(unsigned long long) max_sectors/2);atomic_set (&mddev->recovery_active,0 ); -init_waitqueue_head (&mddev->recovery_wait); last_check =0 ;if (j>2 ) {
PATCH 48/50 md: fix prexor vs sync_request race
In reply to Chris Wright-stable review patch. If anyone has any objections, please let us know.
---------------------
From: Dan Williams <[email protected]>
upstream commit: e0a115e5aa554b93150a8dc1c3fe15467708abb2
During the initial array synchronization process there is a window between when a prexor operation is scheduled to a specific stripe and when it completes for a sync_request to be scheduled to the same stripe. When this happens the prexor completes and the stripe is unconditionally marked "insync", effectively canceling the sync_request for the stripe. Prior to 2.6.23 this was not a problem because the prexor operation was done under sh->lock. The effect in older kernels being that the prexor would still erroneously mark the stripe "insync", but sync_request would be held off and re-mark the stripe as "!in_sync".
Change the write completion logic to not mark the stripe "in_sync" if a prexor was performed. The effect of the change is to sometimes not set STRIPE_INSYNC. The worst this can do is cause the resync to stall waiting for STRIPE_INSYNC to be set. If this were happening, then STRIPE_SYNCING would be set and handle_issuing_new_read_requests would cause all available blocks to eventually be read, at which point prexor would never be used on that stripe any more and STRIPE_INSYNC would eventually be set.
echo repair > /sys/block/mdN/md/sync_action will correct arrays that may have lost this race.
--- drivers/md/raid5.c | 5 +++++ 1 file changed, 5 insertions(+)
drivers/md/raid5.c +5 -0
@@ -2621,6 +2621,7 @@ static void handle_stripe5(struct stripestruct stripe_head_state s;struct r5dev *dev;unsigned long pending =0 ; +int prexor;memset (&s,0 ,sizeof (s)); pr_debug("handling stripe %llu, state=%#lx cnt=%d, pd_idx=%d "
@@ -2740,9 +2741,11 @@ static void handle_stripe5(struct stripe/* leave prexor set until postxor is done, allows us to distinguish * a rmw from a rcw during biodrain */ + prexor =0 ;if (test_bit (STRIPE_OP_PREXOR , &sh->ops.complete) &&test_bit (STRIPE_OP_POSTXOR , &sh->ops.complete)) { + prexor =1 ;clear_bit (STRIPE_OP_PREXOR , &sh->ops.complete);clear_bit (STRIPE_OP_PREXOR , &sh->ops.ack);clear_bit (STRIPE_OP_PREXOR , &sh->ops.pending);
@@ -2776,6 +2779,8 @@ static void handle_stripe5(struct stripeif (!test_and_set_bit (STRIPE_OP_IO , &sh->ops.pending)) sh->ops.count++; +if (prexor) +continue ;if (!test_bit (R5_Insync, &dev->flags) || (i == sh->pd_idx && s.failed ==0 ))set_bit (STRIPE_INSYNC , &sh->state);
PATCH 49/50 capabilities: remain source compatible with 32-bit raw legacy capability support.
In reply to Chris Wright-stable review patch. If anyone has any objections, please let us know.
---------------------
From: Andrew G. Morgan <[email protected]>
upstream commit: ca05a99a54db1db5bca72eccb5866d2a86f8517f
Source code out there hard-codes a notion of what the _LINUX_CAPABILITY_VERSION #define means in terms of the semantics of the raw capability system calls capget() and capset(). Its unfortunate, but true.
Since the confusing header file has been in a released kernel, there is software that is erroneously using 64-bit capabilities with the semantics of 32-bit compatibilities. These recently compiled programs may suffer corruption of their memory when sys_getcap() overwrites more memory than they are coded to expect, and the raising of added capabilities when using sys_capset().
As such, this patch does a number of things to clean up the situation for all. It
1. forces the _LINUX_CAPABILITY_VERSION define to always retain its legacy value.
2. adopts a new #define strategy for the kernel's internal implementation of the preferred magic.
3. deprecates v2 capability magic in favor of a new (v3) magic number. The functionality of v3 is entirely equivalent to v2, the only difference being that the v2 magic causes the kernel to log a "deprecated" warning so the admin can find applications that may be using v2 inappropriately.
[User space code continues to be encouraged to use the libcap API which protects the application from details like this. libcap-2.10 is the first to support v3 capabilities.]
Fixes issue reported in https://bugzilla.redhat.com/show_bug.cgi?id=447518.
Thanks to Bojan Smojver for the report.
--- fs/proc/array.c | 2 include/linux/capability.h | 29 ++++++++--- kernel/capability.c | 111 +++++++++++++++++++++++++++++---------------- 3 files changed, 95 insertions(+), 47 deletions(-)
fs/proc/array.c +1 -1
@@ -287,7 +287,7 @@ static void render_cap_t(struct seq_fileseq_printf (m,"%s" , header);CAP_FOR_EACH_U32 (__capi) {seq_printf (m,"%08x" , - a->cap[(_LINUX_CAPABILITY_U32S-1 ) - __capi]); + a->cap[(_KERNEL_CAPABILITY_U32S-1 ) - __capi]); }seq_printf (m,"\n" ); }
include/linux/capability.h +21 -8
@@ -31,11 +31,11 @@ struct task_struct;#define _LINUX_CAPABILITY_VERSION_1 0x19980330#define _LINUX_CAPABILITY_U32S_1 1 -#define _LINUX_CAPABILITY_VERSION_2 0x20071026 +#define _LINUX_CAPABILITY_VERSION_2 0x20071026/* deprecated - use v3 */ #define _LINUX_CAPABILITY_U32S_2 2 -#define _LINUX_CAPABILITY_VERSION _LINUX_CAPABILITY_VERSION_2 -#define _LINUX_CAPABILITY_U32S _LINUX_CAPABILITY_U32S_2 +#define _LINUX_CAPABILITY_VERSION_3 0x20080522 +#define _LINUX_CAPABILITY_U32S_3 2 typedef struct __user_cap_header_struct { __u32 version;
@@ -77,10 +77,23 @@ struct vfs_cap_data { } data[VFS_CAP_U32 ]; }; -#ifdef __KERNEL__ +#ifndef __KERNEL__ + +/* +* Backwardly compatible definition for source code - trapped in a +* 32-bit world. If you find you need this, please consider using +* libcap to untrap yourself... +*/ +#define _LINUX_CAPABILITY_VERSION _LINUX_CAPABILITY_VERSION_1 +#define _LINUX_CAPABILITY_U32S _LINUX_CAPABILITY_U32S_1 + +#else + +#define _KERNEL_CAPABILITY_VERSION _LINUX_CAPABILITY_VERSION_3 +#define _KERNEL_CAPABILITY_U32S _LINUX_CAPABILITY_U32S_3typedef struct kernel_cap_struct { -__u32 cap[_LINUX_CAPABILITY_U32S]; +__u32 cap[_KERNEL_CAPABILITY_U32S]; }kernel_cap_t ;#define _USER_CAP_HEADER_SIZE (sizeof(struct __user_cap_header_struct))
@@ -350,7 +363,7 @@ typedef struct kernel_cap_struct {*/ #define CAP_FOR_EACH_U32 (__capi) \ - for (__capi = 0; __capi < _LINUX_CAPABILITY_U32S; ++__capi) + for (__capi = 0; __capi < _KERNEL_CAPABILITY_U32S; ++__capi)# define CAP_FS_MASK_B0 (CAP_TO_MASK(CAP_CHOWN) \ | CAP_TO_MASK(CAP_DAC_OVERRIDE) \
@@ -360,7 +373,7 @@ typedef struct kernel_cap_struct {# define CAP_FS_MASK_B1 (CAP_TO_MASK(CAP_MAC_OVERRIDE)) -#if _LINUX_CAPABILITY_U32S !=2 +#if _KERNEL_CAPABILITY_U32S !=2 # error Fix up hand-coded capability macro initializers#else /* HAND-CODED capability initializers */
@@ -371,7 +384,7 @@ typedef struct kernel_cap_struct {# define CAP_NFSD_SET {{ CAP_FS_MASK_B0|CAP_TO_MASK(CAP_SYS_RESOURCE), \ CAP_FS_MASK_B1 } } -#endif /* _LINUX_CAPABILITY_U32S != 2 */ +#endif /* _KERNEL_CAPABILITY_U32S != 2 */ #define CAP_INIT_INH_SET CAP_EMPTY_SET
kernel/capability.c +73 -38
157 lines not on this page · raw message
PATCH 50/50 cpufreq: fix null object access on Transmeta CPU
In reply to Chris Wright-stable review patch. If anyone has any objections, please let us know.
---------------------
From: CHIKAMA masaki <[email protected]>
upstream commit: 879000f94442860e72c934f9e568989bc7fb8ec4
If cpu specific cpufreq driver(i.e. longrun) has "setpolicy" function, governor object isn't set into cpufreq_policy object at "__cpufreq_set_policy" function in driver/cpufreq/cpufreq.c .
This causes a null object access at "store_scaling_setspeed" and "show_scaling_setspeed" function in driver/cpufreq/cpufreq.c when reading or writing through /sys interface (ex. cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed)
Addresses:
http://bugzilla.kernel.org/show_bug.cgi?id=10654 https://bugzilla.redhat.com/show_bug.cgi?id=443354
--- drivers/cpufreq/cpufreq.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/cpufreq/cpufreq.c +2 -2
@@ -607,7 +607,7 @@ static ssize_t store_scaling_setspeed(stunsigned int freq =0 ;unsigned int ret; -if (!policy->governor->store_setspeed) +if (!policy->governor || !policy->governor->store_setspeed)return -EINVAL ; ret =sscanf (buf,"%u" , &freq);
@@ -621,7 +621,7 @@ static ssize_t store_scaling_setspeed(ststatic ssize_t show_scaling_setspeed (struct cpufreq_policy *policy,char *buf) { -if (!policy->governor->show_setspeed) +if (!policy->governor || !policy->governor->show_setspeed)return sprintf (buf,"<unsupported>\n" );return policy->governor->show_setspeed (policy, buf);
Quoted 5 lines · Chris Wright
This is the start of the stable review cycle for the 2.6.25.6 release. There are 50 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 us know. If anyone is a maintainer of the proper subsystem, and wants to add a Signed-off-by: line to the patch, please respond with it.
Please add 2.6.26-rc5's 2884f110d5409714f3a04eeb6d2ecd77da66b242 into 2.6.25.6: it's actually not a serious problem, but it does look as if it's a serious problem, so we should stamp it out.
Thanks,
Hugh
x86: fix bad pmd ffff810000207xxx(9090909090909090)
OGAWA Hirofumi and Fede have reported rare pmd_ERROR messages:mm/memory.c:127: bad pmd ffff810000207xxx(9090909090909090).
Initialization's cleanup_highmap was leaving alignment filler behind in the pmd for MODULES_VADDR: when vmalloc's guard page would occupy a new page table, it's not allocated, and then module unload's vfree hits the bad 9090 pmd entry left over.
---
arch/x86/mm/init_64.c +1 -1
@@ -206,7 +206,7 @@ void __init cleanup_highmap(void)pmd_t *last_pmd = pmd +PTRS_PER_PMD ;for (; pmd < last_pmd; pmd++, vaddr +=PMD_SIZE ) { -if (!pmd_present (*pmd)) +if (pmd_none (*pmd))continue ;if (vaddr < (unsigned long ) _text || vaddr > end)set_pmd (pmd,__pmd (0 ));
Quoted 3 lines · * Hugh Dickins ([email protected]) wrote:
Please add 2.6.26-rc5's
2884f110d5409714f3a04eeb6d2ecd77da66b242into 2.6.25.6: it's actually not a serious problem, but it does look as if it's a serious problem, so we should stamp it out.
Got it, thanks for the reminder.
-chris