- 20 Aug, 2008 8 commits
-
-
Petr Tesarik authored
commit 938bb03d uptream Aesthetic regards aside, commit e8e7b9eb still leaves a bug in the error message, because it uses the unconverted big-endian value for printk. Fix this by using a local variable in machine byte order. The result is correct, more readable, and also produces slightly shorter code on i386. Signed-off-by:
Petr Tesarik <ptesarik@suse.cz> Cc: Jens Axboe <jens.axboe@oracle.com> Cc: Jan Kara <jack@suse.cz> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: <stable@kernel.org> Acked-by:
Borislav Petkov <petkovbb@gmail.com> [bart: __u32 -> u32] Signed-off-by:
Bartlomiej Zolnierkiewicz <bzolnier@gmail.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Tom Zanussi authored
commit 32194450 upstream In relay's current read implementation, if the buffer is completely full but hasn't triggered the buffer-full condition (i.e. the last write didn't cross the subbuffer boundary) and the last subbuffer is exactly full, the subbuffer accounting code erroneously finds nothing available. This patch fixes the problem. Signed-off-by:
Tom Zanussi <tzanussi@gmail.com> Cc: Eduard - Gabriel Munteanu <eduard.munteanu@linux360.ro> Cc: Pekka Enberg <penberg@cs.helsinki.fi> Cc: Jens Axboe <jens.axboe@oracle.com> Cc: Mathieu Desnoyers <compudj@krystal.dyndns.org> Cc: Andrea Righi <righi.andrea@gmail.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Ondrej Zajicek authored
commit 594a8819 upstream commit 20e061fb Author: Ondrej Zajicek <santiago@crfreenet.org> Date: Mon Apr 28 02:15:18 2008 -0700 fbdev: framebuffer_alloc() fixes Correct the dev arg of framebuffer_alloc() in arkfb, s3fb and vt8623fb. causes a null-pointer deref because "info->dev is NULL, info was just kzallocated". Signed-off-by:
Ondrej Zajicek <santiago@crfreenet.org> Reported-by:
"MadLoisae@gmx.net" <MadLoisae@gmx.net> Tested-by:
-
HighPoint Linux Team authored
commit dd07428b upstream Add PCI device ID for new adapter models. Signed-off-by:
HighPoint Linux Team <linux@highpoint-tech.com> Signed-off-by:
James Bottomley <James.Bottomley@HansenPartnership.com> Signed-off-by:
-
Tim Wright authored
commit ad337591 upstream It seems cdrwtool in the udftools has been unusable on "modern" kernels for some time. A Google search reveals many people with the same issue but no solution (cdrwtool fails to format the disk). After spending some time tracking down the issue, it comes down to the following: The udftools still use the older CDROM_SEND_PACKET interface to send things like FORMAT_UNIT through to the drive. They should really be updated, but that's another story. Since most distros are using libata now, the cd or dvd burner appears as a SCSI device, and we wind up in block/scsi_ioctl.c. Here, the code tries to take the "struct cdrom_generic_command" and translate it and stuff it into a "struct sg_io_hdr" structure so it can pass it to the modern sg_io() routine instead. Unfortunately, there is one error, or rather an omission in the translation. The timeout that is passed in in the "struct cdrom_generic_command" is in HZ=100 units, and this is modified and correctly converted to jiffies by use of clock_t_to_jiffies(). However, a little further down, this cgc.timeout value in jiffies is simply copied into the sg_io_hdr timeout, which should be in milliseconds. Since most modern x86 kernels seems to be getting build with HZ=250, the timeout that is passed to sg_io and eventually converted to the timeout_per_command member of the scsi_cmnd structure is now four times too small. Since cdrwtool tries to set the timeout to one hour for the FORMAT_UNIT command, and it takes about 20 minutes to format a 4x CDRW, the SCSI error-handler kicks in after the FORMAT_UNIT completes because it took longer than the incorrectly-calculated timeout. [jejb: fix up whitespace] Signed-off-by:
Tim Wright <timw@splhi.com> Signed-off-by:
-
James Bottomley authored
commit e8bac9e0 upstream The class_device->device conversion is causing an oops in revalidate because it's assuming that the device_for_each_child iterator will only return struct scsi_device children. The conversion made all former class_devices children of the device as well, so this assumption is broken. Fix it. Signed-off-by:
-
James Bottomley authored
commit 671a99c8 upstream There are a few kerneloops.org reports like this one: http://www.kerneloops.org/search.php?search=ses_match_to_enclosure That seem to imply we're running off the end of the VPD inquiry data (although at 512 bytes, it should be long enough for just about anything). we should be using correctly sized buffers anyway, so put those in and hope this oops goes away. Signed-off-by:
-
KOSAKI Motohiro authored
commit a477097d upstream Halesh says: Please find the below testcase provide to test mlock. Test Case : =========================== #include <sys/resource.h> #include <stdio.h> #include <sys/stat.h> #include <sys/types.h> #include <unistd.h> #include <sys/mman.h> #include <fcntl.h> #include <errno.h> #include <stdlib.h> int main(void) { int fd,ret, i = 0; char *addr, *addr1 = NULL; unsigned int page_size; struct rlimit rlim; if (0 != geteuid()) { printf("Execute this pgm as root\n"); exit(1); } /* create a file */ if ((fd = open("mmap_test.c",O_RDWR|O_CREAT,0755)) == -1) { printf("cant create test file\n"); exit(1); } page_size = sysconf(_SC_PAGE_SIZE); /* set the MEMLOCK limit */ rlim.rlim_cur = 2000; rlim.rlim_max = 2000; if ((ret = setrlimit(RLIMIT_MEMLOCK,&rlim)) != 0) { printf("Cant change limit values\n"); exit(1); } addr = 0; while (1) { /* map a page into memory each time*/ if ((addr = (char *) mmap(addr,page_size, PROT_READ | PROT_WRITE,MAP_SHARED,fd,0)) == MAP_FAILED) { printf("cant do mmap on file\n"); exit(1); } if (0 == i) addr1 = addr; i++; errno = 0; /* lock the mapped memory pagewise*/ if ((ret = mlock((char *)addr, 1500)) == -1) { printf("errno value is %d\n", errno); printf("cant lock maped region\n"); exit(1); } addr = addr + page_size; } } ====================================================== This testcase results in an mlock() failure with errno 14 that is EFAULT, but it has nowhere been specified that mlock() will return EFAULT. When I tested the same on older kernels like 2.6.18, I got the correct result i.e errno 12 (ENOMEM). I think in source code mlock(2), setting errno ENOMEM has been missed in do_mlock() , on mlock_fixup() failure. SUSv3 requires the following behavior frmo mlock(2). [ENOMEM] Some or all of the address range specified by the addr and len arguments does not correspond to valid mapped pages in the address space of the process. [EAGAIN] Some or all of the memory identified by the operation could not be locked when the call was made. This rule isn't so nice and slighly strange. but many people think POSIX/SUS compliance is important. Reported-by:
Halesh Sadashiv <halesh.sadashiv@ap.sony.com> Tested-by:
KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com> Signed-off-by:
-
- 06 Aug, 2008 27 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:
-
Jiri Slaby authored
commit 10488f8a upstream Don't forget to kill tasklets on stop to not panic if they fire after freeing some structures. Signed-off-by:
Jiri Slaby <jirislaby@gmail.com> Acked-by:
Nick Kossifidis <mickflemm@gmail.com> Cc: Luis R. Rodriguez <mcgrof@gmail.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com> Signed-off-by:
-
Jiri Slaby authored
commit 3a0f2c87 upstream When signal is noisy, hardware can use all RX buffers and since the last entry in the list is self-linked, it overwrites the entry until we link new buffers. Ensure that we don't free this last one until we are 100% sure that it is not used by the hardware anymore to not cause memory curruption as can be seen below. This is done by checking next buffer in the list. Even after that we know that the hardware refetched the new link and proceeded further (the next buffer is ready) we can finally free the overwritten buffer. We discard it since the status in its descriptor is overwritten (OR-ed by new status) too. ============================================================================= BUG kmalloc-4096: Poison overwritten ----------------------------------------------------------------------------- INFO: 0xffff810067419060-0xffff810067419667. First byte 0x8 instead of 0x6b INFO: Allocated in dev_alloc_skb+0x18/0x30 age=1118 cpu=1 pid=0 INFO: Freed in skb_release_data+0x85/0xd0 age=1105 cpu=1 pid=3718 INFO: Slab 0xffffe200019d0600 objects=7 used=0 fp=0xffff810067419048 flags=0x40000000000020c3 INFO: Object 0xffff810067419048 @offset=4168 fp=0xffff81006741c120 Bytes b4 0xffff810067419038: 4f 0b 02 00 01 00 00 00 5a 5a 5a 5a 5a 5a 5a 5a O.......ZZZZZZZZ Object 0xffff810067419048: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk Object 0xffff810067419058: 6b 6b 6b 6b 6b 6b 6b 6b 08 42 30 00 00 0b 6b 80 kkkkkkkk.B0...k. Object 0xffff810067419068: f0 5d 00 4f 62 08 a3 64 00 0c 42 16 52 e4 f0 5a 360].Ob.243d..B.R344360Z Object 0xffff810067419078: 68 81 00 00 7b a5 b4 be 7d 3b 8f 53 cd d5 de 12 h...{245264276};.S315325336. Object 0xffff810067419088: 96 10 0b 89 48 54 23 41 0f 4e 2d b9 37 c3 cb 29 ....HT#A.N-2717303313) Object 0xffff810067419098: d1 e0 de 14 8a 57 2a cc 3b 44 0d 78 7a 19 12 15 321340336..W*314;D.xz... Object 0xffff8100674190a8: a9 ec d4 35 a8 10 ec 8c 40 a7 06 0a 51 a7 48 bb 2513543245250.354.@247..Q247H273 Object 0xffff8100674190b8: 3e cf a1 c7 38 60 63 3f 51 15 c7 20 eb ba 65 30 >ϡ3078`c?Q.307.353272e0 Redzone 0xffff81006741a048: bb bb bb bb bb bb bb bb 273273273273273273273273 Padding 0xffff81006741a088: 5a 5a 5a 5a 5a 5a 5a 5a ZZZZZZZZ Pid: 3297, comm: ath5k_pci Not tainted 2.6.26-rc8-mm1_64 #427 Call Trace: [<ffffffff802a7306>] print_trailer+0xf6/0x150 [<ffffffff802a7485>] check_bytes_and_report+0x125/0x180 [<ffffffff802a75dc>] check_object+0xac/0x260 [<ffffffff802a9308>] __slab_alloc+0x368/0x6d0 [<ffffffff80544f82>] ? wireless_send_event+0x142/0x310 [<ffffffff804b1bd4>] ? __alloc_skb+0x44/0x150 [<ffffffff80544f82>] ? wireless_send_event+0x142/0x310 [<ffffffff802aa853>] __kmalloc_track_caller+0xc3/0xf0 [<ffffffff804b1bfe>] __alloc_skb+0x6e/0x150 [... stack snipped] FIX kmalloc-4096: Restoring 0xffff810067419060-0xffff810067419667=0x6b FIX kmalloc-4096: Marking all objects used Signed-off-by:
-
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 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 470eaf6b upstream Added the missing SSID of Thinkpad Z60m for model=thinkpad with AD1981HD. Signed-off-by:
Jaroslav Kysela <perex@perex.cz> Signed-off-by:
-
Takashi Iwai authored
commit 9ad593f6 upstream Many HD-audio controllers seem inaccurate about the IRQ timing of PCM period updates. This has caused problems on audio quality; e.g. JACK doesn't work with two periods. This patch fixes the problem by checking the current DMA position at IRQ handler and delays the period-update via a workq if it's inaccurate. 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=398255Signed-off-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:
-
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:
-
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 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:
-
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:
-
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 3d164fb0 upstream. The following commit causes ch_remove oops: commit 24b42566 Author: Greg Kroah-Hartman <gregkh@suse.de> Date: Fri May 16 17:55:12 2008 -0700 SCSI: fix race in device_create There is a race from when a device is created with device_create() and then the drvdata is set with a call to dev_set_drvdata() in which a sysfs file could be open, yet the drvdata will be NULL, causing all sorts of bad things to happen. This patch fixes the problem by using the new function, device_create_drvdata(). It fixes the problem in all of the scsi drivers that need it. Cc: Kay Sievers <kay.sievers@vrfy.org> Cc: Doug Gilbert <dgilbert@interlog.com> Cc: James E.J. Bottomley <James.Bottomley@HansenPartnership.com> Signed-off-by:
FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> Signed-off-by:
-
Nikanth Karthikesan authored
[ Upstream commit 13864515 ] From: "Nikanth Karthikesan" <knikanth@novell.com> Correct disk numbering problem check. Signed-off-by:
Nikanth Karthikesan <knikanth@suse.de> Signed-off-by:
Neil Brown <neilb@suse.de> CC: Oliver Pinter <oliver.pntr@gmail.com> Signed-off-by:
-
David Howells authored
[ Upstream commit 280763c0 ] Fix netfilter xt_time's time_mt()'s use of do_div() on an s64 by using div_s64() instead. This was introduced by patch ee4411a1 ("[NETFILTER]: x_tables: add xt_time match"). Signed-off-by:
David Howells <dhowells@redhat.com> Signed-off-by:
Patrick McHardy <kaber@trash.net> Signed-off-by:
David S. Miller <davem@davemloft.net> CC: Oliver Pinter <oliver.pntr@gmail.com> Signed-off-by:
-
Peter Zijlstra authored
[ Upstream commit d54191b8 ] On Mon, 2008-04-21 at 18:54 -0400, Masami Hiramatsu wrote: > Thank you for reporting. > > Actually, kprobes tries to fixup thread's flags in post_kprobe_handler > (which is called from kprobe_exceptions_notify) by > trace_hardirqs_fixup_flags(pt_regs->flags). However, even the irq flag > is set in pt_regs->flags, true hardirq is still off until returning > from do_debug. Thus, lockdep assumes that hardirq is off without annotation. > > IMHO, one possible solution is that fixing hardirq flags right after > notify_die in do_debug instead of in post_kprobe_handler. My reply to BZ 10489: > [ 2.707509] Kprobe smoke test started > [ 2.709300] ------------[ cut here ]------------ > [ 2.709420] WARNING: at kernel/lockdep.c:2658 check_flags+0x4d/0x12c() > [ 2.709541] Modules linked in: > [ 2.709588] Pid: 1, comm: swapper Not tainted 2.6.25.jml.057 #1 > [ 2.709588] [<c0126acc>] warn_on_slowpath+0x41/0x51 > [ 2.709588] [<c010bafc>] ? save_stack_trace+0x1d/0x3b > [ 2.709588] [<c0140a83>] ? save_trace+0x37/0x89 > [ 2.709588] [<c011987d>] ? kernel_map_pages+0x103/0x11c > [ 2.709588] [<c0109803>] ? native_sched_clock+0xca/0xea > [ 2.709588] [<c0142958>] ? mark_held_locks+0x41/0x5c > [ 2.709588] [<c0382580>] ? kprobe_exceptions_notify+0x322/0x3af > [ 2.709588] [<c0142aff>] ? trace_hardirqs_on+0xf1/0x119 > [ 2.709588] [<c03825b3>] ? kprobe_exceptions_notify+0x355/0x3af > [ 2.709588] [<c0140823>] check_flags+0x4d/0x12c > [ 2.709588] [<c0143c9d>] lock_release+0x58/0x195 > [ 2.709588] [<c038347c>] ? __atomic_notifier_call_chain+0x0/0x80 > [ 2.709588] [<c03834d6>] __atomic_notifier_call_chain+0x5a/0x80 > [ 2.709588] [<c0383508>] atomic_notifier_call_chain+0xc/0xe > [ 2.709588] [<c013b6d4>] notify_die+0x2d/0x2f > [ 2.709588] [<c038168a>] do_debug+0x67/0xfe > [ 2.709588] [<c0381287>] debug_stack_correct+0x27/0x30 > [ 2.709588] [<c01564c0>] ? kprobe_target+0x1/0x34 > [ 2.709588] [<c0156572>] ? init_test_probes+0x50/0x186 > [ 2.709588] [<c04fae48>] init_kprobes+0x85/0x8c > [ 2.709588] [<c04e947b>] kernel_init+0x13d/0x298 > [ 2.709588] [<c04e933e>] ? kernel_init+0x0/0x298 > [ 2.709588] [<c04e933e>] ? kernel_init+0x0/0x298 > [ 2.709588] [<c0105ef7>] kernel_thread_helper+0x7/0x10 > [ 2.709588] ======================= > [ 2.709588] ---[ end trace 778e504de7e3b1e3 ]--- > [ 2.709588] possible reason: unannotated irqs-off. > [ 2.709588] irq event stamp: 370065 > [ 2.709588] hardirqs last enabled at (370065): [<c0382580>] kprobe_exceptions_notify+0x322/0x3af > [ 2.709588] hardirqs last disabled at (370064): [<c0381bb7>] do_int3+0x1d/0x7d > [ 2.709588] softirqs last enabled at (370050): [<c012b464>] __do_softirq+0xfa/0x100 > [ 2.709588] softirqs last disabled at (370045): [<c0107438>] do_softirq+0x74/0xd9 > [ 2.714751] Kprobe smoke test passed successfully how I love this stuff... Ok, do_debug() is a trap, this can happen at any time regardless of the machine's IRQ state. So the first thing we do is fix up the IRQ state. Then we call this die notifier stuff; and return with messed up IRQ state... YAY. So, kprobes fudges it.. notify_die(DIE_DEBUG) kprobe_exceptions_notify() post_kprobe_handler() modify regs->flags trace_hardirqs_fixup_flags(regs->flags); <--- must be it So what's the use of modifying flags if they're not meant to take effect at some point. /me tries to reproduce issue; enable kprobes test thingy && boot OK, that reproduces.. So the below makes it work - but I'm not getting this code; at the time I wrote that stuff I CC'ed each and every kprobe maintainer listed in the usual places but got no reposonse - can some please explain this stuff to me? Are the saved flags only for the TF bit or are they made in full effect later (and if so, where) ? Signed-off-by:
Peter Zijlstra <a.p.zijlstra@chello.nl> Acked-by:
Masami Hiramatsu <mhiramat@redhat.com> Signed-off-by:
Ingo Molnar <mingo@elte.hu> CC: Oliver Pinter <oliver.pntr@gmail.com> Signed-off-by:
-
Neil Brown authored
[ Upstream commit f48ed538 ] There is a possible race in md_probe. If two threads call md_probe for the same device, then one could exit (having checked that ->gendisk exists) before the other has called kobject_init_and_add, thus returning an incomplete kobj which will cause problems when we try to add children to it. So extend the range of protection of disks_mutex slightly to avoid this possibility. Signed-off-by:
-
Cyrill Gorcunov authored
[ Upstream commit d6cd7eff ] Signed-off-by:
Cyrill Gorcunov <gorcunov@gmail.com> Cc: akpm@linux-foundation.org Cc: andi@firstfloor.org Signed-off-by:
-
Cyrill Gorcunov authored
[ Upstream commit ab6bc3e3 ] Signed-off-by:
-
FUJITA Tomonori authored
commit 3f27e3ed upstream [SCSI] bsg: fix bsg_mutex hang with device removal We don't need to hold bsg_mutex during bsg_complete_all_commands(). It leads to a problem that we block bsg_unregister_queue during bsg_complete_all_commands (untill all the outstanding commands complete). Thanks to Pete Wyckoff for finding the bug and testing the patch. The detailed bug report is: http://marc.info/?l=linux-scsi&m=121182137132145&w=2Tested-by:
Pete Wyckoff <pw@osc.edu> Signed-off-by:
-
Herbert Xu authored
netfilter: nf_nat_sip: c= is optional for session Upstream commit c71529e4: According to RFC2327, the connection information is optional in the session description since it can be specified in the media description instead. My provider does exactly that and does not provide any connection information in the session description. As a result the new kernel drops all invite responses. This patch makes it optional as documented. Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au> 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:
-
Greg Kroah-Hartman authored
There is no ftrace in the 2.6.26 kernel release, so remove the documentation as it isn't needed. Cc: Steven Rostedt <rostedt@goodmis.org> Signed-off-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:
-
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:
-
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:
-
