- 09 Aug, 2007 40 commits
-
-
Stefan Bader authored
This patch causes device-mapper to reject any barrier requests. This is done since most of the targets won't handle this correctly anyway. So until the situation improves it is better to reject these requests at the first place. Since barrier requests won't get to the targets, the checks there can be removed. Signed-off-by:
Stefan Bader <shbader@de.ibm.com> Signed-off-by:
Alasdair G Kergon <agk@redhat.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Milan Broz authored
Allow invalid snapshots to be activated instead of failing. This allows userspace to reinstate any given snapshot state - for example after an unscheduled reboot - and clean up the invalid snapshot at its leisure. Signed-off-by:
Milan Broz <mbroz@redhat.com> Signed-off-by:
-
Jun'ichi Nomura authored
bio_alloc_bioset() will return NULL if 'num_vecs' is too large. Use bio_get_nr_vecs() to get estimation of maximum number. Signed-off-by:
Junichi Nomura <j-nomura@ce.jp.nec.com> Signed-off-by:
-
Milan Broz authored
Fix mirror status line broken in dm-log-report-fault-status.patch: - space missing between two words - placeholder ("0") required for compatibility with a subsequent patch - incorrect offset parameter Signed-off-by: -
J. Bruce Fields authored
The handling of the re-registration case is wrong here; the "test" that was returned from auth_domain_lookup will not be used again, so that reference should be put. And auth_domain_lookup never did anything with "new" in this case, so we should just clean it up ourself. Thanks to Akinobu Mita for bug report, analysis, and testing. Cc: Akinobu Mita <akinobu.mita@gmail.com> Signed-off-by:
"J. Bruce Fields" <bfields@citi.umich.edu> Cc: Neil Brown <neilb@suse.de> Cc: Trond Myklebust <trond.myklebust@fys.uio.no> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
-
Stefan Richter authored
Revert commit 0555659d from 2.6.22-rc1. The dma_set_mask call somehow failed on a PowerMac G5, PPC64: http://lkml.org/lkml/2007/8/1/344 Should there ever occur a DMA mapping beyond the physical DMA range, a proper SBP-2 firmware will report transport errors. So let's leave it at that. Same as commit a9c2f188. Signed-off-by:
Stefan Richter <stefanr@s5r6.in-berlin.de> Tested-by:
Olaf Hering <olh@suse.de> Signed-off-by:
-
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:
-
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:
-
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:
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:
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: -
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:
-
