- 11 Aug, 2007 7 commits
-
-
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 <neilb@suse.de> Signed-off-by:
Adrian Bunk <bunk@kernel.org>
-
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 17 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:
David S. Miller <davem@davemloft.net> 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:
-
Patrick McHardy authored
When creating a new connection by sending an unknown chunk type, we don't transition to a valid state, causing a NULL pointer dereference in sctp_packet when accessing sctp_timeouts[SCTP_CONNTRACK_NONE]. Fix by don't creating new conntrack entry if initial state is invalid. Noticed by Vilmos Nebehaj <vilmos.nebehaj@ramsys.hu> Signed-off-by:
-
Andrew Morton authored
Local variable `i' is a byte-counter. Don't use it as an index into an array of le32's. Reported-by:
"young dave" <hidave.darkstar@gmail.com> Signed-off-by:
-
- 30 May, 2007 1 commit
-
-
Adrian Bunk authored
-
- 24 May, 2007 1 commit
-
-
Adrian Bunk authored
-
- 22 May, 2007 9 commits
-
-
Jamal Hadi Salim authored
This fixes an out-of-boundary condition when the classified band equals q->bands. Caught by Alexey Signed-off-by:
Jamal Hadi Salim <hadi@cyberus.ca> Signed-off-by:
-
Corey Mutter authored
Reverse the sense of the promiscuous-mode tests in ip6_mc_input(). Signed-off-by:
Corey Mutter <crm-netdev@mutternet.com> Signed-off-by:
David L Stevens <dlstevens@us.ibm.com> Signed-off-by:
-
David L Stevens authored
When an IPv6 router is forwarding a packet with a link-local scope source address off-link, RFC 4007 requires it to send an ICMPv6 destination unreachable with code 2 ("not neighbor"), but Linux doesn't. Fix below. Signed-off-by: -
Srinivas Aji authored
When the server drops its connection, NFS client reconnects using the same socket after disconnecting. If the new connection's SYN,ACK doesn't contain the TCP timestamp option and the old connection's did, tp->tcp_header_len is recomputed assuming no timestamp header but tp->rx_opt.tstamp_ok remains set. Then tcp_build_and_update_options() adds in a timestamp option past the end of the allocated TCP header, overwriting TCP data, or when the data is in skb_shinfo(skb)->frags[], overwriting skb_shinfo(skb) causing a crash soon after. (The issue was debugged from such a crash.) Similarly, wscale_ok and sack_ok also get set based on the SYN,ACK packet but not reset on disconnect, since they are zeroed out at initialization. The patch zeroes out the entire tp->rx_opt struct in tcp_disconnect() to avoid this sort of problem. Signed-off-by:
Srinivas Aji <Aji_Srinivas@emc.com> Signed-off-by:
-
Sergei Shtylyov authored
Get rid of the CONFIG_NETPOLL_RX option completely since all the dependencies have been removed long ago... Signed-off-by:
Sergei Shtylyov <sshtylyov@ru.mvista.com> Acked-by:
Jeff Garzik <jgarzik@pobox.com> Acked-by:
Matt Mackall <mpm@selenic.com> Signed-off-by:
-
Sergei Shtylyov authored
CONFIG_NETPOLL_TRAP causes the TX queue controls to be completely bypassed in the netpoll's "trapped" mode which easily causes overflows in the drivers with short TX queues (most notably, in 8139too with its 4-deep queue). So, make this option more sensible by making it only bypass the TX softirq wakeup. Signed-off-by:
Tom Rini <trini@kernel.crashing.org> Acked-by:
-
Stephen Hemminger authored
When network device's are renamed, the IPV6 snmp6 code gets confused. It doesn't track name changes so it will OOPS when network device's are removed. The fix is trivial, just unregister/re-register in notify handler. Signed-off-by:
Stephen Hemminger <shemminger@linux-foundation.org> Signed-off-by:
-
Eric Sesterhenn authored
Signed-off-by:
-
Andrew Morton authored
Keith says Compiling 2.6.19-rc6 with gcc version 4.1.0 (SUSE Linux), wait_hpet_tick is optimized away to a never ending loop and the kernel hangs on boot in timer setup. 0000001a <wait_hpet_tick>: 1a: 55 push %ebp 1b: 89 e5 mov %esp,%ebp 1d: eb fe jmp 1d <wait_hpet_tick+0x3> This is not a problem with gcc 3.3.5. Adding barrier() calls to wait_hpet_tick does not help, making the variables volatile does. And the consensus is that gcc-4.1.0 is busted. Adrian Bunk: Changed from a #warning to an #error for 2.6.16. Signed-off-by:
Andrew Morton <akpm@osdl.org> Signed-off-by:
-
- 09 May, 2007 1 commit
-
-
Adrian Bunk authored
-
- 04 May, 2007 3 commits
-
-
Adrian Bunk authored
-
Andrew Hendry authored
__x25_find_socket does a sock_hold. This adds a missing sock_put in x25_receive_data. Signed-off-by:
Andrew Hendry <andrew.hendry@gmail.com> Signed-off-by:
-
Jaroslav Kysela authored
The clusterip_config_find_get() already increases entries reference counter, so there is no reason to do it twice in checkentry() callback. This causes the config to be freed before it is removed from the list, resulting in a crash when adding the next rule. Signed-off-by:
Jaroslav Kysela <perex@suse.cz> Signed-off-by:
-
