- 01 Aug, 2008 29 commits
-
-
Andrew Morton authored
commit 0c65f459 upstream arm's fls() is implemented as a macro, causing it to misbehave when passed 64-bit arguments. Fix. Cc: Nickolay Vinogradov <nickolay@protei.ru> Tested-by:
Krzysztof Halasa <khc@pm.waw.pl> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Jan Beulich authored
commit fb5e2b37 upstream Due to the addition of __attribute__((__cold__)) to a few symbols without adjusting the linker scripts, those symbols currently may end up outside the [_stext,_etext) range, as they get placed in .text.unlikely by (at least) gcc 4.3.0. This may confuse code not only outside of the kernel, symbol_put_addr()'s BUG() could also trigger. Hence we need to add .text.unlikely (and for future uses of __attribute__((__hot__)) also .text.hot) to the TEXT_TEXT() macro. Issue observed by Lukas Lipavsky. Signed-off-by:
Jan Beulich <jbeulich@novell.com> Tested-by:
Lukas Lipavsky <llipavsky@suse.cz> Signed-off-by:
Sam Ravnborg <sam@ravnborg.org> Signed-off-by:
-
David Brownell authored
commit 449321b3 upstream This fixes kernel http://bugzilla.kernel.org/show_bug.cgi?id=11112 (bogus RTC update IRQs reported) for rtc-at91rm9200 by scrubbing old IRQ status before enabling IRQs. It also removes nonfunctional periodic IRQ support from this driver; only update IRQs are reported, or provided by the hardware. I suspect some other RTCs probably have versions of #11112; it's easy to overlook, since most non-RTC drivers don't care about spurious IRQs: they're not reported to userspace. Signed-off-by:
David Brownell <dbrownell@users.sourceforge.net> Report-by:
W Unruh <unruh@physics.ubc.ca> Cc: Andrew Victor <avictor.za@gmail.com> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Jens Axboe authored
commit e8e7b9eb upstream cdrom_read_capacity() will blindly return the capacity from the device without sanity-checking it. This later causes code in fs/buffer.c to oops. Fix this by checking that the device is telling us sensible things. From: Jens Axboe <jens.axboe@oracle.com> Cc: Michael Buesch <mb@bu3sch.de> Cc: Jan Kara <jack@suse.cz> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Borislav Petkov <petkovbb@googlemail.com> Signed-off-by:
Bartlomiej Zolnierkiewicz <bzolnier@gmail.com> [harvey: blocklen is a big-endian value] Signed-off-by:
Harvey Harrison <harvey.harrison@gmail.com> Signed-off-by:
-
Jan Kratochvil authored
commit d536b1f8 upstream currently if you use PTRACE_SINGLEBLOCK on AMD K6-3 (i586) it will crash. Kernel now wrongly assumes existing DEBUGCTLMSR MSR register there. Removed the assumption also for some other non-K6 CPUs but I am not sure there (but it can only bring small inefficiency there if my assumption is wrong). Based on info from Roland McGrath, Chuck Ebbert and Mikulas Patocka. More info at: https://bugzilla.redhat.com/show_bug.cgi?id=456175Signed-off-by:
Jan Kratochvil <jan.kratochvil@redhat.com> Signed-off-by:
Ingo Molnar <mingo@elte.hu> Signed-off-by:
-
Miao Xie authored
commit 91cd4d6e upstream Fix wrong domain attr updates, or we will always update the first sched domain attr. Signed-off-by:
Miao Xie <miaox@cn.fujitsu.com> Cc: Hidetoshi Seto <seto.hidetoshi@jp.fujitsu.com> Cc: Paul Jackson <pj@sgi.com> Cc: Nick Piggin <nickpiggin@yahoo.com.au> Cc: Ingo Molnar <mingo@elte.hu> Signed-off-by:
-
Alexey Dobriyan authored
commit ee1e6ab6 upstream struct pagemap_walk was placed on stack, some hooks are initialized, the rest (->pgd_entry, ->pud_entry, ->pte_entry) are valid but junk. Reported-by:
Eric Sesterhenn <snakebyte@gmx.de> Signed-off-by:
Alexey Dobriyan <adobriyan@gmail.com> Cc: "Vegard Nossum" <vegard.nossum@gmail.com> Signed-off-by:
-
Atsushi Nemoto authored
commit 5f17156f upstream Add missing cond_syscall() entry for compat_sys_epoll_pwait. Signed-off-by:
Atsushi Nemoto <anemo@mba.ocn.ne.jp> Cc: Davide Libenzi <davidel@xmailserver.org> Signed-off-by:
-
Mathieu Desnoyers authored
commit: d35cb360 When a kernel was rebuilt, the previous Module.markers was not cleared. It caused markers with different format strings to appear as duplicates when a markers was changed. This problem is present since scripts/mod/modpost.c started to generate Module.markers, commit b2e3e658 It therefore applies to 2.6.25, 2.6.26 and linux-next. I merely merged the patches from Roland, Wenji and Takashi here. Credits to Roland McGrath <roland@redhat.com> Wenji Huang <wenji.huang@oracle.com> and Takashi Nishiie <t-nishiie@np.css.fujitsu.com> for providing the individual fixes. - Changelog : - Integrated Takashi's Makefile modification to clear Module.markers upon make clean. Signed-off-by:
Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca> Cc: Roland McGrath <roland@redhat.com> Cc: Wenji Huang <wenji.huang@oracle.com> Cc: Takashi Nishiie <t-nishiie@np.css.fujitsu.com> Signed-off-by:
-
H. Peter Anvin authored
Commit 3bf2e774 upstream x86, suspend, acpi: enter Big Real Mode The explanation for recent video BIOS suspend quirk failures is that the VESA BIOS expects to be entered in Big Real Mode (*.limit = 0xffffffff) instead of ordinary Real Mode (*.limit = 0xffff). This patch changes the segment descriptors to Big Real Mode instead. The segment descriptor registers (what Intel calls "segment cache") is always active. The only thing that changes based on CR0.PE is how it is *loaded* and the interpretation of the CS flags. The segment descriptor registers contain of the following sub-registers: selector (the "visible" part), base, limit and flags. In protected mode or long mode, they are loaded from descriptors (or fs.base or gs.base can be manipulated directly in long mode.) In real mode, the only thing changed by a segment register load is the selector and the base, where the base <- selector << 4. In particular, *the limit and the flags are not changed*. As far as the handling of the CS flags: a code segment cannot be writable in protected mode, whereas it is "just another segment" in real mode, so there is some kind of quirk that kicks in for this when CR0.PE <- 0. I'm not sure if this is accomplished by actually changing the cs.flags register or just changing the interpretation; it might be something that is CPU-specific. In particular, the Transmeta CPUs had an explicit "CS is writable if you're in real mode" override, so even if you had loaded CS with an execute-only segment it'd be writable (but not readable!) on return to real mode. I'm not at all sure if that is how other CPUs behave. Signed-off-by:
"H. Peter Anvin" <hpa@zytor.com> Signed-off-by:
-
Oliver Neukum authored
commit 62ad296b upstream usb serial decrements the pm counter even if an interface has been disconnected. If it was a logical disconnect the interface may belong already to another driver. This patch introduces a check for disconnected interfaces. Signed-off-by:
Oliver Neukum <oneukum@suse.de> Signed-off-by:
-
Ingo Molnar authored
commit fab3b58d upstream as reported in: "reboot=bios is mandatory on Dell T5400 server." http://bugzilla.kernel.org/show_bug.cgi?id=11108 add a DMI reboot quirk. Signed-off-by:
-
Herton Ronaldo Krzesinski authored
commit 723edb50 upstream Fallout from commit 33185c50 ("x86: merge signal_32/64.h") Thanks to Dick Streefland who provided an useful testcase on http://lkml.org/lkml/2008/3/17/205 (only applicable to 2.6.24.x), that helped a lot as a deterministic way to bisect an issue that leaded to this fix. Signed-off-by:
Herton Ronaldo Krzesinski <herton@mandriva.com.br> Signed-off-by:
Luiz Fernando N. Capitulino <lcapitulino@mandriva.com.br> Cc: Roland McGrath <roland@redhat.com> Signed-off-by:
-
Paul E. McKenney authored
commit d7c06513 upstream The comment was correct -- need to make the code match the comment. Without this patch, if a CPU goes dynticks idle (and stays there forever) in just the right phase of preemptible-RCU grace-period processing, grace periods stall. The offending sequence of events (courtesy of Promela/spin, at least after I got the liveness criterion coded correctly...) is as follows: o CPU 0 is in dynticks-idle mode. Its dynticks_progress_counter is (say) 10. o CPU 0 takes an interrupt, so rcu_irq_enter() increments CPU 0's dynticks_progress_counter to 11. o CPU 1 is doing RCU grace-period processing in rcu_try_flip_idle(), sees rcu_pending(), so invokes dyntick_save_progress_counter(), which in turn takes a snapshot of CPU 0's dynticks_progress_counter into CPU 0's rcu_dyntick_snapshot -- now set to 11. CPU 1 then updates the RCU grace-period state to rcu_try_flip_waitack(). o CPU 0 returns from its interrupt, so rcu_irq_exit() increments CPU 0's dynticks_progress_counter to 12. o CPU 1 later invokes rcu_try_flip_waitack(), which notices that CPU 0 has not yet responded, and hence in turn invokes rcu_try_flip_waitack_needed(). This function examines the state of CPU 0's dynticks_progress_counter and rcu_dyntick_snapshot variables, which it copies to curr (== 12) and snap (== 11), respectively. Because curr!=snap, the first condition fails. Because curr-snap is only 1 and snap is odd, the second condition fails. rcu_try_flip_waitack_needed() therefore incorrectly concludes that it must wait for CPU 0 to explicitly acknowledge the counter flip. o CPU 0 remains forever in dynticks-idle mode, never taking any more hardware interrupts or any NMIs, and never running any more tasks. (Of course, -something- will usually eventually happen, which might be why we haven't seen this one in the wild. Still should be fixed!) Therefore the grace period never ends. Fix is to make the code match the comment, as shown below. With this fix, the above scenario would be satisfied with curr being even, and allow the grace period to proceed. Signed-off-by:
Paul E. McKenney <paulmck@linux.vnet.ibm.com> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Cc: Josh Triplett <josh@kernel.org> Cc: Dipankar Sarma <dipankar@in.ibm.com> Signed-off-by:
-
Roland McGrath authored
commit 45fdc3a7 upstream ptrace has always returned only -EIO for all failures to access registers. The user_regset calls are allowed to return a more meaningful variety of errors. The REGSET_XFP calls use -ENODEV for !cpu_has_fxsr hardware. Make ptrace return the traditional -EIO instead of the error code from the user_regset call. Signed-off-by:
Roland McGrath <roland@redhat.com> Signed-off-by:
-
Avi Kivity authored
Original-Commit-Hash: c23a6fe17abf8562e675465f8d55ba1a551d314d The direct mapped shadow code (used for real mode and two dimensional paging) sets upper-level ptes using direct assignment rather than calling set_shadow_pte(). A nonpae host will split this into two writes, which opens up a race if another vcpu accesses the same memory area. Fix by calling set_shadow_pte() instead of assigning directly. Noticed by Izik Eidus. Signed-off-by:
Avi Kivity <avi@qumranet.com> Signed-off-by:
-
Marcelo Tosatti authored
Original-Commit-Hash: 3cc312f03e06a8fa39ecb4cc0189efc2bd888899 Flush the shadow mmu before removing regions to avoid stale entries. Signed-off-by:
Marcelo Tosatti <mtosatti@redhat.com> Signed-off-by:
-
Mohammed Gamal authored
Original-Commit-Hash: bcc542267538e9ba933d08b4cd4ebd796e03a3d7 This patch fixes issue encountered with HLT instruction under FreeDOS's HIMEM XMS Driver. The HLT instruction jumped directly to the done label and skips updating the EIP value, therefore causing the guest to spin endlessly on the same instruction. The patch changes the instruction so that it writes back the updated EIP value. Signed-off-by:
Mohammed Gamal <m.gamal005@gmail.com> Signed-off-by:
-
Sheng Yang authored
Original-Commit-Hash: 73f785350b92e1a3af945340f7d10f3978193cba Fix a potention issue caused by kvm_mmu_slot_remove_write_access(). The old behavior don't sync EPT TLB with modified EPT entry, which result in inconsistent content of EPT TLB and EPT table. Signed-off-by:
Sheng Yang <sheng.yang@intel.com> Signed-off-by:
-
Marcelo Tosatti authored
Original-Commit-Hash: 64f6a0c041bd8fc100a0d655058bdbc31feda03c kvm_mmu_zap_page() needs slots lock held (rmap_remove->gfn_to_memslot, for example). Since kvm_lock spinlock is held in mmu_shrink(), do a non-blocking down_read_trylock(). Untested. Signed-off-by:
-
Joerg Roedel authored
Original-Commit-Hash: ab6267b708bec563891294488f2e854be404bdaf On suspend the svm_hardware_disable function is called which frees all svm_data variables. On resume they are not re-allocated. This patch removes the deallocation of svm_data from the hardware_disable function to the hardware_unsetup function which is not called on suspend. Signed-off-by:
Joerg Roedel <joerg.roedel@amd.com> Signed-off-by:
-
Sheng Yang authored
Original-Commit-Hash: 406046a9638a455876b030853862e576a4378d29 The function ept_update_paging_mode_cr0() write to CPU_BASED_VM_EXEC_CONTROL based on vmcs_config.cpu_based_exec_ctrl. That's wrong because the variable may not consistent with the content in the CPU_BASE_VM_EXEC_CONTROL MSR. Signed-off-by:
-
Adam Greenblatt authored
commit c0a1633b upstream Some iso9660 images contain files with rockridge data that is either incorrect or incompletely parsed. Prior to commit f2966632 ("[PATCH] rock: handle directory overflows") (included with kernel 2.6.13) the kernel ignored the rockridge data for these files, while still allowing the files to be accessed under their non-rockridge names. That commit inadvertently changed things so that files with invalid rockridge data could not be accessed at all. (I ran across the problem when comparing some old CDs with hard disk copies I had made long ago under kernel 2.4: a few of the files on the hard disk copies were no longer visible on the CDs.) This change reverts to the pre-2.6.13 behavior. Signed-off-by:
Adam Greenblatt <adam.greenblatt@gmail.com> Reviewed-by:
Pekka Enberg <penberg@cs.helsinki.fi> Signed-off-by:
-
Jan Kara authored
commit b48d3805 upstream When quota structure is going to be dropped and it is dirty, quota code tries to write it. If the write fails for some reason (e. g. transaction cannot be started because the journal is aborted), we try writing again and again and again... Fix the problem by clearing the dirty bit even if the write failed. (akpm: for 2.6.27, 2.6.26.x and 2.6.25.x) Signed-off-by:
Jan Kara <jack@suse.cz> Reviewed-by:
dingdinghua <dingdinghua85@gmail.com> Signed-off-by:
-
Micah Dowty authored
[ Upstream commit ae6134bd ] This is a trivial patch against the hdlcdrv module that fixes its CRC calculation. The finished CRC was overwriting the first two bytes of each packet rather than being appended to the end. I've tested this with 2.6.8 and 2.6.10-rc1, but hdlcdrv hasn't changed much recently so it should work with many other kernel versions. Signed-off-by:
Micah Dowty <micah@navi.cx> Acked-by:
Thomas Sailer <t.sailer@alumni.ethz.ch> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
David S. Miller authored
[ Upstream commit ebb36a97 ] Based upon a report by Olaf Hering. Signed-off-by:
-
Stephen Hemminger authored
[ Upstream commit 847499ce ] This fixes the bridge reference count problem and cleanups ipv6 FIB timer management. Don't use expires field, because it is not a proper way to test, instead use timer_pending(). Signed-off-by:
Stephen Hemminger <shemminger@vyatta.com> Signed-off-by:
-
Gerrit Renker authored
[ Upstream commit 47112e25 ] This patch clamps the cscov setsockopt values to a maximum of 0xFFFF. Setsockopt values greater than 0xffff can cause an unwanted wrap-around. Further, IPv6 jumbograms are not supported (RFC 3838, 3.5), so that values greater than 0xffff are not even useful. Further changes: fixed a typo in the documentation. Signed-off-by:
Gerrit Renker <gerrit@erg.abdn.ac.uk> Signed-off-by:
-
Karl Beldan authored
commit 4fe16897 upstream Signed-off-by:
Karl Beldan <karl.beldan@gmail.com> Acked-by:
Eric Miao <eric.miao@marvell.com> Signed-off-by:
Pierre Ossman <drzeus@drzeus.cx> Signed-off-by:
-
- 13 Jul, 2008 6 commits
-
-
Linus Torvalds authored
-
Li Zefan authored
# cat devices.list c 1:3 r # echo 'c 1:3 w' > sub/devices.allow # cat sub/devices.list c 1:3 w As illustrated, the parent group has no write permission to /dev/null, so it's child should not be allowed to add this write permission. Signed-off-by:
Li Zefan <lizf@cn.fujitsu.com> Acked-by:
Serge Hallyn <serue@us.ibm.com> Cc: Serge Hallyn <serue@us.ibm.com> Cc: Paul Menage <menage@google.com> Cc: Pavel Emelyanov <xemul@openvz.org> Signed-off-by:
-
Li Zefan authored
# echo "b $((0x7fffffff)):$((0x80000000)) rwm" > devices.allow # cat devices.list b 214748364:-21474836 rwm though a major/minor number of 0x800000000 is meaningless, we should not cast it to a negative value. Signed-off-by:
-
Jiri Pirko authored
Signed-off-by:
Jiri Pirko <jpirko@redhat.com> Cc: Randy Dunlap <randy.dunlap@oracle.com> Signed-off-by:
-
Linus Torvalds authored
Merge branch 'sched-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip * 'sched-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip: cpusets, hotplug, scheduler: fix scheduler domain breakage
-
Dmitry Adamushko authored
Commit f18f982a ("sched: CPU hotplug events must not destroy scheduler domains created by the cpusets") introduced a hotplug-related problem as described below: Upon CPU_DOWN_PREPARE, update_sched_domains() -> detach_destroy_domains(&cpu_online_map) does the following: /* * Force a reinitialization of the sched domains hierarchy. The domains * and groups cannot be updated in place without racing with the balancing * code, so we temporarily attach all running cpus to the NULL domain * which will prevent rebalancing while the sched domains are recalculated. */ The sched-domains should be rebuilt when a CPU_DOWN ops. has been completed, effectively either upon CPU_DEAD{_FROZEN} (upon success) or CPU_DOWN_FAILED{_FROZEN} (upon failure -- restore the things to their initial state). That's what update_sched_domains() also does but only for !CPUSETS case. With f18f982a, sched-domains' reinitialization is delegated to CPUSETS code: cpuset_handle_cpuhp() -> common_cpu_mem_hotplug_unplug() -> rebuild_sched_domains() Being called for CPU_UP_PREPARE and if its callback is called after update_sched_domains()), it just negates all the work done by update_sched_domains() -- i.e. a soon-to-be-offline cpu is included in the sched-domains and that makes it visible for the load-balancer while the CPU_DOWN ops. is in progress. __migrate_live_tasks() moves the tasks off a 'dead' cpu (it's already "offline" when this function is called). try_to_wake_up() is called for one of these tasks from another CPU -> the load-balancer (wake_idle()) picks up a "dead" CPU and places the task on it. Then e.g. BUG_ON(rq->nr_running) detects this a bit later -> oops. Signed-off-by:
Dmitry Adamushko <dmitry.adamushko@gmail.com> Tested-by:
Vegard Nossum <vegard.nossum@gmail.com> Cc: Paul Menage <menage@google.com> Cc: Max Krasnyansky <maxk@qualcomm.com> Cc: Paul Jackson <pj@sgi.com> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Cc: miaox@cn.fujitsu.com Cc: rostedt@goodmis.org Cc: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
- 12 Jul, 2008 5 commits
-
-
Linus Torvalds authored
Merge branch 'x86-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip * 'x86-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip: x86: fix ldt limit for 64 bit
-
git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi-rc-fixes-2.6Linus Torvalds authored
* git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi-rc-fixes-2.6: [SCSI] bsg: fix oops on remove [SCSI] fusion: default MSI to disabled for SPI and FC controllers [SCSI] ipr: Fix HDIO_GET_IDENTITY oops for SATA devices [SCSI] mptspi: fix oops in mptspi_dv_renegotiate_work() [SCSI] erase invalid data returned by device
-
Jeff Layton authored
The current definition of wksidarr works fine on little endian arches (since cpu_to_le32 is a no-op there), but on big-endian arches, it fails to compile with this error: error: braced-group within expression allowed only inside a function The problem is that this static declaration has cpu_to_le32 embedded within it, and that expands into a function macro. We need to use __constant_cpu_to_le32() instead. Signed-off-by:
Jeff Layton <jlayton@redhat.com> Cc: Steven French <sfrench@us.ibm.com> Cc: <stable@kernel.org> Signed-off-by:
-
Jeff Layton authored
Try this: mount a share with unix extensions create a file on it umount the share You'll get the following message in the ring buffer: VFS: Busy inodes after unmount of cifs. Self-destruct in 5 seconds. Have a nice day... ...the problem is that cifs_get_inode_info_unix is creating and hashing a new inode even when it's going to return error anyway. The first lookup when creating a file returns an error so we end up leaking this inode before we do the actual create. This appears to be a regression caused by commit 0e4bbde9. The following patch seems to fix it for me, and fixes a minor formatting nit as well. Signed-off-by:Steven French <sfrench@us.ibm.com> Signed-off-by:
-
David Howells authored
Fix FRV irqs_disabled() to return an int, not an unsigned long to avoid this warning: kernel/sched.c: In function '__might_sleep': kernel/sched.c:8198: warning: format '%d' expects type 'int', but argument 3 has type 'long unsigned int' Signed-off-by:
David Howells <dhowells@redhat.com> Signed-off-by:
-
