- 13 2月, 2010 1 次提交
-
-
由 Herbert Xu 提交于
Currently we treat IGMPv3 reports as if it were an IGMPv2/v1 report. This is broken as IGMPv3 reports are formatted differently. So we end up suppressing a bogus multicast group (which should be harmless as long as the leading reserved field is zero). In fact, IGMPv3 does not allow membership report suppression so we should simply ignore IGMPv3 membership reports as a host. This patch does exactly that. I kept the case statement for it so people won't accidentally add it back thinking that we overlooked this case. Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 11 2月, 2010 6 次提交
-
-
由 Damian Lukowski 提交于
Make sure, that TCP has a nonzero RTT estimation after three-way handshake. Currently, a listening TCP has a value of 0 for srtt, rttvar and rto right after the three-way handshake is completed with TCP timestamps disabled. This will lead to corrupt RTO recalculation and retransmission flood when RTO is recalculated on backoff reversion as introduced in "Revert RTO on ICMP destination unreachable" (f1ecd5d9). This behaviour can be provoked by connecting to a server which "responds first" (like SMTP) and rejecting every packet after the handshake with dest-unreachable, which will lead to softirq load on the server (up to 30% per socket in some tests). Thanks to Ilpo Jarvinen for providing debug patches and to Denys Fedoryshchenko for reporting and testing. Changes since v3: Removed bad characters in patchfile. Reported-by: NDenys Fedoryshchenko <denys@visp.net.lb> Signed-off-by: NDamian Lukowski <damian@tvk.rwth-aachen.de> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Simon Kagstrom 提交于
This patch fixes two potential races in the velocity driver: * Move the ACK and error handler to the interrupt handler. This fixes a potential race with shared interrupts when the other device interrupts before the NAPI poll handler has finished. As the velocity driver hasn't acked it's own interrupt, it will then steal the interrupt from the other device. * Use spin_lock_irqsave in velocity_poll. In the current code, the interrupt handler will deadlock if e.g., the NAPI poll handler is executing when an interrupt (for another device) comes in since it tries to take the already held lock. Also unlock the spinlock only after enabling the interrupt in velocity_poll. The error path is moved to the interrupt handler since this is where the ISR is checked now. Signed-off-by: NSimon Kagstrom <simon.kagstrom@netinsight.net> Signed-off-by: NAnders Grafstrom <anders.grafstrom@netinsight.net> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Simon Kagstrom 提交于
velocity_set_coalesce touches ISR and some other sensitive registers not covered by the rtnl lock, so take the velocity spinlock. Signed-off-by: NSimon Kagstrom <simon.kagstrom@netinsight.net> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Simon Kagstrom 提交于
Signed-off-by: NSimon Kagstrom <simon.kagstrom@netinsight.net> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Jelle Martijn Kok 提交于
Add new RTL8187B device. Signed-off-by: NLarry Finger <Larry.Finger@lwfinger.net> Cc: Stable <stable@kernel.org> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 10 2月, 2010 2 次提交
-
-
由 Roel Kluin 提交于
The wrong pointer was tested. Signed-off-by: NRoel Kluin <roel.kluin@gmail.com> Acked-by: NSamuel Ortiz <sameo@linux.intel.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Sujith 提交于
Currently, PAE frames are not assigned proper sequence numbers. Since sending PAE frames as part of aggregates breaks crupto with several APs, they are sent as normal MPDUs. Fix the seqeuence number issue by updating the frame with the internal sequence number. Tested-by: NFelix Fietkau <nbd@openwrt.org> Signed-off-by: NSujith <Sujith.Manoharan@atheros.com> Cc: stable@kernel.org Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 09 2月, 2010 14 次提交
-
-
由 Julia Lawall 提交于
Test the value that was just allocated rather than the previously tested one. A simplified version of the semantic match that finds this problem is as follows: (http://coccinelle.lip6.fr/) // <smpl> @r@ expression *x; expression e; identifier l; @@ if (x == NULL || ...) { ... when forall return ...; } ... when != goto l; when != x = e when != &x *x == NULL // </smpl> Signed-off-by: NJulia Lawall <julia@diku.dk> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Joe Perches 提交于
During the rc period, patches that are not bugfixes should be done using the net-next tree. Signed-off-by: NJoe Perches <joe@perches.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Jan Luebbe 提交于
The action modules have been prefixed with 'act_', but the Kconfig description was not changed. Signed-off-by: NJan Luebbe <jluebbe@debian.org> Acked-by: NJamal Hadi Salim <hadi@cyberus.ca> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Divy Le Ray 提交于
Verify the HW checksum state for frames handed to GRO processing. Signed-off-by: NDivy Le Ray <divy@chelsio.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Eric Dumazet 提交于
Kernel bugzilla #15239 On some workloads, it is quite possible to get a huge dst list to process in dst_gc_task(), and trigger soft lockup detection. Fix is to call cond_resched(), as we run in process context. Reported-by: NPawel Staszewski <pstaszewski@itcare.pl> Tested-by: NPawel Staszewski <pstaszewski@itcare.pl> Signed-off-by: NEric Dumazet <eric.dumazet@gmail.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Johannes Berg 提交于
Reinette found the reason for the warnings that happened occasionally when a hw-offloaded scan finished; her description of the problem: mac80211 will defer the handling of scan requests if it is busy with management work at the time. The scan requests are deferred and run after the work has completed. When this occurs there are currently two problems. * The scan request for hardware scan is not fully populated with the band and channels to scan not initialized. * When the scan is queued the state is not correctly updated to reflect that a scan is in progress. The problem here is that when the driver completes the scan and calls ieee80211_scan_completed() a warning will be triggered since mac80211 was not aware that a scan was in progress. The reason is that the queued scan work will start the hw scan right away when the hw_scan_req struct has already been allocated. However, in the first pass it will not have been filled, which happens at the same time as setting the bits. To fix this, simply move the allocation after the pending work test as well, so that the first iteration of the scan work will call __ieee80211_start_scan() even in the hardware scan case. Bug-identified-by: NReinette Chatre <reinette.chatre@intel.com> Signed-off-by: NJohannes Berg <johannes@sipsolutions.net> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Wey-Yi Guy 提交于
iwl_set_rxon_ht() only get called in iwl_post_associate(); which cause possible incorrect ht configuration. Adding the call in iwl_mac_config() if IEEE80211_CONF_CHANGE_CHANNEL flag is set to re-configure and send rxon command. Fixes http://bugzilla.intellinuxwireless.org/show_bug.cgi?id=2146Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com> Signed-off-by: NReinette Chatre <reinette.chatre@intel.com> CC: stable@kernel.org Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Benoit Papillault 提交于
We only reply to probe request if either the requested SSID is the broadcast SSID or if the requested SSID matches our own SSID. This latter case was not properly handled since we were replying to different SSID with the same length as our own SSID. Signed-off-by: NBenoit Papillault <benoit.papillault@free.fr> Cc: stable@kernel.org Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Patrick McHardy 提交于
As noticed by Jon Masters <jonathan@jonmasters.org>, the conntrack hash size is global and not per namespace, but modifiable at runtime through /sys/module/nf_conntrack/hashsize. Changing the hash size will only resize the hash in the current namespace however, so other namespaces will use an invalid hash size. This can cause crashes when enlarging the hashsize, or false negative lookups when shrinking it. Move the hash size into the per-namespace data and only use the global hash size to initialize the per-namespace value when instanciating a new namespace. Additionally restrict hash resizing to init_net for now as other namespaces are not handled currently. Cc: stable@kernel.org Signed-off-by: NPatrick McHardy <kaber@trash.net> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Alexey Dobriyan 提交于
As per C99 6.2.4(2) when temporary table data goes out of scope, the behaviour is undefined: if (compat) { struct foo tmp; ... private = &tmp; } [dereference private] Signed-off-by: NAlexey Dobriyan <adobriyan@gmail.com> Cc: stable@kernel.org Signed-off-by: NPatrick McHardy <kaber@trash.net>
-
由 Alexey Dobriyan 提交于
Expectation hashtable size was simply glued to a variable with no code to rehash expectations, so it was a bug to allow writing to it. Make "expect_hashsize" readonly. Signed-off-by: NAlexey Dobriyan <adobriyan@gmail.com> Cc: stable@kernel.org Signed-off-by: NPatrick McHardy <kaber@trash.net>
-
由 Eric Dumazet 提交于
nf_conntrack_cachep is currently shared by all netns instances, but because of SLAB_DESTROY_BY_RCU special semantics, this is wrong. If we use a shared slab cache, one object can instantly flight between one hash table (netns ONE) to another one (netns TWO), and concurrent reader (doing a lookup in netns ONE, 'finding' an object of netns TWO) can be fooled without notice, because no RCU grace period has to be observed between object freeing and its reuse. We dont have this problem with UDP/TCP slab caches because TCP/UDP hashtables are global to the machine (and each object has a pointer to its netns). If we use per netns conntrack hash tables, we also *must* use per netns conntrack slab caches, to guarantee an object can not escape from one namespace to another one. Signed-off-by: NEric Dumazet <eric.dumazet@gmail.com> [Patrick: added unique slab name allocation] Cc: stable@kernel.org Signed-off-by: NPatrick McHardy <kaber@trash.net>
-
由 Patrick McHardy 提交于
As discovered by Jon Masters <jonathan@jonmasters.org>, the "untracked" conntrack, which is located in the data section, might be accidentally freed when a new namespace is instantiated while the untracked conntrack is attached to a skb because the reference count it re-initialized. The best fix would be to use a seperate untracked conntrack per namespace since it includes a namespace pointer. Unfortunately this is not possible without larger changes since the namespace is not easily available everywhere we need it. For now move the untracked conntrack initialization to the init_net setup function to make sure the reference count is not re-initialized and handle cleanup in the init_net cleanup function to make sure namespaces can exit properly while the untracked conntrack is in use in other namespaces. Cc: stable@kernel.org Signed-off-by: NPatrick McHardy <kaber@trash.net> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
- 06 2月, 2010 1 次提交
-
-
由 Michael Poole 提交于
The report descriptor is read by user space (via the Service Discovery Protocol), so it is only available during the ioctl to connect. However, the HID probe function that needs the descriptor might not be called until a specific module is loaded. Keep a copy of the descriptor so it is available for later use. Signed-off-by: NMichael Poole <mdpoole@troilus.org> Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
-
- 05 2月, 2010 2 次提交
-
-
由 Rafael J. Wysocki 提交于
Add missing try_to_freeze() to one of the pktgen_thread_worker() code paths so that it doesn't block suspend/hibernation. Fixes http://bugzilla.kernel.org/show_bug.cgi?id=15006Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl> Reported-and-tested-by: NCiprian Dorin Craciun <ciprian.craciun@gmail.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Alexander Duyck 提交于
This change corrects an issue that will cause false hangs when using either 82575 or 82580 in legacy interrupt mode. The issue is caused when there is a slow traffic flow and an "ethtool -r" is executed while using legacy or MSI interrupts. MSI-X is not affected by this issue due to the fact that we were already reconfiguring the vectors after reset. If possible it would be best to push this for net-2.6 since it is resolving a bug but if that is not possible then net-next-2.6 will be fine. Signed-off-by: NAlexander Duyck <alexander.h.duyck@intel.com> Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 04 2月, 2010 14 次提交
-
-
One ioctl has been forgotten when the BKL was push down into irnet_ppp ioctl function. Signed-off-by: NThadeu Lima de Souza Cascardo <cascardo@holoscopio.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
Add the missing unlock_kernel in one ioctl operation. Signed-off-by: NThadeu Lima de Souza Cascardo <cascardo@holoscopio.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Krishna Kumar 提交于
a developer had complained of getting lots of warnings: "eth16 selects TX queue 98, but real number of TX queues is 64" http://www.mail-archive.com/e1000-devel@lists.sourceforge.net/msg02200.html As there was no follow up on that bug, I am submitting this patch assuming that the other return points will not return invalid txq's, and also that this fixes the bug (not tested). Signed-off-by: NKrishna Kumar <krkumar2@in.ibm.com> Signed-off-by: NJesse Brandeburg <jesse.brandeburg@intel.com> Acked-by: NPeter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com> Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Anton Blanchard 提交于
Commit e5a43549 (ixgbe: remove skb_dma_map/unmap calls from driver) looks to have introduced a bug in ixgbe_tx_map. If we get an error from a PCI DMA call, we loop backwards through count until it becomes -1 and return that. The caller of ixgbe_tx_map expects 0 on error, so return that instead. Signed-off-by: NAnton Blanchard <anton@samba.org> Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Amit Kumar Salecha 提交于
o context resources can be in used, while resource cleanup is in progress, during fw recover. o Null pointer execption can occur in send_cmd_desc, if fw recovery module frees tx ring without rtnl lock. o Same applies to ethtool register dump. Signed-off-by: NAmit Kumar Salecha <amit.salecha@qlogic.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Amit Kumar Salecha 提交于
For NX2031, first try to scrub interrupt before requesting firmware reset. Return statement was missing after scrubbbing interrupt. Signed-off-by: NVernon Mauery <vernux@us.ibm.com> Signed-off-by: NAmit Kumar Salecha <amit.salecha@qlogic.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Nick Pelly 提交于
When in sniff mode with a long interval time (1.28s) it can take 4+ seconds to establish a SCO link. Fix by requesting active mode before requesting SCO connection. This improves SCO setup time to ~500ms. Bluetooth headsets that use a long interval time, and exhibit the long SCO connection time include Motorola H790, HX1 and H17. They have a CSR 2.1 chipset. Verified this behavior and fix with host Bluetooth chipsets: BCM4329 and TI1271. 2009-10-13 14:17:46.183722 > HCI Event: Mode Change (0x14) plen 6 status 0x00 handle 1 mode 0x02 interval 2048 Mode: Sniff 2009-10-13 14:17:53.436285 < HCI Command: Setup Synchronous Connection (0x01|0x0028) plen 17 handle 1 voice setting 0x0060 2009-10-13 14:17:53.445593 > HCI Event: Command Status (0x0f) plen 4 Setup Synchronous Connection (0x01|0x0028) status 0x00 ncmd 1 2009-10-13 14:17:57.788855 > HCI Event: Synchronous Connect Complete 0x2c) plen 17 status 0x00 handle 257 bdaddr 00:1A:0E:F1:A4:7F type eSCO Air mode: CVSD Signed-off-by: NNick Pelly <npelly@google.com> Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
-
由 Yoichi Yuasa 提交于
Signed-off-by: NYoichi Yuasa <yuasa@linux-mips.org> Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
-
由 Gerrit Renker 提交于
This fixes commit (38ff3e6b) ("dccp_probe: Fix module load dependencies between dccp and dccp_probe", from 15 Jan). It fixes the construction of the first argument of try_then_request_module(), where only valid return codes from the first argument should be returned. What we do now is assign the result of register_jprobe() to ret, without the side effect of the comparison. Acked-by: NGerrit Renker <gerrit@erg.abdn.ac.uk> Signed-off-by: NNeil Horman <nhorman@tuxdriver.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Gerrit Renker 提交于
This fixes a bug introduced in commit de4ef86c ("dccp: fix dccp rmmod when kernel configured to use slub", 17 Jan): the vsnprintf used sizeof(slab_name_fmt), which became truncated to 4 bytes, since slab_name_fmt is now a 4-byte pointer and no longer a 32-character array. This lead to error messages such as FATAL: Error inserting dccp: No buffer space available >> kernel: [ 1456.341501] kmem_cache_create: duplicate cache cci generated due to the truncation after the 3rd character. Fixed for the moment by introducing a symbolic constant. Tested to fix the bug. Signed-off-by: NGerrit Renker <gerrit@erg.abdn.ac.uk> Acked-by: NNeil Horman <nhorman@tuxdriver.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 stephen hemminger 提交于
The book keeping structure for transmit always had the flags value cleared so transmit DMA maps were never released correctly. Based on patch by Jarek Poplawski, problem observed by Michael Breuer. Signed-off-by: NStephen Hemminger <shemminger@vyatta.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Alexey Dobriyan 提交于
Netlink code does module autoload if protocol userspace is asking for is not ready. However, module can dissapear right after it was autoloaded. Example: modprobe/rmmod stress-testing and xfrm_user.ko providing NETLINK_XFRM. netlink_create() in such situation _will_ create userspace socket and _will_not_ pin module. Now if module was removed and we're going to call ->netlink_rcv into nothing: BUG: unable to handle kernel paging request at ffffffffa02f842a ^^^^^^^^^^^^^^^^ modules are loaded near these addresses here IP: [<ffffffffa02f842a>] 0xffffffffa02f842a PGD 161f067 PUD 1623063 PMD baa12067 PTE 0 Oops: 0010 [#1] PREEMPT SMP DEBUG_PAGEALLOC last sysfs file: /sys/devices/pci0000:00/0000:00:1f.2/host0/target0:0:0/0:0:0:0/block/sda/uevent CPU 1 Pid: 11515, comm: ip Not tainted 2.6.33-rc5-netns-00594-gaaa5728-dirty #6 P5E/P5E RIP: 0010:[<ffffffffa02f842a>] [<ffffffffa02f842a>] 0xffffffffa02f842a RSP: 0018:ffff8800baa3db48 EFLAGS: 00010292 RAX: ffff8800baa3dfd8 RBX: ffff8800be353640 RCX: 0000000000000000 RDX: ffffffff81959380 RSI: ffff8800bab7f130 RDI: 0000000000000001 RBP: ffff8800baa3db58 R08: 0000000000000001 R09: 0000000000000000 R10: 0000000000000001 R11: 0000000000000001 R12: 0000000000000011 R13: ffff8800be353640 R14: ffff8800bcdec240 R15: ffff8800bd488010 FS: 00007f93749656f0(0000) GS:ffff880002300000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b CR2: ffffffffa02f842a CR3: 00000000ba82b000 CR4: 00000000000006e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Process ip (pid: 11515, threadinfo ffff8800baa3c000, task ffff8800bab7eb30) Stack: ffffffff813637c0 ffff8800bd488000 ffff8800baa3dba8 ffffffff8136397d <0> 0000000000000000 ffffffff81344adc 7fffffffffffffff 0000000000000000 <0> ffff8800baa3ded8 ffff8800be353640 ffff8800bcdec240 0000000000000000 Call Trace: [<ffffffff813637c0>] ? netlink_unicast+0x100/0x2d0 [<ffffffff8136397d>] netlink_unicast+0x2bd/0x2d0 netlink_unicast_kernel: nlk->netlink_rcv(skb); [<ffffffff81344adc>] ? memcpy_fromiovec+0x6c/0x90 [<ffffffff81364263>] netlink_sendmsg+0x1d3/0x2d0 [<ffffffff8133975b>] sock_sendmsg+0xbb/0xf0 [<ffffffff8106cdeb>] ? __lock_acquire+0x27b/0xa60 [<ffffffff810a18c3>] ? might_fault+0x73/0xd0 [<ffffffff810a18c3>] ? might_fault+0x73/0xd0 [<ffffffff8106db22>] ? __lock_release+0x82/0x170 [<ffffffff810a190e>] ? might_fault+0xbe/0xd0 [<ffffffff810a18c3>] ? might_fault+0x73/0xd0 [<ffffffff81344c77>] ? verify_iovec+0x47/0xd0 [<ffffffff8133a509>] sys_sendmsg+0x1a9/0x360 [<ffffffff813c2be5>] ? _raw_spin_unlock_irqrestore+0x65/0x70 [<ffffffff8106aced>] ? trace_hardirqs_on+0xd/0x10 [<ffffffff813c2bc2>] ? _raw_spin_unlock_irqrestore+0x42/0x70 [<ffffffff81197004>] ? __up_read+0x84/0xb0 [<ffffffff8106ac95>] ? trace_hardirqs_on_caller+0x145/0x190 [<ffffffff813c207f>] ? trace_hardirqs_on_thunk+0x3a/0x3f [<ffffffff8100262b>] system_call_fastpath+0x16/0x1b Code: Bad RIP value. RIP [<ffffffffa02f842a>] 0xffffffffa02f842a RSP <ffff8800baa3db48> CR2: ffffffffa02f842a If module was quickly removed after autoloading, return -E. Return -EPROTONOSUPPORT if module was quickly removed after autoloading. Signed-off-by: NAlexey Dobriyan <adobriyan@gmail.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Alexey Dobriyan 提交于
1. After sock_register() returns, it's possible to create sockets, even if module still not initialized fully (blame generic module code for that!) 2. Consequently, pfkey_create() can be called with pfkey_net_id still not initialized which will BUG_ON in net_generic(): kernel BUG at include/net/netns/generic.h:43! 3. During netns shutdown, netns ops should be unregistered after key manager unregistered because key manager calls can be triggered from xfrm_user module: general protection fault: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC pfkey_broadcast+0x111/0x210 [af_key] pfkey_send_notify+0x16a/0x300 [af_key] km_state_notify+0x41/0x70 xfrm_flush_sa+0x75/0x90 [xfrm_user] 4. Unregister netns ops after socket ops just in case and for symmetry. Reported by Luca Tettamanti. Signed-off-by: NAlexey Dobriyan <adobriyan@gmail.com> Tested-by: NLuca Tettamanti <kronos.it@gmail.com> Signed-off-by: NEric Dumazet <eric.dumazet@gmail.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Nick Pelly 提交于
When processing a RFCOMM UA frame when the socket is closed and we were not the RFCOMM initiator would cause rfcomm_session_put() to be called twice during rfcomm_process_rx(). This would cause a kernel panic in rfcomm_session_close() then. This could be easily reproduced during disconnect with devices such as Motorola H270 that send RFCOMM UA followed quickly by L2CAP disconnect request. This trace for this looks like: 2009-09-21 17:22:37.788895 < ACL data: handle 1 flags 0x02 dlen 8 L2CAP(d): cid 0x0041 len 4 [psm 3] RFCOMM(s): DISC: cr 0 dlci 20 pf 1 ilen 0 fcs 0x7d 2009-09-21 17:22:37.906204 > HCI Event: Number of Completed Packets (0x13) plen 5 handle 1 packets 1 2009-09-21 17:22:37.933090 > ACL data: handle 1 flags 0x02 dlen 8 L2CAP(d): cid 0x0040 len 4 [psm 3] RFCOMM(s): UA: cr 0 dlci 20 pf 1 ilen 0 fcs 0x57 2009-09-21 17:22:38.636764 < ACL data: handle 1 flags 0x02 dlen 8 L2CAP(d): cid 0x0041 len 4 [psm 3] RFCOMM(s): DISC: cr 0 dlci 0 pf 1 ilen 0 fcs 0x9c 2009-09-21 17:22:38.744125 > HCI Event: Number of Completed Packets (0x13) plen 5 handle 1 packets 1 2009-09-21 17:22:38.763687 > ACL data: handle 1 flags 0x02 dlen 8 L2CAP(d): cid 0x0040 len 4 [psm 3] RFCOMM(s): UA: cr 0 dlci 0 pf 1 ilen 0 fcs 0xb6 2009-09-21 17:22:38.783554 > ACL data: handle 1 flags 0x02 dlen 12 L2CAP(s): Disconn req: dcid 0x0040 scid 0x0041 Avoid calling rfcomm_session_put() twice by skipping this call in rfcomm_recv_ua() if the socket is closed. Signed-off-by: NNick Pelly <npelly@google.com> Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
-