- 06 Dec, 2016 40 commits
-
-
Gregor Boirie authored
BugLink: https://launchpad.net/bugs/1642258 Implement lps22hb temperature sampling channel. Signed-off-by:
Gregor Boirie <gregor.boirie@parrot.com> Tested-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
Jonathan Cameron <jic23@kernel.org> (cherry-picked from commit 85d79136) Signed-off-by:
Shrirang Bagul <shrirang.bagul@canonical.com> Acked-by:
Stefan Bader <stefan.bader@canonical.com> Acked-by:
Tim Gardner <tim.gardner@canonical.com> Signed-off-by:
Luis Henriques <luis.henriques@canonical.com>
-
Gregor Boirie authored
BugLink: https://launchpad.net/bugs/1642258 Details scaling factors and offsets applied to raw temperature and pressure samples. Signed-off-by:
-
Gregor Boirie authored
BugLink: https://launchpad.net/bugs/1642258 Sampled pressure data are 24 bits long and should be stored in a 32 bits word. Signed-off-by:
-
Gregor Boirie authored
BugLink: https://launchpad.net/bugs/1642258 Initial support for ST LPS22HB pressure sensor. Datasheet: http://www2.st.com/resource/en/datasheet/lps22hb.pdf Features: * pressure data and timestamping channels * sampling frequency selection * interrupt based trigger * over I2C or SPI Signed-off-by:
-
Michael Cyr authored
BugLink: http://bugs.launchpad.net/bugs/1642299Signed-off-by:
Michael Cyr <mikecyr@us.ibm.com> Signed-off-by:
Bryant G. Ly <bryantly@linux.vnet.ibm.com> Signed-off-by:
Seth Forshee <seth.forshee@canonical.com> Signed-off-by:
-
Michael Cyr authored
BugLink: http://bugs.launchpad.net/bugs/1642299Signed-off-by:
-
Michael Cyr authored
BugLink: http://bugs.launchpad.net/bugs/1642299Signed-off-by:
-
Michael Cyr authored
BugLink: http://bugs.launchpad.net/bugs/1642299 This patch adds code to disconnect from the client, which will make sure any outstanding commands have been completed, before continuing on with the remove operation. Signed-off-by:
-
Michael Cyr authored
BugLink: http://bugs.launchpad.net/bugs/1642299 This patch changes the way the IBM vSCSI server driver manages its Command/Response Queue (CRQ). We used to register the CRQ with phyp at probe time. Now we wait until tpg_enable_store. Similarly, when tpg_enable_store is called to "disable" (i.e. the stored value is 0), we unregister the queue with phyp. One consquence to this is that we have no need for the PART_UP_WAIT_ENAB state, since we can't get an Init Message from the client in our CRQ if we're waiting to be enabled, since we haven't registered the queue yet. Signed-off-by:
-
Michael Cyr authored
BugLink: http://bugs.launchpad.net/bugs/1642299 This patch reorders functions in a manner necessary for a follow-on patch. It also makes some minor styling changes (mostly removing extra spaces) and fixes some typos. There are no code changes in this patch, with one exception: due to the reordering of the functions, I needed to explicitly declare a function at the top of the file. However, this will be removed in the next patch, since the code requiring the predeclaration will be removed. Signed-off-by:
-
Yuyang Du authored
BugLink: http://bugs.launchpad.net/bugs/1643797 If a newly created task is selected to go to a different CPU in fork balance when it wakes up the first time, its load averages should not be removed from the source CPU since they are never added to it before. The same is also applicable to a never used group entity. Fix it in remove_entity_load_avg(): when entity's last_update_time is 0, simply return. This should precisely identify the case in question, because in other migrations, the last_update_time is set to 0 after remove_entity_load_avg(). Reported-by:
Steve Muckle <steve.muckle@linaro.org> Signed-off-by:
Yuyang Du <yuyang.du@intel.com> [peterz: cfs_rq_last_update_time] Signed-off-by:
Peter Zijlstra (Intel) <peterz@infradead.org> Cc: Dietmar Eggemann <dietmar.eggemann@arm.com> Cc: Juri Lelli <Juri.Lelli@arm.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Mike Galbraith <efault@gmx.de> Cc: Morten Rasmussen <morten.rasmussen@arm.com> Cc: Patrick Bellasi <patrick.bellasi@arm.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Vincent Guittot <vincent.guittot@linaro.org> Link: http://lkml.kernel.org/r/20151216233427.GJ28098@intel.comSigned-off-by:
Ingo Molnar <mingo@kernel.org> (cherry picked from commit 0905f04e) Signed-off-by:
Phidias Chiang <phidias.chiang@canonical.com> Acked-by:
Robert Hooker <robert.hooker@canonical.com> Acked-by:
-
Rob Nelson authored
BugLink: http://bugs.launchpad.net/bugs/1637565 This change provides a mechanism to reduce the number of MMIO doorbell writes for the NVMe driver. When running in a virtualized environment like QEMU, the cost of an MMIO is quite hefy here. The main idea for the patch is provide the device two memory location locations: 1) to store the doorbell values so they can be lookup without the doorbell MMIO write 2) to store an event index. I believe the doorbell value is obvious, the event index not so much. Similar to the virtio specificaiton, the virtual device can tell the driver (guest OS) not to write MMIO unless you are writing past this value. FYI: doorbell values are written by the nvme driver (guest OS) and the event index is written by the virtual device (host OS). The patch implements a new admin command that will communicate where these two memory locations reside. If the command fails, the nvme driver will work as before without any optimizations. Contributions: Eric Northup <digitaleric@google.com> Frank Swiderski <fes@google.com> Ted Tso <tytso@mit.edu> Keith Busch <keith.busch@intel.com> Just to give an idea on the performance boost with the vendor extension: Running fio [1], a stock NVMe driver I get about 200K read IOPs with my vendor patch I get about 1000K read IOPs. This was running with a null device i.e. the backing device simply returned success on every read IO request. [1] Running on a 4 core machine: fio --time_based --name=benchmark --runtime=30 --filename=/dev/nvme0n1 --nrfiles=1 --ioengine=libaio --iodepth=32 --direct=1 --invalidate=1 --verify=0 --verify_fatal=0 --numjobs=4 --rw=randread --blocksize=4k --randrepeat=false Signed-off-by:
Rob Nelson <rlnelson@google.com> [mlin: port for upstream] Signed-off-by:
Ming Lin <mlin@kernel.org> [koike: updated for current APIs] Signed-off-by:
Helen Mae Koike Fornazier <helen.koike@collabora.co.uk> Signed-off-by:
-
Tim Gardner authored
BugLink: http://bugs.launchpad.net/bugs/1637565Signed-off-by:
-
Christoph Hellwig authored
BugLink: http://bugs.launchpad.net/bugs/1637565 The NVMe over Fabrics specification defines a protocol interface and related extensions to NVMe that enable operation over network protocols. The NVMe over Fabrics specification has an NVMe Transport binding for each NVMe Transport. This patch adds the fabrics related definitions: - fabric specific command set and error codes - transport addressing and binding definitions - fabrics sgl extensions - controller identification fabrics enhancements - discovery log page definition Signed-off-by:
Armen Baloyan <armenx.baloyan@intel.com> Signed-off-by:
James Smart <james.smart@broadcom.com> Signed-off-by:
Jay Freyensee <james.p.freyensee@intel.com> Signed-off-by:
Ming Lin <ming.l@ssi.samsung.com> Signed-off-by:
Sagi Grimberg <sagi@grimberg.me> Signed-off-by:
Christoph Hellwig <hch@lst.de> Reviewed-by:
Keith Busch <keith.busch@intel.com> Signed-off-by:
Jens Axboe <axboe@fb.com> (back ported from commit eb793e2c) Signed-off-by:
-
Ming Lin authored
BugLink: http://bugs.launchpad.net/bugs/1637565 For some protocols like NVMe over Fabrics we need to be able to send initialization commands to a specific queue. Based on an earlier patch from Christoph Hellwig <hch@lst.de>. Signed-off-by:
-
Tim Gardner authored
BugLink: http://bugs.launchpad.net/bugs/1642228Signed-off-by:
-
Jiri Pirko authored
BugLink: http://bugs.launchpad.net/bugs/1642514 The matchall classifier matches every packet and allows the user to apply actions on it. This filter is very useful in usecases where every packet should be matched, for example, packet mirroring (SPAN) can be setup very easily using that filter. Signed-off-by:
Jiri Pirko <jiri@mellanox.com> Signed-off-by:
Yotam Gigi <yotamg@mellanox.com> Signed-off-by:
David S. Miller <davem@davemloft.net> (cherry picked from commit bf3994d2) Signed-off-by:
-
Tim Gardner authored
BugLink: http://bugs.launchpad.net/bugs/1642514Signed-off-by:
-
Greg Kroah-Hartman authored
BugLink: http://bugs.launchpad.net/bugs/1643637Signed-off-by:
-
David S. Miller authored
BugLink: http://bugs.launchpad.net/bugs/1643637 [ Upstream commit 0fd0ff01 ] Now that all of the user copy routines are converted to return accurate residual lengths when an exception occurs, we no longer need the broken fixup routines. Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
-
David S. Miller authored
BugLink: http://bugs.launchpad.net/bugs/1643637 [ Upstream commit 614da3d9 ] All of __ret{,l}_mone{_asi,_fp,_asi_fpu} are now unused. Signed-off-by:
-
David S. Miller authored
BugLink: http://bugs.launchpad.net/bugs/1643637 [ Upstream commit ee841d0a ] Report the exact number of bytes which have not been successfully copied when an exception occurs, using the running remaining length. Signed-off-by:
-
David S. Miller authored
BugLink: http://bugs.launchpad.net/bugs/1643637 [ Upstream commit e93704e4 ] Report the exact number of bytes which have not been successfully copied when an exception occurs, using the running remaining length. Signed-off-by:
-
David S. Miller authored
BugLink: http://bugs.launchpad.net/bugs/1643637 [ Upstream commit 7ae3aaf5 ] Report the exact number of bytes which have not been successfully copied when an exception occurs, using the running remaining length. Signed-off-by:
-
David S. Miller authored
BugLink: http://bugs.launchpad.net/bugs/1643637 [ Upstream commit 95707704 ] Report the exact number of bytes which have not been successfully copied when an exception occurs, using the running remaining length. Signed-off-by:
-
David S. Miller authored
BugLink: http://bugs.launchpad.net/bugs/1643637 [ Upstream commit cb736fdb ] Report the exact number of bytes which have not been successfully copied when an exception occurs, using the running remaining length. Signed-off-by:
-
David S. Miller authored
BugLink: http://bugs.launchpad.net/bugs/1643637 [ Upstream commit d0796b55 ] Report the exact number of bytes which have not been successfully copied when an exception occurs, using the running remaining length. Signed-off-by:
-
David S. Miller authored
BugLink: http://bugs.launchpad.net/bugs/1643637 [ Upstream commit 0096ac9f ] Report the exact number of bytes which have not been successfully copied when an exception occurs, using the running remaining length. Signed-off-by:
-
David S. Miller authored
BugLink: http://bugs.launchpad.net/bugs/1643637 [ Upstream commit 83a17d26 ] The fixup helper function mechanism for handling user copy fault handling is not %100 accurrate, and can never be made so. We are going to transition the code to return the running return return length, which is always kept track in one or more registers of each of these routines. In order to convert them one by one, we have to allow the existing behavior to continue functioning. Therefore make all the copy code that wants the fixup helper to be used return negative one. After all of the user copy routines have been converted, this logic and the fixup helpers themselves can be removed completely. Signed-off-by:
-
David S. Miller authored
BugLink: http://bugs.launchpad.net/bugs/1643637 [ Upstream commit aa95ce36 ] It is completely unused. Signed-off-by:
-
David S. Miller authored
BugLink: http://bugs.launchpad.net/bugs/1643637 [ Upstream commit a74ad5e6 ] When the vmalloc area gets fragmented, and because the firmware mapping area sits between where modules live and the vmalloc area, we can sometimes receive requests for enormous kernel TLB range flushes. When this happens the cpu just spins flushing billions of pages and this triggers the NMI watchdog and other problems. We took care of this on the TSB side by doing a linear scan of the table once we pass a certain threshold. Do something similar for the TLB flush, however we are limited by the TLB flush facilities provided by the different chip variants. First of all we use an (mostly arbitrary) cut-off of 256K which is about 32 pages. This can be tuned in the future. The huge range code path for each chip works as follows: 1) On spitfire we flush all non-locked TLB entries using diagnostic acceses. 2) On cheetah we use the "flush all" TLB flush. 3) On sun4v/hypervisor we do a TLB context flush on context 0, which unlike previous chips does not remove "permanent" or locked entries. We could probably do something better on spitfire, such as limiting the flush to kernel TLB entries or even doing range comparisons. However that probably isn't worth it since those chips are old and the TLB only had 64 entries. Reported-by:
James Clarke <jrtc27@jrtc27.com> Tested-by:
-
David S. Miller authored
BugLink: http://bugs.launchpad.net/bugs/1643637 [ Upstream commit a236441b ] Just like the non-cross-call TLB flush handlers, the cross-call ones need to avoid doing PC-relative branches outside of their code blocks. Signed-off-by:
-
David S. Miller authored
BugLink: http://bugs.launchpad.net/bugs/1643637 [ Upstream commit 830cda3f ] Noticed by James Clarke. Signed-off-by:
-
David S. Miller authored
BugLink: http://bugs.launchpad.net/bugs/1643637 [ Upstream commit b429ae4d ] When we copy code over to patch another piece of code, we can only use PC-relative branches that target code within that piece of code. Such PC-relative branches cannot be made to external symbols because the patch moves the location of the code and thus modifies the relative address of external symbols. Use an absolute jmpl to fix this problem. Signed-off-by:
-
David S. Miller authored
BugLink: http://bugs.launchpad.net/bugs/1643637 [ Upstream commit 849c4987 ] If the number of pages we are flushing is more than twice the number of entries in the TSB, just scan the TSB table for matches rather than probing each and every page in the range. Based upon a patch and report by James Clarke. Signed-off-by:
-
James Clarke authored
BugLink: http://bugs.launchpad.net/bugs/1643637 [ Upstream commit 9d9fa230 ] Additionally, if the offset will overflow the immediate for a ba,pt instruction, fall back on a standard ba to get an extra 3 bits. Signed-off-by:
-
Mike Kravetz authored
BugLink: http://bugs.launchpad.net/bugs/1643637 [ Upstream commit af1b1a9b ] do_sparc64_fault() calculates both the base and huge page RSS sizes and uses this information in calls to tsb_grow(). The calculation for base page TSB size is not correct if the task uses hugetlb pages. hugetlb pages are not accounted for in RSS, therefore the call to get_mm_rss(mm) does not include hugetlb pages. However, the number of pages based on huge_pte_count (which does include hugetlb pages) is subtracted from this value. This will result in an artificially small and often negative RSS calculation. The base TSB size is then often set to max_tsb_size as the passed RSS is unsigned, so a negative value looks really big. THP pages are also accounted for in huge_pte_count, and THP pages are accounted for in RSS so the calculation in do_sparc64_fault() is correct if a task only uses THP pages. A single huge_pte_count is not sufficient for TSB sizing if both hugetlb and THP pages can be used. Instead of a single counter, use two: one for hugetlb and one for THP. Signed-off-by:
Mike Kravetz <mike.kravetz@oracle.com> Signed-off-by:
-
Dan Carpenter authored
BugLink: http://bugs.launchpad.net/bugs/1643637 [ Upstream commit 344e3c77 ] We accidentally take the "port->lock" twice in a row. This old code was supposed to be deleted. Fixes: e58e241c ('sparc: serial: Clean up the locking for -rt') Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
-
David S. Miller authored
BugLink: http://bugs.launchpad.net/bugs/1643637 [ Upstream commit 4f6deb8c ] On pre-Niagara systems, we fetch the fault address on data TLB exceptions from the TLB_TAG_ACCESS register. But this register also contains the context ID assosciated with the fault in the low 13 bits of the register value. This propagates into current_thread_info()->fault_address and can cause trouble later on. So clear the low 13-bits out of the TLB_TAG_ACCESS value in the cases where it matters. Reported-by:
Mikulas Patocka <mpatocka@redhat.com> Signed-off-by:
-
Peter Hurley authored
BugLink: http://bugs.launchpad.net/bugs/1643637 commit dd42bf11 upstream. Line discipline drivers may mistakenly misuse ldisc-related fields when initializing. For example, a failure to initialize tty->receive_room in the N_GIGASET_M101 line discipline was recently found and fixed [1]. Now, the N_X25 line discipline has been discovered accessing the previous line discipline's already-freed private data [2]. Harden the ldisc interface against misuse by initializing revelant tty fields before instancing the new line discipline. [1] commit fd98e941 Author: Tilman Schmidt <tilman@imap.cc> Date: Tue Jul 14 00:37:13 2015 +0200 isdn/gigaset: reset tty->receive_room when attaching ser_gigaset [2] Report from Sasha Levin <sasha.levin@oracle.com> [ 634.336761] ================================================================== [ 634.338226] BUG: KASAN: use-after-free in x25_asy_open_tty+0x13d/0x490 at addr ffff8800a743efd0 [ 634.339558] Read of size 4 by task syzkaller_execu/8981 [ 634.340359] ============================================================================= [ 634.341598] BUG kmalloc-512 (Not tainted): kasan: bad access detected ... [ 634.405018] Call Trace: [ 634.405277] dump_stack (lib/dump_stack.c:52) [ 634.405775] print_trailer (mm/slub.c:655) [ 634.406361] object_err (mm/slub.c:662) [ 634.406824] kasan_report_error (mm/kasan/report.c:138 mm/kasan/report.c:236) [ 634.409581] __asan_report_load4_noabort (mm/kasan/report.c:279) [ 634.411355] x25_asy_open_tty (drivers/net/wan/x25_asy.c:559 (discriminator 1)) [ 634.413997] tty_ldisc_open.isra.2 (drivers/tty/tty_ldisc.c:447) [ 634.414549] tty_set_ldisc (drivers/tty/tty_ldisc.c:567) [ 634.415057] tty_ioctl (drivers/tty/tty_io.c:2646 drivers/tty/tty_io.c:2879) [ 634.423524] do_vfs_ioctl (fs/ioctl.c:43 fs/ioctl.c:607) [ 634.427491] SyS_ioctl (fs/ioctl.c:622 fs/ioctl.c:613) [ 634.427945] entry_SYSCALL_64_fastpath (arch/x86/entry/entry_64.S:188) Cc: Tilman Schmidt <tilman@imap.cc> Cc: Sasha Levin <sasha.levin@oracle.com> Signed-off-by:
Peter Hurley <peter@hurleysoftware.com> Cc: Jiri Slaby <jslaby@suse.cz> Signed-off-by:
-
