- 06 Aug, 2008 35 commits
-
-
Greg Kroah-Hartman authored
-
Willy Tarreau authored
commit 82e68f7f upstream snd_seq_oss_synth_make_info() incorrectly reports information to userspace without first checking for the validity of the device number, leading to possible information leak (CVE-2008-3272). Reported-By:
Tobias Klein <tk@trapkit.de> Acked-and-tested-by:
Takashi Iwai <tiwai@suse.de> Cc: stable@kernel.org Signed-off-by:
Willy Tarreau <w@1wt.eu> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Miklos Szeredi authored
commit d70b67c8 upstream Lookup can install a child dentry for a deleted directory. This keeps the directory dentry alive, and the inode pinned in the cache and on disk, even after all external references have gone away. This isn't a big problem normally, since memory pressure or umount will clear out the directory dentry and its children, releasing the inode. But for UBIFS this causes problems because its orphan area can overflow. Fix this by returning ENOENT for all lookups on a S_DEAD directory before creating a child dentry. Thanks to Zoltan Sogor for noticing this while testing UBIFS, and Artem for the excellent analysis of the problem and testing. Reported-by:
Artem Bityutskiy <Artem.Bityutskiy@nokia.com> Tested-by:
Miklos Szeredi <mszeredi@suse.cz> Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
-
Takashi Iwai authored
commit 43785eae upstream Don't create mixer volume elements for Headphone and Speaker if they use the same DAC as normal line-outs on AD1988. Otherwise the amp value gets screwed up, e.g. https://bugzilla.novell.com/show_bug.cgi?id=398255 Signed-off-by:
Jaroslav Kysela <perex@perex.cz> Signed-off-by:
-
Takashi Iwai authored
commit 470eaf6b upstream Added the missing SSID of Thinkpad Z60m for model=thinkpad with AD1981HD. Signed-off-by:
-
Takashi Iwai authored
Backport fixes for usb-audio Oops at reconnection. 9eb70e68... [ALSA] usb-audio - Fix race in reconnection f18638dc... [ALSA] Clean up snd_card_free*() 73d38b13 ... [ALSA] Fix the race of card instance unregistration Signed-off-by:
-
Takashi Iwai authored
commit d2cd74b1 upstream On Audigy2 Platinum, the Analog/Digital mixer switch is inverted. https://bugzilla.novell.com/show_bug.cgi?id=396204 The patch adds a simple workaround. There might be another device requiring a similar fix, too (or fix for audigy2 generically), but right now I fix only the known broken one. Signed-off-by:
-
Takashi Iwai authored
commit 6c4cc3a8 upstream Added more fallbacks to OSS PHONEOUT mixer mapping. This corresponds to the speaker output in general, so now "Mono" and "Speaker" are assigned. Signed-off-by:
-
Takashi Iwai authored
commit e48d6d97 upstream ASUS A9T laptop uses line-out pin as the real front-output while other devices use it as the surround. Signed-off-by:
-
Tejun Heo authored
commit 66d715c9 upstream It seems VT3336 can't do msi either as with its bro 3351. Disable it. Reported in the following SUSE bug. https://bugzilla.novell.com/show_bug.cgi?id=300001 Signed-off-by:
Tejun Heo <tj@kernel.org> Acked-by:
Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
-
Alan Stern authored
commit d1f114d1 upstream This patch (as1097) fixes a bug in the remote-wakeup handling in ehci-hcd. The driver currently does not keep track of whether the change-suspend feature is enabled for each port; the feature is automatically reset the first time it is read. But recent changes to the hub driver require that the feature be read at least twice in order to work properly. A bit-vector is added for storing the change-suspend feature values. Signed-off-by:
Alan Stern <stern@rowland.harvard.edu> Acked-by:
David Brownell <dbrownell@users.sourceforge.net> Signed-off-by:
-
Oliver Neukum authored
commit 90d95ef6 upstream On some boxes the touchpad needs to be reinitialized after resume to make it function again. This fixes bugzilla #10825. Signed-off-by:
Oliver Neukum <oneukum@suse.de> Signed-off-by:
Dmitry Torokhov <dtor@mail.ru> Signed-off-by:
-
Zhang, Rui authored
commit 76ecb4f2 upstream Fix the problem that thermal_get_temp returns the cached value, which causes the temperature in generic thermal never updates. Signed-off-by:
Zhang Rui <rui.zhang@intel.com> Acked-by:
Jean Delvare <khali@linux-fr.org> Signed-off-by:
Len Brown <len.brown@intel.com> Signed-off-by:
-
Arjan van de Ven authored
commit a39a2d7c upstream My laptop thinks that it's a good idea to give -73C as the critical CPU temperature.... which isn't the best thing since it causes a shutdown right at bootup. Temperatures below freezing are clearly invalid critical thresholds so just reject these as such. Signed-off-by:
Arjan van de Ven <arjan@linux.intel.com> Acked-by:
-
Andreas Schwab authored
commit e4cc5894 upstream Current versions of gdb require a working implementation of PTRACE_GETSIGINFO for proper watchpoint support. Since struct siginfo contains pointers it must be converted when passed to a 32-bit debugger. Signed-off-by:
Andreas Schwab <schwab@suse.de> Signed-off-by:
Paul Mackerras <paulus@samba.org> Signed-off-by:
-
Luis R. Rodriguez authored
Commit 6844e63a Hardware encryption doesn't work yet so lets use software encryption for now. Changes-licensed-under: 3-Clause-BSD Signed-off-by:
Luis R. Rodriguez <mcgrof@winlab.rutgers.edu> Signed-off-by:
John W. Linville <linville@tuxdriver.com> Cc: Jiri Benc <jbenc@suse.cz> Signed-off-by:
-
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:
-
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:
-
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:
-
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:
-
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:
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 5 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:
-
