3.1.10-stable review
Subsystems (35)
cover 3.1.10-stable review
Note, this is the LAST 3.1.y stable release. Everyone should move to the 3.2 kernel series now.
This is the start of the stable review cycle for the 3.1.10 release. There are 48 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.
Responses should be made by Wed, January 18, 2012, 18:00: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/v3.0/stable-review/patch-3.1.10-rc1.gz
and the diffstat can be found below.
thanks,
greg k-h
Documentation/virtual/kvm/api.txt | 7 ++ Makefile | 4 +- arch/x86/include/asm/amd_nb.h | 2 + arch/x86/kernel/amd_nb.c | 31 +++++++++ arch/x86/kernel/kvmclock.c | 5 +- arch/x86/kvm/i8254.c | 10 ++- arch/x86/mm/mmap.c | 4 +- arch/x86/pci/Makefile | 3 +- arch/x86/pci/acpi.c | 18 +++++- arch/x86/pci/amd_bus.c | 42 +++--------- drivers/gpu/drm/radeon/r100.c | 5 +- drivers/gpu/drm/radeon/r600_hdmi.c | 7 ++ drivers/gpu/drm/radeon/radeon_device.c | 5 +- drivers/gpu/drm/radeon/rs600.c | 4 +- drivers/hid/Kconfig | 1 + drivers/hid/hid-core.c | 2 +- drivers/md/raid1.c | 11 +++- drivers/mtd/mtd_blkdevs.c | 3 +- drivers/mtd/mtdoops.c | 5 +- drivers/mtd/tests/mtd_stresstest.c | 7 ++ drivers/mtd/ubi/eba.c | 6 +- drivers/mtd/ubi/ubi.h | 2 + drivers/mtd/ubi/wl.c | 12 ++- drivers/net/wireless/rtlwifi/rtl8192se/fw.c | 4 + drivers/pci/msi.c | 10 +++ drivers/platform/x86/ideapad-laptop.c | 2 + drivers/pnp/quirks.c | 42 ++++++++++++ drivers/rtc/interface.c | 4 +- drivers/scsi/mpt2sas/mpt2sas_base.c | 83 ++++++++---------------- drivers/scsi/mpt2sas/mpt2sas_scsih.c | 11 ++-- drivers/xen/xenbus/xenbus_xs.c | 6 ++ fs/ext4/super.c | 7 +- fs/nfs/callback_proc.c | 2 +- fs/nfs/file.c | 4 +- fs/nfs/nfs4proc.c | 96 ++++++++++++++++----------- fs/nfs/nfs4xdr.c | 31 +++++++-- fs/nfs/super.c | 43 +++++------- include/linux/memcontrol.h | 6 ++ include/linux/nfs_xdr.h | 5 ++ include/linux/pci_regs.h | 2 +- include/linux/sunrpc/xdr.h | 2 + include/xen/interface/io/xs_wire.h | 3 + init/do_mounts.c | 35 +++++++++- mm/filemap.c | 18 +----- mm/memcontrol.c | 44 ++++++++++++ mm/slub.c | 5 ++ net/mac80211/wpa.c | 2 +- net/sunrpc/xdr.c | 3 +- security/integrity/ima/ima_api.c | 4 +- security/integrity/ima/ima_queue.c | 17 ++++-- sound/pci/hda/hda_local.h | 7 ++- sound/pci/hda/hda_proc.c | 2 + sound/pci/hda/patch_cirrus.c | 27 ++------ sound/pci/hda/patch_conexant.c | 2 - sound/pci/hda/patch_sigmatel.c | 36 +++++++---- sound/pci/hda/patch_via.c | 5 +- sound/pci/ice1712/amp.c | 7 ++- sound/usb/usx2y/usb_stream.c | 6 +- virt/kvm/assigned-dev.c | 93 +++++++++++++++++++++++--- 59 files changed, 591 insertions(+), 281 deletions(-)
PATCH 1/48 mtdoops: fix the oops_page_used array size
3.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Roman Tereshonkov <[email protected]>
commit 556f063580db2953a7e53cd46b47724246320f60 upstream.
The array of unsigned long pointed by oops_page_used is allocated by vmalloc which requires the size to be in bytes.
BITS_PER_LONG is equal to 32.
If we want to allocate memory for 32 pages with one bit per page then 32 / BITS_PER_LONG is equal to 1 byte that is 8 bits.
To fix it we need to multiply the result by sizeof(unsigned long) equal to 4.
--- drivers/mtd/mtdoops.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/mtd/mtdoops.c +1 -1
@@ -369,7 +369,7 @@ static void mtdoops_notify_add(struct mt/* oops_page_used is a bit field */ cxt->oops_page_used =vmalloc (DIV_ROUND_UP (mtdoops_pages, -BITS_PER_LONG )); +BITS_PER_LONG ) *sizeof (unsigned long ));if (!cxt->oops_page_used) {printk (KERN_ERR "mtdoops: could not allocate page array\n" );return ;
PATCH 2/48 mtd: mtdoops: skip reading initially bad blocks
In reply to Greg KH3.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Roman Tereshonkov <[email protected]>
commit 3538c56329936c78f7d356889908790006d0124c upstream.
Use block_isbad to check and skip the bad blocks reading. This will allow to get rid of the read errors if bad blocks are present initially.
--- drivers/mtd/mtdoops.c | 3 +++ 1 file changed, 3 insertions(+)
drivers/mtd/mtdoops.c +3 -0
@@ -253,6 +253,9 @@ static void find_next_position(struct mtsize_t retlen;for (page =0 ; page < cxt->oops_pages; page++) { +if (mtd->block_isbad && + mtd->block_isbad (mtd, page * record_size)) +continue ;/* Assume the page is used */ mark_page_used (cxt, page); ret = mtd->read(mtd, page * record_size, MTDOOPS_HEADER_SIZE,
PATCH 3/48 mtd: mtd_blkdevs: dont increase open count on error path
In reply to Greg KH3.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Brian Norris <[email protected]>
commit 342ff28f5a2e5aa3236617bd2bddf6c749677ef2 upstream.
Some error paths in mtd_blkdevs were fixed in the following commit:
commit 94735ec4044a6d318b83ad3c5794e931ed168d10
mtd: mtd_blkdevs: fix error path in blktrans_open
But on these error paths, the block device's `dev->open' count is already incremented before we check for errors. This meant that, while the error path was handled correctly on the first time through blktrans_open(), the device is erroneously considered already open on the second time through.
This problem can be seen, for instance, when a UBI volume is simultaneously mounted as a UBIFS partition and read through its corresponding gluebi mtdblockX device. This results in blktrans_open() passing its error checks (with `dev->open > 0') without actually having a handle on the device. Here's a summarized log of the actions and results with nandsim:
# modprobe nandsim
# modprobe mtdblock
# modprobe gluebi
# modprobe ubifs
# ubiattach /dev/ubi_ctrl -m 0
...
# ubimkvol /dev/ubi0 -N test -s 16MiB
...
# mount -t ubifs ubi0:test /mnt
# ls /dev/mtdblock*
/dev/mtdblock0 /dev/mtdblock1
# cat /dev/mtdblock1 > /dev/null
cat: can't open '/dev/mtdblock4': Device or resource busy
# cat /dev/mtdblock1 > /dev/null CPU 0 Unable to handle kernel paging request at virtual address
fffffff0, epc == 8031536c, ra == 8031f280
Oops[#1]:
...
Call Trace:
[<8031536c>] ubi_leb_read+0x14/0x164
[<8031f280>] gluebi_read+0xf0/0x148
[<802edba8>] mtdblock_readsect+0x64/0x198
[<802ecfe4>] mtd_blktrans_thread+0x330/0x3f4
[<8005be98>] kthread+0x88/0x90
[<8000bc04>] kernel_thread_helper+0x10/0x18--- drivers/mtd/mtd_blkdevs.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
drivers/mtd/mtd_blkdevs.c +2 -1
@@ -215,7 +215,7 @@ static int blktrans_open(struct block_demutex_lock (&dev->lock); -if (dev->open++) +if (dev->open) goto unlock;kref_get (&dev->ref);
@@ -235,6 +235,7 @@ static int blktrans_open(struct block_de goto error_release; unlock: + dev->open++;mutex_unlock (&dev->lock);blktrans_dev_put (dev);return ret;
PATCH 4/48 mtd: tests: stresstest: bail out if device has not enough eraseblocks
In reply to Greg KH3.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Wolfram Sang <[email protected]>
commit 2f4478ccff7df845dc9c0f8996a96373122c4417 upstream.
stresstest needs at least two eraseblocks. Bail out gracefully if that condition is not met. Fixes the following 'division by zero' OOPS:
[ 619.100000] mtd_stresstest: MTD device size 131072, eraseblock size 131072, page size 2048, count of eraseblocks 1, pages per eraseblock 64, OOB size 64 [ 619.120000] mtd_stresstest: scanning for bad eraseblocks [ 619.120000] mtd_stresstest: scanned 1 eraseblocks, 0 are bad [ 619.130000] mtd_stresstest: doing operations [ 619.130000] mtd_stresstest: 0 operations done [ 619.140000] Division by zero in kernel.
...
caused by
/* Read or write up 2 eraseblocks at a time - hence 'ebcnt - 1' */
eb %= (ebcnt - 1);--- drivers/mtd/tests/mtd_stresstest.c | 7 +++++++ 1 file changed, 7 insertions(+)
drivers/mtd/tests/mtd_stresstest.c +7 -0
@@ -277,6 +277,12 @@ static int __init mtd_stresstest_init(vo (unsigned long long )mtd->size, mtd->erasesize, pgsize, ebcnt, pgcnt, mtd->oobsize); +if (ebcnt <2 ) { +printk (PRINT_PREF "error: need at least 2 eraseblocks\n" ); + err = -ENOSPC ; + goto out_put_mtd; + } +/* Read or write up 2 eraseblocks at a time */ bufsize = mtd->erasesize *2 ;
@@ -315,6 +321,7 @@ out:kfree (bbt);vfree (writebuf);vfree (readbuf); +out_put_mtd:put_mtd_device (mtd);if (err)printk (PRINT_PREF "error %d occurred\n" , err);
PATCH 5/48 drivers/rtc/interface.c: fix alarm rollover when day or month is out-of-range
In reply to Greg KH3.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ben Hutchings <[email protected]>
commit e74a8f2edb92cb690b467cea0ab652c509e9f624 upstream.
Commit f44f7f96a20a ("RTC: Initialize kernel state from RTC") introduced a potential infinite loop. If an alarm time contains a wildcard month and an invalid day (> 31), or a wildcard year and an invalid month (>= 12), the loop searching for the next matching date will never terminate. Treat the invalid values as wildcards.
Fixes <http://bugs.debian.org/646429>, <http://bugs.debian.org/653331>
--- drivers/rtc/interface.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/rtc/interface.c +2 -2
@@ -227,11 +227,11 @@ int __rtc_read_alarm(struct rtc_device * alarm->time.tm_hour = now.tm_hour;/* For simplicity, only support date rollover for now */ -if (alarm->time.tm_mday ==-1 ) { +if (alarm->time.tm_mday <1 || alarm->time.tm_mday >31 ) { alarm->time.tm_mday = now.tm_mday; missing = day; } -if (alarm->time.tm_mon ==-1 ) { +if ((unsigned )alarm->time.tm_mon >=12 ) { alarm->time.tm_mon = now.tm_mon;if (missing == none) missing = month;
PATCH 6/48 ext4: fix undefined behavior in ext4_fill_flex_info()
In reply to Greg KH3.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Xi Wang <[email protected]>
commit d50f2ab6f050311dbf7b8f5501b25f0bf64a439b upstream.
Commit 503358ae01b70ce6909d19dd01287093f6b6271c ("ext4: avoid divide by zero when trying to mount a corrupted file system") fixes CVE-2009-4307 by performing a sanity check on s_log_groups_per_flex, since it can be set to a bogus value by an attacker.
sbi->s_log_groups_per_flex = sbi->s_es->s_log_groups_per_flex;
groups_per_flex = 1 << sbi->s_log_groups_per_flex;
if (groups_per_flex < 2) { ... }This patch fixes two potential issues in the previous commit.
1) The sanity check might only work on architectures like PowerPC. On x86, 5 bits are used for the shifting amount. That means, given a large s_log_groups_per_flex value like 36, groups_per_flex = 1 << 36 is essentially 1 << 4 = 16, rather than 0. This will bypass the check, leaving s_log_groups_per_flex and groups_per_flex inconsistent.
2) The sanity check relies on undefined behavior, i.e., oversized shift. A standard-confirming C compiler could rewrite the check in unexpected ways. Consider the following equivalent form, assuming groups_per_flex is unsigned for simplicity.
groups_per_flex = 1 << sbi->s_log_groups_per_flex;
if (groups_per_flex == 0 || groups_per_flex == 1) {We compile the code snippet using Clang 3.0 and GCC 4.6. Clang will completely optimize away the check groups_per_flex == 0, leaving the patched code as vulnerable as the original. GCC keeps the check, but there is no guarantee that future versions will do the same.
--- fs/ext4/super.c | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-)
fs/ext4/super.c +3 -4
@@ -1984,17 +1984,16 @@ static int ext4_fill_flex_info(struct sustruct ext4_group_desc *gdp =NULL ;ext4_group_t flex_group_count;ext4_group_t flex_group; -int groups_per_flex =0 ; +unsigned int groups_per_flex =0 ;size_t size;int i; sbi->s_log_groups_per_flex = sbi->s_es->s_log_groups_per_flex; - groups_per_flex =1 << sbi->s_log_groups_per_flex; - -if (groups_per_flex <2 ) { +if (sbi->s_log_groups_per_flex <1 || sbi->s_log_groups_per_flex >31 ) { sbi->s_log_groups_per_flex =0 ;return 1 ; } + groups_per_flex =1 << sbi->s_log_groups_per_flex;/* We allocate both existing and potentially added groups */ flex_group_count = ((sbi->s_groups_count + groups_per_flex - 1) +
PATCH 7/48 ALSA: snd-usb-us122l: Delete calls to preempt_disable
In reply to Greg KH3.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Karsten Wiese <[email protected]>
commit d0f3a2eb9062560bebca8b923424f3ca02a331ba upstream.
They are not needed here.
--- sound/usb/usx2y/usb_stream.c | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-)
sound/usb/usx2y/usb_stream.c +2 -4
@@ -674,7 +674,7 @@ dotry: inurb->transfer_buffer_length = inurb->number_of_packets * inurb->iso_frame_desc[0 ].length; -preempt_disable (); +if (u ==0 ) {int now;struct usb_device *dev = inurb->dev;
@@ -686,19 +686,17 @@ dotry: } err =usb_submit_urb (inurb,GFP_ATOMIC );if (err <0 ) { -preempt_enable ();snd_printk (KERN_ERR "usb_submit_urb(sk->inurb[%i])" " returned %i\n" , u, err);return err; } err =usb_submit_urb (outurb,GFP_ATOMIC );if (err <0 ) { -preempt_enable ();snd_printk (KERN_ERR "usb_submit_urb(sk->outurb[%i])" " returned %i\n" , u, err);return err; } -preempt_enable (); +if (inurb->start_frame != outurb->start_frame) { snd_printd(KERN_DEBUG "u[%i] start_frames differ in:%u out:%u\n",
PATCH 8/48 ALSA: HDA: Fix master control for Cirrus Logic 421X
In reply to Greg KH3.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: David Henningsson <[email protected]>
commit 40d03e63e91af8ddccdfd5a536cc2a6e51433e1d upstream.
The control name "HP/Speakers" is non-standard, and since there is only one DAC on this chip there is no need for a virtual master anyway.
--- sound/pci/hda/patch_cirrus.c | 13 +------------ 1 file changed, 1 insertion(+), 12 deletions(-)
sound/pci/hda/patch_cirrus.c +1 -12
@@ -1756,30 +1756,19 @@ static int build_cs421x_output(struct hdstruct auto_pin_cfg *cfg = &spec->autocfg;struct snd_kcontrol *kctl;int err; -char *name ="HP/Speakers" ; +char *name ="Master" ;fix_volume_caps (codec, dac); -if (!spec->vmaster_sw) { - err =add_vmaster (codec, dac); -if (err <0 ) -return err; - } err =add_mute (codec, name,0 ,HDA_COMPOSE_AMP_VAL (dac,3 ,0 ,HDA_OUTPUT ),0 , &kctl);if (err <0 )return err; - err =snd_ctl_add_slave (spec->vmaster_sw, kctl); -if (err <0 ) -return err; err =add_volume (codec, name,0 ,HDA_COMPOSE_AMP_VAL (dac,3 ,0 ,HDA_OUTPUT ),0 , &kctl);if (err <0 )return err; - err =snd_ctl_add_slave (spec->vmaster_vol, kctl); -if (err <0 ) -return err;if (cfg->speaker_outs) { err = snd_hda_ctl_add(codec, 0,
PATCH 9/48 ALSA: HDA: Fix automute for Cirrus Logic 421x
In reply to Greg KH3.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: David Henningsson <[email protected]>
commit 78e2a928e377d5124932d4399c6c581908b027a0 upstream.
There was a bug in the automute logic causing speakers not to mute when headphones were plugged in.
--- sound/pci/hda/patch_cirrus.c | 14 ++++++-------- 1 file changed, 6 insertions(+), 8 deletions(-)
sound/pci/hda/patch_cirrus.c +6 -8
@@ -916,16 +916,14 @@ static void cs_automute(struct hda_codec/* mute speakers if spdif or hp jack is plugged in */ for (i =0 ; i < cfg->speaker_outs; i++) { +int pin_ctl = hp_present ?0 :PIN_OUT ; +/* detect on spdif is specific to CS421x */ +if (spdif_present && (spec->vendor_nid ==CS421X_VENDOR_NID )) + pin_ctl =0 ; + nid = cfg->speaker_pins[i];snd_hda_codec_write (codec, nid,0 , -AC_VERB_SET_PIN_WIDGET_CONTROL , - hp_present ?0 :PIN_OUT ); -/* detect on spdif is specific to CS421x */ -if (spec->vendor_nid ==CS421X_VENDOR_NID ) { -snd_hda_codec_write (codec, nid,0 , -AC_VERB_SET_PIN_WIDGET_CONTROL , - spdif_present ?0 :PIN_OUT ); - } +AC_VERB_SET_PIN_WIDGET_CONTROL , pin_ctl); } if (spec->board_config == CS420X_MBP53 || spec->board_config == CS420X_MBP55 ||
PATCH 10/48 ALSA: ice1724 - Check for ac97 to avoid kernel oops
In reply to Greg KH3.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Pavel Hofman <[email protected]>
commit e7848163aa2a649d9065f230fadff80dc3519775 upstream.
Cards with identical PCI ids but no AC97 config in EEPROM do not have the ac97 field initialized. We must check for this case to avoid kernel oops.
--- sound/pci/ice1712/amp.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-)
sound/pci/ice1712/amp.c +5 -2
@@ -68,8 +68,11 @@ static int __devinit snd_vt1724_amp_initstatic int __devinit snd_vt1724_amp_add_controls (struct snd_ice1712 *ice) { -/* we use pins 39 and 41 of the VT1616 for left and right read outputs */ -snd_ac97_write_cache (ice->ac97,0x5a ,snd_ac97_read (ice->ac97,0x5a ) & ~0x8000 ); +if (ice->ac97) +/* we use pins 39 and 41 of the VT1616 for left and right +read outputs */ +snd_ac97_write_cache (ice->ac97,0x5a , +snd_ac97_read (ice->ac97,0x5a ) & ~0x8000 );return 0 ; }
PATCH 11/48 ALSA: hda - Use auto-parser for HP laptops with cx20459 codec
In reply to Greg KH3.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Takashi Iwai <[email protected]>
commit de4da59e480cdf1075b33dbaf8078fc87bc52241 upstream.
These laptops can work well with the auto-parser and their BIOS setups, and in addition, the auto-parser fixes the problem with S3/S4 where the unsol event handling is killed after resume due to fallback to the single-cmd mode.
Bugzilla: https://bugzilla.novell.com/show_bug.cgi?id=740115
--- sound/pci/hda/patch_conexant.c | 2 -- 1 file changed, 2 deletions(-)
sound/pci/hda/patch_conexant.c +0 -2
@@ -1119,8 +1119,6 @@ static const char * const cxt5045_modelsstatic const struct snd_pci_quirk cxt5045_cfg_tbl[] = {SND_PCI_QUIRK (0x103c ,0x30d5 ,"HP 530" ,CXT5045_LAPTOP_HP530 ), -SND_PCI_QUIRK_MASK (0x103c ,0xff00 ,0x3000 ,"HP DV Series" , -CXT5045_LAPTOP_HPSENSE ),SND_PCI_QUIRK (0x1179 ,0xff31 ,"Toshiba P105" ,CXT5045_LAPTOP_MICSENSE ),SND_PCI_QUIRK (0x152d ,0x0753 ,"Benq R55E" ,CXT5045_BENQ ),SND_PCI_QUIRK (0x1734 ,0x10ad ,"Fujitsu Si1520" ,CXT5045_LAPTOP_MICSENSE ),
PATCH 12/48 ALSA: hda - Return the error from get_wcaps_type() for invalid NIDs
In reply to Greg KH3.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Takashi Iwai <[email protected]>
commit 3a90274de3548ebb2aabfbf488cea8e275a73dc6 upstream.
When an invalid NID is given, get_wcaps() returns zero as the error, but get_wcaps_type() takes it as the normal value and returns a bogus AC_WID_AUD_OUT value. This confuses the parser.
With this patch, get_wcaps_type() returns -1 when value 0 is given, i.e. an invalid NID is passed to get_wcaps().
Bugzilla: https://bugzilla.novell.com/show_bug.cgi?id=740118
--- sound/pci/hda/hda_local.h | 7 ++++++- sound/pci/hda/hda_proc.c | 2 ++ 2 files changed, 8 insertions(+), 1 deletion(-)
sound/pci/hda/hda_local.h +6 -1
@@ -476,7 +476,12 @@ static inline u32 get_wcaps(struct hda_c }/* get the widget type from widget capability bits */ -#define get_wcaps_type (wcaps) (((wcaps) & AC_WCAP_TYPE) >> AC_WCAP_TYPE_SHIFT) +static inline int get_wcaps_type (unsigned int wcaps) +{ +if (!wcaps) +return -1 ;/* invalid type */ +return (wcaps &AC_WCAP_TYPE ) >>AC_WCAP_TYPE_SHIFT ; +}static inline unsigned int get_wcaps_channels (u32 wcaps) {
sound/pci/hda/hda_proc.c +2 -0
@@ -54,6 +54,8 @@ static const char *get_wid_type_name(uns [AC_WID_BEEP] = "Beep Generator Widget", [AC_WID_VENDOR] = "Vendor Defined Widget", }; +if (wid_value ==-1 ) +return "UNKNOWN Widget" ; wid_value &=0xf ;if (names[wid_value])return names[wid_value];
PATCH 13/48 ALSA: hda - Fix the detection of "Loopback Mixing" control for VIA codecs
In reply to Greg KH3.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Takashi Iwai <[email protected]>
commit 4808d12d1dddb046ec86425e5f6766f02e950292 upstream.
Currently the driver checks only the out_mix_path[] for the primary output route for judging whether to create the loopback-mixing control or not. But, there are cases where aamix-routing is available only on headphone or speaker paths but not on the primary output path. So, the driver ignores such cases inappropriately.
This patch fixes the check of the loopback-mixing control by testing all mix-routing paths.
--- sound/pci/hda/patch_via.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)
sound/pci/hda/patch_via.c +4 -1
@@ -2187,7 +2187,10 @@ static int via_auto_create_loopback_swit {struct via_spec *spec = codec->spec; -if (!spec->aa_mix_nid || !spec->out_mix_path.depth) +if (!spec->aa_mix_nid) +return 0 ;/* no loopback switching available */ +if (!(spec->out_mix_path.depth || spec->hp_mix_path.depth || + spec->speaker_path.depth))return 0 ;/* no loopback switching available */ if (!via_clone_control (spec, &via_aamix_ctl_enum))return -ENOMEM ;
PATCH 14/48 ALSA: hda - Fix the lost power-setup of seconary pins after PM resume
In reply to Greg KH3.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Takashi Iwai <[email protected]>
commit f2cbba7602383cd9cdd21f0a5d0b8bd1aad47b33 upstream.
When multiple headphone or other detectable output pins are present, the power-map has to be updated after resume appropriately, but the current driver doesn't check all pins but only the first pin (since it's enough to check it for the mute-behavior). This resulted in the silent output from the secondary outputs after PM resume.
This patch fixes the problem by checking all pins at (re-)init time.
Bugzilla: https://bugzilla.novell.com/show_bug.cgi?id=740347
--- sound/pci/hda/patch_sigmatel.c | 36 +++++++++++++++++++++++------------- 1 file changed, 23 insertions(+), 13 deletions(-)
sound/pci/hda/patch_sigmatel.c +23 -13
@@ -4306,6 +4306,27 @@ static void stac_store_hints(struct hda_ } } +static void stac_issue_unsol_events (struct hda_codec *codec,int num_pins, +const hda_nid_t *pins) +{ +while (num_pins--) +stac_issue_unsol_event (codec, *pins++); +} + +/* fake event to set up pins */ +static void stac_fake_hp_events (struct hda_codec *codec) +{ +struct sigmatel_spec *spec = codec->spec; + +if (spec->autocfg.hp_outs) +stac_issue_unsol_events (codec, spec->autocfg.hp_outs, + spec->autocfg.hp_pins); +if (spec->autocfg.line_outs && + spec->autocfg.line_out_pins[0 ] != spec->autocfg.hp_pins[0 ]) +stac_issue_unsol_events (codec, spec->autocfg.line_outs, + spec->autocfg.line_out_pins); +} +static int stac92xx_init (struct hda_codec *codec) {struct sigmatel_spec *spec = codec->spec;
@@ -4356,10 +4377,7 @@ static int stac92xx_init(struct hda_codestac92xx_auto_set_pinctl (codec, spec->autocfg.line_out_pins[0 ],AC_PINCTL_OUT_EN );/* fake event to set up pins */ -if (cfg->hp_pins[0 ]) -stac_issue_unsol_event (codec, cfg->hp_pins[0 ]); -else if (cfg->line_out_pins[0 ]) -stac_issue_unsol_event (codec, cfg->line_out_pins[0 ]); +stac_fake_hp_events (codec); }else {stac92xx_auto_init_multi_out (codec);stac92xx_auto_init_hp_out (codec);
@@ -5000,19 +5018,11 @@ static void stac927x_proc_hook(struct sn#ifdef CONFIG_PM static int stac92xx_resume (struct hda_codec *codec) { -struct sigmatel_spec *spec = codec->spec; -stac92xx_init (codec);snd_hda_codec_resume_amp (codec);snd_hda_codec_resume_cache (codec);/* fake event to set up pins again to override cached values */ -if (spec->hp_detect) { -if (spec->autocfg.hp_pins[0 ]) -stac_issue_unsol_event (codec, spec->autocfg.hp_pins[0 ]); -else if (spec->autocfg.line_out_pins[0 ]) -stac_issue_unsol_event (codec, - spec->autocfg.line_out_pins[0 ]); - } +stac_fake_hp_events (codec);return 0 ; }
PATCH 15/48 KVM guest: prevent tracing recursion with kvmclock
In reply to Greg KH3.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Avi Kivity <[email protected]>
(cherry picked from commit 95ef1e52922cf75b1ea2eae54ef886f2cc47eecb)
Prevent tracing of preempt_disable() in get_cpu_var() in kvm_clock_read(). When CONFIG_DEBUG_PREEMPT is enabled, preempt_disable/enable() are traced and this causes the function_graph tracer to go into an infinite recursion. By open coding the preempt_disable() around the get_cpu_var(), we can use the notrace version which prevents preempt_disable/enable() from being traced and prevents the recursion.
Based on a similar patch for Xen from Jeremy Fitzhardinge.
--- arch/x86/kernel/kvmclock.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)
arch/x86/kernel/kvmclock.c +3 -2
@@ -74,9 +74,10 @@ static cycle_t kvm_clock_read(void)struct pvclock_vcpu_time_info *src;cycle_t ret; - src = &get_cpu_var (hv_clock); +preempt_disable_notrace (); + src = &__get_cpu_var (hv_clock); ret =pvclock_clocksource_read (src); -put_cpu_var (hv_clock); +preempt_enable_notrace ();return ret; }
PATCH 16/48 KVM: x86: Prevent starting PIT timers in the absence of irqchip support
In reply to Greg KH3.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jan Kiszka <[email protected]>
(cherry picked from commit 0924ab2cfa98b1ece26c033d696651fd62896c69)
User space may create the PIT and forgets about setting up the irqchips. In that case, firing PIT IRQs will crash the host:
BUG: unable to handle kernel NULL pointer dereference at 0000000000000128 IP: [<ffffffffa10f6280>] kvm_set_irq+0x30/0x170 [kvm] ... Call Trace: [<ffffffffa11228c1>] pit_do_work+0x51/0xd0 [kvm] [<ffffffff81071431>] process_one_work+0x111/0x4d0 [<ffffffff81071bb2>] worker_thread+0x152/0x340 [<ffffffff81075c8e>] kthread+0x7e/0x90 [<ffffffff815a4474>] kernel_thread_helper+0x4/0x10
Prevent this by checking the irqchip mode before starting a timer. We can't deny creating the PIT if the irqchips aren't set up yet as current user land expects this order to work.
--- arch/x86/kvm/i8254.c | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-)
arch/x86/kvm/i8254.c +7 -3
@@ -338,11 +338,15 @@ static enum hrtimer_restart pit_timer_fnreturn HRTIMER_NORESTART ; } -static void create_pit_timer (struct kvm_kpit_state *ps,u32 val,int is_period) +static void create_pit_timer (struct kvm *kvm,u32 val,int is_period) { +struct kvm_kpit_state *ps = &kvm->arch.vpit->pit_state;struct kvm_timer *pt = &ps->pit_timer;s64 interval; +if (!irqchip_in_kernel (kvm)) +return ; + interval =muldiv64 (val,NSEC_PER_SEC ,KVM_PIT_FREQ );pr_debug ("create pit timer, interval is %llu nsec\n" , interval);
@@ -394,13 +398,13 @@ static void pit_load_count(struct kvm *k/* FIXME: enhance mode 4 precision */ case 4 :if (!(ps->flags &KVM_PIT_FLAGS_HPET_LEGACY )) { -create_pit_timer (ps, val,0 ); +create_pit_timer (kvm, val,0 ); }break ;case 2 :case 3 :if (!(ps->flags &KVM_PIT_FLAGS_HPET_LEGACY )){ -create_pit_timer (ps, val,1 ); +create_pit_timer (kvm, val,1 ); }break ;default :
PATCH 17/48 KVM: Remove ability to assign a device without iommu support
In reply to Greg KH3.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alex Williamson <[email protected]>
(cherry picked from commit 423873736b78f549fbfa2f715f2e4de7e6c5e1e9)
This option has no users and it exposes a security hole that we can allow devices to be assigned without iommu protection. Make KVM_DEV_ASSIGN_ENABLE_IOMMU a mandatory option.
--- Documentation/virtual/kvm/api.txt | 3 +++ virt/kvm/assigned-dev.c | 18 +++++++++--------- 2 files changed, 12 insertions(+), 9 deletions(-)
Documentation/virtual/kvm/api.txt +3 -0
@@ -1131,6 +1131,9 @@ following flags are specified: /* Depends on KVM_CAP_IOMMU */ #define KVM_DEV_ASSIGN_ENABLE_IOMMU (1 << 0) +The KVM_DEV_ASSIGN_ENABLE_IOMMU flag is a mandatory option to ensure +isolation of the device. Usages not specifying this flag are deprecated. + 4.49 KVM_DEASSIGN_PCI_DEVICE Capability: KVM_CAP_DEVICE_DEASSIGNMENT
virt/kvm/assigned-dev.c +9 -9
@@ -481,6 +481,9 @@ static int kvm_vm_ioctl_assign_device(ststruct kvm_assigned_dev_kernel *match;struct pci_dev *dev; +if (!(assigned_dev->flags &KVM_DEV_ASSIGN_ENABLE_IOMMU )) +return -EINVAL ; +mutex_lock (&kvm->lock); idx =srcu_read_lock (&kvm->srcu);
@@ -538,16 +541,14 @@ static int kvm_vm_ioctl_assign_device(stlist_add (&match->list, &kvm->arch.assigned_dev_head); -if (assigned_dev->flags &KVM_DEV_ASSIGN_ENABLE_IOMMU ) { -if (!kvm->arch.iommu_domain) { - r =kvm_iommu_map_guest (kvm); -if (r) - goto out_list_del; - } - r =kvm_assign_device (kvm, match); +if (!kvm->arch.iommu_domain) { + r =kvm_iommu_map_guest (kvm);if (r) goto out_list_del; } + r =kvm_assign_device (kvm, match); +if (r) + goto out_list_del; out:srcu_read_unlock (&kvm->srcu, idx);
@@ -587,8 +588,7 @@ static int kvm_vm_ioctl_deassign_device( goto out; } -if (match->flags &KVM_DEV_ASSIGN_ENABLE_IOMMU ) -kvm_deassign_device (kvm, match); +kvm_deassign_device (kvm, match);kvm_free_assigned_device (kvm, match);
PATCH 18/48 KVM: Device assignment permission checks
In reply to Greg KH3.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alex Williamson <[email protected]>
(cherry picked from commit 3d27e23b17010c668db311140b17bbbb70c78fb9)
Only allow KVM device assignment to attach to devices which:
- Are not bridges
- Have BAR resources (assume others are special devices)
- The user has permissions to use
Assigning a bridge is a configuration error, it's not supported, and typically doesn't result in the behavior the user is expecting anyway. Devices without BAR resources are typically chipset components that also don't have host drivers. We don't want users to hold such devices captive or cause system problems by fencing them off into an iommu domain. We determine "permission to use" by testing whether the user has access to the PCI sysfs resource files. By default a normal user will not have access to these files, so it provides a good indication that an administration agent has granted the user access to the device.
[Yang Bai: add missing #include]
[avi: fix comment style]
--- Documentation/virtual/kvm/api.txt | 4 ++ virt/kvm/assigned-dev.c | 75 ++++++++++++++++++++++++++++++++++++++ 2 files changed, 79 insertions(+)
Documentation/virtual/kvm/api.txt +4 -0
@@ -1134,6 +1134,10 @@ following flags are specified: The KVM_DEV_ASSIGN_ENABLE_IOMMU flag is a mandatory option to ensure isolation of the device. Usages not specifying this flag are deprecated. +Only PCI header type 0 devices with PCI BAR resources are supported by +device assignment. The user requesting this ioctl must have read/write +access to the PCI sysfs resource files associated with the device. + 4.49 KVM_DEASSIGN_PCI_DEVICE Capability: KVM_CAP_DEVICE_DEASSIGNMENT
virt/kvm/assigned-dev.c +75 -0
99 lines not on this page · raw message
PATCH 19/48 ideapad: Check if acpi already handle backlight power to avoid a page fault
In reply to Greg KH3.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Rene Bollford <[email protected]>
commit d4afc7754a60b885b63ef23fd194984e2d53a4e6 upstream.
This patch avoid a page fault in the ideapad-laptop extras when turning the backlight power on or off.
--- drivers/platform/x86/ideapad-laptop.c | 2 ++ 1 file changed, 2 insertions(+)
drivers/platform/x86/ideapad-laptop.c +2 -0
@@ -493,6 +493,8 @@ static void ideapad_backlight_notify_powunsigned long power;struct backlight_device *blightdev = priv->blightdev; +if (!blightdev) +return ;if (read_ec_data (ideapad_handle,0x18 , &power))return ; blightdev->props.power = power ?FB_BLANK_UNBLANK :FB_BLANK_POWERDOWN ;
PATCH 20/48 drm/radeon/kms: workaround invalid AVI infoframe checksum issue
In reply to Greg KH3.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Rafał Miłecki <[email protected]>
commit 92db7f6c860b8190571a9dc1fcbc16d003422fe8 upstream.
This change was verified to fix both issues with no video I've investigated. I've also checked checksum calculation with fglrx on:
RV620, HD54xx, HD5450, HD6310, HD6320.
--- drivers/gpu/drm/radeon/r600_hdmi.c | 7 +++++++ 1 file changed, 7 insertions(+)
drivers/gpu/drm/radeon/r600_hdmi.c +7 -0
@@ -196,6 +196,13 @@ static void r600_hdmi_videoinfoframe( frame[0xD ] = (right_bar >>8 );r600_hdmi_infoframe_checksum (0x82 ,0x02 ,0x0D , frame); +/* Our header values (type, version, length) should be alright, Intel +* is using the same. Checksum function also seems to be OK, it works +* fine for audio infoframe. However calculated value is always lower +* by 2 in comparison to fglrx. It breaks displaying anything in case +* of TVs that strictly check the checksum. Hack it manually here to +* workaround this issue. */ + frame[0x0 ] +=2 ;WREG32 (offset+R600_HDMI_VIDEOINFOFRAME_0 , frame[0x0 ] | (frame[0x1 ] <<8 ) | (frame[0x2 ] <<16 ) | (frame[0x3 ] <<24 ));
PATCH 21/48 drm/radeon/kms: disable writeback on pre-R300 asics
In reply to Greg KH3.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alex Deucher <[email protected]>
commit 28eebb703e28bc455ba704adb1026f76649b768c upstream.
We often end up missing fences on older asics with writeback enabled which leads to delays in the userspace accel code, so just disable it by default on those asics.
--- drivers/gpu/drm/radeon/radeon_device.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)
drivers/gpu/drm/radeon/radeon_device.c +4 -1
@@ -224,8 +224,11 @@ int radeon_wb_init(struct radeon_deviceif (radeon_no_wb ==1 ) rdev->wb.enabled = false;else { -/* often unreliable on AGP */ if (rdev->flags &RADEON_IS_AGP ) { +/* often unreliable on AGP */ + rdev->wb.enabled = false; + }else if (rdev->family <CHIP_R300 ) { +/* often unreliable on pre-r300 */ rdev->wb.enabled = false; }else { rdev->wb.enabled = true;
PATCH 22/48 radeon: Fix disabling PCI bus mastering on big endian hosts.
In reply to Greg KH3.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Michel Dänzer <[email protected]>
commit 3df96909b75835d487a9178761622b0cbd7310d4 upstream.
It would previously write basically random bits to PCI configuration space... Not very surprising that the GPU tended to stop responding completely. The resulting MCE even froze the whole machine sometimes.
Now resetting the GPU after a lockup has at least a fighting chance of succeeding.
--- drivers/gpu/drm/radeon/r100.c | 5 +++-- drivers/gpu/drm/radeon/rs600.c | 4 ++-- 2 files changed, 5 insertions(+), 4 deletions(-)
drivers/gpu/drm/radeon/r100.c +3 -2
@@ -2069,6 +2069,7 @@ bool r100_gpu_is_lockup(struct radeon_devoid r100_bm_disable (struct radeon_device *rdev) {u32 tmp; +u16 tmp16;/* disable bus mastering */ tmp =RREG32 (R_000030_BUS_CNTL );
@@ -2079,8 +2080,8 @@ void r100_bm_disable(struct radeon_devicWREG32 (R_000030_BUS_CNTL , (tmp &0xFFFFFFFF ) |0x00000040 ); tmp =RREG32 (RADEON_BUS_CNTL );mdelay (1 ); -pci_read_config_word (rdev->pdev,0x4 , (u16 *)&tmp); -pci_write_config_word (rdev->pdev,0x4 , tmp &0xFFFB ); +pci_read_config_word (rdev->pdev,0x4 , &tmp16); +pci_write_config_word (rdev->pdev,0x4 , tmp16 &0xFFFB );mdelay (1 ); }
drivers/gpu/drm/radeon/rs600.c +2 -2
@@ -324,10 +324,10 @@ void rs600_hpd_fini(struct radeon_devicevoid rs600_bm_disable (struct radeon_device *rdev) { -u32 tmp; +u16 tmp;/* disable bus mastering */ -pci_read_config_word (rdev->pdev,0x4 , (u16 *)&tmp); +pci_read_config_word (rdev->pdev,0x4 , &tmp);pci_write_config_word (rdev->pdev,0x4 , tmp &0xFFFB );mdelay (1 ); }
PATCH 23/48 NFS: Retry mounting NFSROOT
In reply to Greg KH3.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Chuck Lever <[email protected]>
commit 43717c7daebf10b43f12e68512484b3095bb1ba5 upstream.
Lukas Razik <[email protected]> reports that on his SPARC system, booting with an NFS root file system stopped working after commit 56463e50 "NFS: Use super.c for NFSROOT mount option parsing."
We found that the network switch to which Lukas' client was attached was delaying access to the LAN after the client's NIC driver reported that its link was up. The delay was longer than the timeouts used in the NFS client during mounting.
NFSROOT worked for Lukas before commit 56463e50 because in those kernels, the client's first operation was an rpcbind request to determine which port the NFS server was listening on. When that request failed after a long timeout, the client simply selected the default NFS port (2049). By that time the switch was allowing access to the LAN, and the mount succeeded.
Neither of these client behaviors is desirable, so reverting 56463e50 is really not a choice. Instead, introduce a mechanism that retries the NFSROOT mount request several times. This is the same tactic that normal user space NFS mounts employ to overcome server and network delays.
--- init/do_mounts.c | 35 +++++++++++++++++++++++++++++++---- 1 file changed, 31 insertions(+), 4 deletions(-)
init/do_mounts.c +31 -4
@@ -360,15 +360,42 @@ out: }#ifdef CONFIG_ROOT_NFS + +#define NFSROOT_TIMEOUT_MIN 5 +#define NFSROOT_TIMEOUT_MAX 30 +#define NFSROOT_RETRY_MAX 5 +static int __init mount_nfs_root (void ) {char *root_dev, *root_data; +unsigned int timeout; +int try, err; -if (nfs_root_data (&root_dev, &root_data) !=0 ) -return 0 ; -if (do_mount_root (root_dev,"nfs" , root_mountflags, root_data) !=0 ) + err =nfs_root_data (&root_dev, &root_data); +if (err !=0 )return 0 ; -return 1 ; + +/* +* The server or network may not be ready, so try several +* times. Stop after a few tries in case the client wants +* to fall back to other boot methods. +*/ + timeout =NFSROOT_TIMEOUT_MIN ; +for (try =1 ; ; try++) { + err =do_mount_root (root_dev,"nfs" , + root_mountflags, root_data); +if (err ==0 ) +return 1 ; +if (try >NFSROOT_RETRY_MAX ) +break ; + +/* Wait, in case the server refused us immediately */ +ssleep (timeout); + timeout <<=1 ; +if (timeout >NFSROOT_TIMEOUT_MAX ) + timeout =NFSROOT_TIMEOUT_MAX ; + } +return 0 ; }#endif
PATCH 24/48 NFSv4.1: fix backchannel slotid off-by-one bug
In reply to Greg KH3.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Andy Adamson <[email protected]>
commit 61f2e5106582d02f30b6807e3f9c07463c572ccb upstream.
--- fs/nfs/callback_proc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
fs/nfs/callback_proc.c +1 -1
@@ -339,7 +339,7 @@ validate_seqid(struct nfs4_slot_table *tdprintk ("%s enter. slotid %d seqid %d\n" , __func__, args->csa_slotid, args->csa_sequenceid); -if (args->csa_slotid >NFS41_BC_MAX_CALLBACKS ) +if (args->csa_slotid >=NFS41_BC_MAX_CALLBACKS )return htonl (NFS4ERR_BADSLOT ); slot = tbl->slots + args->csa_slotid;
PATCH 25/48 NFS - fix recent breakage to NFS error handling.
In reply to Greg KH3.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: NeilBrown <[email protected]>
commit 2edb6bc3852c681c0d948245bd55108dc6407604 upstream.
Quoted 1 line
Quoted 1 line
From
c6d615d2b97fe305cbf123a8751ced859dca1d5eMon Sep 17 00:00:00 2001
From: NeilBrown <[email protected]>
Date: Wed, 16 Nov 2011 09:39:05 +1100
Subject: [25/48] NFS - fix recent breakage to NFS error handling.
commit 02c24a82187d5a628c68edfe71ae60dc135cd178 made a small and presumably unintended change to write error handling in NFS.
Previously an error from filemap_write_and_wait_range would only be of interest if nfs_file_fsync did not return an error. After this commit, an error from filemap_write_and_wait_range would mean that (the rest of) nfs_file_fsync would not even be called.
This means that:
1/ you are more likely to see EIO than e.g. EDQUOT or ENOSPC. 2/ NFS_CONTEXT_ERROR_WRITE remains set for longer so more writes are
synchronous.
This patch restores previous behaviour.
--- fs/nfs/file.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
fs/nfs/file.c +2 -2
@@ -321,13 +321,13 @@ nfs_file_fsync(struct file *file, loff_t datasync); ret =filemap_write_and_wait_range (inode->i_mapping, start, end); -if (ret) -return ret;mutex_lock (&inode->i_mutex);nfs_inc_stats (inode,NFSIOS_VFSFSYNC ); have_error =test_and_clear_bit (NFS_CONTEXT_ERROR_WRITE , &ctx->flags); status =nfs_commit_inode (inode,FLUSH_SYNC ); +if (status >=0 && ret <0 ) + status = ret; have_error |=test_bit (NFS_CONTEXT_ERROR_WRITE , &ctx->flags);if (have_error) ret =xchg (&ctx->error,0 );
PATCH 26/48 NFSv4: include bitmap in nfsv4 get acl data
In reply to Greg KH3.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Andy Adamson <[email protected]>
commit bf118a342f10dafe44b14451a1392c3254629a1f upstream.
The NFSv4 bitmap size is unbounded: a server can return an arbitrary sized bitmap in an FATTR4_WORD0_ACL request. Replace using the nfs4_fattr_bitmap_maxsz as a guess to the maximum bitmask returned by a server with the inclusion of the bitmap (xdr length plus bitmasks) and the acl data xdr length to the (cached) acl page data.
This is a general solution to commit e5012d1f "NFSv4.1: update nfs4_fattr_bitmap_maxsz" and fixes hitting a BUG_ON in xdr_shrink_bufhead when getting ACLs.
Fix a bug in decode_getacl that returned -EINVAL on ACLs > page when getxattr was called with a NULL buffer, preventing ACL > PAGE_SIZE from being retrieved.
--- fs/nfs/nfs4proc.c | 96 ++++++++++++++++++++++++++------------------- fs/nfs/nfs4xdr.c | 31 ++++++++++---- include/linux/nfs_xdr.h | 5 ++ include/linux/sunrpc/xdr.h | 2 net/sunrpc/xdr.c | 3 - 5 files changed, 89 insertions(+), 48 deletions(-)
fs/nfs/nfs4proc.c +57 -39
@@ -3442,19 +3442,6 @@ static inline int nfs4_server_supports_a*/ #define NFS4ACL_MAXPAGES (XATTR_SIZE_MAX >> PAGE_CACHE_SHIFT) -static void buf_to_pages (const void *buf,size_t buflen, -struct page **pages,unsigned int *pgbase) -{ -const void *p = buf; - - *pgbase =offset_in_page (buf); - p -= *pgbase; -while (p < buf + buflen) { - *(pages++) =virt_to_page (p); - p +=PAGE_CACHE_SIZE ; - } -} -static int buf_to_pages_noslab (const void *buf,size_t buflen,struct page **pages,unsigned int *pgbase) {
@@ -3551,9 +3538,19 @@ out:nfs4_set_cached_acl (inode, acl); } +/* +* The getxattr API returns the required buffer length when called with a +* NULL buf. The NFSv4 acl tool then calls getxattr again after allocating +* the required buf. On a NULL buf, we send a page of data to the server +* guessing that the ACL request can be serviced by a page. If so, we cache +* up to the page of ACL data, and the 2nd call to getxattr is serviced by +* the cache. If not so, we throw away the page, and cache the required +* length. The next getxattr call will then produce another round trip to +* the server, this time with the input buf of the required size. +*/ static ssize_t __nfs4_get_acl_uncached (struct inode *inode,void *buf,size_t buflen) { -struct page *pages[NFS4ACL_MAXPAGES ]; +struct page *pages[NFS4ACL_MAXPAGES ] = {NULL , };struct nfs_getaclargs args = { .fh =NFS_FH (inode), .acl_pages = pages,
@@ -3568,41 +3565,60 @@ static ssize_t __nfs4_get_acl_uncached(s .rpc_argp = &args, .rpc_resp = &res, }; -struct page *localpage =NULL ; -int ret; +int ret = -ENOMEM , npages, i, acl_len =0 ; -if (buflen <PAGE_SIZE ) { -/* As long as we're doing a round trip to the server anyway, -* let's be prepared for a page of acl data. */ - localpage =alloc_page (GFP_KERNEL ); - resp_buf =page_address (localpage); -if (localpage ==NULL ) -return -ENOMEM ; - args.acl_pages[0 ] = localpage; - args.acl_pgbase =0 ; - args.acl_len =PAGE_SIZE ; - }else { - resp_buf = buf; -buf_to_pages (buf, buflen, args.acl_pages, &args.acl_pgbase); + npages = (buflen +PAGE_SIZE -1 ) >>PAGE_SHIFT ; +/* As long as we're doing a round trip to the server anyway, +* let's be prepared for a page of acl data. */ +if (npages ==0 ) + npages =1 ; + +for (i =0 ; i < npages; i++) { + pages[i] =alloc_page (GFP_KERNEL ); +if (!pages[i]) + goto out_free; } - ret =nfs4_call_sync (NFS_SERVER (inode)->client,NFS_SERVER (inode), &msg, &args.seq_args, &res.seq_res,0 ); +if (npages >1 ) { +/* for decoding across pages */ + args.acl_scratch =alloc_page (GFP_KERNEL ); +if (!args.acl_scratch) + goto out_free; + } + args.acl_len = npages *PAGE_SIZE ; + args.acl_pgbase =0 ; +/* Let decode_getfacl know not to fail if the ACL data is larger than +* the page we send as a guess */ +if (buf ==NULL ) + res.acl_flags |=NFS4_ACL_LEN_REQUEST ; + resp_buf =page_address (pages[0 ]); + +dprintk ("%s buf %p buflen %ld npages %d args.acl_len %ld\n" , + __func__, buf, buflen, npages, args.acl_len); + ret =nfs4_call_sync (NFS_SERVER (inode)->client,NFS_SERVER (inode), + &msg, &args.seq_args, &res.seq_res,0 );if (ret) goto out_free; -if (res.acl_len > args.acl_len) -nfs4_write_cached_acl (inode,NULL , res.acl_len); + + acl_len = res.acl_len - res.acl_data_offset; +if (acl_len > args.acl_len) +nfs4_write_cached_acl (inode,NULL , acl_len);else -nfs4_write_cached_acl (inode, resp_buf, res.acl_len); +nfs4_write_cached_acl (inode, resp_buf + res.acl_data_offset, + acl_len);if (buf) { ret = -ERANGE ; -if (res.acl_len > buflen) +if (acl_len > buflen) goto out_free; -if (localpage) -memcpy (buf, resp_buf, res.acl_len); +_copy_from_pages (buf, pages, res.acl_data_offset, + res.acl_len); } - ret = res.acl_len; + ret = acl_len; out_free: -if (localpage) -__free_page (localpage); +for (i =0 ; i < npages; i++) +if (pages[i]) +__free_page (pages[i]); +if (args.acl_scratch) +__free_page (args.acl_scratch);return ret; }
@@ -3633,6 +3649,8 @@ static ssize_t nfs4_proc_get_acl(structnfs_zap_acl_cache (inode); ret =nfs4_read_cached_acl (inode, buf, buflen);if (ret != -ENOENT ) +/* -ENOENT is returned if there is no ACL or if there is an ACL +* but no cached acl data, just the acl length */ return ret;return nfs4_get_acl_uncached (inode, buf, buflen); }
fs/nfs/nfs4xdr.c +23 -8
@@ -2517,11 +2517,13 @@ static void nfs4_xdr_enc_getacl(struct rencode_compound_hdr (xdr, req, &hdr);encode_sequence (xdr, &args->seq_args, &hdr);encode_putfh (xdr, args->fh, &hdr); - replen = hdr.replen + op_decode_hdr_maxsz + nfs4_fattr_bitmap_maxsz +1 ; + replen = hdr.replen + op_decode_hdr_maxsz +1 ;encode_getattr_two (xdr,FATTR4_WORD0_ACL ,0 , &hdr);xdr_inline_pages (&req->rq_rcv_buf, replen <<2 , args->acl_pages, args->acl_pgbase, args->acl_len); +xdr_set_scratch_buffer (xdr,page_address (args->acl_scratch),PAGE_SIZE ); +encode_nops (&hdr); }
@@ -4957,17 +4959,18 @@ decode_restorefh(struct xdr_stream *xdr) }static int decode_getacl (struct xdr_stream *xdr,struct rpc_rqst *req, -size_t *acl_len) +struct nfs_getaclres *res) { -__be32 *savep; +__be32 *savep, *bm_p;uint32_t attrlen, bitmap[3 ] = {0 };struct kvec *iov = req->rq_rcv_buf.head;int status; - *acl_len =0 ; + res->acl_len =0 ;if ((status =decode_op_hdr (xdr,OP_GETATTR )) !=0 ) goto out; + bm_p = xdr->p;if ((status =decode_attr_bitmap (xdr, bitmap)) !=0 ) goto out;if ((status =decode_attr_length (xdr, &attrlen, &savep)) !=0 )
@@ -4979,18 +4982,30 @@ static int decode_getacl(struct xdr_stresize_t hdrlen;u32 recvd; +/* The bitmap (xdr len + bitmaps) and the attr xdr len words +* are stored with the acl data to handle the problem of +* variable length bitmaps.*/ + xdr->p = bm_p; + res->acl_data_offset =be32_to_cpup (bm_p) +2 ; + res->acl_data_offset <<=2 ; +/* We ignore &savep and don't do consistency checks on * the attr length. Let userspace figure it out.... */ hdrlen = (u8 *)xdr->p - (u8 *)iov->iov_base; + attrlen += res->acl_data_offset; recvd = req->rq_rcv_buf.len - hdrlen;if (attrlen > recvd) { -dprintk ("NFS: server cheating in getattr" -" acl reply: attrlen %u > recvd %u\n" , +if (res->acl_flags &NFS4_ACL_LEN_REQUEST ) { +/* getxattr interface called with a NULL buf */ + res->acl_len = attrlen; + goto out; + } +dprintk ("NFS: acl reply: attrlen %u > recvd %u\n" , attrlen, recvd);return -EINVAL ; }xdr_read_pages (xdr, attrlen); - *acl_len = attrlen; + res->acl_len = attrlen; }else status = -EOPNOTSUPP ;
@@ -6028,7 +6043,7 @@ nfs4_xdr_dec_getacl(struct rpc_rqst *rqs status =decode_putfh (xdr);if (status) goto out; - status =decode_getacl (xdr, rqstp, &res->acl_len); + status =decode_getacl (xdr, rqstp, res); out:return status;
include/linux/nfs_xdr.h +5 -0
@@ -602,11 +602,16 @@ struct nfs_getaclargs {size_t acl_len;unsigned int acl_pgbase;struct page ** acl_pages; +struct page * acl_scratch;struct nfs4_sequence_args seq_args; }; +/* getxattr ACL interface flags */ +#define NFS4_ACL_LEN_REQUEST 0x0001/* zero length getxattr buffer */ struct nfs_getaclres {size_t acl_len; +size_t acl_data_offset; +int acl_flags;struct nfs4_sequence_res seq_res; };
include/linux/sunrpc/xdr.h +2 -0
@@ -191,6 +191,8 @@ extern int xdr_decode_array2(struct xdr_ struct xdr_array2_desc *desc);extern int xdr_encode_array2 (struct xdr_buf *buf,unsigned int base,struct xdr_array2_desc *desc); +extern void _copy_from_pages (char *p,struct page **pages,size_t pgbase, +size_t len);/* * Provide some simple tools for XDR buffer overflow-checking etc.
net/sunrpc/xdr.c +2 -1
@@ -296,7 +296,7 @@ _copy_to_pages(struct page **pages, size* Copies data into an arbitrary memory location from an array of pages * The copy is assumed to be non-overlapping. */ -static void +void _copy_from_pages (char *p,struct page **pages,size_t pgbase,size_t len) {struct page **pgfrom;
@@ -324,6 +324,7 @@ _copy_from_pages(char *p, struct page ** }while ((len -= copy) !=0 ); } +EXPORT_SYMBOL_GPL (_copy_from_pages);/* * xdr_shrink_bufhead
PATCH 27/48 nfs: fix regression in handling of context= option in NFSv4
In reply to Greg KH3.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jeff Layton <[email protected]>
commit 8a0d551a59ac92d8ff048d6cb29d3a02073e81e8 upstream.
Setting the security context of a NFSv4 mount via the context= mount option is currently broken. The NFSv4 codepath allocates a parsed options struct, and then parses the mount options to fill it. It eventually calls nfs4_remote_mount which calls security_init_mnt_opts. That clobbers the lsm_opts struct that was populated earlier. This bug also looks like it causes a small memory leak on each v4 mount where context= is used.
Fix this by moving the initialization of the lsm_opts into nfs_alloc_parsed_mount_data. Also, add a destructor for nfs_parsed_mount_data to make it easier to free all of the allocations hanging off of it, and to ensure that the security_free_mnt_opts is called whenever security_init_mnt_opts is.
I believe this regression was introduced quite some time ago, probably by commit c02d7adf.
--- fs/nfs/super.c | 43 +++++++++++++++++++------------------------ 1 file changed, 19 insertions(+), 24 deletions(-)
fs/nfs/super.c +19 -24
@@ -904,10 +904,24 @@ static struct nfs_parsed_mount_data *nfs data->auth_flavor_len =1 ; data->version = version; data->minorversion =0 ; +security_init_mnt_opts (&data->lsm_opts); }return data; } +static void nfs_free_parsed_mount_data (struct nfs_parsed_mount_data *data) +{ +if (data) { +kfree (data->client_address); +kfree (data->mount_server.hostname); +kfree (data->nfs_server.export_path); +kfree (data->nfs_server.hostname); +kfree (data->fscache_uniq); +security_free_mnt_opts (&data->lsm_opts); +kfree (data); + } +} +/* * Sanity-check a server address provided by the mount command. *
@@ -2215,9 +2229,7 @@ static struct dentry *nfs_fs_mount(struc data =nfs_alloc_parsed_mount_data (NFS_DEFAULT_VERSION ); mntfh =nfs_alloc_fhandle ();if (data ==NULL || mntfh ==NULL ) - goto out_free_fh; - -security_init_mnt_opts (&data->lsm_opts); + goto out;/* Validate the mount data */ error =nfs_validate_mount_data (raw_data, data, mntfh, dev_name);
@@ -2229,8 +2241,6 @@ static struct dentry *nfs_fs_mount(struc#ifdef CONFIG_NFS_V4 if (data->version ==4 ) { mntroot =nfs4_try_mount (flags, dev_name, data); -kfree (data->client_address); -kfree (data->nfs_server.export_path); goto out; }#endif /* CONFIG_NFS_V4 */
@@ -2285,13 +2295,8 @@ static struct dentry *nfs_fs_mount(struc s->s_flags |=MS_ACTIVE ; out: -kfree (data->nfs_server.hostname); -kfree (data->mount_server.hostname); -kfree (data->fscache_uniq); -security_free_mnt_opts (&data->lsm_opts); -out_free_fh: +nfs_free_parsed_mount_data (data);nfs_free_fhandle (mntfh); -kfree (data);return mntroot; out_err_nosb:
@@ -2618,9 +2623,7 @@ nfs4_remote_mount(struct file_system_typ mntfh =nfs_alloc_fhandle ();if (data ==NULL || mntfh ==NULL ) - goto out_free_fh; - -security_init_mnt_opts (&data->lsm_opts); + goto out;/* Get a volume representation */ server =nfs4_create_server (data, mntfh);
@@ -2672,13 +2675,10 @@ nfs4_remote_mount(struct file_system_typ s->s_flags |=MS_ACTIVE ; -security_free_mnt_opts (&data->lsm_opts);nfs_free_fhandle (mntfh);return mntroot; out: -security_free_mnt_opts (&data->lsm_opts); -out_free_fh:nfs_free_fhandle (mntfh);return ERR_PTR (error);
@@ -2858,7 +2858,7 @@ static struct dentry *nfs4_mount(struct data =nfs_alloc_parsed_mount_data (4 );if (data ==NULL ) - goto out_free_data; + goto out;/* Validate the mount data */ error =nfs4_validate_mount_data (raw_data, data, dev_name);
@@ -2872,12 +2872,7 @@ static struct dentry *nfs4_mount(struct error =PTR_ERR (res); out: -kfree (data->client_address); -kfree (data->nfs_server.export_path); -kfree (data->nfs_server.hostname); -kfree (data->fscache_uniq); -out_free_data: -kfree (data); +nfs_free_parsed_mount_data (data);dprintk ("<-- nfs4_mount() = %d%s\n" , error, error !=0 ?" [error]" :"" );return res;
PATCH 28/48 HID: bump maximum global item tag report size to 96 bytes
In reply to Greg KH3.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Chase Douglas <[email protected]>
commit e46e927b9b7e8d95526e69322855243882b7e1a3 upstream.
This allows the latest N-Trig devices to function properly.
--- drivers/hid/hid-core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/hid/hid-core.c +1 -1
@@ -361,7 +361,7 @@ static int hid_parser_global(struct hid_case HID_GLOBAL_ITEM_TAG_REPORT_SIZE : parser->global.report_size =item_udata (item); -if (parser->global.report_size >32 ) { +if (parser->global.report_size >96 ) {dbg_hid ("invalid report_size %d\n" , parser->global.report_size);return -1 ;
PATCH 29/48 HID: wiimote: Select INPUT_FF_MEMLESS
In reply to Greg KH3.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: David Herrmann <[email protected]>
commit ef6f41157f3864d9bf42671b2ed66062dcafb72e upstream.
We depend on memless force-feedback support, therefore correctly select the related config options.
--- drivers/hid/Kconfig | 1 + 1 file changed, 1 insertion(+)
drivers/hid/Kconfig +1 -0
@@ -583,6 +583,7 @@ config HID_WACOM_POWER_SUPPLY bool "Wacom Bluetooth devices power supply status support" depends on HID_WACOM select POWER_SUPPLY + select INPUT_FF_MEMLESS ---help--- Say Y here if you want to enable power supply status monitoring for Wacom Bluetooth devices.
Re: [29/48] HID: wiimote: Select INPUT_FF_MEMLESS
Quoted 1 line · Greg KH
3.1-stable review patch. �If anyone has any objections, please let me know.
This one looks like typical patch Makefile/Kconfig "oh, hey this fits anywhere" nonsense, and is completely broken. Original was for a Wiimote, not Wacom.
P.
Quoted 36 lines
------------------
From: David Herrmann <[email protected]>
commit
ef6f41157f3864d9bf42671b2ed66062dcafb72eupstream.We depend on memless force-feedback support, therefore correctly select the related config options.
Reported-by Randy Dunlap <[email protected]>Signed-off-by David Herrmann <[email protected]>Signed-off-by Jiri Kosina <[email protected]>Signed-off-by Greg Kroah-Hartman <[email protected]>---
�drivers/hid/Kconfig | � �1 +
�1 file changed, 1 insertion(+)drivers/hid/Kconfig +0
-0@@ -583,6 +583,7 @@ config HID_WACOM_POWER_SUPPLY� � � �bool "Wacom Bluetooth devices power supply status support" � � � �depends on
HID_WACOM
� � � �selectPOWER_SUPPLY
+ � � � selectINPUT_FF_MEMLESS
� � � �---help---
� � � � �Say Y here if you want to enable power supply status monitoring for � � � � �Wacom Bluetooth devices.--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at �http://vger.kernel.org/majordomo-info.html Please read the FAQ at �http://www.tux.org/lkml/
Re: [29/48] HID: wiimote: Select INPUT_FF_MEMLESS
Quoted 6 lines · Paul Gortmaker
Quoted 1 line · Greg KH
3.1-stable review patch. �If anyone has any objections, please let me know.
This one looks like typical patch Makefile/Kconfig "oh, hey this fits anywhere" nonsense, and is completely broken. �Original was for a Wiimote, not Wacom.
Could someone explain to me where this came from? I cannot remember writing this patch. I wrote this one:
http://git.kernel.org/?p=linux/kernel/git/jikos/hid.git;a=commitdiff;h=ef6f41157f3864d9bf42671b2ed66062dcafb72e
I don't know where you got this "From" line?
Regards
David
Quoted 37 lines
Quoted 37 lines
------------------
From: David Herrmann <[email protected]>
commit
ef6f41157f3864d9bf42671b2ed66062dcafb72eupstream.We depend on memless force-feedback support, therefore correctly select the related config options.
Reported-by Randy Dunlap <[email protected]>Signed-off-by David Herrmann <[email protected]>Signed-off-by Jiri Kosina <[email protected]>Signed-off-by Greg Kroah-Hartman <[email protected]>---
�drivers/hid/Kconfig | � �1 +
�1 file changed, 1 insertion(+)drivers/hid/Kconfig +0
-0@@ -583,6 +583,7 @@ config HID_WACOM_POWER_SUPPLY� � � �bool "Wacom Bluetooth devices power supply status support" � � � �depends on
HID_WACOM
� � � �selectPOWER_SUPPLY
+ � � � selectINPUT_FF_MEMLESS
� � � �---help---
� � � � �Say Y here if you want to enable power supply status monitoring for � � � � �Wacom Bluetooth devices.--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at �http://vger.kernel.org/majordomo-info.html Please read the FAQ at �http://www.tux.org/lkml/
Re: [29/48] HID: wiimote: Select INPUT_FF_MEMLESS
Quoted 9 lines · David Herrmann
Quoted 6 lines · Paul Gortmaker
Quoted 1 line · Greg KH
3.1-stable review patch. If anyone has any objections, please let me know.
This one looks like typical patch Makefile/Kconfig "oh, hey this fits anywhere" nonsense, and is completely broken. Original was for a Wiimote, not Wacom.
Quoted 5 lines
Could someone explain to me where this came from? I cannot remember writing this patch. I wrote this one:
http://git.kernel.org/?p=linux/kernel/git/jikos/hid.git;a=commitdiff;h=ef6f41157f3864d9bf42671b2ed66062dcafb72eI don't know where you got this "From" line?
The patch command creates it automatically.
Get a copy of linux-3.1.y
git show ef6f41157f38 | patch -p1
git diff
There is the new patch.
regards,
dan carpenter
Re: [29/48] HID: wiimote: Select INPUT_FF_MEMLESS
In reply to Paul GortmakerQuoted 5 lines · Paul Gortmaker
Quoted 1 line · Greg KH
3.1-stable review patch. �If anyone has any objections, please let me know.
This one looks like typical patch Makefile/Kconfig "oh, hey this fits anywhere" nonsense, and is completely broken. Original was for a Wiimote, not Wacom.
Ah, thanks for catching that, I missed it on the fuzz application. I've removed it now from this tree, and the 3.0 tree.
greg k-h
PATCH 30/48 UBI: fix missing scrub when there is a bit-flip
In reply to Greg KH3.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Bhavesh Parekh <[email protected]>
commit e801e128b2200c40a0ec236cf2330b2586b6e05a upstream.
Under some cases, when scrubbing the PEB if we did not get the lock on the PEB it fails to scrub. Add that PEB again to the scrub list
Artem: minor amendments.
--- drivers/mtd/ubi/eba.c | 6 ++++-- drivers/mtd/ubi/ubi.h | 2 ++ drivers/mtd/ubi/wl.c | 5 ++++- 3 files changed, 10 insertions(+), 3 deletions(-)
drivers/mtd/ubi/eba.c +4 -2
@@ -1028,12 +1028,14 @@ int ubi_eba_copy_leb(struct ubi_device ** 'ubi_wl_put_peb()' function on the @ubi->move_mutex. In turn, we are * holding @ubi->move_mutex and go sleep on the LEB lock. So, if the * LEB is already locked, we just do not move it and return -* %MOVE_CANCEL_RACE, which means that UBI will re-try, but later. +* %MOVE_RETRY. Note, we do not return %MOVE_CANCEL_RACE here because +* we do not know the reasons of the contention - it may be just a +* normal I/O on this LEB, so we want to re-try. */ err =leb_write_trylock (ubi, vol_id, lnum);if (err) {dbg_wl ("contention on LEB %d:%d, cancel" , vol_id, lnum); -return MOVE_CANCEL_RACE ; +return MOVE_RETRY ; }/*
drivers/mtd/ubi/ubi.h +2 -0
@@ -120,6 +120,7 @@ enum {* PEB * MOVE_CANCEL_BITFLIPS: canceled because a bit-flip was detected in the * target PEB +* MOVE_RETRY: retry scrubbing the PEB */ enum {MOVE_CANCEL_RACE =1 ,
@@ -127,6 +128,7 @@ enum {MOVE_TARGET_RD_ERR ,MOVE_TARGET_WR_ERR ,MOVE_CANCEL_BITFLIPS , + MOVE_RETRY, };/**
drivers/mtd/ubi/wl.c +4 -1
@@ -795,7 +795,10 @@ static int wear_leveling_worker(struct u protect =1 ; goto out_not_moved; } - +if (err ==MOVE_RETRY ) { + scrubbing =1 ; + goto out_not_moved; + }if (err ==MOVE_CANCEL_BITFLIPS || err ==MOVE_TARGET_WR_ERR || err ==MOVE_TARGET_RD_ERR ) {/*
PATCH 31/48 UBI: fix use-after-free on error path
In reply to Greg KH3.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Artem Bityutskiy <[email protected]>
commit e57e0d8e818512047fe379157c3f77f1b9fabffb upstream.
When we fail to erase a PEB, we free the corresponding erase entry object, but then re-schedule this object if the error code was something like -EAGAIN. Obviously, it is a bug to use the object after we have freed it.
--- drivers/mtd/ubi/wl.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-)
drivers/mtd/ubi/wl.c +4 -3
@@ -1052,7 +1052,6 @@ static int erase_worker(struct ubi_devicubi_err ("failed to erase PEB %d, error %d" , pnum, err);kfree (wl_wrk); -kmem_cache_free (ubi_wl_entry_slab, e);if (err == -EINTR || err == -ENOMEM || err == -EAGAIN || err == -EBUSY ) {
@@ -1065,14 +1064,16 @@ static int erase_worker(struct ubi_devic goto out_ro; }return err; - }else if (err != -EIO ) { + } + +kmem_cache_free (ubi_wl_entry_slab, e); +if (err != -EIO )/* * If this is not %-EIO, we have no idea what to do. Scheduling * this physical eraseblock for erasure again would cause * errors again and again. Well, lets switch to R/O mode. */ goto out_ro; - }/* It is %-EIO, the PEB went bad */
PATCH 32/48 PCI: Fix PCI_EXP_TYPE_RC_EC value
In reply to Greg KH3.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alex Williamson <[email protected]>
commit 1830ea91c20b06608f7cdb2455ce05ba834b3214 upstream.
Spec shows this as 1010b = 0xa
--- include/linux/pci_regs.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
include/linux/pci_regs.h +1 -1
@@ -392,7 +392,7 @@#define PCI_EXP_TYPE_DOWNSTREAM 0x6/* Downstream Port */ #define PCI_EXP_TYPE_PCI_BRIDGE 0x7/* PCI/PCI-X Bridge */ #define PCI_EXP_TYPE_RC_END 0x9/* Root Complex Integrated Endpoint */ -#define PCI_EXP_TYPE_RC_EC 0x10/* Root Complex Event Collector */ +#define PCI_EXP_TYPE_RC_EC 0xa/* Root Complex Event Collector */ #define PCI_EXP_FLAGS_SLOT 0x0100/* Slot implemented */ #define PCI_EXP_FLAGS_IRQ 0x3e00/* Interrupt message number */ #define PCI_EXP_DEVCAP 4/* Device capabilities */
PATCH 33/48 PCI: msi: Disable msi interrupts when we initialize a pci device
In reply to Greg KH3.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: "Eric W. Biederman" <[email protected]>
commit a776c491ca5e38c26d9f66923ff574d041e747f4 upstream.
I traced a nasty kexec on panic boot failure to the fact that we had screaming msi interrupts and we were not disabling the msi messages at kernel startup. The booting kernel had not enabled those interupts so was not prepared to handle them.
I can see no reason why we would ever want to leave the msi interrupts enabled at boot if something else has enabled those interrupts. The pci spec specifies that msi interrupts should be off by default. Drivers are expected to enable the msi interrupts if they want to use them. Our interrupt handling code reprograms the interrupt handlers at boot and will not be be able to do anything useful with an unexpected interrupt.
This patch applies cleanly all of the way back to 2.6.32 where I noticed the problem.
--- drivers/pci/msi.c | 10 ++++++++++ 1 file changed, 10 insertions(+)
drivers/pci/msi.c +10 -0
@@ -869,5 +869,15 @@ EXPORT_SYMBOL(pci_msi_enabled);void pci_msi_init_pci_dev (struct pci_dev *dev) { +int pos;INIT_LIST_HEAD (&dev->msi_list); + +/* Disable the msi hardware to avoid screaming interrupts +* during boot. This is the power on reset default so +* usually this should be a noop. +*/ + pos =pci_find_capability (dev,PCI_CAP_ID_MSI ); +if (pos) +msi_set_enable (dev, pos,0 ); +msix_set_enable (dev,0 ); }
PATCH 34/48 x86/PCI: Ignore CPU non-addressable _CRS reserved memory resources
In reply to Greg KH3.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Gary Hade <[email protected]>
commit ae5cd86455381282ece162966183d3f208c6fad7 upstream.
This assures that a _CRS reserved host bridge window or window region is not used if it is not addressable by the CPU. The new code either trims the window to exclude the non-addressable portion or totally ignores the window if the entire window is non-addressable.
The current code has been shown to be problematic with 32-bit non-PAE kernels on systems where _CRS reserves resources above 4GB.
--- arch/x86/pci/acpi.c | 18 ++++++++++++++++-- 1 file changed, 16 insertions(+), 2 deletions(-)
arch/x86/pci/acpi.c +16 -2
@@ -149,7 +149,7 @@ setup_resource(struct acpi_resource *acpstruct acpi_resource_address64 addr;acpi_status status;unsigned long flags; -u64 start, end; +u64 start, orig_end, end; status =resource_to_addr (acpi_res, &addr);if (!ACPI_SUCCESS (status))
@@ -165,7 +165,21 @@ setup_resource(struct acpi_resource *acpreturn AE_OK ; start = addr.minimum + addr.translation_offset; - end = addr.maximum + addr.translation_offset; + orig_end = end = addr.maximum + addr.translation_offset; + +/* Exclude non-addressable range or non-addressable portion of range */ + end =min (end, (u64 )iomem_resource.end); +if (end <= start) { +dev_info (&info->bridge->dev, +"host bridge window [%#llx-%#llx] " +"(ignored, not CPU addressable)\n" , start, orig_end); +return AE_OK ; + }else if (orig_end != end) { +dev_info (&info->bridge->dev, +"host bridge window [%#llx-%#llx] " +"([%#llx-%#llx] ignored, not CPU addressable)\n" , + start, orig_end, end +1 , orig_end); + } res = &info->res[info->res_num]; res->name = info->name;
PATCH 35/48 x86/PCI: amd: factor out MMCONFIG discovery
In reply to Greg KH3.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Bjorn Helgaas <[email protected]>
commit 24d25dbfa63c376323096660bfa9ad45a08870ce upstream.
This factors out the AMD native MMCONFIG discovery so we can use it outside amd_bus.c.
amd_bus.c reads AMD MSRs so it can remove the MMCONFIG area from the PCI resources. We may also need the MMCONFIG information to work around BIOS defects in the ACPI MCFG table.
--- arch/x86/include/asm/amd_nb.h | 2 ++ arch/x86/kernel/amd_nb.c | 31 +++++++++++++++++++++++++++++++ arch/x86/pci/amd_bus.c | 42 +++++++++++------------------------------- 3 files changed, 44 insertions(+), 31 deletions(-)
arch/x86/include/asm/amd_nb.h +2 -0
@@ -1,6 +1,7 @@#ifndef _ASM_X86_AMD_NB_H#define _ASM_X86_AMD_NB_H +#include <linux/ioport.h> #include <linux/pci.h> struct amd_nb_bus_dev_range {
@@ -13,6 +14,7 @@ extern const struct pci_device_id amd_nbextern const struct amd_nb_bus_dev_range amd_nb_bus_dev_ranges[];extern bool early_is_amd_nb (u32 value); +extern struct resource *amd_get_mmconfig_range (struct resource *res);extern int amd_cache_northbridges (void );extern void amd_flush_garts (void );extern int amd_numa_init (void );
arch/x86/kernel/amd_nb.c +31 -0
@@ -119,6 +119,37 @@ bool __init early_is_amd_nb(u32 device)return false; } +struct resource *amd_get_mmconfig_range (struct resource *res) +{ +u32 address; +u64 base, msr; +unsigned segn_busn_bits; + +if (boot_cpu_data.x86_vendor !=X86_VENDOR_AMD ) +return NULL ; + +/* assume all cpus from fam10h have mmconfig */ +if (boot_cpu_data.x86 <0x10 ) +return NULL ; + + address =MSR_FAM10H_MMIO_CONF_BASE ; +rdmsrl (address, msr); + +/* mmconfig is not enabled */ +if (!(msr &FAM10H_MMIO_CONF_ENABLE )) +return NULL ; + + base = msr & (FAM10H_MMIO_CONF_BASE_MASK <<FAM10H_MMIO_CONF_BASE_SHIFT ); + + segn_busn_bits = (msr >>FAM10H_MMIO_CONF_BUSRANGE_SHIFT ) & +FAM10H_MMIO_CONF_BUSRANGE_MASK ; + + res->flags =IORESOURCE_MEM ; + res->start = base; + res->end = base + (1ULL <<(segn_busn_bits +20 )) -1 ; +return res; +} +int amd_get_subcaches (int cpu) {struct pci_dev *link =node_to_amd_nb (amd_get_nb_id (cpu))->link;
arch/x86/pci/amd_bus.c +11 -31
63 lines not on this page · raw message
PATCH 36/48 x86/PCI: build amd_bus.o only when CONFIG_AMD_NB=y
In reply to Greg KH3.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Bjorn Helgaas <[email protected]>
commit 5cf9a4e69c1ff0ccdd1d2b7404f95c0531355274 upstream.
We only need amd_bus.o for AMD systems with PCI. arch/x86/pci/Makefile already depends on CONFIG_PCI=y, so this patch just adds the dependency on CONFIG_AMD_NB.
--- arch/x86/pci/Makefile | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
arch/x86/pci/Makefile +2 -1
@@ -18,8 +18,9 @@ obj-$(CONFIG_X86_NUMAQ) += numaq_32.o obj-$(CONFIG_X86_MRST) += mrst.o obj-y += common.o early.o -obj-y += amd_bus.o bus_numa.o +obj-y += bus_numa.o +obj-$(CONFIG_AMD_NB) += amd_bus.o obj-$(CONFIG_PCI_CNB20LE_QUIRK) += broadcom_bus.o ifeq ($(CONFIG_PCI_DEBUG),y)
PATCH 37/48 SCSI: mpt2sas: Release spinlock for the raid device list before blocking it
In reply to Greg KH3.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: "[email protected]" <[email protected]>
commit 30c43282f3d347f47f9e05199d2b14f56f3f2837 upstream.
Added code to release the spinlock that is used to protect the raid device list before calling a function that can block. The blocking was causing a reschedule, and subsequently it is tried to acquire the same lock, resulting in a panic (NMI Watchdog detecting a CPU lockup).
--- drivers/scsi/mpt2sas/mpt2sas_scsih.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-)
drivers/scsi/mpt2sas/mpt2sas_scsih.c +4 -3
@@ -6564,6 +6564,7 @@ _scsih_mark_responding_raid_device(struc }else sas_target_priv_data =NULL ; raid_device->responding =1 ; +spin_unlock_irqrestore (&ioc->raid_device_lock, flags);starget_printk (KERN_INFO , raid_device->starget,"handle(0x%04x), wwid(0x%016llx)\n" , handle, (unsigned long long )raid_device->wwid);
@@ -6574,16 +6575,16 @@ _scsih_mark_responding_raid_device(struc*/ _scsih_init_warpdrive_properties (ioc, raid_device);if (raid_device->handle == handle) - goto out; +return ;printk (KERN_INFO "\thandle changed from(0x%04x)!!!\n" , raid_device->handle); raid_device->handle = handle;if (sas_target_priv_data) sas_target_priv_data->handle = handle; - goto out; +return ; } } - out: +spin_unlock_irqrestore (&ioc->raid_device_lock, flags); }
PATCH 38/48 SCSI: mpt2sas : Fix for memory allocation error for large host credits
In reply to Greg KH3.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: "[email protected]" <[email protected]>
commit aff132d95ffe14eca96cab90597cdd010b457af7 upstream.
The amount of memory required for tracking chain buffers is rather large, and when the host credit count is big, memory allocation failure occurs inside __get_free_pages.
The fix is to limit the number of chains to 100,000. In addition, the number of host credits is limited to 30,000 IOs. However this limitation can be overridden this using the command line option max_queue_depth. The algorithm for calculating the reply_post_queue_depth is changed so that it is equal to (reply_free_queue_depth + 16), previously it was (reply_free_queue_depth * 2).
--- drivers/scsi/mpt2sas/mpt2sas_base.c | 83 +++++++++++------------------------ drivers/scsi/mpt2sas/mpt2sas_scsih.c | 4 - 2 files changed, 29 insertions(+), 58 deletions(-)
drivers/scsi/mpt2sas/mpt2sas_base.c +27 -56
@@ -66,6 +66,8 @@ static MPT_CALLBACK mpt_callbacks[MPT_MA#define FAULT_POLLING_INTERVAL 1000/* in milliseconds */ +#define MAX_HBA_QUEUE_DEPTH 30000 +#define MAX_CHAIN_DEPTH 100000static int max_queue_depth =-1 ;module_param (max_queue_depth, int,0 );MODULE_PARM_DESC (max_queue_depth," max controller queue depth " );
@@ -2098,8 +2100,6 @@ _base_release_memory_pools(struct MPT2SA }if (ioc->chain_dma_pool)pci_pool_destroy (ioc->chain_dma_pool); - } -if (ioc->chain_lookup) {free_pages ((ulong )ioc->chain_lookup, ioc->chain_pages); ioc->chain_lookup =NULL ; }
@@ -2117,9 +2117,7 @@ static int _base_allocate_memory_pools(struct MPT2SAS_ADAPTER *ioc, int sleep_flag) {struct mpt2sas_facts *facts; -u32 queue_size, queue_diff;u16 max_sge_elements; -u16 num_of_reply_frames;u16 chains_needed_per_io;u32 sz, total_sz;u32 retry_sz;
@@ -2146,7 +2144,8 @@ _base_allocate_memory_pools(struct MPT2S max_request_credit = (max_queue_depth < facts->RequestCredit) ? max_queue_depth : facts->RequestCredit; else - max_request_credit = facts->RequestCredit; + max_request_credit =min_t (u16, facts->RequestCredit, +MAX_HBA_QUEUE_DEPTH ); ioc->hba_queue_depth = max_request_credit; ioc->hi_priority_depth = facts->HighPriorityCredit;
@@ -2187,50 +2186,25 @@ _base_allocate_memory_pools(struct MPT2S } ioc->chains_needed_per_io = chains_needed_per_io; -/* reply free queue sizing - taking into account for events */ - num_of_reply_frames = ioc->hba_queue_depth +32 ; - -/* number of replies frames can't be a multiple of 16 */ -/* decrease number of reply frames by 1 */ -if (!(num_of_reply_frames %16 )) - num_of_reply_frames--; - -/* calculate number of reply free queue entries -* (must be multiple of 16) -*/ - -/* (we know reply_free_queue_depth is not a multiple of 16) */ - queue_size = num_of_reply_frames; - queue_size +=16 - (queue_size %16 ); - ioc->reply_free_queue_depth = queue_size; - -/* reply descriptor post queue sizing */ -/* this size should be the number of request frames + number of reply -* frames -*/ +/* reply free queue sizing - taking into account for 64 FW events */ + ioc->reply_free_queue_depth = ioc->hba_queue_depth +64 ; - queue_size = ioc->hba_queue_depth + num_of_reply_frames +1 ; -/* round up to 16 byte boundary */ -if (queue_size %16 ) - queue_size +=16 - (queue_size %16 ); - -/* check against IOC maximum reply post queue depth */ -if (queue_size > facts->MaxReplyDescriptorPostQueueDepth) { - queue_diff = queue_size - - facts->MaxReplyDescriptorPostQueueDepth; - -/* round queue_diff up to multiple of 16 */ -if (queue_diff %16 ) - queue_diff +=16 - (queue_diff %16 ); - -/* adjust hba_queue_depth, reply_free_queue_depth, -* and queue_size -*/ - ioc->hba_queue_depth -= (queue_diff /2 ); - ioc->reply_free_queue_depth -= (queue_diff /2 ); - queue_size = facts->MaxReplyDescriptorPostQueueDepth; +/* align the reply post queue on the next 16 count boundary */ +if (!ioc->reply_free_queue_depth %16 ) + ioc->reply_post_queue_depth = ioc->reply_free_queue_depth +16 ; +else + ioc->reply_post_queue_depth = ioc->reply_free_queue_depth + +32 - (ioc->reply_free_queue_depth %16 ); +if (ioc->reply_post_queue_depth > + facts->MaxReplyDescriptorPostQueueDepth) { + ioc->reply_post_queue_depth =min_t (u16, + (facts->MaxReplyDescriptorPostQueueDepth - + (facts->MaxReplyDescriptorPostQueueDepth %16 )), + (ioc->hba_queue_depth - (ioc->hba_queue_depth %16 ))); + ioc->reply_free_queue_depth = ioc->reply_post_queue_depth -16 ; + ioc->hba_queue_depth = ioc->reply_free_queue_depth -64 ; } - ioc->reply_post_queue_depth = queue_size; + dinitprintk(ioc, printk(MPT2SAS_INFO_FMT "scatter gather: " "sge_in_main_msg(%d), sge_per_chain(%d), sge_per_io(%d), "
@@ -2316,15 +2290,12 @@ _base_allocate_memory_pools(struct MPT2S"depth(%d)\n" , ioc->name, ioc->request, ioc->scsiio_depth)); -/* loop till the allocation succeeds */ -do { - sz = ioc->chain_depth *sizeof (struct chain_tracker ); - ioc->chain_pages =get_order (sz); - ioc->chain_lookup = (struct chain_tracker *)__get_free_pages ( -GFP_KERNEL , ioc->chain_pages); -if (ioc->chain_lookup ==NULL ) - ioc->chain_depth -=100 ; - }while (ioc->chain_lookup ==NULL ); + ioc->chain_depth =min_t (u32, ioc->chain_depth,MAX_CHAIN_DEPTH ); + sz = ioc->chain_depth *sizeof (struct chain_tracker ); + ioc->chain_pages =get_order (sz); + + ioc->chain_lookup = (struct chain_tracker *)__get_free_pages ( +GFP_KERNEL , ioc->chain_pages); ioc->chain_dma_pool =pci_pool_create ("chain pool" , ioc->pdev, ioc->request_sz,16 ,0 );if (!ioc->chain_dma_pool) {
drivers/scsi/mpt2sas/mpt2sas_scsih.c +2 -2
@@ -978,8 +978,8 @@ _scsih_get_chain_buffer_tracker(struct Mspin_lock_irqsave (&ioc->scsi_lookup_lock, flags);if (list_empty (&ioc->free_chain_list)) {spin_unlock_irqrestore (&ioc->scsi_lookup_lock, flags); -printk (MPT2SAS_WARN_FMT "chain buffers not available\n" , - ioc->name); +dfailprintk (ioc,printk (MPT2SAS_WARN_FMT "chain buffers not " +"available\n" , ioc->name));return NULL ; } chain_req = list_entry(ioc->free_chain_list.next,
PATCH 39/48 xen/xenbus: Reject replies with payload > XENSTORE_PAYLOAD_MAX.
In reply to Greg KH3.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ian Campbell <[email protected]>
commit 9e7860cee18241633eddb36a4c34c7b61d8cecbc upstream.
Haogang Chen found out that:
There is a potential integer overflow in process_msg() that could result in cross-domain attack.
body = kmalloc(msg->hdr.len + 1, GFP_NOIO | __GFP_HIGH);
When a malicious guest passes 0xffffffff in msg->hdr.len, the subsequent call to xb_read() would write to a zero-length buffer.
The other end of this connection is always the xenstore backend daemon so there is no guest (malicious or otherwise) which can do this. The xenstore daemon is a trusted component in the system.
However this seem like a reasonable robustness improvement so we should have it.
And Ian when read the API docs found that:
The payload length (len field of the header) is limited to 4096 (XENSTORE_PAYLOAD_MAX) in both directions. If a client exceeds the limit, its xenstored connection will be immediately killed by xenstored, which is usually catastrophic from the client's point of view. Clients (particularly domains, which cannot just reconnect) should avoid this.
so this patch checks against that instead.
This also avoids a potential integer overflow pointed out by Haogang Chen.
--- drivers/xen/xenbus/xenbus_xs.c | 6 ++++++ include/xen/interface/io/xs_wire.h | 3 +++ 2 files changed, 9 insertions(+)
drivers/xen/xenbus/xenbus_xs.c +6 -0
@@ -801,6 +801,12 @@ static int process_msg(void) goto out; } +if (msg->hdr.len >XENSTORE_PAYLOAD_MAX ) { +kfree (msg); + err = -EINVAL ; + goto out; + } + body =kmalloc (msg->hdr.len +1 ,GFP_NOIO | __GFP_HIGH);if (body ==NULL ) {kfree (msg);
include/xen/interface/io/xs_wire.h +3 -0
@@ -84,4 +84,7 @@ struct xenstore_domain_interface { XENSTORE_RING_IDX rsp_cons, rsp_prod; }; +/* Violating this is very bad. See docs/misc/xenstore.txt. */ +#define XENSTORE_PAYLOAD_MAX 4096 +#endif /* _XS_WIRE_H */
PATCH 40/48 md/raid1: perform bad-block tests for WriteMostly devices too.
In reply to Greg KH3.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: NeilBrown <[email protected]>
commit 307729c8bc5b5a41361af8af95906eee7552acb1 upstream.
We normally try to avoid reading from write-mostly devices, but when we do we really have to check for bad blocks and be sure not to try reading them.
With the current code, best_good_sectors might not get set and that causes zero-length read requests to be send down which is very confusing.
This bug was introduced in commit d2eb35acfdccbe2 and so the patch is suitable for 3.1.x and 3.2.x
--- drivers/md/raid1.c | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-)
drivers/md/raid1.c +10 -1
@@ -508,8 +508,17 @@ static int read_balance(conf_t *conf, r1if (test_bit (WriteMostly, &rdev->flags)) {/* Don't balance among write-mostly, just * use the first as a last resort */ -if (best_disk <0 ) +if (best_disk <0 ) { +if (is_badblock (rdev, this_sector, sectors, + &first_bad, &bad_sectors)) { +if (first_bad < this_sector) +/* Cannot use this */ +continue ; + best_good_sectors = first_bad - this_sector; + }else + best_good_sectors = sectors; best_disk = disk; + }continue ; }/* This is a reasonable device to use. It might
PATCH 41/48 ima: free duplicate measurement memory
In reply to Greg KH3.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Roberto Sassu <[email protected]>
commit 45fae7493970d7c45626ccd96d4a74f5f1eea5a9 upstream.
Info about new measurements are cached in the iint for performance. When the inode is flushed from cache, the associated iint is flushed as well. Subsequent access to the inode will cause the inode to be re-measured and will attempt to add a duplicate entry to the measurement list.
This patch frees the duplicate measurement memory, fixing a memory leak.
--- security/integrity/ima/ima_api.c | 4 ++-- security/integrity/ima/ima_queue.c | 1 + 2 files changed, 3 insertions(+), 2 deletions(-)
security/integrity/ima/ima_api.c +2 -2
@@ -177,8 +177,8 @@ void ima_store_measurement(struct ima_iistrncpy (entry->template.file_name, filename,IMA_EVENT_NAME_LEN_MAX ); result =ima_store_template (entry, violation, inode); -if (!result) +if (!result || result == -EEXIST ) iint->flags |=IMA_MEASURED ; -else +if (result <0 )kfree (entry); }
security/integrity/ima/ima_queue.c +1 -0
@@ -114,6 +114,7 @@ int ima_add_template_entry(struct ima_tememcpy (digest, entry->digest,sizeof digest);if (ima_lookup_digest_entry (digest)) { audit_cause ="hash_exists" ; + result = -EEXIST ; goto out; } }
PATCH 42/48 ima: fix invalid memory reference
In reply to Greg KH3.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Roberto Sassu <[email protected]>
commit 7b7e5916aa2f46e57f8bd8cb89c34620ebfda5da upstream.
Don't free a valid measurement entry on TPM PCR extend failure.
--- security/integrity/ima/ima_queue.c | 16 +++++++++++----- 1 file changed, 11 insertions(+), 5 deletions(-)
security/integrity/ima/ima_queue.c +11 -5
@@ -23,6 +23,8 @@#include <linux/slab.h> #include "ima.h" +#define AUDIT_CAUSE_LEN_MAX 32 +LIST_HEAD (ima_measurements);/* list of all measurements */ /* key: inode (before secure-hashing a file) */
@@ -94,7 +96,8 @@ static int ima_pcr_extend(const u8 *hash result =tpm_pcr_extend (TPM_ANY_NUM ,CONFIG_IMA_MEASURE_PCR_IDX , hash);if (result !=0 ) -pr_err ("IMA: Error Communicating to TPM chip\n" ); +pr_err ("IMA: Error Communicating to TPM chip, result: %d\n" , + result);return result; }
@@ -106,8 +109,9 @@ int ima_add_template_entry(struct ima_te {u8 digest[IMA_DIGEST_SIZE ];const char *audit_cause ="hash_added" ; +char tpm_audit_cause[AUDIT_CAUSE_LEN_MAX ];int audit_info =1 ; -int result =0 ; +int result =0 , tpmresult =0 ;mutex_lock (&ima_extend_list_mutex);if (!violation) {
@@ -129,9 +133,11 @@ int ima_add_template_entry(struct ima_teif (violation)/* invalidate pcr */ memset (digest,0xff ,sizeof digest); - result =ima_pcr_extend (digest); -if (result !=0 ) { - audit_cause ="TPM error" ; + tpmresult =ima_pcr_extend (digest); +if (tpmresult !=0 ) { +snprintf (tpm_audit_cause,AUDIT_CAUSE_LEN_MAX ,"TPM_error(%d)" , + tpmresult); + audit_cause = tpm_audit_cause; audit_info =0 ; } out:
PATCH 43/48 slub: fix a possible memleak in __slab_alloc()
In reply to Greg KH3.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Eric Dumazet <[email protected]>
commit 73736e0387ba0e6d2b703407b4d26168d31516a7 upstream.
Zhihua Che reported a possible memleak in slub allocator on CONFIG_PREEMPT=y builds.
It is possible current thread migrates right before disabling irqs in __slab_alloc(). We must check again c->freelist, and perform a normal allocation instead of scratching c->freelist.
Many thanks to Zhihua Che for spotting this bug, introduced in 2.6.39
V2: Its also possible an IRQ freed one (or several) object(s) and populated c->freelist, so its not a CONFIG_PREEMPT only problem.
--- mm/slub.c | 5 +++++ 1 file changed, 5 insertions(+)
mm/slub.c +5 -0
@@ -2077,6 +2077,11 @@ static void *__slab_alloc(struct kmem_ca goto new_slab; } +/* must check again c->freelist in case of cpu migration or IRQ */ + object = c->freelist; +if (object) + goto load_freelist; +stat (s,ALLOC_SLOWPATH ); do {
PATCH 44/48 PNP: work around Dell 1536/1546 BIOS MMCONFIG bug that breaks USB
In reply to Greg KH3.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Bjorn Helgaas <[email protected]>
commit eb31aae8cb5eb54e234ed2d857ddac868195d911 upstream.
Some Dell BIOSes have MCFG tables that don't report the entire MMCONFIG area claimed by the chipset. If we move PCI devices into that claimed-but-unreported area, they don't work.
This quirk reads the AMD MMCONFIG MSRs and adds PNP0C01 resources as needed to cover the entire area.
Example problem scenario:
BIOS-e820: 00000000cfec5400 - 00000000d4000000 (reserved)
Fam 10h mmconf [d0000000, dfffffff]
PCI: MMCONFIG for domain 0000 [bus 00-3f] at [mem 0xd0000000-0xd3ffffff] (base 0xd0000000) pnp 00:0c: [mem 0xd0000000-0xd3ffffff]
pci 0000:00:12.0: reg 10: [mem 0xffb00000-0xffb00fff]
pci 0000:00:12.0: no compatible bridge window for [mem 0xffb00000-0xffb00fff] pci 0000:00:12.0: BAR 0: assigned [mem 0xd4000000-0xd40000ff]
References: https://bugzilla.kernel.org/show_bug.cgi?id=31602
References: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/647043
References: https://bugzilla.redhat.com/show_bug.cgi?id=770308
--- drivers/pnp/quirks.c | 42 ++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 42 insertions(+)
drivers/pnp/quirks.c +42 -0
@@ -295,6 +295,45 @@ static void quirk_system_pci_resources(s } } +#ifdef CONFIG_AMD_NB + +#include <asm/amd_nb.h> + +static void quirk_amd_mmconfig_area (struct pnp_dev *dev) +{ +resource_size_t start, end; +struct pnp_resource *pnp_res; +struct resource *res; +struct resource mmconfig_res, *mmconfig; + + mmconfig =amd_get_mmconfig_range (&mmconfig_res); +if (!mmconfig) +return ; + +list_for_each_entry (pnp_res, &dev->resources, list) { + res = &pnp_res->res; +if (res->end < mmconfig->start || res->start > mmconfig->end || + (res->start == mmconfig->start && res->end == mmconfig->end)) +continue ; + +dev_info (&dev->dev,FW_BUG +"%pR covers only part of AMD MMCONFIG area %pR; adding more reservations\n" , + res, mmconfig); +if (mmconfig->start < res->start) { + start = mmconfig->start; + end = res->start -1 ; +pnp_add_mem_resource (dev, start, end,0 ); + } +if (mmconfig->end > res->end) { + start = res->end +1 ; + end = mmconfig->end; +pnp_add_mem_resource (dev, start, end,0 ); + } +break ; + } +} +#endif +/* * PnP Quirks * Cards or devices that need some tweaking due to incomplete resource info
@@ -322,6 +361,9 @@ static struct pnp_fixup pnp_fixups[] = {/* PnP resources that might overlap PCI BARs */ {"PNP0c01", quirk_system_pci_resources}, {"PNP0c02", quirk_system_pci_resources}, +#ifdef CONFIG_AMD_NB + {"PNP0c01", quirk_amd_mmconfig_area}, +#endif {""} };
PATCH 45/48 rtl8192se: Fix BUG caused by failure to check skb allocation
In reply to Greg KH3.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Larry Finger <[email protected]>
commit d90db4b12bc1b9b8a787ef28550fdb767ee25a49 upstream.
When downloading firmware into the device, the driver fails to check the return when allocating an skb. When the allocation fails, a BUG can be generated, as seen in https://bugzilla.redhat.com/show_bug.cgi?id=771656.
--- drivers/net/wireless/rtlwifi/rtl8192se/fw.c | 4 ++++ 1 file changed, 4 insertions(+)
drivers/net/wireless/rtlwifi/rtl8192se/fw.c +4 -0
@@ -196,6 +196,8 @@ static bool _rtl92s_firmware_downloadcod/* Allocate skb buffer to contain firmware */ /* info and tx descriptor info. */ skb =dev_alloc_skb (frag_length); +if (!skb) +return false;skb_reserve (skb, extra_descoffset); seg_ptr = (u8 *)skb_put (skb, (u32)(frag_length - extra_descoffset));
@@ -573,6 +575,8 @@ static bool _rtl92s_firmware_set_h2c_cmd len =_rtl92s_get_h2c_cmdlen (MAX_TRANSMIT_BUFFER_SIZE ,1 , &cmd_len); skb =dev_alloc_skb (len); +if (!skb) +return false; cb_desc = (struct rtl_tcb_desc *)(skb->cb); cb_desc->queue_index =TXCMD_QUEUE ; cb_desc->cmd_or_init =DESC_PACKET_TYPE_NORMAL ;
PATCH 46/48 mac80211: fix rx->key NULL pointer dereference in promiscuous mode
In reply to Greg KH3.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Stanislaw Gruszka <[email protected]>
commit 1140afa862842ac3e56678693050760edc4ecde9 upstream.
Since:
commit 816c04fe7ef01dd9649f5ccfe796474db8708be5
Author: Christian Lamparter <[email protected]> Date: Sat Apr 30 15:24:30 2011 +0200
mac80211: consolidate MIC failure report handling
is possible to that we dereference rx->key == NULL when driver set RX_FLAG_MMIC_STRIPPED and not RX_FLAG_IV_STRIPPED and we are in promiscuous mode. This happen with rt73usb and rt61pci at least.
Before the commit we always check rx->key against NULL, so I assume fix should be done in mac80211 (also mic_fail path has similar check).
References:
https://bugzilla.redhat.com/show_bug.cgi?id=769766
http://rt2x00.serialmonkey.com/pipermail/users_rt2x00.serialmonkey.com/2012-January/004395.html
--- net/mac80211/wpa.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
net/mac80211/wpa.c +1 -1
@@ -105,7 +105,7 @@ ieee80211_rx_h_michael_mic_verify(structif (status->flag &RX_FLAG_MMIC_ERROR ) goto mic_fail; -if (!(status->flag &RX_FLAG_IV_STRIPPED )) +if (!(status->flag &RX_FLAG_IV_STRIPPED ) && rx->key) goto update_iv;return RX_CONTINUE ;
PATCH 47/48 memcg: add mem_cgroup_replace_page_cache() to fix LRU issue
In reply to Greg KH3.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: KAMEZAWA Hiroyuki <[email protected]>
commit ab936cbcd02072a34b60d268f94440fd5cf1970b upstream.
Commit ef6a3c6311 ("mm: add replace_page_cache_page() function") added a function replace_page_cache_page(). This function replaces a page in the radix-tree with a new page. WHen doing this, memory cgroup needs to fix up the accounting information. memcg need to check PCG_USED bit etc.
In some(many?) cases, 'newpage' is on LRU before calling replace_page_cache(). So, memcg's LRU accounting information should be fixed, too.
This patch adds mem_cgroup_replace_page_cache() and removes the old hooks.
In that function, old pages will be unaccounted without touchingres_counter and new page will be accounted to the memcg (of old page). WHen overwriting pc->mem_cgroup of newpage, take zone->lru_lock and avoid races with LRU handling.
Background:
replace_page_cache_page() is called by FUSE code in its splice() handling. Here, 'newpage' is replacing oldpage but this newpage is not a newly allocated page and may be on LRU. LRU mis-accounting will be critical for memory cgroup because rmdir() checks the whole LRU is empty and there is no account leak. If a page is on the other LRU than it should be, rmdir() will fail.
This bug was added in March 2011, but no bug report yet. I guess there are not many people who use memcg and FUSE at the same time with upstream kernels.
The result of this bug is that admin cannot destroy a memcg because of account leak. So, no panic, no deadlock. And, even if an active cgroup exist, umount can succseed. So no problem at shutdown.
--- include/linux/memcontrol.h | 6 ++++++ mm/filemap.c | 18 ++---------------- mm/memcontrol.c | 44 ++++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 52 insertions(+), 16 deletions(-)
include/linux/memcontrol.h +6 -0
@@ -116,6 +116,8 @@ struct zone_reclaim_stat* mem_cgroup_get_reclaim_stat_from_page(struct page *page);extern void mem_cgroup_print_oom_info (struct mem_cgroup *memcg,struct task_struct *p); +extern void mem_cgroup_replace_page_cache (struct page *oldpage, +struct page *newpage);#ifdef CONFIG_CGROUP_MEM_RES_CTLR_SWAP extern int do_swap_account;
@@ -361,6 +363,10 @@ static inlinevoid mem_cgroup_count_vm_event (struct mm_struct *mm,enum vm_event_item idx) { } +static inline void mem_cgroup_replace_page_cache (struct page *oldpage, +struct page *newpage) +{ +}#endif /* CONFIG_CGROUP_MEM_CONT */ #if !defined(CONFIG_CGROUP_MEM_RES_CTLR ) || !defined(CONFIG_DEBUG_VM )
mm/filemap.c +2 -16
@@ -393,24 +393,11 @@ EXPORT_SYMBOL(filemap_write_and_wait_ranint replace_page_cache_page (struct page *old,struct page *new,gfp_t gfp_mask) {int error; -struct mem_cgroup *memcg =NULL ;VM_BUG_ON (!PageLocked (old));VM_BUG_ON (!PageLocked (new));VM_BUG_ON (new->mapping); -/* -* This is not page migration, but prepare_migration and -* end_migration does enough work for charge replacement. -* -* In the longer term we probably want a specialized function -* for moving the charge from old to new in a more efficient -* manner. -*/ - error =mem_cgroup_prepare_migration (old, new, &memcg, gfp_mask); -if (error) -return error; - error =radix_tree_preload (gfp_mask & ~__GFP_HIGHMEM);if (!error) {struct address_space *mapping = old->mapping;
@@ -432,13 +419,12 @@ int replace_page_cache_page(struct pageif (PageSwapBacked (new))__inc_zone_page_state (new,NR_SHMEM );spin_unlock_irq (&mapping->tree_lock); +/* mem_cgroup codes must not be called under tree_lock */ +mem_cgroup_replace_page_cache (old, new);radix_tree_preload_end ();if (freepage)freepage (old);page_cache_release (old); -mem_cgroup_end_migration (memcg, old, new, true); - }else { -mem_cgroup_end_migration (memcg, old, new, false); }return error;
mm/memcontrol.c +44 -0
50 lines not on this page · raw message
PATCH 48/48 x86: Fix mmap random address range
In reply to Greg KH3.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ludwig Nussel <[email protected]>
commit 9af0c7a6fa860698d080481f24a342ba74b68982 upstream.
On x86_32 casting the unsigned int result of get_random_int() to long may result in a negative value. On x86_32 the range of mmap_rnd() therefore was -255 to 255. The 32bit mode on x86_64 used 0 to 255 as intended.
The bug was introduced by 675a081 ("x86: unify mmap_{32|64}.c") in January 2008.
--- arch/x86/mm/mmap.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
arch/x86/mm/mmap.c +2 -2
@@ -87,9 +87,9 @@ static unsigned long mmap_rnd(void)*/ if (current->flags &PF_RANDOMIZE ) {if (mmap_is_ia32 ()) - rnd = (long )get_random_int () % (1 <<8 ); + rnd =get_random_int () % (1 <<8 );else - rnd = (long )(get_random_int () % (1 <<28 )); + rnd =get_random_int () % (1 <<28 ); }return rnd <<PAGE_SHIFT ; }