arch/x86/ia32/ia32entry.S | 14 +++---- debian/changelog | 57 ++++++++++++++++++++++++++++++ drivers/ssb/driver_chipcommon_pmu.c | 17 +++++--- drivers/ssb/pci.c | 20 ++-------- drivers/staging/hv/RingBuffer.c | 2 - drivers/staging/hv/StorVscApi.h | 4 +- drivers/staging/hv/storvsc_drv.c | 9 +++- fs/proc/task_mmu.c | 8 +++- include/linux/ssb/ssb.h | 5 ++ include/linux/ssb/ssb_driver_chipcommon.h | 15 +++++++ mm/memory.c | 32 ++++++++++++++-- mm/mlock.c | 8 ++++ 12 files changed, 148 insertions(+), 43 deletions(-)
New commits: commit 2698db1bbfde8339a6aa273433ff70514a76a572 Author: Stephen Hemminger <[email protected]> Date: Tue Sep 21 14:47:41 2010 -0700 2.6.32-1+vyatta+42+larkspur10 commit 0a2eb56246f71409dd92f73b599151701b9f1c4e Author: Stephen Hemminger <[email protected]> Date: Tue Sep 21 14:47:20 2010 -0700 2.6.32-1+vyatta+42+larkspur9 commit 5a806306bb15b7016ca605d91eb8f4e82f1d35ac Author: H. Peter Anvin <[email protected]> Date: Tue Sep 14 12:42:41 2010 -0700 x86-64, compat: Test %rax for the syscall number, not %eax commit 36d001c70d8a0144ac1d038f6876c484849a74de upstream. On 64 bits, we always, by necessity, jump through the system call table via %rax. For 32-bit system calls, in theory the system call number is stored in %eax, and the code was testing %eax for a valid system call number. At one point we loaded the stored value back from the stack to enforce zero-extension, but that was removed in checkin d4d67150165df8bf1cc05e532f6efca96f907cab. An actual 32-bit process will not be able to introduce a non-zero-extended number, but it can happen via ptrace. Instead of re-introducing the zero-extension, test what we are actually going to use, i.e. %rax. This only adds a handful of REX prefixes to the code. Reported-by: Ben Hawkes <[email protected]> Signed-off-by: H. Peter Anvin <[email protected]> Cc: Roland McGrath <[email protected]> Cc: Andrew Morton <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 9500a5139c5f2d9bdc7375c4d7786e1a38b0091b Author: Linus Torvalds <[email protected]> Date: Sun Aug 15 11:35:52 2010 -0700 mm: fix up some user-visible effects of the stack guard page commit d7824370e26325c881b665350ce64fb0a4fde24a upstream. This commit makes the stack guard page somewhat less visible to user space. It does this by: - not showing the guard page in /proc/<pid>/maps It looks like lvm-tools will actually read /proc/self/maps to figure out where all its mappings are, and effectively do a specialized "mlockall()" in user space. By not showing the guard page as part of the mapping (by just adding PAGE_SIZE to the start for grows-up pages), lvm-tools ends up not being aware of it. - by also teaching the _real_ mlock() functionality not to try to lock the guard page. That would just expand the mapping down to create a new guard page, so there really is no point in trying to lock it in place. It would perhaps be nice to show the guard page specially in /proc/<pid>/maps (or at least mark grow-down segments some way), but let's not open ourselves up to more breakage by user space from programs that depends on the exact deails of the 'maps' file. Special thanks to Henrique de Moraes Holschuh for diving into lvm-tools source code to see what was going on with the whole new warning. Reported-and-tested-by: François Valenduc <[email protected] Reported-by: Henrique de Moraes Holschuh <[email protected]> Signed-off-by: Linus Torvalds <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 3deaced4df09feb19eb72aac0c3f95e15bc16a78 Author: Linus Torvalds <[email protected]> Date: Sat Aug 14 11:44:56 2010 -0700 mm: fix page table unmap for stack guard page properly commit 11ac552477e32835cb6970bf0a70c210807f5673 upstream. We do in fact need to unmap the page table _before_ doing the whole stack guard page logic, because if it is needed (mainly 32-bit x86 with PAE and CONFIG_HIGHPTE, but other architectures may use it too) then it will do a kmap_atomic/kunmap_atomic. And those kmaps will create an atomic region that we cannot do allocations in. However, the whole stack expand code will need to do anon_vma_prepare() and vma_lock_anon_vma() and they cannot do that in an atomic region. Now, a better model might actually be to do the anon_vma_prepare() when _creating_ a VM_GROWSDOWN segment, and not have to worry about any of this at page fault time. But in the meantime, this is the straightforward fix for the issue. See https://bugzilla.kernel.org/show_bug.cgi?id588 for details. Reported-by: Wylda <[email protected]> Reported-by: Sedat Dilek <[email protected]> Reported-by: Mike Pagano <[email protected]> Reported-by: François Valenduc <[email protected]> Tested-by: Ed Tomlinson <[email protected]> Cc: Pekka Enberg <[email protected]> Signed-off-by: Linus Torvalds <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit ffc4ff6b8487aea1884564f2895345346024fabe Author: Linus Torvalds <[email protected]> Date: Fri Aug 13 09:24:04 2010 -0700 mm: fix missing page table unmap for stack guard page failure case commit 5528f9132cf65d4d892bcbc5684c61e7822b21e9 upstream. .. which didn't show up in my tests because it's a no-op on x86-64 and most other architectures. But we enter the function with the last-level page table mapped, and should unmap it at exit. Signed-off-by: Linus Torvalds <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit de1e6094b5c738081654b07249082256a3b2df4f Author: Linus Torvalds <[email protected]> Date: Thu Aug 12 17:54:33 2010 -0700 mm: keep a guard page below a grow-down stack segment commit 320b2b8de12698082609ebbc1a17165727f4c893 upstream. This is a rather minimally invasive patch to solve the problem of the user stack growing into a memory mapped area below it. Whenever we fill the first page of the stack segment, expand the segment down by one page. Now, admittedly some odd application might _want_ the stack to grow down into the preceding memory mapping, and so we may at some point need to make this a process tunable (some people might also want to have more than a single page of guarding), but let's try the minimal approach first. Tested with trivial application that maps a single page just below the stack, and then starts recursing. Without this, we will get a SIGSEGV _after_ the stack has smashed the mapping. With this patch, we'll get a nice SIGBUS just as the stack touches the page just above the mapping. Requested-by: Keith Packard <[email protected]> Signed-off-by: Linus Torvalds <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 2bc7a196cb39737fe940149cadc8a2e791adbbd4 Author: Stephen Hemminger <[email protected]> Date: Tue Sep 21 14:40:41 2010 -0700 2.6.32-1+vyatta+42+larkspur8 commit 055919737f7d527d320ce68782630430db1a360b Author: Larry Finger <[email protected]> Date: Fri May 14 22:08:58 2010 -0500 ssb: Handle alternate SSPROM location commit 9d1ac34ec3a67713308ae0883c3359c557f14d17 upstream. In kernel Bugzilla #15825 (2 users), in a wireless mailing list thread (http://lists.infradead.org/pipermail/b43-dev/2010-May/000124.html), and on a netbook owned by John Linville (http://marc.info/?l=linux-wireless&m7230751408818&w=4), there are reports of ssb failing to detect an SPROM at the normal location. After studying the MMIO trace dump for the Broadcom wl driver, it was determined that the affected boxes had a relocated SPROM. This patch fixes all systems that have reported this problem. Signed-off-by: Larry Finger <[email protected]> Signed-off-by: John W. Linville <[email protected]> Cc: Ben Hutchings <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 124f8327e48fb080723c46058f161d65510de8f5 Author: Christoph Fritz <[email protected]> Date: Fri May 28 10:45:59 2010 +0200 ssb: fix NULL ptr deref when pcihost_wrapper is used commit da1fdb02d9200ff28b6f3a380d21930335fe5429 upstream. Ethernet driver b44 does register ssb by it's pcihost_wrapper and doesn't set ssb_chipcommon. A check on this value introduced with commit d53cdbb94a52a920d5420ed64d986c3523a56743 and ea2db495f92ad2cf3301623e60cb95b4062bc484 triggers: BUG: unable to handle kernel NULL pointer dereference at 00000010 IP: [<c1266c36>] ssb_is_sprom_available+0x16/0x30 Signed-off-by: Christoph Fritz <[email protected]> Signed-off-by: John W. Linville <[email protected]> Cc: Larry Finger <[email protected]> Cc: Ben Hutchings <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 3a1c8359eab94936f6a376306881c5c4159c9e49 Author: RafaÅ MiÅecki <[email protected]> Date: Wed Mar 31 21:59:21 2010 +0200 ssb: Look for SPROM at different offset on higher rev CC commit ea2db495f92ad2cf3301623e60cb95b4062bc484 upstream. Our offset handling becomes even a little more hackish now. For some reason I do not understand all offsets as inrelative. It assumes base offset is 0x1000 but it will work for now as we make offsets relative anyway by removing base 0x1000. Should be cleaner however. Signed-off-by: RafaÅ MiÅecki <[email protected]> Signed-off-by: John W. Linville <[email protected]> Cc: Larry Finger <[email protected]> Cc: Ben Hutchings <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 0a8ae3f5b651109b3065b9d247cb1357ba230390 Author: John W. Linville <[email protected]> Date: Wed Mar 31 21:39:35 2010 +0200 ssb: do not read SPROM if it does not exist commit d53cdbb94a52a920d5420ed64d986c3523a56743 upstream. Attempting to read registers that don't exist on the SSB bus can cause hangs on some boxes. At least some b43 devices are 'in the wild' that don't have SPROMs at all. When the SSB bus support loads, it attempts to read these (non-existant) SPROMs and causes hard hangs on the box -- no console output, etc. This patch adds some intelligence to determine whether or not the SPROM is present before attempting to read it. This avoids those hard hangs on those devices with no SPROM attached to their SSB bus. The SSB-attached devices (e.g. b43, et al.) won't work, but at least the box will survive to test further patches. :-) Signed-off-by: John W. Linville <[email protected]> Signed-off-by: RafaÅ MiÅecki <[email protected]> Cc: Larry Finger <[email protected]> Cc: Michael Buesch <[email protected]> Cc: Ben Hutchings <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit ac806dae8a3cad34087455d69d6c3d294910cfcb Author: Greg Kroah-Hartman <[email protected]> Date: Fri Aug 6 10:22:56 2010 -0700 Revert "ssb: Handle Netbook devices where the SPROM address is changed" Turns out this isn't the best way to resolve this issue. The individual patches will be applied instead. Cc: Larry Finger <[email protected]> Cc: Ben Hutchings <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 50493ccd447f6f58d902f96c5eee3ae55b9078b1 Author: Stephen Hemminger <[email protected]> Date: Tue Sep 21 14:36:55 2010 -0700 2.6.32-1+vyatta+42+larkspur7 commit 011204ca5bca9559a54c25c73000efe421629e4f Author: Hank Janssen <[email protected]> Date: Wed Sep 1 11:10:41 2010 -0700 staging: hv: Fixed lockup problem with bounce_buffer scatter list commit 77c5ceaff31645ea049c6706b99e699eae81fb88 upstream. Fixed lockup problem with bounce_buffer scatter list which caused crashes in heavy loads. And minor code indentation cleanup in effected area. Removed whitespace and noted minor indentation changes in description as pointed out by Joe Perches. (Thanks for reviewing Joe) Signed-off-by: Hank Janssen <[email protected]> Signed-off-by: Haiyang Zhang <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> (cherry picked from commit f60f79f09b780ba847f5ff78b0c86c740bd07d99) commit 797b9a7f9e42e14f5f12653ccee79f818ee508de Author: Hank Janssen <[email protected]> Date: Thu Aug 5 19:30:31 2010 +0000 staging: hv: Increased storvsc ringbuffer and max_io_requests commit 15dd1c9f53b31cdc84b8072a88c23fa09527c596 upstream. Increased storvsc ringbuffer and max_io_requests. This now more closely mimics the numbers on Hyper-V. And will allow more IO requests to take place for the SCSI driver. Max_IO is set to double from what it was before, Hyper-V allows it and we have had appliance builder requests to see if it was a problem to increase the number. Ringbuffer size for storvsc is now increased because I have seen A few buffer problems on extremely busy systems. They were Set pretty low before. And since max_io_requests is increased I Really needed to increase the buffer as well. Signed-off-by: Hank Janssen <[email protected]> Signed-off-by: Haiyang Zhang <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> (cherry picked from commit 69e313042c71209ee0ace4b01b3099694ea1d7db) commit f945b27181f043132d2a00aae4e3f3d1fdb7bd9b Author: Haiyang Zhang <[email protected]> Date: Thu Aug 5 19:30:01 2010 +0000 staging: hv: Fixed the value of the 64bit-hole inside ring buffer commit e5fa721d1c2a54261a37eb59686e18dee34b6af6 upstream. Fixed the value of the 64bit-hole inside ring buffer, this caused a problem on Hyper-V when running checked Windows builds. Checked builds of Windows are used internally and given to external system integrators at times. They are builds that for example that all elements in a structure follow the definition of that Structure. The bug this fixed was for a field that we did not fill in at all (Because we do Not use it on the Linux side), and the checked build of windows gives errors on it internally to the Windows logs. This fixes that error. Signed-off-by: Hank Janssen <[email protected]> Signed-off-by: Haiyang Zhang <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> (cherry picked from commit 323f2e45fb38694cd000f7227651af9a2d4c78c8) commit 7cf550877961f6e60740e530c562da0f610c47b0 Author: Hank Janssen <[email protected]> Date: Thu Aug 5 19:29:44 2010 +0000 staging: hv: Fixed bounce kmap problem by using correct index commit 0c47a70a9a8a6d1ec37a53d2f9cb82f8b8ef8aa2 upstream. Fixed bounce offset kmap problem by using correct index. The symptom of the problem is that in some NAS appliances this problem represents Itself by a unresponsive VM under a load with many clients writing small files. Signed-off-by:Hank Janssen <[email protected]> Signed-off-by:Haiyang Zhang <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> (cherry picked from commit 8eccb26da55a81c0bf0b84dacfb7847755203bab) http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;h&98db1bbfde8339a6aa273433ff70514a76a572 http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;h 2eb56246f71409dd92f73b599151701b9f1c4e http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;hZ806306bb15b7016ca605d91eb8f4e82f1d35ac http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;h00a5139c5f2d9bdc7375c4d7786e1a38b0091b http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;h=eaced4df09feb19eb72aac0c3f95e15bc16a78 http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;hÿc4ff6b8487aea1884564f2895345346024fabe http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;hÞ1e6094b5c738081654b07249082256a3b2df4f http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;h+c7a196cb39737fe940149cadc8a2e791adbbd4 http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;h5919737f7d527d320ce68782630430db1a360b http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;h4f8327e48fb080723c46058f161d65510de8f5 http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;h:1c8359eab94936f6a376306881c5c4159c9e49 http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;h 8ae3f5b651109b3065b9d247cb1357ba230390 http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;h¬806dae8a3cad34087455d69d6c3d294910cfcb http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;hP493ccd447f6f58d902f96c5eee3ae55b9078b1 http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;h1204ca5bca9559a54c25c73000efe421629e4f http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;hy7b9a7f9e42e14f5f12653ccee79f818ee508de http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;hù45b27181f043132d2a00aae4e3f3d1fdb7bd9b http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;h|f550877961f6e60740e530c562da0f610c47b0
_______________________________________________ svn mailing list [email protected] http://mailman.vyatta.com/mailman/listinfo/svn
