Consistently check errors using the usual method used in the kernel
for much of its history.  For instance:

int gpmc_cs_set_timings(int cs, const struct gpmc_timings *t)
{
	int div;
	div = gpmc_calc_divider(t->sync_clk);
	if (div < 0)
		return div;
static int gpmc_set_async_mode(int cs, struct gpmc_timings *t)
{
...
	return gpmc_cs_set_timings(cs, t);

.....
	ret = gpmc_set_async_mode(gpmc_onenand_data->cs, &t);
	if (IS_ERR_VALUE(ret))
		return ret;

So, gpmc_cs_set_timings() thinks any negative return value is an error,
but where we check that in higher levels, only a limited range are
errors...

There is only _one_ use of IS_ERR_VALUE() in arch/arm which is really
appropriate, and that is in arch/arm/include/asm/syscall.h:

static inline long syscall_get_error(struct task_struct *task,
				     struct pt_regs *regs)
{
	unsigned long error = regs->ARM_r0;
	return IS_ERR_VALUE(error) ? error : 0;
}

because this function really does have to differentiate between error
return values and addresses which look like negative numbers (eg, from
mmap()).

So, here's a patch to remove them from OMAP, except for the above.
Acked-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

omap_hwmod_lookup() only returns NULL on error, never an error pointer.
Checking the returned pointer using IS_ERR_OR_NULL() is needless
overhead.  Use a simple !ptr check instead.

OMAP devices (oh->od) always have a valid platform device attached (see
omap_device_alloc()) so there's no point validating the platform device
pointer (we will have already oopsed long before if this is not the
case here.)

Lastly, oh->od is only ever NULL or a valid omap device pointer - 'oh'
comes from the statically declared hwmod tables, and the pointer is
only filled in by omap_device_alloc() at a point where the omap device
pointer must be valid.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

pwrdm_can_ever_lose_context() is only ever called from the OMAP GPIO
code, and only with a pointer returned from omap_hwmod_get_pwrdm().
omap_hwmod_get_pwrdm() only ever returns NULL on error, so using
IS_ERR_OR_NULL() to validate the passed pointer is silly.  Use a
simpler !ptr check instead.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

Debugfs functions return NULL when they fail, or an error pointer
when not configured.  The intention behind the error pointer is that
it appears as a valid pointer to the caller, and so the caller
continues inspite of debugfs not being available.

Debugfs failure should only ever be checked with (!ptr) and not the
IS_ERR*() functions.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

Fix clk_get_sys() error handling; IS_ERR() should be used rather than
IS_ERR_OR_NULL() to check for errors.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

regulator_get() does not return NULL as an error value.  Even when it
does return an error, the code as written falls out the error path
while returning zero (indicating no failure.)  Fix this, and use the
more correct IS_ERR() macro to check for errors.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

Use the correct IS_ERR() to determine if clk_get() returned an error.
Set timer->fclk to be an error value initially, and check everywhere
using IS_ERR().  This keeps the range of valid values for 'struct clk'
consistent.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

soc_device_register() never returns NULL, it only ever returns an
error pointer or a valid pointer.  Use the right function (IS_ERR())
to check this.

soc_device_to_device() only ever returns &soc_dev->dev, and so can
never return an error or NULL if the pointer passed into it was
valid, so there's no point checking its return.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

Three's no need to have code initializing this by hand; it's more
efficient to initialize the constant structure members directly.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

We don't need to keep reloading the thread into into r10 - we can do
this once and keep the value cached in the register.  Also, schedule
some instructions better so that the pipeline doesn't stall after a
load in the neon code.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

Pull input subsystem fixes from Dmitry Torokhov:
 "Two small driver fixups and a documentation update for managed input
  devices"

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input:
  Input: wacom - fix wacom_set_report retry logic
  Input: document that unregistering managed devices is not necessary
  Input: lm8323 - fix checking PWM interrupt status

Commit c060f943 ("mm: use aligned zone start for pfn_to_bitidx
calculation") fixed out calculation of the index into the pageblock
bitmap when a !SPARSEMEM zome was not aligned to pageblock_nr_pages.

However, the _allocation_ of that bitmap had never taken this alignment
requirement into accout, so depending on the exact size and alignment of
the zone, the use of that index could then access past the allocation,
resulting in some very subtle memory corruption.

This was reported (and bisected) by Ingo Molnar: one of his random
config builds would hang with certain very specific kernel command line
options.

In the meantime, commit c060f943 has been marked for stable, so this
fix needs to be back-ported to the stable kernels that backported the
commit to use the right alignment.
Bisected-and-tested-by: Ingo Molnar <mingo@kernel.org>
Acked-by: Mel Gorman <mgorman@suse.de>
Cc: stable@kernel.org
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

Merge tag 'stable/for-linus-3.8-rc7-tag-two' of git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen

Pull xen fixes from Konrad Rzeszutek Wilk:
 "Two fixes:

   - A simple bug-fix for redundant NULL check.

   - CVE-2013-0228/XSA-42: x86/xen: don't assume %ds is usable in
     xen_iret for 32-bit PVOPS

  and two reverts:

   - Revert the PVonHVM kexec.  The patch introduces a regression with
     older hypervisor stacks, such as Xen 4.1."

* tag 'stable/for-linus-3.8-rc7-tag-two' of git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen:
  Revert "xen PVonHVM: use E820_Reserved area for shared_info"
  Revert "xen/PVonHVM: fix compile warning in init_hvm_pv_info"
  xen: remove redundant NULL check before unregister_and_remove_pcpu().
  x86/xen: don't assume %ds is usable in xen_iret for 32-bit PVOPS.

As reported by Klaus Schmidinger:
 "In VDR I use an ioctl() call with FE_READ_UNCORRECTED_BLOCKS on a
  device (using stb0899).  After this call I check 'errno' for
  EOPNOTSUPP to determine whether this device supports this call.  This
  used to work just fine, until a few months ago I noticed that my
  devices using stb0899 didn't display their signal quality in VDR's OSD
  any more.  After further investigation I found that
  ioctl(FE_READ_UNCORRECTED_BLOCKS) no longer returns EOPNOTSUPP, but
  rather ENOTTY.  And since I stop getting the signal quality in case
  any unknown errno value appears, this broke my signal quality query
  function."

While the changes reflect what is there at:

  http://comments.gmane.org/gmane.linux.kernel/1235728

it does cause regression on userspace.  So, revert it to stop the
damage.

This reverts commit 177ffe50 ("[media] dvb_frontend: return -ENOTTY
for unimplement IOCTL").
Reported-by: Klaus Schmidinger <Klaus.Schmidinger@tvdr.de>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

Pull sparc fixes from David Miller:
 "A couple small fixes for sparc including some THP brown-paper-bag
  material:

   1) During the merging of all the THP support for various
      architectures, sparc missed adding a
      HAVE_ARCH_TRANSPARENT_HUGEPAGE to it's Kconfig, oops.

   2) Sparc needs to be mindful of hugepages in get_user_pages_fast().

   3) Fix memory leak in SBUS probe, from Cong Ding.

   4) The sunvdc virtual disk client driver has a test of the bitmask of
      vdisk server supported operations which was off by one bit"

* git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc:
  sunvdc: Fix off-by-one in generic_request().
  sparc64: Fix get_user_pages_fast() wrt. THP.
  sparc64: Add missing HAVE_ARCH_TRANSPARENT_HUGEPAGE.
  sparc: kernel/sbus.c: fix memory leakage

Pull one more x86 fix from Peter Anvin:
 "Sigh.  One more patch in the "please don't brick my Samsung" series"

* 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  efi: Clear EFI_RUNTIME_SERVICES rather than EFI_BOOT by "noefi" boot parameter

Pull PCI fix from Bjorn Helgaas:
 "This is another fix for v3.8.  It fixes an oops that happens when a
  Thunderbolt adapter is unplugged (remove device, poll for PME events
  on no-longer-existing device, oops)."

* tag '3.8-pci-fixes-3' of git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci:
  PCI/PM: Clean up PME state when removing a device

Pull omapdss fixes from Tomi Valkeinen:
 "It'd be great if these two late fixes would still make it into 3.8.
  The other one fixes ARM kernel compilation when using 'allyesconfig',
  and the other makes DPI displays function again on OMAP3630 boards:

   - Fix ARM compilation with "allyesconfig" (omapdrm: fix the
     dependency to omapdss)

   - fix DPI displays on OMAP3630 (OMAPDSS: add FEAT_DPI_USES_VDDS_DSI
     to omap3630_dss_feat_list)"

* tag 'omapdss-for-3.8-rc8' of git://gitorious.org/linux-omap-dss2/linux:
  omapdrm: fix the dependency to omapdss
  OMAPDSS: add FEAT_DPI_USES_VDDS_DSI to omap3630_dss_feat_list

Pull i2c maintainer info update from Wolfram Sang:
 "Since my old email and repos are not working anymore, and this already
  caused some confusion, I think a MAINTAINERS update for 3.8 is
  helpful.  So, people trying I2C with the new kernel can properly reach
  me and find my repos."

* 'i2c/for-current' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux:
  MAINTAINERS: change my email and repos

This reverts commit 9d02b43d.

We are doing this b/c on 32-bit PVonHVM with older hypervisors
(Xen 4.1) it ends up bothing up the start_info. This is bad b/c
we use it for the time keeping, and the timekeeping code loops
forever - as the version field never changes. Olaf says to
revert it, so lets do that.
Acked-by: Olaf Hering <olaf@aepfle.de>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

This reverts commit a7be94ac.
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

The 'operations' bitmap corresponds one-for-one with the operation
codes, no adjustment is necessary.
Reported-by: Mark Kettenis <mark.kettenis@xs4all.nl>
Signed-off-by: David S. Miller <davem@davemloft.net>

omapdrm uses "select" in Kconfig to enable omapdss. This doesn't work
correctly, as "select" forces omapdss to be enabled in the config even
if it normally could not be enabled because of missing Kconfig
dependencies.

This causes a build break on ARM, when using allyesconfig:

drivers/video/omap2/dss/dss.c: In function 'dss_calc_clock_div':
drivers/video/omap2/dss/dss.c:572:20: error: 'CONFIG_OMAP2_DSS_MIN_FCK_PER_PCK' undeclared (first use in this function)
drivers/video/omap2/dss/dss.c:572:20: note: each undeclared identifier is reported only once for each function it appears in

Instead of using select, this patch changes omapdrm to use "depend
on".
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>

commit 195e672a
   OMAPDSS: DPI: Remove cpu_is_xxxx checks

made the mistake of assuming that cpu_is_omap34xx() is exclusive of
other cpu_is_* predicates whereas it includes cpu_is_omap3630().

So on an omap3630, code that was previously enabled by
  if (cpu_is_omap34xx())
is now disabled as
  dss_has_feature(FEAT_DPI_USES_VDDS_DSI)
fails.

So add FEAT_DPI_USES_VDDS_DSI to omap3630_dss_feat_list.

Cc: Chandrabhanu Mahapatra <cmahapatra@ti.com>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>

There was a serious problem in samsung-laptop that its platform driver is
designed to run under BIOS and running under EFI can cause the machine to
become bricked or can cause Machine Check Exceptions.

    Discussion about this problem:
    https://bugs.launchpad.net/ubuntu-cdimage/+bug/1040557
    https://bugzilla.kernel.org/show_bug.cgi?id=47121

    The patches to fix this problem:
    efi: Make 'efi_enabled' a function to query EFI facilities
    83e68189

    samsung-laptop: Disable on EFI hardware
    e0094244

Unfortunately this problem comes back again if users specify "noefi" option.
This parameter clears EFI_BOOT and that driver continues to run even if running
under EFI. Refer to the document, this parameter should clear
EFI_RUNTIME_SERVICES instead.

Documentation/kernel-parameters.txt:
===============================================================================
...
	noefi		[X86] Disable EFI runtime services support.
...
===============================================================================

Documentation/x86/x86_64/uefi.txt:
===============================================================================
...
- If some or all EFI runtime services don't work, you can try following
  kernel command line parameters to turn off some or all EFI runtime
  services.
	noefi		turn off all EFI runtime services
...
===============================================================================
Signed-off-by: Satoru Takeuchi <takeuchi_satoru@jp.fujitsu.com>
Link: http://lkml.kernel.org/r/511C2C04.2070108@jp.fujitsu.com
Cc: Matt Fleming <matt.fleming@intel.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>

unregister_and_remove_pcpu on a NULL pointer is a no-op, so the NULL check in
sync_pcpu can be removed.
Signed-off-by: Cyril Roelandt <tipecaml@gmail.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

This fixes CVE-2013-0228 / XSA-42

Drew Jones while working on CVE-2013-0190 found that that unprivileged guest user
in 32bit PV guest can use to crash the > guest with the panic like this:

-------------
general protection fault: 0000 [#1] SMP
last sysfs file: /sys/devices/vbd-51712/block/xvda/dev
Modules linked in: sunrpc ipt_REJECT nf_conntrack_ipv4 nf_defrag_ipv4
iptable_filter ip_tables ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6
xt_state nf_conntrack ip6table_filter ip6_tables ipv6 xen_netfront ext4
mbcache jbd2 xen_blkfront dm_mirror dm_region_hash dm_log dm_mod [last
unloaded: scsi_wait_scan]

Pid: 1250, comm: r Not tainted 2.6.32-356.el6.i686 #1
EIP: 0061:[<c0407462>] EFLAGS: 00010086 CPU: 0
EIP is at xen_iret+0x12/0x2b
EAX: eb8d0000 EBX: 00000001 ECX: 08049860 EDX: 00000010
ESI: 00000000 EDI: 003d0f00 EBP: b77f8388 ESP: eb8d1fe0
 DS: 0000 ES: 007b FS: 0000 GS: 00e0 SS: 0069
Process r (pid: 1250, ti=eb8d0000 task=c2953550 task.ti=eb8d0000)
Stack:
 00000000 0027f416 00000073 00000206 b77f8364 0000007b 00000000 00000000
Call Trace:
Code: c3 8b 44 24 18 81 4c 24 38 00 02 00 00 8d 64 24 30 e9 03 00 00 00
8d 76 00 f7 44 24 08 00 00 02 80 75 33 50 b8 00 e0 ff ff 21 e0 <8b> 40
10 8b 04 85 a0 f6 ab c0 8b 80 0c b0 b3 c0 f6 44 24 0d 02
EIP: [<c0407462>] xen_iret+0x12/0x2b SS:ESP 0069:eb8d1fe0
general protection fault: 0000 [#2]
---[ end trace ab0d29a492dcd330 ]---
Kernel panic - not syncing: Fatal exception
Pid: 1250, comm: r Tainted: G      D    ---------------
2.6.32-356.el6.i686 #1
Call Trace:
 [<c08476df>] ? panic+0x6e/0x122
 [<c084b63c>] ? oops_end+0xbc/0xd0
 [<c084b260>] ? do_general_protection+0x0/0x210
 [<c084a9b7>] ? error_code+0x73/
-------------

Petr says: "
 I've analysed the bug and I think that xen_iret() cannot cope with
 mangled DS, in this case zeroed out (null selector/descriptor) by either
 xen_failsafe_callback() or RESTORE_REGS because the corresponding LDT
 entry was invalidated by the reproducer. "

Jan took a look at the preliminary patch and came up a fix that solves
this problem:

"This code gets called after all registers other than those handled by
IRET got already restored, hence a null selector in %ds or a non-null
one that got loaded from a code or read-only data descriptor would
cause a kernel mode fault (with the potential of crashing the kernel
as a whole, if panic_on_oops is set)."

The way to fix this is to realize that the we can only relay on the
registers that IRET restores. The two that are guaranteed are the
%cs and %ss as they are always fixed GDT selectors. Also they are
inaccessible from user mode - so they cannot be altered. This is
the approach taken in this patch.

Another alternative option suggested by Jan would be to relay on
the subtle realization that using the %ebp or %esp relative references uses
the %ss segment.  In which case we could switch from using %eax to %ebp and
would not need the %ss over-rides. That would also require one extra
instruction to compensate for the one place where the register is used
as scaled index. However Andrew pointed out that is too subtle and if
further work was to be done in this code-path it could escape folks attention
and lead to accidents.
Reviewed-by: Petr Matousek <pmatouse@redhat.com>
Reported-by: Petr Matousek <pmatouse@redhat.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

Mostly mirrors the s390 logic, as unlike x86 we don't need the
SetPageReferenced() bits.

On sparc64 we also lack a user/privileged bit in the huge PMDs.

In order to make this work for THP and non-THP builds, some header
file adjustments were necessary.  Namely, provide the PMD_HUGE_* bit
defines and the pmd_large() inline unconditionally rather than
protected by TRANSPARENT_HUGEPAGE.
Reported-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

This got missed in the cleanups done for the S390 THP
support.

CC: Gerald Schaefer <gerald.schaefer@de.ibm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

Pull networking fixes from David Miller:
 "This is primarily to get those r8169 reverts sorted, but other fixes
  have accumulated meanwhile.

   1) Revert two r8169 changes to fix suspend/resume for some users,
      from Francois Romieu.

   2) PCI dma mapping errors in atl1c are not checked for and this cause
      hard crashes for some users, from Xiong Huang.

   3) In 3.8.x we merged the removal of the EXPERIMENTAL dependency for
      'dlm' but the same patch for 'sctp' got lost somewhere, resulting
      in the potential for build errors since there are cross
      dependencies.  From Kees Cook.

   4) SCTP's ipv6 socket route validation makes boolean tests
      incorrectly, fix from Daniel Borkmann.

   5) mac80211 does sizeof(ptr) instead of (sizeof(ptr) * nelem), from
      Cong Ding.

   6) arp_rcv() can crash on shared non-linear packets, from Eric
      Dumazet.

   7) Avoid crashes in macvtap by setting ->gso_type consistently in
      ixgbe, qlcnic, and bnx2x drivers.  From Michael S Tsirkin and
      Alexander Duyck.

   8) Trinity fuzzer spots infinite loop in __skb_recv_datagram(), fix
      from Eric Dumazet.

   9) STP protocol frames should use high packet priority, otherwise an
      overloaded bridge can get stuck.  From Stephen Hemminger.

  10) The HTB packet scheduler was converted some time ago to store
      internal timestamps in nanoseconds, but we don't convert back into
      psched ticks for the user during dumps.  Fix from Jiri Pirko.

  11) mwl8k channel table doesn't set the .band field properly,
      resulting in NULL pointer derefs.  Fix from Jonas Gorski.

  12) mac80211 doesn't accumulate channels properly during a scan so we
      can downgrade heavily to a much less desirable connection speed.
      Fix from Johannes Berg.

  13) PHY probe failure in stmmac can result in resource leaks and
      double MDIO registery later, from Giuseppe CAVALLARO.

  14) Correct ipv6 checksumming in ip6t_NPT netfilter module, also fix
      address prefix mangling, from YOSHIFUJI Hideaki."

* git://git.kernel.org/pub/scm/linux/kernel/git/davem/net: (27 commits)
  net, sctp: remove CONFIG_EXPERIMENTAL
  net: sctp: sctp_v6_get_dst: fix boolean test in dst cache
  batman-adv: Fix NULL pointer dereference in DAT hash collision avoidance
  net/macb: fix race with RX interrupt while doing NAPI
  atl1c: add error checking for pci_map_single functions
  htb: fix values in opt dump
  ixgbe: Only set gso_type to SKB_GSO_TCPV4 as RSC does not support IPv6
  net: fix infinite loop in __skb_recv_datagram()
  net: qmi_wwan: add Yota / Megafon M100-1 4g modem
  mwl8k: fix band for supported channels
  bridge: set priority of STP packets
  mac80211: fix channel selection bug
  arp: fix possible crash in arp_rcv()
  bnx2x: set gso_type
  qlcnic: set gso_type
  ixgbe: fix gso type
  stmmac: mdio register has to fail if the phy is not found
  stmmac: fix macro used for debugging the xmit
  Revert "r8169: enable internal ASPM and clock request settings".
  Revert "r8169: enable ALDPS for power saving".
  ...

Pull x86 fixes from Peter Anvin:
 "One (hopefully) last batch of x86 fixes.  You asked for the patch by
  patch justifications, so here they are:

      x86, MCE: Retract most UAPI exports

   This one unexports from userspace a bunch of definitions which should
   never have been exported.  We really don't want to create an
   accidental legacy here.

      x86, doc: Add a bootloader ID for OVMF

   This is a documentation-only patch, just recording the official
   assignment of a boot loader ID.

      x86: Do not leak kernel page mapping locations

   Security: avoid making it needlessly easy for user space to probe the
   kernel memory layout.

      x86/mm: Check if PUD is large when validating a kernel address

   Prevent failures using /proc/kcore when using 1G pages.

      x86/apic: Work around boot failure on HP ProLiant DL980 G7 Server systems

   Works around a BIOS problem causing boot failures on affected hardware."

* 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  x86/mm: Check if PUD is large when validating a kernel address
  x86/apic: Work around boot failure on HP ProLiant DL980 G7 Server systems
  x86, doc: Add a bootloader ID for OVMF
  x86: Do not leak kernel page mapping locations
  x86, MCE: Retract most UAPI exports

Change to my private email, change to my shiny new kernel.org repos,
and drop outdated entry from the former maintainer. Drop my PCA entry,
too, since it belongs to the I2C realm anyhow.
Signed-off-by: Wolfram Sang <wolfram@the-dreams.de>

Devices are added to pci_pme_list when drivers use pci_enable_wake()
or pci_wake_from_d3(), but they aren't removed from the list unless
the driver explicitly disables wakeup.  Many drivers never disable
wakeup, so their devices remain on the list even after they are
removed, e.g., via hotplug.  A subsequent PME poll will oops when
it tries to touch the device.

This patch disables PME# on a device before removing it, which removes
the device from pci_pme_list.  This is safe even if the device never
had PME# enabled.

This oops can be triggered by unplugging a Thunderbolt ethernet adapter
on a Macbook Pro, as reported by Daniel below.

[bhelgaas: changelog]
Reference: http://lkml.kernel.org/r/CAMVG2svG21yiM1wkH4_2pen2n+cr2-Zv7TbH3Gj+8MwevZjDbw@mail.gmail.comReported-and-tested-by: Daniel J Blueman <daniel@quora.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
CC: stable@vger.kernel.org

This config item has not carried much meaning for a while now and is
almost always enabled by default. As agreed during the Linux kernel
summit, remove it.
Acked-by: Vlad Yasevich <vyasevich@gmail.com>
Acked-by: Steven Whitehouse <swhiteho@redhat.com>
Signed-off-by: Kees Cook <keescook@chromium.org>
Signed-off-by: David Rientjes <rientjes@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

We walk through the bind address list and try to get the best source
address for a given destination. However, currently, we take the
'continue' path of the loop when an entry is invalid (!laddr->valid)
*and* the entry state does not equal SCTP_ADDR_SRC (laddr->state !=
SCTP_ADDR_SRC).

Thus, still, invalid entries with SCTP_ADDR_SRC might not 'continue'
as well as valid entries with SCTP_ADDR_{NEW, SRC, DEL}, with a possible
false baddr and matchlen as a result, causing in worst case dst route
to be false or possibly NULL.

This test should actually be a '||' instead of '&&'. But lets fix it
and make this a bit easier to read by having the condition the same way
as similarly done in sctp_v4_get_dst.
Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
Acked-by: Vlad Yasevich <vyasevich@gmail.com>
Acked-by: Neil Horman <nhorman@tuxdriver.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

An entry in DAT with the hashed position of 0 can cause a NULL pointer
dereference when the first entry is checked by batadv_choose_next_candidate.
This first candidate automatically has the max value of 0 and the max_orig_node
of NULL. Not checking max_orig_node for NULL in batadv_is_orig_node_eligible
will lead to a NULL pointer dereference when checking for the lowest address.

This problem was added in 785ea114
("batman-adv: Distributed ARP Table - create DHT helper functions").
Signed-off-by: Pau Koning <paukoning@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

When interrupts are disabled, an RX condition can occur but
it is not reported when enabling interrupts again. We need to check
RSR and use napi_reschedule() if condition is met.
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

it is reported that code hit DMA-API errors on 3.8-rc6+,
(see https://bugzilla.redhat.com/show_bug.cgi?id=908436, and
     https://bugzilla.redhat.com/show_bug.cgi?id=908550)

this patch just adds error handler for
    pci_map_single and skb_frag_dma_map.
Signed-off-by: xiong <xiong@qca.qualcomm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

A user reported the following oops when a backup process reads
/proc/kcore:

 BUG: unable to handle kernel paging request at ffffbb00ff33b000
 IP: [<ffffffff8103157e>] kern_addr_valid+0xbe/0x110
 [...]

 Call Trace:
  [<ffffffff811b8aaa>] read_kcore+0x17a/0x370
  [<ffffffff811ad847>] proc_reg_read+0x77/0xc0
  [<ffffffff81151687>] vfs_read+0xc7/0x130
  [<ffffffff811517f3>] sys_read+0x53/0xa0
  [<ffffffff81449692>] system_call_fastpath+0x16/0x1b

Investigation determined that the bug triggered when reading
system RAM at the 4G mark. On this system, that was the first
address using 1G pages for the virt->phys direct mapping so the
PUD is pointing to a physical address, not a PMD page.

The problem is that the page table walker in kern_addr_valid() is
not checking pud_large() and treats the physical address as if
it was a PMD.  If it happens to look like pmd_none then it'll
silently fail, probably returning zeros instead of real data. If
the data happens to look like a present PMD though, it will be
walked resulting in the oops above.

This patch adds the necessary pud_large() check.

Unfortunately the problem was not readily reproducible and now
they are running the backup program without accessing
/proc/kcore so the patch has not been validated but I think it
makes sense.
Signed-off-by: Mel Gorman <mgorman@suse.de>
Reviewed-by: Rik van Riel <riel@redhat.coM>
Reviewed-by: Michal Hocko <mhocko@suse.cz>
Acked-by: Johannes Weiner <hannes@cmpxchg.org>
Cc: stable@vger.kernel.org
Cc: linux-mm@kvack.org
Link: http://lkml.kernel.org/r/20130211145236.GX21389@suse.deSigned-off-by: Ingo Molnar <mingo@kernel.org>