user/sven/linux.git, branch v3.2-rc3

Linux 3.2-rc3

2011-11-24T04:20:28Z

Merge git://github.com/rustyrussell/linux

2011-11-24T04:19:31Z

* git://github.com/rustyrussell/linux: virtio-pci: make reset operation safer virtio-mmio: Correct the name of the guest features selector virtio: add HAS_IOMEM dependency to MMIO platform bus driver

virtio-pci: make reset operation safer

2011-11-24T02:34:48Z

virtio pci device reset actually just does an I/O write, which in PCI is really posted, that is it can complete on CPU before the device has received it. Further, interrupts might have been pending on another CPU, so device callback might get invoked after reset. This conflicts with how drivers use reset, which is typically: reset unregister a callback running after reset completed can race with unregister, potentially leading to use after free bugs. Fix by flushing out the write, and flushing pending interrupts. This assumes that device is never reset from its vq/config callbacks, or in parallel with being added/removed, document this assumption. Signed-off-by: Michael S. Tsirkin Signed-off-by: Rusty Russell

virtio-mmio: Correct the name of the guest features selector

2011-11-24T02:34:47Z

Guest features selector spelling mistake. Cc: Pawel Moll Cc: Rusty Russell Cc: virtualization@lists.linux-foundation.org Signed-off-by: Sasha Levin Signed-off-by: Rusty Russell

virtio: add HAS_IOMEM dependency to MMIO platform bus driver

2011-11-24T02:34:47Z

Fix this compile error on s390: CC [M] drivers/virtio/virtio_mmio.o drivers/virtio/virtio_mmio.c: In function 'vm_get_features': drivers/virtio/virtio_mmio.c:107:2: error: implicit declaration of function 'writel' Cc: Christian Borntraeger Signed-off-by: Heiko Carstens Acked-by: Pawel Moll Signed-off-by: Rusty Russell

Merge branch 'upstream-linus' of git://github.com/jgarzik/libata-dev

2011-11-24T01:26:22Z

* 'upstream-linus' of git://github.com/jgarzik/libata-dev: libata: fix build without BMDMA [libata] ahci_platform: fix DT probing

Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jbarnes/pci

2011-11-23T22:58:46Z

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jbarnes/pci: PCI hotplug: shpchp: don't blindly claim non-AMD 0x7450 device IDs PCI: pciehp: wait 100 ms after Link Training check PCI: pciehp: wait 1000 ms before Link Training check PCI: pciehp: Retrieve link speed after link is trained PCI: Let PCI_PRI depend on PCI PCI: Fix compile errors with PCI_ATS and !PCI_IOV PCI / ACPI: Make acpiphp ignore root bridges using PCIe native hotplug

Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tyhicks/ecryptfs

2011-11-23T22:28:13Z

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tyhicks/ecryptfs: eCryptfs: Extend array bounds for all filename chars eCryptfs: Flush file in vma close eCryptfs: Prevent file create race condition

eCryptfs: Extend array bounds for all filename chars

2011-11-23T21:43:53Z

From mhalcrow's original commit message: Characters with ASCII values greater than the size of filename_rev_map[] are valid filename characters. ecryptfs_decode_from_filename() will access kernel memory beyond that array, and ecryptfs_parse_tag_70_packet() will then decrypt those characters. The attacker, using the FNEK of the crafted file, can then re-encrypt the characters to reveal the kernel memory past the end of the filename_rev_map[] array. I expect low security impact since this array is statically allocated in the text area, and the amount of memory past the array that is accessible is limited by the largest possible ASCII filename character. This patch solves the issue reported by mhalcrow but with an implementation suggested by Linus to simply extend the length of filename_rev_map[] to 256. Characters greater than 0x7A are mapped to 0x00, which is how invalid characters less than 0x7A were previously being handled. Signed-off-by: Tyler Hicks Reported-by: Michael Halcrow Cc: stable@kernel.org

eCryptfs: Flush file in vma close

2011-11-23T21:40:09Z

Dirty pages weren't being written back when an mmap'ed eCryptfs file was closed before the mapping was unmapped. Since f_ops->flush() is not called by the munmap() path, the lower file was simply being released. This patch flushes the eCryptfs file in the vm_ops->close() path. https://launchpad.net/bugs/870326 Signed-off-by: Tyler Hicks Cc: stable@kernel.org [2.6.39+]