Commit Graph

279049 Commits

Author SHA1 Message Date
Xi Wang a0a129f8b6 rps: fix insufficient bounds checking in store_rps_dev_flow_table_cnt()
Setting a large rps_flow_cnt like (1 << 30) on 32-bit platform will
cause a kernel oops due to insufficient bounds checking.

	if (count > 1<<30) {
		/* Enforce a limit to prevent overflow */
		return -EINVAL;
	}
	count = roundup_pow_of_two(count);
	table = vmalloc(RPS_DEV_FLOW_TABLE_SIZE(count));

Note that the macro RPS_DEV_FLOW_TABLE_SIZE(count) is defined as:

	... + (count * sizeof(struct rps_dev_flow))

where sizeof(struct rps_dev_flow) is 8.  (1 << 30) * 8 will overflow
32 bits.

This patch replaces the magic number (1 << 30) with a symbolic bound.

Suggested-by: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: Xi Wang <xi.wang@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2011-12-22 22:34:56 -05:00
Eric Dumazet e688a60480 net: introduce DST_NOPEER dst flag
Chris Boot reported crashes occurring in ipv6_select_ident().

[  461.457562] RIP: 0010:[<ffffffff812dde61>]  [<ffffffff812dde61>]
ipv6_select_ident+0x31/0xa7

[  461.578229] Call Trace:
[  461.580742] <IRQ>
[  461.582870]  [<ffffffff812efa7f>] ? udp6_ufo_fragment+0x124/0x1a2
[  461.589054]  [<ffffffff812dbfe0>] ? ipv6_gso_segment+0xc0/0x155
[  461.595140]  [<ffffffff812700c6>] ? skb_gso_segment+0x208/0x28b
[  461.601198]  [<ffffffffa03f236b>] ? ipv6_confirm+0x146/0x15e
[nf_conntrack_ipv6]
[  461.608786]  [<ffffffff81291c4d>] ? nf_iterate+0x41/0x77
[  461.614227]  [<ffffffff81271d64>] ? dev_hard_start_xmit+0x357/0x543
[  461.620659]  [<ffffffff81291cf6>] ? nf_hook_slow+0x73/0x111
[  461.626440]  [<ffffffffa0379745>] ? br_parse_ip_options+0x19a/0x19a
[bridge]
[  461.633581]  [<ffffffff812722ff>] ? dev_queue_xmit+0x3af/0x459
[  461.639577]  [<ffffffffa03747d2>] ? br_dev_queue_push_xmit+0x72/0x76
[bridge]
[  461.646887]  [<ffffffffa03791e3>] ? br_nf_post_routing+0x17d/0x18f
[bridge]
[  461.653997]  [<ffffffff81291c4d>] ? nf_iterate+0x41/0x77
[  461.659473]  [<ffffffffa0374760>] ? br_flood+0xfa/0xfa [bridge]
[  461.665485]  [<ffffffff81291cf6>] ? nf_hook_slow+0x73/0x111
[  461.671234]  [<ffffffffa0374760>] ? br_flood+0xfa/0xfa [bridge]
[  461.677299]  [<ffffffffa0379215>] ?
nf_bridge_update_protocol+0x20/0x20 [bridge]
[  461.684891]  [<ffffffffa03bb0e5>] ? nf_ct_zone+0xa/0x17 [nf_conntrack]
[  461.691520]  [<ffffffffa0374760>] ? br_flood+0xfa/0xfa [bridge]
[  461.697572]  [<ffffffffa0374812>] ? NF_HOOK.constprop.8+0x3c/0x56
[bridge]
[  461.704616]  [<ffffffffa0379031>] ?
nf_bridge_push_encap_header+0x1c/0x26 [bridge]
[  461.712329]  [<ffffffffa037929f>] ? br_nf_forward_finish+0x8a/0x95
[bridge]
[  461.719490]  [<ffffffffa037900a>] ?
nf_bridge_pull_encap_header+0x1c/0x27 [bridge]
[  461.727223]  [<ffffffffa0379974>] ? br_nf_forward_ip+0x1c0/0x1d4 [bridge]
[  461.734292]  [<ffffffff81291c4d>] ? nf_iterate+0x41/0x77
[  461.739758]  [<ffffffffa03748cc>] ? __br_deliver+0xa0/0xa0 [bridge]
[  461.746203]  [<ffffffff81291cf6>] ? nf_hook_slow+0x73/0x111
[  461.751950]  [<ffffffffa03748cc>] ? __br_deliver+0xa0/0xa0 [bridge]
[  461.758378]  [<ffffffffa037533a>] ? NF_HOOK.constprop.4+0x56/0x56
[bridge]

This is caused by bridge netfilter special dst_entry (fake_rtable), a
special shared entry, where attaching an inetpeer makes no sense.

Problem is present since commit 87c48fa3b4 (ipv6: make fragment
identifications less predictable)

Introduce DST_NOPEER dst flag and make sure ipv6_select_ident() and
__ip_select_ident() fallback to the 'no peer attached' handling.

Reported-by: Chris Boot <bootc@bootc.net>
Tested-by: Chris Boot <bootc@bootc.net>
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2011-12-22 22:34:56 -05:00
Thomas Graf 7838f2ce36 mqprio: Avoid panic if no options are provided
Userspace may not provide TCA_OPTIONS, in fact tc currently does
so not do so if no arguments are specified on the command line.
Return EINVAL instead of panicing.

Signed-off-by: Thomas Graf <tgraf@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2011-12-22 22:34:56 -05:00
Eric Dumazet a13861a28b bridge: provide a mtu() method for fake_dst_ops
Commit 618f9bc74a (net: Move mtu handling down to the protocol
depended handlers) forgot the bridge netfilter case, adding a NULL
dereference in ip_fragment().

Reported-by: Chris Boot <bootc@bootc.net>
CC: Steffen Klassert <steffen.klassert@secunet.com>
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Acked-by: Steffen Klassert <steffen.klassert@secunet.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2011-12-22 22:34:56 -05:00
Linus Torvalds ad1fca2003 Merge branch 'for-linus' of git://neil.brown.name/md
* 'for-linus' of git://neil.brown.name/md:
  md/bitmap: It is OK to clear bits during recovery.
  md: don't give up looking for spares on first failure-to-add
  md/raid5: ensure correct assessment of drives during degraded reshape.
  md/linear: fix hot-add of devices to linear arrays.
2011-12-22 15:36:17 -08:00
NeilBrown 961902c0f8 md/bitmap: It is OK to clear bits during recovery.
commit d0a4bb4927 introduced a
regression which is annoying but fairly harmless.

When writing to an array that is undergoing recovery (a spare
in being integrated into the array), writing to the array will
set bits in the bitmap, but they will not be cleared when the
write completes.

For bits covering areas that have not been recovered yet this is not a
problem as the recovery will clear the bits.  However bits set in
already-recovered region will stay set and never be cleared.
This doesn't risk data integrity.  The only negatives are:
 - next time there is a crash, more resyncing than necessary will
   be done.
 - the bitmap doesn't look clean, which is confusing.

While an array is recovering we don't want to update the
'events_cleared' setting in the bitmap but we do still want to clear
bits that have very recently been set - providing they were written to
the recovering device.

So split those two needs - which previously both depended on 'success'
and always clear the bit of the write went to all devices.

Signed-off-by: NeilBrown <neilb@suse.de>
2011-12-23 09:57:48 +11:00
NeilBrown 60fc13702a md: don't give up looking for spares on first failure-to-add
Before performing a recovery we try to remove any spares that
might not be working, then add any that might have become relevant.

Currently we abort on the first spare that cannot be added.
This is a false optimisation.
It is conceivable that - depending on rules in the personality - a
subsequent spare might be accepted.
Also the loop does other things like count the available spares and
reset the 'recovery_offset' value.

If we abort early these might not happen properly.

So remove the early abort.

In particular if you have an array what is undergoing recovery and
which has extra spares, then the recovery may not restart after as
reboot as the could of 'spares' might end up as zero.

Reported-by: Anssi Hannula <anssi.hannula@iki.fi>
Signed-off-by: NeilBrown <neilb@suse.de>
2011-12-23 09:57:19 +11:00
NeilBrown 30d7a48368 md/raid5: ensure correct assessment of drives during degraded reshape.
While reshaping a degraded array (as when reshaping a RAID0 by first
converting it to a degraded RAID4) we currently get confused about
which devices are in_sync.  In most cases we get it right, but in the
region that is being reshaped we need to treat non-failed devices as
in-sync when we have the data but haven't actually written it out yet.

Reported-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
2011-12-23 09:57:00 +11:00
NeilBrown 09cd9270ea md/linear: fix hot-add of devices to linear arrays.
commit d70ed2e4fa
broke hot-add to a linear array.
After that commit, metadata if not written to devices until they
have been fully integrated into the array as determined by
saved_raid_disk.  That patch arranged to clear that field after
a recovery completed.

However for linear arrays, there is no recovery - the integration is
instantaneous.  So we need to explicitly clear the saved_raid_disk
field.

Signed-off-by: NeilBrown <neilb@suse.de>
2011-12-23 09:56:55 +11:00
David S. Miller 7cc8583372 sparc64: Fix MSIQ HV call ordering in pci_sun4v_msiq_build_irq().
This silently was working for many years and stopped working on
Niagara-T3 machines.

We need to set the MSIQ to VALID before we can set it's state to IDLE.

On Niagara-T3, setting the state to IDLE first was causing HV_EINVAL
errors.  The hypervisor documentation says, rather ambiguously, that
the MSIQ must be "initialized" before one can set the state.

I previously understood this to mean merely that a successful setconf()
operation has been performed on the MSIQ, which we have done at this
point.  But it seems to also mean that it has been set VALID too.

Signed-off-by: David S. Miller <davem@davemloft.net>
2011-12-22 13:46:53 -08:00
Linus Torvalds b3b1b70e62 Merge branch 'usb-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb
* 'usb-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb:
  USB: Fix usb/isp1760 build on sparc
  usb: gadget: epautoconf: do not change number of streams
  usb: dwc3: core: fix cached revision on our structure
  usb: musb: fix reset issue with full speed device
2011-12-22 12:59:47 -08:00
Linus Torvalds abe8809c14 Merge branch 'upstream-linus' of git://github.com/jgarzik/libata-dev
* 'upstream-linus' of git://github.com/jgarzik/libata-dev:
  pata_of_platform: Add missing CONFIG_OF_IRQ dependency.
2011-12-22 12:53:32 -08:00
Gustavo F. Padovan af3e6359a2 Bluetooth: Don't disable interrupt when locking the queue
We run everything in process context now.

Acked-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
2011-12-22 18:07:01 -02:00
Gustavo F. Padovan f20d09d5f7 Bluetooth: remove *_bh usage from hci_dev_list and hci_cb_list
They don't need to disable interrupts anymore, we only run in process
context now.

Acked-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
2011-12-22 18:06:24 -02:00
Gustavo F. Padovan 460da45d92 Bluetooth: Remove lock from inquiry_cache
It was never used, so removing it.

Acked-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
2011-12-22 18:02:06 -02:00
Gustavo F. Padovan 2fb9b3d4e5 Bluetooth: add debug output to l2cap_ack_timeout()
Acked-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
2011-12-22 18:00:54 -02:00
David Miller 19d40dcabf pata_of_platform: Add missing CONFIG_OF_IRQ dependency.
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
2011-12-22 15:00:32 -05:00
Stephen Rothwell b9eda06f80 ipv4: using prefetch requires including prefetch.h
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
Acked-by: Eric Dumazet <eric.dumazet@gmail.com>
Acked-by: David Miller <davem@davemloft.net>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2011-12-22 09:16:09 -08:00
Gustavo F. Padovan 5436538fb5 Bluetooth: Remove l2cap priority from inside RFCOMM.
RFCOMM needs a proper priority mechanism inside itself and not try to use
l2cap priority to fix its own problem.

Acked-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
2011-12-22 14:45:10 -02:00
Jesse Sung c0190925da Bluetooth: Add support for BCM20702A0 [0a5c:21e3]
Add another vendor specific ID for BCM20702A0.

output of usb-devices:
T: Bus=06 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 4 Spd=12 MxCh= 0
D: Ver= 2.00 Cls=ff(vend.) Sub=01 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=0a5c ProdID=21e3 Rev=01.12
S: Manufacturer=Broadcom Corp
S: Product=BCM20702A0
S: SerialNumber=9439E5CBF66C
C: #Ifs= 4 Cfg#= 1 Atr=e0 MxPwr=0mA
I: If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=01 Prot=01 Driver=(none)
I: If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=(none)
I: If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
I: If#= 3 Alt= 0 #EPs= 0 Cls=fe(app. ) Sub=01 Prot=01 Driver=(none)

Signed-off-by: Wen-chien Jesse Sung <jesse.sung@canonical.com>
Acked-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
2011-12-22 14:20:03 -02:00
Brian Gix 5fe57d9e9e Bluetooth: Add SMP to User Passkey and Confirm
Low Energy pairing is performed through the SMP (Security Manager Protocol)
mechanism rather than HCI.

Signed-off-by: Brian Gix <bgix@codeaurora.org>
Acked-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
2011-12-22 14:19:03 -02:00
Brian Gix 2b64d153a0 Bluetooth: Add MITM mechanism to LE-SMP
To achive Man-In-The-Middle (MITM) level security with Low Energy,
we have to enable User Passkey Comparison.  This commit modifies the
hard-coded JUST-WORKS pairing mechanism to support query via the MGMT
interface of Passkey comparison and User Confirmation.

Signed-off-by: Brian Gix <bgix@codeaurora.org>
Acked-by: Marcel Holtmann<marcel@holtmann.org>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
2011-12-22 14:18:59 -02:00
Ulisses Furquim 371fd83563 Bluetooth: Fix deadlocks with sock lock and L2CAP timers locks
When cancelling a delayed work (timer) in L2CAP we can not sleep holding
the sock mutex otherwise we might deadlock with an L2CAP timer handler.
This is possible because RX/TX and L2CAP timers run in different workqueues.
The scenario below illustrates the problem. Thus we are now avoiding to
sleep on the timers locks.

 ======================================================
 [ INFO: possible circular locking dependency detected ]
 3.1.0-05270-ga978dc7-dirty #239
 -------------------------------------------------------
 kworker/1:1/873 is trying to acquire lock:
  (sk_lock-AF_BLUETOOTH-BTPROTO_L2CAP){+.+...}, at: [<ffffffffa002ceac>] l2cap_chan_timeout+0x3c/0xe0 [bluetooth]

 but task is already holding lock:
  ((&(&chan->chan_timer)->work)){+.+...}, at: [<ffffffff81051a86>] process_one_work+0x126/0x450

 which lock already depends on the new lock.

 the existing dependency chain (in reverse order) is:

 -> #1 ((&(&chan->chan_timer)->work)){+.+...}:
        [<ffffffff8106b276>] check_prevs_add+0xf6/0x170
        [<ffffffff8106b903>] validate_chain+0x613/0x790
        [<ffffffff8106dfee>] __lock_acquire+0x4be/0xac0
        [<ffffffff8106ec2d>] lock_acquire+0x8d/0xb0
        [<ffffffff81052a6f>] wait_on_work+0x4f/0x160
        [<ffffffff81052ca3>] __cancel_work_timer+0x73/0x80
        [<ffffffff81052cbd>] cancel_delayed_work_sync+0xd/0x10
        [<ffffffffa002f2ed>] l2cap_chan_connect+0x22d/0x470 [bluetooth]
        [<ffffffffa002fb51>] l2cap_sock_connect+0xb1/0x140 [bluetooth]
        [<ffffffff8130811b>] kernel_connect+0xb/0x10
        [<ffffffffa00cf98a>] rfcomm_session_create+0x12a/0x1c0 [rfcomm]
        [<ffffffffa00cfbe7>] __rfcomm_dlc_open+0x1c7/0x240 [rfcomm]
        [<ffffffffa00d07c2>] rfcomm_dlc_open+0x42/0x70 [rfcomm]
        [<ffffffffa00d3b03>] rfcomm_sock_connect+0x103/0x150 [rfcomm]
        [<ffffffff8130bd7e>] sys_connect+0xae/0xc0
        [<ffffffff813368d2>] compat_sys_socketcall+0xb2/0x220
        [<ffffffff813b2089>] sysenter_dispatch+0x7/0x30

 -> #0 (sk_lock-AF_BLUETOOTH-BTPROTO_L2CAP){+.+...}:
        [<ffffffff8106b16d>] check_prev_add+0x6cd/0x6e0
        [<ffffffff8106b276>] check_prevs_add+0xf6/0x170
        [<ffffffff8106b903>] validate_chain+0x613/0x790
        [<ffffffff8106dfee>] __lock_acquire+0x4be/0xac0
        [<ffffffff8106ec2d>] lock_acquire+0x8d/0xb0
        [<ffffffff8130d91a>] lock_sock_nested+0x8a/0xa0
        [<ffffffffa002ceac>] l2cap_chan_timeout+0x3c/0xe0 [bluetooth]
        [<ffffffff81051ae4>] process_one_work+0x184/0x450
        [<ffffffff8105276e>] worker_thread+0x15e/0x340
        [<ffffffff81057bb6>] kthread+0x96/0xa0
        [<ffffffff813b1ef4>] kernel_thread_helper+0x4/0x10

 other info that might help us debug this:

  Possible unsafe locking scenario:

        CPU0                    CPU1
        ----                    ----
   lock((&(&chan->chan_timer)->work));
                                lock(sk_lock-AF_BLUETOOTH-BTPROTO_L2CAP);
                                lock((&(&chan->chan_timer)->work));
   lock(sk_lock-AF_BLUETOOTH-BTPROTO_L2CAP);

  *** DEADLOCK ***

 2 locks held by kworker/1:1/873:
  #0:  (events){.+.+.+}, at: [<ffffffff81051a86>] process_one_work+0x126/0x450
  #1:  ((&(&chan->chan_timer)->work)){+.+...}, at: [<ffffffff81051a86>] process_one_work+0x126/0x450

 stack backtrace:
 Pid: 873, comm: kworker/1:1 Not tainted 3.1.0-05270-ga978dc7-dirty #239
 Call Trace:
  [<ffffffff813a0f6e>] print_circular_bug+0xd2/0xe3
  [<ffffffff8106b16d>] check_prev_add+0x6cd/0x6e0
  [<ffffffff8106b276>] check_prevs_add+0xf6/0x170
  [<ffffffff8106b903>] validate_chain+0x613/0x790
  [<ffffffff8106dfee>] __lock_acquire+0x4be/0xac0
  [<ffffffff8130d8f6>] ? lock_sock_nested+0x66/0xa0
  [<ffffffff8106ea30>] ? lock_release_nested+0x100/0x110
  [<ffffffff8130d8f6>] ? lock_sock_nested+0x66/0xa0
  [<ffffffff8106ec2d>] lock_acquire+0x8d/0xb0
  [<ffffffffa002ceac>] ? l2cap_chan_timeout+0x3c/0xe0 [bluetooth]
  [<ffffffff8130d91a>] lock_sock_nested+0x8a/0xa0
  [<ffffffffa002ceac>] ? l2cap_chan_timeout+0x3c/0xe0 [bluetooth]
  [<ffffffff81051a86>] ? process_one_work+0x126/0x450
  [<ffffffffa002ceac>] l2cap_chan_timeout+0x3c/0xe0 [bluetooth]
  [<ffffffff81051ae4>] process_one_work+0x184/0x450
  [<ffffffff81051a86>] ? process_one_work+0x126/0x450
  [<ffffffffa002ce70>] ? l2cap_security_cfm+0x4e0/0x4e0 [bluetooth]
  [<ffffffff8105276e>] worker_thread+0x15e/0x340
  [<ffffffff81052610>] ? manage_workers+0x110/0x110
  [<ffffffff81057bb6>] kthread+0x96/0xa0
  [<ffffffff813b1ef4>] kernel_thread_helper+0x4/0x10
  [<ffffffff813af69d>] ? retint_restore_args+0xe/0xe
  [<ffffffff81057b20>] ? __init_kthread_worker+0x70/0x70
  [<ffffffff813b1ef0>] ? gs_change+0xb/0xb

Signed-off-by: Ulisses Furquim <ulisses@profusion.mobi>
Acked-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
2011-12-22 14:15:09 -02:00
Ulisses Furquim 686ebf283b Bluetooth: Make HCI call directly into SCO and L2CAP event functions
The struct hci_proto and all related register/unregister and dispatching
code was removed. HCI core code now call directly the SCO and L2CAP
event functions.

Signed-off-by: Ulisses Furquim <ulisses@profusion.mobi>
Acked-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
2011-12-22 14:07:29 -02:00
Andrei Emeltchenko 68a8aea459 Bluetooth: Remove magic numbers from le scan cmd
Make code readable by removing magic numbers.

Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@intel.com>
Acked-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
2011-12-22 14:03:24 -02:00
Gustavo F. Padovan 8a154a8feb Bluetooth: fix bt_accept_dequeue() to work in process context
No local_bh_disable is needed there once we run everything in process
context. The same goes for the replacement of bh_lock_sock() by
lock_sock().

Acked-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
2011-12-22 14:02:08 -02:00
Xi Wang 8a78389651 vmwgfx: fix incorrect VRAM size check in vmw_kms_fb_create()
Commit e133e737 didn't correctly fix the integer overflow issue.

-	unsigned int required_size;
+	u64 required_size;
	...
	required_size = mode_cmd->pitch * mode_cmd->height;
-	if (unlikely(required_size > dev_priv->vram_size)) {
+	if (unlikely(required_size > (u64) dev_priv->vram_size)) {

Note that both pitch and height are u32.  Their product is still u32 and
would overflow before being assigned to required_size.  A correct way is
to convert pitch and height to u64 before the multiplication.

	required_size = (u64)mode_cmd->pitch * (u64)mode_cmd->height;

This patch calls the existing vmw_kms_validate_mode_vram() for
validation.

Signed-off-by: Xi Wang <xi.wang@gmail.com>
Reviewed-and-tested-by: Thomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2011-12-22 12:31:02 +00:00
Alex Deucher 77e00f2ea9 drm/radeon/kms: bail on BTC parts if MC ucode is missing
We already do this for cayman, need to also do it for
BTC parts.  The default memory and voltage setup is not
adequate for advanced operation.  Continuing will
result in an unusable display.

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@kernel.org
Cc: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2011-12-22 12:28:01 +00:00
Srivatsa S. Bhat e30e2fdfe5 VFS: Fix race between CPU hotplug and lglocks
Currently, the *_global_[un]lock_online() routines are not at all synchronized
with CPU hotplug. Soft-lockups detected as a consequence of this race was
reported earlier at https://lkml.org/lkml/2011/8/24/185. (Thanks to Cong Meng
for finding out that the root-cause of this issue is the race condition
between br_write_[un]lock() and CPU hotplug, which results in the lock states
getting messed up).

Fixing this race by just adding {get,put}_online_cpus() at appropriate places
in *_global_[un]lock_online() is not a good option, because, then suddenly
br_write_[un]lock() would become blocking, whereas they have been kept as
non-blocking all this time, and we would want to keep them that way.

So, overall, we want to ensure 3 things:
1. br_write_lock() and br_write_unlock() must remain as non-blocking.
2. The corresponding lock and unlock of the per-cpu spinlocks must not happen
   for different sets of CPUs.
3. Either prevent any new CPU online operation in between this lock-unlock, or
   ensure that the newly onlined CPU does not proceed with its corresponding
   per-cpu spinlock unlocked.

To achieve all this:
(a) We introduce a new spinlock that is taken by the *_global_lock_online()
    routine and released by the *_global_unlock_online() routine.
(b) We register a callback for CPU hotplug notifications, and this callback
    takes the same spinlock as above.
(c) We maintain a bitmap which is close to the cpu_online_mask, and once it is
    initialized in the lock_init() code, all future updates to it are done in
    the callback, under the above spinlock.
(d) The above bitmap is used (instead of cpu_online_mask) while locking and
    unlocking the per-cpu locks.

The callback takes the spinlock upon the CPU_UP_PREPARE event. So, if the
br_write_lock-unlock sequence is in progress, the callback keeps spinning,
thus preventing the CPU online operation till the lock-unlock sequence is
complete. This takes care of requirement (3).

The bitmap that we maintain remains unmodified throughout the lock-unlock
sequence, since all updates to it are managed by the callback, which takes
the same spinlock as the one taken by the lock code and released only by the
unlock routine. Combining this with (d) above, satisfies requirement (2).

Overall, since we use a spinlock (mentioned in (a)) to prevent CPU hotplug
operations from racing with br_write_lock-unlock, requirement (1) is also
taken care of.

By the way, it is to be noted that a CPU offline operation can actually run
in parallel with our lock-unlock sequence, because our callback doesn't react
to notifications earlier than CPU_DEAD (in order to maintain our bitmap
properly). And this means, since we use our own bitmap (which is stale, on
purpose) during the lock-unlock sequence, we could end up unlocking the
per-cpu lock of an offline CPU (because we had locked it earlier, when the
CPU was online), in order to satisfy requirement (2). But this is harmless,
though it looks a bit awkward.

Debugged-by: Cong Meng <mc@linux.vnet.ibm.com>
Signed-off-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Cc: stable@vger.kernel.org
2011-12-22 02:02:20 -05:00
Linus Torvalds ecefc36b41 Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net
* git://git.kernel.org/pub/scm/linux/kernel/git/davem/net:
  net: Add a flow_cache_flush_deferred function
  ipv4: reintroduce route cache garbage collector
  net: have ipconfig not wait if no dev is available
  sctp: Do not account for sizeof(struct sk_buff) in estimated rwnd
  asix: new device id
  davinci-cpdma: fix locking issue in cpdma_chan_stop
  sctp: fix incorrect overflow check on autoclose
  r8169: fix Config2 MSIEnable bit setting.
  llc: llc_cmsg_rcv was getting called after sk_eat_skb.
  net: bpf_jit: fix an off-one bug in x86_64 cond jump target
  iwlwifi: update SCD BC table for all SCD queues
  Revert "Bluetooth: Revert: Fix L2CAP connection establishment"
  Bluetooth: Clear RFCOMM session timer when disconnecting last channel
  Bluetooth: Prevent uninitialized data access in L2CAP configuration
  iwlwifi: allow to switch to HT40 if not associated
  iwlwifi: tx_sync only on PAN context
  mwifiex: avoid double list_del in command cancel path
  ath9k: fix max phy rate at rate control init
  nfc: signedness bug in __nci_request()
  iwlwifi: do not set the sequence control bit is not needed
2011-12-21 18:29:26 -08:00
Linus Torvalds d5ed5e48f4 Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound:
  ALSA: atmel/ac97c: using software reset instead hardware reset if not available
2011-12-21 18:29:05 -08:00
Linus Torvalds 0703c680f6 Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/sameo/mfd-2.6
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/sameo/mfd-2.6:
  mfd: Include linux/io.h to jz4740-adc
  mfd: Use request_threaded_irq for twl4030-irq instead of irq_set_chained_handler
  mfd: Base interrupt for twl4030-irq must be one-shot
  mfd: Handle tps65910 clear-mask correctly
  mfd: add #ifdef CONFIG_DEBUG_FS guard for ab8500_debug_resources
  mfd: Fix twl-core oops while calling twl_i2c_* for unbound driver
  mfd: include linux/module.h for ab5500-debugfs
  mfd: Update wm8994 active device checks for WM1811
  mfd: Set tps6586x bits if new value is different from the old one
  mfd: Set da903x bits if new value is different from the old one
  mfd: Set adp5520 bits if new value is different from the old one
  mfd: Add missed free_irq in da903x_remove
2011-12-21 18:28:52 -08:00
Dave Kleikamp e6f67b8c05 vfs: __read_cache_page should use gfp argument rather than GFP_KERNEL
lockdep reports a deadlock in jfs because a special inode's rw semaphore
is taken recursively.  The mapping's gfp mask is GFP_NOFS, but is not
used when __read_cache_page() calls add_to_page_cache_lru().

Signed-off-by: Dave Kleikamp <dave.kleikamp@oracle.com>
Acked-by: Hugh Dickins <hughd@google.com>
Acked-by: Al Viro <viro@zeniv.linux.org.uk>
Cc: stable@kernel.org
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2011-12-21 17:02:46 -08:00
Greg Kroah-Hartman 341f5b1080 Merge branch 'for-greg' of git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb into usb-linus
* 'for-greg' of git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb:
  usb: gadget: epautoconf: do not change number of streams
  usb: dwc3: core: fix cached revision on our structure
  usb: musb: fix reset issue with full speed device
2011-12-21 14:42:49 -08:00
David Miller abf058e10c USB: Fix usb/isp1760 build on sparc
This commit:

commit 8f5d621543
Author: Joachim Foerster <joachim.foerster@missinglinkelectronics.com>
Date:   Mon Oct 10 18:06:54 2011 +0200

    usb/isp1760: Let OF bindings depend on general CONFIG_OF instead of PPC_OF .

    To be able to use the driver on other OF-aware architectures, too.
    And add necessary OF related #includes to fix compilation error.

    Signed-off-by: Joachim Foerster <joachim.foerster@missinglinkelectronics.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

enabled the build on all CONFIG_OF architectures, but it cannot do
this.

This driver depends upon CONFIG_OF_IRQ but not all CONFIG_OF platforms
support that infrastructure, in particular Sparc does not so the
build fails.

Please push a patch like the following to Linus so that this code only
gets built where it actually should.

--------------------
usb/isp1760: Add missing CONFIG_OF_IRQ dependency on OF code.

Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-12-21 14:41:04 -08:00
Steffen Klassert c0ed1c14a7 net: Add a flow_cache_flush_deferred function
flow_cach_flush() might sleep but can be called from
atomic context via the xfrm garbage collector. So add
a flow_cache_flush_deferred() function and use this if
the xfrm garbage colector is invoked from within the
packet path.

Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
Acked-by: Timo Teräs <timo.teras@iki.fi>
Signed-off-by: David S. Miller <davem@davemloft.net>
2011-12-21 16:48:08 -05:00
Eric Dumazet 9f28a2fc0b ipv4: reintroduce route cache garbage collector
Commit 2c8cec5c10 (ipv4: Cache learned PMTU information in inetpeer)
removed IP route cache garbage collector a bit too soon, as this gc was
responsible for expired routes cleanup, releasing their neighbour
reference.

As pointed out by Robert Gladewitz, recent kernels can fill and exhaust
their neighbour cache.

Reintroduce the garbage collection, since we'll have to wait our
neighbour lookups become refcount-less to not depend on this stuff.

Reported-by: Robert Gladewitz <gladewitz@gmx.de>
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2011-12-21 15:47:16 -05:00
Xi Wang 7d6c429b26 irda: use msecs_to_jiffies() rather than manual calculation
Also use mod_timer() instead of direct assignment to "expires".

Signed-off-by: Xi Wang <xi.wang@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2011-12-21 15:46:22 -05:00
Giuseppe CAVALLARO 5b9932685f stmmac: update the driver's documentation (Dec-2011)
Signed-off-by: Giuseppe Cavallaro <peppe.cavallaro@st.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2011-12-21 15:44:34 -05:00
Giuseppe CAVALLARO bfab27a146 stmmac: add the experimental PCI support
This patch adds the PCI support (as EXPERIMENTAL)
this has been also tested on XLINX XC2V3000 FF1152AMT0221
D1215994A VIRTEX FPGA board.
To support the PCI bus the main part has been reworked
and both the platform and the PCI specific parts have
been moved into different files.

Signed-off-by: Rayagond Kokatanur <rayagond@vayavyalabs.com>
Signed-off-by: Giuseppe Cavallaro <peppe.cavallaro@st.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2011-12-21 15:44:34 -05:00
Eric Dumazet 225d9b89c9 sch_sfq: rehash queues in perturb timer
A known Out Of Order (OOO) problem hurts SFQ when timer changes
perturbation value, since all new packets delivered to SFQ enqueue might
end on different slots than previous in-flight packets.

With round robin delivery, we can thus deliver packets in a different
order.

Since SFQ is limited to small amount of in-flight packets, we can rehash
packets so that this OOO problem is fixed.

This rehashing is performed only if internal flow classifier is in use.

We now store in skb->cb[] the "struct flow_keys" so that we dont call
skb_flow_dissect() again while rehashing.

Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2011-12-21 15:44:34 -05:00
Michal Simek 4e68ea26e7 net: ethernet: xilinx: Don't use NO_IRQ in xilinx
Fix ll_temac and emaclite drivers. Only Microblaze and Xilinx PPC
use then and both use NO_IRQ as 0. It will be removed in near future.

Signed-off-by: Michal Simek <monstr@monstr.eu>
Signed-off-by: David S. Miller <davem@davemloft.net>
2011-12-21 15:42:50 -05:00
Helmut Schaa aef6c928a9 mac80211: Keep skb->piority for relayed frames in AP mode
When mac80211 relays a frame from STA1 to STA2 in AP mode it will get
re-classified in the tx path. Unfortunately the frame protocol field
is always set to ETH_P_8023 while the classification only kicks in
for ETH_P_IP. Hence, a high priority frame from STA1 will be send to
STA2 as best effort.

Instead of running classification on the frame just use the same
priority as STA1 did. Do this by adding 256 to the skb->priority
to allow cfg80211_classify8021d to shortcut frame classification.

Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2011-12-21 15:07:52 -05:00
Amitkumar Karwar 3aebee028a mwifiex: fix issues in band configuration code
Currently due to following issues in the code even if device is
configured in B only, G only or BG mode using iw bitrates command,
ibss is getting created in BGN mode.

1) mwifiex_channels_to_cfg80211_channel_type() routine gives channel
type as NL80211_CHAN_HT20 for non-HT channel as well, because driver
doesn't store HT information provided by stack for the channel.
This issue is fixed by maintaining channel type information in
'adapter->channel_type'.
2) Band configuration is unnecessarily overwritten with BGN/AN while
setting channel.

This patch makes sure that "adapter->config_bands" correctly gets
modified while setting channel.

Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2011-12-21 15:06:14 -05:00
Amitkumar Karwar 21c3ba3464 mwifiex: use IEEE80211_HT_PARAM_CHA_SEC_* macros
Replace driver specific macros with the corresponding
IEEE80211_HT_PARAM_CHA_SEC_* macros defined in ieee80211.h.
Also, rename 'adapter->chan_offset' to 'adapter->sec_chan_offset'
for consistency.

Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2011-12-21 15:06:13 -05:00
Amitkumar Karwar 43906cdb91 mwifiex: remove redundant band config code
struct mwifiex_ds_band_cfg and mwifiex_set_radio_band_cfg() routine
are unnecessary. It can be done with simple equivalant code.

Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2011-12-21 15:06:13 -05:00
Luis R. Rodriguez cf9bc5bae7 atheros: force endian checks on atheros wireless drivers
Please NACK nasty patches.

Cc: Kalle Valo <kvalo@qca.qualcomm.com>
Signed-off-by: Luis R. Rodriguez <mcgrof@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2011-12-21 15:06:12 -05:00
Marek Lindner ec2b774e7c mac80211: ibss should not purge clients it is not responsible for
The IBSS merge code calls ieee80211_sta_expire() with a relatively
short expire timeout that purges other clients prematurely. The
expire function has to check that only the clients belonging to
the vif in question are purged.

Signed-off-by: Marek Lindner <lindner_marek@yahoo.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2011-12-21 15:06:12 -05:00
Yogesh Ashok Powar eca107ff8a mwl8k: Call ieee80211_stop_tx_ba_cb_irqsafe for already deleted BA stream
When stack calls ampdu_action with action = IEEE80211_AMPDU_TX_STOP
for a stream that has already been removed from the driver, call
ieee80211_tx_ba_stop_irqsafe to clear the stream in the stack.

Signed-off-by: Yogesh Ashok Powar <yogeshp@marvell.com>
Signed-off-by: Nishant Sarmukadam <nishants@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2011-12-21 15:06:11 -05:00
Luis R. Rodriguez ec9a570547 ath9k: fix roadkill due to Joe's patch on ath_dbg() changes
Joe changed ath_dbg() to simpify code but while his patch was
being merged dfs.c was born and as such did not get the change
Joe envisioned. This fixes that. Test compiled with:

 make allmodconfig

Cc: Joe Perches <joe@perches.com>
Cc: Stephen Rothwell <sfr@canb.auug.org.au>
Cc: John W. Linville <linville@tuxdriver.com>
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Luis R. Rodriguez <mcgrof@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2011-12-21 15:06:11 -05:00