]> git.proxmox.com Git - mirror_ubuntu-artful-kernel.git/log
mirror_ubuntu-artful-kernel.git
7 years agopowerpc/xmon: Fix data-breakpoint
Ravi Bangoria [Tue, 22 Nov 2016 09:25:59 +0000 (14:55 +0530)]
powerpc/xmon: Fix data-breakpoint

BugLink: http://bugs.launchpad.net/bugs/1672544
commit c21a493a2b44650707d06741601894329486f2ad upstream.

Currently xmon data-breakpoint feature is broken.

Whenever there is a watchpoint match occurs, hw_breakpoint_handler will
be called by do_break via notifier chains mechanism. If watchpoint is
registered by xmon, hw_breakpoint_handler won't find any associated
perf_event and returns immediately with NOTIFY_STOP. Similarly, do_break
also returns without notifying to xmon.

Solve this by returning NOTIFY_DONE when hw_breakpoint_handler does not
find any perf_event associated with matched watchpoint, rather than
NOTIFY_STOP, which tells the core code to continue calling the other
breakpoint handlers including the xmon one.

Signed-off-by: Ravi Bangoria <ravi.bangoria@linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
7 years agoxprtrdma: Reduce required number of send SGEs
Chuck Lever [Wed, 8 Feb 2017 22:00:10 +0000 (17:00 -0500)]
xprtrdma: Reduce required number of send SGEs

BugLink: http://bugs.launchpad.net/bugs/1672544
commit 16f906d66cd76fb9895cbc628f447532a7ac1faa upstream.

The MAX_SEND_SGES check introduced in commit 655fec6987be
("xprtrdma: Use gathered Send for large inline messages") fails
for devices that have a small max_sge.

Instead of checking for a large fixed maximum number of SGEs,
check for a minimum small number. RPC-over-RDMA will switch to
using a Read chunk if an xdr_buf has more pages than can fit in
the device's max_sge limit. This is considerably better than
failing all together to mount the server.

This fix supports devices that have as few as three send SGEs
available.

Reported-by: Selvin Xavier <selvin.xavier@broadcom.com>
Reported-by: Devesh Sharma <devesh.sharma@broadcom.com>
Reported-by: Honggang Li <honli@redhat.com>
Reported-by: Ram Amrani <Ram.Amrani@cavium.com>
Fixes: 655fec6987be ("xprtrdma: Use gathered Send for large ...")
Tested-by: Honggang Li <honli@redhat.com>
Tested-by: Ram Amrani <Ram.Amrani@cavium.com>
Tested-by: Steve Wise <swise@opengridcomputing.com>
Reviewed-by: Parav Pandit <parav@mellanox.com>
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
7 years agoxprtrdma: Disable pad optimization by default
Chuck Lever [Wed, 8 Feb 2017 22:00:02 +0000 (17:00 -0500)]
xprtrdma: Disable pad optimization by default

BugLink: http://bugs.launchpad.net/bugs/1672544
commit c95a3c6b88658bcb8f77f85f31a0b9d9036e8016 upstream.

Commit d5440e27d3e5 ("xprtrdma: Enable pad optimization") made the
Linux client omit XDR round-up padding in normal Read and Write
chunks so that the client doesn't have to register and invalidate
3-byte memory regions that contain no real data.

Unfortunately, my cheery 2014 assessment that this optimization "is
supported now by both Linux and Solaris servers" was premature.
We've found bugs in Solaris in this area since commit d5440e27d3e5
("xprtrdma: Enable pad optimization") was merged (SYMLINK is the
main offender).

So for maximum interoperability, I'm disabling this optimization
again. If a CM private message is exchanged when connecting, the
client recognizes that the server is Linux, and enables the
optimization for that connection.

Until now the Solaris server bugs did not impact common operations,
and were thus largely benign. Soon, less capable devices on Linux
NFS/RDMA clients will make use of Read chunks more often, and these
Solaris bugs will prevent interoperation in more cases.

Fixes: 677eb17e94ed ("xprtrdma: Fix XDR tail buffer marshalling")
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
7 years agoxprtrdma: Per-connection pad optimization
Chuck Lever [Wed, 8 Feb 2017 21:59:54 +0000 (16:59 -0500)]
xprtrdma: Per-connection pad optimization

BugLink: http://bugs.launchpad.net/bugs/1672544
commit b5f0afbea4f2ea52c613ac2b06cb6de2ea18cb6d upstream.

Pad optimization is changed by echoing into
/proc/sys/sunrpc/rdma_pad_optimize. This is a global setting,
affecting all RPC-over-RDMA connections to all servers.

The marshaling code picks up that value and uses it for decisions
about how to construct each RPC-over-RDMA frame. Having it change
suddenly in mid-operation can result in unexpected failures. And
some servers a client mounts might need chunk round-up, while
others don't.

So instead, copy the pad_optimize setting into each connection's
rpcrdma_ia when the transport is created, and use the copy, which
can't change during the life of the connection, instead.

This also removes a hack: rpcrdma_convert_iovs was using
the remote-invalidation-expected flag to predict when it could leave
out Write chunk padding. This is because the Linux server handles
implicit XDR padding on Write chunks correctly, and only Linux
servers can set the connection's remote-invalidation-expected flag.

It's more sensible to use the pad optimization setting instead.

Fixes: 677eb17e94ed ("xprtrdma: Fix XDR tail buffer marshalling")
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
7 years agoxprtrdma: Fix Read chunk padding
Chuck Lever [Wed, 8 Feb 2017 21:59:46 +0000 (16:59 -0500)]
xprtrdma: Fix Read chunk padding

BugLink: http://bugs.launchpad.net/bugs/1672544
commit 24abdf1be15c478e2821d6fc903a4a4440beff02 upstream.

When pad optimization is disabled, rpcrdma_convert_iovs still
does not add explicit XDR round-up padding to a Read chunk.

Commit 677eb17e94ed ("xprtrdma: Fix XDR tail buffer marshalling")
incorrectly short-circuited the test for whether round-up padding
is needed that appears later in rpcrdma_convert_iovs.

However, if this is indeed a regular Read chunk (and not a
Position-Zero Read chunk), the tail iovec _always_ contains the
chunk's padding, and never anything else.

So, it's easy to just skip the tail when padding optimization is
enabled, and add the tail in a subsequent Read chunk segment, if
disabled.

Fixes: 677eb17e94ed ("xprtrdma: Fix XDR tail buffer marshalling")
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
7 years agodmaengine: ipu: Make sure the interrupt routine checks all interrupts.
Magnus Lilja [Wed, 21 Dec 2016 21:13:58 +0000 (22:13 +0100)]
dmaengine: ipu: Make sure the interrupt routine checks all interrupts.

BugLink: http://bugs.launchpad.net/bugs/1672544
commit adee40b265d7568296e218f079f478197ffa15bf upstream.

Commit 3d8cc00073d6 ("dmaengine: ipu: Consolidate duplicated irq handlers")
consolidated the two interrupts routines into one, but the remaining
interrupt routine only checks the status of the error interrupts, not the
normal interrupts.

This patch fixes that problem (tested on i.MX31 PDK board).

Fixes: 3d8cc00073d6 ("dmaengine: ipu: Consolidate duplicated irq handlers")
Cc: Vinod Koul <vinod.koul@intel.com>
Signed-off-by: Magnus Lilja <lilja.magnus@gmail.com>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
7 years agomtd: nand: ifc: Fix location of eccstat registers for IFC V1.0
Mark Marshall [Thu, 26 Jan 2017 15:18:27 +0000 (16:18 +0100)]
mtd: nand: ifc: Fix location of eccstat registers for IFC V1.0

BugLink: http://bugs.launchpad.net/bugs/1672544
commit 656441478ed55d960df5f3ccdf5a0f8c61dfd0b3 upstream.

The commit 7a654172161c ("mtd/ifc: Add support for IFC controller
version 2.0") added support for version 2.0 of the IFC controller.
The version 2.0 controller has the ECC status registers at a different
location to the previous versions.

Correct the fsl_ifc_nand structure so that the ECC status can be read
from the correct location for both version 1.0 and 2.0 of the controller.

Fixes: 7a654172161c ("mtd/ifc: Add support for IFC controller version 2.0")
Signed-off-by: Mark Marshall <mark.marshall@omicronenergy.com>
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
7 years agobcma: use (get|put)_device when probing/removing device driver
Rafał Miłecki [Sat, 28 Jan 2017 13:31:22 +0000 (14:31 +0100)]
bcma: use (get|put)_device when probing/removing device driver

BugLink: http://bugs.launchpad.net/bugs/1672544
commit a971df0b9d04674e325346c17de9a895425ca5e1 upstream.

This allows tracking device state and e.g. makes devm work as expected.

Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
7 years agomd linear: fix a race between linear_add() and linear_congested()
colyli@suse.de [Sat, 28 Jan 2017 13:11:49 +0000 (21:11 +0800)]
md linear: fix a race between linear_add() and linear_congested()

BugLink: http://bugs.launchpad.net/bugs/1672544
commit 03a9e24ef2aaa5f1f9837356aed79c860521407a upstream.

Recently I receive a bug report that on Linux v3.0 based kerenl, hot add
disk to a md linear device causes kernel crash at linear_congested(). From
the crash image analysis, I find in linear_congested(), mddev->raid_disks
contains value N, but conf->disks[] only has N-1 pointers available. Then
a NULL pointer deference crashes the kernel.

There is a race between linear_add() and linear_congested(), RCU stuffs
used in these two functions cannot avoid the race. Since Linuv v4.0
RCU code is replaced by introducing mddev_suspend().  After checking the
upstream code, it seems linear_congested() is not called in
generic_make_request() code patch, so mddev_suspend() cannot provent it
from being called. The possible race still exists.

Here I explain how the race still exists in current code.  For a machine
has many CPUs, on one CPU, linear_add() is called to add a hard disk to a
md linear device; at the same time on other CPU, linear_congested() is
called to detect whether this md linear device is congested before issuing
an I/O request onto it.

Now I use a possible code execution time sequence to demo how the possible
race happens,

seq    linear_add()                linear_congested()
 0                                 conf=mddev->private
 1   oldconf=mddev->private
 2   mddev->raid_disks++
 3                              for (i=0; i<mddev->raid_disks;i++)
 4                                bdev_get_queue(conf->disks[i].rdev->bdev)
 5   mddev->private=newconf

In linear_add() mddev->raid_disks is increased in time seq 2, and on
another CPU in linear_congested() the for-loop iterates conf->disks[i] by
the increased mddev->raid_disks in time seq 3,4. But conf with one more
element (which is a pointer to struct dev_info type) to conf->disks[] is
not updated yet, accessing its structure member in time seq 4 will cause a
NULL pointer deference fault.

To fix this race, there are 2 parts of modification in the patch,
 1) Add 'int raid_disks' in struct linear_conf, as a copy of
    mddev->raid_disks. It is initialized in linear_conf(), always being
    consistent with pointers number of 'struct dev_info disks[]'. When
    iterating conf->disks[] in linear_congested(), use conf->raid_disks to
    replace mddev->raid_disks in the for-loop, then NULL pointer deference
    will not happen again.
 2) RCU stuffs are back again, and use kfree_rcu() in linear_add() to
    free oldconf memory. Because oldconf may be referenced as mddev->private
    in linear_congested(), kfree_rcu() makes sure that its memory will not
    be released until no one uses it any more.
Also some code comments are added in this patch, to make this modification
to be easier understandable.

This patch can be applied for kernels since v4.0 after commit:
3be260cc18f8 ("md/linear: remove rcu protections in favour of
suspend/resume"). But this bug is reported on Linux v3.0 based kernel, for
people who maintain kernels before Linux v4.0, they need to do some back
back port to this patch.

Changelog:
 - V3: add 'int raid_disks' in struct linear_conf, and use kfree_rcu() to
       replace rcu_call() in linear_add().
 - v2: add RCU stuffs by suggestion from Shaohua and Neil.
 - v1: initial effort.

Signed-off-by: Coly Li <colyli@suse.de>
Cc: Shaohua Li <shli@fb.com>
Cc: Neil Brown <neilb@suse.com>
Signed-off-by: Shaohua Li <shli@fb.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
7 years agortc: sun6i: Switch to the external oscillator
Maxime Ripard [Mon, 23 Jan 2017 10:41:48 +0000 (11:41 +0100)]
rtc: sun6i: Switch to the external oscillator

BugLink: http://bugs.launchpad.net/bugs/1672544
commit fb61bb82cb46a932ef2fc62e1c731c8e7e6640d5 upstream.

The RTC is clocked from either an internal, imprecise, oscillator or an
external one, which is usually much more accurate.

The difference perceived between the time elapsed and the time reported by
the RTC is in a 10% scale, which prevents the RTC from being useful at all.

Fortunately, the external oscillator is reported to be mandatory in the
Allwinner datasheet, so we can just switch to it.

Fixes: 9765d2d94309 ("rtc: sun6i: Add sun6i RTC driver")
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
7 years agortc: sun6i: Add some locking
Maxime Ripard [Mon, 23 Jan 2017 10:41:47 +0000 (11:41 +0100)]
rtc: sun6i: Add some locking

BugLink: http://bugs.launchpad.net/bugs/1672544
commit a9422a19ce270a22fc520f2278fb7e80c58be508 upstream.

Some registers have a read-modify-write access pattern that are not atomic.

Add some locking to prevent from concurrent accesses.

Acked-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
7 years agortc: sun6i: Disable the build as a module
Maxime Ripard [Mon, 23 Jan 2017 10:41:46 +0000 (11:41 +0100)]
rtc: sun6i: Disable the build as a module

BugLink: http://bugs.launchpad.net/bugs/1672544
commit 3753941475ae6501dcd1e41832bd0e6c35247d6a upstream.

Since we have to provide the clock very early on, the RTC driver cannot be
built as a module. Make sure that won't happen.

Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
7 years agof2fs: Fix zoned block device support
Masato Suzuki [Mon, 27 Feb 2017 11:52:49 +0000 (20:52 +0900)]
f2fs: Fix zoned block device support

BugLink: http://bugs.launchpad.net/bugs/1672544
commit 7bb3a371d199156cb6a863feab377146b80942c5 upstream.

The introduction of the multi-device feature partially broke the support
for zoned block devices. In the function f2fs_scan_devices, sbi->devs
allocation and initialization is skipped in the case of a single device
mount. This result in no device information structure being allocated
for the device. This is fine if the device is a regular device, but in
the case of a zoned block device, the device zone type array is not
initialized, which causes the function __f2fs_issue_discard_zone to fail
as get_blkz_type is unable to determine the zone type of a section.

Fix this by always allocating and initializing the sbi->devs device
information array even in the case of a single device if that device is
zoned. For this particular case, make sure to obtain a reference on the
single device so that the call to blkdev_put() in destroy_device_list
operates as expected.

Fixes: 3c62be17d4f562f4 ("f2fs: support multiple devices")
Signed-off-by: Masato Suzuki <masato.suzuki@wdc.com>
Acked-by: Damien Le Moal <damien.lemoal@wdc.com>
Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
7 years agof2fs: avoid to issue redundant discard commands
Jaegeuk Kim [Mon, 27 Feb 2017 19:57:11 +0000 (11:57 -0800)]
f2fs: avoid to issue redundant discard commands

BugLink: http://bugs.launchpad.net/bugs/1672544
commit 8b107f5b97772c7c0c218302e9a4d15b4edf50b4 upstream.

If segs_per_sec is over 1 like under SMR, previously f2fs issues discard
commands redundantly on the same section, since we didn't move end position
for the previous discard command.

E.g.,

                       start  end
                         |    |
      prefree_bitmap = [01111100111100]

And, after issue discard for this section,
                             end      start
                              |        |
      prefree_bitmap = [01111100111100]

Select this section again by searching from (end + 1),
                             start  end
                                |   |
      prefree_bitmap = [01111100111100]

Fixes: 36abef4e796d38 ("f2fs: introduce mode=lfs mount option")
Cc: Damien Le Moal <damien.lemoal@wdc.com>
Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
7 years agof2fs: add ovp valid_blocks check for bg gc victim to fg_gc
Hou Pengyang [Thu, 16 Feb 2017 12:34:31 +0000 (12:34 +0000)]
f2fs: add ovp valid_blocks check for bg gc victim to fg_gc

BugLink: http://bugs.launchpad.net/bugs/1672544
commit e93b9865251a0503d83fd570e7d5a7c8bc351715 upstream.

For foreground gc, greedy algorithm should be adapted, which makes
this formula work well:

(2 * (100 / config.overprovision + 1) + 6)

But currently, we fg_gc have a prior to select bg_gc victim segments to gc
first, these victims are selected by cost-benefit algorithm, we can't guarantee
such segments have the small valid blocks, which may destroy the f2fs rule, on
the worstest case, would consume all the free segments.

This patch fix this by add a filter in check_bg_victims, if segment's has # of
valid blocks over overprovision ratio, skip such segments.

Signed-off-by: Hou Pengyang <houpengyang@huawei.com>
Reviewed-by: Chao Yu <yuchao0@huawei.com>
Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
7 years agof2fs: fix multiple f2fs_add_link() calls having same name
Jaegeuk Kim [Tue, 14 Feb 2017 17:54:37 +0000 (09:54 -0800)]
f2fs: fix multiple f2fs_add_link() calls having same name

BugLink: http://bugs.launchpad.net/bugs/1672544
commit 88c5c13a5027b36d914536fdba23f069d7067204 upstream.

It turns out a stakable filesystem like sdcardfs in AOSP can trigger multiple
vfs_create() to lower filesystem. In that case, f2fs will add multiple dentries
having same name which breaks filesystem consistency.

Until upper layer fixes, let's work around by f2fs, which shows actually not
much performance regression.

Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
7 years agof2fs: fix a problem of using memory after free
Yunlei He [Mon, 19 Dec 2016 12:10:48 +0000 (20:10 +0800)]
f2fs: fix a problem of using memory after free

BugLink: http://bugs.launchpad.net/bugs/1672544
commit 7855eba4d6102f811b6dd142d6c749f53b591fa3 upstream.

This patch fix a problem of using memory after free
in function __try_merge_extent_node.

Fixes: 0f825ee6e873 ("f2fs: add new interfaces for extent tree")
Signed-off-by: Yunlei He <heyunlei@huawei.com>
Reviewed-by: Chao Yu <yuchao0@huawei.com>
Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
7 years agoNFSv4: fix getacl ERANGE for some ACL buffer sizes
Weston Andros Adamson [Thu, 23 Feb 2017 19:54:21 +0000 (14:54 -0500)]
NFSv4: fix getacl ERANGE for some ACL buffer sizes

BugLink: http://bugs.launchpad.net/bugs/1672544
commit ed92d8c137b7794c2c2aa14479298b9885967607 upstream.

We're not taking into account that the space needed for the (variable
length) attr bitmap, with the result that we'd sometimes get a spurious
ERANGE when the ACL data got close to the end of a page.

Just add in an extra page to make sure.

Signed-off-by: Weston Andros Adamson <dros@primarydata.com>
Signed-off-by: J. Bruce Fields <bfields@redhat.com>
Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
7 years agoNFSv4: fix getacl head length estimation
J. Bruce Fields [Thu, 23 Feb 2017 19:53:39 +0000 (14:53 -0500)]
NFSv4: fix getacl head length estimation

BugLink: http://bugs.launchpad.net/bugs/1672544
commit 6682c14bbe505a8b912c57faf544f866777ee48d upstream.

Bitmap and attrlen follow immediately after the op reply header.  This
was an oversight from commit bf118a342f.

Consequences of this are just minor efficiency (extra calls to
xdr_shrink_bufhead).

Fixes: bf118a342f10 "NFSv4: include bitmap in nfsv4 get acl data"
Reviewed-by: Kinglong Mee <kinglongmee@gmail.com>
Signed-off-by: J. Bruce Fields <bfields@redhat.com>
Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
7 years agoRevert "NFSv4.1: Handle NFS4ERR_BADSESSION/NFS4ERR_DEADSESSION replies to OP_SEQUENCE"
Trond Myklebust [Sat, 18 Feb 2017 00:50:18 +0000 (19:50 -0500)]
Revert "NFSv4.1: Handle NFS4ERR_BADSESSION/NFS4ERR_DEADSESSION replies to OP_SEQUENCE"

BugLink: http://bugs.launchpad.net/bugs/1672544
commit a5e14c9376871ee74fe93fdcb380c5d54eaa2d43 upstream.

This reverts commit 2cf10cdd486c362f983abdce00dc1127e8ab8c59.

The patch has been seen to cause excessive looping.

Reported-by: Olga Kornievskaia <aglo@umich.edu>
Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
7 years agopNFS/flexfiles: If the layout is invalid, it must be updated before retrying
Trond Myklebust [Sat, 18 Feb 2017 00:49:09 +0000 (19:49 -0500)]
pNFS/flexfiles: If the layout is invalid, it must be updated before retrying

BugLink: http://bugs.launchpad.net/bugs/1672544
commit df3ab232e462bce20710596d697ade6b72497694 upstream.

If we see that our pNFS READ/WRITE/COMMIT operation failed, but we
also see that our layout segment is no longer valid, then we need to
get a new layout segment before retrying.

Fixes: 90816d1ddacf ("NFSv4.1/flexfiles: Don't mark the entire deviceid...")
Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
7 years agoNFSv4: Fix reboot recovery in copy offload
Trond Myklebust [Fri, 17 Feb 2017 23:42:32 +0000 (18:42 -0500)]
NFSv4: Fix reboot recovery in copy offload

BugLink: http://bugs.launchpad.net/bugs/1672544
commit 9d8cacbf5636657d2cd0dda17438a56d806d3224 upstream.

Copy offload code needs to be hooked into the code for handling
NFS4ERR_BAD_STATEID by ensuring that we set the "stateid" field
in struct nfs4_exception.

Reported-by: Olga Kornievskaia <aglo@umich.edu>
Fixes: 2e72448b07dc3 ("NFS: Add COPY nfs operation")
Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
7 years agoNFSv4: Fix memory and state leak in _nfs4_open_and_get_state
Trond Myklebust [Wed, 8 Feb 2017 16:29:46 +0000 (11:29 -0500)]
NFSv4: Fix memory and state leak in _nfs4_open_and_get_state

BugLink: http://bugs.launchpad.net/bugs/1672544
commit a974deee477af89411e0f80456bfb344ac433c98 upstream.

If we exit because the file access check failed, we currently
leak the struct nfs4_state. We need to attach it to the
open context before returning.

Fixes: 3efb9722475e ("NFSv4: Refactor _nfs4_open_and_get_state..")
Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
7 years agonfsd: special case truncates some more
Christoph Hellwig [Mon, 20 Feb 2017 06:21:33 +0000 (07:21 +0100)]
nfsd: special case truncates some more

BugLink: http://bugs.launchpad.net/bugs/1672544
commit 783112f7401ff449d979530209b3f6c2594fdb4e upstream.

Both the NFS protocols and the Linux VFS use a setattr operation with a
bitmap of attributes to set to set various file attributes including the
file size and the uid/gid.

The Linux syscalls never mix size updates with unrelated updates like
the uid/gid, and some file systems like XFS and GFS2 rely on the fact
that truncates don't update random other attributes, and many other file
systems handle the case but do not update the other attributes in the
same transaction.  NFSD on the other hand passes the attributes it gets
on the wire more or less directly through to the VFS, leading to updates
the file systems don't expect.  XFS at least has an assert on the
allowed attributes, which caught an unusual NFS client setting the size
and group at the same time.

To handle this issue properly this splits the notify_change call in
nfsd_setattr into two separate ones.

Signed-off-by: Christoph Hellwig <hch@lst.de>
Tested-by: Chuck Lever <chuck.lever@oracle.com>
Signed-off-by: J. Bruce Fields <bfields@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
7 years agonfsd: minor nfsd_setattr cleanup
Christoph Hellwig [Mon, 20 Feb 2017 22:04:42 +0000 (17:04 -0500)]
nfsd: minor nfsd_setattr cleanup

BugLink: http://bugs.launchpad.net/bugs/1672544
commit 758e99fefe1d9230111296956335cd35995c0eaf upstream.

Simplify exit paths, size_change use.

Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: J. Bruce Fields <bfields@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
7 years agoVME: restore bus_remove function causing incomplete module unload
Stefano Babic [Fri, 20 Jan 2017 15:38:20 +0000 (10:38 -0500)]
VME: restore bus_remove function causing incomplete module unload

BugLink: http://bugs.launchpad.net/bugs/1672544
commit 9797484ba83d68f18fe1cbd964b7cd830f78f0f7 upstream.

Commit 050c3d52cc7810d9d17b8cd231708609af6876ae ("vme: make core
vme support explicitly non-modular") dropped the remove function
because it appeared as if it was for removal of the bus, which is
not supported.

However, vme_bus_remove() is called when a VME device is removed
from the bus and not when the bus is removed; as it calls the VME
device driver's cleanup function.  Without this function, the
remove() in the VME device driver is never called and VME device
drivers cannot be reloaded again.

Here we restore the remove function that was deleted in that
commit, and the reference to the function in the bus structure.

Fixes: 050c3d52cc78 ("vme: make core vme support explicitly non-modular")
Cc: Manohar Vanga <manohar.vanga@gmail.com>
Acked-by: Martyn Welch <martyn@welchs.me.uk>
Cc: devel@driverdev.osuosl.org
Signed-off-by: Stefano Babic <sbabic@denx.de>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
7 years agortlwifi: rtl8192c-common: Fix "BUG: KASAN:
Larry Finger [Sun, 5 Feb 2017 16:24:22 +0000 (10:24 -0600)]
rtlwifi: rtl8192c-common: Fix "BUG: KASAN:

BugLink: http://bugs.launchpad.net/bugs/1672544
commit 6773386f977ce5af339f9678fa2918909a946c6b upstream.

Kernels built with CONFIG_KASAN=y report the following BUG for rtl8192cu
and rtl8192c-common:

==================================================================
BUG: KASAN: slab-out-of-bounds in rtl92c_dm_bt_coexist+0x858/0x1e40
     [rtl8192c_common] at addr ffff8801c90edb08
Read of size 1 by task kworker/0:1/38
page:ffffea0007243800 count:1 mapcount:0 mapping:          (null)
     index:0x0 compound_mapcount: 0
flags: 0x8000000000004000(head)
page dumped because: kasan: bad access detected
CPU: 0 PID: 38 Comm: kworker/0:1 Not tainted 4.9.7-gentoo #3
Hardware name: Gigabyte Technology Co., Ltd. To be filled by
     O.E.M./Z77-DS3H, BIOS F11a 11/13/2013
Workqueue: rtl92c_usb rtl_watchdog_wq_callback [rtlwifi]
  0000000000000000 ffffffff829eea33 ffff8801d7f0fa30 ffff8801c90edb08
  ffffffff824c0f09 ffff8801d4abee80 0000000000000004 0000000000000297
  ffffffffc070b57c ffff8801c7aa7c48 ffff880100000004 ffffffff000003e8
Call Trace:
  [<ffffffff829eea33>] ? dump_stack+0x5c/0x79
  [<ffffffff824c0f09>] ? kasan_report_error+0x4b9/0x4e0
  [<ffffffffc070b57c>] ? _usb_read_sync+0x15c/0x280 [rtl_usb]
  [<ffffffff824c0f75>] ? __asan_report_load1_noabort+0x45/0x50
  [<ffffffffc06d7a88>] ? rtl92c_dm_bt_coexist+0x858/0x1e40 [rtl8192c_common]
  [<ffffffffc06d7a88>] ? rtl92c_dm_bt_coexist+0x858/0x1e40 [rtl8192c_common]
  [<ffffffffc06d0cbe>] ? rtl92c_dm_rf_saving+0x96e/0x1330 [rtl8192c_common]
...

The problem is due to rtl8192ce and rtl8192cu sharing routines, and having
different layouts of struct rtl_pci_priv, which is used by rtl8192ce, and
struct rtl_usb_priv, which is used by rtl8192cu. The problem was resolved
by placing the struct bt_coexist_info at the head of each of those private
areas.

Reported-and-tested-by: Dmitry Osipenko <digetx@gmail.com>
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Cc: Dmitry Osipenko <digetx@gmail.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
7 years agortlwifi: Fix alignment issues
Ping-Ke Shih [Wed, 28 Dec 2016 21:40:04 +0000 (15:40 -0600)]
rtlwifi: Fix alignment issues

BugLink: http://bugs.launchpad.net/bugs/1672544
commit 40b368af4b750863b2cb66a3a9513241db2f0793 upstream.

The addresses of Wlan NIC registers are natural alignment, but some
drivers have bugs. These are evident on platforms that need natural
alignment to access registers.  This change contains the following:
 1. Function _rtl8821ae_dbi_read() is used to read one byte from DBI,
    thus it should use rtl_read_byte().
 2. Register 0x4C7 of 8192ee is single byte.

Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
7 years agoremoteproc: qcom: mdt_loader: Don't overwrite firmware object
Bjorn Andersson [Fri, 27 Jan 2017 10:06:36 +0000 (02:06 -0800)]
remoteproc: qcom: mdt_loader: Don't overwrite firmware object

BugLink: http://bugs.launchpad.net/bugs/1672544
commit 3e8b571a9a0881ba3381ca0915995696da145ab8 upstream.

The "fw" firmware object is passed from the remoteproc core and should
not be overwritten, as that results in leaked buffers and a double free
of the the last firmware object.

Fixes: 051fb70fd4ea ("remoteproc: qcom: Driver for the self-authenticating Hexagon v5")
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
7 years agogfs2: Add missing rcu locking for glock lookup
Andrew Price [Wed, 22 Feb 2017 17:05:03 +0000 (12:05 -0500)]
gfs2: Add missing rcu locking for glock lookup

BugLink: http://bugs.launchpad.net/bugs/1672544
commit f38e5fb95a1f8feda88531eedc98f69b24748712 upstream.

We must hold the rcu read lock across looking up glocks and trying to
bump their refcount to prevent the glocks from being freed in between.

Signed-off-by: Andrew Price <anprice@redhat.com>
Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com>
Signed-off-by: Bob Peterson <rpeterso@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
7 years agordma_cm: fail iwarp accepts w/o connection params
Steve Wise [Tue, 21 Feb 2017 19:21:57 +0000 (11:21 -0800)]
rdma_cm: fail iwarp accepts w/o connection params

BugLink: http://bugs.launchpad.net/bugs/1672544
commit f2625f7db4dd0bbd16a9c7d2950e7621f9aa57ad upstream.

cma_accept_iw() needs to return an error if conn_params is NULL.
Since this is coming from user space, we can crash.

Reported-by: Shaobo He <shaobo@cs.utah.edu>
Acked-by: Sean Hefty <sean.hefty@intel.com>
Signed-off-by: Steve Wise <swise@opengridcomputing.com>
Signed-off-by: Doug Ledford <dledford@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
7 years agoRDMA/core: Fix incorrect structure packing for booleans
Jason Gunthorpe [Fri, 23 Dec 2016 01:07:52 +0000 (18:07 -0700)]
RDMA/core: Fix incorrect structure packing for booleans

BugLink: http://bugs.launchpad.net/bugs/1672544
commit 55efcfcd7776165b294f8b5cd6e05ca00ec89b7c upstream.

The RDMA core uses ib_pack() to convert from unpacked CPU structs
to on-the-wire bitpacked structs.

This process requires that 1 bit fields are declared as u8 in the
unpacked struct, otherwise the packing process does not read the
value properly and the packed result is wired to 0. Several
places wrongly used int.

Crucially this means the kernel has never, set reversible
correctly in the path record request. It has always asked for
irreversible paths even if the ULP requests otherwise.

When the kernel is used with a SM that supports this feature, it
completely breaks communication management if reversible paths are
not properly requested.

The only reason this ever worked is because opensm ignores the
reversible bit.

Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
Signed-off-by: Doug Ledford <dledford@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
7 years agoDrivers: hv: util: Backup: Fix a rescind processing issue
K. Y. Srinivasan [Fri, 23 Dec 2016 00:54:03 +0000 (16:54 -0800)]
Drivers: hv: util: Backup: Fix a rescind processing issue

BugLink: http://bugs.launchpad.net/bugs/1672544
commit d77044d142e960f7b5f814a91ecb8bcf86aa552c upstream.

VSS may use a char device to support the communication between
the user level daemon and the driver. When the VSS channel is rescinded
we need to make sure that the char device is fully cleaned up before
we can process a new VSS offer from the host. Implement this logic.

Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
7 years agoDrivers: hv: util: Fcopy: Fix a rescind processing issue
K. Y. Srinivasan [Fri, 23 Dec 2016 00:54:02 +0000 (16:54 -0800)]
Drivers: hv: util: Fcopy: Fix a rescind processing issue

BugLink: http://bugs.launchpad.net/bugs/1672544
commit 20951c7535b5e6af46bc37b7142105f716df739c upstream.

Fcopy may use a char device to support the communication between
the user level daemon and the driver. When the Fcopy channel is rescinded
we need to make sure that the char device is fully cleaned up before
we can process a new Fcopy offer from the host. Implement this logic.

Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
7 years agoDrivers: hv: util: kvp: Fix a rescind processing issue
K. Y. Srinivasan [Fri, 23 Dec 2016 00:54:01 +0000 (16:54 -0800)]
Drivers: hv: util: kvp: Fix a rescind processing issue

BugLink: http://bugs.launchpad.net/bugs/1672544
commit 5a66fecbf6aa528e375cbebccb1061cc58d80c84 upstream.

KVP may use a char device to support the communication between
the user level daemon and the driver. When the KVP channel is rescinded
we need to make sure that the char device is fully cleaned up before
we can process a new KVP offer from the host. Implement this logic.

Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
7 years agoDrivers: hv: vmbus: Fix a rescind handling bug
K. Y. Srinivasan [Fri, 23 Dec 2016 00:54:00 +0000 (16:54 -0800)]
Drivers: hv: vmbus: Fix a rescind handling bug

BugLink: http://bugs.launchpad.net/bugs/1672544
commit ccb61f8a99e6c29df4fb96a65dad4fad740d5be9 upstream.

The host can rescind a channel that has been offered to the
guest and once the channel is rescinded, the host does not
respond to any requests on that channel. Deal with the case where
the guest may be blocked waiting for a response from the host.

Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
7 years agoDrivers: hv: vmbus: Prevent sending data on a rescinded channel
K. Y. Srinivasan [Wed, 7 Dec 2016 09:16:28 +0000 (01:16 -0800)]
Drivers: hv: vmbus: Prevent sending data on a rescinded channel

BugLink: http://bugs.launchpad.net/bugs/1672544
commit e7e97dd8b77ee7366f2f8c70a033bf5fa05ec2e0 upstream.

After the channel is rescinded, the host does not read from the rescinded channel.
Fail writes to a channel that has already been rescinded. If we permit writes on a
rescinded channel, since the host will not respond we will have situations where
we will be unable to unload vmbus drivers that cannot have any outstanding requests
to the host at the point they are unoaded.

Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
7 years agohv: init percpu_list in hv_synic_alloc()
Vitaly Kuznetsov [Wed, 7 Dec 2016 09:16:26 +0000 (01:16 -0800)]
hv: init percpu_list in hv_synic_alloc()

BugLink: http://bugs.launchpad.net/bugs/1672544
commit 3c7630d35009e6635e5b58d62de554fd5b6db5df upstream.

Initializing hv_context.percpu_list in hv_synic_alloc() helps to prevent a
crash in percpu_channel_enq() when not all CPUs were online during
initialization and it naturally belongs there.

Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
7 years agohv: allocate synic pages for all present CPUs
Vitaly Kuznetsov [Wed, 7 Dec 2016 09:16:25 +0000 (01:16 -0800)]
hv: allocate synic pages for all present CPUs

BugLink: http://bugs.launchpad.net/bugs/1672544
commit 421b8f20d3c381b215f988b42428f56fc3b82405 upstream.

It may happen that not all CPUs are online when we do hv_synic_alloc() and
in case more CPUs come online later we may try accessing these allocated
structures.

Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
7 years agousb: gadget: f_hid: fix: Move IN request allocation to set_alt()
Krzysztof Opasiak [Tue, 24 Jan 2017 02:27:24 +0000 (03:27 +0100)]
usb: gadget: f_hid: fix: Move IN request allocation to set_alt()

BugLink: http://bugs.launchpad.net/bugs/1672544
commit 749494b6bdbbaf0899aa1c62a1ad74cd747bce47 upstream.

Since commit: ba1582f22231 ("usb: gadget: f_hid: use alloc_ep_req()")
we cannot allocate any requests in bind() as we check if we should
align request buffer based on endpoint descriptor which is assigned
in set_alt().

Allocating request in bind() function causes a NULL pointer
dereference.

This commit moves allocation of IN request from bind() to set_alt()
to prevent this issue.

Fixes: ba1582f22231 ("usb: gadget: f_hid: use alloc_ep_req()")
Tested-by: David Lechner <david@lechnology.com>
Signed-off-by: Krzysztof Opasiak <k.opasiak@samsung.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
7 years agousb: gadget: f_hid: Use spinlock instead of mutex
Krzysztof Opasiak [Thu, 19 Jan 2017 17:55:29 +0000 (18:55 +0100)]
usb: gadget: f_hid: Use spinlock instead of mutex

BugLink: http://bugs.launchpad.net/bugs/1672544
commit 33e4c1a9987a1fc3b42c3b534100b5b006d55c61 upstream.

As IN request has to be allocated in set_alt() and released in
disable() we cannot use mutex to protect it as we cannot sleep
in those funcitons. Let's replace this mutex with a spinlock.

Tested-by: David Lechner <david@lechnology.com>
Signed-off-by: Krzysztof Opasiak <k.opasiak@samsung.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
7 years agousb: gadget: f_hid: fix: Prevent accessing released memory
Krzysztof Opasiak [Thu, 19 Jan 2017 17:55:28 +0000 (18:55 +0100)]
usb: gadget: f_hid: fix: Prevent accessing released memory

BugLink: http://bugs.launchpad.net/bugs/1672544
commit aa65d11aa008f4de58a9cee7e121666d9d68505e upstream.

When we unlock our spinlock to copy data to user we may get
disabled by USB host and free the whole list of completed out
requests including the one from which we are copying the data
to user memory.

To prevent from this let's remove our working element from
the list and place it back only if there is sth left when we
finish with it.

Fixes: 99c515005857 ("usb: gadget: hidg: register OUT INT endpoint for SET_REPORT")
Tested-by: David Lechner <david@lechnology.com>
Signed-off-by: Krzysztof Opasiak <k.opasiak@samsung.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
7 years agousb: gadget: f_hid: fix: Free out requests
Krzysztof Opasiak [Thu, 19 Jan 2017 17:55:27 +0000 (18:55 +0100)]
usb: gadget: f_hid: fix: Free out requests

BugLink: http://bugs.launchpad.net/bugs/1672544
commit 20d2ca955bd09639c7b01db5761d157c297aea0a upstream.

Requests for out endpoint are allocated in bind() function
but never released.

This commit ensures that all pending requests are released
when we disable out endpoint.

Fixes: 99c515005857 ("usb: gadget: hidg: register OUT INT endpoint for SET_REPORT")
Tested-by: David Lechner <david@lechnology.com>
Signed-off-by: Krzysztof Opasiak <k.opasiak@samsung.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
7 years agousb: gadget: udc: fsl: Add missing complete function.
Magnus Lilja [Wed, 25 Jan 2017 21:07:59 +0000 (22:07 +0100)]
usb: gadget: udc: fsl: Add missing complete function.

BugLink: http://bugs.launchpad.net/bugs/1672544
commit 5528954a1a0c49c6974ef1b8d6eaceff536204d5 upstream.

Commit 304f7e5e1d08 ("usb: gadget: Refactor request completion")
removed check if req->req.complete is non-NULL, resulting in a NULL
pointer derefence and a kernel panic.
This patch adds an empty complete function instead of re-introducing
the req->req.complete check.

Fixes: 304f7e5e1d08 ("usb: gadget: Refactor request completion")
Signed-off-by: Magnus Lilja <lilja.magnus@gmail.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
7 years agousb: gadget: udc-core: Rescan pending list on driver unbind
Krzysztof Opasiak [Mon, 16 Jan 2017 07:40:57 +0000 (08:40 +0100)]
usb: gadget: udc-core: Rescan pending list on driver unbind

BugLink: http://bugs.launchpad.net/bugs/1672544
commit 8236800da115a3e24b9165c573067343f51cf5ea upstream.

Since:

commit 855ed04a3758 ("usb: gadget: udc-core: independent registration
of gadgets and gadget drivers")

if we load gadget module but there is no free udc available
then it will be stored on a pending gadgets list.

$ modprobe g_zero.ko
$ modprobe g_ether.ko
[] udc-core: couldn't find an available UDC - added [g_ether] to list
of pending drivers

We scan this list each time when new UDC appears in system.
But we can get a free UDC each time after gadget unbind.
This commit add scanning of that list directly after unbinding
gadget from udc.

Thanks to this, when we unload first gadget:

$ rmmod g_zero.ko

gadget which is pending is automatically
attached to that UDC (if name matches).

Fixes: 855ed04a3758 ("usb: gadget: udc-core: independent registration of gadgets and gadget drivers")
Signed-off-by: Krzysztof Opasiak <k.opasiak@samsung.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
7 years agousb: host: xhci: plat: check hcc_params after add hcd
William wu [Tue, 17 Jan 2017 07:32:07 +0000 (15:32 +0800)]
usb: host: xhci: plat: check hcc_params after add hcd

BugLink: http://bugs.launchpad.net/bugs/1672544
commit 5de4e1ea9a731cad195ce5152705c21daef3bbba upstream.

The commit 4ac53087d6d4 ("usb: xhci: plat: Create both
HCDs before adding them") move add hcd to the end of
probe, this cause hcc_params uninitiated, because xHCI
driver sets hcc_params in xhci_gen_setup() called from
usb_add_hcd().

This patch checks the Maximum Primary Stream Array Size
in the hcc_params register after add primary hcd.

Signed-off-by: William wu <william.wu@rock-chips.com>
Acked-by: Roger Quadros <rogerq@ti.com>
Fixes: 4ac53087d6d4 ("usb: xhci: plat: Create both HCDs before adding them")
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
7 years agousb: dwc3: gadget: skip Set/Clear Halt when invalid
Felipe Balbi [Thu, 19 Jan 2017 11:38:42 +0000 (13:38 +0200)]
usb: dwc3: gadget: skip Set/Clear Halt when invalid

BugLink: http://bugs.launchpad.net/bugs/1672544
commit ffb80fc672c3a7b6afd0cefcb1524fb99917b2f3 upstream.

At least macOS seems to be sending
ClearFeature(ENDPOINT_HALT) to endpoints which
aren't Halted. This makes DWC3's CLEARSTALL command
time out which causes several issues for the driver.

Instead, let's just return 0 and bail out early.

Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
7 years agousb: musb: da8xx: Remove CPPI 3.0 quirk and methods
Alexandre Bailon [Thu, 2 Feb 2017 03:30:12 +0000 (21:30 -0600)]
usb: musb: da8xx: Remove CPPI 3.0 quirk and methods

BugLink: http://bugs.launchpad.net/bugs/1672544
commit a994ce2d7e66008381a0b184c73be9ae9b72eb5c upstream.

DA8xx driver is registering and using the CPPI 3.0 DMA controller but
actually, the DA8xx has a CPPI 4.1 DMA controller.
Remove the CPPI 3.0 quirk and methods.

Fixes: f8e9f34f80a2 ("usb: musb: Fix up DMA related macros")
Fixes: 7f6283ed6fe8 ("usb: musb: Set up function pointers for DMA")
Signed-off-by: Alexandre Bailon <abailon@baylibre.com>
Acked-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Acked-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Bin Liu <b-liu@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
7 years agow1: ds2490: USB transfer buffers need to be DMAable
Maciej S. Szmigiero [Wed, 18 Jan 2017 20:31:11 +0000 (21:31 +0100)]
w1: ds2490: USB transfer buffers need to be DMAable

BugLink: http://bugs.launchpad.net/bugs/1672544
commit 61cd1b4cd1e8f7f7642ab64529d9bd52e8374641 upstream.

ds2490 driver was doing USB transfers from / to buffers on a stack.
This is not permitted and made the driver non-working with vmapped stacks.

Since all these transfers are done under the same bus_mutex lock we can
simply use shared buffers in a device private structure for two most common
of them.

While we are at it, let's also fix a comparison between int and size_t in
ds9490r_search() which made the driver spin in this function if state
register get requests were failing.

Signed-off-by: Maciej S. Szmigiero <mail@maciej.szmigiero.name>
Acked-by: Evgeniy Polyakov <zbr@ioremap.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
7 years agow1: don't leak refcount on slave attach failure in w1_attach_slave_device()
Maciej S. Szmigiero [Sat, 21 Jan 2017 22:50:18 +0000 (23:50 +0100)]
w1: don't leak refcount on slave attach failure in w1_attach_slave_device()

BugLink: http://bugs.launchpad.net/bugs/1672544
commit d2ce4ea1a0b0162e5d2d7e7942ab6f5cc2063d5a upstream.

Near the beginning of w1_attach_slave_device() we increment a w1 master
reference count.
Later, when we are going to exit this function without actually attaching
a slave device (due to failure of __w1_attach_slave_device()) we need to
decrement this reference count back.

Signed-off-by: Maciej S. Szmigiero <mail@maciej.szmigiero.name>
Fixes: 9fcbbac5ded489 ("w1: process w1 netlink commands in w1_process thread")
Cc: Evgeniy Polyakov <zbr@ioremap.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
7 years agocan: usb_8dev: Fix memory leak of priv->cmd_msg_buffer
Marc Kleine-Budde [Thu, 2 Mar 2017 11:03:40 +0000 (12:03 +0100)]
can: usb_8dev: Fix memory leak of priv->cmd_msg_buffer

BugLink: http://bugs.launchpad.net/bugs/1672544
commit 7c42631376306fb3f34d51fda546b50a9b6dd6ec upstream.

The priv->cmd_msg_buffer is allocated in the probe function, but never
kfree()ed. This patch converts the kzalloc() to resource-managed
kzalloc.

Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
7 years agocan: gs_usb: Don't use stack memory for USB transfers
Ethan Zonca [Fri, 24 Feb 2017 16:27:36 +0000 (11:27 -0500)]
can: gs_usb: Don't use stack memory for USB transfers

BugLink: http://bugs.launchpad.net/bugs/1672544
commit c919a3069c775c1c876bec55e00b2305d5125caa upstream.

Fixes: 05ca5270005c can: gs_usb: add ethtool set_phys_id callback to locate physical device
The gs_usb driver is performing USB transfers using buffers allocated on
the stack. This causes the driver to not function with vmapped stacks.
Instead, allocate memory for the transfer buffers.

Signed-off-by: Ethan Zonca <e@ethanzonca.com>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
7 years agoiio: pressure: mpl3115: do not rely on structure field ordering
Peter Rosin [Wed, 1 Feb 2017 20:40:56 +0000 (21:40 +0100)]
iio: pressure: mpl3115: do not rely on structure field ordering

BugLink: http://bugs.launchpad.net/bugs/1672544
commit 9cf6cdba586ced75c69b8314b88b2d2f5ce9b3ed upstream.

Fixes a regression triggered by a change in the layout of
struct iio_chan_spec, but the real bug is in the driver which assumed
a specific structure layout in the first place. Hint: the two bits were
not OR:ed together as implied by the indentation prior to this patch,
there was a comma between them, which accidentally moved the ..._SCALE
bit to the next structure field. That field was .info_mask_shared_by_type
before the _available attributes was added by commit 51239600074b
("iio:core: add a callback to allow drivers to provide _available
attributes") and .info_mask_separate_available afterwards, and the
regression happened.

info_mask_shared_by_type is actually a better choice than the originally
intended info_mask_separate for the ..._SCALE bit since a constant is
returned from mpl3115_read_raw for the scale. Using
info_mask_shared_by_type also preserves the behavior from before the
regression and is therefore less likely to cause other interesting side
effects.

The above mentioned regression causes an unintended sysfs attibute to
show up that is not backed by code, in turn causing the following NULL
pointer defererence to happen on access.

Segmentation fault

Unable to handle kernel NULL pointer dereference at virtual address 00000000
pgd = ecc3c000
[00000000] *pgd=87f91831
Internal error: Oops: 80000007 [#1] SMP ARM
Modules linked in:
CPU: 1 PID: 1051 Comm: cat Not tainted 4.10.0-rc5-00009-gffd8858-dirty #3
Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
task: ed54ec00 task.stack: ee2bc000
PC is at 0x0
LR is at iio_read_channel_info_avail+0x40/0x280
pc : [<00000000>]    lr : [<c06fbc1c>]    psr: a0070013
sp : ee2bdda8  ip : 00000000  fp : ee2bddf4
r10: c0a53c74  r9 : ed79f000  r8 : ee8d1018
r7 : 00001000  r6 : 00000fff  r5 : ee8b9a00  r4 : ed79f000
r3 : ee2bddc4  r2 : ee2bddbc  r1 : c0a86dcc  r0 : ee8d1000
Flags: NzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment none
Control: 10c5387d  Table: 3cc3c04a  DAC: 00000051
Process cat (pid: 1051, stack limit = 0xee2bc210)
Stack: (0xee2bdda8 to 0xee2be000)
dda0:                   ee2bddc0 00000002 c016d720 c016d394 ed54ec00 00000000
ddc0: 60070013 ed413780 00000001 edffd480 ee8b9a00 00000fff 00001000 ee8d1018
dde0: ed79f000 c0a53c74 ee2bde0c ee2bddf8 c0513c58 c06fbbe8 edffd480 edffd540
de00: ee2bde3c ee2bde10 c0293474 c0513c40 c02933e4 ee2bde60 00000001 ed413780
de20: 00000001 ed413780 00000000 edffd480 ee2bde4c ee2bde40 c0291d00 c02933f0
de40: ee2bde9c ee2bde50 c024679c c0291ce0 edffd4b0 b6e37000 00020000 ee2bdf78
de60: 00000000 00000000 ed54ec00 ed013200 00000817 c0a111fc edffd540 ed413780
de80: b6e37000 00020000 00020000 ee2bdf78 ee2bded4 ee2bdea0 c0292890 c0246604
dea0: c0117940 c016ba50 00000025 c0a111fc b6e37000 ed413780 ee2bdf78 00020000
dec0: ee2bc000 b6e37000 ee2bdf44 ee2bded8 c021d158 c0292770 c0117764 b6e36004
dee0: c0f0d7c4 ee2bdfb0 b6f89228 00021008 ee2bdfac ee2bdf00 c0101374 c0117770
df00: 00000000 00000000 ee2bc000 00000000 ee2bdf34 ee2bdf20 c016ba04 c0171080
df20: 00000000 00020000 ed413780 b6e37000 00000000 ee2bdf78 ee2bdf74 ee2bdf48
df40: c021e7a0 c021d130 c023e300 c023e280 ee2bdf74 00000000 00000000 ed413780
df60: ed413780 00020000 ee2bdfa4 ee2bdf78 c021e870 c021e71c 00000000 00000000
df80: 00020000 00020000 b6e37000 00000003 c0108084 00000000 00000000 ee2bdfa8
dfa0: c0107ee0 c021e838 00020000 00020000 00000003 b6e37000 00020000 0001a2b4
dfc0: 00020000 00020000 b6e37000 00000003 7fffe000 00000000 00000000 00020000
dfe0: 00000000 be98eb4c 0000c740 b6f1985c 60070010 00000003 00000000 00000000
Backtrace:
[<c06fbbdc>] (iio_read_channel_info_avail) from [<c0513c58>] (dev_attr_show+0x24/0x50)
 r10:c0a53c74 r9:ed79f000 r8:ee8d1018 r7:00001000 r6:00000fff r5:ee8b9a00
 r4:edffd480
[<c0513c34>] (dev_attr_show) from [<c0293474>] (sysfs_kf_seq_show+0x90/0x110)
 r5:edffd540 r4:edffd480
[<c02933e4>] (sysfs_kf_seq_show) from [<c0291d00>] (kernfs_seq_show+0x2c/0x30)
 r10:edffd480 r9:00000000 r8:ed413780 r7:00000001 r6:ed413780 r5:00000001
 r4:ee2bde60 r3:c02933e4
[<c0291cd4>] (kernfs_seq_show) from [<c024679c>] (seq_read+0x1a4/0x4e0)
[<c02465f8>] (seq_read) from [<c0292890>] (kernfs_fop_read+0x12c/0x1cc)
 r10:ee2bdf78 r9:00020000 r8:00020000 r7:b6e37000 r6:ed413780 r5:edffd540
 r4:c0a111fc
[<c0292764>] (kernfs_fop_read) from [<c021d158>] (__vfs_read+0x34/0x118)
 r10:b6e37000 r9:ee2bc000 r8:00020000 r7:ee2bdf78 r6:ed413780 r5:b6e37000
 r4:c0a111fc
[<c021d124>] (__vfs_read) from [<c021e7a0>] (vfs_read+0x90/0x11c)
 r8:ee2bdf78 r7:00000000 r6:b6e37000 r5:ed413780 r4:00020000
[<c021e710>] (vfs_read) from [<c021e870>] (SyS_read+0x44/0x90)
 r8:00020000 r7:ed413780 r6:ed413780 r5:00000000 r4:00000000
[<c021e82c>] (SyS_read) from [<c0107ee0>] (ret_fast_syscall+0x0/0x1c)
 r10:00000000 r8:c0108084 r7:00000003 r6:b6e37000 r5:00020000 r4:00020000
Code: bad PC value
---[ end trace 9c4938ccd0389004 ]---

Fixes: cc26ad455f57 ("iio: Add Freescale MPL3115A2 pressure / temperature sensor driver")
Fixes: 51239600074b ("iio:core: add a callback to allow drivers to provide _available attributes")
Reported-by: Ken Lin <ken.lin@advantech.com>
Tested-by: Ken Lin <ken.lin@advantech.com>
Signed-off-by: Peter Rosin <peda@axentia.se>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
7 years agoiio: pressure: mpl115: do not rely on structure field ordering
Peter Rosin [Wed, 1 Feb 2017 20:40:57 +0000 (21:40 +0100)]
iio: pressure: mpl115: do not rely on structure field ordering

BugLink: http://bugs.launchpad.net/bugs/1672544
commit 6a6e1d56a0769795a36c0461c64bf5e5b9bbb4c0 upstream.

Fixes a regression triggered by a change in the layout of
struct iio_chan_spec, but the real bug is in the driver which assumed
a specific structure layout in the first place. Hint: the three bits were
not OR:ed together as implied by the indentation prior to this patch,
there was a comma between the first two, which accidentally moved the
..._SCALE and ..._OFFSET bits to the next structure field. That field
was .info_mask_shared_by_type before the _available attributes was added
by commit 51239600074b ("iio:core: add a callback to allow drivers to
provide _available attributes") and .info_mask_separate_available
afterwards, and the regression happened.

info_mask_shared_by_type is actually a better choice than the originally
intended info_mask_separate for the ..._SCALE and ..._OFFSET bits since
a constant is returned from mpl115_read_raw for the scale/offset. Using
info_mask_shared_by_type also preserves the behavior from before the
regression and is therefore less likely to cause other interesting side
effects.

The above mentioned regression causes unintended sysfs attibutes to
show up that are not backed by code, in turn causing a NULL pointer
defererence to happen on access.

Fixes: 3017d90e8931 ("iio: Add Freescale MPL115A2 pressure / temperature sensor driver")
Fixes: 51239600074b ("iio:core: add a callback to allow drivers to provide _available attributes")
Signed-off-by: Peter Rosin <peda@axentia.se>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
7 years agoRevert "arm64: mm: set the contiguous bit for kernel mappings where appropriate"
Mark Rutland [Thu, 23 Feb 2017 16:22:55 +0000 (16:22 +0000)]
Revert "arm64: mm: set the contiguous bit for kernel mappings where appropriate"

BugLink: http://bugs.launchpad.net/bugs/1672544
commit d81bbe6d882461dec4b71dbe2aa85565fcca4187 upstream.

This reverts commit 0bfc445dec9dd8130d22c9f4476eed7598524129.

When we change the permissions of regions mapped using contiguous
entries, the architecture requires us to follow a Break-Before-Make
strategy, breaking *all* associated entries before we can change any of
the following properties from the entries:

 - presence of the contiguous bit
 - output address
 - attributes
 - permissiones

Failure to do so can result in a number of problems (e.g. TLB conflict
aborts and/or erroneous results from TLB lookups).

See ARM DDI 0487A.k_iss10775, "Misprogramming of the Contiguous bit",
page D4-1762.

We do not take this into account when altering the permissions of kernel
segments in mark_rodata_ro(), where we change the permissions of live
contiguous entires one-by-one, leaving them transiently inconsistent.
This has been observed to result in failures on some fast model
configurations.

Unfortunately, we cannot follow Break-Before-Make here as we'd have to
unmap kernel text and data used to perform the sequence.

For the timebeing, revert commit 0bfc445dec9dd813 so as to avoid issues
resulting from this misuse of the contiguous bit.

Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reported-by: Jean-Philippe Brucker <jean-philippe.brucker@arm.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <Will.Deacon@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
7 years agoKVM: arm/arm64: vgic: Stop injecting the MSI occurrence twice
Shanker Donthineni [Fri, 3 Feb 2017 02:30:03 +0000 (20:30 -0600)]
KVM: arm/arm64: vgic: Stop injecting the MSI occurrence twice

BugLink: http://bugs.launchpad.net/bugs/1672544
commit 0bdbf3b071986ba80731203683cf623d5c0cacb1 upstream.

The IRQFD framework calls the architecture dependent function
twice if the corresponding GSI type is edge triggered. For ARM,
the function kvm_set_msi() is getting called twice whenever the
IRQFD receives the event signal. The rest of the code path is
trying to inject the MSI without any validation checks. No need
to call the function vgic_its_inject_msi() second time to avoid
an unnecessary overhead in IRQ queue logic. It also avoids the
possibility of VM seeing the MSI twice.

Simple fix, return -1 if the argument 'level' value is zero.

Reviewed-by: Eric Auger <eric.auger@redhat.com>
Reviewed-by: Christoffer Dall <cdall@linaro.org>
Signed-off-by: Shanker Donthineni <shankerd@codeaurora.org>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
7 years agoarm64: fix erroneous __raw_read_system_reg() cases
Mark Rutland [Thu, 2 Feb 2017 17:32:14 +0000 (17:32 +0000)]
arm64: fix erroneous __raw_read_system_reg() cases

BugLink: http://bugs.launchpad.net/bugs/1672544
commit 7d0928f18bf890d2853281f59aba0dd5a46b34f9 upstream.

Since it was introduced in commit da8d02d19ffdd201 ("arm64/capabilities:
Make use of system wide safe value"), __raw_read_system_reg() has
erroneously mapped some sysreg IDs to other registers.

For the fields in ID_ISAR5_EL1, our local feature detection will be
erroneous. We may spuriously detect that a feature is uniformly
supported, or may fail to detect when it actually is, meaning some
compat hwcaps may be erroneous (or not enforced upon hotplug).

This patch corrects the erroneous entries.

Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Fixes: da8d02d19ffdd201 ("arm64/capabilities: Make use of system wide safe value")
Reported-by: Catalin Marinas <catalin.marinas@arm.com>
Cc: Suzuki K Poulose <suzuki.poulose@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
7 years agoarm64: dma-mapping: Fix dma_mapping_error() when bypassing SWIOTLB
Robin Murphy [Wed, 25 Jan 2017 18:31:31 +0000 (18:31 +0000)]
arm64: dma-mapping: Fix dma_mapping_error() when bypassing SWIOTLB

BugLink: http://bugs.launchpad.net/bugs/1672544
commit adbe7e26f4257f72817495b9bce114284060b0d7 upstream.

When bypassing SWIOTLB on small-memory systems, we need to avoid calling
into swiotlb_dma_mapping_error() in exactly the same way as we avoid
swiotlb_dma_supported(), because the former also relies on SWIOTLB state
being initialised.

Under the assumptions for which we skip SWIOTLB, dma_map_{single,page}()
will only ever return the DMA-offset-adjusted physical address of the
page passed in, thus we can report success unconditionally.

Fixes: b67a8b29df7e ("arm64: mm: only initialize swiotlb when necessary")
CC: Jisheng Zhang <jszhang@marvell.com>
Reported-by: Aaro Koskinen <aaro.koskinen@iki.fi>
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
7 years agoarm/arm64: KVM: Enforce unconditional flush to PoC when mapping to stage-2
Marc Zyngier [Wed, 25 Jan 2017 12:29:59 +0000 (12:29 +0000)]
arm/arm64: KVM: Enforce unconditional flush to PoC when mapping to stage-2

BugLink: http://bugs.launchpad.net/bugs/1672544
commit 8f36ebaf21fdae99c091c67e8b6fab33969f2667 upstream.

When we fault in a page, we flush it to the PoC (Point of Coherency)
if the faulting vcpu has its own caches off, so that it can observe
the page we just brought it.

But if the vcpu has its caches on, we skip that step. Bad things
happen when *another* vcpu tries to access that page with its own
caches disabled. At that point, there is no garantee that the
data has made it to the PoC, and we access stale data.

The obvious fix is to always flush to PoC when a page is faulted
in, no matter what the state of the vcpu is.

Fixes: 2d58b733c876 ("arm64: KVM: force cache clean on page fault when caches are off")
Reviewed-by: Christoffer Dall <christoffer.dall@linaro.org>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
7 years agox86/pkeys: Check against max pkey to avoid overflows
Dave Hansen [Thu, 23 Feb 2017 22:26:03 +0000 (14:26 -0800)]
x86/pkeys: Check against max pkey to avoid overflows

BugLink: http://bugs.launchpad.net/bugs/1672544
commit 58ab9a088ddac4efe823471275859d64f735577e upstream.

Kirill reported a warning from UBSAN about undefined behavior when using
protection keys.  He is running on hardware that actually has support for
it, which is not widely available.

The warning triggers because of very large shifts of integers when doing a
pkey_free() of a large, invalid value. This happens because we never check
that the pkey "fits" into the mm_pkey_allocation_map().

I do not believe there is any danger here of anything bad happening
other than some aliasing issues where somebody could do:

pkey_free(35);

and the kernel would effectively execute:

pkey_free(8);

While this might be confusing to an app that was doing something stupid, it
has to do something stupid and the effects are limited to the app shooting
itself in the foot.

Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
Cc: linux-kselftest@vger.kernel.org
Cc: shuah@kernel.org
Cc: kirill.shutemov@linux.intel.com
Link: http://lkml.kernel.org/r/20170223222603.A022ED65@viggo.jf.intel.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
7 years agofuse: add missing FR_FORCE
Miklos Szeredi [Wed, 22 Feb 2017 19:08:25 +0000 (20:08 +0100)]
fuse: add missing FR_FORCE

BugLink: http://bugs.launchpad.net/bugs/1672544
commit 2e38bea99a80eab408adee27f873a188d57b76cb upstream.

fuse_file_put() was missing the "force" flag for the RELEASE request when
sending synchronously (fuseblk).

If this flag is not set, then a sync request may be interrupted before it
is dequeued by the userspace filesystem.  In this case the OPEN won't be
balanced with a RELEASE.

Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
Fixes: 5a18ec176c93 ("fuse: fix hang of single threaded fuseblk filesystem")
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
7 years agocrypto: api - Add crypto_requires_off helper
Herbert Xu [Sun, 26 Feb 2017 04:22:35 +0000 (12:22 +0800)]
crypto: api - Add crypto_requires_off helper

BugLink: http://bugs.launchpad.net/bugs/1672544
commit 016df0abc56ec06d0c63c5318ef53e40738dea8b upstream.

This patch adds crypto_requires_off which is an extension of
crypto_requires_sync for similar bits such as NEED_FALLBACK.

Suggested-by: Marcelo Cerri <marcelo.cerri@canonical.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
7 years agocrypto: xts - Propagate NEED_FALLBACK bit
Herbert Xu [Sun, 26 Feb 2017 04:24:10 +0000 (12:24 +0800)]
crypto: xts - Propagate NEED_FALLBACK bit

BugLink: http://bugs.launchpad.net/bugs/1672544
commit 89027579bc6c2febbcc9c2f9d5069adf71539e4b upstream.

When we're used as a fallback algorithm, we should propagate
the NEED_FALLBACK bit when searching for the underlying ECB mode.

This just happens to fix a hang too because otherwise the search
may end up loading the same module that triggered this XTS creation.

Fixes: f1c131b45410 ("crypto: xts - Convert to skcipher")
Reported-by: Harald Freudenberger <freude@linux.vnet.ibm.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
7 years agocrypto: testmgr - Pad aes_ccm_enc_tv_template vector
Laura Abbott [Tue, 28 Feb 2017 22:07:25 +0000 (14:07 -0800)]
crypto: testmgr - Pad aes_ccm_enc_tv_template vector

BugLink: http://bugs.launchpad.net/bugs/1672544
commit 1c68bb0f62bf8de8bb30123ea840d5168f25abea upstream.

Running with KASAN and crypto tests currently gives

 BUG: KASAN: global-out-of-bounds in __test_aead+0x9d9/0x2200 at addr ffffffff8212fca0
 Read of size 16 by task cryptomgr_test/1107
 Address belongs to variable 0xffffffff8212fca0
 CPU: 0 PID: 1107 Comm: cryptomgr_test Not tainted 4.10.0+ #45
 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.9.1-1.fc24 04/01/2014
 Call Trace:
  dump_stack+0x63/0x8a
  kasan_report.part.1+0x4a7/0x4e0
  ? __test_aead+0x9d9/0x2200
  ? crypto_ccm_init_crypt+0x218/0x3c0 [ccm]
  kasan_report+0x20/0x30
  check_memory_region+0x13c/0x1a0
  memcpy+0x23/0x50
  __test_aead+0x9d9/0x2200
  ? kasan_unpoison_shadow+0x35/0x50
  ? alg_test_akcipher+0xf0/0xf0
  ? crypto_skcipher_init_tfm+0x2e3/0x310
  ? crypto_spawn_tfm2+0x37/0x60
  ? crypto_ccm_init_tfm+0xa9/0xd0 [ccm]
  ? crypto_aead_init_tfm+0x7b/0x90
  ? crypto_alloc_tfm+0xc4/0x190
  test_aead+0x28/0xc0
  alg_test_aead+0x54/0xd0
  alg_test+0x1eb/0x3d0
  ? alg_find_test+0x90/0x90
  ? __sched_text_start+0x8/0x8
  ? __wake_up_common+0x70/0xb0
  cryptomgr_test+0x4d/0x60
  kthread+0x173/0x1c0
  ? crypto_acomp_scomp_free_ctx+0x60/0x60
  ? kthread_create_on_node+0xa0/0xa0
  ret_from_fork+0x2c/0x40
 Memory state around the buggy address:
  ffffffff8212fb80: 00 00 00 00 01 fa fa fa fa fa fa fa 00 00 00 00
  ffffffff8212fc00: 00 01 fa fa fa fa fa fa 00 00 00 00 01 fa fa fa
 >ffffffff8212fc80: fa fa fa fa 00 05 fa fa fa fa fa fa 00 00 00 00
                                   ^
  ffffffff8212fd00: 01 fa fa fa fa fa fa fa 00 00 00 00 01 fa fa fa
  ffffffff8212fd80: fa fa fa fa 00 00 00 00 00 05 fa fa fa fa fa fa

This always happens on the same IV which is less than 16 bytes.

Per Ard,

"CCM IVs are 16 bytes, but due to the way they are constructed
internally, the final couple of bytes of input IV are dont-cares.

Apparently, we do read all 16 bytes, which triggers the KASAN errors."

Fix this by padding the IV with null bytes to be at least 16 bytes.

Fixes: 0bc5a6c5c79a ("crypto: testmgr - Disable rfc4309 test and convert test vectors")
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Laura Abbott <labbott@redhat.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
7 years agocrypto: xts - Add ECB dependency
Milan Broz [Thu, 23 Feb 2017 07:38:26 +0000 (08:38 +0100)]
crypto: xts - Add ECB dependency

BugLink: http://bugs.launchpad.net/bugs/1672544
commit 12cb3a1c4184f891d965d1f39f8cfcc9ef617647 upstream.

Since the
   commit f1c131b45410a202eb45cc55980a7a9e4e4b4f40
   crypto: xts - Convert to skcipher
the XTS mode is based on ECB, so the mode must select
ECB otherwise it can fail to initialize.

Signed-off-by: Milan Broz <gmazyland@gmail.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
7 years agoDrivers: hv: vmbus: Raise retry/wait limits in vmbus_post_msg()
Vitaly Kuznetsov [Wed, 7 Dec 2016 09:16:24 +0000 (01:16 -0800)]
Drivers: hv: vmbus: Raise retry/wait limits in vmbus_post_msg()

BugLink: http://bugs.launchpad.net/bugs/1672544
commit c0bb03924f1a80e7f65900e36c8e6b3dc167c5f8 upstream.

DoS protection conditions were altered in WS2016 and now it's easy to get
-EAGAIN returned from vmbus_post_msg() (e.g. when we try changing MTU on a
netvsc device in a loop). All vmbus_post_msg() callers don't retry the
operation and we usually end up with a non-functional device or crash.

While host's DoS protection conditions are unknown to me my tests show that
it can take up to 10 seconds before the message is sent so doing udelay()
is not an option, we really need to sleep. Almost all vmbus_post_msg()
callers are ready to sleep but there is one special case:
vmbus_initiate_unload() which can be called from interrupt/NMI context and
we can't sleep there. I'm also not sure about the lonely
vmbus_send_tl_connect_request() which has no in-tree users but its external
users are most likely waiting for the host to reply so sleeping there is
also appropriate.

Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
7 years agoPCI: altera: Fix TLP_CFG_DW0 for TLP write
Ley Foon Tan [Tue, 28 Feb 2017 10:37:16 +0000 (18:37 +0800)]
PCI: altera: Fix TLP_CFG_DW0 for TLP write

BugLink: http://bugs.launchpad.net/bugs/1672544
commit 2a7275a3d867b228216886aae35e1f64291180b1 upstream.

eb5767122feb ("PCI: altera: Simplify TLB_CFG_DW0 usage") used
TLP_FMTTYPE_CFGRD* (instead of TLP_FMTTYPE_CFGWR*) for TLP writes, which
causes writing to configuration space to fail.  Fix it by using correct
FMTTYPE for write operation.

Fixes: eb5767122feb ("PCI: altera: Simplify TLB_CFG_DW0 usage")
Signed-off-by: Ley Foon Tan <ley.foon.tan@intel.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
7 years agoPCI: hv: Fix wslot_to_devfn() to fix warnings on device removal
Dexuan Cui [Fri, 10 Feb 2017 21:18:46 +0000 (15:18 -0600)]
PCI: hv: Fix wslot_to_devfn() to fix warnings on device removal

BugLink: http://bugs.launchpad.net/bugs/1672544
commit 60e2e2fbafdd1285ae1b4ad39ded41603e0c74d0 upstream.

The devfn of 00:02.0 is 0x10.  devfn_to_wslot(0x10) == 0x2, and
wslot_to_devfn(0x2) should be 0x10, while it's 0x2 in the current code.

Due to this, hv_eject_device_work() -> pci_get_domain_bus_and_slot()
returns NULL and pci_stop_and_remove_bus_device() is not called.

Later when the real device driver's .remove() is invoked by
hv_pci_remove() -> pci_stop_root_bus(), some warnings can be noticed
because the VM has lost the access to the underlying device at that
time.

Signed-off-by: Jake Oshins <jakeo@microsoft.com>
Signed-off-by: Dexuan Cui <decui@microsoft.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Haiyang Zhang <haiyangz@microsoft.com>
CC: K. Y. Srinivasan <kys@microsoft.com>
CC: Stephen Hemminger <sthemmin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
7 years agoath9k: use correct OTP register offsets for the AR9340 and AR9550
Christian Lamparter [Tue, 14 Feb 2017 19:10:30 +0000 (20:10 +0100)]
ath9k: use correct OTP register offsets for the AR9340 and AR9550

BugLink: http://bugs.launchpad.net/bugs/1672544
commit c9f1e32600816d695f817477d56490bfc2ba43c6 upstream.

This patch fixes the OTP register definitions for the AR934x and AR9550
WMAC SoC.

Previously, the ath9k driver was unable to initialize the integrated
WMAC on an Aerohive AP121:

| ath: phy0: timeout (1000 us) on reg 0x30018: 0xbadc0ffe & 0x00000007 != 0x00000004
| ath: phy0: timeout (1000 us) on reg 0x30018: 0xbadc0ffe & 0x00000007 != 0x00000004
| ath: phy0: Unable to initialize hardware; initialization status: -5
| ath9k ar934x_wmac: failed to initialize device
| ath9k: probe of ar934x_wmac failed with error -5

It turns out that the AR9300_OTP_STATUS and AR9300_OTP_DATA
definitions contain a typo.

Cc: Gabor Juhos <juhosg@openwrt.org>
Fixes: add295a4afbdf5852d0 "ath9k: use correct OTP register offsets for AR9550"
Signed-off-by: Christian Lamparter <chunkeey@googlemail.com>
Signed-off-by: Chris Blake <chrisrblake93@gmail.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
7 years agoath9k: fix race condition in enabling/disabling IRQs
Felix Fietkau [Thu, 2 Feb 2017 09:14:52 +0000 (10:14 +0100)]
ath9k: fix race condition in enabling/disabling IRQs

BugLink: http://bugs.launchpad.net/bugs/1672544
commit 3a5e969bb2f6692a256352649355d56d018d6b88 upstream.

The code currently relies on refcounting to disable IRQs from within the
IRQ handler and re-enabling them again after the tasklet has run.

However, due to race conditions sometimes the IRQ handler might be
called twice, or the tasklet may not run at all (if interrupted in the
middle of a reset).

This can cause nasty imbalances in the irq-disable refcount which will
get the driver permanently stuck until the entire radio has been stopped
and started again (ath_reset will not recover from this).

Instead of using this fragile logic, change the code to ensure that
running the irq handler during tasklet processing is safe, and leave the
refcount untouched.

Signed-off-by: Felix Fietkau <nbd@nbd.name>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
7 years agoath5k: drop bogus warning on drv_set_key with unsupported cipher
Felix Fietkau [Wed, 11 Jan 2017 14:32:13 +0000 (16:32 +0200)]
ath5k: drop bogus warning on drv_set_key with unsupported cipher

BugLink: http://bugs.launchpad.net/bugs/1672544
commit a70e1d6fd6b5e1a81fa6171600942bee34f5128f upstream.

Simply return -EOPNOTSUPP instead.

Signed-off-by: Felix Fietkau <nbd@nbd.name>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
7 years agoath10k: fix boot failure in UTF mode/testmode
Tamizh chelvam [Thu, 2 Feb 2017 06:32:18 +0000 (08:32 +0200)]
ath10k: fix boot failure in UTF mode/testmode

BugLink: http://bugs.launchpad.net/bugs/1672544
commit cb4281528b62207918b1e95827cad7527aa4dbaa upstream.

Rx filter reset and the dynamic tx switch mode (EXT_RESOURCE_CFG)
configuration are causing the following errors when UTF firmware
is loaded to the target.

Error message 1:
[ 598.015629] ath10k_pci 0001:01:00.0: failed to ping firmware: -110
[ 598.020828] ath10k_pci 0001:01:00.0: failed to reset rx filter: -110
[ 598.141556] ath10k_pci 0001:01:00.0: failed to start core (testmode): -110

Error message 2:
[ 668.615839] ath10k_ahb a000000.wifi: failed to send ext resource cfg command : -95
[ 668.618902] ath10k_ahb a000000.wifi: failed to start core (testmode): -95

Avoiding these configurations while bringing the target in
testmode is solving the problem.

Signed-off-by: Tamizh chelvam <c_traja@qti.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
7 years agomei: remove support for broken parallel read
Alexander Usyskin [Tue, 7 Feb 2017 22:41:45 +0000 (00:41 +0200)]
mei: remove support for broken parallel read

BugLink: http://bugs.launchpad.net/bugs/1672544
commit cb97fbbcac15982406e0c74cd5512a8b6fcf10b3 upstream.

Parallel reads from multiple threads on a file descriptor
are not well defined and racy. It is safer to return to original
behavior and simply fail the additional read.
The solution is to remove request for next read credit.

Fixes: ff1586a7ea57 ("mei: enqueue consecutive reads")
Signed-off-by: Alexander Usyskin <alexander.usyskin@intel.com>
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
7 years agosamples/seccomp: fix 64-bit comparison macros
Mathias Svensson [Fri, 6 Jan 2017 21:32:39 +0000 (13:32 -0800)]
samples/seccomp: fix 64-bit comparison macros

BugLink: http://bugs.launchpad.net/bugs/1672544
commit 916cafdc95843fb9af5fd5f83ca499d75473d107 upstream.

There were some bugs in the JNE64 and JLT64 comparision macros. This fixes
them, improves comments, and cleans up the file while we are at it.

Reported-by: Stephen Röttger <sroettger@google.com>
Signed-off-by: Mathias Svensson <idolf@google.com>
Signed-off-by: Kees Cook <keescook@chromium.org>
Signed-off-by: James Morris <james.l.morris@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
7 years agoext4: fix fencepost in s_first_meta_bg validation
Theodore Ts'o [Wed, 15 Feb 2017 06:26:39 +0000 (01:26 -0500)]
ext4: fix fencepost in s_first_meta_bg validation

BugLink: http://bugs.launchpad.net/bugs/1672544
commit 2ba3e6e8afc9b6188b471f27cf2b5e3cf34e7af2 upstream.

It is OK for s_first_meta_bg to be equal to the number of block group
descriptor blocks.  (It rarely happens, but it shouldn't cause any
problems.)

https://bugzilla.kernel.org/show_bug.cgi?id=194567

Fixes: 3a4b77cd47bb837b8557595ec7425f281f2ca1fe
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
7 years agoext4: return EROFS if device is r/o and journal replay is needed
Theodore Ts'o [Sun, 5 Feb 2017 06:26:48 +0000 (01:26 -0500)]
ext4: return EROFS if device is r/o and journal replay is needed

BugLink: http://bugs.launchpad.net/bugs/1672544
commit 4753d8a24d4588657bc0a4cd66d4e282dff15c8c upstream.

If the file system requires journal recovery, and the device is
read-ony, return EROFS to the mount system call.  This allows xfstests
generic/050 to pass.

Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
7 years agoext4: preserve the needs_recovery flag when the journal is aborted
Theodore Ts'o [Sun, 5 Feb 2017 04:38:06 +0000 (23:38 -0500)]
ext4: preserve the needs_recovery flag when the journal is aborted

BugLink: http://bugs.launchpad.net/bugs/1672544
commit 97abd7d4b5d9c48ec15c425485f054e1c15e591b upstream.

If the journal is aborted, the needs_recovery feature flag should not
be removed.  Otherwise, it's the journal might not get replayed and
this could lead to more data getting lost.

Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
7 years agoext4: fix inline data error paths
Theodore Ts'o [Sun, 5 Feb 2017 04:04:00 +0000 (23:04 -0500)]
ext4: fix inline data error paths

BugLink: http://bugs.launchpad.net/bugs/1672544
commit eb5efbcb762aee4b454b04f7115f73ccbcf8f0ef upstream.

The write_end() function must always unlock the page and drop its ref
count, even on an error.

Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
7 years agoext4: fix use-after-iput when fscrypt contexts are inconsistent
Eric Biggers [Thu, 2 Feb 2017 02:07:11 +0000 (21:07 -0500)]
ext4: fix use-after-iput when fscrypt contexts are inconsistent

BugLink: http://bugs.launchpad.net/bugs/1672544
commit dd01b690f8f4b1e414f89e5a9a5326bf720d6652 upstream.

In the case where the child's encryption context was inconsistent with
its parent directory, we were using inode->i_sb and inode->i_ino after
the inode had already been iput().  Fix this by doing the iput() in the
correct places.

Note: only ext4 had this bug, not f2fs and ubifs.

Fixes: d9cdc9033181 ("ext4 crypto: enforce context consistency")
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
7 years agoext4: fix data corruption in data=journal mode
Jan Kara [Fri, 27 Jan 2017 19:35:38 +0000 (14:35 -0500)]
ext4: fix data corruption in data=journal mode

BugLink: http://bugs.launchpad.net/bugs/1672544
commit 3b136499e906460919f0d21a49db1aaccf0ae963 upstream.

ext4_journalled_write_end() did not propely handle all the cases when
generic_perform_write() did not copy all the data into the target page
and could mark buffers with uninitialized contents as uptodate and dirty
leading to possible data corruption (which would be quickly fixed by
generic_perform_write() retrying the write but still). Fix the problem
by carefully handling the case when the page that is written to is not
uptodate.

Reported-by: Al Viro <viro@ZenIV.linux.org.uk>
Signed-off-by: Jan Kara <jack@suse.cz>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
7 years agoext4: trim allocation requests to group size
Jan Kara [Fri, 27 Jan 2017 19:34:30 +0000 (14:34 -0500)]
ext4: trim allocation requests to group size

BugLink: http://bugs.launchpad.net/bugs/1672544
commit cd648b8a8fd5071d232242d5ee7ee3c0815776af upstream.

If filesystem groups are artifically small (using parameter -g to
mkfs.ext4), ext4_mb_normalize_request() can result in a request that is
larger than a block group. Trim the request size to not confuse
allocation code.

Reported-by: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
Signed-off-by: Jan Kara <jack@suse.cz>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
7 years agoext4: do not polute the extents cache while shifting extents
Roman Pen [Mon, 9 Jan 2017 02:00:35 +0000 (21:00 -0500)]
ext4: do not polute the extents cache while shifting extents

BugLink: http://bugs.launchpad.net/bugs/1672544
commit 03e916fa8b5577d85471452a3d0c5738aa658dae upstream.

Inside ext4_ext_shift_extents() function ext4_find_extent() is called
without EXT4_EX_NOCACHE flag, which should prevent cache population.

This leads to oudated offsets in the extents tree and wrong blocks
afterwards.

Patch fixes the problem providing EXT4_EX_NOCACHE flag for each
ext4_find_extents() call inside ext4_ext_shift_extents function.

Fixes: 331573febb6a2
Signed-off-by: Roman Pen <roman.penyaev@profitbricks.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Cc: Namjae Jeon <namjae.jeon@samsung.com>
Cc: Andreas Dilger <adilger.kernel@dilger.ca>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
7 years agoext4: Include forgotten start block on fallocate insert range
Roman Pen [Mon, 9 Jan 2017 01:59:35 +0000 (20:59 -0500)]
ext4: Include forgotten start block on fallocate insert range

BugLink: http://bugs.launchpad.net/bugs/1672544
commit 2a9b8cba62c0741109c33a2be700ff3d7703a7c2 upstream.

While doing 'insert range' start block should be also shifted right.
The bug can be easily reproduced by the following test:

    ptr = malloc(4096);
    assert(ptr);

    fd = open("./ext4.file", O_CREAT | O_TRUNC | O_RDWR, 0600);
    assert(fd >= 0);

    rc = fallocate(fd, 0, 0, 8192);
    assert(rc == 0);
    for (i = 0; i < 2048; i++)
            *((unsigned short *)ptr + i) = 0xbeef;
    rc = pwrite(fd, ptr, 4096, 0);
    assert(rc == 4096);
    rc = pwrite(fd, ptr, 4096, 4096);
    assert(rc == 4096);

    for (block = 2; block < 1000; block++) {
            rc = fallocate(fd, FALLOC_FL_INSERT_RANGE, 4096, 4096);
            assert(rc == 0);

            for (i = 0; i < 2048; i++)
                    *((unsigned short *)ptr + i) = block;

            rc = pwrite(fd, ptr, 4096, 4096);
            assert(rc == 4096);
    }

Because start block is not included in the range the hole appears at
the wrong offset (just after the desired offset) and the following
pwrite() overwrites already existent block, keeping hole untouched.

Simple way to verify wrong behaviour is to check zeroed blocks after
the test:

   $ hexdump ./ext4.file | grep '0000 0000'

The root cause of the bug is a wrong range (start, stop], where start
should be inclusive, i.e. [start, stop].

This patch fixes the problem by including start into the range.  But
not to break left shift (range collapse) stop points to the beginning
of the a block, not to the end.

The other not obvious change is an iterator check on validness in a
main loop.  Because iterator is unsigned the following corner case
should be considered with care: insert a block at 0 offset, when stop
variables overflows and never becomes less than start, which is 0.
To handle this special case iterator is set to NULL to indicate that
end of the loop is reached.

Fixes: 331573febb6a2
Signed-off-by: Roman Pen <roman.penyaev@profitbricks.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Cc: Namjae Jeon <namjae.jeon@samsung.com>
Cc: Andreas Dilger <adilger.kernel@dilger.ca>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
7 years agoloop: fix LO_FLAGS_PARTSCAN hang
Omar Sandoval [Wed, 1 Mar 2017 18:42:38 +0000 (10:42 -0800)]
loop: fix LO_FLAGS_PARTSCAN hang

BugLink: http://bugs.launchpad.net/bugs/1672544
commit e02898b423802b1f3a3aaa7f16e896da069ba8f7 upstream.

loop_reread_partitions() needs to do I/O, but we just froze the queue,
so we end up waiting forever. This can easily be reproduced with losetup
-P. Fix it by moving the reread to after we unfreeze the queue.

Fixes: ecdd09597a57 ("block/loop: fix race between I/O and set_status")
Reported-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Omar Sandoval <osandov@fb.com>
Reviewed-by: Ming Lei <tom.leiming@gmail.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
7 years agoblock/loop: fix race between I/O and set_status
Ming Lei [Sat, 11 Feb 2017 03:40:45 +0000 (11:40 +0800)]
block/loop: fix race between I/O and set_status

BugLink: http://bugs.launchpad.net/bugs/1672544
commit ecdd09597a57251323b0de50e3d45e69298c4a83 upstream.

Inside set_status, transfer need to setup again, so
we have to drain IO before the transition, otherwise
oops may be triggered like the following:

divide error: 0000 [#1] SMP KASAN
CPU: 0 PID: 2935 Comm: loop7 Not tainted 4.10.0-rc7+ #213
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs
01/01/2011
task: ffff88006ba1e840 task.stack: ffff880067338000
RIP: 0010:transfer_xor+0x1d1/0x440 drivers/block/loop.c:110
RSP: 0018:ffff88006733f108 EFLAGS: 00010246
RAX: 0000000000000000 RBX: ffff8800688d7000 RCX: 0000000000000059
RDX: 0000000000000000 RSI: 1ffff1000d743f43 RDI: ffff880068891c08
RBP: ffff88006733f160 R08: ffff8800688d7001 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000000 R12: ffff8800688d7000
R13: ffff880067b7d000 R14: dffffc0000000000 R15: 0000000000000000
FS:  0000000000000000(0000) GS:ffff88006d000000(0000)
knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00000000006c17e0 CR3: 0000000066e3b000 CR4: 00000000001406f0
Call Trace:
 lo_do_transfer drivers/block/loop.c:251 [inline]
 lo_read_transfer drivers/block/loop.c:392 [inline]
 do_req_filebacked drivers/block/loop.c:541 [inline]
 loop_handle_cmd drivers/block/loop.c:1677 [inline]
 loop_queue_work+0xda0/0x49b0 drivers/block/loop.c:1689
 kthread_worker_fn+0x4c3/0xa30 kernel/kthread.c:630
 kthread+0x326/0x3f0 kernel/kthread.c:227
 ret_from_fork+0x31/0x40 arch/x86/entry/entry_64.S:430
Code: 03 83 e2 07 41 29 df 42 0f b6 04 30 4d 8d 44 24 01 38 d0 7f 08
84 c0 0f 85 62 02 00 00 44 89 f8 41 0f b6 48 ff 25 ff 01 00 00 99 <f7>
7d c8 48 63 d2 48 03 55 d0 48 89 d0 48 89 d7 48 c1 e8 03 83
RIP: transfer_xor+0x1d1/0x440 drivers/block/loop.c:110 RSP:
ffff88006733f108
---[ end trace 0166f7bd3b0c0933 ]---

Reported-by: Dmitry Vyukov <dvyukov@google.com>
Signed-off-by: Ming Lei <tom.leiming@gmail.com>
Tested-by: Dmitry Vyukov <dvyukov@google.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
7 years agojbd2: don't leak modified metadata buffers on an aborted journal
Theodore Ts'o [Sun, 5 Feb 2017 04:14:19 +0000 (23:14 -0500)]
jbd2: don't leak modified metadata buffers on an aborted journal

BugLink: http://bugs.launchpad.net/bugs/1672544
commit e112666b4959b25a8552d63bc564e1059be703e8 upstream.

If the journal has been aborted, we shouldn't mark the underlying
buffer head as dirty, since that will cause the metadata block to get
modified.  And if the journal has been aborted, we shouldn't allow
this since it will almost certainly lead to a corrupted file system.

Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
7 years agoFix: Disable sys_membarrier when nohz_full is enabled
Mathieu Desnoyers [Thu, 3 Nov 2016 16:29:28 +0000 (10:29 -0600)]
Fix: Disable sys_membarrier when nohz_full is enabled

BugLink: http://bugs.launchpad.net/bugs/1672544
commit 907565337ebf998a68cb5c5b2174ce5e5da065eb upstream.

Userspace applications should be allowed to expect the membarrier system
call with MEMBARRIER_CMD_SHARED command to issue memory barriers on
nohz_full CPUs, but synchronize_sched() does not take those into
account.

Given that we do not want unrelated processes to be able to affect
real-time sensitive nohz_full CPUs, simply return ENOSYS when membarrier
is invoked on a kernel with enabled nohz_full CPUs.

Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
CC: Josh Triplett <josh@joshtriplett.org>
CC: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Chris Metcalf <cmetcalf@mellanox.com>
Cc: Rik van Riel <riel@redhat.com>
Acked-by: Lai Jiangshan <jiangshanlai@gmail.com>
Reviewed-by: Josh Triplett <josh@joshtriplett.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
7 years agopower: reset: at91-poweroff: timely shutdown LPDDR memories
Alexandre Belloni [Tue, 25 Oct 2016 09:37:59 +0000 (11:37 +0200)]
power: reset: at91-poweroff: timely shutdown LPDDR memories

BugLink: http://bugs.launchpad.net/bugs/1672544
commit 0b0408745e7ff24757cbfd571d69026c0ddb803c upstream.

LPDDR memories can only handle up to 400 uncontrolled power off. Ensure the
proper power off sequence is used before shutting down the platform.

Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
7 years agoscsi: use 'scsi_device_from_queue()' for scsi_dh
Hannes Reinecke [Fri, 17 Feb 2017 08:02:45 +0000 (09:02 +0100)]
scsi: use 'scsi_device_from_queue()' for scsi_dh

BugLink: http://bugs.launchpad.net/bugs/1672544
commit 857de6e00778738dc3d61f75acbac35bdc48e533 upstream.

The device handler needs to check if a given queue belongs to a scsi
device; only then does it make sense to attach a device handler.

[mkp: dropped flags]

Signed-off-by: Hannes Reinecke <hare@suse.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
7 years agoscsi: aacraid: Reorder Adapter status check
Raghava Aditya Renukunta [Thu, 16 Feb 2017 20:51:21 +0000 (12:51 -0800)]
scsi: aacraid: Reorder Adapter status check

BugLink: http://bugs.launchpad.net/bugs/1672544
commit c421530bf848604e97d0785a03b3fe2c62775083 upstream.

The driver currently checks the SELF_TEST_FAILED first and then
KERNEL_PANIC next. Under error conditions(boot code failure) both
SELF_TEST_FAILED and KERNEL_PANIC can be set at the same time.

The driver has the capability to reset the controller on an KERNEL_PANIC,
but not on SELF_TEST_FAILED.

Fixed by first checking KERNEL_PANIC and then the others.

Fixes: e8b12f0fb835223752 ([SCSI] aacraid: Add new code for PMC-Sierra's SRC base controller family)
Signed-off-by: Raghava Aditya Renukunta <RaghavaAditya.Renukunta@microsemi.com>
Reviewed-by: David Carroll <David.Carroll@microsemi.com>
Reviewed-by: Johannes Thumshirn <jthumshirn@suse.de>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
7 years agoRevert "scsi: aacraid: Reorder Adapter status check"
Tim Gardner [Mon, 13 Mar 2017 21:01:22 +0000 (15:01 -0600)]
Revert "scsi: aacraid: Reorder Adapter status check"

BugLink: http://bugs.launchpad.net/bugs/1672544
This reverts commit 50fdf33266027d8629d29adc35dec0f9635b29f3.

Revert in favor of upstream stable.

Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
7 years agoscsi: qla2xxx: Fix Regression introduced by pci_alloc_irq_vectors_affinity call.
Michael Hernandez [Wed, 15 Feb 2017 23:37:21 +0000 (15:37 -0800)]
scsi: qla2xxx: Fix Regression introduced by pci_alloc_irq_vectors_affinity call.

BugLink: http://bugs.launchpad.net/bugs/1672544
commit 67f2db8792f96d8f7521461635d25f9c80245d80 upstream.

For target mode, we need to increase minimum vectors value by one to
account for ATIO queue.

Following stack trace will be seen

Call Trace:
qla24xx_config_rings+0x15a/0x230 [qla2xxx]
qla2x00_init_rings+0x1a1/0x3a0 [qla2xxx]
qla2x00_restart_isp+0x5c/0x120 [qla2xxx]
qla2x00_abort_isp+0x138/0x430 [qla2xxx]
? __schedule+0x260/0x580
qla2x00_do_dpc+0x3bc/0x920 [qla2xxx]
? qla2x00_relogin+0x290/0x290 [qla2xxx]
? schedule+0x3a/0xa0
? qla2x00_relogin+0x290/0x290 [qla2xxx]
kthread+0x103/0x140
? __kthread_init_worker+0x40/0x40
ret_from_fork+0x29/0x40

RIP: qlt_24xx_config_rings+0x6c/0x90

[mkp: fixed Fixes: hash]

Fixes: 17e5fc58588b ("scsi: qla2xxx: fix MSI-X vector affinity")
Signed-off-by: Michael Hernandez <michael.hernandez@cavium.com>
Signed-off-by: Himanshu Madhani <himanshu.madhani@cavium.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
7 years agoscsi: qla2xxx: Fix response queue count for Target mode.
Michael Hernandez [Wed, 15 Feb 2017 23:37:20 +0000 (15:37 -0800)]
scsi: qla2xxx: Fix response queue count for Target mode.

BugLink: http://bugs.launchpad.net/bugs/1672544
commit d0d2c68b759bbf678e078fd0c71b5fde65a9392c upstream.

Target mode initialization was not calculating response queue values
correctly resulting into one less MSI-X vector.

[mkp: fixed Fixes: hash]

Fixes: 093df73771ba ("scsi: qla2xxx: Fix Target mode handling with Multiqueue changes.")
Signed-off-by: Michael Hernandez <michael.hernandez@cavium.com>
Signed-off-by: Himanshu Madhani <himanshu.madhani@cavium.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
7 years agoscsi: qla2xxx: Cleaned up queue configuration code.
Michael Hernandez [Wed, 15 Feb 2017 23:37:19 +0000 (15:37 -0800)]
scsi: qla2xxx: Cleaned up queue configuration code.

BugLink: http://bugs.launchpad.net/bugs/1672544
commit f54f2cb540b53d55a81d620e816810d59be5cb1b upstream.

This patch cleaned up queue configuration code, such that once
initialized, we should not touch msix_count value.  This will prevent
incorrect numbers of MSI-X vectors requested while performing target
mode configuration.

[mkp: fixed Fixes: hash]

Fixes: d74595278f4a ("scsi: qla2xxx: Add multiple queue pair functionality.")
Signed-off-by: Michael Hernandez <michael.hernandez@cavium.com>
Signed-off-by: Himanshu Madhani <himanshu.madhani@cavium.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
7 years agodm raid: fix data corruption on reshape request
Heinz Mauelshagen [Tue, 28 Feb 2017 18:17:49 +0000 (19:17 +0100)]
dm raid: fix data corruption on reshape request

BugLink: http://bugs.launchpad.net/bugs/1672544
commit d36a19541fe8f392778ac137d60f9be8dfdd8f9d upstream.

The lvm2 sequence to manage dm-raid constructor flags that trigger a
rebuild or a reshape is defined as:

1) load table with flags (e.g. rebuild/delta_disks/data_offset)
2) clear out the flags in lvm2 metadata
3) store the lvm2 metadata, reload the table to reset the flags
   previously established during the initial load (1) -- in order to
   prevent repeatedly requesting a rebuild or a reshape on activation

Currently, loading an inactive table with rebuild/reshape flags
specified will cause dm-raid to rebuild/reshape on resume and thus start
updating the raid metadata (about the progress).  When the second table
reload, to reset the flags, occurs the constructor accesses the volatile
progress state kept in the raid superblocks.  Because the active mapping
is still processing the rebuild/reshape, that position will be stale by
the time the device is resumed.

In the reshape case, this causes data corruption by processing already
reshaped stripes again.  In the rebuild case, it does _not_ cause data
corruption but instead involves superfluous rebuilds.

Fix by keeping the raid set frozen during the first resume and then
allow the rebuild/reshape during the second resume.

Fixes: 9dbd1aa3a ("dm raid: add reshaping support to the target")
Signed-off-by: Heinz Mauelshagen <heinzm@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
7 years agodm round robin: revert "use percpu 'repeat_count' and 'current_path'"
Mike Snitzer [Fri, 17 Feb 2017 04:57:17 +0000 (23:57 -0500)]
dm round robin: revert "use percpu 'repeat_count' and 'current_path'"

BugLink: http://bugs.launchpad.net/bugs/1672544
commit 37a098e9d10db6e2efc05fe61e3a6ff2e9802c53 upstream.

The sloppy nature of lockless access to percpu pointers
(s->current_path) in rr_select_path(), from multiple threads, is
causing some paths to used more than others -- which results in less
IO performance being observed.

Revert these upstream commits to restore truly symmetric round-robin
IO submission in DM multipath:

b0b477c dm round robin: use percpu 'repeat_count' and 'current_path'
802934b dm round robin: do not use this_cpu_ptr() without having preemption disabled

There is no benefit to all this complexity if repeat_count = 1 (which is
the recommended default).

Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
7 years agodm stats: fix a leaked s->histogram_boundaries array
Mikulas Patocka [Wed, 15 Feb 2017 17:06:19 +0000 (12:06 -0500)]
dm stats: fix a leaked s->histogram_boundaries array

BugLink: http://bugs.launchpad.net/bugs/1672544
commit 6085831883c25860264721df15f05bbded45e2a2 upstream.

Fixes: dfcfac3e4cd9 ("dm stats: collect and report histogram of IO latencies")
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
7 years agodm cache: fix corruption seen when using cache > 2TB
Joe Thornber [Thu, 9 Feb 2017 16:46:18 +0000 (11:46 -0500)]
dm cache: fix corruption seen when using cache > 2TB

BugLink: http://bugs.launchpad.net/bugs/1672544
commit ca763d0a53b264a650342cee206512bc92ac7050 upstream.

A rounding bug due to compiler generated temporary being 32bit was found
in remap_to_cache().  A localized cast in remap_to_cache() fixes the
corruption but this preferred fix (changing from uint32_t to sector_t)
eliminates potential for future rounding errors elsewhere.

Signed-off-by: Joe Thornber <ejt@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
7 years agoPM / devfreq: Fix wrong trans_stat of passive devfreq device
Chanwoo Choi [Tue, 31 Jan 2017 06:38:17 +0000 (15:38 +0900)]
PM / devfreq: Fix wrong trans_stat of passive devfreq device

BugLink: http://bugs.launchpad.net/bugs/1672544
commit 30582c25a4b4e0a5e456a309fde79b845e9473b2 upstream.

Until now, the trans_stat information of passive devfreq is not updated.
This patch updates the trans_stat information after setting the target
frequency of passive devfreq device.

Fixes: 996133119f57 ("PM / devfreq: Add new passive governor")
Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
7 years agoPM / devfreq: Fix available_governor sysfs
Chanwoo Choi [Tue, 31 Jan 2017 06:38:16 +0000 (15:38 +0900)]
PM / devfreq: Fix available_governor sysfs

BugLink: http://bugs.launchpad.net/bugs/1672544
commit bcf23c79c4e46130701370af4383b61a3cba755c upstream.

The devfreq using passive governor is not able to change the governor.
So, the user can not change the governor through 'available_governor' sysfs
entry. Also, the devfreq which don't use the passive governor is not able to
change to 'passive' governor on the fly.

Fixes: 996133119f57 ("PM / devfreq: Add new passive governor")
Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>