ipv6: introdcue __ipv6_addr_needs_scope_id and ipv6_iface_scope_id helper functions

[msm/android-3.4 commit 2c75b248e5243d0af7cc97522148db7415a70f8a]

__ipv6_addr_needs_scope_id checks if an ipv6 address needs to supply
a 'sin6_scope_id != 0'. 'sin6_scope_id != 0' was enforced in case
of link-local addresses. To support interface-local multicast these
checks had to be enhanced and are now consolidated into these new helper
functions.

v2:
a) migrated to struct ipv6_addr_props

v3:
a) reverted changes for ipv6_addr_props
b) test for address type instead of comparing scope

v4:
a) unchanged

Bug: 9469865
Change-Id: I11213e9917223a6aefa243f541d1830c4234dda6
Suggested-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Cc: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Acked-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
Acked-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Lorenzo Colitti <lorenzo@google.com>
Signed-off-by: Francisco Franco <franciscofranco.1990@gmail.com>
net: ipv6: Add IPv6 support to the ping socket.

[msm/android-3.4 commit 1f0675844e3b63a765e5bd32bc5af051ccd951c0]

This adds the ability to send ICMPv6 echo requests without a
raw socket. The equivalent ability for ICMPv4 was added in
2011.

Instead of having separate code paths for IPv4 and IPv6, make
most of the code in net/ipv4/ping.c dual-stack and only add a
few IPv6-specific bits (like the protocol definition) to a new
net/ipv6/ping.c. Hopefully this will reduce divergence and/or
duplication of bugs in the future.

Caveats:

- Setting options via ancillary data (e.g., using IPV6_PKTINFO
  to specify the outgoing interface) is not yet supported.
- There are no separate security settings for IPv4 and IPv6;
  everything is controlled by /proc/net/ipv4/ping_group_range.
- The proc interface does not yet display IPv6 ping sockets
  properly.

Tested with a patched copy of ping6 and using raw socket calls.
Compiles and works with all of CONFIG_IPV6={n,m,y}.

Signed-off-by: Francisco Franco <franciscofranco.1990@gmail.com>

Conflicts:
	net/ipv4/ping.c

Bug: 9469865
Change-Id: I0ee65904b96716912604904eaa856b9a081fd52a
Signed-off-by: Lorenzo Colitti <lorenzo@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
[lorenzo@google.com: backported to 3.4]
Signed-off-by: Lorenzo Colitti <lorenzo@google.com>
[lorenzo@google.com: include export.h to fix missing THIS_MODULE]
Signed-off-by: Lorenzo Colitti <lorenzo@google.com>

Signed-off-by: Francisco Franco <franciscofranco.1990@gmail.com>
ping: always initialize ->sin6_scope_id and ->sin6_flowinfo

[msm/android-3.4 commit 14e41a18688ec8d52ea3163f7898455b52365854]

If we don't need scope id, we should initialize it to zero.
Same for ->sin6_flowinfo.

Bug: 9469865
Change-Id: Idcf0370dfec405ada9d57fdad10f34893fe728f3
Cc: Lorenzo Colitti <lorenzo@google.com>
Cc: David S. Miller <davem@davemloft.net>
Signed-off-by: Cong Wang <amwang@redhat.com>
Acked-by: Lorenzo Colitti <lorenzo@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Lorenzo Colitti <lorenzo@google.com>
Signed-off-by: Francisco Franco <franciscofranco.1990@gmail.com>
net: ipv6: add missing lock in ping_v6_sendmsg

[msm/android-3.4 commit 3a018d2e8fc2910e5fb2077cde81cad659e2c7f9]

Bug: 9469865
Change-Id: I630ec036086c734f67a70291d7e77dde3b5f3f43
Signed-off-by: Lorenzo Colitti <lorenzo@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Francisco Franco <franciscofranco.1990@gmail.com>
net: ipv6: fix wrong ping_v6_sendmsg return value

[msm/android-3.4 commit 5f0fd6105f491b8b435863e98f7e96d617e3da84]

ping_v6_sendmsg currently returns 0 on success. It should return
the number of bytes written instead.

Bug: 9469865
Change-Id: Ic5f3eeb74725bfb5bdca9a533461492b68e2e072
Signed-off-by: Lorenzo Colitti <lorenzo@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Francisco Franco <franciscofranco.1990@gmail.com>
ipv6: use a stronger hash for tcp

It looks like its possible to open thousands of TCP IPv6
sessions on a server, all landing in a single slot of TCP hash
table. Incoming packets have to lookup sockets in a very
long list.

We should hash all bits from foreign IPv6 addresses, using
a salt and hash mix, not a simple XOR.

inet6_ehashfn() can also separately use the ports, instead
of xoring them.

Reported-by: Neal Cardwell <ncardwell@google.com>
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Yuchung Cheng <ycheng@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Iliyan Malchev <malchev@google.com>

Conflicts:
	include/net/ipv6.h
net: defer net_secret[] initialization

Instead of feeding net_secret[] at boot time, defer the init
at the point first socket is created.

This permits some platforms to use better entropy sources than
the ones available at boot time.

Signed-off-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
ARM: 7809/1: perf: fix event validation for software group leaders

It is possible to construct an event group with a software event as a
group leader and then subsequently add a hardware event to the group.
This results in the event group being validated by adding all members
of the group to a fake PMU and attempting to allocate each event on
their respective PMU.

Unfortunately, for software events wthout a corresponding arm_pmu, this
results in a kernel crash attempting to dereference the ->get_event_idx
function pointer.

This patch fixes the problem by checking explicitly for software events
and ignoring those in event validation (since they can always be
scheduled). We will probably want to revisit this for 3.12, since the
validation checks don't appear to work correctly when dealing with
multiple hardware PMUs anyway.

Cc: <stable@vger.kernel.org>
Reported-by: Vince Weaver <vincent.weaver@maine.edu>
Tested-by: Vince Weaver <vincent.weaver@maine.edu>
Tested-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

Conflicts:
	arch/arm/kernel/perf_event.c

Signed-off-by: Patrick Tjin <pattjin@google.com>
perf/arm: Fix armpmu_map_hw_event()

Fix constraint check in armpmu_map_hw_event().

Reported-and-tested-by: Vince Weaver <vincent.weaver@maine.edu>
Cc: <stable@kernel.org>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Patrick Tjin <pattjin@google.com>
cpuinit: get rid of __cpuinit, first regexp
This commit is the result of:

find -name "*.c" | xargs sed -i "s/ __cpuinit / /g"

Signed-off-by: Arjan van de Ven <arjan@linux.intel.com>
Signed-off-by: Dennis Rassmann <showp1984@gmail.com>

Conflicts:
	arch/arm/mach-msm/acpuclock-krait.c

Conflicts:
	arch/arm/kernel/arch_timer.c
	arch/arm/kernel/smp.c
	arch/arm/mach-msm/acpuclock-krait.c
	kernel/workqueue.c

Conflicts:
	arch/arm/mach-msm/cpufreq.c
cpuinit: get rid of __cpuinit, third regexp
This commit is the result of:

find -name "*.c" | xargs sed -i "s/ __cpuinitdata//g"

Signed-off-by: Arjan van de Ven <arjan@linux.intel.com>
Signed-off-by: Dennis Rassmann <showp1984@gmail.com>
ARM: 7810/1: perf: Fix array out of bounds access in armpmu_map_hw_event()

Vince Weaver reports an oops in the ARM perf event code while
running his perf_fuzzer tool on a pandaboard running v3.11-rc4.

Unable to handle kernel paging request at virtual address 73fd14cc
pgd = eca6c000
[73fd14cc] *pgd=00000000
Internal error: Oops: 5 [#1] SMP ARM
Modules linked in: snd_soc_omap_hdmi omapdss snd_soc_omap_abe_twl6040 snd_soc_twl6040 snd_soc_omap snd_soc_omap_hdmi_card snd_soc_omap_mcpdm snd_soc_omap_mcbsp snd_soc_core snd_compress regmap_spi snd_pcm snd_page_alloc snd_timer snd soundcore
CPU: 1 PID: 2790 Comm: perf_fuzzer Not tainted 3.11.0-rc4 #6
task: eddcab80 ti: ed892000 task.ti: ed892000
PC is at armpmu_map_event+0x20/0x88
LR is at armpmu_event_init+0x38/0x280
pc : [<c001c3e4>]    lr : [<c001c17c>]    psr: 60000013
sp : ed893e40  ip : ecececec  fp : edfaec00
r10: 00000000  r9 : 00000000  r8 : ed8c3ac0
r7 : ed8c3b5c  r6 : edfaec00  r5 : 00000000  r4 : 00000000
r3 : 000000ff  r2 : c0496144  r1 : c049611c  r0 : edfaec00
Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment user
Control: 10c5387d  Table: aca6c04a  DAC: 00000015
Process perf_fuzzer (pid: 2790, stack limit = 0xed892240)
Stack: (0xed893e40 to 0xed894000)
3e40: 00000800 c001c17c 00000002 c008a748 00000001 00000000 00000000 c00bf078
3e60: 00000000 edfaee50 00000000 00000000 00000000 edfaec00 ed8c3ac0 edfaec00
3e80: 00000000 c073ffac ed893f20 c00bf180 00000001 00000000 c00bf078 ed893f20
3ea0: 00000000 ed8c3ac0 00000000 00000000 00000000 c0cb0818 eddcab80 c00bf440
3ec0: ed893f20 00000000 eddcab80 eca76800 00000000 eca76800 00000000 00000000
3ee0: 00000000 ec984c80 eddcab80 c00bfe68 00000000 00000000 00000000 00000080
3f00: 00000000 ed892000 00000000 ed892030 00000004 ecc7e3c8 ecc7e3c8 00000000
3f20: 00000000 00000048 ecececec 00000000 00000000 00000000 00000000 00000000
3f40: 00000000 00000000 00297810 00000000 00000000 00000000 00000000 00000000
3f60: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
3f80: 00000002 00000002 000103a4 00000002 0000016c c00128e8 ed892000 00000000
3fa0: 00090998 c0012700 00000002 000103a4 00090ab8 00000000 00000000 0000000f
3fc0: 00000002 000103a4 00000002 0000016c 00090ab0 00090ab8 000107a0 00090998
3fe0: bed92be0 bed92bd0 0000b785 b6e8f6d0 40000010 00090ab8 00000000 00000000
[<c001c3e4>] (armpmu_map_event+0x20/0x88) from [<c001c17c>] (armpmu_event_init+0x38/0x280)
[<c001c17c>] (armpmu_event_init+0x38/0x280) from [<c00bf180>] (perf_init_event+0x108/0x180)
[<c00bf180>] (perf_init_event+0x108/0x180) from [<c00bf440>] (perf_event_alloc+0x248/0x40c)
[<c00bf440>] (perf_event_alloc+0x248/0x40c) from [<c00bfe68>] (SyS_perf_event_open+0x4f4/0x8fc)
[<c00bfe68>] (SyS_perf_event_open+0x4f4/0x8fc) from [<c0012700>] (ret_fast_syscall+0x0/0x48)
Code: 0a000005 e3540004 0a000016 e3540000 (0791010c)

This is because event->attr.config in armpmu_event_init()
contains a very large number copied directly from userspace and
is never checked against the size of the array indexed in
armpmu_map_hw_event(). Fix the problem by checking the value of
config before indexing the array and rejecting invalid config
values.

Change-Id: I77c21164fc0f57f8a44dd0bcc7d00b51998669f6
Reported-by: Vince Weaver <vincent.weaver@maine.edu>
Tested-by: Vince Weaver <vincent.weaver@maine.edu>
Acked-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Git-commit: d9f966357b14e356dbd83b8f4a197a287ab4ff83
Git-repo: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
CRs-fixed: 561044
Signed-off-by: Joonwoo Park <joonwoop@codeaurora.org>
mmc: Urgent request support

mmc: do not pack random requests

Packed commands causes higher latency since the completion of each
request is sent to the upper layer upon completion of the complete
packed request.
The benefit from this feature is card dependent. Some of the card
vendors do not have any benefit from using packed commands for random
requests. In case there is no benefit in random requests packing,
it is better to disable the packing to prevent this high latency.
This patch also add the new stop packing reason to the write packing
statistics.

Change-Id: I141887dcef2ceee14848634cc27c3c85f8edc7a5
Signed-off-by: Maya Erez <merez@codeaurora.org>

mmc: fix async request mechanism for sequential read scenarios

When current request is running on the bus and if next request fetched
by mmcqd is NULL, mmc context (mmcqd thread) gets blocked until the
current request completes. This means that if new request comes in while
the mmcqd thread is blocked, this new request can not be prepared in
parallel to current ongoing request. This may result in delaying the new
request execution and increase it's latency.

This change allows to wake up the MMC thread on new request arrival.
Now once the MMC thread is woken up, a new request can be fetched and
prepared in parallel to the current running request which means this new
request can be started immediately after the current running request
completes.

With this change read throughput is improved by 16%.

Change-Id: I8d74fda719c89a710330807c9d8994d40c885aa0
Signed-off-by: Konstantin Dorfman <kdorfman@codeaurora.org>

mmc: block: add mmc_blk_disable_wr_packing() disables packing mode

The function disables packing mode. Right now the only reason is
change in data direction.

Change-Id: I0f4edba3da93fde28cf47ac95754a95e411fa2af
Signed-off-by: Konstantin Dorfman <kdorfman@codeaurora.org>

mmc: Add support to handle Urgent data transfer request

Urgent request notification stops currently running transaction
on bus.
In order to decrease a latency of a prioritized requests (aka Urgent
request), we might want to stop the transmission of a running "low
priority" request in order to handle the Urgent request. The urgency of
the request is decided by the block layer I/O scheduler. When the block
layer notifies the MMC layer of an urgent request and if the MMC layer is
blocked on current request to complete, it will be woken up.

The decision on whether to stop an ongoing transfer is taken according to
several parameters, one of them being the number of bytes already
transferred for ongoing transfer by host controller so far.

To calculate how many bytes were successfully programmed before stop,
CORRECTLY_PRG_SECTORS_NUM[245:242] parsed from EXT_CSD register. The
remainder of stopped request (and next prepared request in case it
exists) re-inserted back to the I/O scheduler to be handled after the
completion of the urgent request.

In case it is decided not to stop the ongoing transfer, MMC context will
wait for normal completion of the ongoing transfer, then already prepared
next request (if it exists) will be re-inserted back into block layer and
the urgent request fetched.

URGENT_REQUEST handling has following dependencies:
1. Host controller driver should support mmc_host op named "stop_request"
2. Block I/O scheduler should support re-insert API
3. eMMC card should support HPI (High Priority Interrupt) command

If any of the above dependencies are not met then urgent request mechanism
will not become operational.

Change-Id: Ic3fa1ca9463cc8991aefee940d8bfddf76c111d3
Signed-off-by: Konstantin Dorfman <kdorfman@codeaurora.org>

mmc: core: ignore new request notification, when 2 requests are in progress

In case both host->areq and areq requests exist and the new request
notification unblocks mmc context, instead of BUG_ON() in mmc_start_req(),
mmc_wait_for_data_req_done() continue to wait again for the completion
of the current request. New request notification is ignored in this case.

Change-Id: I5a0201a9fbe4cbaeb0c0a9b83f56f4af74eff95b
Signed-off-by: Konstantin Dorfman <kdorfman@codeaurora.org>

mmc: fix read latency of urgent request

In order to improve read request latency, urgent notification allowed
anytime, when current or previous requests are existing in the mmc layer.
It is not allowed to stop following running requests:
- urgent request: block layer should serialize urgent request notification.
- read request: it can't be packed, therefore it is better
to wait for its completion.
- REQ_FUA: interruption and delay in such request will impact sync process
of upper layers.

Change-Id: Id7d1480cce2059c1f23a5f29ad8f74e858be1ee6
Signed-off-by: Konstantin Dorfman <kdorfman@codeaurora.org>
Signed-off-by: Maya Erez <merez@codeaurora.org>
Signed-off-by: Tatyana Brokhman <tlinder@codeaurora.org>

mmc: msm_sdcc: enable support to handle Urgent data transfer request

In order to decrease a latency of a prioritized requests (aka Urgent
request), we might want to stop the transmission of a running "low
priority" request in order to handle the Urgent request.

URGENT_REQUEST handling has following dependencies:
1. Host controller driver should support mmc_host op named "stop_request"
2. Block I/O scheduler should support re-insert API
3. eMMC card should support HPI (High Priority Interrupt) command
If any of the above dependencies are not met then urgent request mechanism
will not become operational.

Change-Id: I976af4fa794fb0fac701fe12f249c36d78080c6e
Signed-off-by: Konstantin Dorfman <kdorfman@codeaurora.org>

mmc: Do not perform blocking BKOPS

BKOPS operations can take long time and cause bad user experience and
failure of time critical operations as EFS sync.
In order to prevent the above failures all the levels will be handled only
in idle time BKOPS handling and will allow interrupting the BKOPS when
needed.
In case the card raised an exception with a need for BKOPS, a flag will
be set to indicate MMC to start the BKOPS activity when it becomes idle.

Fixed-CRs: 432027
Change-Id: I5f7b43569c0242f0fea83355f76f286b1ad037bc
Signed-off-by: Maya Erez <merez@codeaurora.org>
(cherry picked from commit 5f8ac3b955e44def61c2238192000ffe5f126714)

Conflicts:
	drivers/mmc/core/core.h
	include/linux/mmc/host.h
PM / Sleep: call early resume handlers when suspend_noirq fails

Commit cf579dfb82550e34de7ccf3ef090d8b834ccd3a9 (PM / Sleep: Introduce
"late suspend" and "early resume" of devices) introduced a bug where
suspend_late handlers would be called, but if dpm_suspend_noirq returned
an error the early_resume handlers would never be called.  All devices
would end up on the dpm_late_early_list, and would never be resumed
again.

Fix it by calling dpm_resume_early when dpm_suspend_noirq returns
an error.

Signed-off-by: Colin Cross <ccross@android.com>
Cc: stable@vger.kernel.org
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>

Change-Id: I6fe42f02efdc0b5fb0949b7d5c1c8eb8da96825d
Signed-off-by: Joel King <joelking@codeaurora.org>

Conflicts:
	drivers/base/power/main.c
PM: Allow runtime suspend again if prepare is failed

commit 8a5bdaf3 never allow the runtime suspend if prepare is failed.
The complete phase is invoked when calling __device_suspend.
It allows the runtime suspend again. But if prepare is failed,
__device_suspend won't be called and the complete phase won't also
called. Thus this runtime suspend will be blocked forever.

If prepare is failed, you should allow the runtime suspend again.

Change-Id: I57c7c04609299244a042f2524e1c65dbbdd91ae3
cfg80211: Fix memory leak

When a driver requests a specific regulatory domain after cfg80211 already
has one, a struct ieee80211_regdomain is leaked.

Change-Id: Id28fc9861b9c911a97bd242439eabca097d76258
Reported-by: Larry Finger <Larry.Finger@lwfinger.net>
Tested-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Git-commit: b7566fc363e23f0efd3fa1e1460f9421cdc0d77e
Git-repo: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
[mattw@codeaurora.org: trivially backport to the msm-3.4 kernel]
Signed-off-by: Matt Wagantall <mattw@codeaurora.org>

Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
cfg80211: add flags to define country IE processing rules

802.11 cards may have different country IE parsing behavioural
preferences and vendors may want to support these. These preferences
were managed by the WIPHY_FLAG_CUSTOM_REGULATORY and the
WIPHY_FLAG_STRICT_REGULATORY flags and their combination.
Instead of using this existing notation, split out the country IE
behavioural preferences to a new flag. This will allow us to add more
customizations easily and make the code more maintainable. Also add
a new flag to disable country IE hints issued by the CORE as the
first customization.

Change-Id: I66ba4a92ac0f029a115eea0a274b02db11279787
CRs-Fixed: 542802
Signed-off-by: Mihir Shete <smihir@codeaurora.org>

Conflicts:
	include/net/cfg80211.h
cfg80211: export regulatory_hint_user() API

This is to help the hardware configured in world
roaming mode to save power when not connected to
any AP.

CRs-Fixed: 542802
Change-Id: Ia643d0e9848dcd486832973bd6dd186edd7bd4ea
Signed-off-by: Mihir Shete <smihir@codeaurora.org>
cfg80211: fix set_regdom() to cancel requests with same alpha2

Use a different error code if the regdomain is same and then
set the request processed so that it doesn't block new
requests.

Git-commit: 959085352b7c44ff9bae4d8a4d76146193260e4c
Git-repo: git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-testing.git
Author: Kalle Valo <kvalo@qca.qualcomm.com>
Date: Thu Jul 12 15:33:58 2012 +0300

Change-Id: I8cbcf80bb43d983c72cf9037f30e11ae8d329b06
Signed-off-by: Mihir Shete <smihir@codeaurora.org>
cfg80211: permanently disable channels specified by base settings

if a custom regulatory domain is passed and if a rule for a channel
indicates it should be disabled that channel should always remain
disabled as per its documentation and design.
Likewise if WIPHY_FLAG_STRICT_REGULATORY flag is set and a
regulatory_hint() is issued if a channel is disabled that channel should
remain disabled.
Without this change only drivers that set the _orig flags appropriately
on their own would ensure disallowed channels remaind disabled. This
helps drivers save code by relying on the APIS provided to entrust
channels that should not be enabled be respected by only having to use
wiphy_apply_custom_regulatory() or regulatory_hint() with the
WIPHY_FLAG_STRICT_REGULATORY set.
If wiphy_apply_custom_regulatory() is used together with
WIPHY_FLAG_STRICT_REGULATORY and a regulatory_hint() issued later, the
incoming regulatory domain can override previously set _orig parameters
from the initial custom regulatory setting.

Change-Id: Ia1af4b293bd299ac20e1934e5e03e633ecb9d6ee
Signed-off-by: Luis R. Rodriguez <mcgrof@do-not-panic.com>
Signed-off-by: Mihir Shete <smihir@codeaurora.org>