- 06 Apr, 2007 22 commits
-
-
Mauro Carvalho Chehab authored
V4L: Fix SECAM handling on saa7115 (cherry picked from commit a9aaec4e) Signed-off-by:
Mauro Carvalho Chehab <mchehab@infradead.org> Signed-off-by:
Michael Krufky <mkrufky@linuxtv.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Trent Piepho authored
V4L: radio: Fix error in Kbuild file All the radio drivers need video_dev, but they were depending on VIDEO_DEV!=n. That meant that one could try to compile the driver into the kernel when VIDEO_DEV=m, which will not work. If video_dev is a module, then the radio drivers must be modules too. (cherry picked from commit b10fece5) Signed-off-by:
Trent Piepho <xyzzy@speakeasy.org> Signed-off-by:
-
Michael Krufky authored
DVB: fix nxt200x rf input switching After dvb tuner refactoring, the pll buffer has been altered such that the pll address is now stored in buf[0]. Instead of sending buf to set_pll_input, we should send buf+1. (cherry picked from commit f5ae29e2) Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Thomas Graf authored
[NET]: Fix fib_rules compatibility breakage Based upon a patch from Patrick McHardy. The fib_rules netlink attribute policy introduced in 2.6.19 broke userspace compatibilty. When specifying a rule with "from all" or "to all", iproute adds a zero byte long netlink attribute, but the policy requires all addresses to have a size equal to sizeof(struct in_addr)/sizeof(struct in6_addr), resulting in a validation error. Check attribute length of FRA_SRC/FRA_DST in the generic framework by letting the family specific rules implementation provide the length of an address. Report an error if address length is non zero but no address attribute is provided. Fix actual bug by checking address length for non-zero instead of relying on availability of attribute. Signed-off-by:
Thomas Graf <tgraf@suug.ch> Signed-off-by:
Patrick McHardy <kaber@trash.net> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Al Viro authored
Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
-
Mikael Pettersson authored
[SPARC]: sparc64 gcc-4.2.0 20070317 -Werror failure Compiling 2.6.21-rc5 with gcc-4.2.0 20070317 (prerelease) for sparc64 fails as follows: gcc -Wp,-MD,arch/sparc64/kernel/.time.o.d -nostdinc -isystem /home/mikpe/pkgs/linux-sparc64/gcc-4.2.0/lib/gcc/sparc64-unknown-linux-gnu/4.2.0/include -D__KERNEL__ -Iinclude -include include/linux/autoconf.h -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -Os -m64 -pipe -mno-fpu -mcpu=ultrasparc -mcmodel=medlow -ffixed-g4 -ffixed-g5 -fcall-used-g7 -Wno-sign-compare -Wa,--undeclared-regs -fomit-frame-pointer -fno-stack-protector -Wdeclaration-after-statement -Wno-pointer-sign -Werror -D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR(time)" -D"KBUILD_MODNAME=KBUILD_STR(time)" -c -o arch/sparc64/kernel/time.o arch/sparc64/kernel/time.c cc1: warnings being treated as errors arch/sparc64/kernel/time.c: In function 'kick_start_clock': arch/sparc64/kernel/time.c:559: warning: overflow in implicit constant conversion make[1]: *** [arch/sparc64/kernel/time.o] Error 1 make: *** [arch/sparc64/kernel] Error 2 gcc gets unhappy when the MSTK_SET macro's u8 __val variable is updated with &= ~0xff (MSTK_YEAR_MASK). Making the constant unsigned fixes the problem. [ I fixed up the sparc32 side as well -DaveM ] Signed-off-by:
Mikael Pettersson <mikpe@it.uu.se> Signed-off-by:
-
Alexey Dobriyan authored
[NET]: Correct accept(2) recovery after sock_attach_fd() * d_alloc() in sock_attach_fd() fails leaving ->f_dentry of new file NULL * bail out to out_fd label, doing fput()/__fput() on new file * but __fput() assumes valid ->f_dentry and dereferences it Signed-off-by:
Alexey Dobriyan <adobriyan@sw.ru> Signed-off-by:
-
David Miller authored
[VIDEO] ffb: Fix two DAC handling bugs. The determination of whether the DAC has inverted cursor logic is broken, import the version checks the X.org driver uses to fix this. Next, when we change the timing generator, borrow code from X.org that does 10 NOP reads of the timing generator register afterwards to make sure the video-enable transition occurs cleanly. Finally, use macros for the DAC registers and fields in order to provide documentation for the next person who reads this code. Signed-off-by:
-
Arnaldo Carvalho de Melo authored
[DCCP] getsockopt: Fix DCCP_SOCKOPT_[SEND,RECV]_CSCOV We were only checking if there was enough space to put the int, but left len as specified by the (malicious) user, sigh, fix it by setting len to sizeof(val) and transfering just one int worth of data, the one asked for. Also check for negative len values. Signed-off-by:
Arnaldo Carvalho de Melo <acme@ghostprotocols.net> Signed-off-by:
-
G. Liakhovetski authored
[PPP]: Don't leak an sk_buff on interface destruction. Signed-off-by:
G. Liakhovetski <gl@dsa-ac.de> Acked-by:
Paul Mackerras <paulus@samba.org> Signed-off-by:
-
David Miller authored
[IPV6]: Fix routing round-robin locking. As per RFC2461, section 6.3.6, item #2, when no routers on the matching list are known to be reachable or probably reachable we do round robin on those available routes so that we make sure to probe as many of them as possible to detect when one becomes reachable faster. Each routing table has a rwlock protecting the tree and the linked list of routes at each leaf. The round robin code executes during lookup and thus with the rwlock taken as a reader. A small local spinlock tries to provide protection but this does not work at all for two reasons: 1) The round-robin list manipulation, as coded, goes like this (with read lock held): walk routes finding head and tail spin_lock(); rotate list using head and tail spin_unlock(); While one thread is rotating the list, another thread can end up with stale values of head and tail and then proceed to corrupt the list when it gets the lock. This ends up causing the OOPS in fib6_add() later onthat many people have been hitting. 2) All the other code paths that run with the rwlock held as a reader do not expect the list to change on them, they expect it to remain completely fixed while they hold the lock in that way. So, simply stated, it is impossible to implement this correctly using a manipulation of the list without violating the rwlock locking semantics. Reimplement using a per-fib6_node round-robin pointer. This way we don't need to manipulate the list at all, and since the round-robin pointer can only ever point to real existing entries we don't need to perform any locking on the changing of the round-robin pointer itself. We only need to reset the round-robin pointer to NULL when the entry it is pointing to is removed. The idea is from Thomas Graf and it is very similar to how this was implemented before the advanced router selection code when in. Signed-off-by: -
Patrick McHardy authored
[NET_SCHED]: Fix ingress locking Ingress queueing uses a seperate lock for serializing enqueue operations, but fails to properly protect itself against concurrent changes to the qdisc tree. Use queue_lock for now since the real fix it quite intrusive. Signed-off-by:
-
Patrick McHardy authored
[NET_SCHED]: cls_basic: fix NULL pointer dereference cls_basic doesn't allocate tp->root before it is linked into the active classifier list, resulting in a NULL pointer dereference when packets hit the classifier before its ->change function is called. Reported by Chris Madden <chris@reflexsecurity.com> Signed-off-by:
-
Stefan Richter authored
Fix NULL pointer dereference on hot ejection of a FireWire card while dv1394 was loaded. http://bugzilla.kernel.org/show_bug.cgi?id=7121 I did not test card ejection with open /dev/dv1394 files yet. Signed-off-by:
Stefan Richter <stefanr@s5r6.in-berlin.de> Signed-off-by:
-
Paolo 'Blaisorblade' Giarrusso authored
Currently we have a confused udelay implementation. * __const_udelay does not accept usecs but xloops in i386 and x86_64 * our implementation requires usecs as arg * it gets a xloops count when called by asm/arch/delay.h Bugs related to this (extremely long shutdown times) where reported by some x86_64 users, especially using Device Mapper. To hit this bug, a compile-time constant time parameter must be passed - that's why UML seems to work most times. Fix this with a simple udelay implementation. Signed-off-by:
Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it> Signed-off-by:
-
Jeff Dike authored
This patch uses MAX_REG_NR consistently to refer to the register file size. FRAME_SIZE isn't sufficient because on x86_64, it is smaller than the ptrace register file size. MAX_REG_NR was introduced as a consistent way to get the number of registers, but wasn't used everywhere it should be. When this causes a problem, it makes PTRACE_SETREGS fail on x86_64 because of a corrupted segment register value in the known-good register file. The patch also adds a register dump at that point in case there are any future problems here. Signed-off-by:
Jeff Dike <jdike@linux.intel.com> Signed-off-by:
-
Jeff Dike authored
During a static link, ld has started putting a .note section in the .uml.setup.init section. This has the result that the UML setups begin with 32 bytes of garbage and UML crashes immediately on boot. This patch creates a specific .note section for ld to drop this stuff into. Signed-off-by:
-
Jeff Dike authored
This fixes a problem seen by a number of people running UML on newer host kernels. init would hang with an infinite segfault loop. It turns out that the host kernel was providing a AT_SYSINFO_EHDR of 0xffffe000, which faked UML into believing that the host VDSO page could be reused. However, AT_SYSINFO pointed into the middle of the address space, and was unmapped as a result. Because UML was providing AT_SYSINFO_EHDR and AT_SYSINFO to its own processes, these would branch to nowhere when trying to use the VDSO. The fix is to also check the location of AT_SYSINFO when deciding whether to use the host's VDSO. Signed-off-by:
-
Jeff Dike authored
UML/x86_64 needs the same packing of struct epoll_event as x86_64. Signed-off-by:
-
Robert Hancock authored
sata_nv: delay on switching between NCQ and non-NCQ commands This patch appears to solve some problems with commands timing out in cases where an NCQ command is immediately followed by a non-NCQ command (or possibly vice versa). This is a rather ugly solution, but until we know more about why this is needed, this is about all we can do. [backport to 2.6.20 by Chuck Ebbert <cebbert@redhat.com>] Signed-off-by:
Robert Hancock <hancockr@shaw.ca> Cc: Chuck Ebbert <cebbert@redhat.com> Signed-off-by:
Jeff Garzik <jeff@garzik.org> Signed-off-by:
-
Albert Lee authored
ide: remove clearing bmdma status from cdrom_decode_status() (rev #4) patch 2/2: Remove clearing bmdma status from cdrom_decode_status() since ATA devices might need it as well. (http://lkml.org/lkml/2006/12/4/201 and http://lkml.org/lkml/2006/11/15/94) Signed-off-by:
Albert Lee <albertcc@tw.ibm.com> Cc: Sergei Shtylyov <sshtylyov@ru.mvista.com> Cc: Alan Cox <alan@lxorguk.ukuu.org.uk> Cc: "Adam W. Hawks" <awhawks@us.ibm.com> Cc: Chuck Ebbert <cebbert@redhat.com> Signed-off-by:
Bartlomiej Zolnierkiewicz <bzolnier@gmail.com> Signed-off-by:
-
Albert Lee authored
ide: clear bmdma status in ide_intr() for ICHx controllers (revised #4) patch 1/2 (revised): - Fix drive->waiting_for_dma to work with CDB-intr devices. - Do the dma status clearing in ide_intr() and add a new hwif->ide_dma_clear_irq for Intel ICHx controllers. Revised per Alan, Sergei and Bart's advice. Patch against 2.6.20-rc6. Tested ok on my ICH4 and pdc20275 adapters. Please review/apply, thanks. Signed-off-by:
-
- 23 Mar, 2007 18 commits
-
-
Greg Kroah-Hartman authored
-
David Miller authored
[SPARC64]: store-init needs trailing membar. The manual says that it is required and we actually have crash reports where loads see stale data due to not having membars here. In one case the networking does: memset(skb, 0, offsetof(struct sk_buff, truesize)); and then some code later checks skb->nohdr for zero, but it's still the value that was there before the memset(). Note that arch/sparc64/lib/xor.S already got this right. Signed-off-by:
-
Kai Makisara authored
[SCSI] st: fix Tape dies if wrong block size used, bug 7919 On Thu, 1 Feb 2007, Andrew Morton wrote: > On Thu, 1 Feb 2007 15:34:29 -0800 > bugme-daemon@bugzilla.kernel.org wrote: > > > http://bugzilla.kernel.org/show_bug.cgi?id=7919 > > > > Summary: Tape dies if wrong block size used > > Kernel Version: 2.6.20-rc5 > > Status: NEW > > Severity: normal > > Owner: scsi_drivers-other@kernel-bugs.osdl.org > > Submitter: dmartin@sccd.ctc.edu > > > > > > Most recent kernel where this bug did *NOT* occur: 2.6.17.14 > > > > Other Kernels Tested and Results: > > > > OK 2.6.15.7 > > OK 2.6.16.37 > > OK 2.6.17.14 > > BAD 2.6.18.6 > > BAD 2.6.18-1.2869.fc6 > > BAD 2.6.19.2 + > > BAD 2.6.20-rc5 > > > > NOTE: 2.6.18-1.2869.fc6 is a Fedora modified kernel, all others are from kernel.org > > ... > > Steps to reproduce: > > Get a Adaptec AHA-2940U/UW/D / AIC-7881U card and a tape drive, > > install a recent kernel > > set the tape block size - mt setblk 4096 > > read from or write to tape using wrong block size - tar -b 7 -cvf /dev/tape foo > > Write does not trigger this bug because the driver refuses in fixed block mode writes that are not a multiple of the block size. Read does trigger it in my system. The bug is not associated with any specific HBA. st tries to do direct i/o in fixed block mode with reads that are not a multiple of tape block size. The patch in this message fixes the st problem by switching to using the driver buffer up to the next close of the device file in fixed block mode if the user asks for a read like this. I don't know why the bug has surfaced only after 2.6.17 although the st problem is old. There may be another bug in the block subsystem and this patch works around it. However, the patch fixes a problem in st and in this way it is a valid fix. This patch may also fix the bug 7900. The patch compiles and is lightly tested. Signed-off-by:
Kai Makisara <kai.makisara@kolumbus.fi> Cc: Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
James Bottomley <James.Bottomley@SteelEye.com> Signed-off-by:
-
Dmitry Torokhov authored
Do not assume that AUX_LOOP command is broken unless it completes successfully but returns wrong (unexpected) data. Cc: Chuck Ebbert <cebbert@redhat.com> Signed-off-by:
Dmitry Torokhov <dtor@mail.ru> Signed-off-by:
-
Jeff Dike authored
x86_64 needs some TLS fixes. What was missing was remembering the child thread id during clone and stuffing it into the child during each context switch. The %fs value is stored separately in the thread structure since the host controls what effect it has on the actual register file. The host also needs to store it in its own thread struct, so we need the value kept outside the register file. arch_prctl_skas was fixed to call PTRACE_ARCH_PRCTL appropriately. There is some saving and restoring of registers in the ARCH_SET_* cases so that the correct set of registers are changed on the host and restored to the process when it runs again. Signed-off-by:
Jeff Dike <jdike@addtoit.com> Signed-off-by:
-
Al Viro authored
GFP_KERNEL allocations in non-blocking context; fixed by killing an idiotic use of security_getprocattr(). Acked-by:
Stephen Smalley <sds@tycho.nsa.gov> Acked-by:
James Morris <jmorris@namei.org> Cc: Chuck Ebbert <cebbert@redhat.com> Signed-off-by:
-
Dmitry Torokhov authored
Input: i8042 - fix AUX IRQ delivery check On boxes that do not implement AUX LOOP command we can not verify AUX IRQ delivery and must assume that it is wired properly. Cc: Chuck Ebbert <cebbert@redhat.com> Signed-off-by:
-
Zach Brown authored
This patch fixes a user-triggerable oops that was reported by Leonid Ananiev as archived at http://lkml.org/lkml/2007/2/8/337. dio writes invalidate clean pages that intersect the written region so that subsequent buffered reads go to disk to read the new data. If this fails the interface tries to tell the caller that the cache is inconsistent by returning EIO. Before this patch we had the problem where this invalidation failure would clobber -EIOCBQUEUED as it made its way from fs/direct-io.c to fs/aio.c. Both fs/aio.c and bio completion call aio_complete() and we reference freed memory, usually oopsing. This patch addresses this problem by invalidating before the write so that we can cleanly return -EIO before ->direct_IO() has had a chance to return -EIOCBQUEUED. There is a compromise here. During the dio write we can fault in mmap()ed pages which intersect the written range with get_user_pages() if the user provided them for the source buffer. This is a crazy thing to do, but we can make it mostly work in most cases by trying the invalidation again. The compromise is that we won't return an error if this second invalidation fails if it's an AIO write and we have -EIOCBQUEUED. This was tested by having two processes race performing large O_DIRECT and buffered ordered writes. Within minutes ext3 would see a race between ext3_releasepage() and jbd holding a reference on ordered data buffers and would cause invalidation to fail, panicing the box. The test can be found in the 'aio_dio_bugs' test group in test.kernel.org/autotest. After this patch the test passes. Signed-off-by:
Zach Brown <zach.brown@oracle.com> Signed-off-by:
Benjamin LaHaise <bcrl@kvack.org> Cc: Chuck Ebbert <cebbert@redhat.com> Cc: Leonid Ananiev <leonid.i.ananiev@linux.intel.com> Cc: Nick Piggin <nickpiggin@yahoo.com.au> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
-
Ankita Garg authored
Looking at oom_kill.c, found that the intention to not kill the selected process if any of its children/siblings has OOM_DISABLE set, is not being met. Signed-off-by:
Ankita Garg <ankita@in.ibm.com> Cc: Chuck Ebbert <cebbert@redhat.com> Acked-by:
Nick Piggin <npiggin@suse.de> Acked-by:
William Irwin <wli@holomorphy.com> Signed-off-by:
-
Takashi Iwai authored
[ALSA] hda-intel - Fix codec probe with ATI contorllers ATI controllers may have up to 4 codecs while ICH up to 3. Thus the earlier fix to change AZX_MAX_CODECS to 3 cause a regression on some devices that have the audio codec at bit#3. Now max codecs is defined according to the driver type, either 3 or 4. Currently 4 is set only to ATI chips. Other might need the same change, too. Cc: Chuck Ebbert <cebbert@redhat.com> Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
Jaroslav Kysela <perex@suse.cz>
-
Dmitry Torokhov authored
Input: i8042 - really suppress ACK/NAK during panic blink On some boxes panic blink procedure manages to send both bytes to keyboard contoller before getting first ACK so we need to make i8042_suppress_kbd_ack a counter instead of boolean. Cc: Chuck Ebbert <cebbert@redhat.com> Signed-off-by:
-
Samuel Ortiz authored
Without this initialization one gets kernel BUG at kernel/rtmutex_common.h:80! This patch should also be included in the -stable kernel. Signed-off-by:
Samuel Ortiz <samuel@sortiz.org> Cc: David Miller <davem@davemloft.net> Signed-off-by:
-
David Miller authored
[SPARC64]: Get DEBUG_PAGEALLOC working again. We have to make sure to use base-pagesize TLB entries even during the early transition period where we need TLB miss handling but don't have the kernel page tables setup yet for the linear region. Also, it is necessary therefore to not use the 4MB TSB for these translations, and instead use the normal kernel TSB. This allows us to also get rid of the 4MB tsb for debug builds which shrinks the kernel a little bit. Signed-off-by:
-
David Miller authored
[SPARC64]: Add missing HPAGE_MASK masks on address parameters. These pte loops all assume the passed in address is HPAGE aligned, make sure that is actually true. Signed-off-by:
-
Alexey Dobriyan authored
[NET]: Copy mac_len in skb_clone() as well ANK says: "It is rarely used, that's wy it was not noticed. But in the places, where it is used, it should be disaster." Signed-off-by:
-
Masayuki Nakagawa authored
[IPV6]: ipv6_fl_socklist is inadvertently shared. The ipv6_fl_socklist from listening socket is inadvertently shared with new socket created for connection. This leads to a variety of interesting, but fatal, bugs. For example, removing one of the sockets may lead to the other socket's encountering a page fault when the now freed list is referenced. The fix is to not share the flow label list with the new socket. Signed-off-by:
Masayuki Nakagawa <nakagawa.msy@ncos.nec.co.jp> Signed-off-by:
-
Robert Olsson authored
[IPV4]: Do not disable preemption in trie_leaf_remove(). Hello, Just discussed this Patrick... We have two users of trie_leaf_remove, fn_trie_flush and fn_trie_delete both are holding RTNL. So there shouldn't be need for this preempt stuff. This is assumed to a leftover from an older RCU-take. > Mhh .. I think I just remembered something - me incorrectly suggesting > to add it there while we were talking about this at OLS :) IIRC the > idea was to make sure tnode_free (which at that time didn't use > call_rcu) wouldn't free memory while still in use in a rcu read-side > critical section. It should have been synchronize_rcu of course, > but with tnode_free using call_rcu it seems to be completely > unnecessary. So I guess we can simply remove it. Signed-off-by:
Robert Olsson <robert.olsson@its.uu.se> Signed-off-by:
-
Joy Latten authored
[XFRM]: Fix missing protocol comparison of larval SAs. I noticed that in xfrm_state_add we look for the larval SA in a few places without checking for protocol match. So when using both AH and ESP, whichever one gets added first, deletes the larval SA. It seems AH always gets added first and ESP is always the larval SA's protocol since the xfrm->tmpl has it first. Thus causing the additional km_query() Adding the check eliminates accidental double SA creation. Signed-off-by:
Joy Latten <latten@austin.ibm.com> Signed-off-by:
-
