pandora-kernel.git
5 years agoOMAP3: allow to disable UART4
Grazvydas Ignotas [Tue, 5 Jul 2016 21:34:23 +0000 (00:34 +0300)]
OMAP3: allow to disable UART4

and disable on pandora so that resources are not wasted to manage it

5 years agoASoC: pandora: try to power down the DAC properly
Grazvydas Ignotas [Mon, 4 Jul 2016 23:57:40 +0000 (02:57 +0300)]
ASoC: pandora: try to power down the DAC properly

some nasty stuff, but without this, there is like 5-10mW loss

5 years agoOMAP3: PM: disable sys_clkreq signalling while audio is active
Grazvydas Ignotas [Mon, 4 Jul 2016 23:54:11 +0000 (02:54 +0300)]
OMAP3: PM: disable sys_clkreq signalling while audio is active

see comment in this commit itself

5 years agoASoC: twl4030: remove unused structure
Grazvydas Ignotas [Mon, 4 Jul 2016 23:52:27 +0000 (02:52 +0300)]
ASoC: twl4030: remove unused structure

5 years agoRevert "ASoC: twl4030: disable 256fs clock on shutdown"
Grazvydas Ignotas [Sun, 3 Jul 2016 19:44:59 +0000 (22:44 +0300)]
Revert "ASoC: twl4030: disable 256fs clock on shutdown"

This reverts commit 5ee6c9912674b66378fe9d9ed9561baf8025b740.

wrong thing to do because:
- disables clock if one stream ends even while another still runs
- stops the clock while DAC is still active - DAC always requires
  a clock while PD is high

5 years agoOMAP2+: id: avoid register read
Grazvydas Ignotas [Sat, 28 May 2016 21:23:56 +0000 (00:23 +0300)]
OMAP2+: id: avoid register read

omap_type is always known and nobody else is using this kernel.
The goal is to allow the compiler to remove some code in idle path.

5 years agoOMAP2: PM debug: always compile
Grazvydas Ignotas [Sat, 28 May 2016 21:20:50 +0000 (00:20 +0300)]
OMAP2: PM debug: always compile

The stats are always collected anyway, so make them accessible without
CONFIG_PM_DEBUG.

5 years agoOMAP3: PM: some OFF mode hacks
Grazvydas Ignotas [Thu, 26 May 2016 00:31:09 +0000 (03:31 +0300)]
OMAP3: PM: some OFF mode hacks

Set off mode by default where it works.
Allow to set off mode for everythng except core+per or just per.

5 years agoOMAP3: PM: fix io chain setup
Grazvydas Ignotas [Sat, 28 May 2016 21:29:16 +0000 (00:29 +0300)]
OMAP3: PM: fix io chain setup

seems like wrong register was read

5 years agoARM: OMAP3: hwmod data: set sw control flag on dss hwmods
Grazvydas Ignotas [Fri, 27 May 2016 23:48:17 +0000 (02:48 +0300)]
ARM: OMAP3: hwmod data: set sw control flag on dss hwmods

Without this hwmod's _setup() enables interface clock and leaves it on
forever supposedly for hw autoidle to manage. However this causes
clockdomain's reference counter to never return to zero and
omap3xxx_clkdm_clk_disable() never gets called to remove autoteps to
MPU, which means DSS ends up needlessly transitioning alog with the CPU.

This hack avoids such switching. It also makes context loss counter work
without need to call pwrdm_{pre,post}_transition on all power domains in
omap_sram_idle() as it's taken care by clkdm enable/disable.

Could not measure any power usage differences though.

5 years agoARM: OMAP3: hwmod data: some mainline backports
Grazvydas Ignotas [Fri, 27 May 2016 23:32:29 +0000 (02:32 +0300)]
ARM: OMAP3: hwmod data: some mainline backports

Mostly from 844a3b632b7, which had changes mixed with refactoring.
Note that it re-adds OCPIF_SWSUP_IDLE on venc, which was previously
removed by 1f5e6247ca99 - this is backported here too.

5 years agoARM: OMAP3: Fix external abort on 36xx waking from off mode idle
Dave Gerlach [Thu, 14 Apr 2016 01:49:48 +0000 (20:49 -0500)]
ARM: OMAP3: Fix external abort on 36xx waking from off mode idle

Depending on timing during the resume path from off mode on 36xx, we may
see external aborts. These seem to be caused by the following:

- OMAP3 Advisory 1.62 "MPU Cannot Exit from Standby" says we need to
  disable intc autoidle before WFI

- DM3730 Advisory 1.106 "MPU Leaves MSTANDBY State Before IDLEREQ of
  Interrupt Controller is Released" says we need to wait before
  accessing intc

omap3_intc_resume_idle restores the intc autoidle for all resume paths,
however in the resume path from off mode only it is also being restored
by omap_intc_restore_context before this call to omap3_intc_resume_idle
happens. The second restore of the intc autoidle in this path is what
appears to be causing the external abort so for the off mode resume path
let's rely on omap_intc_restore_context to restore intc autoidle, and
for all other paths let omap3_intc_resume_idle handle it as it is now.

[notasas@gmail.com: 3.2 backport]
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
5 years agoOMAPDSS: enable hw on gamma control
Grazvydas Ignotas [Sat, 28 May 2016 00:20:49 +0000 (03:20 +0300)]
OMAPDSS: enable hw on gamma control

forgot it back in 2012, relied on display being already on...

5 years agopandora: set up twl pulldowns and debounce
Grazvydas Ignotas [Tue, 24 May 2016 00:12:22 +0000 (03:12 +0300)]
pandora: set up twl pulldowns and debounce

pulldowns supposedly save power, no differences noticed tho

5 years agoomap_hsmmc: try to avoid reading the card too early
Grazvydas Ignotas [Sun, 22 May 2016 22:41:02 +0000 (01:41 +0300)]
omap_hsmmc: try to avoid reading the card too early

Pandora's SD sockets have card detect that triggers way before the card
is fully inserted, so sometimes the commands start before card has finished
moving and got locked in it's place. Try to delay more to deal with it.

5 years agopandora: add some hacky controls for expansion and 5v supplies
Grazvydas Ignotas [Sun, 22 May 2016 22:12:02 +0000 (01:12 +0300)]
pandora: add some hacky controls for expansion and 5v supplies

5 years agoASoC: pandora: add a regulator for dac
Grazvydas Ignotas [Sun, 22 May 2016 22:19:46 +0000 (01:19 +0300)]
ASoC: pandora: add a regulator for dac

Comes from regen-controlled 5V supply.

5 years agoOMAPDSS: TPO-TD03MTEA1: add vdd regulator
Grazvydas Ignotas [Sun, 22 May 2016 22:16:48 +0000 (01:16 +0300)]
OMAPDSS: TPO-TD03MTEA1: add vdd regulator

It's for CC units, where vdd comes from regen controlled 5V supply.
On Rebirth/1GHz vdd is controlled by vaux1 (vcc).

5 years agoehci-omap: add a vbus regulator
Grazvydas Ignotas [Sun, 22 May 2016 22:14:32 +0000 (01:14 +0300)]
ehci-omap: add a vbus regulator

the driver already uses one but it's for the PHY

5 years agopandora: add internal 5v and expansion supplies
Grazvydas Ignotas [Sun, 22 May 2016 22:08:53 +0000 (01:08 +0300)]
pandora: add internal 5v and expansion supplies

Those used to be always-on and not managed by the kernel,
now they will be.

5 years agomfd: twl-core: add a way to register dependent device
Grazvydas Ignotas [Sun, 22 May 2016 21:54:43 +0000 (00:54 +0300)]
mfd: twl-core: add a way to register dependent device

Need to add a regulator after other twl regulators are added but before
other devices probe.

5 years agoregulator: add regen regulator
Grazvydas Ignotas [Sun, 22 May 2016 21:48:06 +0000 (00:48 +0300)]
regulator: add regen regulator

Well it's not really a regulator, just an output signal that is
programmed the same way as a regulator, so it's easiest to add it
this way.

5 years agoregulator: core: don't crash if set_voltage fails
Grazvydas Ignotas [Sun, 22 May 2016 21:44:47 +0000 (00:44 +0300)]
regulator: core: don't crash if set_voltage fails

it was calling list_voltage() with uninitialized selector

5 years agoMerge branch 'stable-3.2' into pandora-3.2
Grazvydas Ignotas [Sun, 3 Jul 2016 00:22:57 +0000 (03:22 +0300)]
Merge branch 'stable-3.2' into pandora-3.2

5 years agoLinux 3.2.81 v3.2.81
Ben Hutchings [Wed, 15 Jun 2016 20:28:15 +0000 (21:28 +0100)]
Linux 3.2.81

5 years agonet: fix a kernel infoleak in x25 module
Kangjie Lu [Sun, 8 May 2016 16:10:14 +0000 (12:10 -0400)]
net: fix a kernel infoleak in x25 module

commit 79e48650320e6fba48369fccf13fd045315b19b8 upstream.

Stack object "dte_facilities" is allocated in x25_rx_call_request(),
which is supposed to be initialized in x25_negotiate_facilities.
However, 5 fields (8 bytes in total) are not initialized. This
object is then copied to userland via copy_to_user, thus infoleak
occurs.

Signed-off-by: Kangjie Lu <kjlu@gatech.edu>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
5 years agonet: fix infoleak in rtnetlink
Kangjie Lu [Tue, 3 May 2016 20:46:24 +0000 (16:46 -0400)]
net: fix infoleak in rtnetlink

commit 5f8e44741f9f216e33736ea4ec65ca9ac03036e6 upstream.

The stack object “map” has a total size of 32 bytes. Its last 4
bytes are padding generated by compiler. These padding bytes are
not initialized and sent out via “nla_put”.

Signed-off-by: Kangjie Lu <kjlu@gatech.edu>
Signed-off-by: David S. Miller <davem@davemloft.net>
[bwh: Backported to 3.2: adjust context, indentation]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
5 years agonet: fix infoleak in llc
Kangjie Lu [Tue, 3 May 2016 20:35:05 +0000 (16:35 -0400)]
net: fix infoleak in llc

commit b8670c09f37bdf2847cc44f36511a53afc6161fd upstream.

The stack object “info” has a total size of 12 bytes. Its last byte
is padding which is not initialized and leaked via “put_cmsg”.

Signed-off-by: Kangjie Lu <kjlu@gatech.edu>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
5 years agonf_conntrack: avoid kernel pointer value leak in slab name
Linus Torvalds [Sat, 14 May 2016 18:11:44 +0000 (11:11 -0700)]
nf_conntrack: avoid kernel pointer value leak in slab name

commit 31b0b385f69d8d5491a4bca288e25e63f1d945d0 upstream.

The slab name ends up being visible in the directory structure under
/sys, and even if you don't have access rights to the file you can see
the filenames.

Just use a 64-bit counter instead of the pointer to the 'net' structure
to generate a unique name.

This code will go away in 4.7 when the conntrack code moves to a single
kmemcache, but this is the backportable simple solution to avoiding
leaking kernel pointers to user space.

Fixes: 5b3501faa874 ("netfilter: nf_conntrack: per netns nf_conntrack_cachep")
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Acked-by: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
5 years agoget_rock_ridge_filename(): handle malformed NM entries
Al Viro [Thu, 5 May 2016 20:25:35 +0000 (16:25 -0400)]
get_rock_ridge_filename(): handle malformed NM entries

commit 99d825822eade8d827a1817357cbf3f889a552d6 upstream.

Payloads of NM entries are not supposed to contain NUL.  When we run
into such, only the part prior to the first NUL goes into the
concatenation (i.e. the directory entry name being encoded by a bunch
of NM entries).  We do stop when the amount collected so far + the
claimed amount in the current NM entry exceed 254.  So far, so good,
but what we return as the total length is the sum of *claimed*
sizes, not the actual amount collected.  And that can grow pretty
large - not unlimited, since you'd need to put CE entries in
between to be able to get more than the maximum that could be
contained in one isofs directory entry / continuation chunk and
we are stop once we'd encountered 32 CEs, but you can get about 8Kb
easily.  And that's what will be passed to readdir callback as the
name length.  8Kb __copy_to_user() from a buffer allocated by
__get_free_page()

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
5 years agoparisc: fix a bug when syscall number of tracee is __NR_Linux_syscalls
Dmitry V. Levin [Wed, 27 Apr 2016 01:56:11 +0000 (04:56 +0300)]
parisc: fix a bug when syscall number of tracee is __NR_Linux_syscalls

commit f0b22d1bb2a37a665a969e95785c75a4f49d1499 upstream.

Do not load one entry beyond the end of the syscall table when the
syscall number of a traced process equals to __NR_Linux_syscalls.
Similar bug with regular processes was fixed by commit 3bb457af4fa8
("[PARISC] Fix bug when syscall nr is __NR_Linux_syscalls").

This bug was found by strace test suite.

Signed-off-by: Dmitry V. Levin <ldv@altlinux.org>
Acked-by: Helge Deller <deller@gmx.de>
Signed-off-by: Helge Deller <deller@gmx.de>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
5 years agoproc: prevent accessing /proc/<PID>/environ until it's ready
Mathias Krause [Thu, 5 May 2016 23:22:26 +0000 (16:22 -0700)]
proc: prevent accessing /proc/<PID>/environ until it's ready

commit 8148a73c9901a8794a50f950083c00ccf97d43b3 upstream.

If /proc/<PID>/environ gets read before the envp[] array is fully set up
in create_{aout,elf,elf_fdpic,flat}_tables(), we might end up trying to
read more bytes than are actually written, as env_start will already be
set but env_end will still be zero, making the range calculation
underflow, allowing to read beyond the end of what has been written.

Fix this as it is done for /proc/<PID>/cmdline by testing env_end for
zero.  It is, apparently, intentionally set last in create_*_tables().

This bug was found by the PaX size_overflow plugin that detected the
arithmetic underflow of 'this_len = env_end - (env_start + src)' when
env_end is still zero.

The expected consequence is that userland trying to access
/proc/<PID>/environ of a not yet fully set up process may get
inconsistent data as we're in the middle of copying in the environment
variables.

Fixes: https://forums.grsecurity.net/viewtopic.php?f=3&t=4363
Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=116461
Signed-off-by: Mathias Krause <minipli@googlemail.com>
Cc: Emese Revfy <re.emese@gmail.com>
Cc: Pax Team <pageexec@freemail.hu>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Mateusz Guzik <mguzik@redhat.com>
Cc: Alexey Dobriyan <adobriyan@gmail.com>
Cc: Cyrill Gorcunov <gorcunov@openvz.org>
Cc: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
5 years agocrypto: hash - Fix page length clamping in hash walk
Herbert Xu [Wed, 4 May 2016 09:52:56 +0000 (17:52 +0800)]
crypto: hash - Fix page length clamping in hash walk

commit 13f4bb78cf6a312bbdec367ba3da044b09bf0e29 upstream.

The crypto hash walk code is broken when supplied with an offset
greater than or equal to PAGE_SIZE.  This patch fixes it by adjusting
walk->pg and walk->offset when this happens.

Reported-by: Steffen Klassert <steffen.klassert@secunet.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
5 years agoACPICA: Dispatcher: Update thread ID for recursive method calls
Prarit Bhargava [Wed, 4 May 2016 05:48:56 +0000 (13:48 +0800)]
ACPICA: Dispatcher: Update thread ID for recursive method calls

commit 93d68841a23a5779cef6fb9aa0ef32e7c5bd00da upstream.

ACPICA commit 7a3bd2d962f221809f25ddb826c9e551b916eb25

Set the mutex owner thread ID.
Original patch from: Prarit Bhargava <prarit@redhat.com>

Link: https://bugzilla.kernel.org/show_bug.cgi?id=115121
Link: https://github.com/acpica/acpica/commit/7a3bd2d9
Signed-off-by: Prarit Bhargava <prarit@redhat.com>
Tested-by: Andy Lutomirski <luto@kernel.org> # On a Dell XPS 13 9350
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
5 years agodrm/radeon: make sure vertical front porch is at least 1
Alex Deucher [Mon, 2 May 2016 22:53:27 +0000 (18:53 -0400)]
drm/radeon: make sure vertical front porch is at least 1

commit 3104b8128d4d646a574ed9d5b17c7d10752cd70b upstream.

hw doesn't like a 0 value.

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
5 years agoMinimal fix-up of bad hashing behavior of hash_64()
Linus Torvalds [Mon, 2 May 2016 19:46:42 +0000 (12:46 -0700)]
Minimal fix-up of bad hashing behavior of hash_64()

commit 689de1d6ca95b3b5bd8ee446863bf81a4883ea25 upstream.

This is a fairly minimal fixup to the horribly bad behavior of hash_64()
with certain input patterns.

In particular, because the multiplicative value used for the 64-bit hash
was intentionally bit-sparse (so that the multiply could be done with
shifts and adds on architectures without hardware multipliers), some
bits did not get spread out very much.  In particular, certain fairly
common bit ranges in the input (roughly bits 12-20: commonly with the
most information in them when you hash things like byte offsets in files
or memory that have block factors that mean that the low bits are often
zero) would not necessarily show up much in the result.

There's a bigger patch-series brewing to fix up things more completely,
but this is the fairly minimal fix for the 64-bit hashing problem.  It
simply picks a much better constant multiplier, spreading the bits out a
lot better.

NOTE! For 32-bit architectures, the bad old hash_64() remains the same
for now, since 64-bit multiplies are expensive.  The bigger hashing
cleanup will replace the 32-bit case with something better.

The new constants were picked by George Spelvin who wrote that bigger
cleanup series.  I just picked out the constants and part of the comment
from that series.

Cc: George Spelvin <linux@horizon.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
5 years agoMake hash_64() use a 64-bit multiply when appropriate
Linus Torvalds [Sat, 13 Sep 2014 18:24:03 +0000 (11:24 -0700)]
Make hash_64() use a 64-bit multiply when appropriate

commit 23d0db76ffa13ffb95229946e4648568c3c29db5 upstream.

The hash_64() function historically does the multiply by the
GOLDEN_RATIO_PRIME_64 number with explicit shifts and adds, because
unlike the 32-bit case, gcc seems unable to turn the constant multiply
into the more appropriate shift and adds when required.

However, that means that we generate those shifts and adds even when the
architecture has a fast multiplier, and could just do it better in
hardware.

Use the now-cleaned-up CONFIG_ARCH_HAS_FAST_MULTIPLIER (together with
"is it a 64-bit architecture") to decide whether to use an integer
multiply or the explicit sequence of shift/add instructions.

Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
[bwh: This has no immediate effect in 3.2 because nothing defines
 CONFIG_ARCH_HAS_FAST_MULTIPLIER. However the following fix removes
 that condition.]

5 years agoEDAC: i7core, sb_edac: Don't return NOTIFY_BAD from mce_decoder callback
Tony Luck [Fri, 29 Apr 2016 13:42:25 +0000 (15:42 +0200)]
EDAC: i7core, sb_edac: Don't return NOTIFY_BAD from mce_decoder callback

commit c4fc1956fa31003bfbe4f597e359d751568e2954 upstream.

Both of these drivers can return NOTIFY_BAD, but this terminates
processing other callbacks that were registered later on the chain.
Since the driver did nothing to log the error it seems wrong to prevent
other interested parties from seeing it. E.g. neither of them had even
bothered to check the type of the error to see if it was a memory error
before the return NOTIFY_BAD.

Signed-off-by: Tony Luck <tony.luck@intel.com>
Acked-by: Aristeu Rozanski <aris@redhat.com>
Acked-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Cc: linux-edac <linux-edac@vger.kernel.org>
Link: http://lkml.kernel.org/r/72937355dd92318d2630979666063f8a2853495b.1461864507.git.tony.luck@intel.com
Signed-off-by: Borislav Petkov <bp@suse.de>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
5 years agomm/huge_memory: replace VM_NO_THP VM_BUG_ON with actual VMA check
Konstantin Khlebnikov [Thu, 28 Apr 2016 23:18:32 +0000 (16:18 -0700)]
mm/huge_memory: replace VM_NO_THP VM_BUG_ON with actual VMA check

commit 3486b85a29c1741db99d0c522211c82d2b7a56d0 upstream.

Khugepaged detects own VMAs by checking vm_file and vm_ops but this way
it cannot distinguish private /dev/zero mappings from other special
mappings like /dev/hpet which has no vm_ops and popultes PTEs in mmap.

This fixes false-positive VM_BUG_ON and prevents installing THP where
they are not expected.

Link: http://lkml.kernel.org/r/CACT4Y+ZmuZMV5CjSFOeXviwQdABAgT7T+StKfTqan9YDtgEi5g@mail.gmail.com
Fixes: 78f11a255749 ("mm: thp: fix /dev/zero MAP_PRIVATE and vm_flags cleanups")
Signed-off-by: Konstantin Khlebnikov <koct9i@gmail.com>
Reported-by: Dmitry Vyukov <dvyukov@google.com>
Acked-by: Vlastimil Babka <vbabka@suse.cz>
Acked-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Cc: Dmitry Vyukov <dvyukov@google.com>
Cc: Andrea Arcangeli <aarcange@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
[bwh: Backported to 3.2:
 - The assertions use VM_BUG_ON() and also check is_linear_pfn_mapping();
   keep that check
 - Adjust context]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
5 years agothp: introduce hugepage_vma_check()
Bob Liu [Wed, 12 Dec 2012 00:00:39 +0000 (16:00 -0800)]
thp: introduce hugepage_vma_check()

commit fa475e517adb422cb3492e636195f9b2c0d009c8 upstream.

Multiple places do the same check.

Signed-off-by: Bob Liu <lliubbo@gmail.com>
Cc: Andrea Arcangeli <aarcange@redhat.com>
Cc: Michal Hocko <mhocko@suse.cz>
Cc: Minchan Kim <minchan.kim@gmail.com>
Cc: Ni zhan Chen <nizhan.chen@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
[bwh: Backported to 3.2:
 - Also move the is_linear_pfn_mapping() test
 - Adjust context]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
5 years agoIB/security: Restrict use of the write() interface
Jason Gunthorpe [Mon, 11 Apr 2016 01:13:13 +0000 (19:13 -0600)]
IB/security: Restrict use of the write() interface

commit e6bd18f57aad1a2d1ef40e646d03ed0f2515c9e3 upstream.

The drivers/infiniband stack uses write() as a replacement for
bi-directional ioctl().  This is not safe. There are ways to
trigger write calls that result in the return structure that
is normally written to user space being shunted off to user
specified kernel memory instead.

For the immediate repair, detect and deny suspicious accesses to
the write API.

For long term, update the user space libraries and the kernel API
to something that doesn't present the same security vulnerabilities
(likely a structured ioctl() interface).

The impacted uAPI interfaces are generally only available if
hardware from drivers/infiniband is installed in the system.

Reported-by: Jann Horn <jann@thejh.net>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
[ Expanded check to all known write() entry points ]
Signed-off-by: Doug Ledford <dledford@redhat.com>
[bwh: Backported to 3.2:
 - Drop changes to hfi1
 - include/rdma/ib.h didn't exist, so create it with the usual header guard
   and include it in drivers/infiniband/core/ucma.c
 - ipath_write() has the same problem, so add the same restriction there]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
5 years agodrm/i915: Fix system resume if PCI device remained enabled
Imre Deak [Mon, 18 Apr 2016 11:45:54 +0000 (14:45 +0300)]
drm/i915: Fix system resume if PCI device remained enabled

commit dab9a2663f4e688106c041f7cd2797a721382f0a upstream.

During system resume we depended on pci_enable_device() also putting the
device into PCI D0 state. This won't work if the PCI device was already
enabled but still in D3 state. This is because pci_enable_device() is
refcounted and will not change the HW state if called with a non-zero
refcount. Leaving the device in D3 will make all subsequent device
accesses fail.

This didn't cause a problem most of the time, since we resumed with an
enable refcount of 0. But it fails at least after module reload because
after that we also happen to leak a PCI device enable reference: During
probing we call drm_get_pci_dev() which will enable the PCI device, but
during device removal drm_put_dev() won't disable it. This is a bug of
its own in DRM core, but without much harm as it only leaves the PCI
device enabled. Fixing it is also a bit more involved, due to DRM
mid-layering and because it affects non-i915 drivers too. The fix in
this patch is valid regardless of the problem in DRM core.

v2:
- Add a code comment about the relation of this fix to the freeze/thaw
  vs. the suspend/resume phases. (Ville)
- Add a code comment about the inconsistent ordering of set power state
  and device enable calls. (Chris)

CC: Ville Syrjälä <ville.syrjala@linux.intel.com>
CC: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1460979954-14503-1-git-send-email-imre.deak@intel.com
(cherry picked from commit 44410cd0bfb26bde9288da34c190cc9267d42a20)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
[bwh: Backported to 3.2:
 - Return error code directly
 - Adjust context]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
5 years agoUSB: serial: cp210x: add Straizona Focusers device ids
Jasem Mutlaq [Tue, 19 Apr 2016 07:38:27 +0000 (10:38 +0300)]
USB: serial: cp210x: add Straizona Focusers device ids

commit 613ac23a46e10d4d4339febdd534fafadd68e059 upstream.

Adding VID:PID for Straizona Focusers to cp210x driver.

Signed-off-by: Jasem Mutlaq <mutlaqja@ikarustech.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
5 years agoUSB: serial: cp210x: add ID for Link ECU
Mike Manning [Mon, 18 Apr 2016 12:13:23 +0000 (12:13 +0000)]
USB: serial: cp210x: add ID for Link ECU

commit 1d377f4d690637a0121eac8701f84a0aa1e69a69 upstream.

The Link ECU is an aftermarket ECU computer for vehicles that provides
full tuning abilities as well as datalogging and displaying capabilities
via the USB to Serial adapter built into the device.

Signed-off-by: Mike Manning <michael@bsch.com.au>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
5 years agobatman-adv: Fix broadcast/ogm queue limit on a removed interface
Linus Lüssing [Fri, 11 Mar 2016 13:04:49 +0000 (14:04 +0100)]
batman-adv: Fix broadcast/ogm queue limit on a removed interface

commit c4fdb6cff2aa0ae740c5f19b6f745cbbe786d42f upstream.

When removing a single interface while a broadcast or ogm packet is
still pending then we will free the forward packet without releasing the
queue slots again.

This patch is supposed to fix this issue.

Fixes: 6d5808d4ae1b ("batman-adv: Add missing hardif_free_ref in forw_packet_free")
Signed-off-by: Linus Lüssing <linus.luessing@c0d3.blue>
[sven@narfation.org: fix conflicts with current version]
Signed-off-by: Sven Eckelmann <sven@narfation.org>
Signed-off-by: Marek Lindner <mareklindner@neomailbox.ch>
Signed-off-by: Antonio Quartulli <a@unstable.cc>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
5 years agobatman-adv: Reduce refcnt of removed router when updating route
Sven Eckelmann [Sun, 20 Mar 2016 11:27:53 +0000 (12:27 +0100)]
batman-adv: Reduce refcnt of removed router when updating route

commit d1a65f1741bfd9c69f9e4e2ad447a89b6810427d upstream.

_batadv_update_route rcu_derefences orig_ifinfo->router outside of a
spinlock protected region to print some information messages to the debug
log. But this pointer is not checked again when the new pointer is assigned
in the spinlock protected region. Thus is can happen that the value of
orig_ifinfo->router changed in the meantime and thus the reference counter
of the wrong router gets reduced after the spinlock protected region.

Just rcu_dereferencing the value of orig_ifinfo->router inside the spinlock
protected region (which also set the new pointer) is enough to get the
correct old router object.

Fixes: e1a5382f978b ("batman-adv: Make orig_node->router an rcu protected pointer")
Signed-off-by: Sven Eckelmann <sven@narfation.org>
Signed-off-by: Marek Lindner <mareklindner@neomailbox.ch>
Signed-off-by: Antonio Quartulli <a@unstable.cc>
[bwh: Backported to 3.2: s/orig_ifinfo/orig_node/]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
5 years agobatman-adv: Check skb size before using encapsulated ETH+VLAN header
Sven Eckelmann [Fri, 26 Feb 2016 16:56:13 +0000 (17:56 +0100)]
batman-adv: Check skb size before using encapsulated ETH+VLAN header

commit c78296665c3d81f040117432ab9e1cb125521b0c upstream.

The encapsulated ethernet and VLAN header may be outside the received
ethernet frame. Thus the skb buffer size has to be checked before it can be
parsed to find out if it encapsulates another batman-adv packet.

Fixes: 420193573f11 ("batman-adv: softif bridge loop avoidance")
Signed-off-by: Sven Eckelmann <sven@narfation.org>
Signed-off-by: Marek Lindner <mareklindner@neomailbox.ch>
Signed-off-by: Antonio Quartulli <a@unstable.cc>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
5 years agox86/mm/xen: Suppress hugetlbfs in PV guests
Jan Beulich [Thu, 21 Apr 2016 06:27:04 +0000 (00:27 -0600)]
x86/mm/xen: Suppress hugetlbfs in PV guests

commit 103f6112f253017d7062cd74d17f4a514ed4485c upstream.

Huge pages are not normally available to PV guests. Not suppressing
hugetlbfs use results in an endless loop of page faults when user mode
code tries to access a hugetlbfs mapped area (since the hypervisor
denies such PTEs to be created, but error indications can't be
propagated out of xen_set_pte_at(), just like for various of its
siblings), and - once killed in an oops like this:

  kernel BUG at .../fs/hugetlbfs/inode.c:428!
  invalid opcode: 0000 [#1] SMP
  ...
  RIP: e030:[<ffffffff811c333b>]  [<ffffffff811c333b>] remove_inode_hugepages+0x25b/0x320
  ...
  Call Trace:
   [<ffffffff811c3415>] hugetlbfs_evict_inode+0x15/0x40
   [<ffffffff81167b3d>] evict+0xbd/0x1b0
   [<ffffffff8116514a>] __dentry_kill+0x19a/0x1f0
   [<ffffffff81165b0e>] dput+0x1fe/0x220
   [<ffffffff81150535>] __fput+0x155/0x200
   [<ffffffff81079fc0>] task_work_run+0x60/0xa0
   [<ffffffff81063510>] do_exit+0x160/0x400
   [<ffffffff810637eb>] do_group_exit+0x3b/0xa0
   [<ffffffff8106e8bd>] get_signal+0x1ed/0x470
   [<ffffffff8100f854>] do_signal+0x14/0x110
   [<ffffffff810030e9>] prepare_exit_to_usermode+0xe9/0xf0
   [<ffffffff814178a5>] retint_user+0x8/0x13

This is CVE-2016-3961 / XSA-174.

Reported-by: Vitaly Kuznetsov <vkuznets@redhat.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: David Vrabel <david.vrabel@citrix.com>
Cc: Denys Vlasenko <dvlasenk@redhat.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Juergen Gross <JGross@suse.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Luis R. Rodriguez <mcgrof@suse.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Toshi Kani <toshi.kani@hp.com>
Cc: xen-devel <xen-devel@lists.xenproject.org>
Link: http://lkml.kernel.org/r/57188ED802000078000E431C@prv-mh.provo.novell.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
5 years agos390/hugetlb: add hugepages_supported define
Dominik Dingel [Fri, 17 Jul 2015 23:23:39 +0000 (16:23 -0700)]
s390/hugetlb: add hugepages_supported define

commit 7f9be77555bb2e52de84e9dddf7b4eb20cc6e171 upstream.

On s390 we only can enable hugepages if the underlying hardware/hypervisor
also does support this.  Common code now would assume this to be
signaled by setting HPAGE_SHIFT to 0.  But on s390, where we only
support one hugepage size, there is a link between HPAGE_SHIFT and
pageblock_order.

So instead of setting HPAGE_SHIFT to 0, we will implement the check for
the hardware capability.

Signed-off-by: Dominik Dingel <dingel@linux.vnet.ibm.com>
Acked-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
Cc: Christian Borntraeger <borntraeger@de.ibm.com>
Cc: Michael Holzheu <holzheu@linux.vnet.ibm.com>
Cc: Gerald Schaefer <gerald.schaefer@de.ibm.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
5 years agomm: hugetlb: allow hugepages_supported to be architecture specific
Dominik Dingel [Fri, 17 Jul 2015 23:23:37 +0000 (16:23 -0700)]
mm: hugetlb: allow hugepages_supported to be architecture specific

commit 2531c8cf56a640cd7d17057df8484e570716a450 upstream.

s390 has a constant hugepage size, by setting HPAGE_SHIFT we also change
e.g. the pageblock_order, which should be independent in respect to
hugepage support.

With this patch every architecture is free to define how to check
for hugepage support.

Signed-off-by: Dominik Dingel <dingel@linux.vnet.ibm.com>
Acked-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
Cc: Christian Borntraeger <borntraeger@de.ibm.com>
Cc: Michael Holzheu <holzheu@linux.vnet.ibm.com>
Cc: Gerald Schaefer <gerald.schaefer@de.ibm.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
5 years agohugetlb: ensure hugepage access is denied if hugepages are not supported
Nishanth Aravamudan [Tue, 6 May 2014 19:50:00 +0000 (12:50 -0700)]
hugetlb: ensure hugepage access is denied if hugepages are not supported

commit 457c1b27ed56ec472d202731b12417bff023594a upstream.

Currently, I am seeing the following when I `mount -t hugetlbfs /none
/dev/hugetlbfs`, and then simply do a `ls /dev/hugetlbfs`.  I think it's
related to the fact that hugetlbfs is properly not correctly setting
itself up in this state?:

  Unable to handle kernel paging request for data at address 0x00000031
  Faulting instruction address: 0xc000000000245710
  Oops: Kernel access of bad area, sig: 11 [#1]
  SMP NR_CPUS=2048 NUMA pSeries
  ....

In KVM guests on Power, in a guest not backed by hugepages, we see the
following:

  AnonHugePages:         0 kB
  HugePages_Total:       0
  HugePages_Free:        0
  HugePages_Rsvd:        0
  HugePages_Surp:        0
  Hugepagesize:         64 kB

HPAGE_SHIFT == 0 in this configuration, which indicates that hugepages
are not supported at boot-time, but this is only checked in
hugetlb_init().  Extract the check to a helper function, and use it in a
few relevant places.

This does make hugetlbfs not supported (not registered at all) in this
environment.  I believe this is fine, as there are no valid hugepages
and that won't change at runtime.

[akpm@linux-foundation.org: use pr_info(), per Mel]
[akpm@linux-foundation.org: fix build when HPAGE_SHIFT is undefined]
Signed-off-by: Nishanth Aravamudan <nacc@linux.vnet.ibm.com>
Reviewed-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
Acked-by: Mel Gorman <mgorman@suse.de>
Cc: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
[bwh: Backported to 3.2:
 - Drop changes to hugetlb_show_meminfo()
 - Adjust context]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
5 years agoatl2: Disable unimplemented scatter/gather feature
Ben Hutchings [Wed, 20 Apr 2016 22:23:08 +0000 (23:23 +0100)]
atl2: Disable unimplemented scatter/gather feature

commit f43bfaeddc79effbf3d0fcb53ca477cca66f3db8 upstream.

atl2 includes NETIF_F_SG in hw_features even though it has no support
for non-linear skbs.  This bug was originally harmless since the
driver does not claim to implement checksum offload and that used to
be a requirement for SG.

Now that SG and checksum offload are independent features, if you
explicitly enable SG *and* use one of the rare protocols that can use
SG without checkusm offload, this potentially leaks sensitive
information (before you notice that it just isn't working).  Therefore
this obscure bug has been designated CVE-2016-2117.

Reported-by: Justin Yackoski <jyackoski@crypto-nite.com>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Fixes: ec5f06156423 ("net: Kill link between CSUM and SG features.")
Signed-off-by: David S. Miller <davem@davemloft.net>
[bwh: Backported to 3.2: adjust context]

5 years agopowerpc: scan_features() updates incorrect bits for REAL_LE
Anton Blanchard [Fri, 15 Apr 2016 02:06:13 +0000 (12:06 +1000)]
powerpc: scan_features() updates incorrect bits for REAL_LE

commit 6997e57d693b07289694239e52a10d2f02c3a46f upstream.

The REAL_LE feature entry in the ibm_pa_feature struct is missing an MMU
feature value, meaning all the remaining elements initialise the wrong
values.

This means instead of checking for byte 5, bit 0, we check for byte 0,
bit 0, and then we incorrectly set the CPU feature bit as well as MMU
feature bit 1 and CPU user feature bits 0 and 2 (5).

Checking byte 0 bit 0 (IBM numbering), means we're looking at the
"Memory Management Unit (MMU)" feature - ie. does the CPU have an MMU.
In practice that bit is set on all platforms which have the property.

This means we set CPU_FTR_REAL_LE always. In practice that seems not to
matter because all the modern cpus which have this property also
implement REAL_LE, and we've never needed to disable it.

We're also incorrectly setting MMU feature bit 1, which is:

  #define MMU_FTR_TYPE_8xx 0x00000002

Luckily the only place that looks for MMU_FTR_TYPE_8xx is in Book3E
code, which can't run on the same cpus as scan_features(). So this also
doesn't matter in practice.

Finally in the CPU user feature mask, we're setting bits 0 and 2. Bit 2
is not currently used, and bit 0 is:

  #define PPC_FEATURE_PPC_LE 0x00000001

Which says the CPU supports the old style "PPC Little Endian" mode.
Again this should be harmless in practice as no 64-bit CPUs implement
that mode.

Fix the code by adding the missing initialisation of the MMU feature.

Also add a comment marking CPU user feature bit 2 (0x4) as reserved. It
would be unsafe to start using it as old kernels incorrectly set it.

Fixes: 44ae3ab3358e ("powerpc: Free up some CPU feature bits by moving out MMU-related features")
Signed-off-by: Anton Blanchard <anton@samba.org>
[mpe: Flesh out changelog, add comment reserving 0x4]
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
[bwh: Backported to 3.2: adjust filename, context]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
5 years agoInput: pmic8xxx-pwrkey - fix algorithm for converting trigger delay
Stephen Boyd [Sun, 17 Apr 2016 12:21:42 +0000 (05:21 -0700)]
Input: pmic8xxx-pwrkey - fix algorithm for converting trigger delay

commit eda5ecc0a6b865561997e177c393f0b0136fe3b7 upstream.

The trigger delay algorithm that converts from microseconds to
the register value looks incorrect. According to most of the PMIC
documentation, the equation is

delay (Seconds) = (1 / 1024) * 2 ^ (x + 4)

except for one case where the documentation looks to have a
formatting issue and the equation looks like

delay (Seconds) = (1 / 1024) * 2 x + 4

Most likely this driver was written with the improper
documentation to begin with. According to the downstream sources
the valid delays are from 2 seconds to 1/64 second, and the
latter equation just doesn't make sense for that. Let's fix the
algorithm and the range check to match the documentation and the
downstream sources.

Reported-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Fixes: 92d57a73e410 ("input: Add support for Qualcomm PMIC8XXX power key")
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Tested-by: John Stultz <john.stultz@linaro.org>
Acked-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
[bwh: Backported to 3.2: use pdata->kpd_trigger_delay_us not kpd_delay]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
5 years agousb: hcd: out of bounds access in for_each_companion
Robert Dobrowolski [Thu, 24 Mar 2016 10:30:07 +0000 (03:30 -0700)]
usb: hcd: out of bounds access in for_each_companion

commit e86103a75705c7c530768f4ffaba74cf382910f2 upstream.

On BXT platform Host Controller and Device Controller figure as
same PCI device but with different device function. HCD should
not pass data to Device Controller but only to Host Controllers.
Checking if companion device is Host Controller, otherwise skip.

Signed-off-by: Robert Dobrowolski <robert.dobrowolski@linux.intel.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
5 years agoUSB: uas: Add a new NO_REPORT_LUNS quirk
Hans de Goede [Tue, 12 Apr 2016 10:27:09 +0000 (12:27 +0200)]
USB: uas: Add a new NO_REPORT_LUNS quirk

commit 1363074667a6b7d0507527742ccd7bbed5e3ceaa upstream.

Add a new NO_REPORT_LUNS quirk and set it for Seagate drives with
an usb-id of: 0bc2:331a, as these will fail to respond to a
REPORT_LUNS command.

Reported-and-tested-by: David Webb <djw@noc.ac.uk>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[bwh: Backported to 3.2:
 - Adjust context
 - Drop the UAS changes]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
5 years agousb: xhci: fix wild pointers in xhci_mem_cleanup
Lu Baolu [Fri, 8 Apr 2016 13:25:09 +0000 (16:25 +0300)]
usb: xhci: fix wild pointers in xhci_mem_cleanup

commit 71504062a7c34838c3fccd92c447f399d3cb5797 upstream.

This patch fixes some wild pointers produced by xhci_mem_cleanup.
These wild pointers will cause system crash if xhci_mem_cleanup()
is called twice.

Reported-and-tested-by: Pengcheng Li <lpc.li@hisilicon.com>
Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[bwh: Backported to 3.2: there's no xhci_hcd::ext_caps field to clear]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
5 years agousb: xhci: applying XHCI_PME_STUCK_QUIRK to Intel BXT B0 host
Rafal Redzimski [Fri, 8 Apr 2016 13:25:05 +0000 (16:25 +0300)]
usb: xhci: applying XHCI_PME_STUCK_QUIRK to Intel BXT B0 host

commit 0d46faca6f887a849efb07c1655b5a9f7c288b45 upstream.

Broxton B0 also requires XHCI_PME_STUCK_QUIRK.
Adding PCI device ID for Broxton B and adding to quirk.

Signed-off-by: Rafal Redzimski <rafal.f.redzimski@intel.com>
Signed-off-by: Robert Dobrowolski <robert.dobrowolski@linux.intel.com>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
5 years agonl80211: check netlink protocol in socket release notification
Dmitry Ivanov [Wed, 6 Apr 2016 14:23:18 +0000 (17:23 +0300)]
nl80211: check netlink protocol in socket release notification

commit 8f815cdde3e550e10c2736990d791f60c2ce43eb upstream.

A non-privileged user can create a netlink socket with the same port_id as
used by an existing open nl80211 netlink socket (e.g. as used by a hostapd
process) with a different protocol number.

Closing this socket will then lead to the notification going to nl80211's
socket release notification handler, and possibly cause an action such as
removing a virtual interface.

Fix this issue by checking that the netlink protocol is NETLINK_GENERIC.
Since generic netlink has no notifier chain of its own, we can't fix the
problem more generically.

Fixes: 026331c4d9b5 ("cfg80211/mac80211: allow registering for and sending action frames")
Signed-off-by: Dmitry Ivanov <dima@ubnt.com>
[rewrite commit message]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
5 years agokvm: x86: do not leak guest xcr0 into host interrupt handlers
David Matlack [Wed, 30 Mar 2016 19:24:47 +0000 (12:24 -0700)]
kvm: x86: do not leak guest xcr0 into host interrupt handlers

commit fc5b7f3bf1e1414bd4e91db6918c85ace0c873a5 upstream.

An interrupt handler that uses the fpu can kill a KVM VM, if it runs
under the following conditions:
 - the guest's xcr0 register is loaded on the cpu
 - the guest's fpu context is not loaded
 - the host is using eagerfpu

Note that the guest's xcr0 register and fpu context are not loaded as
part of the atomic world switch into "guest mode". They are loaded by
KVM while the cpu is still in "host mode".

Usage of the fpu in interrupt context is gated by irq_fpu_usable(). The
interrupt handler will look something like this:

if (irq_fpu_usable()) {
        kernel_fpu_begin();

        [... code that uses the fpu ...]

        kernel_fpu_end();
}

As long as the guest's fpu is not loaded and the host is using eager
fpu, irq_fpu_usable() returns true (interrupted_kernel_fpu_idle()
returns true). The interrupt handler proceeds to use the fpu with
the guest's xcr0 live.

kernel_fpu_begin() saves the current fpu context. If this uses
XSAVE[OPT], it may leave the xsave area in an undesirable state.
According to the SDM, during XSAVE bit i of XSTATE_BV is not modified
if bit i is 0 in xcr0. So it's possible that XSTATE_BV[i] == 1 and
xcr0[i] == 0 following an XSAVE.

kernel_fpu_end() restores the fpu context. Now if any bit i in
XSTATE_BV == 1 while xcr0[i] == 0, XRSTOR generates a #GP. The
fault is trapped and SIGSEGV is delivered to the current process.

Only pre-4.2 kernels appear to be vulnerable to this sequence of
events. Commit 653f52c ("kvm,x86: load guest FPU context more eagerly")
from 4.2 forces the guest's fpu to always be loaded on eagerfpu hosts.

This patch fixes the bug by keeping the host's xcr0 loaded outside
of the interrupts-disabled region where KVM switches into guest mode.

Suggested-by: Andy Lutomirski <luto@amacapital.net>
Signed-off-by: David Matlack <dmatlack@google.com>
[Move load after goto cancel_injection. - Paolo]
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
[bwh: Backported to 3.2:
 - Adjust context
 - Drop change in__kvm_set_xcr()]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
5 years agolibahci: save port map for forced port map
Srinivas Kandagatla [Fri, 1 Apr 2016 07:52:56 +0000 (08:52 +0100)]
libahci: save port map for forced port map

commit 2fd0f46cb1b82587c7ae4a616d69057fb9bd0af7 upstream.

In usecases where force_port_map is used saved_port_map is never set,
resulting in not programming the PORTS_IMPL register as part of initial
config. This patch fixes this by setting it to port_map even in case
where force_port_map is used, making it more inline with other parts of
the code.

Fixes: 566d1827df2e ("libata: disable forced PORTS_IMPL for >= AHCI 1.3")
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Acked-by: Tejun Heo <tj@kernel.org>
Reviewed-by: Andy Gross <andy.gross@linaro.org>
Signed-off-by: Tejun Heo <tj@kernel.org>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
5 years agoInput: gtco - fix crash on detecting device without endpoints
Vladis Dronov [Thu, 31 Mar 2016 17:53:42 +0000 (10:53 -0700)]
Input: gtco - fix crash on detecting device without endpoints

commit 162f98dea487206d9ab79fc12ed64700667a894d upstream.

The gtco driver expects at least one valid endpoint. If given malicious
descriptors that specify 0 for the number of endpoints, it will crash in
the probe function. Ensure there is at least one endpoint on the interface
before using it.

Also let's fix a minor coding style issue.

The full correct report of this issue can be found in the public
Red Hat Bugzilla:

https://bugzilla.redhat.com/show_bug.cgi?id=1283385

Reported-by: Ralf Spenneberg <ralf@spenneberg.net>
Signed-off-by: Vladis Dronov <vdronov@redhat.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
5 years agoipmi: fix timeout calculation when bmc is disconnected
Xie XiuQi [Fri, 24 Jan 2014 20:00:52 +0000 (14:00 -0600)]
ipmi: fix timeout calculation when bmc is disconnected

commit e21404dc0ac7ac971c1e36274b48bb460463f4e5 upstream.

Loading ipmi_si module while bmc is disconnected, we found the timeout
is longer than 5 secs.  Actually it takes about 3 mins and 20
secs.(HZ=250)

error message as below:
  Dec 12 19:08:59 linux kernel: IPMI BT: timeout in RD_WAIT [ ] 1 retries left
  Dec 12 19:08:59 linux kernel: BT: write 4 bytes seq=0x01 03 18 00 01
  [...]
  Dec 12 19:12:19 linux kernel: IPMI BT: timeout in RD_WAIT [ ]
  Dec 12 19:12:19 linux kernel: failed 2 retries, sending error response
  Dec 12 19:12:19 linux kernel: IPMI: BT reset (takes 5 secs)
  Dec 12 19:12:19 linux kernel: IPMI BT: flag reset [ ]

Function wait_for_msg_done() use schedule_timeout_uninterruptible(1) to
sleep 1 tick, so we should subtract jiffies_to_usecs(1) instead of 100
usecs from timeout.

Reported-by: Hu Shiyuan <hushiyuan@huawei.com>
Signed-off-by: Xie XiuQi <xiexiuqi@huawei.com>
Signed-off-by: Corey Minyard <cminyard@mvista.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Cc: sebastian.riemer@profitbricks.com
Cc: cminyard@mvista.com
Cc: openipmi-developer@lists.sourceforge.net
5 years agox86, sparse: Do not force removal of __user when calling copy_to/from_user_nocheck()
Steven Rostedt [Fri, 3 Jan 2014 21:45:00 +0000 (16:45 -0500)]
x86, sparse: Do not force removal of __user when calling copy_to/from_user_nocheck()

commit df90ca969035d3f6c95044e272f75bf417b14245 upstream.

Commit ff47ab4ff3cdd "x86: Add 1/2/4/8 byte optimization to 64bit
__copy_{from,to}_user_inatomic" added a "_nocheck" call in between
the copy_to/from_user() and copy_user_generic(). As both the
normal and nocheck versions of theses calls use the proper __user
annotation, a typecast to remove it should not be added.
This causes sparse to spin out the following warnings:

arch/x86/include/asm/uaccess_64.h:207:47: warning: incorrect type in argument 2 (different address spaces)
arch/x86/include/asm/uaccess_64.h:207:47:    expected void const [noderef] <asn:1>*src
arch/x86/include/asm/uaccess_64.h:207:47:    got void const *<noident>
arch/x86/include/asm/uaccess_64.h:207:47: warning: incorrect type in argument 2 (different address spaces)
arch/x86/include/asm/uaccess_64.h:207:47:    expected void const [noderef] <asn:1>*src
arch/x86/include/asm/uaccess_64.h:207:47:    got void const *<noident>
arch/x86/include/asm/uaccess_64.h:207:47: warning: incorrect type in argument 2 (different address spaces)
arch/x86/include/asm/uaccess_64.h:207:47:    expected void const [noderef] <asn:1>*src
arch/x86/include/asm/uaccess_64.h:207:47:    got void const *<noident>
arch/x86/include/asm/uaccess_64.h:207:47: warning: incorrect type in argument 2 (different address spaces)
arch/x86/include/asm/uaccess_64.h:207:47:    expected void const [noderef] <asn:1>*src
arch/x86/include/asm/uaccess_64.h:207:47:    got void const *<noident>

Cc: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
Link: http://lkml.kernel.org/r/20140103164500.5f6478f5@gandalf.local.home
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Cc: Jaccon Bastiaansen <jaccon.bastiaansen@gmail.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: mingo@redhat.com
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: h.zuidam@computer.org
5 years agox86: Add 1/2/4/8 byte optimization to 64bit __copy_{from,to}_user_inatomic
Andi Kleen [Fri, 16 Aug 2013 21:17:19 +0000 (14:17 -0700)]
x86: Add 1/2/4/8 byte optimization to 64bit __copy_{from,to}_user_inatomic

commit ff47ab4ff3cddfa7bc1b25b990e24abe2ae474ff upstream.

The 64bit __copy_{from,to}_user_inatomic always called
copy_from_user_generic, but skipped the special optimizations for 1/2/4/8
byte accesses.

This especially hurts the futex call, which accesses the 4 byte futex
user value with a complicated fast string operation in a function call,
instead of a single movl.

Use __copy_{from,to}_user for _inatomic instead to get the same
optimizations. The only problem was the might_fault() in those functions.
So move that to new wrapper and call __copy_{f,t}_user_nocheck()
from *_inatomic directly.

32bit already did this correctly by duplicating the code.

Signed-off-by: Andi Kleen <ak@linux.intel.com>
Link: http://lkml.kernel.org/r/1376687844-19857-2-git-send-email-andi@firstfloor.org
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Cc: Jaccon Bastiaansen <jaccon.bastiaansen@gmail.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: mingo@redhat.com
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: h.zuidam@computer.org
5 years agocrypto: gcm - Fix rfc4543 decryption crash
Herbert Xu [Fri, 18 Mar 2016 14:42:40 +0000 (22:42 +0800)]
crypto: gcm - Fix rfc4543 decryption crash

This bug has already bee fixed upstream since 4.2.  However, it
was fixed during the AEAD conversion so no fix was backported to
the older kernels.

When we do an RFC 4543 decryption, we will end up writing the
ICV beyond the end of the dst buffer.  This should lead to a
crash but for some reason it was never noticed.

This patch fixes it by only writing back the ICV for encryption.

Fixes: d733ac90f9fe ("crypto: gcm - fix rfc4543 to handle async...")
Reported-by: Patrick Meyer <patrick.meyer@vasgard.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
5 years agocrypto: gcm - fix rfc4543 to handle async crypto correctly
Jussi Kivilinna [Sun, 7 Apr 2013 13:43:46 +0000 (16:43 +0300)]
crypto: gcm - fix rfc4543 to handle async crypto correctly

commit d733ac90f9fe8ac284e523f9920b507555b12f6d upstream.

If the gcm cipher used by rfc4543 does not complete request immediately,
the authentication tag is not copied to destination buffer. Patch adds
correct async logic for this case.

Signed-off-by: Jussi Kivilinna <jussi.kivilinna@iki.fi>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
5 years agox86/microcode/amd: Do not overwrite final patch levels
Borislav Petkov [Mon, 12 Oct 2015 09:22:42 +0000 (11:22 +0200)]
x86/microcode/amd: Do not overwrite final patch levels

commit 0399f73299f1b7e04de329050f7111b362b7eeb5 upstream.

A certain number of patch levels of applied microcode should not
be overwritten by the microcode loader, otherwise bad things
will happen.

Check those and abort update if the current core has one of
those final patch levels applied by the BIOS. 32-bit needs
special handling, of course.

See https://bugzilla.suse.com/show_bug.cgi?id=913996 for more
info.

Tested-by: Peter Kirchgeßner <pkirchgessner@t-online.de>
Signed-off-by: Borislav Petkov <bp@suse.de>
Cc: Borislav Petkov <bp@alien8.de>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Tony Luck <tony.luck@intel.com>
Link: http://lkml.kernel.org/r/1444641762-9437-7-git-send-email-bp@alien8.de
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Cc: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
5 years agox86/microcode/amd: Extract current patch level read to a function
Borislav Petkov [Mon, 12 Oct 2015 09:22:41 +0000 (11:22 +0200)]
x86/microcode/amd: Extract current patch level read to a function

commit 2eff73c0a11f19ff082a566e3429fbaaca7b8e7b upstream.

Pave the way for checking the current patch level of the
microcode in a core. We want to be able to do stuff depending on
the patch level - in this case decide whether to update or not.
But that will be added in a later patch.

Drop unused local var uci assignment, while at it.

Integrate a fix for 32-bit and CONFIG_PARAVIRT from Takashi Iwai:

 Use native_rdmsr() in check_current_patch_level() because with
 CONFIG_PARAVIRT enabled and on 32-bit, where we run before
 paging has been enabled, we cannot deref pv_info yet. Or we
 could, but we'd need to access its physical address. This way of
 fixing it is simpler. See:

   https://bugzilla.suse.com/show_bug.cgi?id=943179 for the background.

Signed-off-by: Borislav Petkov <bp@suse.de>
Cc: Borislav Petkov <bp@alien8.de>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Takashi Iwai <tiwai@suse.com>:
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Tony Luck <tony.luck@intel.com>
Link: http://lkml.kernel.org/r/1444641762-9437-6-git-send-email-bp@alien8.de
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Cc: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
5 years agoRevert "net: validate variable length ll headers"
Ben Hutchings [Sun, 1 May 2016 16:00:43 +0000 (18:00 +0200)]
Revert "net: validate variable length ll headers"

This reverts commit b5518429e70cd783b8ca52335456172c1a0589f6, which was
commit 2793a23aacbd754dbbb5cb75093deb7e4103bace upstream.  It is
pointless unless af_packet calls the new function.

Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
5 years agoRevert "ax25: add link layer header validation function"
Ben Hutchings [Sun, 1 May 2016 15:59:44 +0000 (17:59 +0200)]
Revert "ax25: add link layer header validation function"

This reverts commit 0954b59d9f4b2dcc59f28d1f64c3a21062a64372, which was
commit ea47781c26510e5d97f80f9aceafe9065bd5e3aa upstream.  It is
pointless unless af_packet calls the new function.

Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
5 years agopandora: defconfig: enable smartreflex
Grazvydas Ignotas [Sun, 15 May 2016 12:44:27 +0000 (15:44 +0300)]
pandora: defconfig: enable smartreflex

should do no harm as it's inactive by default, to enable do:
 mkdir /debug
 mount -t debugfs none /debug
 echo 1 > /debug/smartreflex/sr_mpu_iva/autocomp

5 years agobq27x00_battery: optimize i2c read
Grazvydas Ignotas [Sat, 14 May 2016 19:59:00 +0000 (22:59 +0300)]
bq27x00_battery: optimize i2c read

One big instead of many small ones.
Less irqs, wakeups and context switches.

5 years agoARM: OMAP2+: PM: fix return value check in omap2_set_init_voltage()
Wei Yongjun [Thu, 27 Sep 2012 05:54:36 +0000 (13:54 +0800)]
ARM: OMAP2+: PM: fix return value check in omap2_set_init_voltage()

In case of error, the function voltdm_lookup() returns NULL
not ERR_PTR(). The IS_ERR() test in the return value check
should be replaced with NULL test.

dpatch engine is used to auto generate this patch.
(https://github.com/weiyj/dpatch)

Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Acked-by: Jean Pihet <j-pihet@ti.com>
Signed-off-by: Kevin Hilman <khilman@ti.com>
5 years agoARM: OMAP2+: SmartReflex: fix return value check in sr_dev_init()
Wei Yongjun [Thu, 27 Sep 2012 05:54:22 +0000 (13:54 +0800)]
ARM: OMAP2+: SmartReflex: fix return value check in sr_dev_init()

In case of error, the function voltdm_lookup() returns NULL
not ERR_PTR(). The IS_ERR() test in the return value check
should be replaced with NULL test.

dpatch engine is used to auto generate this patch.
(https://github.com/weiyj/dpatch)

Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Acked-by: Jean Pihet <j-pihet@ti.com>
Signed-off-by: Kevin Hilman <khilman@ti.com>
5 years agoARM: OMAP3+: SmartReflex: fix error handling
Jean Pihet [Wed, 29 Feb 2012 22:33:49 +0000 (23:33 +0100)]
ARM: OMAP3+: SmartReflex: fix error handling

Fix the code to correctly use IS_ERR and PTR_ERR on the return
values pointers

Reported-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Signed-off-by: Jean Pihet <j-pihet@ti.com>
Reviewed-by: Kevin Hilman <khilman@ti.com>
Signed-off-by: Kevin Hilman <khilman@ti.com>
5 years agoARM: OMAP3+: SmartReflex: fix the use of debugfs_create_* API
Jean Pihet [Wed, 29 Feb 2012 22:33:48 +0000 (23:33 +0100)]
ARM: OMAP3+: SmartReflex: fix the use of debugfs_create_* API

The debugfs_create_* API returns a return code or NULL
in the return ptr in case of problem.
Fix the smartreflex code to take this into account.

Signed-off-by: Jean Pihet <j-pihet@ti.com>
Reviewed-by: Kevin Hilman <khilman@ti.com>
Signed-off-by: Kevin Hilman <khilman@ti.com>
5 years agoARM: OMAP3+: SmartReflex: micro-optimization for sanity check
Felipe Balbi [Wed, 29 Feb 2012 22:33:47 +0000 (23:33 +0100)]
ARM: OMAP3+: SmartReflex: micro-optimization for sanity check

val && (val != 1) == val > 1

Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Jean Pihet <j-pihet@ti.com>
Reviewed-by: Kevin Hilman <khilman@ti.com>
Signed-off-by: Kevin Hilman <khilman@ti.com>
5 years agoARM: OMAP3+: SmartReflex: misc cleanups
Felipe Balbi [Wed, 29 Feb 2012 22:33:46 +0000 (23:33 +0100)]
ARM: OMAP3+: SmartReflex: misc cleanups

There are no functional changes here, only misc cleanups in general:
- re-organize variable declarations,
- converting if {} else if {} else {} into switch statements,
- correct comments typos,
- add/remove white lines to improve readability,
- etc.

Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Jean Pihet <j-pihet@ti.com>
Reviewed-by: Kevin Hilman <khilman@ti.com>
Signed-off-by: Kevin Hilman <khilman@ti.com>
5 years agoARM: OMAP3+: SmartReflex: move late_initcall() closer to its argument
Felipe Balbi [Wed, 29 Feb 2012 22:33:45 +0000 (23:33 +0100)]
ARM: OMAP3+: SmartReflex: move late_initcall() closer to its argument

no functional changes, trivial patch.

Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Jean Pihet <j-pihet@ti.com>
Reviewed-by: Kevin Hilman <khilman@ti.com>
Signed-off-by: Kevin Hilman <khilman@ti.com>
5 years agoARM: OMAP3+: SmartReflex: add missing platform_set_drvdata()
Felipe Balbi [Wed, 29 Feb 2012 22:33:44 +0000 (23:33 +0100)]
ARM: OMAP3+: SmartReflex: add missing platform_set_drvdata()

That's very useful to fetch the correct struct sr_info
from the PM handlers.

Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Jean Pihet <j-pihet@ti.com>
Reviewed-by: Kevin Hilman <khilman@ti.com>
Signed-off-by: Kevin Hilman <khilman@ti.com>
5 years agoARM: OMAP3+: hwmod: add SmartReflex IRQs
Nishanth Menon [Wed, 29 Feb 2012 22:33:43 +0000 (23:33 +0100)]
ARM: OMAP3+: hwmod: add SmartReflex IRQs

Add OMAP3 SmartReflex IRQs in hwmod structures. Without these IRQs
being registered the SmartReflex driver will be unable to get the
IRQ numbers to handle notifications.

Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Jean Pihet <j-pihet@ti.com>
Reviewed-by: Kevin Hilman <khilman@ti.com>
Signed-off-by: Kevin Hilman <khilman@ti.com>
5 years agoARM: OMAP3+: SmartReflex: clear ERRCONFIG_VPBOUNDINTST only on a need
Nishanth Menon [Wed, 29 Feb 2012 22:33:42 +0000 (23:33 +0100)]
ARM: OMAP3+: SmartReflex: clear ERRCONFIG_VPBOUNDINTST only on a need

The VPBOUNDINTST field of the ERRCONFIG register has an additional
functional meaning of force clearing the SR internal signal with VP
(sr_interruptz).
This can result in scenarios where the VP->SR protocol is violated
because the SR internal signal with VP is already high and VP will
never clear the vpirqclr signal.
Therefore during the next force update to reset to nominal voltage,
VP cannot pulse vpirqclr, so the PRCM HW cannot generate the tranxdone
IRQ and the situation is not recoverable until a cold reset is invoked.

To prevent this situation, check if status is set before clearing it
as this needs to be done only on a need basis.

Reported-by: Vincent Bour <v-bour@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Jean Pihet <j-pihet@ti.com>
Reviewed-by: Kevin Hilman <khilman@ti.com>
Signed-off-by: Kevin Hilman <khilman@ti.com>
5 years agoARM: OMAP3+: SmartReflex: Fix status masking in ERRCONFIG register
Nishanth Menon [Wed, 29 Feb 2012 22:33:41 +0000 (23:33 +0100)]
ARM: OMAP3+: SmartReflex: Fix status masking in ERRCONFIG register

ERRCONFIG register has status bits that were intended not to
be destroyed by bad modification. We cleanup and simplify the
handling the status in the modify path.

Reported-by: Vincent Bour <v-bour@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Jean Pihet <j-pihet@ti.com>
Reviewed-by: Kevin Hilman <khilman@ti.com>
Signed-off-by: Kevin Hilman <khilman@ti.com>
5 years agoARM: OMAP3+: SmartReflex: Add a shutdown hook
Nishanth Menon [Wed, 29 Feb 2012 23:29:44 +0000 (00:29 +0100)]
ARM: OMAP3+: SmartReflex: Add a shutdown hook

SmartReflex fix for erratum ID i724.

Since OMAP's VP and PRM modules do not get reset by warm reset,
we should ensure that proper shutdown procedure is followed prior
to allowing the kernel to reboot back up.

Without this, Smartreflex module might be left active or
system might be caught in an indeterminate sequence when
software controlled reboot is triggered, leaving the next
reboot behavior to be unpredictable.

In the case of hardware controlled warm reset such as that
by watchdog timer, prevention of this scenario is not possible.

Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Jean Pihet <j-pihet@ti.com>
Reviewed-by: Kevin Hilman <khilman@ti.com>
Signed-off-by: Kevin Hilman <khilman@ti.com>
5 years agoARM: OMAP3+: SmartReflex Class3: disable errorgen before disable VP
Nishanth Menon [Wed, 29 Feb 2012 22:33:39 +0000 (23:33 +0100)]
ARM: OMAP3+: SmartReflex Class3: disable errorgen before disable VP

SmartReflex AVS Errorgen module supplies signals to Voltage
Processor. It is suggested that by disabling Errorgen module
before we disable VP, we might be able to ensure lesser
chances of race condition to occur in the system.

Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Jean Pihet <j-pihet@ti.com>
Reviewed-by: Kevin Hilman <khilman@ti.com>
Signed-off-by: Kevin Hilman <khilman@ti.com>
5 years agoARM: OMAP3+: SmartReflex: fix err interrupt disable sequence
Nishanth Menon [Wed, 29 Feb 2012 22:33:38 +0000 (23:33 +0100)]
ARM: OMAP3+: SmartReflex: fix err interrupt disable sequence

sr_modify_mask takes mask, value as parameters, the usage
currently is value, mask which is wrong, as a result
vpboundint_st which was supposed to have been disabled,
does not get disabled.

Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Jean Pihet <j-pihet@ti.com>
Reviewed-by: Kevin Hilman <khilman@ti.com>
Signed-off-by: Kevin Hilman <khilman@ti.com>
5 years agoARM: OMAP3+: SmartReflex: use voltage domain name in device attributes
Shweta Gulati [Wed, 29 Feb 2012 22:33:37 +0000 (23:33 +0100)]
ARM: OMAP3+: SmartReflex: use voltage domain name in device attributes

To set sr ntarget values for all volt_domain,
volt_table is retrieved by doing a look_up of 'vdd_name'
field from omap_hwmod but voltage domain pointer does not
belong to omap_hwmod and is not used anywhere else.
As a part of voltage layer and SR Layer clean up volt
pointer is removed from omap_hwmod and added in dev
attributes of SR. The value of the field must match
the voltage domain names for the binding to be effective.

Tested on OMAP3630 SDP, OMAP3530 Beagleboard and
OMAP4430 SDP Board.

Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Shweta Gulati <shweta.gulati@ti.com>
Acked by: Nishanth Menon <nm@ti.com>
Cc: Benoit Cousson <b-cousson@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
Signed-off-by: Jean Pihet <j-pihet@ti.com>
Reviewed-by: Kevin Hilman <khilman@ti.com>
Signed-off-by: Kevin Hilman <khilman@ti.com>
5 years agoARM: OMAP2+: Fix devexit for smartreflex when CONFIG_HOTPLUG is not set
Tony Lindgren [Thu, 23 Feb 2012 22:55:40 +0000 (14:55 -0800)]
ARM: OMAP2+: Fix devexit for smartreflex when CONFIG_HOTPLUG is not set

Otherwise we get:

`omap_sr_remove' referenced in section `.data' of arch/arm/mach-omap2/built-in.o:
defined in discarded section `.devexit.text' of arch/arm/mach-omap2/built-in.o

Signed-off-by: Tony Lindgren <tony@atomide.com>
5 years agoARM: OMAP2+: arch/arm/mach-omap2/smartreflex.c: add missing iounmap
Julia Lawall [Thu, 12 Jan 2012 09:55:17 +0000 (10:55 +0100)]
ARM: OMAP2+: arch/arm/mach-omap2/smartreflex.c: add missing iounmap

Add missing iounmap in error handling code, in a case where the function
already preforms iounmap on some other execution path.

A simplified version of the semantic match that finds this problem is as
follows: (http://coccinelle.lip6.fr/)

// <smpl>
@@
expression e;
statement S,S1;
int ret;
@@
e = \(ioremap\|ioremap_nocache\)(...)
... when != iounmap(e)
if (<+...e...+>) S
... when any
    when != iounmap(e)
*if (...)
   { ... when != iounmap(e)
     return ...; }
... when any
iounmap(e);
// </smpl>

Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
Signed-off-by: Tony Lindgren <tony@atomide.com>
5 years agoMerge branch 'stable-3.2' into pandora-3.2
Grazvydas Ignotas [Sun, 15 May 2016 12:42:35 +0000 (15:42 +0300)]
Merge branch 'stable-3.2' into pandora-3.2

5 years agoLinux 3.2.80 v3.2.80
Ben Hutchings [Sat, 30 Apr 2016 22:05:28 +0000 (00:05 +0200)]
Linux 3.2.80

5 years agonetfilter: x_tables: fix unconditional helper
Florian Westphal [Tue, 22 Mar 2016 17:02:52 +0000 (18:02 +0100)]
netfilter: x_tables: fix unconditional helper

commit 54d83fc74aa9ec72794373cb47432c5f7fb1a309 upstream.

Ben Hawkes says:

 In the mark_source_chains function (net/ipv4/netfilter/ip_tables.c) it
 is possible for a user-supplied ipt_entry structure to have a large
 next_offset field. This field is not bounds checked prior to writing a
 counter value at the supplied offset.

Problem is that mark_source_chains should not have been called --
the rule doesn't have a next entry, so its supposed to return
an absolute verdict of either ACCEPT or DROP.

However, the function conditional() doesn't work as the name implies.
It only checks that the rule is using wildcard address matching.

However, an unconditional rule must also not be using any matches
(no -m args).

The underflow validator only checked the addresses, therefore
passing the 'unconditional absolute verdict' test, while
mark_source_chains also tested for presence of matches, and thus
proceeeded to the next (not-existent) rule.

Unify this so that all the callers have same idea of 'unconditional rule'.

Reported-by: Ben Hawkes <hawkes@google.com>
Signed-off-by: Florian Westphal <fw@strlen.de>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
5 years agojme: Fix device PM wakeup API usage
Guo-Fu Tseng [Sat, 5 Mar 2016 00:11:56 +0000 (08:11 +0800)]
jme: Fix device PM wakeup API usage

commit 81422e672f8181d7ad1ee6c60c723aac649f538f upstream.

According to Documentation/power/devices.txt

The driver should not use device_set_wakeup_enable() which is the policy
for user to decide.

Using device_init_wakeup() to initialize dev->power.should_wakeup and
dev->power.can_wakeup on driver initialization.

And use device_may_wakeup() on suspend to decide if WoL function should
be enabled on NIC.

Reported-by: Diego Viola <diego.viola@gmail.com>
Signed-off-by: Guo-Fu Tseng <cooldavid@cooldavid.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
5 years agojme: Do not enable NIC WoL functions on S0
Guo-Fu Tseng [Sat, 5 Mar 2016 00:11:55 +0000 (08:11 +0800)]
jme: Do not enable NIC WoL functions on S0

commit 0772a99b818079e628a1da122ac7ee023faed83e upstream.

Otherwise it might be back on resume right after going to suspend in
some hardware.

Reported-by: Diego Viola <diego.viola@gmail.com>
Signed-off-by: Guo-Fu Tseng <cooldavid@cooldavid.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
5 years agoipv6: Count in extension headers in skb->network_header
Jakub Sitnicki [Tue, 5 Apr 2016 16:41:08 +0000 (18:41 +0200)]
ipv6: Count in extension headers in skb->network_header

[ Upstream commit 3ba3458fb9c050718b95275a3310b74415e767e2 ]

When sending a UDPv6 message longer than MTU, account for the length
of fragmentable IPv6 extension headers in skb->network_header offset.
Same as we do in alloc_new_skb path in __ip6_append_data().

This ensures that later on __ip6_make_skb() will make space in
headroom for fragmentable extension headers:

/* move skb->data to ip header from ext header */
if (skb->data < skb_network_header(skb))
__skb_pull(skb, skb_network_offset(skb));

Prevents a splat due to skb_under_panic:

skbuff: skb_under_panic: text:ffffffff8143397b len:2126 put:14 \
head:ffff880005bacf50 data:ffff880005bacf4a tail:0x48 end:0xc0 dev:lo
------------[ cut here ]------------
kernel BUG at net/core/skbuff.c:104!
invalid opcode: 0000 [#1] KASAN
CPU: 0 PID: 160 Comm: reproducer Not tainted 4.6.0-rc2 #65
[...]
Call Trace:
 [<ffffffff813eb7b9>] skb_push+0x79/0x80
 [<ffffffff8143397b>] eth_header+0x2b/0x100
 [<ffffffff8141e0d0>] neigh_resolve_output+0x210/0x310
 [<ffffffff814eab77>] ip6_finish_output2+0x4a7/0x7c0
 [<ffffffff814efe3a>] ip6_output+0x16a/0x280
 [<ffffffff815440c1>] ip6_local_out+0xb1/0xf0
 [<ffffffff814f1115>] ip6_send_skb+0x45/0xd0
 [<ffffffff81518836>] udp_v6_send_skb+0x246/0x5d0
 [<ffffffff8151985e>] udpv6_sendmsg+0xa6e/0x1090
[...]

Reported-by: Ji Jianwen <jiji@redhat.com>
Signed-off-by: Jakub Sitnicki <jkbs@redhat.com>
Acked-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
5 years agoipv4: l2tp: fix a potential issue in l2tp_ip_recv
Haishuang Yan [Sun, 3 Apr 2016 14:09:23 +0000 (22:09 +0800)]
ipv4: l2tp: fix a potential issue in l2tp_ip_recv

[ Upstream commit 5745b8232e942abd5e16e85fa9b27cc21324acf0 ]

pskb_may_pull() can change skb->data, so we have to load ptr/optr at the
right place.

Signed-off-by: Haishuang Yan <yanhaishuang@cmss.chinamobile.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
5 years agoxfrm: Fix crash observed during device unregistration and decryption
subashab@codeaurora.org [Thu, 24 Mar 2016 04:39:50 +0000 (22:39 -0600)]
xfrm: Fix crash observed during device unregistration and decryption

[ Upstream commit 071d36bf21bcc837be00cea55bcef8d129e7f609 ]

A crash is observed when a decrypted packet is processed in receive
path. get_rps_cpus() tries to dereference the skb->dev fields but it
appears that the device is freed from the poison pattern.

[<ffffffc000af58ec>] get_rps_cpu+0x94/0x2f0
[<ffffffc000af5f94>] netif_rx_internal+0x140/0x1cc
[<ffffffc000af6094>] netif_rx+0x74/0x94
[<ffffffc000bc0b6c>] xfrm_input+0x754/0x7d0
[<ffffffc000bc0bf8>] xfrm_input_resume+0x10/0x1c
[<ffffffc000ba6eb8>] esp_input_done+0x20/0x30
[<ffffffc0000b64c8>] process_one_work+0x244/0x3fc
[<ffffffc0000b7324>] worker_thread+0x2f8/0x418
[<ffffffc0000bb40c>] kthread+0xe0/0xec

-013|get_rps_cpu(
     |    dev = 0xFFFFFFC08B688000,
     |    skb = 0xFFFFFFC0C76AAC00 -> (
     |      dev = 0xFFFFFFC08B688000 -> (
     |        name =
"......................................................
     |        name_hlist = (next = 0xAAAAAAAAAAAAAAAA, pprev =
0xAAAAAAAAAAA

Following are the sequence of events observed -

- Encrypted packet in receive path from netdevice is queued
- Encrypted packet queued for decryption (asynchronous)
- Netdevice brought down and freed
- Packet is decrypted and returned through callback in esp_input_done
- Packet is queued again for process in network stack using netif_rx

Since the device appears to have been freed, the dereference of
skb->dev in get_rps_cpus() leads to an unhandled page fault
exception.

Fix this by holding on to device reference when queueing packets
asynchronously and releasing the reference on call back return.

v2: Make the change generic to xfrm as mentioned by Steffen and
update the title to xfrm

Suggested-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Jerome Stanislaus <jeromes@codeaurora.org>
Signed-off-by: Subash Abhinov Kasiviswanathan <subashab@codeaurora.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
5 years agoqlge: Fix receive packets drop.
Manish Chopra [Tue, 15 Mar 2016 11:13:45 +0000 (07:13 -0400)]
qlge: Fix receive packets drop.

[ Upstream commit 2c9a266afefe137bff06bbe0fc48b4d3b3cb348c ]

When running small packets [length < 256 bytes] traffic, packets were
being dropped due to invalid data in those packets which were
delivered by the driver upto the stack. Using pci_dma_sync_single_for_cpu
ensures copying latest and updated data into skb from the receive buffer.

Signed-off-by: Sony Chacko <sony.chacko@qlogic.com>
Signed-off-by: Manish Chopra <manish.chopra@qlogic.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
5 years agofarsync: fix off-by-one bug in fst_add_one
Arnd Bergmann [Mon, 14 Mar 2016 14:18:35 +0000 (15:18 +0100)]
farsync: fix off-by-one bug in fst_add_one

[ Upstream commit e725a66c0202b5f36c2f9d59d26a65c53bbf21f7 ]

gcc-6 finds an out of bounds access in the fst_add_one function
when calculating the end of the mmio area:

drivers/net/wan/farsync.c: In function 'fst_add_one':
drivers/net/wan/farsync.c:418:53: error: index 2 denotes an offset greater than size of 'u8[2][8192] {aka unsigned char[2][8192]}' [-Werror=array-bounds]
 #define BUF_OFFSET(X)   (BFM_BASE + offsetof(struct buf_window, X))
                                                     ^
include/linux/compiler-gcc.h:158:21: note: in definition of macro '__compiler_offsetof'
  __builtin_offsetof(a, b)
                     ^
drivers/net/wan/farsync.c:418:37: note: in expansion of macro 'offsetof'
 #define BUF_OFFSET(X)   (BFM_BASE + offsetof(struct buf_window, X))
                                     ^~~~~~~~
drivers/net/wan/farsync.c:2519:36: note: in expansion of macro 'BUF_OFFSET'
                                  + BUF_OFFSET ( txBuffer[i][NUM_TX_BUFFER][0]);
                                    ^~~~~~~~~~

The warning is correct, but not critical because this appears
to be a write-only variable that is set by each WAN driver but
never accessed afterwards.

I'm taking the minimal fix here, using the correct pointer by
pointing 'mem_end' to the last byte inside of the register area
as all other WAN drivers do, rather than the first byte outside of
it. An alternative would be to just remove the mem_end member
entirely.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>