- 01 Aug, 2008 19 commits
-
-
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:
Greg Kroah-Hartman <gregkh@suse.de>
-
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:
Ingo Molnar <mingo@elte.hu> 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:
Andrew Morton <akpm@linux-foundation.org> 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:
Linus Torvalds <torvalds@linux-foundation.org> 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 15 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:
-
Robert Richter authored
Cc: Philippe Elie <phil.el@wanadoo.fr> Cc: John Levon <levon@movementarian.org> Cc: Maynard Johnson <maynardj@us.ibm.com> Cc: Richard Purdie <rpurdie@openedhand.com> Cc: Daniel Hansel <daniel.hansel@linux.vnet.ibm.com> Cc: Jason Yeh <jason.yeh@amd.com> Cc: Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Robert Richter <robert.richter@amd.com> Signed-off-by:
-
Jon Smirl authored
Add the rtc8564 chip entry Signed-off-by:
Jon Smirl <jonsmirl@gmail.com> Signed-off-by:
Alessandro Zummo <a.zummo@towertech.it> Cc: David Brownell <david-b@pacbell.net> Signed-off-by:
-
Alessandro Zummo authored
Fix chip naming from fm3031-rtc to fm3031 Signed-off-by:
-
Andres Salomon authored
Cortland Setlow pointed out a bug in ov7670.c where the result from ov7670_read() was just being checked for !0, rather than <0. This made me realize that ov7670_read's semantics were rather confusing; it both fills in 'value' with the result, and returns it. This is goes against general kernel convention; so rather than fixing callers, let's fix the function. This makes ov7670_read return <0 in the case of an error, and 0 upon success. Thus, code like: res = ov7670_read(...); if (!res) goto error; ..will work properly. Signed-off-by:
Cortland Setlow <csetlow@tower-research.com> Signed-off-by:
Andres Salomon <dilinger@debian.org> Acked-by:
Jonathan Corbet <corbet@lwn.net> Cc: <stable@kernel.org> Signed-off-by:
-
Eric W. Biederman authored
I had 8250.nr_uarts=16 in the boot line of a test kernel and I had a weird mysterious crash in sysfs. After taking an in-depth look I realized that CONFIG_SERIAL_8250_NR_UARTS was set to 4 and I was walking off the end of the serial8250_ports array. Ouch!!! Don't let this happen to someone else. Signed-off-by:
Eric W. Biederman <ebiederm@xmission.com> Acked-by:
Alan Cox <alan@redhat.com> Cc: <stable@kernel.org> Signed-off-by:
-
Jaya Kumar authored
This patch is a bugfix for how defio handles multiple processes manipulating the same framebuffer. Thanks to Bernard Blackham for identifying this bug. It occurs when two applications mmap the same framebuffer and concurrently write to the same page. Normally, this doesn't occur since only a single process mmaps the framebuffer. The symptom of the bug is that the mapping applications will hang. The cause is that defio incorrectly tries to add the same page twice to the pagelist. The solution I have is to walk the pagelist and check for a duplicate before adding. Since I needed to walk the pagelist, I now also keep the pagelist in sorted order. Signed-off-by:
Jaya Kumar <jayakumar.lkml@gmail.com> Cc: Bernard Blackham <bernard@largestprime.net> Cc: <stable@kernel.org> Signed-off-by:
-
Darren Jenkins authored
Coverity CID: 1356 RESOURCE_LEAK I found a very old patch for this that was Acked but did not get applied https://lists.linux-foundation.org/pipermail/kernel-janitors/2006-September/016362.html There looks to be a small leak in isdn_writebuf_stub() in isdn_common.c, when copy_from_user() returns an un-copied data length (length != 0). The below patch should be a minimally invasive fix. Signed-off-by:
Darren Jenkins <darrenrjenkins@gmailcom> Acked-by:
Karsten Keil <kkeil@suse.de> Cc: <stable@kernel.org> Signed-off-by:
-
Darren Jenkins authored
Coverity CID: 2172 RESOURCE_LEAK When pool_allocate() tries to enlarge a packet, if it can not allocate enough memory, it returns NULL without first freeing the old packet. This patch just frees the packet first. Signed-off-by:
Darren Jenkins <darrenrjenkins@gmail.com> Acked-by:
Jiri Kosina <jkosina@suse.cz> Cc: <stable@kernel.org> Signed-off-by:
-
James Bottomley authored
If you do a modremove of any sas driver, you run into an oops on shutdown when the host is removed (coming from the host bsg device). The root cause seems to be that there's a use after free of the bsg_class_device: In bsg_kref_release_function, this is used (to do a put_device(bcg->parent) after bcg->release has been called. In sas (and possibly many other things) bcd->release frees the queue which contains the bsg_class_device, so we get a put_device on unreferenced memory. Fix this by taking a copy of the pointer to the parent before releasing bsg. Acked-by:
FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> Signed-off-by:
James Bottomley <James.Bottomley@HansenPartnership.com>
-
James Bottomley authored
There's a fault on the FC controllers that makes them not respond correctly to MSI. The SPI controllers are fine, but are likely to be onboard on older motherboards which don't handle MSI correctly, so default both these cases to disabled. Enable by setting the module parameter mpt_msi_enable=1. For the SAS case, enable MSI by default, but it can be disabled by setting the module parameter mpt_msi_enable=0. Cc: "Prakash, Sathya" <sathya.prakash@lsi.com> Signed-off-by:
-
