hso: remove claiming and releasing of USB interface

No need to reclaim the same USB interface beeing probed.
Releasing interface does nothing also.

This is already in for a long time in off-kernel hso driver
and no regresions were noticed for this change.

Signed-off-by: Paulius Zaleckas <paulius.zaleckas@teltonika.lt>
Cc: Denis Joseph Barrow <D.Barow@option.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

ppp_generic: Simplify tx_dropped stats

Local variable dev = ppp->dev

Signed-off-by: Paulius Zaleckas <paulius.zaleckas@teltonika.lt>
Signed-off-by: David S. Miller <davem@davemloft.net>

Merge branch 'master' of git://git./linux/kernel/git/holtmann/bluetooth-next-2.6

m68knommu: remove ColdFire specific setup code from FEC driver

Remove the ColdFire CPU specific setup from here. The ColdFire
CPU platform code now sets up all this.

Signed-off-by: Greg Ungerer <gerg@uclinux.org>
Signed-off-by: David S. Miller <davem@davemloft.net>

fec: add FEC platform support to ColdFire CPU's setup code

m68knommu: add FEC platform support to ColdFire CPU's setup code

Move the per-CPU FEC driver setup code into the actual platform
setup code for each ColdFire CPU varient.

Signed-off-by: Greg Ungerer <gerg@uclinux.org>
Signed-off-by: David S. Miller <davem@davemloft.net>

MISDN: list usage cleanup

Trivial cleanup, list_del(); list_add_tail() is equivalent
to list_move_tail(). Semantic patch for coccinelle can be
found at www.cccmz.de/~snakebyte/list_move_tail.spatch

Signed-off-by: Eric Sesterhenn <snakebyte@gmx.de>
Acked-by: Karsten Keil <kkeil@novell.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

qlge: Reduce debug print output.

Get rid of some noise that is for debug only.

Signed-off-by: Ron Mercer <ron.mercer@qlogic.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

qlge: Prepare to add new device.

This organizes a few calls into a function table to enable adding new
devices.

Signed-off-by: Ron Mercer <ron.mercer@qlogic.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

qlge: Move firmware event handler.

This is not a logical change but rather a move of the inbound firmware event
handler into it's own function as it will later be called by the outbound
path.
The addition of the mutex is to create exclusive access to the mailbox
commands between inbound and outbound handling.

Signed-off-by: Ron Mercer <ron.mercer@qlogic.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

qlge: Clean up firmware reset path.

Add function for performing the reset rather than in-line. This function
may later be called by a core dump process.

Signed-off-by: Ron Mercer <ron.mercer@qlogic.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

qlge: Add defines for firmware support.

Signed-off-by: Ron Mercer <ron.mercer@qlogic.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

mdio: fix non-constant printk warnings

Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

forcedeth: fix non-constant printk warnings

Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

hamachi: fix non-constant printk warnings

Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

sundance: fix non-constant printk warnings

Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

starfire: fix non-constant printk warnings

Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

via-rhine: fix non-constant printk warnings

Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

fealnx: fix non-constant printk warnings

Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

natsemi: fix non-constant printk warnings

Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

acenic: fix non-constant printk warnings

Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

yellowfin: fix non-constant printk warnings

Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

sis900: fix non-constant printk warnings

Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

ne2k-pci: fix non-constant printk warnings

Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

3c59x: get rid of non-const printk warnings

Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

lapb: get rid of non-const printk warning

Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

tulip: get rid of warning for non-const string literal

Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

Bluetooth: Remove some pointless conditionals before kfree_skb()

Remove some pointless conditionals before kfree_skb().

Signed-off-by: Wei Yongjun <yjwei@cn.fujitsu.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>

Bluetooth: Remove some pointless conditionals before kfree_skb()

Remove some pointless conditionals before kfree_skb().

Signed-off-by: Wei Yongjun <yjwei@cn.fujitsu.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>

Bluetooth: Move hci_conn_del_sysfs() back to avoid device destruct too early

The following commit introduce a regression:

commit 7d0db0a373195385a2e0b19d1f5e4b186fdcffac
Author: Marcel Holtmann <marcel@holtmann.org>
Date:   Mon Jul 14 20:13:51 2008 +0200

[Bluetooth] Use a more unique bus name for connections

I get panic as following (by netconsole):

[ 2709.344034] usb 5-1: new full speed USB device using uhci_hcd and address 4
[ 2709.505776] usb 5-1: configuration #1 chosen from 1 choice
[ 2709.569207] Bluetooth: Generic Bluetooth USB driver ver 0.4
[ 2709.570169] usbcore: registered new interface driver btusb
[ 2845.742781] BUG: unable to handle kernel paging request at 6b6b6c2f
[ 2845.742958] IP: [<c015515c>] __lock_acquire+0x6c/0xa80
[ 2845.743087] *pde = 00000000
[ 2845.743206] Oops: 0002 [#1] SMP
[ 2845.743377] last sysfs file: /sys/class/bluetooth/hci0/hci0:6/type
[ 2845.743742] Modules linked in: btusb netconsole snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss rfcomm l2cap bluetooth vfat fuse snd_hda_codec_idt snd_hda_intel snd_hda_codec snd_hwdep snd_pcm pl2303 snd_timer psmouse usbserial snd 3c59x e100 serio_raw soundcore i2c_i801 intel_agp mii agpgart snd_page_alloc rtc_cmos rtc_core thermal processor rtc_lib button thermal_sys sg evdev
[ 2845.743742]
[ 2845.743742] Pid: 0, comm: swapper Not tainted (2.6.29-rc5-smp #54) Dell DM051
[ 2845.743742] EIP: 0060:[<c015515c>] EFLAGS: 00010002 CPU: 0
[ 2845.743742] EIP is at __lock_acquire+0x6c/0xa80
[ 2845.743742] EAX: 00000046 EBX: 00000046 ECX: 6b6b6b6b EDX: 00000002
[ 2845.743742] ESI: 6b6b6b6b EDI: 00000000 EBP: c064fd14 ESP: c064fcc8
[ 2845.743742]  DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068
[ 2845.743742] Process swapper (pid: 0, ti=c064e000 task=c05d1400 task.ti=c064e000)
[ 2845.743742] Stack:
[ 2845.743742]  c05d1400 00000002 c05d1400 00000001 00000002 00000000 f65388dc c05d1400
[ 2845.743742]  6b6b6b6b 00000292 c064fd0c c0153732 00000000 00000000 00000001 f700fa50
[ 2845.743742]  00000046 00000000 00000000 c064fd40 c0155be6 00000000 00000002 00000001
[ 2845.743742] Call Trace:
[ 2845.743742]  [<c0153732>] ? trace_hardirqs_on_caller+0x72/0x1c0
[ 2845.743742]  [<c0155be6>] ? lock_acquire+0x76/0xa0
[ 2845.743742]  [<c03e1aad>] ? skb_dequeue+0x1d/0x70
[ 2845.743742]  [<c046c885>] ? _spin_lock_irqsave+0x45/0x80
[ 2845.743742]  [<c03e1aad>] ? skb_dequeue+0x1d/0x70
[ 2845.743742]  [<c03e1aad>] ? skb_dequeue+0x1d/0x70
[ 2845.743742]  [<c03e1f94>] ? skb_queue_purge+0x14/0x20
[ 2845.743742]  [<f8171f5a>] ? hci_conn_del+0x10a/0x1c0 [bluetooth]
[ 2845.743742]  [<f81399c9>] ? l2cap_disconn_ind+0x59/0xb0 [l2cap]
[ 2845.743742]  [<f81795ce>] ? hci_conn_del_sysfs+0x8e/0xd0 [bluetooth]
[ 2845.743742]  [<f8175758>] ? hci_event_packet+0x5f8/0x31c0 [bluetooth]
[ 2845.743742]  [<c03dfe19>] ? sock_def_readable+0x59/0x80
[ 2845.743742]  [<c046c14d>] ? _read_unlock+0x1d/0x20
[ 2845.743742]  [<f8178aa9>] ? hci_send_to_sock+0xe9/0x1d0 [bluetooth]
[ 2845.743742]  [<c015388b>] ? trace_hardirqs_on+0xb/0x10
[ 2845.743742]  [<f816fa6a>] ? hci_rx_task+0x2ba/0x490 [bluetooth]
[ 2845.743742]  [<c0133661>] ? tasklet_action+0x31/0xc0
[ 2845.743742]  [<c013367c>] ? tasklet_action+0x4c/0xc0
[ 2845.743742]  [<c0132eb7>] ? __do_softirq+0xa7/0x170
[ 2845.743742]  [<c0116dec>] ? ack_apic_level+0x5c/0x1c0
[ 2845.743742]  [<c0132fd7>] ? do_softirq+0x57/0x60
[ 2845.743742]  [<c01333dc>] ? irq_exit+0x7c/0x90
[ 2845.743742]  [<c01055bb>] ? do_IRQ+0x4b/0x90
[ 2845.743742]  [<c01333d5>] ? irq_exit+0x75/0x90
[ 2845.743742]  [<c010392c>] ? common_interrupt+0x2c/0x34
[ 2845.743742]  [<c010a14f>] ? mwait_idle+0x4f/0x70
[ 2845.743742]  [<c0101c05>] ? cpu_idle+0x65/0xb0
[ 2845.743742]  [<c045731e>] ? rest_init+0x4e/0x60
[ 2845.743742] Code: 0f 84 69 02 00 00 83 ff 07 0f 87 1e 06 00 00 85 ff 0f 85 08 05 00 00 8b 4d cc 8b 49 04 85 c9 89 4d d4 0f 84 f7 04 00 00 8b 75 d4 <f0> ff 86 c4 00 00 00 89 f0 e8 56 a9 ff ff 85 c0 0f 85 6e 03 00
[ 2845.743742] EIP: [<c015515c>] __lock_acquire+0x6c/0xa80 SS:ESP 0068:c064fcc8
[ 2845.743742] ---[ end trace 4c985b38f022279f ]---
[ 2845.743742] Kernel panic - not syncing: Fatal exception in interrupt
[ 2845.743742] ------------[ cut here ]------------
[ 2845.743742] WARNING: at kernel/smp.c:329 smp_call_function_many+0x151/0x200()
[ 2845.743742] Hardware name: Dell DM051
[ 2845.743742] Modules linked in: btusb netconsole snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss rfcomm l2cap bluetooth vfat fuse snd_hda_codec_idt snd_hda_intel snd_hda_codec snd_hwdep snd_pcm pl2303 snd_timer psmouse usbserial snd 3c59x e100 serio_raw soundcore i2c_i801 intel_agp mii agpgart snd_page_alloc rtc_cmos rtc_core thermal processor rtc_lib button thermal_sys sg evdev
[ 2845.743742] Pid: 0, comm: swapper Tainted: G      D    2.6.29-rc5-smp #54
[ 2845.743742] Call Trace:
[ 2845.743742]  [<c012e076>] warn_slowpath+0x86/0xa0
[ 2845.743742]  [<c015041b>] ? trace_hardirqs_off+0xb/0x10
[ 2845.743742]  [<c0146384>] ? up+0x14/0x40
[ 2845.743742]  [<c012e661>] ? release_console_sem+0x31/0x1e0
[ 2845.743742]  [<c046c8ab>] ? _spin_lock_irqsave+0x6b/0x80
[ 2845.743742]  [<c015041b>] ? trace_hardirqs_off+0xb/0x10
[ 2845.743742]  [<c046c900>] ? _read_lock_irqsave+0x40/0x80
[ 2845.743742]  [<c012e7f2>] ? release_console_sem+0x1c2/0x1e0
[ 2845.743742]  [<c0146384>] ? up+0x14/0x40
[ 2845.743742]  [<c015041b>] ? trace_hardirqs_off+0xb/0x10
[ 2845.743742]  [<c046a3d7>] ? __mutex_unlock_slowpath+0x97/0x160
[ 2845.743742]  [<c046a563>] ? mutex_trylock+0xb3/0x180
[ 2845.743742]  [<c046a4a8>] ? mutex_unlock+0x8/0x10
[ 2845.743742]  [<c015b991>] smp_call_function_many+0x151/0x200
[ 2845.743742]  [<c010a1a0>] ? stop_this_cpu+0x0/0x40
[ 2845.743742]  [<c015ba61>] smp_call_function+0x21/0x30
[ 2845.743742]  [<c01137ae>] native_smp_send_stop+0x1e/0x50
[ 2845.743742]  [<c012e0f5>] panic+0x55/0x110
[ 2845.743742]  [<c01065a8>] oops_end+0xb8/0xc0
[ 2845.743742]  [<c010668f>] die+0x4f/0x70
[ 2845.743742]  [<c011a8c9>] do_page_fault+0x269/0x610
[ 2845.743742]  [<c011a660>] ? do_page_fault+0x0/0x610
[ 2845.743742]  [<c046cbaf>] error_code+0x77/0x7c
[ 2845.743742]  [<c015515c>] ? __lock_acquire+0x6c/0xa80
[ 2845.743742]  [<c0153732>] ? trace_hardirqs_on_caller+0x72/0x1c0
[ 2845.743742]  [<c0155be6>] lock_acquire+0x76/0xa0
[ 2845.743742]  [<c03e1aad>] ? skb_dequeue+0x1d/0x70
[ 2845.743742]  [<c046c885>] _spin_lock_irqsave+0x45/0x80
[ 2845.743742]  [<c03e1aad>] ? skb_dequeue+0x1d/0x70
[ 2845.743742]  [<c03e1aad>] skb_dequeue+0x1d/0x70
[ 2845.743742]  [<c03e1f94>] skb_queue_purge+0x14/0x20
[ 2845.743742]  [<f8171f5a>] hci_conn_del+0x10a/0x1c0 [bluetooth]
[ 2845.743742]  [<f81399c9>] ? l2cap_disconn_ind+0x59/0xb0 [l2cap]
[ 2845.743742]  [<f81795ce>] ? hci_conn_del_sysfs+0x8e/0xd0 [bluetooth]
[ 2845.743742]  [<f8175758>] hci_event_packet+0x5f8/0x31c0 [bluetooth]
[ 2845.743742]  [<c03dfe19>] ? sock_def_readable+0x59/0x80
[ 2845.743742]  [<c046c14d>] ? _read_unlock+0x1d/0x20
[ 2845.743742]  [<f8178aa9>] ? hci_send_to_sock+0xe9/0x1d0 [bluetooth]
[ 2845.743742]  [<c015388b>] ? trace_hardirqs_on+0xb/0x10
[ 2845.743742]  [<f816fa6a>] hci_rx_task+0x2ba/0x490 [bluetooth]
[ 2845.743742]  [<c0133661>] ? tasklet_action+0x31/0xc0
[ 2845.743742]  [<c013367c>] tasklet_action+0x4c/0xc0
[ 2845.743742]  [<c0132eb7>] __do_softirq+0xa7/0x170
[ 2845.743742]  [<c0116dec>] ? ack_apic_level+0x5c/0x1c0
[ 2845.743742]  [<c0132fd7>] do_softirq+0x57/0x60
[ 2845.743742]  [<c01333dc>] irq_exit+0x7c/0x90
[ 2845.743742]  [<c01055bb>] do_IRQ+0x4b/0x90
[ 2845.743742]  [<c01333d5>] ? irq_exit+0x75/0x90
[ 2845.743742]  [<c010392c>] common_interrupt+0x2c/0x34
[ 2845.743742]  [<c010a14f>] ? mwait_idle+0x4f/0x70
[ 2845.743742]  [<c0101c05>] cpu_idle+0x65/0xb0
[ 2845.743742]  [<c045731e>] rest_init+0x4e/0x60
[ 2845.743742] ---[ end trace 4c985b38f02227a0 ]---
[ 2845.743742] ------------[ cut here ]------------
[ 2845.743742] WARNING: at kernel/smp.c:226 smp_call_function_single+0x8e/0x110()
[ 2845.743742] Hardware name: Dell DM051
[ 2845.743742] Modules linked in: btusb netconsole snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss rfcomm l2cap bluetooth vfat fuse snd_hda_codec_idt snd_hda_intel snd_hda_codec snd_hwdep snd_pcm pl2303 snd_timer psmouse usbserial snd 3c59x e100 serio_raw soundcore i2c_i801 intel_agp mii agpgart snd_page_alloc rtc_cmos rtc_core thermal processor rtc_lib button thermal_sys sg evdev
[ 2845.743742] Pid: 0, comm: swapper Tainted: G      D W  2.6.29-rc5-smp #54
[ 2845.743742] Call Trace:
[ 2845.743742]  [<c012e076>] warn_slowpath+0x86/0xa0
[ 2845.743742]  [<c012e000>] ? warn_slowpath+0x10/0xa0
[ 2845.743742]  [<c015041b>] ? trace_hardirqs_off+0xb/0x10
[ 2845.743742]  [<c0146384>] ? up+0x14/0x40
[ 2845.743742]  [<c012e661>] ? release_console_sem+0x31/0x1e0
[ 2845.743742]  [<c046c8ab>] ? _spin_lock_irqsave+0x6b/0x80
[ 2845.743742]  [<c015041b>] ? trace_hardirqs_off+0xb/0x10
[ 2845.743742]  [<c046c900>] ? _read_lock_irqsave+0x40/0x80
[ 2845.743742]  [<c012e7f2>] ? release_console_sem+0x1c2/0x1e0
[ 2845.743742]  [<c0146384>] ? up+0x14/0x40
[ 2845.743742]  [<c015b7be>] smp_call_function_single+0x8e/0x110
[ 2845.743742]  [<c010a1a0>] ? stop_this_cpu+0x0/0x40
[ 2845.743742]  [<c026d23f>] ? cpumask_next_and+0x1f/0x40
[ 2845.743742]  [<c015b95a>] smp_call_function_many+0x11a/0x200
[ 2845.743742]  [<c010a1a0>] ? stop_this_cpu+0x0/0x40
[ 2845.743742]  [<c015ba61>] smp_call_function+0x21/0x30
[ 2845.743742]  [<c01137ae>] native_smp_send_stop+0x1e/0x50
[ 2845.743742]  [<c012e0f5>] panic+0x55/0x110
[ 2845.743742]  [<c01065a8>] oops_end+0xb8/0xc0
[ 2845.743742]  [<c010668f>] die+0x4f/0x70
[ 2845.743742]  [<c011a8c9>] do_page_fault+0x269/0x610
[ 2845.743742]  [<c011a660>] ? do_page_fault+0x0/0x610
[ 2845.743742]  [<c046cbaf>] error_code+0x77/0x7c
[ 2845.743742]  [<c015515c>] ? __lock_acquire+0x6c/0xa80
[ 2845.743742]  [<c0153732>] ? trace_hardirqs_on_caller+0x72/0x1c0
[ 2845.743742]  [<c0155be6>] lock_acquire+0x76/0xa0
[ 2845.743742]  [<c03e1aad>] ? skb_dequeue+0x1d/0x70
[ 2845.743742]  [<c046c885>] _spin_lock_irqsave+0x45/0x80
[ 2845.743742]  [<c03e1aad>] ? skb_dequeue+0x1d/0x70
[ 2845.743742]  [<c03e1aad>] skb_dequeue+0x1d/0x70
[ 2845.743742]  [<c03e1f94>] skb_queue_purge+0x14/0x20
[ 2845.743742]  [<f8171f5a>] hci_conn_del+0x10a/0x1c0 [bluetooth]
[ 2845.743742]  [<f81399c9>] ? l2cap_disconn_ind+0x59/0xb0 [l2cap]
[ 2845.743742]  [<f81795ce>] ? hci_conn_del_sysfs+0x8e/0xd0 [bluetooth]
[ 2845.743742]  [<f8175758>] hci_event_packet+0x5f8/0x31c0 [bluetooth]
[ 2845.743742]  [<c03dfe19>] ? sock_def_readable+0x59/0x80
[ 2845.743742]  [<c046c14d>] ? _read_unlock+0x1d/0x20
[ 2845.743742]  [<f8178aa9>] ? hci_send_to_sock+0xe9/0x1d0 [bluetooth]
[ 2845.743742]  [<c015388b>] ? trace_hardirqs_on+0xb/0x10
[ 2845.743742]  [<f816fa6a>] hci_rx_task+0x2ba/0x490 [bluetooth]
[ 2845.743742]  [<c0133661>] ? tasklet_action+0x31/0xc0
[ 2845.743742]  [<c013367c>] tasklet_action+0x4c/0xc0
[ 2845.743742]  [<c0132eb7>] __do_softirq+0xa7/0x170
[ 2845.743742]  [<c0116dec>] ? ack_apic_level+0x5c/0x1c0
[ 2845.743742]  [<c0132fd7>] do_softirq+0x57/0x60
[ 2845.743742]  [<c01333dc>] irq_exit+0x7c/0x90
[ 2845.743742]  [<c01055bb>] do_IRQ+0x4b/0x90
[ 2845.743742]  [<c01333d5>] ? irq_exit+0x75/0x90
[ 2845.743742]  [<c010392c>] common_interrupt+0x2c/0x34
[ 2845.743742]  [<c010a14f>] ? mwait_idle+0x4f/0x70
[ 2845.743742]  [<c0101c05>] cpu_idle+0x65/0xb0
[ 2845.743742]  [<c045731e>] rest_init+0x4e/0x60
[ 2845.743742] ---[ end trace 4c985b38f02227a1 ]---
[ 2845.743742] Rebooting in 3 seconds..

My logitec bluetooth mouse trying connect to pc, but
pc side reject the connection again and again. then panic happens.

The reason is due to hci_conn_del_sysfs now called in hci_event_packet,
the del work is done in a workqueue, so it's possible done before
skb_queue_purge called.

I move the hci_conn_del_sysfs after skb_queue_purge just as that before
marcel's commit.

Remove the hci_conn_del_sysfs in hci_conn_hash_flush as well due to
hci_conn_del will deal with the work.

Signed-off-by: Dave Young <hidave.darkstar@gmail.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>

Bluetooth: Permit BT_SECURITY also for L2CAP raw sockets

Userspace pairing code can be simplified if it doesn't have to fall
back to using L2CAP_LM in the case of L2CAP raw sockets. This patch
allows the BT_SECURITY socket option to be used for these sockets.

Signed-off-by: Johan Hedberg <johan.hedberg@nokia.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>

Bluetooth: Fix RFCOMM usage of in-kernel L2CAP sockets

The CID value of L2CAP sockets need to be set to zero. All userspace
applications do this via memset() on the sockaddr_l2 structure. The
RFCOMM implementation uses in-kernel L2CAP sockets and so it has to
make sure that l2_cid is set to zero.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>

Bluetooth: Disallow usage of L2CAP CID setting for now

In the future the L2CAP layer will have full support for fixed channels
and right now it already can export the channel assignment, but for the
functions bind() and connect() the usage of only CID 0 is allowed. This
allows an easy detection if the kernel supports fixed channels or not,
because otherwise it would impossible for application to tell.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>

Bluetooth: Change RFCOMM to use BT_CONNECT2 for BT_DEFER_SETUP

When BT_DEFER_SETUP is enabled on a RFCOMM socket, then switch its
current state from BT_OPEN to BT_CONNECT2. This gives the Bluetooth
core a unified way to handle L2CAP and RFCOMM sockets. The BT_CONNECT2
state is designated for incoming connections.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>

Bluetooth: Fix poll() misbehavior when using BT_DEFER_SETUP

When BT_DEFER_SETUP has been enabled on a Bluetooth socket it keeps
signaling POLLIN all the time. This is a wrong behavior. The POLLIN
should only be signaled if the client socket is in BT_CONNECT2 state
and the parent has been BT_DEFER_SETUP enabled.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>

Bluetooth: Set authentication requirement before requesting it

The authentication requirement got only updated when the security level
increased. This is a wrong behavior. The authentication requirement is
read by the Bluetooth daemon to make proper decisions when handling the
IO capabilities exchange. So set the value that is currently expected by
the higher layers like L2CAP and RFCOMM.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>

Bluetooth: Fix authentication requirements for L2CAP security check

The L2CAP layer can trigger the authentication via an ACL connection or
later on to increase the security level. When increasing the security
level it didn't use the same authentication requirements when triggering
a new ACL connection. Make sure that exactly the same authentication
requirements are used. The only exception here are the L2CAP raw sockets
which are only used for dedicated bonding.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>

Bluetooth: Ask upper layers for HCI disconnect reason

Some of the qualification tests demand that in case of failures in L2CAP
the HCI disconnect should indicate a reason why L2CAP fails. This is a
bluntly layer violation since multiple L2CAP connections could be using
the same ACL and thus forcing a disconnect reason is not a good idea.

To comply with the Bluetooth test specification, the disconnect reason
is now stored in the L2CAP connection structure and every time a new
L2CAP channel is added it will set back to its default. So only in the
case where the L2CAP channel with the disconnect reason is really the
last one, it will propagated to the HCI layer.

The HCI layer has been extended with a disconnect indication that allows
it to ask upper layers for a disconnect reason. The upper layer must not
support this callback and in that case it will nicely default to the
existing behavior. If an upper layer like L2CAP can provide a disconnect
reason that one will be used to disconnect the ACL or SCO link.

No modification to the ACL disconnect timeout have been made. So in case
of Linux to Linux connection the initiator will disconnect the ACL link
before the acceptor side can signal the specific disconnect reason. That
is perfectly fine since Linux doesn't make use of this value anyway. The
L2CAP layer has a perfect valid error code for rejecting connection due
to a security violation. It is unclear why the Bluetooth specification
insists on having specific HCI disconnect reason.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>

Bluetooth: Add CID field to L2CAP socket address structure

In preparation for L2CAP fixed channel support, the CID value of a
L2CAP connection needs to be accessible via the socket interface. The
CID is the connection identifier and exists as source and destination
value. So extend the L2CAP socket address structure with this field and
change getsockname() and getpeername() to fill it in.

The bind() and connect() functions have been modified to handle L2CAP
socket address structures of variable sizes. This makes them future
proof if additional fields need to be added.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>

Bluetooth: Request L2CAP fixed channel list if available

If the extended features mask indicates support for fixed channels,
request the list of available fixed channels. This also enables the
fixed channel features bit so remote implementations can request
information about it. Currently only the signal channel will be
listed.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>

Bluetooth: Don't enforce authentication for L2CAP PSM 1 and 3

The recommendation for the L2CAP PSM 1 (SDP) is to not use any kind
of authentication or encryption. So don't trigger authentication
for incoming and outgoing SDP connections.

For L2CAP PSM 3 (RFCOMM) there is no clear requirement, but with
Bluetooth 2.1 the initiator is required to enable authentication
and encryption first and this gets enforced. So there is no need
to trigger an additional authentication step. The RFCOMM service
security will make sure that a secure enough link key is present.

When the encryption gets enabled after the SDP connection setup,
then switch the security level from SDP to low security.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>

Bluetooth: Fix double L2CAP connection request

If the remote L2CAP server uses authentication pending stage and
encryption is enabled it can happen that a L2CAP connection request is
sent twice due to a race condition in the connection state machine.

When the remote side indicates any kind of connection pending, then
track this state and skip sending of L2CAP commands for this period.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>

Bluetooth: Fix race condition with L2CAP information request

When two L2CAP connections are requested quickly after the ACL link has
been established there exists a window for a race condition where a
connection request is sent before the information response has been
received. Any connection request should only be sent after an exchange
of the extended features mask has been finished.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>

Bluetooth: Set authentication requirements if not available

When no authentication requirements are selected, but an outgoing or
incoming connection has requested any kind of security enforcement,
then set these authentication requirements.

This ensures that the userspace always gets informed about the
authentication requirements (if available). Only when no security
enforcement has happened, the kernel will signal invalid requirements.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>

Bluetooth: Use general bonding whenever possible

When receiving incoming connection to specific services, always use
general bonding. This ensures that the link key gets stored and can be
used for further authentications.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>

Bluetooth: Add SCO fallback for eSCO connection attempts

When attempting to setup eSCO connections it can happen that some link
manager implementations fail to properly negotiate the eSCO parameters
and thus fail the eSCO setup. Normally the link manager is responsible
for the negotiation of the parameters and actually fallback to SCO if
no agreement can be reached. In cases where the link manager is just too
stupid, then at least try to establish a SCO link if eSCO fails.

For the Bluetooth devices with EDR support this includes handling packet
types of EDR basebands. This is particular tricky since for the EDR the
logic of enabling/disabling one specific packet type is turned around.
This fix contains an extra bitmask to disable eSCO EDR packet when
trying to fallback to a SCO connection.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>

Bluetooth: Don't check encryption for L2CAP raw sockets

For L2CAP sockets with medium and high security requirement a missing
encryption will enforce the closing of the link. For the L2CAP raw
sockets this is not needed, so skip that check.

This fixes a crash when pairing Bluetooth 2.0 (and earlier) devices
since the L2CAP state machine got confused and then locked up the whole
system.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>

Bluetooth: Submit bulk URBs along with interrupt URBs

Submitting the bulk URBs for ACL data transfers only on demand has no
real benefit compared to just submit them when a Bluetooth device gets
opened. So when submitting the interrupt URBs for HCI events, just
submit the bulk URBs, too.

This solves a problem with some Bluetooth USB dongles that has been
reported over the last few month. These devices require that the bulk
URBs are actually present. These devices are really broken, but there
is nothing we can do about it.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>

Bluetooth: When encryption is dropped, do not send RFCOMM packets

During a role change with pre-Bluetooth 2.1 devices, the remote side drops
the encryption of the RFCOMM connection. We allow a grace period for the
encryption to be re-established, before dropping the connection. During
this grace period, the RFCOMM_SEC_PENDING flag is set. Check this flag
before sending RFCOMM packets.

Signed-off-by: Jaikumar Ganesh <jaikumar@google.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>

Bluetooth: Eliminate a sparse warning in bt3c driver

This eliminates a sparse warning that symbol 'stat' shadows an earlier one.

Signed-off-by: Andre Haupt <andre@bitwigglers.org>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>

Bluetooth: Remove CONFIG_DEBUG_LOCK_ALLOC ifdefs

Due to lockdep changes, the CONFIG_DEBUG_LOCK_ALLOC ifdef is not needed
now. So just remove it here.

The following commit fixed the !lockdep build warnings:

commit e8f6fbf62de37cbc2e179176ac7010d5f4396b67
Author: Ingo Molnar <mingo@elte.hu>
Date:   Wed Nov 12 01:38:36 2008 +0000

    lockdep: include/linux/lockdep.h - fix warning in net/bluetooth/af_bluetooth.c

Signed-off-by: Dave Young <hidave.darkstar@gmail.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>

Bluetooth: Update version numbers

With the support for the enhanced security model and the support for
deferring connection setup, it is a good idea to increase various
version numbers.

This is purely cosmetic and has no effect on the behavior, but can
be really helpful when debugging problems in different kernel versions.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>

Bluetooth: Restrict application of socket options

The new socket options should only be evaluated for SOL_BLUETOOTH level
and not for every other level. Previously this causes some minor issues
when detecting if a kernel with certain features is available.

Also restrict BT_SECURITY to SOCK_SEQPACKET for L2CAP and SOCK_STREAM for
the RFCOMM protocol.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>

Bluetooth: Disconnect L2CAP connections without encryption

For L2CAP connections with high security setting, the link will be
immediately dropped when the encryption gets disabled. For L2CAP
connections with medium security there will be grace period where
the remote device has the chance to re-enable encryption. If it
doesn't happen then the link will also be disconnected.

The requirement for the grace period with medium security comes from
Bluetooth 2.0 and earlier devices that require role switching.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>

Bluetooth: Pause RFCOMM TX when encryption drops

A role switch with devices following the Bluetooth pre-2.1 standards
or without Encryption Pause and Resume support is not possible if
encryption is enabled. Most newer headsets require the role switch,
but also require that the connection is encrypted.

For connections with a high security mode setting, the link will be
immediately dropped. When the connection uses medium security mode
setting, then a grace period is introduced where the TX is halted and
the remote device gets a change to re-enable encryption after the
role switch. If not re-enabled the link will be dropped.

Based on initial work by Ville Tervo <ville.tervo@nokia.com>

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>

Bluetooth: Replace RFCOMM link mode with security level

Change the RFCOMM internals to use the new security levels and remove
the link mode details.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>

Bluetooth: Replace L2CAP link mode with security level

Change the L2CAP internals to use the new security levels and remove
the link mode details.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>

Bluetooth: Add enhanced security model for Simple Pairing

The current security model is based around the flags AUTH, ENCRYPT and
SECURE. Starting with support for the Bluetooth 2.1 specification this is
no longer sufficient. The different security levels are now defined as
SDP, LOW, MEDIUM and SECURE.

Previously it was possible to set each security independently, but this
actually doesn't make a lot of sense. For Bluetooth the encryption depends
on a previous successful authentication. Also you can only update your
existing link key if you successfully created at least one before. And of
course the update of link keys without having proper encryption in place
is a security issue.

The new security levels from the Bluetooth 2.1 specification are now
used internally. All old settings are mapped to the new values and this
way it ensures that old applications still work. The only limitation
is that it is no longer possible to set authentication without also
enabling encryption. No application should have done this anyway since
this is actually a security issue. Without encryption the integrity of
the authentication can't be guaranteed.

As default for a new L2CAP or RFCOMM connection, the LOW security level
is used. The only exception here are the service discovery sessions on
PSM 1 where SDP level is used. To have similar security strength as with
a Bluetooth 2.0 and before combination key, the MEDIUM level should be
used. This is according to the Bluetooth specification. The MEDIUM level
will not require any kind of man-in-the-middle (MITM) protection. Only
the HIGH security level will require this.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>

Bluetooth: Fix SCO state handling for incoming connections

When the remote device supports only SCO connections, on receipt of
the HCI_EV_CONN_COMPLETE event packet, the connect state is changed to
BT_CONNECTED, but the socket state is not updated. Hence, the connect()
call times out even though the SCO connection has been successfully
established.

Based on a report by Jaikumar Ganesh <jaikumar@google.com>

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>

Bluetooth: Reject incoming SCO connections without listeners

All SCO and eSCO connection are auto-accepted no matter if there is a
corresponding listening socket for them. This patch changes this and
connection requests for SCO and eSCO without any socket are rejected.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>

Bluetooth: Add support for deferring L2CAP connection setup

In order to decide if listening L2CAP sockets should be accept()ed
the BD_ADDR of the remote device needs to be known. This patch adds
a socket option which defines a timeout for deferring the actual
connection setup.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>

Bluetooth: Add support for deferring RFCOMM connection setup

In order to decide if listening RFCOMM sockets should be accept()ed
the BD_ADDR of the remote device needs to be known. This patch adds
a socket option which defines a timeout for deferring the actual
connection setup.

The connection setup is done after reading from the socket for the
first time. Until then writing to the socket returns ENOTCONN.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>

Bluetooth: Add global deferred socket parameter

The L2CAP and RFCOMM applications require support for authorization
and the ability of rejecting incoming connection requests. The socket
interface is not really able to support this.

This patch does the ground work for a socket option to defer connection
setup. Setting this option allows calling of accept() and then the
first read() will trigger the final connection setup. Calling close()
would reject the connection.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>

Bluetooth: Preparation for usage of SOL_BLUETOOTH

The socket option levels SOL_L2CAP, SOL_RFOMM and SOL_SCO are currently
in use by various Bluetooth applications. Going forward the common
option level SOL_BLUETOOTH should be used. This patch prepares the clean
split of the old and new option levels while keeping everything backward
compatibility.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>

Bluetooth: Fix issue with return value of rfcomm_sock_sendmsg()

In case of connection failures the rfcomm_sock_sendmsg() should return
an error and not a 0 value.

Signed-off-by: Victor Shcherbatyuk <victor.shcherbatyuk@tomtom.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>

Merge branch 'master' of /linux/kernel/git/davem/net-2.6

Conflicts:
drivers/net/wireless/orinoco/orinoco.c

Merge branch 'master' of git://git./linux/kernel/git/linville/wireless-2.6

asix: new device ids

This patch adds two new device ids to the asix driver.

One comes directly from the asix driver on their web site, the other was
reported by Armani Liao as needed for the MSI X320 to get the driver to
work properly for it.

Reported-by: Armani Liao <aliao@novell.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: David S. Miller <davem@davemloft.net>

qlge: Use one path to (re)fill rx buffers.

Currently there are two paths for filling rx buffer queues. One is
used during initialization and the other during runtime.  This patch
removes ql_alloc_sbq_buffers() and ql_alloc_lbq_buffers() and replaces
them with a call to the runtime functions ql_update_lbq() and
ql_update_sbq().

Signed-off-by: Ron Mercer <ron.mercer@qlogic.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

qlge: Optimize rx buffer refill process.

RX Buffers are refilled in chunks of 16 at a time before notifying the
hardware with a register write.  This can cause several writes to take
place in a given napi poll call.  This change causes the write to take place
only once at the end of the call.

Signed-off-by: Ron Mercer <ron.mercer@qlogic.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

qlge: Change frame route hw semaphore granularity.

Instead of taking/giving the hw semaphore repeatedly when iterating over
several frame to queue route settings, we have the caller hold it until
all are done.
This reduces PCI bus chatter and possible waits.

Signed-off-by: Ron Mercer <ron.mercer@qlogic.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

qlge: Increase MAC addr hw sem granularity.

Instead of taking/giving the semaphore repeatedly when iterating over
several adderesses, we have the caller hold it until all are done.  This
reduces PCI bus chatter and possible waits.

Signed-off-by: Ron Mercer <ron.mercer@qlogic.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

qlge: Clean up mac address and frame route settings.

Setting MAC addresses and routing frames to various queues will need to
be done in response to firmware events as well as during initialization.
This change encapsulates the facilities into a single call that can
later me made from other places.

Signed-off-by: Ron Mercer <ron.mercer@qlogic.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

sit: used time_before for comparing jiffies

The functions time_before is more robust for comparing
jiffies against other values.

Signed-off-by: Wei Yongjun <yjwei@cn.fujitsu.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

ipip: used time_before for comparing jiffies

The functions time_before is more robust for comparing
jiffies against other values.

Signed-off-by: Wei Yongjun <yjwei@cn.fujitsu.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

gre: used time_before for comparing jiffies

The functions time_before is more robust for comparing
jiffies against other values.

Signed-off-by: Wei Yongjun <yjwei@cn.fujitsu.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

ipv6: Remove some pointless conditionals before kfree_skb()

Remove some pointless conditionals before kfree_skb().

The semantic match that finds the problem is as follows:
(http://www.emn.fr/x-info/coccinelle/)

// <smpl>
@@
expression E;
@@
- if (E)
-  kfree_skb(E);
+ kfree_skb(E);
// </smpl>

Signed-off-by: Wei Yongjun <yjwei@cn.fujitsu.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

netlink: change nlmsg_notify() return value logic

This patch changes the return value of nlmsg_notify() as follows:

If NETLINK_BROADCAST_ERROR is set by any of the listeners and
an error in the delivery happened, return the broadcast error;
else if there are no listeners apart from the socket that
requested a change with the echo flag, return the result of the
unicast notification. Thus, with this patch, the unicast
notification is handled in the same way of a broadcast listener
that has set the NETLINK_BROADCAST_ERROR socket flag.

This patch is useful in case that the caller of nlmsg_notify()
wants to know the result of the delivery of a netlink notification
(including the broadcast delivery) and take any action in case
that the delivery failed. For example, ctnetlink can drop packets
if the event delivery failed to provide reliable logging and
state-synchronization at the cost of dropping packets.

This patch also modifies the rtnetlink code to ignore the return
value of rtnl_notify() in all callers. The function rtnl_notify()
(before this patch) returned the error of the unicast notification
which makes rtnl_set_sk_err() reports errors to all listeners. This
is not of any help since the origin of the change (the socket that
requested the echoing) notices the ENOBUFS error if the notification
fails and should resync itself.

Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Acked-by: Patrick McHardy <kaber@trash.net>
Signed-off-by: David S. Miller <davem@davemloft.net>

mv643xx_eth: set sane default receive coalescing timeout

A receive coalescing timeout of 250 usec appears to strike a good
balance between allowing enough received frames to be aggregated for
LRO to do its job and not allowing the connection to stall due to
delaying ACKs to the remote end for too long.

Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

mv643xx_eth: move a couple of init actions from ->open() to port probe

Move the netif_carrier_off() call in ->open() to port probe, so that
ethtool doesn't report the link as being up before we have up'd the
interface.

Move initialisation of the rx/tx coalescing timers from ->open() to
port probe, so that we don't reset the coalescing timers every time
the interface is up'd.

Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

mv643xx_eth: convert to net_device_ops

Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

mv643xx_eth: make LRO unconditional

Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

tcp_scalable: Update malformed & dead url

Signed-off-by: Joe Perches <joe@perches.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

netxen: refactor pci probe

Split pci probe function into smaller logical blocks.

Signed-off-by: Dhananjay Phadke <dhananjay@netxen.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

netxen: cleanup unused code

Signed-off-by: Dhananjay Phadke <dhananjay@netxen.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

netxen: advertise wake-on-lan support

Add ethtool wake on lan support.

Signed-off-by: Dhananjay Phadke <dhananjay@netxen.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

netxen: firmware download support

Signed-off-by: Dhananjay Phadke <dhananjay@netxen.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

ixbge: fix bug when using large pages and jumbo frames

it was pointed out on the list that ixgbe was failing when using 64kB pages
and large 16kB MTU.

since with a 64kB PAGE_SIZE MAX_SKB_FRAGS = 3, the way the driver was
configuring page usage was assuming 2kB is half a page, and was only
ever dmaing that much data to a half page.

(16kB - header size) / 2048 = 7 or 8 pages, which would far exceed 3

adjust the driver to account for these large pages, the hardware can
support DMA to up to 16kB for each descriptor.

Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

ixgbe: Move ring features into an enum, allowing easier future maintenance

From: Shannon Nelson <shannon.nelson@intel.com>

The ring_feature member of ixgbe_adapter is statically allocated based on
the supported features of the device.  When a new feature is added, we need
to manually update the static allocation.  This patch makes the feature
list an enum, eliminating the need for multiple updates to the code when
adding a new feature.

Signed-off-by: Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

Merge branch 'master' of git://git./linux/kernel/git/kaber/nf-2.6

netfilter: xt_recent: fix proc-file addition/removal of IPv4 addresses

Fix regression introduded by commit 079aa88 (netfilter: xt_recent: IPv6 support):

From http://bugzilla.kernel.org/show_bug.cgi?id=12753:

Problem Description:
An uninitialized buffer causes IPv4 addresses added manually (via the +IP
command to the proc interface) to never match any packets. Similarly, the -IP
command fails to remove IPv4 addresses.

Details:
In the function recent_entry_lookup, the xt_recent module does comparisons of
the entire nf_inet_addr union value, both for IPv4 and IPv6 addresses. For
addresses initialized from actual packets the remaining 12 bytes not occupied
by the IPv4 are zeroed so this works correctly. However when setting the
nf_inet_addr addr variable in the recent_mt_proc_write function, only the IPv4
bytes are initialized and the remaining 12 bytes contain garbage.

Hence addresses added in this way never match any packets, unless these
uninitialized 12 bytes happened to be zero by coincidence. Similarly, addresses
cannot consistently be removed using the proc interface due to mismatch of the
garbage bytes (although it will sometimes work to remove an address that was
added manually).

Reading the /proc/net/xt_recent/ entries hides this problem because this only
uses the first 4 bytes when displaying IPv4 addresses.

Steps to reproduce:
$ iptables -I INPUT -m recent --rcheck -j LOG
$ echo +169.254.156.239 > /proc/net/xt_recent/DEFAULT
$ cat /proc/net/xt_recent/DEFAULT
src=169.254.156.239 ttl: 0 last_seen: 119910 oldest_pkt: 1 119910

[At this point no packets from 169.254.156.239 are being logged.]

$ iptables -I INPUT -s 169.254.156.239 -m recent --set
$ cat /proc/net/xt_recent/DEFAULT
src=169.254.156.239 ttl: 0 last_seen: 119910 oldest_pkt: 1 119910
src=169.254.156.239 ttl: 255 last_seen: 126184 oldest_pkt: 4 125434, 125684, 125934, 126184

[At this point, adding the address via an iptables rule, packets are being
logged correctly.]

$ echo -169.254.156.239 > /proc/net/xt_recent/DEFAULT
$ cat /proc/net/xt_recent/DEFAULT
src=169.254.156.239 ttl: 0 last_seen: 119910 oldest_pkt: 1 119910
src=169.254.156.239 ttl: 255 last_seen: 126992 oldest_pkt: 10 125434, 125684, 125934, 126184, 126434, 126684, 126934, 126991, 126991, 126992
$ echo -169.254.156.239 > /proc/net/xt_recent/DEFAULT
$ cat /proc/net/xt_recent/DEFAULT
src=169.254.156.239 ttl: 0 last_seen: 119910 oldest_pkt: 1 119910
src=169.254.156.239 ttl: 255 last_seen: 126992 oldest_pkt: 10 125434, 125684, 125934, 126184, 126434, 126684, 126934, 126991, 126991, 126992

[Removing the address via /proc interface failed evidently.]

Possible solutions:
- initialize the addr variable in recent_mt_proc_write
- compare only 4 bytes for IPv4 addresses in recent_entry_lookup

Signed-off-by: Patrick McHardy <kaber@trash.net>

Merge branch 'master' of /linux/kernel/git/davem/net-2.6

Merge branch 'master' of /home/davem/src/GIT/linux-2.6/

Merge branch 'master' of /home/davem/src/GIT/linux-2.6/

Doc: Refer to ip-sysctl.txt for strict vs. loose rp_filter mode

The IP_ADVANCED_ROUTER Kconfig describes the rp_filter
proc option.  Recent changes added a loose mode.
Instead of documenting this change too places, refer to
the document describing it:
 Documentation/networking/ip-sysctl.txt

I'm considering moving the rp_filter description away
from the Kconfig file into ip-sysctl.txt.

Signed-off-by: Jesper Dangaard Brouer <hawk@comx.dk>
Signed-off-by: David S. Miller <davem@davemloft.net>

Doc: Cleanup whitespaces in ip-sysctl.txt

Fix up whitespaces while going though ip-sysctl.txt anyway.

Signed-off-by: Jesper Dangaard Brouer <hawk@comx.dk>
Signed-off-by: David S. Miller <davem@davemloft.net>

Doc: Fix typos in ip-sysctl.txt about rp_filter.

First fix a typo in Stephens patch ;-)

Signed-off-by: Jesper Dangaard Brouer <hawk@comx.dk>
Signed-off-by: David S. Miller <davem@davemloft.net>

netxen: handle pci bar 0 mapping failure

PCI bar 0 is used for memory mapped register access.
If ioremap fails (returns NULL), register access results
in crash.

Use pci_ioremap_bar() instead of ioremap(), the latter
fails on on 32 bit powerpc where pci resource address is
> 32 bits.

Signed-off-by: Dhananjay Phadke <dhananjay@netxen.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

netxen: fix physical port mapping

The PCI function to physical port mapping is valid only for
old firmware. New firmware (4.0.0+) abstracts this.
So driver should never try to access phy using invalid
mapping. The behavior is unpredictable when PCI functions
4-7 are enabled on the same NIC.

Signed-off-by: Dhananjay Phadke <dhananjay@netxen.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

Merge git://git./linux/kernel/git/davem/net-2.6

* git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6:
  net: amend the fix for SO_BSDCOMPAT gsopt infoleak
  netns: build fix for net_alloc_generic

proc: proc_get_inode should de_put when inode already initialized

de_get is called before every proc_get_inode, but corresponding de_put is
called only when dropping last reference to an inode. This might cause
something like
remove_proc_entry: /proc/stats busy, count=14496
to be printed to the syslog.

The fix is to call de_put in case of an already initialized inode in
proc_get_inode.

Signed-off-by: Krzysztof Sachanowicz <analyzer1@gmail.com>
Tested-by: Marcin Pilipczuk <marcin.pilipczuk@gmail.com>
Acked-by: Al Viro <viro@ZenIV.linux.org.uk>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>