- 09 Aug, 2007 40 commits
-
-
Tejun Heo authored
Please warmly welcome the first member from FUJITSU to the prestigious NCQ spurious completion club. This is reported by Serge Van Thillo in bugzilla bug 8730. http://bugzilla.kernel.org/show_bug.cgi?id=8730Signed-off-by:
Tejun Heo <htejun@gmail.com> Cc: Serge van Thillo <nulleke@hotmail.com> Cc: Jeff Garzik <jeff@garzik.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Jens Axboe authored
With the cfq_queue hash removal, we inadvertently got rid of the async queue sharing. This was not intentional, in fact CFQ purposely shares the async queue per priority level to get good merging for async writes. So put some logic in cfq_get_queue() to track the shared queues. Signed-off-by:
Jens Axboe <jens.axboe@oracle.com> Signed-off-by:
-
Adrian Bunk authored
If it's EXPORT_SYMBOL'ed it can't be __devinit. Reported by Mikael Pettersson. Signed-off-by:
Adrian Bunk <bunk@stusta.de> Cc: "Antonino A. Daplas" <adaplas@pol.net> Cc: Michal Piotrowski <michal.k.k.piotrowski@gmail.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
-
Oleg Nesterov authored
Pointed out by Michal Schmidt <mschmidt@redhat.com>. The bug was introduced in 2.6.22 by me. cleanup_workqueue_thread() does flush_cpu_workqueue(cwq) in a loop until ->worklist becomes empty. This is live-lockable, a re-niced caller can get CPU after wake_up() and insert a new barrier before the lower-priority cwq->thread has a chance to clear ->current_work. Change cleanup_workqueue_thread() to do flush_cpu_workqueue(cwq) only once. We can rely on the fact that run_workqueue() won't return until it flushes all works. So it is safe to call kthread_stop() after that, the "should stop" request won't be noticed until run_workqueue() returns. Signed-off-by:
Oleg Nesterov <oleg@tv-sign.ru> Cc: Michal Schmidt <mschmidt@redhat.com> Cc: Srivatsa Vaddagiri <vatsa@in.ibm.com> Signed-off-by:
-
Mattia Dongili authored
The rewritten event reading code from sonypi was absolutely wrong, this patche makes things functional for type2 and type1 models. Cc: Andrei Paskevich <andrei@capet.iut-fbleau.fr> Signed-off-by:
Mattia Dongili <malattia@linux.it> Signed-off-by:
-
Jeff Dike authored
COWed devices can't handle more than 32 (64 on x86_64) sectors in one request due to the size of the bitmap being carried around in the io_thread_req. Enforce that by telling the block layer not to put too many sectors in requests to COWed devices. Signed-off-by:
Jeff Dike <jdike@linux.intel.com> Cc: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it> Signed-off-by:
-
Herbert van den Bergh authored
Fix a bug in mm/mlock.c on 32-bit architectures that prevents a user from locking more than 4GB of shared memory, or allocating more than 4GB of shared memory in hugepages, when rlim[RLIMIT_MEMLOCK] is set to RLIM_INFINITY. Signed-off-by:
Herbert van den Bergh <herbert.van.den.bergh@oracle.com> Acked-by:
Chris Mason <chris.mason@oracle.com> Signed-off-by:
-
Joe Jin authored
That static `nid' index needs locking. Without it we can end up calling alloc_pages_node() with an illegal node ID and the kernel crashes. Acked-by:
Gurudas Pai <gurudas.pai@oracle.com> Signed-off-by:
-
Jan Kara authored
We have to check that also the second checkpoint list is non-empty before dropping the transaction. Signed-off-by:
Jan Kara <jack@suse.cz> Cc: Chuck Ebbert <cebbert@redhat.com> Cc: Kirill Korotaev <dev@openvz.org> Cc: <linux-ext4@vger.kernel.org> Signed-off-by:
-
Jan Kara authored
We have to check that also the second checkpoint list is non-empty before dropping the transaction. Signed-off-by:
-
Venki Pallipadi authored
[CPUFREQ] acpi-cpufreq: Proper ReadModifyWrite of PERF_CTL MSR During recent acpi-cpufreq changes, writing to PERF_CTL msr changed from RMW of entire 64 bit to RMW of low 32 bit and clearing of upper 32 bit. Fix it back to do a proper RMW of the MSR. Signed-off-by:
Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Signed-off-by:
Dave Jones <davej@redhat.com> Cc: Chuck Ebbert <cebbert@redhat.com> Signed-off-by:
-
Ayaz Abdulla authored
This patch contains errata fixes for the realtek phy. It only renamed the defines to be phy specific. Signed-off-by:
Ayaz Abdulla <aabdulla@nvidia.com> Signed-off-by:
-
Ayaz Abdulla authored
This patch contains errata fixes for the vitesse phy. It only renamed the defines to be phy specific. Signed-off-by:
-
Ayaz Abdulla authored
This patch contains errata fixes for the cicada phy. It only renamed the defines to be phy specific. Signed-off-by:
-
Mariusz Kozlowski authored
When buf_check_overflow() returns != 0 we will hit kfree(ERR_PTR(err)) and it will not be happy about it. Signed-off-by:
Mariusz Kozlowski <m.kozlowski@tuxland.pl> Cc: Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
-
Fengguang Wu authored
Define two convenient macros for read-ahead: - MAX_RA_PAGES: rounded down counterpart of VM_MAX_READAHEAD - MIN_RA_PAGES: rounded _up_ counterpart of VM_MIN_READAHEAD Note that the rounded up MIN_RA_PAGES will work flawlessly with _large_ page sizes like 64k. Signed-off-by:
Fengguang Wu <wfg@mail.ustc.edu.cn> Cc: Steven Pratt <slpratt@austin.ibm.com> Cc: Ram Pai <linuxram@us.ibm.com> Cc: Rusty Russell <rusty@rustcorp.com.au> Signed-off-by:
-
J. Bruce Fields authored
The value of nperbucket calculated here is too small--we should be rounding up instead of down--with the result that the index j in the following loop can overflow the raparm_hash array. At least in my case, the next thing in memory turns out to be export_table, so the symptoms I see are crashes caused by the appearance of four zeroed-out export entries in the first bucket of the hash table of exports (which were actually entries in the readahead cache, a pointer to which had been written to the export table in this initialization code). It looks like the bug was probably introduced with commit fce1456a ("knfsd: make the readahead params cache SMP-friendly"). Cc: Greg Banks <gnb@melbourne.sgi.com> Signed-off-by:
"J. Bruce Fields" <bfields@citi.umich.edu> Acked-by:
NeilBrown <neilb@suse.de> Signed-off-by:
-
Michael Halcrow authored
There is another bug recently introduced into the ecryptfs_setattr() function in 2.6.22. eCryptfs will attempt to treat special files like regular eCryptfs files on chmod, chown, and so forth. This leads to a NULL pointer dereference. This patch validates that the file is a regular file before proceeding with operations related to the inode's crypt_stat. Thanks to Ryusuke Konishi for finding this bug and suggesting the fix. Signed-off-by:
Michael Halcrow <mhalcrow@us.ibm.com> Signed-off-by:
-
Jean Tourrilhes authored
Victor Porton reported that the SoftMAC layer had random problem when setting the ESSID : http://bugzilla.kernel.org/show_bug.cgi?id=8686 After investigation, it turned out to be worse, the SoftMAC layer is left in an inconsistent state. The fix is pretty trivial. Signed-off-by:
Jean Tourrilhes <jt@hpl.hp.com> Acked-by:
Michael Buesch <mb@bu3sch.de> Acked-by:
Larry Finger <Larry.Finger@lwfinger.net> Acked-by:
John W. Linville <linville@tuxdriver.com> Signed-off-by:
-
Stefan Richter authored
Found and debugged by Jay Fenlason <fenlason@redhat.com>. The bug was especially noticeable with direct I/O over fw-sbp2. Same as commit 9c9bdf4d. Signed-off-by:
Stefan Richter <stefanr@s5r6.in-berlin.de> Signed-off-by:
Kristian Høgsberg <krh@redhat.com> Signed-off-by:
-
Stefan Richter authored
context_stop is called by bus_reset_tasklet, among else. Fixes http://bugzilla.kernel.org/show_bug.cgi?id=8735. Same as commit b980f5a2. Signed-off-by:
-
Thomas Gleixner authored
Some systems have a HPET which is not incrementing, which leads to a complete hang. Detect it during HPET setup. Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Signed-off-by:
Andi Kleen <ak@suse.de> Cc: john stultz <johnstul@us.ibm.com> Signed-off-by:
-
Milan Broz authored
Flush workqueue before releasing bioset and mopools in dm-crypt. There can be finished but not yet released request. Call chain causing oops: run workqueue dec_pending bio_endio(...); <remove device request - remove mempool> mempool_free(io, cc->io_pool); This usually happens when cryptsetup create temporary luks mapping in the beggining of crypt device activation. When dm-core calls destructor crypt_dtr, no new request are possible. Signed-off-by:Milan Broz <mbroz@redhat.com> Cc: Chuck Ebbert <cebbert@redhat.com> Cc: Patrick McHardy <kaber@trash.net> Acked-by:
Alasdair G Kergon <agk@redhat.com> Cc: Christophe Saout <christophe@saout.de> Signed-off-by:
-
Herton Ronaldo Krzesinski authored
As reported by Gustavo de Nardin <gustavodn@mandriva.com.br>, while trying to compile xosview (http://xosview.sourceforge.net/) with upstream kernel headers being used you get the following errors: serialmeter.cc:48:30: error: linux/serial_reg.h: No such file or directory serialmeter.cc: In member function 'virtual void SerialMeter::checkResources()': serialmeter.cc:71: error: 'UART_LSR' was not declared in this scope serialmeter.cc:71: error: 'UART_MSR' was not declared in this scope ... Signed-off-by:
Herton Ronaldo Krzesinski <herton@mandriva.com.br> Cc: Gustavo de Nardin <gustavodn@mandriva.com.br> Cc: David Woodhouse <dwmw2@infradead.org> Cc: Russell King <rmk@arm.linux.org.uk> Signed-off-by:
-
Mingming Cao authored
Yan Zheng wrote: > I think I found a bug in ext4/extents.c, "ext4_ext_put_in_cache" uses > "__u32" to receive physical block number. "ext4_ext_put_in_cache" is > used in "ext4_ext_get_blocks", it sets ext4 inode's extent cache > according most recently tree lookup (higher 16 bits of saved physical > block number are always zero). when serving a mapping request, > "ext4_ext_get_blocks" first check whether the logical block is in > inode's extent cache. if the logical block is in the cache and the > cached region isn't a gap, "ext4_ext_get_blocks" gets physical block > number by using cached region's physical block number and offset in > the cached region. as described above, "ext4_ext_get_blocks" may > return wrong result when there are physical block numbers bigger than > 0xffffffff. > You are right. Thanks for reporting this! Signed-off-by:
Mingming Cao <cmm@us.ibm.com> Cc: Yan Zheng <yanzheng@21cn.com> Cc: <linux-ext4@vger.kernel.org> Signed-off-by:
-
Andreas Schwab authored
The fourth argument of sys_futex is ignored when op == FUTEX_WAKE_OP, but futex_wake_op expects it as its nr_wake2 parameter. The only user of this operation in glibc is always passing 1, so this bug had no consequences so far. Signed-off-by:
Andreas Schwab <schwab@suse.de> Cc: Ingo Molnar <mingo@elte.hu> Signed-off-by:
Ulrich Drepper <drepper@redhat.com> Signed-off-by:
-
Alexey Dobriyan authored
On every open/close one struct seq_operations leaks. Kudos to /proc/slab_allocators. Signed-off-by:
Alexey Dobriyan <adobriyan@sw.ru> Acked-by:
Ingo Molnar <mingo@elte.hu> Signed-off-by:
-
Daniel Ritz authored
Give sockets up to 100ms of additional time to power down. otherwise we might generate false warnings with KERN_ERR priority (like in bug #8262). Signed-off-by:
Daniel Ritz <daniel.ritz@gmx.ch> Cc: Nils Neumann <nils.neumann@rwth-aachen.de> Signed-off-by:
-
Maik Hampel authored
In case of read errors raid10d tries to print a nice error message, unfortunately using data from an already put bio. Signed-off-by:
Maik Hampel <m.hampel@gmx.de> Acked-By:
-
Arne Redlich authored
When writing to a broken array, raid10 currently happily emits empty bio lists. IOW, the master bio will never be completed, sending writers to UNINTERRUPTIBLE_SLEEP forever. Signed-off-by:
Arne Redlich <agr@powerkom-dd.de> Acked-by:
-
Pavel Emelianov authored
When user locks an ipc shmem segmant with SHM_LOCK ctl and the segment is already locked the shmem_lock() function returns 0. After this the subsequent code leaks the existing user struct: == ipc/shm.c: sys_shmctl() == ... err = shmem_lock(shp->shm_file, 1, user); if (!err) { shp->shm_perm.mode |= SHM_LOCKED; shp->mlock_user = user; } ... == Other results of this are: 1. the new shp->mlock_user is not get-ed and will point to freed memory when the task dies. 2. the RLIMIT_MEMLOCK is screwed on both user structs. The exploit looks like this: == id = shmget(...); setresuid(uid, 0, 0); shmctl(id, SHM_LOCK, NULL); setresuid(uid + 1, 0, 0); shmctl(id, SHM_LOCK, NULL); == My solution is to return 0 to the userspace and do not change the segment's user. Signed-off-by:Pavel Emelianov <xemul@openvz.org> Signed-off-by:
-
Ulrich Drepper authored
Is there a reason why the "online" file in the subdirectories for the CPUs in /sys/devices/system isn't world-readable? I cannot imagine it to be security relevant especially now that a getcpu() syscall can be used to determine what CPUa thread runs on. The file is useful to correctly implement the sysconf() function to return the number of online CPUs. In the presence of hotplug we currently cannot provide this information. The patch below should to it. Signed-off-by:
-
Alexey Dobriyan authored
Signed-off-by:
-
Dave Airlie authored
This 965G and above chipsets moved the batch buffer non-secure bits to another place. This means that previous drm's allowed in-secure batchbuffers to be submitted to the hardware from non-privileged users who are logged into X and and have access to direct rendering. Signed-off-by:
Dave Airlie <airlied@redhat.com> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Jens Axboe authored
If add_to_page_cache_lru() fails, the page will not be locked. But splice jumps to an error path that does a page release and unlock, causing a BUG() in unlock_page(). Fix this by adding one more label that just releases the page. This bug was actually triggered on EL5 by gurudas pai <gurudas.pai@oracle.com> using fio. Signed-off-by:
-
Dmitry Torokhov authored
Input: lifebook - fix an oops on Panasonic CF-18 Signed-off-by:
Dmitry Torokhov <dtor@mail.ru> Signed-off-by:
-
Hans Verkuil authored
State struct was never freed. (cherry picked from commit 1b2232ab) Signed-off-by:
Hans Verkuil <hverkuil@xs4all.nl> Signed-off-by:
Mauro Carvalho Chehab <mchehab@infradead.org> Signed-off-by:
Michael Krufky <mkrufky@linuxtv.org> Signed-off-by:
-
Hans Verkuil authored
Starting an MPEG and VBI capture simultaneously caused errors in the VBI setup: this setup was done twice when it should be done only for the first stream that is opened. Added a mutex to prevent this from happening. (cherry picked from commit f8859691) Signed-off-by:
-
Hans Verkuil authored
The VBI DMA is handled in a special way and is marked with a bit. However, that bit was set at the wrong time and could be cleared by mistake if a PCM (or other) DMA request would arrive before the VBI DMA was completed. So on completion of the VBI DMA the driver no longer knew that that DMA transfer was for VBI data. And this in turn caused havoc with the card's DMA engine. (cherry picked from commit dd1e729d) Signed-off-by:
-
Hans Verkuil authored
The old service_set_out setting was still tested, even though it no longer was ever set and was in fact obsolete. This meant that everything that was written to /dev/vbi16 was ignored. Removed the service_set_out variable altogether and now it works again. (cherry picked from commit 47fd3ba9) Signed-off-by:
-
