- 18 Mar, 2010 10 commits
-
-
git://oss.sgi.com/xfs/xfsLinus Torvalds authored
* 'for-linus' of git://oss.sgi.com/xfs/xfs: xfs: don't warn about page discards on shutdown xfs: use scalable vmap API xfs: remove old vmap cache
-
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6Linus Torvalds authored
* git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6: (39 commits) gigaset: fix build failure bridge: Make first arg to deliver_clone const. bridge br_multicast: Don't refer to BR_INPUT_SKB_CB(skb)->mrouters_only without IGMP snooping. route: Fix caught BUG_ON during rt_secret_rebuild_oneshot() bridge br_multicast: Fix skb leakage in error path. bridge br_multicast: Fix handling of Max Response Code in IGMPv3 message. NET: netpoll, fix potential NULL ptr dereference tipc: fix lockdep warning on address assignment l2tp: Fix UDP socket reference count bugs in the pppol2tp driver smsc95xx: wait for PHY to complete reset during init l2tp: Fix oops in pppol2tp_xmit smsc75xx: SMSC LAN75xx USB gigabit ethernet adapter driver ne: Do not use slashes in irq name string NET: ksz884x, fix lock imbalance gigaset: correct range checking off by one error bridge: Fix br_forward crash in promiscuous mode bridge: Move NULL mdb check into br_mdb_ip_get ISDN: Add PCI ID for HFC-2S/4S Beronet Card PCIe net-2.6 [Bug-Fix][dccp]: fix oops caused after failed initialisation myri: remove dead code ...
-
git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc-2.6Linus Torvalds authored
* git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc-2.6: sunxvr1000: Add missing FB=y depenency. MAINTAINERS: Add entry for sparc serial drivers. drivers/serial/sunsab.c: adjust the constant used to initialize the interrupt_mask0 fields
-
git://git.kernel.org/pub/scm/linux/kernel/git/brodo/pcmcia-2.6Linus Torvalds authored
* 'urgent' of git://git.kernel.org/pub/scm/linux/kernel/git/brodo/pcmcia-2.6: PCMCIA: resource, fix lock imbalance pcmcia: add important if statement pcmcia: re-route Cardbus IRQ to ISA on ti1130 bridges if necessary pcmcia: allow for cb_irq to differ from pci_dev's irq in yenta_socket pcmcia: honor saved flags in yenta_socket's I365_CSCINT register pcmcia: revert "irq probe can be done without risking an IRQ storm" pcmcia: pd6729, i82092: use parent (PCI) resources pcmcia/vrc4171: use local spinlock for device local lock.
-
Heiko Carstens authored
Implement arch specific arch_get_memory_phys_device function and initialize phys_device for each memory section. That way we finally can tell which piece of memory belongs to which physical device. This makes s390's /sys/devices/system/memory/memoryX/phys_device display the correct thing? Signed-off-by:
Heiko Carstens <heiko.carstens@de.ibm.com> Cc: Dave Hansen <haveblue@us.ibm.com> Cc: Gerald Schaefer <gerald.schaefer@de.ibm.com> Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
Heiko Carstens authored
/sys/devices/system/memory/memoryX/phys_device is supposed to contain the number of the physical device that the corresponding piece of memory belongs to. In case a physical device should be replaced or taken offline for whatever reason it is necessary to set all corresponding memory pieces offline. The current implementation always sets phys_device to '0' and there is no way or hook to change that. Seems like there was a plan to implement that but it wasn't finished for whatever reason. So add a weak function which architectures can override to actually set the phys_device from within add_memory_block(). Signed-off-by:
-
Akinobu Mita authored
Replace open-coded loop with for_each_set_bit(). Signed-off-by:
Akinobu Mita <akinobu.mita@gmail.com> Cc: Clemens Ladisch <clemens@ladisch.de> Cc: Bob Picco <bob.picco@hp.com> Signed-off-by:
-
Akinobu Mita authored
Use bitmap_weight() instead of doing hweight32() for each u32 element in the page. Signed-off-by:
-
Venkatesh Pallipadi authored
jffs2 uses rb_node = NULL; to zero rb_root. The problem with this is that 17d9ddc72fb8bba0d4f678 ("rbtree: Add support for augmented rbtrees") in the linux-next tree adds a new field to that struct which needs to be NULL as well. This patch uses RB_ROOT as the intializer so all of the relevant fields will be NULL'd. Signed-off-by:Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Cc: Eric Paris <eparis@redhat.com> Acked-by:
David Woodhouse <dwmw2@infradead.org> Signed-off-by:
-
KAMEZAWA Hiroyuki authored
swap_cgroup uses 2bytes data and uses cmpxchg in a new operation. 2byte cmpxchg/xchg is not available on some archs. This patch replaces cmpxchg/xchg with operations under lock. Signed-off-by:
KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> Reported-by: Sachin Sant <sachinp@in.ibm.com> wrote: Acked-by:
Balbir Singh <balbir@in.ibm.com> Acked-by:
Daisuke Nishimura <nishimura@mxp.nes.nec.co.jp> Cc: Li Zefan <lizf@cn.fujitsu.com> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by:
-
- 17 Mar, 2010 1 commit
-
-
Tilman Schmidt authored
Update the dummy LL interface to the LL interface change introduced by commit daab433c03c15fd642c71c94eb51bdd3f32602c8. This fixes the build failure occurring after that commit when enabling ISDN_DRV_GIGASET but neither ISDN_I4L nor ISDN_CAPI. Impact: bugfix Signed-off-by:
Tilman Schmidt <tilman@imap.cc> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
- 16 Mar, 2010 24 commits
-
-
David S. Miller authored
Signed-off-by: -
David S. Miller authored
Otherwise we get a warning from the call in br_forward(). Signed-off-by: -
YOSHIFUJI Hideaki / 吉藤英明 authored
Without CONFIG_BRIDGE_IGMP_SNOOPING, BR_INPUT_SKB_CB(skb)->mrouters_only is not appropriately initialized, so we can see garbage. A clear option to fix this is to set it even without that config, but we cannot optimize out the branch. Let's introduce a macro that returns value of mrouters_only and let it return 0 without CONFIG_BRIDGE_IGMP_SNOOPING. Signed-off-by:
YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org> Signed-off-by:
-
Vitaliy Gusev authored
route: Fix caught BUG_ON during rt_secret_rebuild_oneshot() Call rt_secret_rebuild can cause BUG_ON(timer_pending(&net->ipv4.rt_secret_timer)) in add_timer as there is not any synchronization for call rt_secret_rebuild_oneshot() for the same net namespace. Also this issue affects to rt_secret_reschedule(). Thus use mod_timer enstead. Signed-off-by:
Vitaliy Gusev <vgusev@openvz.org> Acked-by:
Neil Horman <nhorman@tuxdriver.com> Signed-off-by:
-
YOSHIFUJI Hideaki / 吉藤英明 authored
Signed-off-by:
-
YOSHIFUJI Hideaki / 吉藤英明 authored
Signed-off-by:
-
Jiri Slaby authored
Stanse found that one error path in netpoll_setup dereferences npinfo even though it is NULL. Avoid that by adding new label and go to that instead. Signed-off-by:
Jiri Slaby <jslaby@suse.cz> Cc: Daniel Borkmann <danborkmann@googlemail.com> Cc: David S. Miller <davem@davemloft.net> Acked-by: chavey@google.com Acked-by:
Matt Mackall <mpm@selenic.com> Signed-off-by:
-
Neil Horman authored
So in the forward porting of various tipc packages, I was constantly getting this lockdep warning everytime I used tipc-config to set a network address for the protocol: [ INFO: possible circular locking dependency detected ] 2.6.33 #1 tipc-config/1326 is trying to acquire lock: (ref_table_lock){+.-...}, at: [<ffffffffa0315148>] tipc_ref_discard+0x53/0xd4 [tipc] but task is already holding lock: (&(&entry->lock)->rlock#2){+.-...}, at: [<ffffffffa03150d5>] tipc_ref_lock+0x43/0x63 [tipc] which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (&(&entry->lock)->rlock#2){+.-...}: [<ffffffff8107b508>] __lock_acquire+0xb67/0xd0f [<ffffffff8107b78c>] lock_acquire+0xdc/0x102 [<ffffffff8145471e>] _raw_spin_lock_bh+0x3b/0x6e [<ffffffffa03152b1>] tipc_ref_acquire+0xe8/0x11b [tipc] [<ffffffffa031433f>] tipc_createport_raw+0x78/0x1b9 [tipc] [<ffffffffa031450b>] tipc_createport+0x8b/0x125 [tipc] [<ffffffffa030f221>] tipc_subscr_start+0xce/0x126 [tipc] [<ffffffffa0308fb2>] process_signal_queue+0x47/0x7d [tipc] [<ffffffff81053e0c>] tasklet_action+0x8c/0xf4 [<ffffffff81054bd8>] __do_softirq+0xf8/0x1cd [<ffffffff8100aadc>] call_softirq+0x1c/0x30 [<ffffffff810549f4>] _local_bh_enable_ip+0xb8/0xd7 [<ffffffff81054a21>] local_bh_enable_ip+0xe/0x10 [<ffffffff81454d31>] _raw_spin_unlock_bh+0x34/0x39 [<ffffffffa0308eb8>] spin_unlock_bh.clone.0+0x15/0x17 [tipc] [<ffffffffa0308f47>] tipc_k_signal+0x8d/0xb1 [tipc] [<ffffffffa0308dd9>] tipc_core_start+0x8a/0xad [tipc] [<ffffffffa01b1087>] 0xffffffffa01b1087 [<ffffffff8100207d>] do_one_initcall+0x72/0x18a [<ffffffff810872fb>] sys_init_module+0xd8/0x23a [<ffffffff81009b42>] system_call_fastpath+0x16/0x1b -> #0 (ref_table_lock){+.-...}: [<ffffffff8107b3b2>] __lock_acquire+0xa11/0xd0f [<ffffffff8107b78c>] lock_acquire+0xdc/0x102 [<ffffffff81454836>] _raw_write_lock_bh+0x3b/0x6e [<ffffffffa0315148>] tipc_ref_discard+0x53/0xd4 [tipc] [<ffffffffa03141ee>] tipc_deleteport+0x40/0x119 [tipc] [<ffffffffa0316e35>] release+0xeb/0x137 [tipc] [<ffffffff8139dbf4>] sock_release+0x1f/0x6f [<ffffffff8139dc6b>] sock_close+0x27/0x2b [<ffffffff811116f6>] __fput+0x12a/0x1df [<ffffffff811117c5>] fput+0x1a/0x1c [<ffffffff8110e49b>] filp_close+0x68/0x72 [<ffffffff8110e552>] sys_close+0xad/0xe7 [<ffffffff81009b42>] system_call_fastpath+0x16/0x1b Finally decided I should fix this. Its a straightforward inversion, tipc_ref_acquire takes two locks in this order: ref_table_lock entry->lock while tipc_deleteport takes them in this order: entry->lock (via tipc_port_lock()) ref_table_lock (via tipc_ref_discard()) when the same entry is referenced, we get the above warning. The fix is equally straightforward. Theres no real relation between the entry->lock and the ref_table_lock (they just are needed at the same time), so move the entry->lock aquisition in tipc_ref_acquire down, after we unlock ref_table_lock (this is safe since the ref_table_lock guards changes to the reference table, and we've already claimed a slot there. I've tested the below fix and confirmed that it clears up the lockdep issue Signed-off-by: -
James Chapman authored
This patch fixes UDP socket refcnt bugs in the pppol2tp driver. A bug can cause a kernel stack trace when a tunnel socket is closed. A way to reproduce the issue is to prepare the UDP socket for L2TP (by opening a tunnel pppol2tp socket) and then close it before any L2TP sessions are added to it. The sequence is Create UDP socket Create tunnel pppol2tp socket to prepare UDP socket for L2TP pppol2tp_connect: session_id=0, peer_session_id=0 L2TP SCCRP control frame received (tunnel_id==0) pppol2tp_recv_core: sock_hold() pppol2tp_recv_core: sock_put L2TP ZLB control frame received (tunnel_id=nnn) pppol2tp_recv_core: sock_hold() pppol2tp_recv_core: sock_put Close tunnel management socket pppol2tp_release: session_id=0, peer_session_id=0 Close UDP socket udp_lib_close: BUG The addition of sock_hold() in pppol2tp_connect() solves the problem. For data frames, two sock_put() calls were added to plug a refcnt leak per received data frame. The ref that is grabbed at the top of pppol2tp_recv_core() must always be released, but this wasn't done for accepted data frames or data frames discarded because of bad UDP checksums. This leak meant that any UDP socket that had passed L2TP data traffic (i.e. L2TP data frames, not just L2TP control frames) using pppol2tp would not be released by the kernel. WARNING: at include/net/sock.h:435 udp_lib_unhash+0x117/0x120() Pid: 1086, comm: openl2tpd Not tainted 2.6.33-rc1 #8 Call Trace: [<c119e9b7>] ? udp_lib_unhash+0x117/0x120 [<c101b871>] ? warn_slowpath_common+0x71/0xd0 [<c119e9b7>] ? udp_lib_unhash+0x117/0x120 [<c101b8e3>] ? warn_slowpath_null+0x13/0x20 [<c119e9b7>] ? udp_lib_unhash+0x117/0x120 [<c11598a7>] ? sk_common_release+0x17/0x90 [<c11a5e33>] ? inet_release+0x33/0x60 [<c11577b0>] ? sock_release+0x10/0x60 [<c115780f>] ? sock_close+0xf/0x30 [<c106e542>] ? __fput+0x52/0x150 [<c106b68e>] ? filp_close+0x3e/0x70 [<c101d2e2>] ? put_files_struct+0x62/0xb0 [<c101eaf7>] ? do_exit+0x5e7/0x650 [<c1081623>] ? mntput_no_expire+0x13/0x70 [<c106b68e>] ? filp_close+0x3e/0x70 [<c101eb8a>] ? do_group_exit+0x2a/0x70 [<c101ebe1>] ? sys_exit_group+0x11/0x20 [<c10029b0>] ? sysenter_do_call+0x12/0x26 Signed-off-by:
James Chapman <jchapman@katalix.com> Signed-off-by:
-
Steve Glendinning authored
This patch ensures the PHY correctly completes its reset before setting register values. Signed-off-by:
Steve Glendinning <steve.glendinning@smsc.com> Signed-off-by:
-
James Chapman authored
When transmitting L2TP frames, we derive the outgoing interface's UDP checksum hardware assist capabilities from the tunnel dst dev. This can sometimes be NULL, especially when routing protocols are used and routing changes occur. This patch just checks for NULL dst or dev pointers when checking for netdev hardware assist features. BUG: unable to handle kernel NULL pointer dereference at 0000000c IP: [<f89d074c>] pppol2tp_xmit+0x341/0x4da [pppol2tp] *pde = 00000000 Oops: 0000 [#1] SMP last sysfs file: /sys/class/net/lo/operstate Modules linked in: pppol2tp pppox ppp_generic slhc ipv6 dummy loop snd_hda_codec_atihdmi snd_hda_intel snd_hda_codec snd_pcm snd_timer snd soundcore snd_page_alloc evdev psmouse serio_raw processor button i2c_piix4 i2c_core ati_agp agpgart pcspkr ext3 jbd mbcache sd_mod ide_pci_generic atiixp ide_core ahci ata_generic floppy ehci_hcd ohci_hcd libata e1000e scsi_mod usbcore nls_base thermal fan thermal_sys [last unloaded: scsi_wait_scan] Pid: 0, comm: swapper Not tainted (2.6.32.8 #1) EIP: 0060:[<f89d074c>] EFLAGS: 00010297 CPU: 3 EIP is at pppol2tp_xmit+0x341/0x4da [pppol2tp] EAX: 00000000 EBX: f64d1680 ECX: 000005b9 EDX: 00000000 ESI: f6b91850 EDI: f64d16ac EBP: f6a0c4c0 ESP: f70a9cac DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068 Process swapper (pid: 0, ti=f70a8000 task=f70a31c0 task.ti=f70a8000) Stack: 000005a9 000005b9 f734c400 f66652c0 f7352e00 f67dc800 00000000 f6b91800 <0> 000005a3 f70ef6c4 f67dcda9 000005a3 f89b192e 00000246 000005a3 f64d1680 <0> f63633e0 f6363320 f64d1680 f65a7320 f65a7364 f65856c0 f64d1680 f679f02f Call Trace: [<f89b192e>] ? ppp_push+0x459/0x50e [ppp_generic] [<f89b217f>] ? ppp_xmit_process+0x3b6/0x430 [ppp_generic] [<f89b2306>] ? ppp_start_xmit+0x10d/0x120 [ppp_generic] [<c11c15cb>] ? dev_hard_start_xmit+0x21f/0x2b2 [<c11d0947>] ? sch_direct_xmit+0x48/0x10e [<c11c19a0>] ? dev_queue_xmit+0x263/0x3a6 [<c11e2a9f>] ? ip_finish_output+0x1f7/0x221 [<c11df682>] ? ip_forward_finish+0x2e/0x30 [<c11de645>] ? ip_rcv_finish+0x295/0x2a9 [<c11c0b19>] ? netif_receive_skb+0x3e9/0x404 [<f814b791>] ? e1000_clean_rx_irq+0x253/0x2fc [e1000e] [<f814cb7a>] ? e1000_clean+0x63/0x1fc [e1000e] [<c1047eff>] ? sched_clock_local+0x15/0x11b [<c11c1095>] ? net_rx_action+0x96/0x195 [<c1035750>] ? __do_softirq+0xaa/0x151 [<c1035828>] ? do_softirq+0x31/0x3c [<c10358fe>] ? irq_exit+0x26/0x58 [<c1004b21>] ? do_IRQ+0x78/0x89 [<c1003729>] ? common_interrupt+0x29/0x30 [<c101ac28>] ? native_safe_halt+0x2/0x3 [<c1008c54>] ? default_idle+0x55/0x75 [<c1009045>] ? c1e_idle+0xd2/0xd5 [<c100233c>] ? cpu_idle+0x46/0x62 Code: 8d 45 08 f0 ff 45 08 89 6b 08 c7 43 68 7e fb 9c f8 8a 45 24 83 e0 0c 3c 04 75 09 80 63 64 f3 e9 b4 00 00 00 8b 43 18 8b 4c 24 04 <8b> 40 0c 8d 79 11 f6 40 44 0e 8a 43 64 75 51 6a 00 8b 4c 24 08 EIP: [<f89d074c>] pppol2tp_xmit+0x341/0x4da [pppol2tp] SS:ESP 0068:f70a9cac CR2: 000000000000000c Signed-off-by:
-
Steve Glendinning authored
This patch adds a driver for SMSC's LAN7500 family of USB 2.0 to gigabit ethernet adapters. It's loosely based on the smsc95xx driver but the device registers for LAN7500 are completely different. Signed-off-by:
-
Atsushi Nemoto authored
This patch fixes following warning introduced by commit 12bac0d9 ("proc: warn on non-existing proc entries"): WARNING: at /work/mips-linux/make/linux/fs/proc/generic.c:316 __xlate_proc_name+0xe0/0xe8() name 'RBHMA4X00/RTL8019' Signed-off-by:
Atsushi Nemoto <anemo@mba.ocn.ne.jp> Signed-off-by:
-
Jiri Slaby authored
Stanse found that one error path (when alloc_skb fails) in netdev_tx omits to unlock hw_priv->hwlock. Fix that. Signed-off-by:
-
Tilman Schmidt authored
Correct a potential array overrun due to an off by one error in the range check on the CAPI CONNECT_REQ CIPValue parameter. Found and reported by Dan Carpenter using smatch. Impact: bugfix Signed-off-by:
-
Dave Chinner authored
If we are doing a forced shutdown, we can get lots of noise about delalloc pages being discarded. This is happens by design during a forced shutdown, so don't spam the logs with these messages. Signed-off-by:
Dave Chinner <dchinner@redhat.com> Reviewed-by:
Christoph Hellwig <hch@lst.de> Signed-off-by:
Alex Elder <aelder@sgi.com>
-
Alex Elder authored
Re-apply a commit that had been reverted due to regressions that have since been fixed. From 95f8e302 Mon Sep 17 00:00:00 2001 From: Nick Piggin <npiggin@suse.de> Date: Tue, 6 Jan 2009 14:43:09 +1100 Implement XFS's large buffer support with the new vmap APIs. See the vmap rewrite (db64fe02) for some numbers. The biggest improvement that comes from using the new APIs is avoiding the global KVA allocation lock on every call. Signed-off-by:Nick Piggin <npiggin@suse.de> Reviewed-by:
Christoph Hellwig <hch@infradead.org> Signed-off-by:
Lachlan McIlroy <lachlan@sgi.com> Only modifications here were a minor reformat, plus making the patch apply given the new use of xfs_buf_is_vmapped(). Modified-by:
-
Alex Elder authored
Re-apply a commit that had been reverted due to regressions that have since been fixed. Original commit: d2859751 Author: Nick Piggin <npiggin@suse.de> Date: Tue, 6 Jan 2009 14:40:44 +1100 XFS's vmap batching simply defers a number (up to 64) of vunmaps, and keeps track of them in a list. To purge the batch, it just goes through the list and calls vunamp on each one. This is pretty poor: a global TLB flush is generally still performed on each vunmap, with the most expensive parts of the operation being the broadcast IPIs and locking involved in the SMP callouts, and the locking involved in the vmap management -- none of these are avoided by just batching up the calls. I'm actually surprised it ever made much difference. (Now that the lazy vmap allocator is upstream, this description is not quite right, but the vunmap batching still doesn't seem to do much). Rip all this logic out of XFS completely. I will improve vmap performance and scalability directly in subsequent patch. Signed-off-by: -
Jiri Slaby authored
Stanse found that one error path (when alloc_skb fails) in netdev_tx omits to unlock hw_priv->hwlock. Fix that by moving away from unlock in each fail path. Unlock at one place instead. Introduced in 94a819f8 (pcmcia: assert locking to struct pcmcia_device) Signed-off-by:
Dominik Brodowski <linux@dominikbrodowski.net>
-
David S. Miller authored
Signed-off-by: -
Julia Lawall authored
From: Julia Lawall <julia@diku.dk> SAB82532_ISR0_TCD is declared in drivers/serial/subsab.h as relating to a status register, while SAB82532_IMR0_TCD is declared in the same file as relating to a mask register. The latter seems more appropriate for the interrupt_mask0 field, and follows the strategy for initializing this field elsewhere in the same file. Both SAB82532_ISR0_TCD and SAB82532_IMR0_TCD have the same value. Signed-off-by:
Julia Lawall <julia@diku.dk> Signed-off-by:
-
Michael Braun authored
From: Michael Braun <michael-dev@fami-braun.de> bridge: Fix br_forward crash in promiscuous mode It's a linux-next kernel from 2010-03-12 on an x86 system and it OOPs in the bridge module in br_pass_frame_up (called by br_handle_frame_finish) because brdev cannot be dereferenced (its set to a non-null value). Adding some BUG_ON statements revealed that BR_INPUT_SKB_CB(skb)->brdev == br-dev (as set in br_handle_frame_finish first) only holds until br_forward is called. The next call to br_pass_frame_up then fails. Digging deeper it seems that br_forward either frees the skb or passes it to NF_HOOK which will in turn take care of freeing the skb. The same is holds for br_pass_frame_ip. So it seems as if two independent skb allocations are required. As far as I can see, commit b33084be ("bridge: Avoid unnecessary clone on forward path") removed skb duplication and so likely causes this crash. This crash does not happen on 2.6.33. I've therefore modified br_forward the same way br_flood has been modified so that the skb is not freed if skb0 is going to be used and I can confirm that the attached patch resolves the issue for me. Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by:
-
Herbert Xu authored
Since all callers of br_mdb_ip_get need to check whether the hash table is NULL, this patch moves the check into the function. This fixes the two callers (query/leave handler) that didn't check it. Reported-by:
Michael Braun <michael-dev@fami-braun.de> Signed-off-by:
-
Lars Ellenberg authored
A few subdevice IDs seem to have been dropped when hfc_multi was included upstream, just compare the list at http://www.openvox.cn/viewvc/misdn/trunk/hfc_multi.c?revision=75&view=annotate#l175 with the IDs in drivers/isdn/hardware/mISDN/hfcmulti.c Added PCIe 2 Port card and LED settings (same as PCI) Do not use <linux/pci_ids.h> /KKe Signed-off-by:
Lars Ellenberg <lars.ellenberg@linbit.com> Signed-off-by:
Karsten Keil <keil@b1-systems.de> Signed-off-by:
-
- 15 Mar, 2010 5 commits
-
-
David S. Miller authored
-
Gerrit Renker authored
dccp: fix panic caused by failed initialisation This fixes a kernel panic reported thanks to Andre Noll: if DCCP is compiled into the kernel and any out of the initialisation steps in net/dccp/proto.c:dccp_init() fail, a subsequent attempt to create a SOCK_DCCP socket will panic, since inet{,6}_create() are not prevented from creating DCCP sockets. This patch fixes the problem by propagating a failure in dccp_init() to dccp_v{4,6}_init_net(), and from there to dccp_v{4,6}_init(), so that the DCCP protocol is not made available if its initialisation fails. Signed-off-by:Gerrit Renker <gerrit@erg.abdn.ac.uk> Signed-off-by:
-
Dan Carpenter authored
We can never reach the return statement. Signed-off-by:
Dan Carpenter <error27@gmail.com> Signed-off-by:
-
Tilman Schmidt authored
Calling tty_buffer_request_room() before tty_insert_flip_string() is unnecessary, costs CPU and for big buffers can mess up the multi-page allocation avoidance. Signed-off-by:
-
Tilman Schmidt authored
In RING handling, clear the table of received parameter strings in a loop like everywhere else, instead of by enumeration which had already gotten out of sync. Impact: minor bugfix Signed-off-by:
-
