Merge branch 'drm-fixes' of git://people.freedesktop.org/~airlied/linux
Pull drm fixes from Dave Airlie:
"Final drm fixes: one core locking imbalance regression, and a bunch of
i915 baytrail s/r fixes"
* 'drm-fixes' of git://people.freedesktop.org/~airlied/linux:
drm: fix drm_mode_getconnector() locking imbalance regression
drm/i915/vlv: remove wait for previous GFX clk disable request
drm/i915/chv: Remove Wait for a previous gfx force-off
drm/i915/vlv: save/restore the power context base reg
Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/sage/ceph-client
Pull ceph revert from Sage Weil:
"This corrects a recent misadventure with __GFP_MEMALLOC and
PF_MEMALLOC; it turns out it's not a good fit for RBD and we're better
off relying on dirty page throttling"
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/sage/ceph-client:
Revert "libceph: use memalloc flags for net IO"
Merge misc fixes from Andrew Morton:
"Three fixes"
* emailed patches from Andrew Morton <akpm@linux-foundation.org>:
mm: numa: disable change protection for vma(VM_HUGETLB)
include/linux/dmapool.h: declare struct device
mm: move zone lock to a different cache line than order-0 free page lists
Copy the kernel module data from user space in chunks
Unlike most (all?) other copies from user space, kernel module loading
is almost unlimited in size. So we do a potentially huge
"copy_from_user()" when we copy the module data from user space to the
kernel buffer, which can be a latency concern when preemption is
disabled (or voluntary).
Also, because 'copy_from_user()' clears the tail of the kernel buffer on
failures, even a *failed* copy can end up wasting a lot of time.
Normally neither of these are concerns in real life, but they do trigger
when doing stress-testing with trinity. Running in a VM seems to add
its own overheadm causing trinity module load testing to even trigger
the watchdog.
The simple fix is to just chunk up the module loading, so that it never
tries to copy insanely big areas in one go. That bounds the latency,
and also the amount of (unnecessarily, in this case) cleared memory for
the failure case.
The rule for 'copy_from_user()' is that it zeroes the remaining kernel
buffer even when the copy fails halfway, just to make sure that we don't
leave uninitialized kernel memory around. Because even if we check for
errors, some kernel buffers stay around after thge copy (think page
cache).
However, the x86-64 logic for user copies uses a copy_user_generic()
function for all the cases, that set the "zerorest" flag for any fault
on the source buffer. Which meant that it didn't just try to clear the
kernel buffer after a failure in copy_from_user(), it also tried to
clear the destination user buffer for the "copy_in_user()" case.
Not only is that pointless, it also means that the clearing code has to
worry about the tail clearing taking page faults for the user buffer
case. Which is just stupid, since that case shouldn't happen in the
first place.
Get rid of the whole "zerorest" thing entirely, and instead just check
if the destination is in kernel space or not. And then just use
memset() to clear the tail of the kernel buffer if necessary.
Dave Airlie [Wed, 8 Apr 2015 20:59:50 +0000 (06:59 +1000)]
Merge tag 'drm-intel-fixes-2015-04-08' of git://anongit.freedesktop.org/drm-intel into drm-fixes
three commits, all cc: stable, to address Baytrail
suspend/resume issues.
* tag 'drm-intel-fixes-2015-04-08' of git://anongit.freedesktop.org/drm-intel:
drm/i915/vlv: remove wait for previous GFX clk disable request
drm/i915/chv: Remove Wait for a previous gfx force-off
drm/i915/vlv: save/restore the power context base reg
const __read_mostly is a senseless combination. If something
is already const it cannot be __read_mostly. Remove the bogus
__read_mostly in the fou driver.
This fixes section conflicts with LTO.
Signed-off-by: Andi Kleen <ak@linux.intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Alessio Igor Bogani <alessio.bogani@elettra.eu> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
David S. Miller [Wed, 8 Apr 2015 19:17:38 +0000 (15:17 -0400)]
Merge branch 'rds'
Sowmini Varadhan says:
====================
RDS: RDS-core fixes
This patch-series updates the RDS core and rds-tcp modules with
some bug fixes that were originally authored by Andy Grover,
Zach Brown, and Chris Mason.
v2: Code review comment by Sergei Shtylov
V3: DaveM comments:
- dropped patches 3, 5 for "heuristic" changes in rds_send_xmit().
Investigation into the root-cause of these IB-triggered changes
produced the feedback: "I don't remember seeing "RDS: Stuck RM"
message in last 1-1.5 years and checking with other folks. It may very
well be some old workaround for stale connection for which long term
fix is already made and this part of code not exercised anymore."
Any such fixes, *if* they are needed, can/should be done in the
IB specific RDS transport modules.
- similarly dropped the LL_SEND_FULL patch (patch 6 in v2 set)
v4: Documentation/networking/rds.txt contains incorrect references
to "missing sysctl values for pf_rds and sol_rds in mainline".
The sysctl values were never needed in mainline, thus fix the
documentation.
v5: Clarify comment per http://www.spinics.net/lists/netdev/msg324220.html
v6: Re-added entire version history to cover letter.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
RDS: make sure not to loop forever inside rds_send_xmit
If a determined set of concurrent senders keep the send queue full,
we can loop forever inside rds_send_xmit. This fix has two parts.
First we are dropping out of the while(1) loop after we've processed a
large batch of messages.
Second we add a generation number that gets bumped each time the
xmit bit lock is acquired. If someone else has jumped in and
made progress in the queue, we skip our goto restart.
Original patch by Chris Mason.
Signed-off-by: Sowmini Varadhan <sowmini.varadhan@oracle.com> Signed-off-by: David S. Miller <davem@davemloft.net>
RDS: only use passive connections when addresses match
Passive connections were added for the case where one loopback IB
connection between identical addresses needs another connection to store
the second QP. Unfortunately, they were also created in the case where
the addesses differ and we already have both QPs.
This lead to a message reordering bug.
- two different IB interfaces and addresses on a machine: A B
- traffic is sent from A to B
- connection from A-B is created, connect request sent
- listening accepts connect request, B-A is created
- traffic flows, next_rx is incremented
- unacked messages exist on the retrans list
- connection A-B is shut down, new connect request sent
- listen sees existing loopback B-A, creates new passive B-A
- retrans messages are sent and delivered because of 0 next_rx
The problem is that the second connection request saw the previously
existing parent connection. Instead of using it, and using the existing
next_rx_seq state for the traffic between those IPs, it mistakenly
thought that it had to create a passive connection.
We fix this by only using passive connections in the special case where
laddr and faddr match. In this case we'll only ever have one parent
sending connection requests and one passive connection created as the
listening path sees the existing parent connection which initiated the
request.
Original patch by Zach Brown
Signed-off-by: Sowmini Varadhan <sowmini.varadhan@oracle.com> Signed-off-by: David S. Miller <davem@davemloft.net>
RDS: Documentation: Document AF_RDS, PF_RDS and SOL_RDS correctly.
AF_RDS, PF_RDS and SOL_RDS are available in header files,
and there is no need to get their values from /proc. Document
this correctly.
Fixes: 0c5f9b8830aa ("RDS: Documentation") Signed-off-by: Sowmini Varadhan <sowmini.varadhan@oracle.com> Signed-off-by: David S. Miller <davem@davemloft.net>
ALSA: hda - Fix headphone pin config for Lifebook T731
Some BIOS version of Fujitsu Lifebook T731 seems to set up the
headphone pin (0x21) without the assoc number 0x0f while it's set only
to the output on the docking port (0x1a). With the recent commit
[03ad6a8c93b6: ALSA: hda - Fix "PCM" name being used on one DAC when
there are two DACs], this resulted in the weird mixer element
mapping where the headphone on the laptop is assigned as a shared
volume with the speaker and the docking port is assigned as an
individual headphone.
This patch improves the situation by correcting the headphone pin
config to the more appropriate value.
Reported-and-tested-by: Taylor Smock <smocktaylor@gmail.com> Cc: <stable@vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de>
ALSA: bebob: fix to processing in big-endian machine for sending cue
Some M-Audio devices require to receive bootup command just after
powering on, while codes in BeBoB driver doesn't work properly in
big-endian machine because the command should be aligned by
little-endian.
This commit fixes this bug. This fix should go to stable kernel.
David Ahern reported that d63e2e1f3df9 breaks booting on an 8-socket T5
sparc system. He also verified that the system boots with d63e2e1f3df9
reverted. Yinghai has some fixes, but they need a little more polishing
than we can do before v4.0.
Bjorn Helgaas [Tue, 24 Mar 2015 16:12:45 +0000 (11:12 -0500)]
PCI: Don't look for ACPI hotplug parameters if ACPI is disabled
Booting a v3.18 or newer Xen domU kernel with PCI devices passed through
results in an oops (this is a 32-bit 3.13.11 dom0 with a 64-bit 4.4.0
hypervisor and 32-bit domU):
Don't look for ACPI configuration information if ACPI has been disabled.
I don't think this is the best fix, because we can boot plain Linux (no
Xen) with "acpi=off", and we don't need this check in pci_get_hp_params().
There should be a better fix that would make Xen domU work the same way.
The domU kernel has ACPI support but it has no AML. There should be a way
to initialize the ACPI data structures so things fail gracefully rather
than oopsing. This is an interim fix to address the regression.
Fixes: 6cd33649fa83 ("PCI: Add pci_configure_device() during enumeration") Link: https://bugzilla.kernel.org/show_bug.cgi?id=96301 Reported-by: Michael D Labriola <mlabriol@gdeb.com> Tested-by: Michael D Labriola <mlabriol@gdeb.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> CC: stable@vger.kernel.org # v3.18+
ARM: mvebu: use 0xf1000000 as internal registers on Armada 370 DB
All Marvell EBU SoCs (Kirkwood, Dove, Orion, Armada) have the
capability of changing the location of their internal registers (i.e
the registers for most hardware blocks inside the SoC). When coming
out of reset, the internal registers are mapped at 0xd0000000, but
since years and years, the tradition has been to have the internal
registers remapped at 0xf1000000 by the bootloader, and Linux has
since then assumed that the internal registers for the SoC were
located at 0xf1000000 on Kirkwood, Dove, Orion, etc. Linux has never
been aware that those registers are remappable (and there is no way to
know where they are mapped at runtime, since the register to configure
the address of the registers is itself within the internal registers).
Then came the Armada 370 and Armada XP, in which some of the very
early silicon steppings had an issue, which forced to use 0xd0000000:
the SoC was no longer working properly when the internal registers
were remapped at 0xf1000000. This issue is only affecting very early
silicon steppings and production steppings are not affected: the issue
has been fixed in between.
Since what we (Free Electrons) used to do the initial submission of
the Armada 370 and Armada XP platforms was evaluation boards with
those very early steppings, we submitted Device Tree that assumed the
internal registers were mapped at 0xd0000000. This is the case for
Armada 370 DB, Armada XP DB and Armada XP GP.
However, in practice, since Marvell has been shipping the evaluation
boards with production steppings of the SoC, they are shipping those
boards with bootloaders that remap the registers to 0xf1000000. We
have already changed this internal register address to 0xf1000000 for
the Armada XP DB in commit 82066bdb5a75 and for the Armada XP GP in
commit 91ed32200e6e (both merged in v3.15).
We only recently got our hand on an Armada 370 DB with a production
stepping of the SoC, which uses a bootloader that remaps internal
registers at 0xf1000000. Therefore, this commit aligns the Armada 370
DB to be like the Armada XP DB and Armada XP GP: assume that the
internal registers are mapped at 0xf1000000.
We would like to stress out the fact that the usage of 0xd0000000 as
the internal register base address was a temporary workaround for
early steppings deficiencies, and that the real long-term solution is
the usage of 0xf1000000. Having 0xd0000000 is an *accident* in the
life of the Marvell platform support in the kernel, as is confirmed by
the usage of 0xf1000000 in all previous Marvell platforms (Dove,
Kirkwood, Orion).
There are unfortunately a number of commercial devices that continue
to use 0xd0000000 even though they use production steppings of the
SoC, simply because the vendors of such devices have never bothered
using a more recent bootloader version from Marvell. There is not much
we can do about it, and we plan on keeping 0xd0000000 in the Device
Tree of such devices.
The main reason for remapping the internal registers at 0xf1000000
instead of 0xd0000000 is that it leaves more space in the 0 -> 4 GB
part of the physical address space for RAM. With registers at
0xd0000000, all RAM between 0xd0000000 to 0xffffffff is lost because
it's covered by the I/O registers.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Acked-by: Andrew Lunn <andrew@lunn.ch> Acked-by: Jason Cooper <jason@lakedameon.net> Acked-by: Gregory CLEMENT <gregory.clement@free-electrons.com> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Kailang Yang [Wed, 8 Apr 2015 08:34:00 +0000 (16:34 +0800)]
ALSA: hda/realtek - Make more stable to get pin sense for ALC283
Pin sense will active when power pin is wake up.
Power pin will not wake up immediately during resume state.
Add some delay to wait for power pin activated.
Signed-off-by: Kailang Yang <kailang@realtek.com> Cc: <stable@vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de>
drm: Fix deadlock due to getconnector locking changes
If the drm_connector_find() call returns NULL, we should no longer
call drm_modeset_unlock() to avoid locking imbalance.
Signed-off-by: Tommi Rantala <tt.rantala@gmail.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Dave Airlie <airlied@redhat.com>
mm: numa: disable change protection for vma(VM_HUGETLB)
Currently when a process accesses a hugetlb range protected with
PROTNONE, unexpected COWs are triggered, which finally puts the hugetlb
subsystem into a broken/uncontrollable state, where for example
h->resv_huge_pages is subtracted too much and wraps around to a very
large number, and the free hugepage pool is no longer maintainable.
This patch simply stops changing protection for vma(VM_HUGETLB) to fix
the problem. And this also allows us to avoid useless overhead of minor
faults.
Signed-off-by: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com> Suggested-by: Mel Gorman <mgorman@suse.de> Cc: Hugh Dickins <hughd@google.com> Cc: "Kirill A. Shutemov" <kirill@shutemov.name> Cc: David Rientjes <rientjes@google.com> Cc: Rik van Riel <riel@redhat.com> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Cc: Ingo Molnar <mingo@elte.hu> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Mark Brown [Tue, 7 Apr 2015 21:26:44 +0000 (14:26 -0700)]
include/linux/dmapool.h: declare struct device
dmapool uses struct device in function arguments but relies on an
implicit inclusion to declare struct device causing warnings in some
configurations:
include/linux/dmapool.h:31:7: warning: 'struct device' declared inside parameter list
Fix this by adding a struct device declaration to the file.
Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
mm: move zone lock to a different cache line than order-0 free page lists
Huang Ying reported the following problem due to commit 3484b2de9499 ("mm:
rearrange zone fields into read-only, page alloc, statistics and page
reclaim lines") from the Intel performance tests
The problem is specific to very large machines under stress. It was not
reproducible with the machines I had used to justify the original patch
because large numbers of CPUs are required. When pressure is high enough,
the cache line is bouncing between CPUs trying to acquire the lock and the
holder of the lock adjusting free lists. The intention was that the
acquirer of the lock would automatically have the cache line holding the
free lists but according to Huang, this is not a universal win.
One possibility is to move the zone lock to its own cache line but it
increases the size of the zone. This patch moves the lock to the other
end of the free lists where they do not contend under high pressure. It
does mean the page allocator paths now require more cache lines but Huang
reports that it restores performance to previous levels on large machines
Beshay, Joseph [Mon, 6 Apr 2015 18:00:56 +0000 (18:00 +0000)]
netem: Fixes byte backlog accounting for the first of two chained netem instances
Fixes byte backlog accounting for the first of two chained netem instances.
Bytes backlog reported now corresponds to the number of queued packets.
When two netem instances are chained, for instance to apply rate and queue
limitation followed by packet delay, the number of backlogged bytes reported
by the first netem instance is wrong. It reports the sum of bytes in the queues
of the first and second netem. The first netem reports the correct number of
backlogged packets but not bytes. This is shown in the example below.
Consider a chain of two netem schedulers created using the following commands:
The interface used to produce this output has an MTU of 1500. The output for
backlogged bytes behind netem 1 is 172694b. This value is not correct. Consider
the total number of sent bytes and packets. By dividing the number of sent
bytes by the number of sent packets, we get an average packet size of ~=1504.
If we divide the number of backlogged bytes by packets, we get ~=2365. This is
due to the first netem incorrectly counting the 63588b which are in netem 2's
queue as being in its own queue. To verify this is the case, we subtract them
from the reported value and divide by the number of packets as follows:
172694 - 63588 = 109106 bytes actualled backlogged in netem 1
109106 / 73 packets ~= 1494 bytes (which matches our MTU)
The root cause is that the byte accounting is not done at the
same time with packet accounting. The solution is to update the backlog value
every time the packet queue is updated.
Signed-off-by: Joseph D Beshay <joseph.beshay@utdallas.edu> Acked-by: Hagen Paul Pfeifer <hagen@jauu.net> Signed-off-by: David S. Miller <davem@davemloft.net>
Dirty page throttling should be sufficient for us in the general case
so there is no need to use __GFP_MEMALLOC - it would be needed only in
the swap-over-rbd case, which we currently don't support. (It would
probably take approximately the commit that is being reverted to add
that support, but we would also need the "swap" option to distinguish
from the general case and make sure swap ceph_client-s aren't shared
with anything else.) See ceph-devel threads [1] and [2] for the
details of why enabling pfmemalloc reserves for all cases is a bad
thing.
On top of potential system lockups related to drained emergency
reserves, this turned out to cause ceph lockups in case peers are on
the same host and communicating via loopback due to sk_filter()
dropping pfmemalloc skbs on the receiving side because the receiving
loopback socket is not tagged with SOCK_MEMALLOC.
[1] "SOCK_MEMALLOC vs loopback"
http://www.spinics.net/lists/ceph-devel/msg22998.html
[2] "[PATCH] libceph: don't set memalloc flags in loopback case"
http://www.spinics.net/lists/ceph-devel/msg23392.html
Russell King [Thu, 2 Apr 2015 14:38:18 +0000 (15:38 +0100)]
ARM: vexpress: fix CPU hotplug with CT9x4 tile.
The Cortex A9 tile fails to unplug CPUs if errata 643719 is not enabled.
This leads to random weird behaviours, but ultimately seem to lock the
kernel one way or another when a CPU is hot unplugged.
Symptoms range from a spinlock lockup in the scheduler, the entire
system hanging, to dumping out the kernel printk buffer a few lines at
a time, and other weird behaviours.
This is caused by the outgoing CPU not having its inner caches properly
flushed before it exits coherency - flush_cache_louis() is used to
achieve this, but as a result of the hardware bug, this function ends
up doing nothing without the errata workaround enabled.
As the Versatile Express has an affected CPU, this errata must always
be enabled.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
drm/i915: vlv: factor out vlv_force_gfx_clock and check for pending force-of
but I'm not sure why. It has caused problems for us in the past (see 85250ddff7a6 "drm/i915/chv: Remove Wait for a previous gfx force-off"
and 8d4eee9cd7a1 "drm/i915: vlv: increase timeout when forcing on the
GFX clock") and doesn't seem to be required, so let's just drop it.
References: https://bugs.freedesktop.org/show_bug.cgi?id=89611 Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Tested-by: Darren Hart <dvhart@linux.intel.com> Reviewed-by: Deepak S <deepak.s@linux.intel.com> Cc: stable@vger.kernel.org # c9c52e24194a: drm/i915/chv: Remove Wait ... Cc: stable@vger.kernel.org Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Deepak S [Sat, 28 Mar 2015 09:53:34 +0000 (15:23 +0530)]
drm/i915/chv: Remove Wait for a previous gfx force-off
On CHV, PUNIT team confirmed that 'VLV_GFX_CLK_STATUS_BIT' is not a
sticky bit and it will always be set. So ignore Check for previous
Gfx force off during suspend and allow the force clk as part S0ix
Sequence
Signed-off-by: Deepak S <deepak.s@linux.intel.com> Cc: stable@vger.kernel.org Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
drm/i915/vlv: save/restore the power context base reg
Some BIOSes (e.g. the one on the Minnowboard) don't save/restore this
reg. If it's unlocked, we can just restore the previous value, and if
it's locked (in case the BIOS re-programmed it for us) the write will be
ignored and we'll still have "did it move" sanity check in the PM code to
warn us if something is still amiss.
References: https://bugs.freedesktop.org/show_bug.cgi?id=89611 Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Tested-by: Darren Hart <dvhart@linux.intel.com> Cc: stable@vger.kernel.org Reviewed-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Deepak S <deepak.s@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Yao Xiwei [Thu, 2 Apr 2015 15:31:17 +0000 (17:31 +0200)]
vti6: fix uninit when using x-netns
When the kernel deleted a vti6 interface, this interface was not removed from
the tunnels list. Thus, when the ip6_vti module was removed, this old interface
was found and the kernel tried to delete it again. This was leading to a kernel
panic.
Fixes: 61220ab34948 ("vti6: Enable namespace changing") Signed-off-by: Yao Xiwei <xiwei.yao@6wind.com> Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com> Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
Commit 70be6c91c86596ad2b60c73587880b47df170a41
("xfrm: Add xfrm_tunnel_skb_cb to the skb common buffer") added check
which dereferences ->outer_mode too early but larval SAs don't have
this pointer set (yet). So check for tunnel stuff later.
Mike Noordermeer reported this bug and patiently applied all the debugging.
Technically this is remote-oops-in-interrupt-context type of thing.
Input: elantech - fix absolute mode setting on some ASUS laptops
On ASUS TP500LN and X750JN, the touchpad absolute mode is reset each
time set_rate is done.
In order to fix this, we will verify the firmware version, and if it
matches the one in those laptops, the set_rate function is overloaded
with a function elantech_set_rate_restore_reg_07 that performs the
set_rate with the original function, followed by a restore of reg_07
(the register that sets the absolute mode on elantech v4 hardware).
Also the ASUS TP500LN and X750JN firmware version, capabilities, and
button constellation is added to elantech.c
Cc: stable@vger.kernel.org Reported-and-tested-by: George Moutsopoulos <gmoutso@yahoo.co.uk> Signed-off-by: Ulrik De Bie <ulrik.debie-os@e2big.org> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
1) In TCP, don't register an FRTO for cumulatively ACK'd data that was
previously SACK'd, from Neal Cardwell.
2) Need to hold RNL mutex in ipv4 multicast code namespace cleanup,
from Cong WANG.
3) Similarly we have to hold RNL mutex for fib_rules_unregister(), also
from Cong WANG.
4) Revert and rework netns nsid allocation fix, from Nicolas Dichtel.
5) When we encapsulate for a tunnel device, skb->sk still points to the
user socket. So this leads to cases where we retraverse the
ipv4/ipv6 output path with skb->sk being of some other address
family (f.e. AF_PACKET). This can cause things to crash since the
ipv4 output path is dereferencing an AF_PACKET socket as if it were
an ipv4 one.
The short term fix for 'net' and -stable is to elide these socket
checks once we've entered an encapsulation sequence by testing
xmit_recursion.
Longer term we have a better solution wherein we pass the tunnel's
socket down through the output paths, but that is way too invasive
for 'net' and -stable.
From Hannes Frederic Sowa.
6) l2tp_init() failure path forgets to unregister per-net ops, from
Cong WANG.
* git://git.kernel.org/pub/scm/linux/kernel/git/davem/net:
net/mlx4_core: Fix error message deprecation for ConnectX-2 cards
net: dsa: fix filling routing table from OF description
l2tp: unregister l2tp_net_ops on failure path
mvneta: dont call mvneta_adjust_link() manually
ipv6: protect skb->sk accesses from recursive dereference inside the stack
netns: don't allocate an id for dead netns
Revert "netns: don't clear nsid too early on removal"
ip6mr: call del_timer_sync() in ip6mr_free_table()
net: move fib_rules_unregister() under rtnl lock
ipv4: take rtnl_lock and mark mrt table as freed on namespace cleanup
tcp: fix FRTO undo on cumulative ACK of SACKed range
xen-netfront: transmit fully GSO-sized packets
net/mlx4_core: Fix error message deprecation for ConnectX-2 cards
Commit 1daa4303b4ca ("net/mlx4_core: Deprecate error message at
ConnectX-2 cards startup to debug") did the deprecation only for port 1
of the card. Need to deprecate for port 2 as well.
Fixes: 1daa4303b4ca ("net/mlx4_core: Deprecate error message at ConnectX-2 cards startup to debug") Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il> Signed-off-by: Amir Vadai <amirv@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
net: dsa: fix filling routing table from OF description
According to description in 'include/net/dsa.h', in cascade switches
configurations where there are more than one interconnected devices,
'rtable' array in 'dsa_chip_data' structure is used to indicate which
port on this switch should be used to send packets to that are destined
for corresponding switch.
However, dsa_of_setup_routing_table() fills 'rtable' with port numbers
of the _target_ switch, but not current one.
This commit removes redundant devicetree parsing and adds needed port
number as a function argument. So dsa_of_setup_routing_table() now just
looks for target switch number by parsing parent of 'link' device node.
To remove possible misunderstandings with the way of determining target
switch number, a corresponding comment was added to the source code and
to the DSA device tree bindings documentation file.
This was tested on a custom board with two Marvell 88E6095 switches with
following corresponding routing tables: { -1, 10 } and { 8, -1 }.
Signed-off-by: Pavel Nakonechny <pavel.nakonechny@skitlab.ru> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input
Pull input fixes from Dmitry Torokhov:
"Updates for the input subsystem - two more tweaks for ALPS driver to
work out kinks after splitting the touchpad, trackstick, and potential
external PS/2 mouse into separate input devices.
Changes to support ALPS SS4 devices (protocol V8) will be coming in
4.1..."
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input:
Input: alps - document stick behavior for protocol V2
Input: alps - report V2 Dualpoint Stick events via the right evdev node
Input: alps - report interleaved bare PS/2 packets via dev3
ipv6: protect skb->sk accesses from recursive dereference inside the stack
We should not consult skb->sk for output decisions in xmit recursion
levels > 0 in the stack. Otherwise local socket settings could influence
the result of e.g. tunnel encapsulation process.
ipv6 does not conform with this in three places:
1) ip6_fragment: we do consult ipv6_npinfo for frag_size
2) sk_mc_loop in ipv6 uses skb->sk and checks if we should
loop the packet back to the local socket
3) ip6_skb_dst_mtu could query the settings from the user socket and
force a wrong MTU
Furthermore:
In sk_mc_loop we could potentially land in WARN_ON(1) if we use a
PF_PACKET socket ontop of an IPv6-backed vxlan device.
Reuse xmit_recursion as we are currently only interested in protecting
tunnel devices.
Cc: Jiri Pirko <jiri@resnulli.us> Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org> Signed-off-by: David S. Miller <davem@davemloft.net>
Nicolas Ferre [Sun, 5 Apr 2015 20:30:18 +0000 (22:30 +0200)]
Merge tag 'at91-dt2' into at91-next
Second batch of DT changes for 4.1:
- RTC nodes for at91sam9x5 boards and at91sam9n12ek
- HLCDC nodes and pin definitions for sama5d3 & sama5d4
- additional uarts for sama5d3
Nicolas Ferre [Sun, 5 Apr 2015 20:29:14 +0000 (22:29 +0200)]
Merge tag 'at91-cleanup4_bis' into at91-next
Fourth batch of cleanup for 4.1:
- 1 issues revealed by the kbuild test robot fixed
- move of some functions and macros into relevant files to be able to
streamline the at91 specific header afterwards
Hans de Goede [Sat, 4 Apr 2015 00:20:05 +0000 (17:20 -0700)]
Input: alps - report V2 Dualpoint Stick events via the right evdev node
On V2 devices the DualPoint Stick reports bare packets, these should be
reported via the "AlpsPS/2 ALPS DualPoint Stick" dev2 evdev node, which also
has the INPUT_PROP_POINTING_STICK propbit set.
Note that since there is no way to distinguish these packets from an external
PS/2 mouse (insofar as these laptops have an external PS/2 port) this means
that we will be reporting PS/2 mouse events via this evdev node too, as we've
been doing in kernel 3.19 and older.
This has been tested on a Dell Latitude D620 and a Dell Latitude E6400,
which both have a V2 touchpad + a DualPoint Stick which reports bare packets.
Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Pali Rohár <pali.rohar@gmail.com> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Hans de Goede [Sat, 4 Apr 2015 00:14:40 +0000 (17:14 -0700)]
Input: alps - report interleaved bare PS/2 packets via dev3
Bare packets should be reported via the same evdev device independent on
whether they are detected on the beginning of a packet or in the middle
of a packet.
This has been tested on a Dell Latitude E6400, where the DualPoint Stick
reports bare packets, which get reported via dev3 when the touchpad is
idle, and via dev2 when the touchpad and stick are used simultaneously.
This commit fixes this inconsistency by always reporting bare packets via
dev3. Note that since the come from a DualPoint Stick they really should be
reported via dev2, this gets fixed in a later commit.
Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Pali Rohár <pali.rohar@gmail.com> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Merge tag 'usb-4.0-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb
Pull USB fixes from Greg KH:
"Here are some small USB fixes and new device ids for 4.0-rc6. Nothing
major, some xhci fixes for reported problems, and some usb-serial
device ids.
All have been in linux-next for a while"
* tag 'usb-4.0-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb:
USB: ftdi_sio: Use jtag quirk for SNAP Connect E10
usb: isp1760: fix spin unlock in the error path of isp1760_udc_start
usb: xhci: apply XHCI_AVOID_BEI quirk to all Intel xHCI controllers
usb: xhci: handle Config Error Change (CEC) in xhci driver
USB: keyspan_pda: add new device id
USB: ftdi_sio: Added custom PID for Synapse Wireless product
Merge tag 'staging-4.0-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging
Pull staging driver fixes from Greg KH:
"Here are some staging driver fixes, well, really all just IIO driver
fixes, for 4.0-rc6. They fix issues that have been reported with
these drivers.
All of these patches have been in linux-next for a while"
* tag 'staging-4.0-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging:
iio: imu: Use iio_trigger_get for indio_dev->trig assignment
iio: adc: vf610: use ADC clock within specification
iio/adc/cc10001_adc.c: Fix !HAS_IOMEM build
iio: core: Fix double free.
iio:inv-mpu6050: Fix inconsistency for the scale channel
staging: iio: dummy: Fix undefined symbol build error
iio: inv_mpu6050: Clear timestamps fifo while resetting hardware fifo
staging: iio: hmc5843: Set iio name property in sysfs
iio: bmc150: change sampling frequency
iio: fix drivers that check buffer->scan_mask
Merge tag 'tty-4.0-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty
Pull tty/serial fixes from Greg KH:
"Here are 3 serial driver fixes for 4.0-rc6. They fix some reported
issues with the samsung and fsl_lpuart drivers.
All have been in linux-next for a while"
* tag 'tty-4.0-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty:
tty: serial: fsl_lpuart: clear receive flag on FIFO flush
tty: serial: fsl_lpuart: specify transmit FIFO size
serial: samsung: Clear operation mode on UART shutdown
Eric Wong [Tue, 31 Mar 2015 07:34:05 +0000 (07:34 +0000)]
ALSA: usb-audio: don't try to get Benchmark DAC1 sample rate
Adding this quirk allows us to avoid the noisy
"cannot get freq at ep 0x1" message in dmesg output every time
playback starts.
This ought to affect other Benchmark DAC1 variations using the same
"Microchip Technology, Inc." chip as well, but I have only tested
with the "Pre" variant.
Signed-off-by: Eric Wong <normalperson@yhbt.net> Cc: Joe Turner <joe@oampo.co.uk> Signed-off-by: Takashi Iwai <tiwai@suse.de>
Olof Johansson [Fri, 3 Apr 2015 22:07:21 +0000 (15:07 -0700)]
Merge branch 'next/soc' into for-next
* next/soc:
ARM: EXYNOS: allow cpuidle driver usage on Exynos3250 SoC
ARM: EXYNOS: add AFTR mode support for Exynos3250
ARM: EXYNOS: add code for setting/clearing boot flag
ARM: EXYNOS: fix CPU1 hotplug on Exynos3250
ARM: S3C64XX: Use fixed IRQ bases to avoid conflicts on Cragganmore
ARM: EXYNOS: Remove left over 'extra_save'
ARM: EXYNOS: Constify exynos_pm_data array
ARM: EXYNOS: use static in suspend.c
ARM: EXYNOS: Use platform device name as power domain name
ARM: EXYNOS: add support for async-bridge clocks for pm_domains
Olof Johansson [Fri, 3 Apr 2015 22:06:26 +0000 (15:06 -0700)]
Merge branch 'next/dt' into for-next
* next/dt:
ARM: dts: Fixed typo interrupt-cells for exynos5420 and exynos5250
ARM: dts: Add HS400 support for exynos5420 and exynos5800
ARM: dts: add async-bridge clocks to gsc power domain for exynos5420
ARM: dts: add async-bridge clocks to disp1 power domain for exynos5420
dt-bindings: add asynchronous bridge clock for exynos
ARM: dts: Define stdout-path property for exynos5250-spring
ARM: dts: Define stdout-path property for exynos5250-snow
ARM: dts: Define stdout-path property for Peach boards
ARM: dts: Add assigned clock parents to CMU node for exynos3250
ARM: dts: Add mclk entry for Peach boards
ARM: dts: Add WiFi module support for Peach boards
ARM: dts: Mux XMMCnDATA[0] pad correctly for Exynos5420 boards
ARM: dts: add eMMC reset line for exynos5422-odroidxu3
ARM: dts: add eMMC reset line for exynos4412-odroid-common
ARM: dts: represent bridge and panel connection for exynos5420-peach-pit
ARM: dts: represent bridge and panel connection for exynos5250-snow
ARM: dts: Add cap-sdio-irq to wifi mmc node for exynos5250-snow
ARM: dts: Enable wifi power-on for exynos5250-snow
Olof Johansson [Fri, 3 Apr 2015 22:05:41 +0000 (15:05 -0700)]
Merge tag 'samsung-updates' of git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung into next/soc
Merge "Samsung mach updates for v4.1" from Kukjin Kim:
- for s3c64xx
: use fixed IRQ bases to avoid conflicts on Cragganmore
- for exynos3250
: add cpuidle and AFTR mode support
: fix CPU1 hotplug
- for exynos SoCs
: add code for setting/clearing boot flag for cpuidle AFTR
: remove left over 'extra_save' and constify 'exynos_pm_data' array
: use static in suspend.c as per compiler suggestions
: use platform device name as power domain name
: add support for async-bridge clocks for pm_domains (exynos5420)
* tag 'samsung-updates' of git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung:
ARM: EXYNOS: allow cpuidle driver usage on Exynos3250 SoC
ARM: EXYNOS: add AFTR mode support for Exynos3250
ARM: EXYNOS: add code for setting/clearing boot flag
ARM: EXYNOS: fix CPU1 hotplug on Exynos3250
ARM: S3C64XX: Use fixed IRQ bases to avoid conflicts on Cragganmore
ARM: EXYNOS: Remove left over 'extra_save'
ARM: EXYNOS: Constify exynos_pm_data array
ARM: EXYNOS: use static in suspend.c
ARM: EXYNOS: Use platform device name as power domain name
ARM: EXYNOS: add support for async-bridge clocks for pm_domains
Olof Johansson [Fri, 3 Apr 2015 21:59:52 +0000 (14:59 -0700)]
Merge tag 'samsung-dt' of git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung into next/dt
Merge "Samsung DT updates for v4.1" from Kukjin Kim:
- for exynos3250
: add assigned clock parents for CMU nodes
- for exynos4412-odroid
: add eMMC reset line
- for exynos5250
: fixed typo for interrupt-cells
- for exynos5250-snow
: define stdout-path property
: represent bridge and panel connection
: enable wifi power-on and add cap-sdio-irq to wifi mmc node
- for exynos5250-spring
: define stdout-path property
- for exynos5420
: fixed typo for interrupt-cells
: add async-bridge clocks for gsc and disp1 PDs
- for exynos5420 boards
: Mux XMMCnDATA[0] pad correctly
- for exynos5420-odroidxu3
: add eMMC reset line
- for Peach boards
: add HS400 support and define stdout-path property
: add mclk entry and add WiFi module support
: represent bridge and panel connection
* tag 'samsung-dt' of git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung:
ARM: dts: Fixed typo interrupt-cells for exynos5420 and exynos5250
ARM: dts: Add HS400 support for exynos5420 and exynos5800
ARM: dts: add async-bridge clocks to gsc power domain for exynos5420
ARM: dts: add async-bridge clocks to disp1 power domain for exynos5420
dt-bindings: add asynchronous bridge clock for exynos
ARM: dts: Define stdout-path property for exynos5250-spring
ARM: dts: Define stdout-path property for exynos5250-snow
ARM: dts: Define stdout-path property for Peach boards
ARM: dts: Add assigned clock parents to CMU node for exynos3250
ARM: dts: Add mclk entry for Peach boards
ARM: dts: Add WiFi module support for Peach boards
ARM: dts: Mux XMMCnDATA[0] pad correctly for Exynos5420 boards
ARM: dts: add eMMC reset line for exynos5422-odroidxu3
ARM: dts: add eMMC reset line for exynos4412-odroid-common
ARM: dts: represent bridge and panel connection for exynos5420-peach-pit
ARM: dts: represent bridge and panel connection for exynos5250-snow
ARM: dts: Add cap-sdio-irq to wifi mmc node for exynos5250-snow
ARM: dts: Enable wifi power-on for exynos5250-snow
Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input
Pull input subsystem fixes from Dmitry Torokhov:
"A fix for ALPS driver for issue introduced in the latest update and a
tweak for yet another Lenovo box in Synaptics.
There will be more ALPS tweaks coming.."
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input:
Input: define INPUT_PROP_ACCELEROMETER behavior
Input: synaptics - fix min-max quirk value for E440
Input: synaptics - add quirk for Thinkpad E440
Input: ALPS - fix max coordinates for v5 and v7 protocols
Input: add MT_TOOL_PALM
Olof Johansson [Fri, 3 Apr 2015 21:57:51 +0000 (14:57 -0700)]
Merge tag 'samsung-defconfig' of git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung into next/defconfig
Merge "Samsung defconfig updates for v4.1" from Kukjin Kim:
- update exynos-defconfig
: enable HDMI, CPUidle, ChromeOS EC chardev driver
and thermal emulation, Marvell WiFi-Ex, CPUfreq,
and support for NFS rootfs
: remove EXYNOS_THERMAL_CORE define
and disable IOMMU support until support it
* tag 'samsung-defconfig' of git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung:
ARM: exynos_defconfig: Enable HDMI support
ARM: exynos_defconfig: Enable options to mount a rootfs via NFS
ARM: exynos_defconfig: Enable ChromeOS EC chardev driver
ARM: exynos_defconfig: Enable CPU idle
ARM: exynos_defconfig: Enable Marvell WiFi-Ex support
ARM: exynos_defconfig: Disable IOMMU support
ARM: exynos_defconfig: Enable support for cpufreq on Exynos SoCs
ARM: exynos_defconfig: Enable thermal emulation for Exynos TMU
ARM: exynos_defconfig: Remove CONFIG_EXYNOS_THERMAL_CORE define
Olof Johansson [Fri, 3 Apr 2015 21:56:56 +0000 (14:56 -0700)]
Merge tag 'samsung-fixes-v4.1' of git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung into next/fixes-non-critical
Merge "Samsung non-critical fixes for v4.1" from Kukjin Kim:
- mostly trivial build fixes with random configurations
from Arnd Bergmann
for s3c24xx:
avoid a Kconfig warning and fix header file inclusions,
and fix building without PM_SLEEP and use SAMSUNG_WAKEMASK
for s3c64xx:
fix __initdata section mismatch and add I2C dependencies,
and fix building with PM_SLEEP
* tag 'samsung-fixes-v4.1' of git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung:
ARM: S3C24XX: avoid a Kconfig warning
ARM: S3C24XX: fix header file inclusions
ARM: S3C24XX: fix building without PM_SLEEP
ARM: S3C24XX: use SAMSUNG_WAKEMASK for s3c2416
ARM: S3C64XX: fix __initdata section mismatch
ARM: S3C64XX: fix building without CONFIG_PM_SLEEP
ARM: S3C64XX: add I2C dependencies where needed
Olof Johansson [Fri, 3 Apr 2015 21:56:27 +0000 (14:56 -0700)]
Merge branch 'next/dt' into for-next
* next/dt:
ARM: mvebu: Conform L2CC node with ePAPR specification by adding cache-level
ARM: mvebu: clk: remove cpuclk resources overlapping coredivclk registers on Armada XP
Nicolas Ferre [Tue, 31 Mar 2015 08:56:10 +0000 (10:56 +0200)]
ARM: at91/dt: sama5d3 xplained: add phy address for macb1
After 57a38effa598 (net: phy: micrel: disable broadcast for KSZ8081/KSZ8091)
the macb1 interface refuses to work properly because it tries
to cling to address 0 which isn't able to communicate in broadcast with
the mac anymore. The micrel phy on the board is actually configured
to show up at address 1.
Adding the phy node and its real address fixes the issue.
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com> Cc: Johan Hovold <johan@kernel.org> Cc: <stable@vger.kernel.org> #3.19 Signed-off-by: Olof Johansson <olof@lixom.net>
Olof Johansson [Fri, 3 Apr 2015 21:54:13 +0000 (14:54 -0700)]
Merge tag 'mvebu-dt-4.1-3' of git://git.infradead.org/linux-mvebu into next/dt
Merge "ARM: mvebu: dt changes for v4.1 (round 3)" from Gregory Clement:
mvebu dt changes for v4.1 (part #3)
These changes have no influence on the kernel behavior (except
removing a warning message), but they allow to have a better
representation of the hardware.
- conform L2CC node with ePAPR specification by adding cache-level
- remove cpuclk resources overlapping coredivclk registers on Armada XP
* tag 'mvebu-dt-4.1-3' of git://git.infradead.org/linux-mvebu:
ARM: mvebu: Conform L2CC node with ePAPR specification by adding cache-level
ARM: mvebu: clk: remove cpuclk resources overlapping coredivclk registers on Armada XP
Olof Johansson [Fri, 3 Apr 2015 21:51:10 +0000 (14:51 -0700)]
Merge tag 'samsung-fixes-2' of git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung into fixes
Merge "Samsung 2nd fixes for v4.0" from Kukjin Kim:
- Fix build breakage exynos cpuidle driver on !SMP
because it is coupled built-in so added check for SMP.
- Fix lid, power pin-functions and mmc node updates
for exynos5250-spring: Fixes commit ID 53dd4138bb0a
("ARM: dts: Add exynos5250-spring device tree")
* tag 'samsung-fixes-2' of git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung:
ARM: EXYNOS: Fix build breakage cpuidle on !SMP
ARM: dts: fix lid and power pin-functions for exynos5250-spring
ARM: dts: fix mmc node updates for exynos5250-spring
Olof Johansson [Fri, 3 Apr 2015 21:49:52 +0000 (14:49 -0700)]
Merge tag 'v4.0-next-soc' of https://github.com/mbgg/linux-mediatek into next/drivers
Merge "ARM: mediatek: soc updates for v4.1" from Matthias Brugger:
- enable the pin controller in Kconfig
- Add PMIC wrapper for MT8135 and MT8173 SoCs
* tag 'v4.0-next-soc' of https://github.com/mbgg/linux-mediatek:
soc: mediatek: Add PMIC wrapper for MT8135 and MT8173 SoCs
ARM: mediatek: enable the pin controller
Olof Johansson [Fri, 3 Apr 2015 21:47:54 +0000 (14:47 -0700)]
Merge tag 'v4.0-next-dts' of https://github.com/mbgg/linux-mediatek into next/dt
Merge "ARM: mediatek: dts updates for v4.1" from Matthias Brugger:
- Add pinctrl/GPIO/EINT node for mt8135.
- document binding for the PMIC wrapper
- Add watchdog to mt6589
* tag 'v4.0-next-dts' of https://github.com/mbgg/linux-mediatek:
ARM: DTS: Add watchdog to mt6589
dt-bindings: ARM: Mediatek: document binding for the PMIC wrapper
ARM: dts: mt8135: Add pinctrl/GPIO/EINT node for mt8135.