- 24 Sep, 2007 4 commits
-
-
Adrian Bunk authored
-
Ilpo Järvinen authored
It's possible that new SACK blocks that should trigger new LOST markings arrive with new data (which previously made is_dupack false). In addition, I think this fixes a case where we get a cumulative ACK with enough SACK blocks to trigger the fast recovery (is_dupack would be false there too). I'm not completely pleased with this solution because readability of the code is somewhat questionable as 'is_dupack' in SACK case is no longer about dupacks only but would mean something like 'lost_marker_work_todo' too... But because of Eifel stuff done in CA_Recovery, the FLAG_DATA_SACKED check cannot be placed to the if statement which seems attractive solution. Nevertheless, I didn't like adding another variable just for that either... :-) Signed-off-by:
Ilpo Järvinen <ilpo.jarvinen@helsinki.fi> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
Adrian Bunk <bunk@kernel.org>
-
Konstantin Sharlaimov authored
This patch addresses the issue with "osize too small" errors in mppe encryption. The patch fixes the issue with wrong output buffer size being passed to ppp decompression routine. -------------------- As pointed out by Suresh Mahalingam, the issue addressed by ppp-fix-osize-too-small-errors-when-decoding patch is not fully resolved yet. The size of allocated output buffer is correct, however it size passed to ppp->rcomp->decompress in ppp_generic.c if wrong. The patch fixes that. -------------------- Signed-off-by:
Konstantin Sharlaimov <konstantin.sharlaimov@gmail.com> Signed-off-by:
-
Konstantin Sharlaimov authored
The mppe_decompress() function required a buffer that is 1 byte too small when receiving a message of mru size. This fixes buffer allocation to prevent this from occurring. Signed-off-by:
-
- 30 Aug, 2007 3 commits
-
-
David S. Miller authored
The underflow exception cases were wrong. This is one weird area of ieee1754 handling in that the underflow behavior changes based upon whether underflow is enabled in the trap enable mask of the FPU control register. As a specific case the Sparc V9 manual gives us the following description: -------------------- If UFM = 0: Underflow occurs if a nonzero result is tiny and a loss of accuracy occurs. Tininess may be detected before or after rounding. Loss of accuracy may be either a denormalization loss or an inexact result. If UFM = 1: Underflow occurs if a nonzero result is tiny. Tininess may be detected before or after rounding. -------------------- What this amounts to in the packing case is if we go subnormal, we set underflow if any of the following are true: 1) rounding sets inexact 2) we ended up rounding back up to normal (this is the case where we set the exponent to 1 and set the fraction to zero), this should set inexact too 3) underflow is set in FPU control register trap-enable mask The initially discovered example was "DBL_MIN / 16.0" which incorrectly generated an underflow. It should not, unless underflow is set in the trap-enable mask of the FPU csr. Another example, "0x0.0000000000001p-1022 / 16.0", should signal both inexact and underflow. The cpu implementations and ieee1754 literature is very clear about this. This is case #2 above. However, if underflow is set in the trap enable mask, only underflow should be set and reported as a trap. That is handled properly by the prioritization logic in arch/sparc{,64}/math-emu/math.c:record_exception(). Based upon a report and test case from Jakub Jelinek. Signed-off-by: -
Mark Fortescue authored
__ndelay and __udelay have not been delayung >= specified time. The problem with __ndelay has been tacked down to the rounding of the multiplier constant. By changing this, delays > app 18us are correctly calculated. The problem with __udelay has also been tracked down to rounding issues. Changing the multiplier constant (to match that used in sparc64) corrects for large delays and adding in a rounding constant corrects for trunctaion errors in the claculations. Many short delays will return without looping. This is not an error as there is the fixed delay of doing all the maths to calculate the loop count. Signed-off-by:
Mark Fortescue <mark@mtfhpc.demon.co.uk> Signed-off-by:
-
Alexander Shmelev authored
Sparc optimized memset (arch/sparc/lib/memset.S) does not fill last byte of the memory area, if area size is less than 8 bytes and start address is not word (4-bytes) aligned. Here is code chunk where bug located: /* %o0 - memory address, %o1 - size, %g3 - value */ 8: add %o0, 1, %o0 subcc %o1, 1, %o1 bne,a 8b stb %g3, [%o0 - 1] This code should write byte every loop iteration, but last time delay instruction stb is not executed because branch instruction sets "annul" bit. Patch replaces bne,a by bne instruction. Error can be reproduced by simple kernel module: -------------------- #include <linux/module.h> #include <linux/config.h> #include <linux/kernel.h> #include <linux/errno.h> #include <string.h> static void do_memset(void **p, int size) { memset(p, 0x00, size); } static int __init memset_test_init(void) { char fooc[8]; int *fooi; memset(fooc, 0xba, sizeof(fooc)); do_memset((void**)(fooc + 3), 1); fooi = (int*) fooc; printk("%08X %08X\n", fooi[0], fooi[1]); return -1; } static void __exit memset_test_cleanup(void) { return; } module_init(memset_test_init); module_exit(memset_test_cleanup); MODULE_LICENSE("GPL"); EXPORT_NO_SYMBOLS; -------------------- Signed-off-by:Alexander Shmelev <ashmelev@task.sun.mcst.ru> Signed-off-by:
-
- 23 Aug, 2007 1 commit
-
-
Neil Brown authored
md/bitmap tracks how many active write requests are pending on blocks associated with each bit in the bitmap, so that it knows when it can clear the bit (when count hits zero). The counter has 14 bits of space, so if there are ever more than 16383, we cannot cope. Currently the code just calles BUG_ON as "all" drivers have request queue limits much smaller than this. However is seems that some don't. Apparently some multipath configurations can allow more than 16383 concurrent write requests. So, in this unlikely situation, instead of calling BUG_ON we now wait for the count to drop down a bit. This requires a new wait_queue_head, some waiting code, and a wakeup call. Tested by limiting the counter to 20 instead of 16383 (writes go a lot slower in that case...). Signed-off-by:
Neil Brown <neilb@suse.de> Signed-off-by:
-
- 22 Aug, 2007 7 commits
-
-
Neil Brown authored
While developing more functionality in mdadm I found some bugs in md... - When we remove a device from an inactive array (write 'remove' to the 'state' sysfs file - see 'state_store') would should not update the superblock information - as we may not have read and processed it all properly yet. - initialise all raid_disk entries to '-1' else the 'slot sysfs file will claim '0' for all devices in an array before the array is started. - all '\n' not to be present at the end of words written to sysfs files - when we use SET_ARRAY_INFO to set the md metadata version, set the flag to say that there is persistant metadata. - allow GET_BITMAP_FILE to be called on an array that hasn't been started yet. Signed-off-by:
-
Neil Brown authored
Fix few bugs that meant that: - superblocks weren't alway written at exactly the right time (this could show up if the array was not written to - writting to the array causes lots of superblock updates and so hides these errors). - restarting device recovery after a clean shutdown (version-1 metadata only) didn't work as intended (or at all). 1/ Ensure superblock is updated when a new device is added. 2/ Remove an inappropriate test on MD_RECOVERY_SYNC in md_do_sync. The body of this if takes one of two branches depending on whether MD_RECOVERY_SYNC is set, so testing it in the clause of the if is wrong. 3/ Flag superblock for updating after a resync/recovery finishes. 4/ If we find the neeed to restart a recovery in the middle (version-1 metadata only) make sure a full recovery (not just as guided by bitmaps) does get done. Signed-off-by: -
Neil Brown authored
.. so that you can use bitmaps with 32bit userspace on a 64 bit kernel. Signed-off-by:
-
Neil Brown authored
The comment gives more details, but I didn't quite have the sequencing write, so there was room for races to leave bits unset in the on-disk bitmap for short periods of time. Signed-off-by:
-
Neil Brown authored
When a device is unplugged, requests are moved from one or two (depending on whether a bitmap is in use) queues to the main request queue. So whenever requests are put on either of those queues, we should make sure the raid5 array is 'plugged'. However we don't. We currently plug the raid5 queue just before putting requests on queues, so there is room for a race. If something unplugs the queue at just the wrong time, requests will be left on the queue and nothing will want to unplug them. Normally something else will plug and unplug the queue fairly soon, but there is a risk that nothing will. Signed-off-by:
-
Neil Brown authored
We introduced 'io_sectors' recently so we could count the sectors that causes io during resync separate from sectors which didn't cause IO - there can be a difference if a bitmap is being used to accelerate resync. However when a speed is reported, we find the number of sectors processed recently by subtracting an oldish io_sectors count from a current 'curr_resync' count. This is wrong because curr_resync counts all sectors, not just io sectors. So, add a field to mddev to store the curren io_sectors separately from curr_resync, and use that in the calculations. Signed-off-by:
-
Neil Brown authored
When an array has a bitmap, a device can be removed and re-added and only blocks changes since the removal (as recorded in the bitmap) will be resynced. It should be possible to do a similar thing to arrays without bitmaps. i.e. if a device is removed and re-added and *no* changes have been made in the interim, then the add should not require a resync. This patch allows that option. This means that when assembling an array one device at a time (e.g. during device discovery) the array can be enabled read-only as soon as enough devices are available, but extra devices can still be added without causing a resync. Signed-off-by:
-
- 11 Aug, 2007 9 commits
-
-
Neil Brown authored
md/bitmap modifies i_writecount of a bitmap file to make sure that no-one else writes to it. The reverting of the change is sometimes done twice, and there is one error path where it is omitted. This patch tidies that up. Signed-off-by:
-
Neil Brown authored
bitmap_active is never called, and the BITMAP_ACTIVE flag is never users or tested, so discard them both. Also remove some out-of-date 'todo' comments. Signed-off-by:
-
Neil Brown authored
md/bitmap gets a collection of pages representing the bitmap when it initialises the bitmap, and puts all the references when discarding the bitmap. It also occasionally takes extra references without any good reason, and sometimes drops them ... though it doesn't always drop them, which can result in a memory leak. This patch removes the unnecessary 'get_page' calls, and the corresponding 'put_page' calls. Signed-off-by:
-
Neil Brown authored
In particular, this means that we use 4 bits per page instead of a whole unsigned long. Signed-off-by:
-
Neil Brown authored
md/bitmap has some attributes per-page. Handling of these attributes in largely abstracted in set_page_attr and clear_page_attr. However get_page_attr exposes the format used to store them. So prior to changing that format, introduce test_page_attr instead of get_page_attr, and make appropriate usage changes. Signed-off-by:
-
Neil Brown authored
When "mdadm --grow /dev/mdX --bitmap=none" is used to remove a filebacked bitmap, the bitmap was disconnected from the array, but the file wasn't closed (until the array was stopped). The file also wasn't closed if adding the bitmap file failed. Signed-off-by:
-
Neil Brown authored
Currently a device failure during recovery leaves bits set in the bitmap. This normally isn't a problem as the offending device will be rejected because of errors. However if device re-adding is being used with non-persistent bitmaps, this can be a problem. Signed-off-by:
-
Neil Brown authored
I really should make this a function of the personality.... Signed-off-by:
-
James Bottomley authored
There's a bug in the MCA bus matching algorithm in that it promotes from signed short to int before comparing with the actual id and does sign extension on anything > 0x7fff (which means that pos ids > 0x7fff never get correctly matched). Signed-off-by:
James Bottomley <James.Bottomley@SteelEye.com> Signed-off-by:
-
- 25 Jul, 2007 1 commit
-
-
Adrian Bunk authored
-
- 22 Jul, 2007 15 commits
-
-
Adrian Bunk authored
-
Dmitry Butskoy authored
Taken from http://bugzilla.kernel.org/show_bug.cgi?id=8747 Problem Description: It is related to the possibility to obtain MSG_ERRQUEUE messages from the udp and raw sockets, both connected and unconnected. There is a little typo in net/ipv6/icmp.c code, which prevents such messages to be delivered to the errqueue of the correspond raw socket, when the socket is CONNECTED. The typo is due to swap of local/remote addresses. Consider __raw_v6_lookup() function from net/ipv6/raw.c. When a raw socket is looked up usual way, it is something like: sk = __raw_v6_lookup(sk, nexthdr, daddr, saddr, IP6CB(skb)->iif); where "daddr" is a destination address of the incoming packet (IOW our local address), "saddr" is a source address of the incoming packet (the remote end). But when the raw socket is looked up for some icmp error report, in net/ipv6/icmp.c:icmpv6_notify() , daddr/saddr are obtained from the echoed fragment of the "bad" packet, i.e. "daddr" is the original destination address of that packet, "saddr" is our local address. Hence, for icmpv6_notify() must use "saddr, daddr" in its arguments, not "daddr, saddr" ... Steps to reproduce: Create some raw socket, connect it to an address, and cause some error situation: f.e. set ttl=1 where the remote address is more than 1 hop to reach. Set IPV6_RECVERR . Then send something and wait for the error (f.e. poll() with POLLERR|POLLIN). You should receive "time exceeded" icmp message (because of "ttl=1"), but the socket do not receive it. If you do not connect your raw socket, you will receive MSG_ERRQUEUE successfully. (The reason is that for unconnected socket there are no actual checks for local/remote addresses). Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Adrian Bunk <bunk@stusta.de>
-
Patrick McHardy authored
As noticed by Jarek Poplawski <jarkao2@o2.pl>, the timer removal in gen_kill_estimator races with the timer function rearming the timer. Check whether the timer list is empty before rearming the timer in the timer function to fix this. Signed-off-by:
Patrick McHardy <kaber@trash.net> Acked-by:
Jarek Poplawski <jarkao2@o2.pl> Signed-off-by:
-
Vlad Yasevich authored
SCTP currently permits users to bind to link-local addresses, but doesn't verify that the scope id specified at bind matches the interface that the address is configured on. It was report that this can hang a system. Signed-off-by:
Vlad Yasevich <vladislav.yasevich@hp.com> Signed-off-by:
-
Johannes Berg authored
skb_clone_fraglist is static so it shouldn't be exported. Signed-off-by:
Johannes Berg <johannes@sipsolutions.net> Signed-off-by:
-
Yasuyuki Kozakai authored
The conntrack assigned to locally generated ICMP error is usually the one assigned to the original packet which has caused the error. But if the original packet is handled as invalid by nf_conntrack, no conntrack is assigned to the original packet. Then nf_ct_attach() cannot assign any conntrack to the ICMP error packet. In that case the current nf_conntrack_icmp assigns appropriate conntrack to it. But the current code mistakes the direction of the packet. As a result, NAT code mistakes the address to be mangled. To fix the bug, this changes nf_conntrack_icmp not to assign conntrack to such ICMP error. Actually no address is necessary to be mangled in this case. Spotted by Jordan Russell. Upstream commit ID: 130e7a83Signed-off-by:
Yasuyuki Kozakai <yasuyuki.kozakai@toshiba.co.jp> Signed-off-by:
-
Albert Lee authored
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:
Albert Lee <albertcc@tw.ibm.com> Signed-off-by:
-
Ingo Molnar authored
fix deadlock in the 8139too driver: poll handlers should never forcibly enable local interrupts, because they might be used by netpoll/printk from IRQ context. ================================= [ INFO: inconsistent lock state ] 2.6.19 #11 --------------------------------- inconsistent {softirq-on-W} -> {in-softirq-W} usage. swapper/1 [HC0[0]:SC1[1]:HE1:SE0] takes: (&npinfo->poll_lock){-+..}, at: [<c0350a41>] net_rx_action+0x64/0x1de {softirq-on-W} state was registered at: [<c0134c86>] mark_lock+0x5b/0x39c [<c0135012>] mark_held_locks+0x4b/0x68 [<c01351e9>] trace_hardirqs_on+0x115/0x139 [<c02879e6>] rtl8139_poll+0x3d7/0x3f4 [<c035c85d>] netpoll_poll+0x82/0x32f [<c035c775>] netpoll_send_skb+0xc9/0x12f [<c035cdcc>] netpoll_send_udp+0x253/0x25b [<c0288463>] write_msg+0x40/0x65 [<c011cead>] __call_console_drivers+0x45/0x51 [<c011cf16>] _call_console_drivers+0x5d/0x61 [<c011d4fb>] release_console_sem+0x11f/0x1d8 [<c011d7d7>] register_console+0x1ac/0x1b3 [<c02883f8>] init_netconsole+0x55/0x67 [<c010040c>] init+0x9a/0x24e [<c01049cf>] kernel_thread_helper+0x7/0x10 [<ffffffff>] 0xffffffff irq event stamp: 819992 hardirqs last enabled at (819992): [<c0350a16>] net_rx_action+0x39/0x1de hardirqs last disabled at (819991): [<c0350b1e>] net_rx_action+0x141/0x1de softirqs last enabled at (817552): [<c01214e4>] __do_softirq+0xa3/0xa8 softirqs last disabled at (819987): [<c0106051>] do_softirq+0x5b/0xc9 other info that might help us debug this: no locks held by swapper/1. stack backtrace: [<c0104d88>] dump_trace+0x63/0x1e8 [<c0104f26>] show_trace_log_lvl+0x19/0x2e [<c010532d>] show_trace+0x12/0x14 [<c0105343>] dump_stack+0x14/0x16 [<c0134980>] print_usage_bug+0x23c/0x246 [<c0134d33>] mark_lock+0x108/0x39c [<c01356a7>] __lock_acquire+0x361/0x9ed [<c0136018>] lock_acquire+0x56/0x72 [<c03aff1f>] _spin_lock+0x35/0x42 [<c0350a41>] net_rx_action+0x64/0x1de [<c0121493>] __do_softirq+0x52/0xa8 [<c0106051>] do_softirq+0x5b/0xc9 [<c0121338>] irq_exit+0x3c/0x48 [<c0106163>] do_IRQ+0xa4/0xbd [<c01047c6>] common_interrupt+0x2e/0x34 [<c011db92>] vprintk+0x2c0/0x309 [<c011dbf6>] printk+0x1b/0x1d [<c01003f2>] init+0x80/0x24e [<c01049cf>] kernel_thread_helper+0x7/0x10 ======================= Signed-off-by:Ingo Molnar <mingo@elte.hu> Signed-off-by:
-
Al Viro authored
Going through the string and waiting for _pointer_ to become '\0' is not what the authors meant... Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk> Acked-by:
Ben Collins <ben.collins@ubuntu.com> Signed-off-by:
-
Al Viro authored
Shows how many people are testing coda - the bug had been there for 5 years and results of stepping on it are not subtle. Signed-off-by:
-
Mark Glines authored
This diff changes the default port range used for outgoing connections, from "use 32768-61000 in most cases, but use N-4999 on small boxes (where N is a multiple of 1024, depending on just *how* small the box is)" to just "use 32768-61000 in all cases". I don't believe there are any drawbacks to this change, and it keeps outgoing connection ports farther away from the mess of IANA-registered ports. Signed-off-by:
Mark Glines <mark@glines.org> Signed-off-by:
-
Vasily Averin authored
sys_setsockopt() do not check properly timeout values for SO_RCVTIMEO/SO_SNDTIMEO, for example it's possible to set negative timeout values. POSIX do not defines behaviour for sys_setsockopt in case negative timeouts, but requires that setsockopt() shall fail with -EDOM if the send and receive timeout values are too big to fit into the timeout fields in the socket structure. In current implementation negative timeout can lead to error messages like "schedule_timeout: wrong timeout value". Proposed patch: - checks tv_usec and returns -EDOM if it is wrong - do not allows to set negative timeout values (sets 0 instead) and outputs ratelimited information message about such attempts. Signed-off-By:
Vasily Averin <vvs@sw.ru> Signed-off-by:
-
Jan Engelhardt authored
The Linux kernel ignored the PROM's serial settings (115200,n,8,1 in my case). This was because mode_prop remained "ttyX-mode" (expected: "ttya-mode") due to the constness of string literals when used with "char *". Since there is no "ttyX-mode" property in the PROM, Linux always used the default 9600. [ Investigation of the suncore.s assembler reveals that gcc optimizied away the stores, yet did not emit a warning, which is a pretty anti-social thing to do and is the only reason this bug lived for so long -DaveM ] Signed-off-by:
Jan Engelhardt <jengelh@gmx.de> Signed-off-by:
-
Dave Jones authored
As mentioned in http://bugzilla.kernel.org/show_bug.cgi?id=5015 The helptext implies that this is on by default. This may be true on some distros (Fedora/RHEL have it enabled in /etc/sysctl.conf), but the kernel defaults to it off. Signed-off-by:
Dave Jones <davej@redhat.com> Signed-off-by:
-
David S. Miller authored
Noticed by Matvejchikov Ilya. Signed-off-by:
-
