- 20 Aug, 2008 34 commits
-
-
Marcelo Tosatti authored
(cherry picked from commit c93cd3a5) If 'g' is one then limit is 4kb granular. Signed-off-by:
Marcelo Tosatti <mtosatti@redhat.com> Signed-off-by:
Avi Kivity <avi@qumranet.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Avi Kivity authored
(cherry-picked from commit 577bdc49) When an event (such as an interrupt) is injected, and the stack is shadowed (and therefore write protected), the guest will exit. The current code will see that the stack is shadowed and emulate a few instructions, each time postponing the injection. Eventually the injection may succeed, but at that time the guest may be unwilling to accept the interrupt (for example, the TPR may have changed). This occurs every once in a while during a Windows 2008 boot. Fix by unshadowing the fault address if the fault was due to an event injection. Signed-off-by:
-
Marcelo Tosatti authored
(cherry-picked from commit 34198bf8) There is no guarantee that the old TSS descriptor in the GDT contains the proper base address. This is the case for Windows installation's reboot-via-triplefault. Use guest registers instead. Also translate the address properly. Signed-off-by:
-
Marcelo Tosatti authored
(cherry picked from commit 98899aa0) The segment base is always a linear address, so translate before accessing guest memory. Signed-off-by:
-
David S. Miller authored
[ Upstream commit 0a4949c4 ] That's the userland thread register, so we should never try to change it like this. Based upon glibc bug nptl/6577 and suggestions by Jakub Jelinek. Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
David S. Miller authored
[ Upstream commit 17b6f586 ] We were picking %i7 out of the wrong register window stack slot. Signed-off-by:
-
Mikael Pettersson authored
[ Upstream commit d72609e1 ] Correct sparc64's implementation of FUTEX_OP_ANDN to do a bitwise negate of the oparg parameter before applying the AND operation. All other archs that support FUTEX_OP_ANDN either negate oparg explicitly (frv, ia64, mips, sh, x86), or do so indirectly by using an and-not instruction (powerpc). Since sparc64 has and-not, I chose to use that solution. I've not found any use of FUTEX_OP_ANDN in glibc so the impact of this bug is probably minor. But other user-space components may try to use it so it should still get fixed. Signed-off-by:
Mikael Pettersson <mikpe@it.uu.se> Signed-off-by:
-
Wei Yongjun authored
[ Upstream commit 77e2f14f ] SCTP used ip6_xmit() to send fragments after received ICMP packet too big message. But while send packet used ip6_xmit, the skb->local_df is not initialized. So when skb if enter ip6_fragment(), the following code will discard the skb. ip6_fragment(...) { if (!skb->local_df) { ... return -EMSGSIZE; } ... } SCTP do the following step: 1. send packet ip6_xmit(skb, ipfragok=0) 2. received ICMP packet too big message 3. if PMTUD_ENABLE: ip6_xmit(skb, ipfragok=1) This patch fixed the problem by set local_df if ipfragok is true. Signed-off-by:
Wei Yongjun <yjwei@cn.fujitsu.com> Acked-by:
Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by:
-
Stephen Hemminger authored
[ Upstream commit 697f8d03 ] The rationale is: * use u32 consistently * no need to do LCG on values from (better) get_random_bytes * use more data from get_random_bytes for secondary seeding * don't reduce state space on srandom32() * enforce state variable initialization restrictions Note: the second paper has a version of random32() with even longer period and a version of random64() if needed. Signed-off-by:
Stephen Hemminger <shemminger@vyatta.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Cc: David S. Miller <davem@davemloft.net> Signed-off-by:
-
Florian Westphal authored
[ Upstream commit 16df845f ] ecn_ok is not initialized when a connection is established by cookies. The cookie syn-ack never sets ECN, so ecn_ok must be set to 0. Spotted using ns-3/network simulation cradle simulator and valgrind. Signed-off-by:
Florian Westphal <fw@strlen.de> Signed-off-by:
-
Arnaldo Carvalho de Melo authored
commit 3e8a0a55 upstream Thanks to Eugene Teo for reporting this problem. Signed-off-by:
Eugene Teo <eugeneteo@kernel.sg> Signed-off-by:
Arnaldo Carvalho de Melo <acme@redhat.com> Signed-off-by:
Gerrit Renker <gerrit@erg.abdn.ac.uk> Signed-off-by:
-
Steve French authored
commit 2c731afb upstream Signed-off-by:
Steve French <sfrench@us.ibm.com> Signed-off-by:
-
Steve French authored
commit ad661334 upstream In looking at network named pipe support on cifs, I noticed that Dave Howell's iget patch: iget: stop CIFS from using iget() and read_inode() broke mounts to IPC$ (the interprocess communication share), and don't handle the error case (when getting info on the root inode fails). Thanks to Gunter who noted a typo in a debug line in the original version of this patch. CC: David Howells <dhowells@redhat.com> CC: Gunter Kukkukk <linux@kukkukk.com> Signed-off-by:
-
Carlos Corbacho authored
commit 5c742b45 upstream In the old acer_acpi, I discovered that on some of the newer AMW0 laptops that supported the WMID methods, they don't work properly for setting the wireless and bluetooth values. So for the AMW0 V2 laptops, we want to use both the 'old' AMW0 and the 'new' WMID methods for setting wireless & bluetooth to guarantee we always enable it. This was fixed in acer_acpi some time ago, but I forgot to port the patch over to acer-wmi when it was merged. (Without this patch, early AMW0 V2 laptops such as the Aspire 5040 won't work with acer-wmi, where-as they did with the old acer_acpi). AK: fix compilation Signed-off-by:
Carlos Corbacho <carlos@strangeworlds.co.uk> Signed-off-by:
Andi Kleen <ak@linux.intel.com> Signed-off-by:
-
Sven Wegener authored
commit 8ab19ea3 upstream There is a slight chance for a deadlock in the estimator code. We can't call del_timer_sync() while holding our lock, as the timer might be active and spinning for the lock on another cpu. Work around this issue by using try_to_del_timer_sync() and releasing the lock. We could actually delete the timer outside of our lock, as the add and kill functions are only every called from userspace via [gs]etsockopt() and are serialized by a mutex, but better make this explicit. Signed-off-by:
Sven Wegener <sven.wegener@stealer.net> Acked-by:
Simon Horman <horms@verge.net.au> Signed-off-by:
-
Andre Schenk authored
commit b5894a50 upstream USB product id registration for the ELV HS485 USB adapter (www.elv.de) to their home automation bus system. Applies to 2.6.26. Signed-off-by:
Andre Schenk <andre@melior.s.bawue.de> Signed-off-by:
-
Frederik Kriewitz authored
commit a00c3cad upstream The Patch adds support for Luminance Stellaris Evaluation/Development Kits (FTDI 2232C based). The PIDs were missing. Successfully tested with a Stellaris LM3S8962 Evaluation kit. Signed-off-by:
Frederik Kriewitz <frederik@kriewitz.eu> Signed-off-by:
-
Alan Stern authored
commit 0282b7f2 upstream This patch (as1121) fixes a bug in the USB serial core. When a device is unregistered, the core will give back its minors -- even if the device hasn't been assigned any! The patch reserves the highest minor value (255) to mean that no minor was assigned. It also removes some dead code and does a small style fixup. Signed-off-by:
Alan Stern <stern@rowland.harvard.edu> Signed-off-by:
-
Dave Jones authored
commit b9a097f2 upstream usb-storage: quirk around v1.11 firmware on Nikon D40 https://bugzilla.redhat.com/show_bug.cgi?id=454028 Just as in earlier firmware versions, we need to perform this quirk for the latest version too. Speculatively do the entry for the D80 too, as they seem to have the same firmware problems historically. Signed-off-by:
Dave Jones <davej@redhat.com> Cc: Johannes Berg <johannes@sipsolutions.net> Cc: Alan Stern <stern@rowland.harvard.edu> Signed-off-by:
-
Alan Stern authored
commit 368ee646 upstream This patch (as1115) adds unusual_devs entries with the IGNORE_RESIDE flag for the iRiver T10 and the Simple Tech/Datafab CF+SM card reader. Apparently these devices provide reasonable residue values for READ and WRITE operations, but not for others like INQUIRY or READ CAPACITY. This fixes the iRiver T10 problem reported in Bugzilla #11125. Signed-off-by:
-
Alan Stern authored
commit 1a21175a upstream This patch (as1122) fixes a bug: When an interface is unregistered, its children (sysfs files and endpoint devices) are unregistered after it instead of before. Signed-off-by:
Kay Sievers <kay.sievers@vrfy.org> Signed-off-by:
-
Tollef Fog Heen authored
commit 8c809681 upstream USB ID 4348:5523 is handled by the ch341 driver. Remove it from the pl2023 driver. Reverts 002e8f2c. Signed-off-by:
Tollef Fog Heen <tfheen@err.no> Signed-off-by:
-
Jean Delvare authored
commit 5ede40f8 upstream I broke an error path with d03c21ec, sorry about that. The machine will crash if the i2c_attach_client() or maven_init_client() calls fail, although nobody has yet reported this happening. Signed-off-by:
Jean Delvare <khali@linux-fr.org> Acked-by:
Krzysztof Helt <krzysztof.h1@wp.pl> Cc: Petr Vandrovec <VANDROVE@vc.cvut.cz> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
David Miller authored
commit 969830b2 upstream Some chips appear to have the 2D engine hang during screen redraw, typically in a sequence of copyarea operations. This appear to be solved by adding a flush of the engine destination pixel cache and waiting for the engine to be idle before issuing the accel operation. The performance impact seems to be fairly small. Here is a trace on an RV370 (PCI device ID 0x5b64), it records the RBBM_STATUS register, then the source x/y, destination x/y, and width/height used for the copy: ---------------------------------------- radeonfb_prim_copyarea: STATUS[00000140] src[210:70] dst[210:60] wh[a0:10] radeonfb_prim_copyarea: STATUS[00000140] src[2b8:70] dst[2b8:60] wh[88:10] radeonfb_prim_copyarea: STATUS[00000140] src[348:70] dst[348:60] wh[40:10] radeonfb_prim_copyarea: STATUS[80020140] src[390:70] dst[390:60] wh[88:10] radeonfb_prim_copyarea: STATUS[8002613f] src[40:80] dst[40:70] wh[28:10] radeonfb_prim_copyarea: STATUS[80026139] src[a8:80] dst[a8:70] wh[38:10] radeonfb_prim_copyarea: STATUS[80026133] src[e8:80] dst[e8:70] wh[80:10] radeonfb_prim_copyarea: STATUS[8002612d] src[170:80] dst[170:70] wh[30:10] radeonfb_prim_copyarea: STATUS[80026127] src[1a8:80] dst[1a8:70] wh[8:10] radeonfb_prim_copyarea: STATUS[80026121] src[1b8:80] dst[1b8:70] wh[88:10] radeonfb_prim_copyarea: STATUS[8002611b] src[248:80] dst[248:70] wh[68:10] ---------------------------------------- When things are going fine the copies complete before the next ROP is even issued, but all of a sudden the 2D unit becomes active (bit 17 in RBBM_STATUS) and the FIFO retry (bit 13) and FIFO pipeline busy (bit 14) are set as well. The FIFO begins to backup until it becomes full. What happens next is the radeon_fifo_wait() times out, and we access the chip illegally leading to a bus error which usually wedges the box. None of this makes it to the console screen, of course :-) radeon_fifo_wait() should be modified to reset the accelerator when this timeout happens instead of programming the chip anyways. ---------------------------------------- radeonfb: FIFO Timeout ! ERROR(0): Cheetah error trap taken afsr[0010080005000000] afar[000007f900800e40] TL1(0) ERROR(0): TPC[595114] TNPC[595118] O7[459788] TSTATE[11009601] ERROR(0): TPC<radeonfb_copyarea+0xfc/0x248> ERROR(0): M_SYND(0), E_SYND(0), Privileged ERROR(0): Highest priority error (0000080000000000) "Bus error response from system bus" ERROR(0): D-cache idx[0] tag[0000000000000000] utag[0000000000000000] stag[0000000000000000] ERROR(0): D-cache data0[0000000000000000] data1[0000000000000000] data2[0000000000000000] data3[0000000000000000] ERROR(0): I-cache idx[0] tag[0000000000000000] utag[0000000000000000] stag[0000000000000000] u[0000000000000000] l[00\ ERROR(0): I-cache INSN0[0000000000000000] INSN1[0000000000000000] INSN2[0000000000000000] INSN3[0000000000000000] ERROR(0): I-cache INSN4[0000000000000000] INSN5[0000000000000000] INSN6[0000000000000000] INSN7[0000000000000000] ERROR(0): E-cache idx[800e40] tag[000000000e049f4c] ERROR(0): E-cache data0[fffff8127d300180] data1[00000000004b5384] data2[0000000000000000] data3[0000000000000000] Ker:xnel panic - not syncing: Irrecoverable deferred error trap. ---------------------------------------- Another quirk is that these copyarea calls will not happen until the first drivers/char/vt.c:redraw_screen() occurs. This will only happen if you 1) VC switch or 2) run "consolechars" or 3) unblank the screen. This seems to happen because until a redraw_screen() the screen scrolling method used by fbcon is not finalized yet. I've seen this with other fb drivers too. So if all you do is boot straight into X you will never see this bug on the relevant chips. Signed-off-by:
Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by:
-
Oleg Nesterov authored
commit ba661292 upstream The bug was reported and analysed by Mark McLoughlin <markmc@redhat.com>, the patch is based on his and Roland's suggestions. posix_timer_event() always rewrites the pre-allocated siginfo before sending the signal. Most of the written info is the same all the time, but memset(0) is very wrong. If ->sigq is queued we can race with collect_signal() which can fail to find this siginfo looking at .si_signo, or copy_siginfo() can copy the wrong .si_code/si_tid/etc. In short, sys_timer_settime() can in fact stop the active timer, or the user can receive the siginfo with the wrong .si_xxx values. Move "memset(->info, 0)" from posix_timer_event() to alloc_posix_timer(), change send_sigqueue() to set .si_overrun = 0 when ->sigq is not queued. It would be nice to move the whole sigq->info initialization from send to create path, but this is not easy to do without uglifying timer_create() further. As Roland rightly pointed out, we need more cleanups/fixes here, see the "FIXME" comment in the patch. Hopefully this patch makes sense anyway, and it can mask the most bad implications. Reported-by:
Mark McLoughlin <markmc@redhat.com> Signed-off-by:
Oleg Nesterov <oleg@tv-sign.ru> Cc: Mark McLoughlin <markmc@redhat.com> Cc: Oliver Pinter <oliver.pntr@gmail.com> Cc: Roland McGrath <roland@redhat.com> Cc: Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Signed-off-by:
-
Oleg Nesterov authored
commit 54da1174 upstream do_schedule_next_timer() sets info->si_overrun = timr->it_overrun_last, this discards the already accumulated overruns. Signed-off-by:
-
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:
-
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:
-
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 6 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:
-
