- 13 Apr, 2007 4 commits
-
-
Stephen Hemminger authored
Driver needs to turn off carrier when down, otherwise it can confuse bonding and bridging and looks like carrier is on immediately when it is brought back up. Signed-off-by:
Stephen Hemminger <shemminger@linux-foundation.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Stephen Hemminger authored
This adds working recovery from transmit timeouts. Previous code didn't do enough to truly reset chip. It is a backport of the 2.6.21 code. Signed-off-by:
-
Thomas Gleixner authored
The __copy_to_user_inatomic() calls in file_read_actor() and pipe_read() are broken on original i386 machines, where WP-works-ok == false, as __copy_to_user_inatomic() on such systems calls functions which might sleep and/or contain cond_resched() calls inside of a kmap_atomic() region. The original check for WP-works-ok was in access_ok(), but got moved during the 2.5 series to fix a race vs. swap. Return the number of bytes to copy in the case where we are in an atomic region, so the non atomic code pathes in file_read_actor() and pipe_read() are taken. This could be optimized to avoid the kmap_atomic by moving the check for WP-works-ok into fault_in_pages_writeable(), but this is more intrusive and can be done later. Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Acked-by:
Ingo Molnar <mingo@elte.hu> Signed-off-by:
-
Jan Beulich authored
Commit 2e3646e5 changed the way the split config tree is built, but failed to also adjust fixdep accordingly - if changing a config option from or to m, files referencing the respective CONFIG_..._MODULE (but not the corresponding CONFIG_...) didn't get rebuilt. The problem is that trisate symbol are represent with three different symbols: SYMBOL=n => no symbol defined SYMBOL=y => CONFIG_SYMBOL defined to '1' SYMBOL=m => CONFIG_SYMBOL_MODULE defined to '1' But conf_split_config do not distingush between the =y and =m case, so only the =y case is honoured. This is fixed in fixdep so when a CONFIG symbol with _MODULE is found we skip that part and only look for the CONFIG_SYMBOL version. Signed-off-by:
Jan Beulich <jbeulich@novell.com> Signed-off-by:
Sam Ravnborg <sam@ravnborg.org> Signed-off-by:
-
- 06 Apr, 2007 36 commits
-
-
Chris Wright authored
-
Herbert Xu authored
In the scatterwalk_copychunks loop, We should be advancing by len_this_page and not nbytes. The latter is the total length. Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by:
Chris Wright <chrisw@sous-sol.org>
-
Paolo 'Blaisorblade' Giarrusso authored
There was a typo in commit b40b478e, preventing it from working - 32bit binaries crashed hopelessly before the below fix and work perfectly now. Signed-off-by:
Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> [chrisw: update changelog to reflect -stable commit id] Signed-off-by:
-
Greg Kroah-Hartman authored
-
Jean Delvare authored
When we receive an AppleTalk frame shorter than what its header says, we still attempt to verify its checksum, and trip on the BUG_ON() at the end of function atalk_sum_skb() because of the length mismatch. This has security implications because this can be triggered by simply sending a specially crafted ethernet frame to a target victim, effectively crashing that host. Thus this qualifies, I think, as a remote DoS. Here is the frame I used to trigger the crash, in npg format: <Appletalk Killer> { # Ethernet header ----- XX XX XX XX XX XX # Destination MAC 00 00 00 00 00 00 # Source MAC 00 1D # Length # LLC header ----- AA AA 03 08 00 07 80 9B # Appletalk # Appletalk header ----- 00 1B # Packet length (invalid) 00 01 # Fake checksum 00 00 00 00 # Destination and source networks 00 00 00 00 # Destination and source nodes and ports # Payload ----- 0C 0D 0E 0F 10 11 12 13 14 } The destination MAC address must be set to those of the victim. The severity is mitigated by two requirements: * The target host must have the appletalk kernel module loaded. I suspect this isn't so frequent. * AppleTalk frames are non-IP, thus I guess they can only travel on local networks. I am no network expert though, maybe it is possible to somehow encapsulate AppleTalk packets over IP. The bug has been reported back in June 2004: http://bugzilla.kernel.org/show_bug.cgi?id=2979 But it wasn't investigated, and was closed in July 2006 as both reporters had vanished meanwhile. This code was new in kernel 2.6.0-test5: http://git.kernel.org/?p=linux/kernel/git/tglx/history.git;a=commitdiff;h=7ab442d7e0a76402c12553ee256f756097cae2d2 And not modified since then, so we can assume that vanilla kernels 2.6.0-test5 and later, and distribution kernels based thereon, are affected. Note that I still do not know for sure what triggered the bug in the real-world cases. The frame could have been corrupted by the kernel if we have a bug hiding somewhere. But more likely, we are receiving the faulty frame from the network. Signed-off-by:Jean Delvare <jdelvare@suse.de> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Daniel Drake authored
Commit d720bc4b partially removed a private implementation of baud speed decoding. However it doesn't seem to be complete: after the speed is decoded, it is still being used as an index to a local speed table (array overrun, no doubt). This was found by Graham Murray who noticed it caused a 2.6.19 regression with the SX driver: https://bugs.gentoo.org/170554Signed-off-by:
Daniel Drake <dsd@gentoo.org> Acked-by:
Alan Cox <alan@lxorguk.ukuu.org.uk> Cc: Russell King <rmk@arm.linux.org.uk> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
-
Jeff Garzik authored
[libata] sata_mv: Fix 50xx irq mask IRQ mask bits assumed a 60xx or newer generation chip, which is very wrong for the 50xx series. Luckily both generations shared the per-port interrupt mask bits, leaving only the "misc chip features" bits to be completely mismatched. Fix 50xx by ensuring we only program bits that exist. Cc: Chuck Ebbert <cebbert@redhat.com> Signed-off-by:
Jeff Garzik <jeff@garzik.org> Signed-off-by:
-
Jeff Garzik authored
[libata] sata_mv: don't touch reserved bits in EDMA config register The code in mv_edma_cfg() reflected its 60xx origins, by doing things [slightly] incorrectly on the older 50xx and newer 6042/7042 chips. Clean up the EDMA configuration setup such that, each chip family carefully initializes its own EDMA setup. Cc: Chuck Ebbert <cebbert@redhat.com> Signed-off-by:
-
Mark Lord authored
libata bugfix: HDIO_DRIVE_TASK I was trying to use HDIO_DRIVE_TASK for something today, and discovered that the libata implementation does not copy over the upper four LBA bits from args[6]. This is serious, as any tools using this ioctl would have their commands applied to the wrong sectors on the drive, possibly resulting in disk corruption. Ideally, newer apps should use SG_IO/ATA_16 directly, avoiding this bug. But with libata poised to displace drivers/ide, better compatibility here is a must. This patch fixes libata to use the upper four LBA bits passed in from the ioctl. The original drivers/ide implementation copies over all bits except for the master/slave select bit. With this patch, libata will copy only the four high-order LBA bits, just in case there are assumptions elsewhere in libata (?). Signed-off-by:
Mark Lord <mlord@pobox.com> Cc: Chuck Ebbert <cebbert@redhat.com> Signed-off-by:
-
Tejun Heo authored
libata: clear TF before IDENTIFYing Some devices chock if Feature is not clear when IDENTIFY is issued. Set ATA_TFLAG_ISADDR | ATA_TFLAG_DEVICE for IDENTIFY such that whole TF is cleared when reading ID data. Kudos to Art Haas for testing various futile patches over several months and Mark Lord for pointing out the fix. Signed-off-by:
Tejun Heo <htejun@gmail.com> Cc: Art Haas <ahaas@airmail.net> Cc: Mark Lord <mlord@pobox.com> Cc: Chuck Ebbert <cebbert@redhat.com> Signed-off-by:
-
J. Bruce Fields authored
[CRYPTO] api: scatterwalk_copychunks() fails to advance through scatterlist In the loop in scatterwalk_copychunks(), if walk->offset is zero, then scatterwalk_pagedone rounds that up to the nearest page boundary: walk->offset += PAGE_SIZE - 1; walk->offset &= PAGE_MASK; which is a no-op in this case, so we don't advance to the next element of the scatterlist array: if (walk->offset >= walk->sg->offset + walk->sg->length) scatterwalk_start(walk, sg_next(walk->sg)); and we end up copying the same data twice. It appears that other callers of scatterwalk_{page}done first advance walk->offset, so I believe that's the correct thing to do here. This caused a bug in NFS when run with krb5p security, which would cause some writes to fail with permissions errors--for example, writes of less than 8 bytes (the des blocksize) at the start of a file. A git-bisect shows the bug was originally introduced by 5c64097a, first in 2.6.19-rc1. Cc: Chuck Ebbert <cebbert@redhat.com> Signed-off-by:J. Bruce Fields <bfields@citi.umich.edu> Signed-off-by:
-
Alan Tyson authored
[CIFS] reset mode when client notices that ATTR_READONLY is no longer set [<cebbert@redhat.com>: removed changelog part of patch] Cc: Chuck Ebbert <cebbert@redhat.com> Signed-off-by:
Alan Tyso <atyson@hp.com> Signed-off-by:
Jeff Layton <jlayton@redhat.com> Signed-off-by:
Steve French <sfrench@us.ibm.com> Signed-off-by:
-
Steve French authored
[CIFS] Allow reset of file to ATTR_NORMAL when archive bit not set When a file had a dos attribute of 0x1 (readonly - but dos attribute of archive was not set) - doing chmod 0777 or equivalent would try to set a dos attribute of 0 (which some servers ignore) rather than ATTR_NORMAL (0x20) which most servers accept. Does not affect servers which support the CIFS Unix Extensions. [<cebbert@redhat.com>: removed changelog part of patch] Cc: Chuck Ebbert <cebbert@redhat.com> Acked-by:
Prasad Potluri <pvp@us.ibm.com> Acked-by:
Shirish Pargaonkar <shirishp@us.ibm.com> Signed-off-by:
-
Bartlomiej Zolnierkiewicz authored
"ide: fix drive side 80c cable check, take 2" patch from Tejun Heo (commit fab59375) fixed 80c bit test (bit13 of word93) but we also need to fix master/slave IDENTIFY order (slave device should be probed first in order to make it release PDIAG- signal) and we should also check for pre-ATA3 slave devices (which may not release PDIAG- signal). Unfortunately the fact that IDE driver doesn't reset devices itself helps only a bit as it seems that some BIOS-es reset ATA devices after programming the chipset, some BIOS-es can be set to not probe/configure selected devices, there may be no BIOS in case of add-on cards etc. Since we are quite late in the release cycle and the required changes will affect a lot of systems just revert the fix for now. [ Please also see libata commit f31f0cc2. ] Cc: Chuck Ebbert <cebbert@redhat.com> Signed-off-by:
Bartlomiej Zolnierkiewicz <bzolnier@gmail.com> Signed-off-by:
-
Vasily Averin authored
I2O subsystem has been broken in mainstream several months ago (after 2.6.18). Commit 4aff5e23 from Jens Axboe split struct request ->flags into two parts: cmd_type and cmd_flags. In i2o layer this patch has replaced flag REQ_SPECIAL by the according cmd_type. However i2o has used REQ_SPECIAL not as command type but as driver-specific flag for the debug purposes. As result all i2o requests have type "special" now, are not processed to the hardware and fail with I/O error: i2o/hda:<3>Buffer I/O error on device i2o/hda, logical block 0 Buffer I/O error on device i2o/hda, logical block 0 Buffer I/O error on device i2o/hda, logical block 0 unable to read partition table block-osm: device added (TID: 207): i2o/hda The following patch removes the extra debug checks without any drawbacks and restores the normal driver's work. Signed-off-by:
Vasily Averin <vvs@sw.ru> Acked-by:
Markus Lidel <Markus.Lidel@shadowconnect.com> Cc: Jens Axboe <jens.axboe@oracle.com> From: Chuck Ebbert <cebbert@redhat.com> Signed-off-by:
-
Tejun Heo authored
jmicron: make ide jmicron driver play nice with libata ones When libata is configured, the device is configured such that SATA and PATA ports live in separate functions with different programming interfaces. pata_jmicron and ide jmicron drivers can drive only the PATA part. This patch makes jmicron match PCI class code such that it doesn't attach itself to the SATA part preventing the proper ahci driver from attaching. This change is suggested by Bartlomiej. Signed-off-by:
-
Oliver Endriss authored
V4L: saa7146: Fix allocation of clipping memory Olaf Hering pointed out that SAA7146_CLIPPING_MEM would become very large for PAGE_SIZE > 4K. In fact, the number of clipping windows is limited to 16, and calculate_clipping_registers_rect() does not use more than 256 bytes. SAA7146_CLIPPING_MEM adjusted accordingly. (cherry picked from commit 7a7cd192) Thanks-to: Olaf Hering <olaf@aepfle.de> Acked-by:
Michael Hunold <hunold@linuxtv.org> Signed-off-by:
Oliver Endriss <o.endriss@gmx.de> Signed-off-by:
Mauro Carvalho Chehab <mchehab@infradead.org> Signed-off-by:
Michael Krufky <mkrufky@linuxtv.org> Signed-off-by:
-
Simon Arlott authored
dvb-core: fix several locking related problems Fix several instances of dvb-core functions using mutex_lock_interruptible and returning -ERESTARTSYS where the calling function will either never retry or never check the return value. These cause a race condition with dvb_dmxdev_filter_free and dvb_dvr_release, both of which are filesystem release functions whose return value is ignored and will never be retried. When this happens it becomes impossible to open dvr0 again (-EBUSY) since it has not been released properly. (cherry picked from commit c2788502) Signed-off-by:
Simon Arlott <simon@fire.lp0.eu> Signed-off-by:
Johannes Stezenbach <js@linuxtv.org> Signed-off-by:
-
Thomas Viehweger authored
DVB: isl6421: don't reference freed memory After freeing a block there should be no reference to this block. (cherry picked from commit 09d48954) Signed-off-by:
Thomas Viehweger <Thomas.Viehweger@marconi.com> Signed-off-by:
-
Hans Verkuil authored
V4L: msp_attach must return 0 if no msp3400 was found. Returning -1 causes the probe to stop, but it should just continue instead. This patch fixes an annoying 'i2c_adapter i2c-7: Client creation failed at 0x44 (-1)' kernel message that appeared in 2.6.20 (cherry picked from commit 3284b4e0) Signed-off-by:
Hans Verkuil <hverkuil@xs4all.nl> Signed-off-by:
-
Mauro Carvalho Chehab authored
V4L: Fix SECAM handling on saa7115 (cherry picked from commit a9aaec4e) Signed-off-by:
-
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:
-
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:
-
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:
-
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:
-
