- 09 Aug, 2007 40 commits
-
-
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:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
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:
Jens Axboe <jens.axboe@oracle.com> 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:
-
Hans Verkuil authored
If v4l2_ctrl_next is called without the V4L2_CTRL_FLAG_NEXT_CTRL then it should check whether the passed control ID is valid and return 0 if it isn't. Otherwise a for-loop over the control IDs will never end. (cherry picked from commit a46c5fbc) Signed-off-by:
-
Davide Libenzi authored
Davi fixed a missing cast in the __put_user(), that was making timerfd return a single byte instead of the full value. Talking with Michael about the timerfd man page, we think it'd be better to use a u64 for the returned value, to align it with the eventfd implementation. This is an ABI change. The timerfd code is new in 2.6.22 and if we merge this into 2.6.23 then we should also merge it into 2.6.22.x. That will leave a few early 2.6.22 kernels out in the wild which might misbehave when a future timerfd-enabled glibc is run on them. mtk says: The difference would be that read() will only return 4 bytes, while the application will expect 8. If the application is checking the size of returned value, as it should, then it will be able to detect the problem (it could even be sophisticated enough to know that if this is a 4-byte return, then it is running on an old 2.6.22 kernel). If the application is not checking the return from read(), then its 8-byte buffer will not be filled -- the contents of the last 4 bytes will be undefined, so the u64 value as a whole will be junk. When I wrote up that description above, I forgot a crucial detail. The above description described the difference between the new behavior implemented by the patch, and the current (i.e., 2.6.22) *intended* behavior. However, as I originally remarked to Davide, the 2.6.22 read() behavior is broken: it should return 4 bytes on a read(), but as originally implemented, only the least significant byte contained valid information. (In other words, the top 3 bytes of overrun information were simply being discarded.) So the patch both fixes a bug in the originally intended behavior, and changes the intended behavior (to return 8 bytes from a read() instead of 4). Signed-off-by:
Davide Libenzi <davidel@xmailserver.org> Cc: Michael Kerrisk <mtk-manpages@gmx.net> Cc: Davi Arnaut <davi@haxent.com.br> Signed-off-by:
-
Stefan Richter authored
As far as I know, all CardBus FireWire 400 adapters have a maximum payload of 1024 bytes which is less than the speed-dependent limit of 2048 bytes. Fw-sbp2 has to take the host adapter's limit into account. This apparently fixes Juju's incompatibility with my CardBus cards, a NEC based card and a VIA based card. Backport of commit 25659f71. Signed-off-by:
-
Alan Cox authored
On the SCSI layer ioctl path there is no implicit permissions check for ioctls (and indeed other drivers implement unprivileged ioctls). aacraid however allows all sorts of very admin only things to be done so should check. Signed-off-by:
Alan Cox <alan@redhat.com> Acked-by:
Mark Salyzyn <mark_salyzyn@adaptec.com> Signed-off-by:
-
Petr Vandrovec authored
ata_tf_read was setting HOB bit when lba48 command was submitted, but was not clearing it before reading "normal" data. As it is only place which sets HOB bit in control register, and register reads should not be affected by other bits, let's just clear it when we are done with reading upper bytes so non-48bit commands do not have to touch ctl at all. pata_scc suffered from same problem... Signed-off-by:
Petr Vandrovec <petr@vandrovec.name> Signed-off-by:
Jeff Garzik <jeff@garzik.org> Signed-off-by:
-
