Per commit "77873803 net_dma: mark broken" net_dma is no longer used
and there is no plan to fix it.

This is the mechanical removal of bits in CONFIG_NET_DMA ifdef guards.
Reverting the remainder of the net_dma induced changes is deferred to
subsequent patches.

Marked for stable due to Roman's report of a memory leak in
dma_pin_iovec_pages():

    https://lkml.org/lkml/2014/9/3/177

Cc: Dave Jiang <dave.jiang@intel.com>
Cc: Vinod Koul <vinod.koul@intel.com>
Cc: David Whipple <whipple@securedatainnovations.ch>
Cc: Alexander Duyck <alexander.h.duyck@intel.com>
Cc: <stable@vger.kernel.org>
Reported-by: NRoman Gushchin <klamm@yandex-team.ru>
Acked-by: NDavid S. Miller <davem@davemloft.net>
Signed-off-by: NDan Williams <dan.j.williams@intel.com>

I am stepping down as dmaengine maintainer as the bulk of the activity
in the subsystem is primarily targeted at the slave-dma case handled by
Vinod, and I have recently been unable to give the few patches I do
receive timely review.  There is still an item in my backlog to
eliminate the async_tx api and the constraints it poses on dmaengine
drivers, but I need not hold on to the maintainer role in the meantime.
I will still be subscribed to dmaengine@vger.kernel.org to answer
questions, but all patches should be routed through Vinod unless/until a
maintainer for the non-slave-dma use case arrives.  It is non-entirely
clear at this point that there is enough work going forward for a
separate maintainer of the pure-offload case.

Ongoing development of the ioatdma driver is handled by Dave.  I'm still
interested in reviewing ioatdma patches, but he is the primary
maintainer/developer going forward.

IOP platforms are not generating any traffic in my inbox, but if a patch
did arrive I've long since lost access to hardware.

Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Vinod Koul <vinod.koul@intel.com>
Cc: Dave Jiang <dave.jiang@intel.com>
Signed-off-by: NDan Williams <dan.j.williams@intel.com>

When we fail to allocate memory for thread->srcs or thread->dsts and src_cnt or
dst_cnt great than 1 we leak memory on error path. This patch fixes the issue.
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: NDan Williams <dan.j.williams@intel.com>

To be future-proof and for better readability the time comparisons are modified
to use time_before_jiffies() instead of plain, error-prone math.
Signed-off-by: NManuel Schölling <manuel.schoelling@gmx.de>
[djbw: use time_before_jiffies() to make argument order more clear]
Signed-off-by: NDan Williams <dan.j.williams@intel.com>

the partial xor result must be kept until the next
tx is generated.

Cc: <stable@vger.kernel.org>
Signed-off-by: NXuelin Shi <xuelin.shi@freescale.com>
Signed-off-by: NDan Williams <dan.j.williams@intel.com>

Now that mv_xor_slot_cleanup() has no remaining callers, we remove it
and rename __mv_xor_slot_cleanup() to mv_xor_slot_cleanup().

We take this opportunity to add a comment that makes it clear that the
channel spinlock should be held before calling mv_xor_slot_cleanup().
Signed-off-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: NEzequiel Garcia <ezequiel.garcia@free-electrons.com>
Signed-off-by: NDan Williams <dan.j.williams@intel.com>

In order to simplify the code, remove all the calls to the locked
mv_xor_slot_cleanup() and instead use the unlocked version only,

It's less error prone to have just one function, and require the caller
to ensure proper locking.
Signed-off-by: NEzequiel Garcia <ezequiel.garcia@free-electrons.com>
Signed-off-by: NDan Williams <dan.j.williams@intel.com>

In mv_xor_status(), we are currently calling mv_xor_clean_completed_slots()
when the transaction is complete (the cookie status is DMA_COMPLETE).
However, a completed status means that mv_xor_slot_cleanup() was called,
which cleans the completed slots.

In other words, there's nothing to cleanup for a completed transaction in
mv_xor_status(). Remove the unneeded call to mv_xor_clean_completed_slots().
Reported-by: NDan Williams <dan.j.williams@intel.com>
Signed-off-by: NEzequiel Garcia <ezequiel.garcia@free-electrons.com>
Signed-off-by: NDan Williams <dan.j.williams@intel.com>

As result of deprecation of MSI-X/MSI enablement functions
pci_enable_msix() and pci_enable_msi_block() all drivers
using these two interfaces need to be updated to use the
new pci_enable_msi_range()  or pci_enable_msi_exact()
and pci_enable_msix_range() or pci_enable_msix_exact()
interfaces.

Function pci_enable_msix() returns a tri-state value while
pci_enable_msi_exact() is a canonical zero/-errno variant.
The former is being phased out in favor of the latter.
In case of 'ioat' there (should be) no difference.

Cc: Vinod Koul <vinod.koul@intel.com>
Signed-off-by: NAlexander Gordeev <agordeev@redhat.com>
Signed-off-by: NDan Williams <dan.j.williams@intel.com>

Includes an appropriate header file dma_v2.h in ioat/dca.c because
functions ioat2_dca_init() and ioat3_dca_init() have their function
declarations in dma_v2.h.

This eliminates the following warning in ioat/dca.c:
drivers/dma/ioat/dca.c:410:22: warning: no previous prototype for ‘ioat2_dca_init’ [-Wmissing-prototypes]
drivers/dma/ioat/dca.c:624:22: warning: no previous prototype for ‘ioat3_dca_init’ [-Wmissing-prototypes]
Signed-off-by: NRashika Kheria <rashika.kheria@gmail.com>
Reviewed-by: NJosh Triplett <josh@joshtriplett.org>
Acked-by: NVinod Koul <vinod.koul@intel.com>
Signed-off-by: NDan Williams <dan.j.williams@intel.com>

Mark the functions ioat3_prep_xor_val(), ioat3_prep_pq_val() and
ioat3_prep_pqxor_val() as static in dma_v3.c because they are not used
outside this file.

This eliminates the following warnings in dma_v3.c:
drivers/dma/ioat/dma_v3.c:741:1: warning: no previous prototype for ‘ioat3_prep_xor_val’ [-Wmissing-prototypes]
drivers/dma/ioat/dma_v3.c:1092:1: warning: no previous prototype for ‘ioat3_prep_pq_val’ [-Wmissing-prototypes]
drivers/dma/ioat/dma_v3.c:1134:1: warning: no previous prototype for ‘ioat3_prep_pqxor_val’ [-Wmissing-prototypes]
Signed-off-by: NRashika Kheria <rashika.kheria@gmail.com>
Reviewed-by: NJosh Triplett <josh@joshtriplett.org>
Acked-by: NVinod Koul <vinod.koul@intel.com>
Signed-off-by: NDan Williams <dan.j.williams@intel.com>

This commit adds proper error checking for various DMA API calls,
as reported by DMA_API_DEBUG=y.
Signed-off-by: NEzequiel Garcia <ezequiel.garcia@free-electrons.com>
Signed-off-by: NDan Williams <dan.j.williams@intel.com>

Use PCI standard marco dev_is_pci() instead of directly compare
pci_bus_type to check whether it is pci device.
Signed-off-by: NYijing Wang <wangyijing@huawei.com>
Signed-off-by: NDan Williams <dan.j.williams@intel.com>

Pull scheduler fixes from Ingo Molnar:
 "Three small fixes"

* 'sched-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  sched/clock: Prevent tracing recursion in sched_clock_cpu()
  stop_machine: Fix^2 race between stop_two_cpus() and stop_cpus()
  sched/deadline: Deny unprivileged users to set/change SCHED_DEADLINE policy

Pull perf fixes from Ingo Molnar:
 "Misc smaller fixes"

* 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  perf/x86: Fix leak in uncore_type_init failure paths
  perf machine: Use map as success in ip__resolve_ams
  perf symbols: Fix crash in elf_section_by_name
  perf trace: Decode architecture-specific signal numbers

While testing and documenting the msgrcv() MSG_COPY flag that Stanislav
Kinsbursky added in commit 4a674f34 ("ipc: introduce message queue
copy feature" => kernel 3.8), I discovered a couple of bugs in the
implementation.  The two bugs concern MSG_COPY interactions with other
msgrcv() flags, namely:

 (A) MSG_COPY + MSG_EXCEPT
 (B) MSG_COPY + !IPC_NOWAIT

The bugs are distinct (and the fix for the first one is obvious),
however my fix for both is a single-line patch, which is why I'm
combining them in a single mail, rather than writing two mails+patches.

 ===== (A) MSG_COPY + MSG_EXCEPT =====

With the addition of the MSG_COPY flag, there are now two msgrcv()
flags--MSG_COPY and MSG_EXCEPT--that modify the meaning of the 'msgtyp'
argument in unrelated ways.  Specifying both in the same call is a
logical error that is currently permitted, with the effect that MSG_COPY
has priority and MSG_EXCEPT is ignored.  The call should give an error
if both flags are specified.  The patch below implements that behavior.

 ===== (B) (B) MSG_COPY + !IPC_NOWAIT =====

The test code that was submitted in commit 3a665531 ("selftests: IPC
message queue copy feature test") shows MSG_COPY being used in
conjunction with IPC_NOWAIT.  In other words, if there is no message at
the position 'msgtyp'.  return immediately with the error in ENOMSG.

What was not (fully) tested is the behavior if MSG_COPY is specified
*without* IPC_NOWAIT, and there is an odd behavior.  If the queue
contains less than 'msgtyp' messages, then the call blocks until the
next message is written to the queue.  At that point, the msgrcv() call
returns a copy of the newly added message, regardless of whether that
message is at the ordinal position 'msgtyp'.  This is clearly bogus, and
problematic for applications that might want to make use of the MSG_COPY
flag.

I considered the following possible solutions to this problem:

 (1) Force the call to block until a message *does* appear at the
     position 'msgtyp'.

 (2) If the MSG_COPY flag is specified, the kernel should implicitly add
     IPC_NOWAIT, so that the call fails with ENOMSG for this case.

 (3) If the MSG_COPY flag is specified, but IPC_NOWAIT is not, generate
     an error (probably, EINVAL is the right one).

I do not know if any application would really want to have the
functionality of solution (1), especially since an application can
determine in advance the number of messages in the queue using msgctl()
IPC_STAT.  Obviously, this solution would be the most work to implement.

Solution (2) would have the effect of silently fixing any applications
that tried to employ broken behavior.  However, it would mean that if we
later decided to implement solution (1), then user-space could not
easily detect what the kernel supports (but, since I'm somewhat doubtful
that solution (1) is needed, I'm not sure that this is much of a
problem).

Solution (3) would have the effect of informing broken applications that
they are doing something broken.  The downside is that this would cause
a ABI breakage for any applications that are currently employing the
broken behavior.  However:

a) Those applications are almost certainly not getting the results they
   expect.
b) Possibly, those applications don't even exist, because MSG_COPY is
   currently hidden behind CONFIG_CHECKPOINT_RESTORE.

The upside of solution (3) is that if we later decided to implement
solution (1), user-space could determine what the kernel supports, via
the error return.

In my view, solution (3) is mildly preferable to solution (2), and
solution (1) could still be done later if anyone really cares.  The
patch below implements solution (3).

PS.  For anyone out there still listening, it's the usual story:
documenting an API (and the thinking about, and the testing of the API,
that documentation entails) is the one of the single best ways of
finding bugs in the API, as I've learned from a lot of experience.  Best
to do that documentation before releasing the API.
Signed-off-by: NMichael Kerrisk <mtk.manpages@gmail.com>
Acked-by: NStanislav Kinsbursky <skinsbursky@parallels.com>
Cc: Stanislav Kinsbursky <skinsbursky@parallels.com>
Cc: stable@vger.kernel.org
Cc: Serge Hallyn <serge.hallyn@canonical.com>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Pavel Emelyanov <xemul@parallels.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Pull SCSI fixes from James Bottomley:
 "This is a set of six fixes.  Two are instant crash/null deref types
  (storvsc and isci).  The two qla2xxx are initialisation problems that
  cause MSI-X failures and card misdetection, the isci erroneous macro
  is actually illegal C that's causing a miscompile with certain gcc
  versions and the be2iscsi bad if expression is a static checker fix"

* tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi:
  [SCSI] storvsc: NULL pointer dereference fix
  [SCSI] qla2xxx: Poll during initialization for ISP25xx and ISP83xx
  [SCSI] isci: correct erroneous for_each_isci_host macro
  [SCSI] isci: fix reset timeout handling
  [SCSI] be2iscsi: fix bad if expression
  [SCSI] qla2xxx: Fix multiqueue MSI-X registration.

Pull x86 fixes from Peter Anvin:
 "Two x86 fixes: Suresh's eager FPU fix, and a fix to the NUMA quirk for
  AMD northbridges.

  This only includes Suresh's fix patch, not the "mostly a cleanup"
  patch which had __init issues"

* 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  x86/amd/numa: Fix northbridge quirk to assign correct NUMA node
  x86, fpu: Check tsk_used_math() in kernel_fpu_end() for eager FPU

Pull ACPI and power management fixes from Rafael Wysocki:
 "Three of these are regression fixes, for two recent regressions and
  one introduced during the 3.13 cycle, and the fourth one is a working
  version of the fix that had to be reverted last time.

  Specifics:

   - A recent ACPI resources handling fix overlooked the fact that it
     had to update the ACPI PNP subsystem's resources parsing too and
     caused confusing warning messages to be printed during system
     intialization on some systems (with arguably buggy ACPI tables).
     Fix from Zhang Rui.

   - Moving the early ACPI initialization before timekeeping_init()
     earlier in this cycle broke fast TSC calibration on at least one
     system, so it needs to be done later, but still before
     efi_enter_virtual_mode() to allow the EFI initialization to refer
     to ACPI.

   - A change related to code duplication reduction in the cpufreq core
     inadvertently caused cpufreq intialization to fail for some CPUs
     handled by intel_pstate by adding checks that may fail for that
     driver, but aren't even necessary when it is used.  The issue is
     addressed by preventing those checks from run in the configurations
     in which they aren't needed.

   - If the Hardware Reduced ACPI flag is set in the ACPI tables, system
     suspend, hibernation and ACPI power off will only work when special
     sleep control and sleep status registeres are provided (their
     addresses in the ACPI tables are not zero).  If those registers are
     not available, the features in question have no chances to work, so
     they shouldn't even be regarded as supported.  That helps with
     power off in particular, because alternative power off methods may
     be used then and they may actually work"

* tag 'pm+acpi-3.14-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
  ACPI / sleep: Add extra checks for HW Reduced ACPI mode sleep states
  ACPI / init: Invoke early ACPI initialization later
  cpufreq: Skip current frequency initialization for ->setpolicy drivers
  PNP / ACPI: proper handling of ACPI IO/Memory resource parsing failures

Pull device-mapper fixes form Mike Snitzer:
 "Two small fixes for the DM cache target:

   - fix corruption with >2TB fast device due to truncation bug
   - fix access beyond end of origin device due to a partial block"

* tag 'dm-3.14-fixes-4' of git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm:
  dm cache: fix access beyond end of origin device
  dm cache: fix truncation bug when copying a block to/from >2TB fast device

For systems with multiple servers and routed fabric, all
northbridges get assigned to the first server. Fix this by also
using the node reported from the PCI bus. For single-fabric
systems, the northbriges are on PCI bus 0 by definition, which
are on NUMA node 0 by definition, so this is invarient on most
systems.

Tested on fam10h and fam15h single and multi-fabric systems and
candidate for stable.
Signed-off-by: NDaniel J Blueman <daniel@numascale.com>
Acked-by: NSteffen Persvold <sp@numascale.com>
Acked-by: NBorislav Petkov <bp@suse.de>
Cc: <stable@vger.kernel.org>
Link: http://lkml.kernel.org/r/1394710981-3596-1-git-send-email-daniel@numascale.comSigned-off-by: NIngo Molnar <mingo@kernel.org>

Pull drm fixes from Dave Airlie:
 "Pretty minor set of fixes for radeon, ttm and vmwgfx.  The ttm ones
  are a regression and an oops seen on server chipsets"

* 'drm-fixes' of git://people.freedesktop.org/~airlied/linux:
  drm/vmwgfx: Fix a surface reference corner-case in legacy emulation mode
  drm/radeon/cik: properly set compute ring status on disable
  drm/radeon/cik: stop the sdma engines in the enable() function
  drm/radeon/cik: properly set sdma ring status on disable
  drm/radeon: fix runpm disabling on non-PX harder
  drm/ttm: don't oops if no invalidate_caches()
  drm/ttm: Work around performance regression with VM_PFNMAP

Pull i2c Kconfig fix from Wolfram Sang.

* 'i2c/for-current' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux:
  i2c: Remove usage of orphaned symbol OF_I2C

Pull networking fixes from David Miller:
 "I know this is a bit more than you want to see, and I've told the
  wireless folks under no uncertain terms that they must severely scale
  back the extent of the fixes they are submitting this late in the
  game.

  Anyways:

   1) vmxnet3's netpoll doesn't perform the equivalent of an ISR, which
      is the correct implementation, like it should.  Instead it does
      something like a NAPI poll operation.  This leads to crashes.

      From Neil Horman and Arnd Bergmann.

   2) Segmentation of SKBs requires proper socket orphaning of the
      fragments, otherwise we might access stale state released by the
      release callbacks.

      This is a 5 patch fix, but the initial patches are giving
      variables and such significantly clearer names such that the
      actual fix itself at the end looks trivial.

      From Michael S.  Tsirkin.

   3) TCP control block release can deadlock if invoked from a timer on
      an already "owned" socket.  Fix from Eric Dumazet.

   4) In the bridge multicast code, we must validate that the
      destination address of general queries is the link local all-nodes
      multicast address.  From Linus Lüssing.

   5) The x86 BPF JIT support for negative offsets puts the parameter
      for the helper function call in the wrong register.  Fix from
      Alexei Starovoitov.

   6) The descriptor type used for RTL_GIGA_MAC_VER_17 chips in the
      r8169 driver is incorrect.  Fix from Hayes Wang.

   7) The xen-netback driver tests skb_shinfo(skb)->gso_type bits to see
      if a packet is a GSO frame, but that's not the correct test.  It
      should use skb_is_gso(skb) instead.  Fix from Wei Liu.

   8) Negative msg->msg_namelen values should generate an error, from
      Matthew Leach.

   9) at86rf230 can deadlock because it takes the same lock from it's
      ISR and it's hard_start_xmit method, without disabling interrupts
      in the latter.  Fix from Alexander Aring.

  10) The FEC driver's restart doesn't perform operations in the correct
      order, so promiscuous settings can get lost.  Fix from Stefan
      Wahren.

  11) Fix SKB leak in SCTP cookie handling, from Daniel Borkmann.

  12) Reference count and memory leak fixes in TIPC from Ying Xue and
      Erik Hugne.

  13) Forced eviction in inet_frag_evictor() must strictly make sure all
      frags are deleted, otherwise module unload (f.e.  6lowpan) can
      crash.  Fix from Florian Westphal.

  14) Remove assumptions in AF_UNIX's use of csum_partial() (which it
      uses as a hash function), which breaks on PowerPC.  From Anton
      Blanchard.

      The main gist of the issue is that csum_partial() is defined only
      as a value that, once folded (f.e.  via csum_fold()) produces a
      correct 16-bit checksum.  It is legitimate, therefore, for
      csum_partial() to produce two different 32-bit values over the
      same data if their respective alignments are different.

  15) Fix endiannes bug in MAC address handling of ibmveth driver, also
      from Anton Blanchard.

  16) Error checks for ipv6 exthdrs offload registration are reversed,
      from Anton Nayshtut.

  17) Externally triggered ipv6 addrconf routes should count against the
      garbage collection threshold.  Fix from Sabrina Dubroca.

  18) The PCI shutdown handler added to the bnx2 driver can wedge the
      chip if it was not brought up earlier already, which in particular
      causes the firmware to shut down the PHY.  Fix from Michael Chan.

  19) Adjust the sanity WARN_ON_ONCE() in qdisc_list_add() because as
      currently coded it can and does trigger in legitimate situations.
      From Eric Dumazet.

  20) BNA driver fails to build on ARM because of a too large udelay()
      call, fix from Ben Hutchings.

  21) Fair-Queue qdisc holds locks during GFP_KERNEL allocations, fix
      from Eric Dumazet.

  22) The vlan passthrough ops added in the previous release causes a
      regression in source MAC address setting of outgoing headers in
      some circumstances.  Fix from Peter Boström"

* git://git.kernel.org/pub/scm/linux/kernel/git/davem/net: (70 commits)
  ipv6: Avoid unnecessary temporary addresses being generated
  eth: fec: Fix lost promiscuous mode after reconnecting cable
  bonding: set correct vlan id for alb xmit path
  at86rf230: fix lockdep splats
  net/mlx4_en: Deregister multicast vxlan steering rules when going down
  vmxnet3: fix building without CONFIG_PCI_MSI
  MAINTAINERS: add networking selftests to NETWORKING
  net: socket: error on a negative msg_namelen
  MAINTAINERS: Add tools/net to NETWORKING [GENERAL]
  packet: doc: Spelling s/than/that/
  net/mlx4_core: Load the IB driver when the device supports IBoE
  net/mlx4_en: Handle vxlan steering rules for mac address changes
  net/mlx4_core: Fix wrong dump of the vxlan offloads device capability
  xen-netback: use skb_is_gso in xenvif_start_xmit
  r8169: fix the incorrect tx descriptor version
  tools/net/Makefile: Define PACKAGE to fix build problems
  x86: bpf_jit: support negative offsets
  bridge: multicast: enable snooping on general queries only
  bridge: multicast: add sanity check for general query destination
  tcp: tcp_release_cb() should release socket ownership
  ...

The symbol is an orphan, don't depend on it anymore.
Signed-off-by: NRichard Weinberger <richard@nod.at>
[wsa: enhanced commit message]
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
Fixes: 687b81d0 (i2c: move OF helpers into the core)
Cc: stable@kernel.org

* pnp:
  PNP / ACPI: proper handling of ACPI IO/Memory resource parsing failures

* acpi-init:
  ACPI / init: Invoke early ACPI initialization later

* acpi-sleep:
  ACPI / sleep: Add extra checks for HW Reduced ACPI mode sleep states

* pm-cpufreq:
  cpufreq: Skip current frequency initialization for ->setpolicy drivers

If the HW Reduced ACPI mode bit is set in the FADT, ACPICA uses
the optional sleep control and sleep status registers for making
the system enter sleep states (including S5), so it is not possible
to use system sleep states or power it off using ACPI if the HW
Reduced ACPI mode bit is set and those registers are not available.

For this reason, add a new function, acpi_sleep_state_supported(),
checking if the HW Reduced ACPI mode bit is set and whether or not
system sleep states are usable in that case in addition to checking
the return value of acpi_get_sleep_type_data() and make the ACPI
sleep setup routines use that function to check the availability of
system sleep states.

Among other things, this prevents the kernel from attempting to
use ACPI for powering off HW Reduced ACPI systems without the sleep
control and sleep status registers, because ACPI power off doesn't
have a chance to work on them.  That allows alternative power off
mechanisms that may actually work to be used on those systems.  The
affected machines include Dell Venue 8 Pro, Asus T100TA, Haswell
Desktop SDP and Ivy Bridge EP Demo depot.

References: https://bugzilla.kernel.org/show_bug.cgi?id=70931Reported-by: NAdam Williamson <awilliam@redhat.com>
Tested-by: NAubrey Li <aubrey.li@linux.intel.com>
Cc: 3.4+ <stable@vger.kernel.org> # 3.4+
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

tmp_prefered_lft is an offset to ifp->tstamp, not now. Therefore
age needs to be added to the condition.

Age calculation in ipv6_create_tempaddr is different from the one
in addrconf_verify and doesn't consider ADDRCONF_TIMER_FUZZ_MINUS.
This can cause age in ipv6_create_tempaddr to be less than the one
in addrconf_verify and therefore unnecessary temporary address to
be generated.
Use age calculation as in addrconf_modify to avoid this.
Signed-off-by: NHeiner Kallweit <heiner.kallweit@web.de>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

If the Freescale fec is in promiscuous mode and network cable is
reconnected then the promiscuous mode get lost. The problem is caused
by a too soon call of set_multicast_list to re-enable promisc mode.
The FEC_R_CNTRL register changes are overwritten by fec_restart.

This patch fixes this by moving the call behind the init of FEC_R_CNTRL
register in fec_restart.

Successful tested on a i.MX28 board.
Signed-off-by: NStefan Wahren <stefan.wahren@i2se.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The commit d3ab3ffd
(bonding: use rlb_client_info->vlan_id instead of ->tag)
remove the rlb_client_info->tag, but occur some issues,
The vlan_get_tag() will return 0 for success and -EINVAL for
error, so the client_info->vlan_id always be set to 0 if the
vlan_get_tag return 0 for success, so the client_info would
never get a correct vlan id.

We should only set the vlan id to 0 when the vlan_get_tag return error.

Fixes: d3ab3ffd (bonding: use rlb_client_info->vlan_id instead of ->tag)

CC: Ding Tianhong <dingtianhong@huawei.com>
CC: Jay Vosburgh <fubar@us.ibm.com>
CC: Andy Gospodarek <andy@greyhouse.net>
Signed-off-by: NDing Tianhong <dingtianhong@huawei.com>
Acked-by: NVeaceslav Falico <vfalico@redhat.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This patch fix a lockdep in the at86rf230 driver, otherwise we get:

[   30.206517] =================================
[   30.211078] [ INFO: inconsistent lock state ]
[   30.215647] 3.14.0-20140108-1-00994-g32e9426 #163 Not tainted
[   30.221660] ---------------------------------
[   30.226222] inconsistent {HARDIRQ-ON-W} -> {IN-HARDIRQ-W} usage.
[   30.232514] systemd-udevd/157 [HC1[1]:SC0[0]:HE0:SE1] takes:
[   30.238439]  (&(&lp->lock)->rlock){?.+...}, at: [<c03600f8>] at86rf230_isr+0x18/0x44
[   30.246621] {HARDIRQ-ON-W} state was registered at:
[   30.251728]   [<c0061ce4>] __lock_acquire+0x7a4/0x18d8
[   30.257135]   [<c0063500>] lock_acquire+0x68/0x7c
[   30.262071]   [<c0588820>] _raw_spin_lock+0x28/0x38
[   30.267203]   [<c0361240>] at86rf230_xmit+0x1c/0x144
[   30.272412]   [<c057ba6c>] mac802154_xmit_worker+0x88/0x148
[   30.278271]   [<c0047844>] process_one_work+0x274/0x404
[   30.283761]   [<c00484c0>] worker_thread+0x228/0x374
[   30.288971]   [<c004cfb8>] kthread+0xd0/0xe4
[   30.293455]   [<c000dac8>] ret_from_fork+0x14/0x2c
[   30.298493] irq event stamp: 8948
[   30.301963] hardirqs last  enabled at (8947): [<c00cb290>] __kmalloc+0xb4/0x110
[   30.309636] hardirqs last disabled at (8948): [<c00115d4>] __irq_svc+0x34/0x5c
[   30.317215] softirqs last  enabled at (8452): [<c0037324>] __do_softirq+0x1dc/0x264
[   30.325243] softirqs last disabled at (8439): [<c0037638>] irq_exit+0x80/0xf4

We use the lp->lock inside the isr of at86rf230, that's why we need the
irqsave spinlock calls.
Signed-off-by: NAlexander Aring <alex.aring@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

When mlx4_en_stop_port() is called, we need to deregister also the
tunnel steering rules that relate to multicast.
Signed-off-by: NOr Gerlitz <ogerlitz@mellanox.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Since commit d25f06ea "vmxnet3: fix netpoll race condition",
the vmxnet3 driver fails to build when CONFIG_PCI_MSI is disabled,
because it unconditionally references the vmxnet3_msix_rx()
function.

To fix this, use the same #ifdef in the caller that exists around
the function definition.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Cc: Neil Horman <nhorman@tuxdriver.com>
Cc: Shreyas Bhatewara <sbhatewara@vmware.com>
Cc: "VMware, Inc." <pv-drivers@vmware.com>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: stable@vger.kernel.org
Acked-by: NNeil Horman <nhorman@tuxdriver.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Add it to NETWORKING [GENERAL] to make sure patches for selftests
go to the netdev list as well.
Signed-off-by: NDaniel Borkmann <dborkman@redhat.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Second pull request of 2014-03-12. The first one was requested to be canceled.

Rob's fix for oops on invalidate_caches() and a fix for a
performance regression.

* tag 'ttm-fixes-3.14-2014-03-12' of git://people.freedesktop.org/~thomash/linux:
  drm/ttm: don't oops if no invalidate_caches()
  drm/ttm: Work around performance regression with VM_PFNMAP

A few more radeon fixes.

* 'drm-fixes-3.14' of git://people.freedesktop.org/~agd5f/linux:
  drm/radeon/cik: properly set compute ring status on disable
  drm/radeon/cik: stop the sdma engines in the enable() function
  drm/radeon/cik: properly set sdma ring status on disable
  drm/radeon: fix runpm disabling on non-PX harder

Merge tag 'vmwgfx-fixes-3.14-2014-03-13' of git://people.freedesktop.org/~thomash/linux into drm-fixes

Pull request of 2014-03-13

one minor fix for new hw

* tag 'vmwgfx-fixes-3.14-2014-03-13' of git://people.freedesktop.org/~thomash/linux:
  drm/vmwgfx: Fix a surface reference corner-case in legacy emulation mode

If running on a gb-object capable device with a non-gb capable surface
exporter (X server) and a gb capable surface referencing client (GL driver),
the referencing client expects to find a shareable backing buffer attached to
the surface at reference time. This may not be the case if the surface has
not yet been validated. This would cause the surface reference IOCTL to
return an error.
Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: NJakob Bornecrantz <jakob@vmware.com>

Pull PCI fixes from Bjorn Helgaas:
 "These are two important regression fixes for bugs we've introduced so
  far in v3.14.

  One of the resource allocation changes from the merge window is broken
  for 32-bit kernels where we don't use _CRS for PCI host bridges
  (mostly pre-2008 machines), so there's a fix for that.

  The INTx enable change we put in after the merge window turned out to
  break pciehp because we re-enable INTx on the hotplug bridge, which
  apparently breaks MSI for future hotplug events"

* tag 'pci-v3.14-fixes-2' of git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci:
  PCI: Don't check resource_size() in pci_bus_alloc_resource()
  PCI: Enable INTx in pci_reenable_device() only when MSI/MSI-X not enabled