mptcp: Build-Fix

When fullmesh is enabled and IPv6 is disabled we had:

net/mptcp/mptcp_fullmesh.c: In function ‘full_mesh_new_session’:
net/mptcp/mptcp_fullmesh.c:1114:24: error: ‘struct sock_common’ has no member named ‘skc_v6_daddr’
make[3]: *** [net/mptcp/mptcp_fullmesh.o] Error 1
make[3]: *** Waiting for unfinished jobs....
make[2]: *** [net/mptcp] Error 2
make[1]: *** [net] Error 2
make: *** [sub-make] Error 2

Fixes: 2ac4542f96e65 (mptcp: Reduce mptcp_update_metasocket to its minimum)
Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>
mptcp: remove mptcp_skb_entail_init and clean-up MPTCPHDR_SEQ usage

Since the DSS option is built only in mptcp_skb_entail, set
MPTCPHDR_SEQ here. This allows us to remove mptcp_skb_entail_init.

This patch also removes the MPTCPHDR_SEQ check in mptcp_is_data_fin()
as it is not necessary on the TX path and on the RX path checks are
done in mptcp_parse_options() to make sure DATA FIN comes together with
a DSS mapping.

To fix a compare issue mptcp_is_data_fin() is converter to return a
bool. We do the same for a few other similar functions.

The patch also removes setting MPTCPHDR_SEQ in mptcp_send_fin. It was
added in commit e7fabbc2d4 to fix snd_wnd_test. In the meanwhile
snd_wnd_test was reworked and it seem that is no longer needed.

Depends-on: f5ad780c48e2077 (Fix: Create full new skb for the subflow)
Signed-off-by: Octavian Purdila <octavian.purdila@intel.com>
Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>
mptcp: pack mptcp flags

Some flags are TX or RX only so reuse thise bits to make space for 5
more TX only flags and to convert MPTCPHDR_JOIN to a proper flag.

Depends-on: 6a91bab7c3dac (Cleanup)
Signed-off-by: Octavian Purdila <octavian.purdila@intel.com>
Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>
mptcp: create helper functions to deal with DSS options

Move code that creates the DSS option into separate functions to allow
code reuse in both mptcp_skb_entail and mptcp_options_write.

Depends-on: f5ad780c48e2077 (Fix: Create full new skb for the subflow)
Signed-off-by: Octavian Purdila <octavian.purdila@intel.com>
Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>
mptcp: rework DSS handling

Save DSS options in tcp_skb_cb when queing a packet to a subflow and
remove code that explictly copies them between skb copies.

Note that since we save the options in a union with skb_inet_parm we
need to clear them when we are done needing them (i.e. when we write
them to the TCP options) because the IP layer expects a clean
skb_inet_parm.

Also it is safe to union them with path_mask since path_mask is not
used after queing the packet to the subflow.

Depends-on: 582e3bdae0117 (mptcp: create helper functions to deal with DSS options)
Signed-off-by: Octavian Purdila <octavian.purdila@intel.com>
Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>
mptcp: Fix shift-sack-data for MPTCP

If we are shifting sack'd data, we are removing one skb from the
write-queue. This skb will be holding a DSS-option in tcp_skb_cb->dss.

By removing the skb, the dss-option is lost forever and (may) never
reach the receiver.

So, we cannot shift sack'd data.

Fixes: f17b29179f97e (TSO Support for MPTCP)
Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>
mptcp: Allow receiving splitted data-fin without mapping on last skb

It may be, that we receive a mapping covering two segments. This mapping
may include a DATA_FIN and it may be that the last of these two segments
does not have a DSS-option. Then, mptcp_is_data_fin2() will always be
false and we do not set the fin-bit on the segment.

Fixes: 47080a0c11823 (Simplify tcp read code from application)
Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>
tcp: add gfp parameter to tcp_fragment

tcp_fragment can be called from process context (from tso_fragment).
Add a new gfp parameter to allow it to preserve atomic memory if
possible.

Depends-on: c8ac37746489f ([TCP]: Fix bug #5070: kernel BUG at net/ipv4/tcp_output.c:864)
Signed-off-by: Octavian Purdila <octavian.purdila@intel.com>
Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>
mptcp: add gfp parameter to mptcp_fragment

mptcp_fragment can be called from process context (from
mptso_fragment).  Add a new gfp parameter to allow it to preserve
atomic memory, if possible.

Depends-on: e5d878af34b2e (tcp: add gfp parameter to tcp_fragment)
Signed-off-by: Octavian Purdila <octavian.purdila@intel.com>
Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>
mptcp: remove mptso_fragment

In the MPTCP case mptso_fragment can be called for frames that already
leaved the meta-sock so we must ajust the packet counters. This makes
mptso_fragment very similar with mptcp_fragment.

To remove some code duplication lets use mptcp_fragment instead of
mptso_fragment, the overhead should be very small.

Depends-on: e5d878af34b2e (tcp: add gfp parameter to tcp_fragment)
Signed-off-by: Octavian Purdila <octavian.purdila@intel.com>
Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>
mptcp: remove code duplication between mptcp_fragment and tcp_fragment

Because DSS handling has now been moved out of tcp_fragment, we can
avoid duplicating code between mptcp_fragment and tcp_fragment.

For the reinjection case we do need to undo some tcp_fragment
operations. Not so pretty, but still I think it is better since it is
easier to read how the MPTCP path differs over the TCP path.

Depends-on: e5d878af34b2e (tcp: add gfp parameter to tcp_fragment)
Signed-off-by: Octavian Purdila <octavian.purdila@intel.com>
Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>
mptcp: New path manager callbacks for subsocket binds and Binder path manager

Binder path manager module (based on ndiffports) which enables per-subflow loose source routing.
Please see the Binder paper for more info: http://dl.acm.org/citation.cfm?id=2502894

Depends-on: c31d21d039d80 (Modularize the path-manager)
Signed-off-by: Duncan Eastoe <duncaneastoe@gmail.com>
Signed-off-by: bluca <luca.boccassi@gmail.com>
Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>
futex: Add another early deadlock detection check

commit 866293ee54227584ffcb4a42f69c1f365974ba7f upstream.

Dave Jones trinity syscall fuzzer exposed an issue in the deadlock
detection code of rtmutex:
  http://lkml.kernel.org/r/20140429151655.GA14277@redhat.com

That underlying issue has been fixed with a patch to the rtmutex code,
but the futex code must not call into rtmutex in that case because
    - it can detect that issue early
    - it avoids a different and more complex fixup for backing out

If the user space variable got manipulated to 0x80000000 which means
no lock holder, but the waiters bit set and an active pi_state in the
kernel is found we can figure out the recursive locking issue by
looking at the pi_state owner. If that is the current task, then we
can safely return -EDEADLK.

The check should have been added in commit 59fa62451 (futex: Handle
futex_pi OWNER_DIED take over correctly) already, but I did not see
the above issue caused by user space manipulation back then.

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Dave Jones <davej@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Darren Hart <darren@dvhart.com>
Cc: Davidlohr Bueso <davidlohr@hp.com>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Clark Williams <williams@redhat.com>
Cc: Paul McKenney <paulmck@linux.vnet.ibm.com>
Cc: Lai Jiangshan <laijs@cn.fujitsu.com>
Cc: Roland McGrath <roland@hack.frob.com>
Cc: Carlos ODonell <carlos@redhat.com>
Cc: Jakub Jelinek <jakub@redhat.com>
Cc: Michael Kerrisk <mtk.manpages@gmail.com>
Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Link: http://lkml.kernel.org/r/20140512201701.097349971@linutronix.de
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
futex: Prevent attaching to kernel threads

commit f0d71b3dcb8332f7971b5f2363632573e6d9486a upstream.

We happily allow userspace to declare a random kernel thread to be the
owner of a user space PI futex.

Found while analysing the fallout of Dave Jones syscall fuzzer.

We also should validate the thread group for private futexes and find
some fast way to validate whether the "alleged" owner has RW access on
the file which backs the SHM, but that's a separate issue.

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Dave Jones <davej@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Darren Hart <darren@dvhart.com>
Cc: Davidlohr Bueso <davidlohr@hp.com>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Clark Williams <williams@redhat.com>
Cc: Paul McKenney <paulmck@linux.vnet.ibm.com>
Cc: Lai Jiangshan <laijs@cn.fujitsu.com>
Cc: Roland McGrath <roland@hack.frob.com>
Cc: Carlos ODonell <carlos@redhat.com>
Cc: Jakub Jelinek <jakub@redhat.com>
Cc: Michael Kerrisk <mtk.manpages@gmail.com>
Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Link: http://lkml.kernel.org/r/20140512201701.194824402@linutronix.de
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
MIPS/loongson2_cpufreq: Fix CPU clock rate setting

commit 8e8acb32960f42c81b1d50deac56a2c07bb6a18a upstream.

Loongson2 has been using (incorrectly) kHz for cpu_clk rate. This has
been unnoticed, as loongson2_cpufreq was the only place where the rate
was set/get. After commit 652ed95d5fa6074b3c4ea245deb0691f1acb6656
(cpufreq: introduce cpufreq_generic_get() routine) things however broke,
and now loops_per_jiffy adjustments are incorrect (1000 times too long).
The patch fixes this by changing cpu_clk rate to Hz.

Signed-off-by: Aaro Koskinen <aaro.koskinen@iki.fi>
Cc: Rafael J. Wysocki <rjw@rjwysocki.net>
Cc: Viresh Kumar <viresh.kumar@linaro.org>
Cc: linux-mips@linux-mips.org
Cc: linux-kernel@vger.kernel.org
Cc: cpufreq@vger.kernel.org
Cc: Aaro Koskinen <aaro.koskinen@iki.fi>
Patchwork: https://patchwork.linux-mips.org/patch/6678/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
mips: dts: Fix missing device_type="memory" property in memory nodes

commit dfc44f8030653b345fc6fb337558c3a07536823f upstream.

A few platforms lack a 'device_type = "memory"' for their memory
nodes, relying on an old ppc quirk in order to discover its memory.
Add the missing data so that all parsing code can find memory nodes
correctly.

Signed-off-by: Leif Lindholm <leif.lindholm@linaro.org>
Cc: linux-mips@linux-mips.org
Cc: devicetree@vger.kernel.org
Cc: Mark Rutland <mark.rutland@arm.com>
Acked-by: John Crispin <blogic@openwrt.org>
Signed-off-by: Grant Likely <grant.likely@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
rtmutex: Fix deadlock detector for real

commit 397335f004f41e5fcf7a795e94eb3ab83411a17c upstream.

The current deadlock detection logic does not work reliably due to the
following early exit path:

	/*
	 * Drop out, when the task has no waiters. Note,
	 * top_waiter can be NULL, when we are in the deboosting
	 * mode!
	 */
	if (top_waiter && (!task_has_pi_waiters(task) ||
			   top_waiter != task_top_pi_waiter(task)))
		goto out_unlock_pi;

So this not only exits when the task has no waiters, it also exits
unconditionally when the current waiter is not the top priority waiter
of the task.

So in a nested locking scenario, it might abort the lock chain walk
and therefor miss a potential deadlock.

Simple fix: Continue the chain walk, when deadlock detection is
enabled.

We also avoid the whole enqueue, if we detect the deadlock right away
(A-A). It's an optimization, but also prevents that another waiter who
comes in after the detection and before the task has undone the damage
observes the situation and detects the deadlock and returns
-EDEADLOCK, which is wrong as the other task is not in a deadlock
situation.

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Reviewed-by: Steven Rostedt <rostedt@goodmis.org>
Cc: Lai Jiangshan <laijs@cn.fujitsu.com>
Link: http://lkml.kernel.org/r/20140522031949.725272460@linutronix.de
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
ftrace/module: Hardcode ftrace_module_init() call into load_module()

commit a949ae560a511fe4e3adf48fa44fefded93e5c2b upstream.

A race exists between module loading and enabling of function tracer.

	CPU 1				CPU 2
	-----				-----
  load_module()
   module->state = MODULE_STATE_COMING

				register_ftrace_function()
				 mutex_lock(&ftrace_lock);
				 ftrace_startup()
				  update_ftrace_function();
				   ftrace_arch_code_modify_prepare()
				    set_all_module_text_rw();
				   <enables-ftrace>
				    ftrace_arch_code_modify_post_process()
				     set_all_module_text_ro();

				[ here all module text is set to RO,
				  including the module that is
				  loading!! ]

   blocking_notifier_call_chain(MODULE_STATE_COMING);
    ftrace_init_module()

     [ tries to modify code, but it's RO, and fails!
       ftrace_bug() is called]

When this race happens, ftrace_bug() will produces a nasty warning and
all of the function tracing features will be disabled until reboot.

The simple solution is to treate module load the same way the core
kernel is treated at boot. To hardcode the ftrace function modification
of converting calls to mcount into nops. This is done in init/main.c
there's no reason it could not be done in load_module(). This gives
a better control of the changes and doesn't tie the state of the
module to its notifiers as much. Ftrace is special, it needs to be
treated as such.

The reason this would work, is that the ftrace_module_init() would be
called while the module is in MODULE_STATE_UNFORMED, which is ignored
by the set_all_module_text_ro() call.

Link: http://lkml.kernel.org/r/1395637826-3312-1-git-send-email-indou.takao@jp.fujitsu.com

Reported-by: Takao Indoh <indou.takao@jp.fujitsu.com>
Acked-by: Rusty Russell <rusty@rustcorp.com.au>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
of/irq: do irq resolution in platform_get_irq

commit 9ec36cafe43bf835f8f29273597a5b0cbc8267ef upstream.

Currently we get the following kind of errors if we try to use interrupt
phandles to irqchips that have not yet initialized:

irq: no irq domain found for /ocp/pinmux@48002030 !
------------[ cut here ]------------
WARNING: CPU: 0 PID: 1 at drivers/of/platform.c:171 of_device_alloc+0x144/0x184()
Modules linked in:
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.12.0-00038-g42a9708 #1012
(show_stack+0x14/0x1c)
(dump_stack+0x6c/0xa0)
(warn_slowpath_common+0x64/0x84)
(warn_slowpath_null+0x1c/0x24)
(of_device_alloc+0x144/0x184)
(of_platform_device_create_pdata+0x44/0x9c)
(of_platform_bus_create+0xd0/0x170)
(of_platform_bus_create+0x12c/0x170)
(of_platform_populate+0x60/0x98)

This is because we're wrongly trying to populate resources that are not
yet available. It's perfectly valid to create irqchips dynamically, so
let's fix up the issue by resolving the interrupt resources when
platform_get_irq is called.

And then we also need to accept the fact that some irqdomains do not
exist that early on, and only get initialized later on. So we can
make the current WARN_ON into just into a pr_debug().

We still attempt to populate irq resources when we create the devices.
This allows current drivers which don't use platform_get_irq to continue
to function. Once all drivers are fixed, this code can be removed.

Suggested-by: Russell King <linux@arm.linux.org.uk>
Signed-off-by: Rob Herring <robh@kernel.org>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Tested-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Grant Likely <grant.likely@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
irqchip: Gic: Support forced affinity setting

commit ffde1de64012c406dfdda8690918248b472f24e4 upstream.

To support the affinity setting of per cpu timers in the early startup
of a not yet online cpu, implement the force logic, which disables the
cpu online check.

Tagged for stable to allow a simple fix of the affected SoC clock
event drivers.

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Cc: Kyungmin Park <kyungmin.park@samsung.com>
Cc: Marek Szyprowski <m.szyprowski@samsung.com>
Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Cc: Tomasz Figa <t.figa@samsung.com>,
Cc: Daniel Lezcano <daniel.lezcano@linaro.org>,
Cc: Kukjin Kim <kgene.kim@samsung.com>
Cc: linux-arm-kernel@lists.infradead.org,
Link: http://lkml.kernel.org/r/20140416143315.916984416@linutronix.de
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>