- 06 Aug, 2008 19 commits
-
-
Holger Macht authored
commit 7efd52a4 upstream If acpi_install_notify_handler() for a bay device fails, the bay driver is superfluous. Most likely, another driver (like libata) is already caring about this device anyway. Furthermore, register_hotplug_dock_device(acpi_handle) from the dock driver must not be called twice with the same handler. This would result in an endless loop consuming 100% of CPU. So clean up and exit. Signed-off-by:
Holger Macht <hmacht@suse.de> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Len Brown <len.brown@intel.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Marcel Holtmann authored
commit ec8dab36 upstream When using the HIDP or BNEP kernel support, the user-space needs to know if the connection has been terminated for some reasons. Wake up the application if that happens. Otherwise kernel and user-space are no longer on the same page and weird behaviors can happen. Signed-off-by:
Marcel Holtmann <marcel@holtmann.org> Signed-off-by:
-
Frank Seidel authored
commit 0607fd02 upstream I received a complaint that some FAT formated medias (e.g. sd memory cards) trigger a "unknown partition table" message even though there is no partition table and they work correctly, while in general (when e.g. formated with mkdosfs or even Windows Vista) this message is not shown. Currently this seems only to happen when the medias get formatted with Windows XP (and possibly Win 2000). Then the boot indicator byte contains garbage (part of text message) and so do the other parts checked by msdos_paritition which then later triggers this message. References: novell bug #364365 Most fat formatted media without partition table contains zeros in the boot indication and the other tested bytes and so falls through the checks in msdos_partition, leading it to return with 1 (all is fine). But some (e.g. WinXP formatted) fat fomated medias don't use boot_ind and so the check fails and causes a "unkown partition table" warning eventhough there is none and everything would be fine. This additional check directly verifies if there is a fat formatted medium without a partition table. Signed-off-by:
Frank Seidel <fseidel@suse.de> Cc: Andreas Dilger <adilger@sun.com> Acked-by:
OGAWA Hirofumi <hirofumi@mail.parknet.co.jp> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Andrew Morton authored
commit 73f20e58 upstream The on-disk media specification field in FAT is only 8-bits, so testing for <=0xff is pointless, and can generate a "comparison is always true due to limited range of data type" warning. While we're there, convert FAT_VALID_MEDIA() into a C function - the present implementation is buggy: it generates either one or two references to its argument. Cc: Frank Seidel <fseidel@suse.de> Acked-by:
-
Jiri Kosina authored
commit 0376bce7 upstream. Acer Aspire 1360 needs to be added to nomux blacklist, otherwise its touchpad misbehaves. Reported-by:
Clark Tompsett <clarkt@cnsp.com> Signed-off-by:
Jiri Kosina <jkosina@suse.cz> Signed-off-by:
Dmitry Torokhov <dtor@mail.ru> Signed-off-by:
-
Jiri Kosina authored
commit 3f79b1e9 upstream Reported-by:
Hans Aschauer <Hans.Aschauer@web.de> Signed-off-by:
-
Jiri Kosina authored
Commit efd51846 upstream Fujitsu Siemens Amilo Pro V2030 needs nomux table entry, in addition to already existing entry for V2010 model (note that Fujitsu-Siemens changed the capitalization in the DMI data for product). Tested-by:
Jiri Mleziva <jmleziva@tiscali.cz> Signed-off-by:
-
Jiri Kosina authored
commit 5b5b43d0 upstream Gericom Bellagio needs to be added to nomux blacklist, otherwise its touchpad misbehaves. Reported-by:
Roland Kletzing <roland.kletzing@materna.de> Signed-off-by:
-
Jiri Kosina authored
commit c3a34f43 upstream This patch introduces i8042_dmi_nopnp_table to make it possible to perform DMI matches for systems that need 'i8042.nopnp' to work correctly, and introduces such an entry for Intel D845PESV -- this system doesn't detect PS2 mouse reliably without this option, as reported by Robert Lewis. [dtor@mail.ru - make it compile if CONFIG_PNP is off - reported by Randy Dunlap] Signed-off-by:
-
Jiri Kosina authored
commit 2f6a77d5 upstream There are systems that fail in i8042_resume() with i8042: Can't write CTR to resume as i8042_command(&i8042_ctr, I8042_CMD_CTL_WCTR) fails even though the controller claimed itself to be ready before. One retry after failing write fixes the problems on the failing systems. Reported-by:
Helmut Schaa <hschaa@novell.com> Signed-off-by:
-
Josef Bacik authored
commit 5b9a499d upstream There are several cases where the running transaction can get buffers added to its BJ_Metadata list which it never dirtied, which makes its t_nr_buffers counter end up larger than its t_outstanding_credits counter. This will cause issues when starting new transactions as while we are logging buffers we decrement t_outstanding_buffers, so when t_outstanding_buffers goes negative, we will report that we need less space in the journal than we actually need, so transactions will be started even though there may not be enough room for them. In the worst case scenario (which admittedly is almost impossible to reproduce) this will result in the journal running out of space. The fix is to only refile buffers from the committing transaction to the running transactions BJ_Modified list when b_modified is set on that journal, which is the only way to be sure if the running transaction has modified that buffer. This patch also fixes an accounting error in journal_forget, it is possible that we can call journal_forget on a buffer without having modified it, only gotten write access to it, so instead of freeing a credit, we only do so if the buffer was modified. The assert will help catch if this problem occurs. Without these two patches I could hit this assert within minutes of running postmark, with them this issue no longer arises. Thank you, Signed-off-by:
Josef Bacik <jbacik@redhat.com> Cc: <linux-ext4@vger.kernel.org> Acked-by:
Jan Kara <jack@ucw.cz> Signed-off-by:
-
Mingming Cao authored
commit 3f31fddf upstream journal_try_to_free_buffers() could race with jbd commit transaction when the later is holding the buffer reference while waiting for the data buffer to flush to disk. If the caller of journal_try_to_free_buffers() request tries hard to release the buffers, it will treat the failure as error and return back to the caller. We have seen the directo IO failed due to this race. Some of the caller of releasepage() also expecting the buffer to be dropped when passed with GFP_KERNEL mask to the releasepage()->journal_try_to_free_buffers(). With this patch, if the caller is passing the __GFP_WAIT and __GFP_FS to indicating this call could wait, in case of try_to_free_buffers() failed, let's waiting for journal_commit_transaction() to finish commit the current committing transaction, then try to free those buffers again. [akpm@linux-foundation.org: coding-style fixes] Signed-off-by:
Mingming Cao <cmm@us.ibm.com> Reviewed-by:
Badari Pulavarty <pbadari@us.ibm.com> Acked-by:
Jan Kara <jack@suse.cz> Signed-off-by:
-
Josef Bacik authored
commit 5bc833fe upstream Currently at the start of a journal commit we loop through all of the buffers on the committing transaction and clear the b_modified flag (the flag that is set when a transaction modifies the buffer) under the j_list_lock. The problem is that everywhere else this flag is modified only under the jbd lock buffer flag, so it will race with a running transaction who could potentially set it, and have it unset by the committing transaction. This is also a big waste, you can have several thousands of buffers that you are clearing the modified flag on when you may not need to. This patch removes this code and instead clears the b_modified flag upon entering do_get_write_access/journal_get_create_access, so if that transaction does indeed use the buffer then it will be accounted for properly, and if it does not then we know we didn't use it. That will be important for the next patch in this series. Tested thoroughly by myself using postmark/iozone/bonnie++. Signed-off-by:
-
Trond Myklebust authored
commit f41f7418 upstream ...and ensure that we obey the NFS_INO_INVALID_ACL flag when retrieving the acls. Signed-off-by:
Trond Myklebust <Trond.Myklebust@netapp.com> Signed-off-by:
-
FUJITA Tomonori authored
commit 483d8876 upstream Add an include <asm/time.h> statement for get_tb(). Signed-off-by:
FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> Signed-off-by:
Geoff Levand <geoffrey.levand@am.sony.com> Signed-off-by:
Paul Mackerras <paulus@samba.org> Cc: Jeff Mahoney <jeffm@suse.com> Signed-off-by:
-
Al Viro authored
commit e9baf6e5 upstream In case when both EEXIST and EROFS would apply we used to return the former in mkdir(2) and friends. Lest anyone suspects us of being consistent, in the same situation knfsd gave clients nfs_erofs... ro-bind series had switched the syscall side of things to returning -EROFS and immediately broke an application - namely, mkdir -p. Patch restores the original behaviour... Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk> Acked-by:
Jan Blunck <jblunck@suse.de> Signed-off-by:
-
Hannes Reinecke authored
commit 69cd39e9 upstream Newer Dell CERC firmware (>= 6.62) implement a random deletion handling compatible with the legacy megaraid driver. The legacy handling shifted the target ID by 0x80 only for I/O commands (READ/WRITE/etc), whereas megaraid_mbox shifts the target ID always if random deletion is supported. The resulted in megaraid_mbox sending an INQUIRY to the wrong channel, and not finding any devices, obviously. So we disable the random deletion support if the offending firmware is found. Addresses http://bugzilla.kernel.org/show_bug.cgi?id=6695 Signed-off-by:
Hannes Reinecke <hare@suse.de> Signed-off-by:
Bo Yang <Bo.Yang@lsi.com> Signed-off-by:
James Bottomley <James.Bottomley@HansenPartnership.com> Signed-off-by:
-
Ingo Molnar authored
commit 756a6c68 upstream x86: ioremap of 64-bit resource on 32-bit kernel fix Signed-off-by:
Ingo Molnar <mingo@elte.hu> Cc: Chuck Ebbert <cebbert@redhat.com> Signed-off-by:
-
Linus Torvalds authored
commit 0056e65f upstream We zero-fill them like we are supposed to, and that's all fine. It's only an error if the 'romfs_copyfrom()' routine isn't able to fill the data that is supposed to be there. Most of the patch is really just re-organizing the code a bit, and using separate variables for the error value and for how much of the page we actually filled from the filesystem. Reported-and-tested-by:
Chris Fester <cfester@wms.com> Cc: Alexander Viro <viro@zeniv.linux.org.uk> Cc: Matt Waddel <matt.waddel@freescale.com> Cc: Greg Ungerer <gerg@snapgear.com> Signed-of-by:
-
- 01 Aug, 2008 21 commits
-
-
Greg Kroah-Hartman authored
-
Linus Torvalds authored
commit 94ad374a upstream The iov_iter_advance() function would look at the iov->iov_len entry even though it might have iterated over the whole array, and iov was pointing past the end. This would cause DEBUG_PAGEALLOC to trigger a kernel page fault if the allocation was at the end of a page, and the next page was unallocated. The quick fix is to just change the order of the tests: check that there is any iovec data left before we check the iov entry itself. Thanks to Alexey Dobriyan for finding this case, and testing the fix. Reported-and-tested-by:
Alexey Dobriyan <adobriyan@gmail.com> Cc: Nick Piggin <npiggin@suse.de> Cc: Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
-
Patrick McHardy authored
netfilter: nf_conntrack_tcp: fix endless loop Upstream commit 6b69fe0c : When a conntrack entry is destroyed in process context and destruction is interrupted by packet processing and the packet is an attempt to reopen a closed connection, TCP conntrack tries to kill the old entry itself and returns NF_REPEAT to pass the packet through the hook again. This may lead to an endless loop: TCP conntrack repeatedly finds the old entry, but can not kill it itself since destruction is already in progress, but destruction in process context can not complete since TCP conntrack is keeping the CPU busy. Drop the packet in TCP conntrack if we can't kill the connection ourselves to avoid this. Reported by: hemao77@gmail.com [ Kernel bugzilla #11058 ] Signed-off-by:
Patrick McHardy <kaber@trash.net> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
David Gibson authored
Correct hash flushing from huge_ptep_set_wrprotect() [stable tree version] A fix for incorrect flushing of the hash page table at fork() for hugepages was recently committed as 86df8642 . Without this fix, a process can make a MAP_PRIVATE hugepage mapping, then fork() and have writes to the mapping after the fork() pollute the child's version. Unfortunately this bug also exists in the stable branch. In fact in that case copy_hugetlb_page_range() from mm/hugetlb.c calls ptep_set_wrprotect() directly, the hugepage variant hook huge_ptep_set_wrprotect() doesn't even exist. The patch below is a port of the fix to the stable25/master branch. It introduces a huge_ptep_set_wrprotect() call, but this is #defined to be equal to ptep_set_wrprotect() unless the arch defines its own version and sets __HAVE_ARCH_HUGE_PTEP_SET_WRPROTECT. This arch preprocessor flag is kind of nasty, but it seems the sanest way to introduce this fix with minimum risk of breaking other archs for whom prep_set_wprotect() is suitable for hugepages. Signed-off-by:
Andy Whitcroft <apw@shadowen.org> Signed-off-by:
David Gibson <david@gibson.dropbear.id.au> Signed-off-by:
-
Pavel Roskin authored
commit 256b152b upstream MSI is a nice thing, but we cannot enable it without changing the interrupt handler. If we do it, we break MSI capable hardware, specifically AR5006 chipset. Signed-off-by:
Pavel Roskin <proski@gnu.org> Acked-by:
Nick Kossifidis <mickflemm@gmail.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com> Signed-off-by:
-
Julia Lawall authored
commit 4104863f upstream The mutex is released on a successful return, so it would seem that it should be released on an error return as well. The semantic patch finds this problem is as follows: (http://www.emn.fr/x-info/coccinelle/ ) // <smpl> @@ expression l; @@ mutex_lock(l); .. when != mutex_unlock(l) when any when strict ( if (...) { ... when != mutex_unlock(l) + mutex_unlock(l); return ...; } | mutex_unlock(l); ) // </smpl> Signed-off-by:
Julia Lawall <julia@diku.dk> Signed-off-by:
Michael Buesch <mb@bu3sch.de> Signed-off-by:
-
Thomas Renninger authored
commit a1531acd upstream Ingo Molnar provided a fix to not call _PPC at processor driver initialization time in "[PATCH] ACPI: fix cpufreq regression" (git commit e4233dec ) But it can still happen that _PPC is called at processor driver initialization time. This patch should make sure that this is not possible anymore. Signed-off-by:
Thomas Renninger <trenn@suse.de> Cc: Andi Kleen <andi@firstfloor.org> Cc: Len Brown <lenb@kernel.org> Cc: Dave Jones <davej@codemonkey.org.uk> Cc: Ingo Molnar <mingo@elte.hu> Cc: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Signed-off-by:
-
Eric Sandeen authored
commit 7fcba054 upstream Date: Mon, 28 Jul 2008 15:46:39 -0700 Subject: eCryptfs: use page_alloc not kmalloc to get a page of memory With SLUB debugging turned on in 2.6.26, I was getting memory corruption when testing eCryptfs. The root cause turned out to be that eCryptfs was doing kmalloc(PAGE_CACHE_SIZE); virt_to_page() and treating that as a nice page-aligned chunk of memory. But at least with SLUB debugging on, this is not always true, and the page we get from virt_to_page does not necessarily match the PAGE_CACHE_SIZE worth of memory we got from kmalloc. My simple testcase was 2 loops doing "rm -f fileX; cp /tmp/fileX ." for 2 different multi-megabyte files. With this change I no longer see the corruption. Signed-off-by:
Eric Sandeen <sandeen@redhat.com> Acked-by:
Michael Halcrow <mhalcrow@us.ibm.com> Acked-by:
Rik van Riel <riel@redhat.com> Signed-off-by:
-
Jesse Brandeburg authored
commit bb5d10ac upstream The ixgbe driver was untested with device ID 8086:10c8 but still advertises support. Currently if this device is present in the system when the driver is loaded, the system will panic. Remove this device ID until full support can be tested with available hardware. This patch is necessary for 2.6.24, 2.6.25 and 2.6.26 Signed-off-by:
Jesse Brandeburg <jesse.brandeburg@intel.com> Signed-off-by:
Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by:
Jeff Garzik <jgarzik@redhat.com> Signed-off-by:
-
Mathieu Desnoyers authored
commit 5def9a3a upstream Paul pointed out two incorrect read barriers in the marker handler code in the path where multiple probes are connected. Those are ordering reads of "ptype" (single or multi probe marker), "multi" array pointer, and "multi" array data access. It should be ordered like this : read ptype smp_rmb() read multi array pointer smp_read_barrier_depends() access data referenced by multi array pointer The code with a single probe connected (optimized case, does not have to allocate an array) has correct memory ordering. It applies to kernel 2.6.26.x, 2.6.25.x and linux-next. Signed-off-by:
Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca> Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com> Signed-off-by:
-
Luotao Fu authored
commit 9a7867e1 upstream The block transfer routine in the mpc52xx psc spi driver misinterpret the datasheet. According to the processor datasheet the chipselect is held as long as the EOF is not written. Theoretically blocks of any sizes can be transferred in this way. The old routine however writes an EOF after every word, which has the size of size_of_word. This makes the transfer slow. Also fixed some duplicate code. Signed-off-by:
Luotao Fu <l.fu@pengutronix.de> Signed-off-by:
David Brownell <dbrownell@users.sourceforge.net> Signed-off-by:
-
Hugh Dickins authored
commit 14fcc23f upstream SuSE's insserve initscript ordering program hits kernel BUG at mm/shmem.c:814 on 2.6.26. It's using posix_fadvise on directories, and the shmem_readpage method added in 2.6.23 is letting POSIX_FADV_WILLNEED allocate useless pages to a tmpfs directory, incrementing i_blocks count but never decrementing it. Fix this by assigning shmem_aops (pointing to readpage and writepage and set_page_dirty) only when it's needed, on a regular file or a long symlink. Many thanks to Kel for outstanding bugreport and steps to reproduce it. Reported-by:
Kel Modderman <kel@otaku42.de> Tested-by:
Hugh Dickins <hugh@veritas.com> Signed-off-by:
-
Alex Nixon authored
commit 3971e1a9 upstream This commit: commit ba52de12 Author: Theodore Ts'o <tytso@mit.edu> Date: Wed Sep 27 01:50:49 2006 -0700 [PATCH] inode-diet: Eliminate i_blksize from the inode structure caused the block size used by pseudo-filesystems to decrease from PAGE_SIZE to 1024 leading to a doubling of the number of context switches during a kernbench run. Signed-off-by:
Alex Nixon <Alex.Nixon@citrix.com> Cc: Andi Kleen <andi@firstfloor.org> Cc: Jeremy Fitzhardinge <jeremy@goop.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Ingo Molnar <mingo@elte.hu> Cc: Ian Campbell <Ian.Campbell@eu.citrix.com> Cc: "Theodore Ts'o" <tytso@mit.edu> Cc: Alexander Viro <viro@zeniv.linux.org.uk> Cc: Hugh Dickins <hugh@veritas.com> Cc: Jens Axboe <jens.axboe@oracle.com> Signed-off-by:
-
Ingo Molnar authored
based on e22146e6 upstream Fix bug in kernel_physical_mapping_init() that causes kernel page table to be built incorrectly for systems with greater than 512GB of memory. Signed-off-by:
Jack Steiner <steiner@sgi.com> Cc: linux-mm@kvack.org Signed-off-by:
-
Tejun Heo authored
commit 15fe982e upstream ahci: retry enabling AHCI a few times before spitting out WARN_ON() Some chips need AHCI_EN set more than once to actually set it. Try a few times before giving up and spitting out WARN_ON(). Signed-off-by:
Tejun Heo <htejun@gmail.com> Cc: Peer Chen <pchen@nvidia.com> Cc: Volker Armin Hemmann <volker.armin.hemmann@tu-clausthal.de> Signed-off-by:
-
Pierre Ossman authored
Commit 981bcead upstream. Stop the S/PDIF DMA engine and output when the device is told to pause. It will keep on looping the current buffer contents if this isn't done. Signed-off-by:
Pierre Ossman <drzeus@drzeus.cx> Tested-by:
Rene Herman <rene.herman@gmail.com> Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
Jaroslav Kysela <perex@perex.cz> Cc: Chuck Ebbert <cebbert@redhat.com> Signed-off-by:
-
Akio Idehara authored
[ALSA] hda - Fix "alc262_sony_unsol[]" hda_verb array commit 7b1e8795 upstream I think that hda_verb array must have "terminator (empty array)". But alc262_sony_unsol[] does not have it. And it causes gcc-4.3's buggy behavior with snd_hda_sequence_write(). Signed-off-by:
Akio Idehara <zbe64533@gmail.com> Signed-off-by:
-
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:
Russell King <rmk+kernel@arm.linux.org.uk> 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:
-
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:
-
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:
-
