[PATCH] PCI: Warn about host bridge device when its numa node is NO_NODE
As the disscusion in [1]: A PCI device really _MUST_ have a node assigned. It is possible to have a PCI bridge shared between two nodes, such that the PCI devices have equidistance. But the moment you scale this out, you either get devices that are 'local' to a package while having multiple packages, or if you maintain a single bridge in a big system, things become so slow it all doesn't matter anyway. Assigning a node (one of the shared) is, in the generic ase of multiple packages, the better solution over assigning all nodes. As pci_device_add() will assign the pci device' node according to the bus the device is on, which is decided by pcibus_to_node(). Currently different arch may implement the pcibus_to_node() based on bus->sysdata or bus device' node, which has the same node as the bridge device. And for devices behind another bridge case, the child bus device is setup with proper parent bus device and inherit its parent' sysdata in pci_alloc_child_bus(), so the pcie device under the child bus should have the same node as the parent bridge when device_add() is called, which will set the node to its parent's node when the child device' node is NUMA_NO_NODE. So this patch only warns about the case when a host bridge device is registered with a node of NO_NODE in pci_register_host_bridge(). And it only warns about that when there are more than one numa nodes in the system. [1] https://lore.kernel.org/lkml/1568724534-146242-1-git-send-email-linyunsh...@huawei.com/ Signed-off-by: Yunsheng Lin --- drivers/pci/probe.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c index 3d5271a..22be96a 100644 --- a/drivers/pci/probe.c +++ b/drivers/pci/probe.c @@ -927,6 +927,9 @@ static int pci_register_host_bridge(struct pci_host_bridge *bridge) list_add_tail(&bus->node, &pci_root_buses); up_write(&pci_bus_sem); + if (nr_node_ids > 1 && dev_to_node(bus->bridge) == NUMA_NO_NODE) + dev_err(bus->bridge, FW_BUG "No node assigned on NUMA capable HW by BIOS. Please contact your vendor for updates.\n"); + return 0; unregister: -- 2.8.1
broonie-spi/for-next boot bisection: v5.4-rc3-73-gc673f2d99c3d on jetson-tk1
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* This automated bisection report was sent to you on the basis *
* that you may be involved with the breaking commit it has *
* found. No manual investigation has been done to verify it, *
* and the root cause of the problem may be somewhere else. *
* *
* If you do send a fix, please include this trailer:*
* Reported-by: "kernelci.org bot" *
* *
* Hope this helps! *
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
broonie-spi/for-next boot bisection: v5.4-rc3-73-gc673f2d99c3d on jetson-tk1
Summary:
Start: c673f2d99c3d Merge remote-tracking branch 'spi/topic/ptp' into
spi-next
Details:https://kernelci.org/boot/id/5daa485f59b5142f647525a0
Plain log:
https://storage.kernelci.org//broonie-spi/for-next/v5.4-rc3-73-gc673f2d99c3d/arm/multi_v7_defconfig+CONFIG_SMP=n/gcc-8/lab-collabora/boot-tegra124-jetson-tk1.txt
HTML log:
https://storage.kernelci.org//broonie-spi/for-next/v5.4-rc3-73-gc673f2d99c3d/arm/multi_v7_defconfig+CONFIG_SMP=n/gcc-8/lab-collabora/boot-tegra124-jetson-tk1.html
Result: 3e5ec1db8bfe spi: Fix SPI_CS_HIGH setting when using native and
GPIO CS
Checks:
revert: PASS
verify: PASS
Parameters:
Tree: broonie-spi
URL:https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git
Branch: for-next
Target: jetson-tk1
CPU arch: arm
Lab:lab-collabora
Compiler: gcc-8
Config: multi_v7_defconfig+CONFIG_SMP=n
Test suite: boot
Breaking commit found:
---
commit 3e5ec1db8bfee845d9f8560d1c64aeaccd586398
Author: Gregory CLEMENT
Date: Fri Oct 18 17:29:29 2019 +0200
spi: Fix SPI_CS_HIGH setting when using native and GPIO CS
When improving the CS GPIO support at core level, the SPI_CS_HIGH
has been enabled for all the CS lines used for a given SPI controller.
However, the SPI framework allows to have on the same controller native
CS and GPIO CS. The native CS may not support the SPI_CS_HIGH, so they
should not be setup automatically.
With this patch the setting is done only for the CS that will use a
GPIO as CS
Fixes: f3186dd87669 ("spi: Optionally use GPIO descriptors for CS GPIOs")
Cc:
Signed-off-by: Gregory CLEMENT
Link:
https://lore.kernel.org/r/20191018152929.3287-1-gregory.clem...@bootlin.com
Signed-off-by: Mark Brown
diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c
index f8b4654a57d3..d07517151340 100644
--- a/drivers/spi/spi.c
+++ b/drivers/spi/spi.c
@@ -1711,15 +1711,7 @@ static int of_spi_parse_dt(struct spi_controller *ctlr,
struct spi_device *spi,
spi->mode |= SPI_3WIRE;
if (of_property_read_bool(nc, "spi-lsb-first"))
spi->mode |= SPI_LSB_FIRST;
-
- /*
-* For descriptors associated with the device, polarity inversion is
-* handled in the gpiolib, so all chip selects are "active high" in
-* the logical sense, the gpiolib will invert the line if need be.
-*/
- if (ctlr->use_gpio_descriptors)
- spi->mode |= SPI_CS_HIGH;
- else if (of_property_read_bool(nc, "spi-cs-high"))
+ if (of_property_read_bool(nc, "spi-cs-high"))
spi->mode |= SPI_CS_HIGH;
/* Device DUAL/QUAD mode */
@@ -1783,6 +1775,14 @@ static int of_spi_parse_dt(struct spi_controller *ctlr,
struct spi_device *spi,
}
spi->chip_select = value;
+ /*
+* For descriptors associated with the device, polarity inversion is
+* handled in the gpiolib, so all gpio chip selects are "active high"
+* in the logical sense, the gpiolib will invert the line if need be.
+*/
+ if ((ctlr->use_gpio_descriptors) && ctlr->cs_gpiods[spi->chip_select])
+ spi->mode |= SPI_CS_HIGH;
+
/* Device speed */
rc = of_property_read_u32(nc, "spi-max-frequency", &value);
if (rc) {
---
Git bisection log:
---
git bisect start
# good: [4f5cafb5cb8471e54afdc9054d973535614f7675] Linux 5.4-rc3
git bisect good 4f5cafb5cb8471e54afdc9054d973535614f7675
# bad: [c673f2d99c3d644733cc1b0ceabdec47047bbe80] Merge remote-tracking branch
'spi/topic/ptp' into spi-next
git bisect bad c673f2d99c3d644733cc1b0ceabdec47047bbe80
# good: [b2c98153f45fc17b9fcb241000f2d131ddea6030] spi: introduce spi_delay
struct as "value + unit" & spi_delay_exec()
git bisect good b2c98153f45fc17b9fcb241000f2d131ddea6030
# good: [4f3d957718e7f0ac2b033dbf48c7cddecd0a8dd3] spi: pxa2xx: No need to keep
Re: ARM: add __always_inline to functions called from __get_user_check()
> Am 19.10.2019 um 03:59 schrieb Masahiro Yamada > : > > On Fri, Oct 18, 2019 at 7:06 PM H. Nikolaus Schaller > wrote: >> >> Hi, >> I wonder what happened to your patch. We were "hit" by it in v5.4-rc1 and >> after finding, it made our OMAP based device bootable again (using our >> own defconfig which optimizes for SIZE). >> >> But it does not seem to have arrived in linux-next > > It is in linux-next. Ah, now I found it. It has a "8908/1:" in its title so that search by (full) subject could not find it. Thanks! > > >> and should IMHO >> be fixed during the v5.4 release candidate cycle. > > I agree. > > > Masahiro BR and thanks, Nikolaus
RE:PERSONAL LETTER FROM MRS RASHIA AMIRA
Greetings My name is Barrister Hans Erich. I have a client who is interested to invest in your country, she is a well known politician in her country and deserve a lucrative investment partnership with you outside her country without any delay Please can you manage such investment please Kindly reply for further details. Your full names - Your urgent response will be appreciated Thank you and God bless you. Barrister Hans Erich Yours sincerely, Barrister Hans Erich
mmotm 2019-10-18-22-40 uploaded
The mm-of-the-moment snapshot 2019-10-18-22-40 has been uploaded to http://www.ozlabs.org/~akpm/mmotm/ mmotm-readme.txt says README for mm-of-the-moment: http://www.ozlabs.org/~akpm/mmotm/ This is a snapshot of my -mm patch queue. Uploaded at random hopefully more than once a week. You will need quilt to apply these patches to the latest Linus release (5.x or 5.x-rcY). The series file is in broken-out.tar.gz and is duplicated in http://ozlabs.org/~akpm/mmotm/series The file broken-out.tar.gz contains two datestamp files: .DATE and .DATE--mm-dd-hh-mm-ss. Both contain the string -mm-dd-hh-mm-ss, followed by the base kernel version against which this patch series is to be applied. This tree is partially included in linux-next. To see which patches are included in linux-next, consult the `series' file. Only the patches within the #NEXT_PATCHES_START/#NEXT_PATCHES_END markers are included in linux-next. A full copy of the full kernel tree with the linux-next and mmotm patches already applied is available through git within an hour of the mmotm release. Individual mmotm releases are tagged. The master branch always points to the latest release, so it's constantly rebasing. http://git.cmpxchg.org/cgit.cgi/linux-mmotm.git/ The directory http://www.ozlabs.org/~akpm/mmots/ (mm-of-the-second) contains daily snapshots of the -mm tree. It is updated more frequently than mmotm, and is untested. A git copy of this tree is available at http://git.cmpxchg.org/cgit.cgi/linux-mmots.git/ and use of this tree is similar to http://git.cmpxchg.org/cgit.cgi/linux-mmotm.git/, described above. This mmotm tree contains the following patches against 5.4-rc3: (patches marked "*" will be included in linux-next) origin.patch * drivers-base-memoryc-dont-access-uninitialized-memmaps-in-soft_offline_page_store.patch * mm-dont-access-uninitialized-memmaps-in-fs-proc-pagec.patch * mm-memory-failurec-dont-access-uninitialized-memmaps-in-memory_failure.patch * scripts-gdb-fix-lx-dmesg-when-config_printk_caller-is-set.patch * mm-page_owner-dont-access-uninitialized-memmaps-when-reading-proc-pagetypeinfo.patch * mm-memory_hotplug-dont-access-uninitialized-memmaps-in-shrink_pgdat_span.patch * mm-memunmap-dont-access-uninitialized-memmap-in-memunmap_pages.patch * mm-memcg-slab-fix-panic-in-__free_slab-caused-by-premature-memcg-pointer-release.patch * resend-ocfs2-fix-error-handling-in-ocfs2_setattr.patch * mm-gup_benchmark-add-a-missing-w-to-getopt-string.patch * mm-gup-fix-a-misnamed-write-argument-and-a-related-bug.patch * mm-vmscan-get-number-of-pages-on-the-lru-list-in-memcgroup-base-on-lru_zone_size.patch * mm-memblock-do-not-enforce-current-limit-for-memblock_phys-family.patch * hugetlbfs-dont-access-uninitialized-memmaps-in-pfn_range_valid_gigantic.patch * ocfs2-fix-panic-due-to-ocfs2_wq-is-null.patch * mm-memcontrol-update-lruvec-counters-in-mem_cgroup_move_account.patch * zram-fix-race-between-backing_dev_show-and-backing_dev_store.patch * mm-include-linux-huge_mmh-for-is_vma_temporary_stack.patch * mm-include-linux-ramfsh-for-generic_file_vm_ops-definition.patch * mm-include-linux-mmanh-for-vm_committed_as_batch.patch * proc-meminfo-fix-output-alignment.patch * mm-thp-fix-node-page-state-in-split_huge_page_to_list.patch * mm-support-removing-arbitrary-sized-pages-from-mapping.patch * mm-thp-allow-drop-thp-from-page-cache.patch * uprobe-only-do-foll_split_pmd-for-uprobe-register.patch * scripts-gdb-fix-debugging-modules-on-s390.patch * proc-kpageflags-prevent-an-integer-overflow-in-stable_page_flags.patch * proc-kpageflags-do-not-use-uninitialized-struct-pages.patch * mmthp-recheck-each-page-before-collapsing-file-thp.patch * mm-memcontrol-fix-null-ptr-deref-in-percpu-stats-flush.patch * mm-meminit-recalculate-pcpu-batch-and-high-limits-after-init-completes.patch * ocfs2-protect-extent-tree-in-the-ocfs2_prepare_inode_for_write.patch * ocfs2-protect-extent-tree-in-the-ocfs2_prepare_inode_for_write-checkpatch-fixes.patch * ocfs2-remove-unused-function-ocfs2_prepare_inode_for_refcount.patch * ocfs2-fix-passing-zero-to-ptr_err-warning.patch * ramfs-support-o_tmpfile.patch mm.patch * mm-slab-make-kmalloc_info-contain-all-types-of-names.patch * mm-slab-remove-unused-kmalloc_size.patch * mm-slab_common-use-enum-kmalloc_cache_type-to-iterate-over-kmalloc-caches.patch * mm-slub-print-the-offset-of-fault-addresses.patch * mm-update-comments-in-slubc.patch * mm-swap-disallow-swapon-on-zoned-block-devices.patch * mm-swap-disallow-swapon-on-zoned-block-devices-fix.patch * mm-trivial-mark_page_accessed-cleanup.patch * mm-memcg-clean-up-reclaim-iter-array.patch * mm-vmscan-expose-cgroup_ino-for-memcg-reclaim-tracepoints.patch * mm-vmstat-add-helpers-to-get-vmstat-item-names-for-each-enum-type.patch * mm-memcontrol-use-vmstat-names-for-printing-statistics.patch * mm-drop-mmap_sem-before-calling-balance_dirty_pages-in-write-fault.patch * shmem-pin-the-file-in-shmem_fault-if-mmap_sem-is-dropped.patch
RE:PERSONAL LETTER FROM MRS RASHIA AMIRA
Greetings My name is Barrister Hans Erich. I have a client who is interested to invest in your country, she is a well known politician in her country and deserve a lucrative investment partnership with you outside her country without any delay Please can you manage such investment please Kindly reply for further details. Your full names - Your urgent response will be appreciated Thank you and God bless you. Barrister Hans Erich Yours sincerely, Barrister Hans Erich
Re: [PATCH v3] mm,thp: recheck each page before collapsing file THP
> On Oct 18, 2019, at 6:17 PM, Andrew Morton wrote:
>
> On Fri, 18 Oct 2019 11:03:45 -0700 Song Liu wrote:
>
>> In collapse_file(), after locking the page, it is necessary to recheck
>> that the page is up-to-date. Add PageUptodate() check for both shmem THP
>> and file THP.
>>
>> Current khugepaged should not try to collapse dirty file THP, because it
>> is limited to read only text. Add a PageDirty check and warning for file
>> THP. This is added after page_mapping() check, because if the page is
>> truncated, it might be dirty.
>
> When fixing a bug, please always fully describe the end-user visible
> effects of that bug. This is vital information for people who are
> considering the fix for backporting.
The end user effect is, corruption in page cache. While grouping pages
into a huge page, the page cache mistakenly includes some pages that
are not uptodate, and considers the huge page is uptodate.
I am attaching updated commit log to the end.
>
> I'm suspecting that you've found a race condition which can trigger a
> VM_BUG_ON_PAGE(), which is rather serious. But that was just a wild
> guess. Please don't make us wildly guess :(
>
> The old code looked rather alarming:
>
> } else if (!PageUptodate(page)) {
> xas_unlock_irq(&xas);
> wait_on_page_locked(page);
> if (!trylock_page(page)) {
> result = SCAN_PAGE_LOCK;
> goto xa_unlocked;
> }
> get_page(page);
>
> We don't have a ref on that page. After we've released the xarray lock
> we have no business playing with *page at all, correct?
Yeah, this piece is not just redundant, but also buggy. I am also
including some information about it.
Updated commit log:
= 8< =
In collapse_file(), for !is_shmem case, current check cannot guarantee
the locked page is up-to-date. Specifically, xas_unlock_irq() should not
be called before lock_page() and get_page(); and it is necessary to
recheck PageUptodate() after locking the page.
With this bug and CONFIG_READ_ONLY_THP_FOR_FS=y, madvise(HUGE)'ed .text
may contain corrupted data. This is because khugepaged mistakenly
collapses some not up-to-date sub pages into a huge page, and assumes the
huge page is up-to-date. This will NOT corrupt data in the disk, because
the page is read-only and never written back. Fix this by properly
checking PageUptodate() after locking the page. This check replaces
"VM_BUG_ON_PAGE(!PageUptodate(page), page);".
Also, move PageDirty() check after locking the page. Current khugepaged
should not try to collapse dirty file THP, because it is limited to
read-only .text. Add a warning with the PageDirty() check as it should
not happen. This warning is added after page_mapping() check, because
if the page is truncated, it might be dirty.
Fixes: 99cb0dbd47a1 ("mm,thp: add read-only THP support for (non-shmem) FS")
Cc: Kirill A. Shutemov
Cc: Johannes Weiner
Cc: Hugh Dickins
Cc: William Kucharski
Cc: Andrew Morton
Signed-off-by: Song Liu
= 8< =
Thanks,
Song
KASAN: use-after-free Read in fuse_request_end
Hello,
syzbot found the following crash on:
HEAD commit:283ea345 coccinelle: api/devm_platform_ioremap_resource: r..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=13afce90e0
kernel config: https://syzkaller.appspot.com/x/.config?x=e0ac4d9b35046343
dashboard link: https://syzkaller.appspot.com/bug?extid=ae0bb7aae3de6b4594e2
compiler: gcc (GCC) 9.0.0 20181231 (experimental)
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=14018fa0e0
The bug was bisected to:
commit d49937749fef2597f6bcaf2a0ed67e88e347b7fb
Author: Miklos Szeredi
Date: Tue Sep 10 13:04:11 2019 +
fuse: stop copying args to fuse_req
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=1611092760
final crash:https://syzkaller.appspot.com/x/report.txt?x=1511092760
console output: https://syzkaller.appspot.com/x/log.txt?x=092760
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+ae0bb7aae3de6b459...@syzkaller.appspotmail.com
Fixes: d49937749fef ("fuse: stop copying args to fuse_req")
==
BUG: KASAN: use-after-free in fuse_request_end+0x825/0x990 fs/fuse/dev.c:279
Read of size 8 at addr 8880a15b8468 by task syz-executor.0/8726
CPU: 0 PID: 8726 Comm: syz-executor.0 Not tainted 5.4.0-rc3+ #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x172/0x1f0 lib/dump_stack.c:113
print_address_description.constprop.0.cold+0xd4/0x30b mm/kasan/report.c:374
__kasan_report.cold+0x1b/0x41 mm/kasan/report.c:506
kasan_report+0x12/0x20 mm/kasan/common.c:634
__asan_report_load8_noabort+0x14/0x20 mm/kasan/generic_report.c:132
fuse_request_end+0x825/0x990 fs/fuse/dev.c:279
fuse_dev_do_read.isra.0+0x115b/0x1df0 fs/fuse/dev.c:1295
fuse_dev_read+0x165/0x200 fs/fuse/dev.c:1328
call_read_iter include/linux/fs.h:1889 [inline]
new_sync_read+0x4d7/0x800 fs/read_write.c:414
__vfs_read+0xe1/0x110 fs/read_write.c:427
vfs_read+0x1f0/0x440 fs/read_write.c:461
ksys_read+0x14f/0x290 fs/read_write.c:587
__do_sys_read fs/read_write.c:597 [inline]
__se_sys_read fs/read_write.c:595 [inline]
__x64_sys_read+0x73/0xb0 fs/read_write.c:595
do_syscall_64+0xfa/0x760 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x459a59
Code: fd b7 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7
48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff
ff 0f 83 cb b7 fb ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:7f764c086c78 EFLAGS: 0246 ORIG_RAX:
RAX: ffda RBX: 0003 RCX: 00459a59
RDX: fed0 RSI: 200030c0 RDI: 0003
RBP: 0075bfc8 R08: R09:
R10: R11: 0246 R12: 7f764c0876d4
R13: 004c70e6 R14: 004dca70 R15:
Allocated by task 8726:
save_stack+0x23/0x90 mm/kasan/common.c:69
set_track mm/kasan/common.c:77 [inline]
__kasan_kmalloc mm/kasan/common.c:510 [inline]
__kasan_kmalloc.constprop.0+0xcf/0xe0 mm/kasan/common.c:483
kasan_kmalloc+0x9/0x10 mm/kasan/common.c:524
kmem_cache_alloc_trace+0x158/0x790 mm/slab.c:3550
kmalloc include/linux/slab.h:556 [inline]
kzalloc include/linux/slab.h:690 [inline]
fuse_send_init+0x48/0x440 fs/fuse/inode.c:974
fuse_fill_super+0x2a6/0x3a0 fs/fuse/inode.c:1257
vfs_get_super+0x13e/0x2e0 fs/super.c:1189
get_tree_nodev+0x23/0x30 fs/super.c:1219
fuse_get_tree+0x12e/0x190 fs/fuse/inode.c:1282
vfs_get_tree+0x8e/0x300 fs/super.c:1545
do_new_mount fs/namespace.c:2823 [inline]
do_mount+0x143d/0x1d10 fs/namespace.c:3143
ksys_mount+0xdb/0x150 fs/namespace.c:3352
__do_sys_mount fs/namespace.c:3366 [inline]
__se_sys_mount fs/namespace.c:3363 [inline]
__x64_sys_mount+0xbe/0x150 fs/namespace.c:3363
do_syscall_64+0xfa/0x760 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
Freed by task 8724:
save_stack+0x23/0x90 mm/kasan/common.c:69
set_track mm/kasan/common.c:77 [inline]
kasan_set_free_info mm/kasan/common.c:332 [inline]
__kasan_slab_free+0x102/0x150 mm/kasan/common.c:471
kasan_slab_free+0xe/0x10 mm/kasan/common.c:480
__cache_free mm/slab.c:3425 [inline]
kfree+0x10a/0x2c0 mm/slab.c:3756
process_init_reply+0xfb/0x1620 fs/fuse/inode.c:964
fuse_request_end+0x388/0x990 fs/fuse/dev.c:326
end_requests+0x16c/0x240 fs/fuse/dev.c:2049
fuse_abort_conn+0xa4d/0xdb0 fs/fuse/dev.c:2144
fuse_sb_destroy+0xa3/0x120 fs/fuse/inode.c:1325
fuse_kill_sb_anon+0x16/0x30 fs/fuse/inode.c:1336
deactivate_locked_super+0x95/0x100 fs/super.c:335
deactivate_super fs/super.c:366 [inline]
deactivate_super+0x1b2/0x1d0 fs/super.c:362
cleanup_mnt+0x351/0x4c0 fs/namespace.c:1102
__cleanup_mnt+0x16/0x20 fs/namespace.c:1109
task_work_run+0x145/0x1c0 kernel/task_work.c:113
tr
RE:PERSONAL LETTER FROM MRS RASHIA AMIRA
Greetings My name is Barrister Hans Erich. I have a client who is interested to invest in your country, she is a well known politician in her country and deserve a lucrative investment partnership with you outside her country without any delay Please can you manage such investment please Kindly reply for further details. Your full names - Your urgent response will be appreciated Thank you and God bless you. Barrister Hans Erich Yours sincerely, Barrister Hans Erich
RE:PERSONAL LETTER FROM MRS RASHIA AMIRA
Greetings My name is Barrister Hans Erich. I have a client who is interested to invest in your country, she is a well known politician in her country and deserve a lucrative investment partnership with you outside her country without any delay Please can you manage such investment please Kindly reply for further details. Your full names - Your urgent response will be appreciated Thank you and God bless you. Barrister Hans Erich Yours sincerely, Barrister Hans Erich
Re: [PATCH v4 2/2] iio: (bma400) add driver for the BMA400
On Fri, 2019-10-18 at 03:18 +, Dan Robertson wrote:
> Add a IIO driver for the Bosch BMA400 3-axes ultra-low power accelerometer.
> The driver supports reading from the acceleration and temperature
> registers. The driver also supports reading and configuring the output data
> rate, oversampling ratio, and scale.
trivial logging note:
> diff --git a/drivers/iio/accel/bma400_core.c b/drivers/iio/accel/bma400_core.c
[]
> +static int bma400_get_accel_reg(struct bma400_data *data,
> + const struct iio_chan_spec *chan,
> + int *val)
> +{
[]
> + dev_err(data->dev, "invalid axis channel modifier");
All the logging should use \n terminations
dev_err(data->dev, "invalid axis channel modifier\n");
[]
> +static int bma400_get_accel_output_data_rate(struct bma400_data *data)
> +{
[]
> + dev_err(data->dev, "invalid ODR=%x", odr);
should be:
dev_err(data->dev, "invalid ODR=%x\n", odr);
etc...
Re: memory leak in copy_net_ns
Hello, syzbot has tested the proposed patch and the reproducer did not trigger crash: Reported-and-tested-by: syzbot+3b3296d032353c331...@syzkaller.appspotmail.com Tested on: commit: 43b815c6 Merge tag 'armsoc-fixes' of git://git.kernel.org/.. git tree: https://github.com/google/kasan.git kernel config: https://syzkaller.appspot.com/x/.config?x=d9ba1b8c7fca2c71 dashboard link: https://syzkaller.appspot.com/bug?extid=3b3296d032353c33184b compiler: gcc (GCC) 9.0.0 20181231 (experimental) patch: https://syzkaller.appspot.com/x/patch.diff?x=118f59e8e0 Note: testing is done by a robot and is best-effort only.
Re: memory leak in copy_net_ns
#syz test: https://github.com/google/kasan.git 43b815c6 >From 366b85e1555a8ef4d0f0759c2da8d8dff4598ace Mon Sep 17 00:00:00 2001 From: Takeshi Misawa Date: Sat, 19 Oct 2019 11:44:45 +0900 Subject: [PATCH] keys: Fix memory leak in copy_net_ns If copy_net_ns() failed after net_alloc(), net->key_domain is leaked. Fix this, by freeing key_domain in error path. syzbot report: BUG: memory leak unreferenced object 0x8881175007e0 (size 32): comm "syz-executor902", pid 7069, jiffies 4294944350 (age 28.400s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 backtrace: [] kmemleak_alloc_recursive include/linux/kmemleak.h:43 [inline] [ ] slab_post_alloc_hook mm/slab.h:439 [inline] [ ] slab_alloc mm/slab.c:3326 [inline] [ ] kmem_cache_alloc_trace+0x13d/0x280 mm/slab.c:3553 [<59fc92b9>] kmalloc include/linux/slab.h:547 [inline] [<59fc92b9>] kzalloc include/linux/slab.h:742 [inline] [<59fc92b9>] net_alloc net/core/net_namespace.c:398 [inline] [<59fc92b9>] copy_net_ns+0xb2/0x220 net/core/net_namespace.c:445 [ ] create_new_namespaces+0x141/0x2a0 kernel/nsproxy.c:103 [<8047d645>] unshare_nsproxy_namespaces+0x7f/0x100 kernel/nsproxy.c:202 [<5993ea6e>] ksys_unshare+0x236/0x490 kernel/fork.c:2674 [<19417e75>] __do_sys_unshare kernel/fork.c:2742 [inline] [<19417e75>] __se_sys_unshare kernel/fork.c:2740 [inline] [<19417e75>] __x64_sys_unshare+0x16/0x20 kernel/fork.c:2740 [ ] do_syscall_64+0x76/0x1a0 arch/x86/entry/common.c:296 [<38550184>] entry_SYSCALL_64_after_hwframe+0x44/0xa9 syzbot reported other leak in copy_net_ns -> setup_net. This problem is already fixed by cf47a0b882a4e5f6b34c7949d7b293e9287f1972. sysbot link: https://syzkaller.appspot.com/bug?id=3babacc2ed6bddb8e168d022ef77d32db0e05ea6 Fixes: 9b242610514f ("keys: Network namespace domain tag") Reported-by: syzbot+3b3296d032353c331...@syzkaller.appspotmail.com Signed-off-by: Takeshi Misawa --- net/core/net_namespace.c | 1 + 1 file changed, 1 insertion(+) diff --git a/net/core/net_namespace.c b/net/core/net_namespace.c index a0e0d298c991..b88905792795 100644 --- a/net/core/net_namespace.c +++ b/net/core/net_namespace.c @@ -478,6 +478,7 @@ struct net *copy_net_ns(unsigned long flags, if (rv < 0) { put_userns: + key_remove_domain(net->key_domain); put_user_ns(user_ns); net_drop_ns(net); dec_ucounts: -- 2.17.1
Re: [PATCH v10 3/3] mm: fix double page fault on arm64 if PTE_AF is cleared
Hi Palmer
On 2019/10/19 4:38, Palmer Dabbelt wrote:
On Wed, 16 Oct 2019 16:46:08 PDT (-0700), w...@kernel.org wrote:
Hey Palmer,
On Wed, Oct 16, 2019 at 04:21:59PM -0700, Palmer Dabbelt wrote:
On Tue, 08 Oct 2019 05:39:44 PDT (-0700), w...@kernel.org wrote:
> On Tue, Oct 08, 2019 at 02:19:05AM +, Justin He (Arm Technology
China) wrote:
> > > On Mon, Sep 30, 2019 at 09:57:40AM +0800, Jia He wrote:
> > > > diff --git a/mm/memory.c b/mm/memory.c
> > > > index b1ca51a079f2..1f56b0118ef5 100644
> > > > --- a/mm/memory.c
> > > > +++ b/mm/memory.c
> > > > @@ -118,6 +118,13 @@ int randomize_va_space __read_mostly =
> > > > 2;
> > > > #endif
> > > >
> > > > +#ifndef arch_faults_on_old_pte
> > > > +static inline bool arch_faults_on_old_pte(void)
> > > > +{
> > > > + return false;
> > > > +}
> > > > +#endif
> > >
> > > Kirill has acked this, so I'm happy to take the patch as-is, however
isn't
> > > it the case that /most/ architectures will want to return true for
> > > arch_faults_on_old_pte()? In which case, wouldn't it make more sense for
> > > that to be the default, and have x86 and arm64 provide an override? For
> > > example, aren't most architectures still going to hit the double fault
> > > scenario even with your patch applied?
> >
> > No, after applying my patch series, only those architectures which
don't provide
> > setting access flag by hardware AND don't implement their
arch_faults_on_old_pte
> > will hit the double page fault.
> >
> > The meaning of true for arch_faults_on_old_pte() is "this arch doesn't
have the hardware
> > setting access flag way, it might cause page fault on an old pte"
> > I don't want to change other architectures' default behavior here. So
by default,
> > arch_faults_on_old_pte() is false.
>
> ...and my complaint is that this is the majority of supported architectures,
> so you're fixing something for arm64 which also affects arm, powerpc,
> alpha, mips, riscv, ...
>
> Chances are, they won't even realise they need to implement
> arch_faults_on_old_pte() until somebody runs into the double fault and
> wastes lots of time debugging it before they spot your patch.
If I understand the semantics correctly, we should have this set to true. I
don't have any context here, but we've got
/*
* The kernel assumes that TLBs don't cache invalid
* entries, but in RISC-V, SFENCE.VMA specifies an
* ordering constraint, not a cache flush; it is
* necessary even after writing invalid entries.
*/
local_flush_tlb_page(addr);
in do_page_fault().
Ok, although I think this is really about whether or not your hardware can
make a pte young when accessed, or whether you take a fault and do it
by updating the pte explicitly.
v12 of the patches did change the default, so you should be "safe" with
those either way:
http://lists.infradead.org/pipermail/linux-arm-kernel/2019-October/686030.html
OK, that fence is because we allow invalid translations to be cached, which
is a completely different issue.
RISC-V implementations are allowed to have software managed accessed/dirty
bits. For some reason I thought we were relying on the firmware to handle
this, but I can't actually find the code so I might be crazy. Wherever it's
done, there's no spec enforcing it so we should leave this true on RISC-V.
Thanks for the confirmation. So we can keep the default arch_faults_on_old_pte
(return true) on RISC-V.
Thanks.
---
Cheers,
Justin (Jia He)
Re: [PATCH v4 2/2] iio: (bma400) add driver for the BMA400
On Fri, Oct 18, 2019 at 10:23:38AM +0300, Andy Shevchenko wrote:
> On Fri, Oct 18, 2019 at 6:44 AM Dan Robertson wrote:
> > + * bma400.h - Register constants and other forward declarations
> > + *needed by the bma400 sources.
>
> Including file name in the file is not the best practice. Imagine if
> by some reason we will need to rename it (to support more sensors, for
> example, and reflect it by replacing 00 -> 0x).
> So, please, remove here and everywhere else.
That makes sense.
> > +#define BMA400_TWO_BITS_MASK0x03
> > +#define BMA400_LP_OSR_MASK 0x60
> > +#define BMA400_NP_OSR_MASK 0x30
> > +#define BMA400_ACC_ODR_MASK 0x0f
> > +#define BMA400_ACC_SCALE_MASK 0xc0
>
> GENMASK()
> (Don't forget to include bits.h for it)
Thanks.
> > +static const int bma400_scale_table[] = {
> > + 0, 38344,
> > + 0, 76590,
> > + 0, 153277,
>
> > + 0, 306457
>
> Better to leave comma here. It doesn't matter for this device, but
> make of use the better practices.
> > +};
>
> Also, I'm wondering why values are not exactly multiply by 2. Is in DS
> of the chip any explanation for this?
It would be a multiply by 2. I tried to follow the bma180 driver here, but I'm
starting to think that may be the wrong approach.
> > +static const int bma400_osr_table[] = { 0, 1, 3 };
>
> > +/* See the ACC_CONFIG1 section of the datasheet */
> > +static const int bma400_sample_freqs[] = {
> > + 12, 50,
> > + 25, 0,
> > + 50, 0,
> > + 100, 0,
> > + 200, 0,
> > + 400, 0,
> > + 800, 0,
> > +};
>
> This can be replaced by a formula(s).
Yeah I think I can implement the get, set, and read functions for sample_freq
with a formula, but the scale and sample frequency tables are needed by the
implementation of read_avail. A implementation of read_avail with a range and
a step would be ideal, but I couldn't find any documentation on implementing
read_avail where the step value of the range is a multiple. Please correct
me if I've missed something.
Note that this applies to the scale table as well.
> > +struct bma400_sample_freq {
> > + int hz;
> > + int uhz;
> > +};
>
> I'm wondering why above table is not using this struct.
Originally it did, but I changed this in the second version when I added support
for iio_info read_avail to try to be a little closer to other implementations of
iio_read avail.
> > +const struct regmap_config bma400_regmap_config = {
> > + .reg_bits = 8,
> > + .val_bits = 8,
> > + .max_register = BMA400_CMD_REG,
> > + .cache_type = REGCACHE_RBTREE,
> > + .writeable_reg = bma400_is_writable_reg,
> > + .volatile_reg = bma400_is_volatile_reg,
> > +};
>
> > +EXPORT_SYMBOL(bma400_regmap_config);
>
> Why? And why it's not _GPL?
This is used by the bma400_i2c module.
> > + int ret;
> > + int host_temp;
> > + unsigned int raw_temp;
>
> Better reversed xmas tree order.
Sounds good.
>
> > + if (idx + 1 >= ARRAY_SIZE(bma400_sample_freqs)) {
>
> Why do you need this churn with +1 and = ?
Since we've "flattened" the array of sample frequency we need to ensure that the
Hz (bma400_sample_freqs[idx]) and uHz (bma400_sample_freqs[idx + 1]) are both
valid. This will be negated in the next version as I'll switch to a formula.
Instead I'll ensure the returned ODR value is not above 0x0b.
> > + dev_err(data->dev, "sample freq index is too high");
> > + ret = -EINVAL;
> > + goto error;
> > + }
>
>
> > + for (i = 0; i + 1 < ARRAY_SIZE(bma400_sample_freqs); i += 2) {
>
> Using defined struct will guarantee you to have always 2x members in
> the array. So, drop this arithmetic churn.
I should be able to figure out how to use a formula here, but I see where you're
coming from and I agree.
> > + if (ret < 0) {
> > + dev_err(data->dev, "Failed to read chip id register: %x!",
> > ret);
>
> %x for returned error code is too hackerish.
Makes sense. I'll change this in the update.
> > + return ret;
>
> > + } else if (val != BMA400_ID_REG_VAL) {
>
> Redundant 'else'
> > + dev_err(data->dev, "CHIP ID MISMATCH: %x!", ret);
>
> Hacker detected!
:)
> > + return -ENODEV;
> > + }
>
> > + /*
> > +* TODO: The datasheet waits 1500us here in the example, but
> > +* lists 2/ODR as the wakeup time.
> > +*/
> > + usleep_range(1500, 2);
>
> These range values are too sparse. Usually the second one is less than
> first one * 2.
> Fix it now.
Good to know. I'll fix this in the update.
> > +EXPORT_SYMBOL(bma400_probe);
>
> Why is not GPL?
Ah, saw in the docs "GPL" means GPL-2.0.
>
> > +EXPORT_SYMBOL(bma400_remove);
>
> Ditto.
This symbol is used in bma400_i2c.
>
> P.S. I probably missed some places with the
Re: [GIT PULL] RISC-V updates for v5.4-rc4
The pull request you sent on Fri, 18 Oct 2019 16:36:14 -0700 (PDT): > git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux.git > tags/riscv/for-v5.4-rc4 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/dfdcff3215ae4ed7975b0991243d1dd8e1250bec Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [PATCH] random: make try_to_generate_entropy() more robust
On Fri, Oct 18, 2019 at 4:42 PM Jörn Engel wrote:
>
> We can generate entropy on almost any CPU, even if it doesn't provide a
> high-resolution timer for random_get_entropy(). As long as the CPU is
> not idle, it changed the register file every few cycles. As long as the
> ALU isn't fully synchronized with the timer, the drift between the
> register file and the timer is enough to generate entropy from.
> static void entropy_timer(struct timer_list *t)
> {
> + struct pt_regs *regs = get_irq_regs();
> +
> + /*
> + * Even if we don't have a high-resolution timer in our system,
> + * the register file itself is a high-resolution timer. It
> + * isn't monotonic or particularly useful to read the current
> + * time. But it changes with every retired instruction, which
> + * is enough to generate entropy from.
> + */
> + mix_pool_bytes(&input_pool, regs, sizeof(*regs));
Ok, so I still like this conceptually, but I'm not entirely sure that
get_irq_regs() works reliably in a timer. It's done from softirq
TIMER_SOFTIRQ context, so not necessarily _in_ an interrupt.
Now, admittedly this code doesn't really need "reliably". The odd
occasional hickup would arguably just add more noise. And I think the
code works fine. get_irq_regs() will return a pointer to the last
interrupt or exception frame on the current CPU, and I guess it's all
fine. But let's bring in Thomas, who was not only active in the
randomness discussion, but might also have stronger opinions on this
get_irq_regs() usage.
Thomas, opinions? Using the register state (while we're doing the
whole entropy load with scheduling etc) looks like a good source of
high-entropy data outside of just the TSC, so it does seem like a very
valid model. But I want to run it past more people first, and Thomas
is the obvious victim^Wchoice.
Linus
Re: [PATCH 2/2] firmware: coreboot: Export active CBFS partition
> I don't know why we need to draw a line in the sand and say that if the > kernel doesn't need to know about it then it shouldn't parse it. I want > there to be a consistent userspace ABI that doesn't just move things > straight from memory to userspace in some binary format. I'd rather we > have an ABI that decodes and exposes information about the coreboot > tables through existing frameworks/subsystems where possible and makes > up new ones otherwise. Okay... I'm just saying this might grow to become a lot of stuff as people start having more and more use cases they want to support. But if you think the kernel should be the one parsing all that, I'm happy to defer to your expertise there (I'm not really a kernel guy after all). > One concern I have is endianness of the binary data. Is it big endian or > little endian or CPU native endian? The kernel can boot into big or > little endian on ARM platforms and userspace can be different vs. the > bootloader too. Userspace shouldn't need to know this detail, the kernel > should know and do the conversions and expose it somehow. That's why I'm > suggesting in this case we describe fmap as a sysfs class. I don't see > how we could export that information otherwise, besides in a binary blob > that falls into traps like this. Right now it's just always CPU byte order of what coreboot happened to run at, and it's not exporting that info in any way either. We don't really have support for big-endian architectures anyway so it's not something we really thought about yet. If it ever comes to that, I assume the byte order of the table header's magic number could be used to tell the difference. > Right now we make devices for all the coreboot table entries, which is > pretty weird considering that some table entries are things like > LB_TAG_LINKER. That isn't a device. It's some information about how > coreboot was linked. We should probably blacklist tags so we don't make > devices and capture these ones in the bus code and expose them in > /sys/firware/coreboot/ somehow. We should also add device randomness > from the serial numbers, etc. that coreboot has stashed away in the > tables. I mean... should any of them be devices, then? All table entries are just "some information", where are you defining the difference there? I'm not sure if the current representation is the right one, but I think they should probably all be handled in a consistent way.
Re: [PATCH v2 2/2] mm/memory-failure.c: Don't access uninitialized memmaps in memory_failure()
On Thu, 10 Oct 2019 09:17:42 +0200 David Hildenbrand wrote: > >> - pgmap = get_dev_pagemap(pfn, NULL); > >> - if (pgmap) > >> - return memory_failure_dev_pagemap(pfn, flags, pgmap); > >> - > >> - p = pfn_to_page(pfn); > > > > This change seems to assume that memory_failure_dev_pagemap() is never > > called for online pages. Is it an intended behavior? > > Or the concept "online pages" is not applicable to zone device pages? > > Yes, that's the real culprit. ZONE_DEVICE/devmem pages are never online > (SECTION_IS_ONLINE). The terminology "online" only applies to pages that > were given to the buddy. And as we support sup-section hotadd for > devmem, we cannot easily make use of the section flag it. I already > proposed somewhere to convert SECTION_IS_ONLINE to a subsection bitmap > and call it something like pfn_active(). > > pfn_online() would then be "pfn_active() && zone != ZONE_DEVICE". And we > could use pfn_active() everywhere to test for initialized memmaps (well, > besides some special cases like device reserved memory that does not > span full sub-sections). Until now, nobody volunteered and I have other > things to do. Is it worth a code comment or two to make this clearer?
Re: [PATCH v6 2/2] HID: logitech: Support WirelessDeviceStatus connect events
On Friday, October 18, 2019 11:38 AM, Benjamin Tissoires
wrote:
> On Mon, Oct 14, 2019 at 8:36 PM Mazin Rezk mn...@protonmail.com wrote:
>
> > This patch allows WirelessDeviceStatus (0x1d4b) events to be detected as
> > connection events in the hid-logitech-hidpp module.
> > Devices with HIDPP_QUIRK_WIRELESS_DEVICE_STATUS use WirelessDeviceStatus
> > instead of traditional connect events. Since all Bluetooth LE devices seem
> > to act this way, HIDPP_QUIRK_CLASS_BLUETOOTH_LE aliases this quirk.
> >
> > Signed-off-by: Mazin Rezk mn...@protonmail.com
> >
> > ---
> >
> > drivers/hid/hid-logitech-hidpp.c | 42
> > 1 file changed, 37 insertions(+), 5 deletions(-)
> > diff --git a/drivers/hid/hid-logitech-hidpp.c
> > b/drivers/hid/hid-logitech-hidpp.c
> > index 997b1056850a..9b3df57ca857 100644
> > --- a/drivers/hid/hid-logitech-hidpp.c
> > +++ b/drivers/hid/hid-logitech-hidpp.c
> > @@ -60,6 +60,7 @@ MODULE_PARM_DESC(disable_tap_to_click,
> > #define HIDPP_QUIRK_CLASS_K750 BIT(4)
> > /* bits 2..15 are reserved for classes /
> > +#define HIDPP_QUIRK_WIRELESS_DEVICE_STATUS BIT(19)
> > #define HIDPP_QUIRK_MISSING_SHORT_REPORTS BIT(20)
> > / #define HIDPP_QUIRK_CONNECT_EVENTS BIT(21) disabled */#define
> > HIDPP_QUIRK_WTP_PHYSICAL_BUTTONS BIT(22)
> > @@ -82,7 +83,8 @@ MODULE_PARM_DESC(disable_tap_to_click,
> > HIDPP_QUIRK_HI_RES_SCROLL_X2120 | \
> > HIDPP_QUIRK_HI_RES_SCROLL_X2121)
> > -#define HIDPP_QUIRK_CLASS_BLUETOOTH_LE HIDPP_QUIRK_MISSING_SHORT_REPORTS
> > +#define HIDPP_QUIRK_CLASS_BLUETOOTH_LE (HIDPP_QUIRK_MISSING_SHORT_REPORTS
> > | \
> >
> > -
> > HIDPP_QUIRK_WIRELESS_DEVICE_STATUS)
> >
> >
> >
> > #define HIDPP_QUIRK_DELAYED_INIT HIDPP_QUIRK_NO_HIDINPUT
> > @@ -189,6 +191,8 @@ struct hidpp_device {
> >
> > struct hidpp_battery battery;
> > struct hidpp_scroll_counter vertical_wheel_counter;
> >
> >
> > -
> > - u8 wireless_feature_index;
> >
> >
> >
> > };
> > /* HID++ 1.0 error codes */
> > @@ -402,10 +406,14 @@ static inline bool hidpp_match_error(struct
> > hidpp_report *question,
> > (answer->fap.params[0] == question->fap.funcindex_clientid);
> > }
> > -static inline bool hidpp_report_is_connect_event(struct hidpp_report
> > *report)
> > +static inline bool hidpp_report_is_connect_event(struct hidpp_device
> > *hidpp,
> >
> > - struct hidpp_report
> > *report)
> >
> >
> >
> > {
> >
> > - return (report->report_id == REPORT_ID_HIDPP_SHORT) &&
> >
> >
> > - (report->rap.sub_id == 0x41);
> >
> >
> >
> > - return ((hidpp->quirks & HIDPP_QUIRK_WIRELESS_DEVICE_STATUS) &&
> >
> >
> > - (report->fap.feature_index ==
> > hidpp->wireless_feature_index)) ||
> >
> >
> > - (((report->report_id == REPORT_ID_HIDPP_SHORT) ||
> >
> >
> > - (hidpp->quirks & HIDPP_QUIRK_MISSING_SHORT_REPORTS)) &&
> >
> >
> > - (report->rap.sub_id == 0x41));
> >
> >
>
> I wonder if we need a quirk after all: if
> hidpp->wireless_feature_index is non null, that means that we have the
> quirk.
> Unless the feature is present for non BLE devices, in which case, we
> might want to enable them one by one, for now.
>
> Cheers,
> Benjamin
Come to think of it, it does seem redundant. I'll likely extend the
WirelessDeviceStatus check to all HID++ 2.0 devices and just forgo the
added quirks entirely.
Thanks,
Mazin
>
> > }
> > /**
> > @@ -1282,6 +1290,24 @@ static int hidpp_battery_get_property(struct
> > power_supply *psy,
> > return ret;
> > }
> > +/*
> > -- /
> > +/ 0x1d4b: Wireless device status /
> > +/
> > --
> > */+#define HIDPP_PAGE_WIRELESS_DEVICE_STATUS 0x1d4b
> > +
> > +static int hidpp_set_wireless_feature_index(struct hidpp_device *hidpp)
> > +{
> >
> > - u8 feature_type;
> >
> >
> > - int ret;
> >
> >
> > -
> > - ret = hidpp_root_get_feature(hidpp,
> >
> >
> > - HIDPP_PAGE_WIRELESS_DEVICE_STATUS,
> >
> >
> > - &hidpp->wireless_feature_index,
> >
> >
> > - &feature_type);
> >
> >
> > -
> > - return ret;
> >
> >
> >
> > +}
> > +
> > /*
> > -- /
> > / 0x2120: Hi-resolution scrolling /
> > /
> > --
> > */@@ -3077,7 +3103,7 @@ static int hidpp_raw_hidpp_event(struct
> > hidpp_device *hidpp, u8 *data,
> > }
> > }
> >
> > - if (unlikely(hidpp_report_is_connect_event(report))) {
> >
> >
> >
> > - if (unlikely(hidpp_report_is_connect_event(hidpp, report))) {
> > atomic_set(&hidpp->conne
Re: [PATCH] lib/vdso: Use __arch_use_vsyscall() to indicate fallback
Hi, Andy,
On Fri, Oct 18, 2019 at 11:15 AM Andy Lutomirski wrote:
>
> On Thu, Oct 17, 2019 at 7:57 PM Huacai Chen wrote:
> >
> > In do_hres(), we currently use whether the return value of __arch_get_
> > hw_counter() is negtive to indicate fallback, but this is not a good
> > idea. Because:
> >
> > 1, ARM64 returns ULL_MAX but MIPS returns 0 when clock_mode is invalid;
> > 2, For a 64bit counter, a "negtive" value of counter is actually valid.
>
> s/negtive/negative
>
> What's the actual bug? Is it that MIPS is returning 0 but the check
> is < 0? Sounds like MIPS should get fixed.
My original bug is what Vincenzo said, MIPS has a boot failure if no
valid clock_mode, and surely MIPS need to fix. However, when I try to
fix it, I found that clock_getres() has another problem, because
__cvdso_clock_getres_common() get vd[CS_HRES_COARSE].hrtimer_res, but
hrtimer_res is set in update_vdso_data() which relies on
__arch_use_vsyscall().
>
> >
> > To solve this problem, we use U64_MAX as the only "invalid" return
> > value -- this is still not fully correct, but has no problem in most
> > cases.
>
> I'm sort of okay with that, but...
>
> > Moreover, all vdso time-related functions should rely on the
> > return value of __arch_use_vsyscall(), because update_vdso_data() and
> > update_vsyscall_tz() also rely on it. So, in the core functions of
> > __cvdso_gettimeofday(), __cvdso_clock_gettime() and __cvdso_clock_
> > getres(), if __arch_use_vsyscall() returns false, we use the fallback
> > functions directly.
>
> __arch_use_vsyscall() is not currently intended for use in the vDSO at all.
>
> >
> > Fixes: 00b26474c2f1613d7ab894c5 ("lib/vdso: Provide generic VDSO
> > implementation")
> > Cc: sta...@vger.kernel.org
> > Cc: Arnd Bergmann
> > Cc: Paul Burton
> > Cc: linux-m...@vger.kernel.org
> > Cc: linux-arm-ker...@lists.infradead.org
> > Signed-off-by: Huacai Chen
> > ---
> > arch/arm64/include/asm/vdso/vsyscall.h | 2 +-
> > arch/mips/include/asm/vdso/vsyscall.h | 2 +-
> > include/asm-generic/vdso/vsyscall.h| 2 +-
> > lib/vdso/gettimeofday.c| 12 +++-
> > 4 files changed, 14 insertions(+), 4 deletions(-)
> >
> > diff --git a/arch/arm64/include/asm/vdso/vsyscall.h
> > b/arch/arm64/include/asm/vdso/vsyscall.h
> > index 0c731bf..406e6de 100644
> > --- a/arch/arm64/include/asm/vdso/vsyscall.h
> > +++ b/arch/arm64/include/asm/vdso/vsyscall.h
> > @@ -31,7 +31,7 @@ int __arm64_get_clock_mode(struct timekeeper *tk)
> > #define __arch_get_clock_mode __arm64_get_clock_mode
> >
> > static __always_inline
> > -int __arm64_use_vsyscall(struct vdso_data *vdata)
> > +int __arm64_use_vsyscall(const struct vdso_data *vdata)
> > {
> > return !vdata[CS_HRES_COARSE].clock_mode;
> > }
> > diff --git a/arch/mips/include/asm/vdso/vsyscall.h
> > b/arch/mips/include/asm/vdso/vsyscall.h
> > index 1953147..8b10dd7 100644
> > --- a/arch/mips/include/asm/vdso/vsyscall.h
> > +++ b/arch/mips/include/asm/vdso/vsyscall.h
> > @@ -29,7 +29,7 @@ int __mips_get_clock_mode(struct timekeeper *tk)
> > #define __arch_get_clock_mode __mips_get_clock_mode
> >
> > static __always_inline
> > -int __mips_use_vsyscall(struct vdso_data *vdata)
> > +int __mips_use_vsyscall(const struct vdso_data *vdata)
> > {
> > return (vdata[CS_HRES_COARSE].clock_mode != VDSO_CLOCK_NONE);
> > }
> > diff --git a/include/asm-generic/vdso/vsyscall.h
> > b/include/asm-generic/vdso/vsyscall.h
> > index e94b1978..ac05a625 100644
> > --- a/include/asm-generic/vdso/vsyscall.h
> > +++ b/include/asm-generic/vdso/vsyscall.h
> > @@ -26,7 +26,7 @@ static __always_inline int __arch_get_clock_mode(struct
> > timekeeper *tk)
> > #endif /* __arch_get_clock_mode */
> >
> > #ifndef __arch_use_vsyscall
> > -static __always_inline int __arch_use_vsyscall(struct vdso_data *vdata)
> > +static __always_inline int __arch_use_vsyscall(const struct vdso_data
> > *vdata)
> > {
> > return 1;
> > }
> > diff --git a/lib/vdso/gettimeofday.c b/lib/vdso/gettimeofday.c
> > index e630e7f..4ad062e 100644
> > --- a/lib/vdso/gettimeofday.c
> > +++ b/lib/vdso/gettimeofday.c
> > @@ -9,6 +9,7 @@
> > #include
> > #include
> > #include
> > +#include
> >
> > /*
> > * The generic vDSO implementation requires that gettimeofday.h
> > @@ -50,7 +51,7 @@ static int do_hres(const struct vdso_data *vd, clockid_t
> > clk,
> > cycles = __arch_get_hw_counter(vd->clock_mode);
> > ns = vdso_ts->nsec;
> > last = vd->cycle_last;
> > - if (unlikely((s64)cycles < 0))
> > + if (unlikely(cycles == U64_MAX))
> > return -1;
>
> I would actually prefer:
>
> if (unlikely(cycles < last))
>
> or perhaps:
>
> if (unlikely((s64)(cycles-last) < 0))
>
> which would have the nice side effect of getting rid of the annoying
> x86 special case in vdso_calc_delta(). The former version is
> compatible with U64_MAX, whereas the latter version would need the
> error c
Re: ARM: add __always_inline to functions called from __get_user_check()
On Fri, Oct 18, 2019 at 7:06 PM H. Nikolaus Schaller wrote: > > Hi, > I wonder what happened to your patch. We were "hit" by it in v5.4-rc1 and > after finding, it made our OMAP based device bootable again (using our > own defconfig which optimizes for SIZE). > > But it does not seem to have arrived in linux-next It is in linux-next. > and should IMHO > be fixed during the v5.4 release candidate cycle. I agree. Masahiro > > BR and thanks, > Nikolaus Schaller > -- Best Regards Masahiro Yamada
Re: [PATCH v6 1/2] HID: logitech: Add MX Master over Bluetooth
On Friday, October 18, 2019 11:36 AM, Benjamin Tissoires
wrote:
> Hi Mazin,
>
> On Mon, Oct 14, 2019 at 8:36 PM Mazin Rezk mn...@protonmail.com wrote:
>
> > This patch adds support for the MX Master (b01e and b012) and also adds
> > foundational code for other Bluetooth LE HID++ devices to be added.
> > Some devices do not support short reports and thus have a quirk
> > (HIDPP_QUIRK_MISSING_SHORT_REPORTS) that forces short reports to be sent as
> > long reports. Since all Bluetooth LE HID++ devices seem to act this way,
> > HIDPP_QUIRK_CLASS_BLUETOOTH_LE aliases this quirk.
> > To allow for some space for future quirks, I changed the comment that
> > defines the bits reserved for classes from 2...20 to 2..15.
> >
> > Signed-off-by: Mazin Rezk mn...@protonmail.com
> >
> > ---
> >
> > drivers/hid/hid-logitech-hidpp.c | 24 +++-
> > 1 file changed, 23 insertions(+), 1 deletion(-)
> > diff --git a/drivers/hid/hid-logitech-hidpp.c
> > b/drivers/hid/hid-logitech-hidpp.c
> > index 0179f7ed77e5..997b1056850a 100644
> > --- a/drivers/hid/hid-logitech-hidpp.c
> > +++ b/drivers/hid/hid-logitech-hidpp.c
> > @@ -59,7 +59,8 @@ MODULE_PARM_DESC(disable_tap_to_click,
> > #define HIDPP_QUIRK_CLASS_G920 BIT(3)
> > #define HIDPP_QUIRK_CLASS_K750 BIT(4)
> > -/* bits 2..20 are reserved for classes /
> > +/ bits 2..15 are reserved for classes /
> > +#define HIDPP_QUIRK_MISSING_SHORT_REPORTS BIT(20)
> > / #define HIDPP_QUIRK_CONNECT_EVENTS BIT(21) disabled */#define
> > HIDPP_QUIRK_WTP_PHYSICAL_BUTTONS BIT(22)
> > #define HIDPP_QUIRK_NO_HIDINPUT BIT(23)
> > @@ -81,6 +82,8 @@ MODULE_PARM_DESC(disable_tap_to_click,
> > HIDPP_QUIRK_HI_RES_SCROLL_X2120 | \
> > HIDPP_QUIRK_HI_RES_SCROLL_X2121)
> > +#define HIDPP_QUIRK_CLASS_BLUETOOTH_LE HIDPP_QUIRK_MISSING_SHORT_REPORTS
> > +
> > #define HIDPP_QUIRK_DELAYED_INIT HIDPP_QUIRK_NO_HIDINPUT
> > #define HIDPP_CAPABILITY_HIDPP10_BATTERY BIT(0)
> > @@ -340,6 +343,12 @@ static int hidpp_send_rap_command_sync(struct
> > hidpp_device *hidpp_dev,
> > struct hidpp_report *message;
> > int ret, max_count;
> >
> > - /* Force long reports on devices that do not support short
> > reports */
> >
> >
> > - if (hidpp_dev->quirks & HIDPP_QUIRK_MISSING_SHORT_REPORTS &&
> >
> >
> > - report_id == REPORT_ID_HIDPP_SHORT)
> >
> >
> > - report_id = REPORT_ID_HIDPP_LONG;
> >
> >
>
> Wouldn't it be faster to just store which report needs to be put here
> in struct hidpp_device?
>
> > -
> > - switch (report_id) {
> > case REPORT_ID_HIDPP_SHORT:
> > max_count = HIDPP_REPORT_SHORT_LENGTH - 4;
> >
> >
> >
> > @@ -3482,6 +3491,12 @@ static bool hidpp_validate_report(struct hid_device
> > *hdev, int id,
> > static bool hidpp_validate_device(struct hid_device *hdev)
> > {
> >
> > - struct hidpp_device *hidpp = hid_get_drvdata(hdev);
> >
> >
> > - /* Skip the short report check if the device does not support it
> > */
> >
> >
> > - if (hidpp->quirks & HIDPP_QUIRK_MISSING_SHORT_REPORTS)
> >
> >
> > - return hidpp_validate_report(hdev, REPORT_ID_HIDPP_LONG,
> >
> >
> > - HIDPP_REPORT_LONG_LENGTH,
> > false);
> >
> >
> > -
>
> I just merged Andrey's report detection, which means you will need to
> update this hunk:
> https://git.kernel.org/pub/scm/linux/kernel/git/hid/hid.git/commit/?h=for-5.4/upstream-fixes&id=905d754c53a522aacf806ea1d3e7c929148c1910
>
> The good thing, is that now you can simply auto-detect if the short
> report is missing. If the returned report_length is null, you know
> that the report is missing (and thus you can remember to set the
> quirk/which report id is needed).
>
> Cheers,
> Benjamin
Thank you, I'll try to rework this patch based on the changes introduced in
that commit.
Thanks,
Mazin
>
> > return hidpp_validate_report(hdev, REPORT_ID_HIDPP_SHORT,
> > HIDPP_REPORT_SHORT_LENGTH, false) &&
> >hidpp_validate_report(hdev, REPORT_ID_HIDPP_LONG,
> >
> >
> > @@ -3773,6 +3788,13 @@ static const struct hid_device_id hidpp_devices[] = {
> > { /* MX5500 keyboard over Bluetooth */
> > HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_LOGITECH, 0xb30b),
> > .driver_data = HIDPP_QUIRK_HIDPP_CONSUMER_VENDOR_KEYS },
> >
> > - { /* MX Master mouse over Bluetooth */
> >
> >
> > - HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_LOGITECH, 0xb012),
> >
> >
> > - .driver_data = HIDPP_QUIRK_HI_RES_SCROLL_X2121 |
> >
> >
> > - HIDPP_QUIRK_CLASS_BLUETOOTH_LE },
> >
> >
> > - { HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_LOGITECH, 0xb01e),
> >
> >
> > - .driver_data = HIDPP_QUIRK_HI_RES_SCROLL_X2121 |
> >
> >
> > - HIDPP_QUIRK_CLASS_BLUETOOTH_LE },
> > {}
> >
> >
> >
> > };
> > --
> > 2.23.0
Re: [PATCH v3 2/3] mm/vmalloc: respect passed gfp_mask when do preloading
On Fri, 18 Oct 2019 11:40:49 +0200 Uladzislau Rezki wrote: > > > alloc_vmap_area() is given a gfp_mask for the page allocator. > > > Let's respect that mask and consider it even in the case when > > > doing regular CPU preloading, i.e. where a context can sleep. > > > > This is explaining what but it doesn't say why. I would go with > > " > > Allocation functions should comply with the given gfp_mask as much as > > possible. The preallocation code in alloc_vmap_area doesn't follow that > > pattern and it is using a hardcoded GFP_KERNEL. Although this doesn't > > really make much difference because vmalloc is not GFP_NOWAIT compliant > > in general (e.g. page table allocations are GFP_KERNEL) there is no > > reason to spread that bad habit and it is good to fix the antipattern. > > " > I can go with that, agree. I am not sure if i need to update the patch > and send v4. Or maybe Andrew can directly update it in his tree. > > Andrew, should i send or can update? I updated the changelog with Michal's words prior to committing. You were cc'ed :) From: "Uladzislau Rezki (Sony)" Subject: mm/vmalloc: respect passed gfp_mask when doing preloading Allocation functions should comply with the given gfp_mask as much as possible. The preallocation code in alloc_vmap_area doesn't follow that pattern and it is using a hardcoded GFP_KERNEL. Although this doesn't really make much difference because vmalloc is not GFP_NOWAIT compliant in general (e.g. page table allocations are GFP_KERNEL) there is no reason to spread that bad habit and it is good to fix the antipattern. [mho...@suse.com: rewrite changelog] Link: http://lkml.kernel.org/r/20191016095438.12391-2-ure...@gmail.com Signed-off-by: Uladzislau Rezki (Sony) Acked-by: Michal Hocko Cc: Daniel Wagner Cc: Hillf Danton Cc: Matthew Wilcox Cc: Oleksiy Avramchenko Cc: Peter Zijlstra Cc: Sebastian Andrzej Siewior Cc: Steven Rostedt Cc: Thomas Gleixner Signed-off-by: Andrew Morton --- mm/vmalloc.c |8 1 file changed, 4 insertions(+), 4 deletions(-) --- a/mm/vmalloc.c~mm-vmalloc-respect-passed-gfp_mask-when-do-preloading +++ a/mm/vmalloc.c @@ -1063,9 +1063,9 @@ static struct vmap_area *alloc_vmap_area return ERR_PTR(-EBUSY); might_sleep(); + gfp_mask = gfp_mask & GFP_RECLAIM_MASK; - va = kmem_cache_alloc_node(vmap_area_cachep, - gfp_mask & GFP_RECLAIM_MASK, node); + va = kmem_cache_alloc_node(vmap_area_cachep, gfp_mask, node); if (unlikely(!va)) return ERR_PTR(-ENOMEM); @@ -1073,7 +1073,7 @@ static struct vmap_area *alloc_vmap_area * Only scan the relevant parts containing pointers to other objects * to avoid false negatives. */ - kmemleak_scan_area(&va->rb_node, SIZE_MAX, gfp_mask & GFP_RECLAIM_MASK); + kmemleak_scan_area(&va->rb_node, SIZE_MAX, gfp_mask); retry: /* @@ -1099,7 +1099,7 @@ retry: * Just proceed as it is. If needed "overflow" path * will refill the cache we allocate from. */ - pva = kmem_cache_alloc_node(vmap_area_cachep, GFP_KERNEL, node); + pva = kmem_cache_alloc_node(vmap_area_cachep, gfp_mask, node); spin_lock(&vmap_area_lock); _
Re: [PATCH v4 2/2] iio: (bma400) add driver for the BMA400
On Thu, Oct 17, 2019 at 09:25:37PM -0700, Randy Dunlap wrote:
> On 10/17/19 8:18 PM, Dan Robertson wrote:
> > +config BMA400
> > + tristate "Bosch BMA400 3-Axis Accelerometer Driver"
> > + depends on I2C
> > + select REGMAP
> > + select BMA400_I2C if (I2C)
>
> Since BMA400 already depends on I2C, the "if (I2C)" above is
> redundant so it's not needed.
You are correct. I'll remove the depends on I2C.
> > +struct bma400_data {
> > + struct device *dev;
> > + struct mutex mutex; /* data register lock */
>
> needs #include
Good point.
> > +static int bma400_get_accel_scale_idx(struct bma400_data *data, int val)
> > +{
> > + int i;
> > +
> > + for (i = 1; i < ARRAY_SIZE(bma400_scale_table); i += 2) {
>
> needs #include
> for ARRAY_SIZE()
Thanks
Cheers,
- Dan
signature.asc
Description: Digital signature
Re: [PATCH 2/3] mm, meminit: Recalculate pcpu batch and high limits after init completes
On Fri, 18 Oct 2019 15:09:59 +0100 Mel Gorman
wrote:
> > > Cc: sta...@vger.kernel.org # v4.15+
> >
> > Hmm, are you sure about 4.15? Doesn't this go all the way down to
> > deferred initialization? I do not see any recent changes on when
> > setup_per_cpu_pageset is called.
> >
>
> No, I'm not 100% sure. It looks like this was always an issue from the
> code but did not happen on at least one 4.12-based distribution kernel for
> reasons that are non-obvious. Either way, the tag should have been "v4.1+"
I could mark
mm-pcp-share-common-code-between-memory-hotplug-and-percpu-sysctl-handler.patch
mm-meminit-recalculate-pcpu-batch-and-high-limits-after-init-completes.patch
as Cc: [4.1+]
But for backporting purposes it's a bit cumbersome that [2/3] is the
important patch. I think I'll switch the ordering so that
mm-meminit-recalculate-pcpu-batch-and-high-limits-after-init-completes.patch
is the first patch and the other two can be queued for 5.5-rc1, OK?
Also, is a Reported-by:Matt appropriate here?
From: Mel Gorman
Subject: mm, meminit: recalculate pcpu batch and high limits after init
completes
Deferred memory initialisation updates zone->managed_pages during the
initialisation phase but before that finishes, the per-cpu page allocator
(pcpu) calculates the number of pages allocated/freed in batches as well
as the maximum number of pages allowed on a per-cpu list. As
zone->managed_pages is not up to date yet, the pcpu initialisation
calculates inappropriately low batch and high values.
This increases zone lock contention quite severely in some cases with the
degree of severity depending on how many CPUs share a local zone and the
size of the zone. A private report indicated that kernel build times were
excessive with extremely high system CPU usage. A perf profile indicated
that a large chunk of time was lost on zone->lock contention.
This patch recalculates the pcpu batch and high values after deferred
initialisation completes on each node. It was tested on a 2-socket AMD
EPYC 2 machine using a kernel compilation workload -- allmodconfig and all
available CPUs.
mmtests configuration: config-workload-kernbench-max Configuration was
modified to build on a fresh XFS partition.
kernbench
5.4.0-rc3 5.4.0-rc3
vanilla resetpcpu-v1r1
Amean user-25613249.50 ( 0.00%)15928.40 * -20.22%*
Amean syst-25614760.30 ( 0.00%) 4551.77 * 69.16%*
Amean elsp-256 162.42 ( 0.00%) 118.46 * 27.06%*
Stddevuser-256 42.97 ( 0.00%) 50.83 ( -18.30%)
Stddevsyst-256 336.87 ( 0.00%) 33.70 ( 90.00%)
Stddevelsp-2562.46 ( 0.00%)0.81 ( 67.01%)
5.4.0-rc3 5.4.0-rc3
vanillaresetpcpu-v1r1
Duration User 39766.2447802.92
Duration System 44298.1013671.93
Duration Elapsed 519.11 387.65
The patch reduces system CPU usage by 69.16% and total build time by
27.06%. The variance of system CPU usage is also much reduced.
Link: http://lkml.kernel.org/r/20191018105606.3249-3-mgor...@techsingularity.net
Signed-off-by: Mel Gorman
Tested-by: Matt Fleming
Acked-by: Michal Hocko
Cc: Vlastimil Babka
Cc: Thomas Gleixner
Cc: Borislav Petkov
Cc: [4.1+]
Signed-off-by: Andrew Morton
---
mm/page_alloc.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
---
a/mm/page_alloc.c~mm-meminit-recalculate-pcpu-batch-and-high-limits-after-init-completes
+++ a/mm/page_alloc.c
@@ -1818,6 +1818,14 @@ static int __init deferred_init_memmap(v
*/
while (spfn < epfn)
nr_pages += deferred_init_maxorder(&i, zone, &spfn, &epfn);
+
+ /*
+* The number of managed pages has changed due to the initialisation
+* so the pcpu batch and high limits needs to be updated or the limits
+* will be artificially small.
+*/
+ zone_pcp_update(zone);
+
zone_empty:
pgdat_resize_unlock(pgdat, &flags);
@@ -8514,7 +8522,6 @@ void free_contig_range(unsigned long pfn
WARN(count != 0, "%d pages are still in use!\n", count);
}
-#ifdef CONFIG_MEMORY_HOTPLUG
/*
* The zone indicated has a new number of managed_pages; batch sizes and percpu
* page high values need to be recalulated.
@@ -8528,7 +8535,6 @@ void __meminit zone_pcp_update(struct zo
per_cpu_ptr(zone->pageset, cpu));
mutex_unlock(&pcp_batch_high_lock);
}
-#endif
void zone_pcp_reset(struct zone *zone)
{
_
Re: [PATCH v2] ftgmac100: Disable HW checksum generation on AST2500
On 10/18/19, 5:03 PM, "Benjamin Herrenschmidt" wrote: On Fri, 2019-10-18 at 22:50 +, Vijay Khemka wrote: > I don't have much understanding of IP Stack but I went through code details and > you are right and found that it should fallback to SW calculation for IPV6 but it doesn't > happen because ftgmac100_hard_start_xmit checks for CHECKSUM_PARTIAL before > setting HW checksum and calling ftgmac100_prep_tx_csum function. And in my > understanding, this value is set CHECKSUM_PARTIAL in IP stack. I looked up IP stack for > IPV6, file net/ipv6/ip6_output.c, function __ip6_append_data: here it sets > CHECKSUM_PARTIAL only for UDP packets not for TCP packets. Please look at line > number 1880. This could be an issue we are seeing here as why > ftgmac100_prep_tx_csum is not getting triggered for IPV6 with TCP. Please correct > me if my understanding is wrong. > Not entirely sure. tcp_v6_send_response() in tcp_ipv6.c does set CHECKSUM_PARTIAL as well. I don't really know how things are being handled in that part of the network stack though. From a driver perspective, if the value of ip_summed is not CHECKSUM_PARTIAL it means we should not have to calculate any checksum. At least that's my understanding here. You may need to add some traces to the driver to see what you get in there, what protocol indication etc... and analyze the corresponding packets with something like tcpdump or wireshark on the other end. Thanks Ben, I will try to add some trace and test whatever possible and test it. As we don't have tcpdump into our image and I have limited understanding of networking stack so if you get some time to verify ipv6, it will be really helpful. Cheers, Ben.
Re: [PATCH v2 3/3] KVM: VMX: Some minor refactor of MSR bitmap
On 10/19/2019 1:27 AM, Sean Christopherson wrote:
On Fri, Oct 18, 2019 at 05:37:23PM +0800, Xiaoyao Li wrote:
Move the MSR bitmap capability check from vmx_disable_intercept_for_msr()
and vmx_enable_intercept_for_msr(), so that we can do the check far
early before we really want to touch the bitmap.
Also, we can move the common MSR not-intercept setup to where msr bitmap
is actually used.
Signed-off-by: Xiaoyao Li
---
Changes in v2:
- Remove the check of cpu_has_vmx_msr_bitmap() from
vmx_{disable,enable}_intercept_for_msr (Krish)
---
arch/x86/kvm/vmx/vmx.c | 65 +-
1 file changed, 33 insertions(+), 32 deletions(-)
diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c
index b083316a598d..017689d0144e 100644
--- a/arch/x86/kvm/vmx/vmx.c
+++ b/arch/x86/kvm/vmx/vmx.c
@@ -343,8 +343,8 @@ module_param_cb(vmentry_l1d_flush, &vmentry_l1d_flush_ops,
NULL, 0644);
static bool guest_state_valid(struct kvm_vcpu *vcpu);
static u32 vmx_segment_access_rights(struct kvm_segment *var);
-static __always_inline void vmx_disable_intercept_for_msr(unsigned long
*msr_bitmap,
- u32 msr, int type);
+static __always_inline void vmx_set_intercept_for_msr(unsigned long
*msr_bitmap,
+ u32 msr, int type, bool value);
void vmx_vmexit(void);
@@ -2000,9 +2000,9 @@ static int vmx_set_msr(struct kvm_vcpu *vcpu, struct msr_data *msr_info)
* in the merging. We update the vmcs01 here for L1 as well
* since it will end up touching the MSR anyway now.
*/
- vmx_disable_intercept_for_msr(vmx->vmcs01.msr_bitmap,
- MSR_IA32_SPEC_CTRL,
- MSR_TYPE_RW);
+ vmx_set_intercept_for_msr(vmx->vmcs01.msr_bitmap,
+ MSR_IA32_SPEC_CTRL,
+ MSR_TYPE_RW, false);
IMO this is a net negative. The explicit "disable" is significantly more
intuitive than "set" with a %false param, e.g. at a quick glance it would
be easy to think this code is "setting", i.e. "enabling" interception.
How about renaming it to vmx_switch_intercept_for_msr()?
or just add the cpu_has_vmx_msr_bitmap() check outside because the check
is removed in vmx_disable_intercept_for_msr()
break;
case MSR_IA32_PRED_CMD:
if (!msr_info->host_initiated &&
@@ -2028,8 +2028,9 @@ static int vmx_set_msr(struct kvm_vcpu *vcpu, struct
msr_data *msr_info)
* vmcs02.msr_bitmap here since it gets completely overwritten
* in the merging.
*/
- vmx_disable_intercept_for_msr(vmx->vmcs01.msr_bitmap,
MSR_IA32_PRED_CMD,
- MSR_TYPE_W);
+ vmx_set_intercept_for_msr(vmx->vmcs01.msr_bitmap,
+ MSR_IA32_PRED_CMD,
+ MSR_TYPE_W, false);
break;
case MSR_IA32_CR_PAT:
if (!kvm_pat_valid(data))
@@ -3599,9 +3600,6 @@ static __always_inline void
vmx_disable_intercept_for_msr(unsigned long *msr_bit
{
int f = sizeof(unsigned long);
- if (!cpu_has_vmx_msr_bitmap())
- return;
As above, I'd rather keep these here. Functionally it changes nothing on
CPUs with an MSR bitmap. For old CPUs, it saves all of two uops in paths
that aren't performance critical.
-
if (static_branch_unlikely(&enable_evmcs))
evmcs_touch_msr_bitmap();
@@ -3637,9 +3635,6 @@ static __always_inline void vmx_enable_intercept_for_msr(unsigned long *msr_bitm
{
int f = sizeof(unsigned long);
- if (!cpu_has_vmx_msr_bitmap())
- return;
-
if (static_branch_unlikely(&enable_evmcs))
evmcs_touch_msr_bitmap();
@@ -3673,6 +3668,9 @@ static __always_inline void vmx_enable_intercept_for_msr(unsigned long *msr_bitm
static __always_inline void vmx_set_intercept_for_msr(unsigned long
*msr_bitmap,
u32 msr, int type, bool
value)
{
+ if (!cpu_has_vmx_msr_bitmap())
+ return;
+
if (value)
vmx_enable_intercept_for_msr(msr_bitmap, msr, type);
else
@@ -4163,11 +4161,30 @@ static void ept_set_mmio_spte_mask(void)
static void vmx_vmcs_setup(struct vcpu_vmx *vmx)
{
+ unsigned long *msr_bitmap;
+
if (nested)
nested_vmx_vmcs_setup();
- if (cpu_has_vmx_msr_bitmap())
+ if (cpu_has_vmx_msr_bitmap()) {
+ msr_bitmap = vmx->vmcs01.msr_bitmap;
+ vmx_disable_intercept_for_msr(msr_bitmap, MSR_IA32_TSC,
MSR_TYPE_R);
+ vmx_disable_intercept_for_msr(msr_bitmap, MSR_FS_BASE,
MSR_TYPE_RW);
+ vmx_disable_int
Re: [PATCH v3] mm,thp: recheck each page before collapsing file THP
On Fri, 18 Oct 2019 11:03:45 -0700 Song Liu wrote:
> In collapse_file(), after locking the page, it is necessary to recheck
> that the page is up-to-date. Add PageUptodate() check for both shmem THP
> and file THP.
>
> Current khugepaged should not try to collapse dirty file THP, because it
> is limited to read only text. Add a PageDirty check and warning for file
> THP. This is added after page_mapping() check, because if the page is
> truncated, it might be dirty.
When fixing a bug, please always fully describe the end-user visible
effects of that bug. This is vital information for people who are
considering the fix for backporting.
I'm suspecting that you've found a race condition which can trigger a
VM_BUG_ON_PAGE(), which is rather serious. But that was just a wild
guess. Please don't make us wildly guess :(
The old code looked rather alarming:
} else if (!PageUptodate(page)) {
xas_unlock_irq(&xas);
wait_on_page_locked(page);
if (!trylock_page(page)) {
result = SCAN_PAGE_LOCK;
goto xa_unlocked;
}
get_page(page);
We don't have a ref on that page. After we've released the xarray lock
we have no business playing with *page at all, correct?
Re: [PATCH 00/46] ARM: pxa: towards multiplatform support
On 10/18/19 8:40 AM, Arnd Bergmann wrote: Hi PXA maintainers, I'm in the process of getting the old ARM platforms to all build in a single kernel. The largest part of that work is changing all the device drivers to no longer require mach/*.h header files. This series does it for arch/pxa/. As with the omap1 and s3c24xx series I sent before, I don't expect this all to be correct in the first version, though a lot of the patches are fairly simple and I did exhaustive compile-time testing on them. Please test if you have the hardware, or review! I don't get very far. $ make-arm pxa_defconfig arch/arm/Kconfig:677: can't open file "arch/arm/plat-pxa/Kconfig" scripts/kconfig/Makefile:90: recipe for target 'pxa_defconfig' failed make[1]: *** [pxa_defconfig] Error 1 Makefile:567: recipe for target 'pxa_defconfig' failed make: *** [pxa_defconfig] Error 2 $ git describe v5.4-rc3-52-gfcc4181cd625 Also: $ git grep plat-pxa Documentation/arm/marvel.rst: arch/arm/plat-pxa Documentation/arm/marvel.rst: arch/arm/plat-pxa Documentation/arm/marvel.rst: directory. The plat-pxa/ would therefore disappear. arch/arm/Kconfig:source "arch/arm/plat-pxa/Kconfig" arch/arm/mach-mmp/Makefile:ccflags-$(CONFIG_ARCH_MULTIPLATFORM) := -I$(srctree)/arch/arm/plat-pxa/include drivers/gpio/gpio-pxa.c: * linux/arch/arm/plat-pxa/gpio.c drivers/soc/pxa/mfp.c: * linux/arch/arm/plat-pxa/mfp.c Did I pick the wrong tree ? Guenter
Re: [PATCH] clocksource: tsc: respect tsc bootparam for clocksource_tsc_early
On 10/18/19, 2:41 PM, "Thomas Gleixner" wrote: > On Wed, 2 Oct 2019, Michael Zhivich wrote: > > Introduction of clocksource_tsc_early broke functionality of "tsc=reliable" > > and "tsc=nowatchdog" boot params, since clocksource_tsc_early is *always* > > registered with CLOCK_SOURCE_MUST_VERIFY and thus put on the watchdog list. > > > > If CPU is very busy during boot, the watchdog clocksource may not be > > read frequently enough, resulting in a large difference that is treated as > > "negative" by clocksource_delta() and incorrectly truncated to 0. > > What? > > > clocksource: timekeeping watchdog on CPU1: Marking clocksource > >'tsc-early' as unstable because the skew is too large: > > clocksource: 'refined-jiffies' wd_now: fffb7019 wd_last: fffb6e28 > > 0xfffb7019 - 0xfffb6e28 = 497 > > What's treated negative there? And what would truncate that to 0? > > > mask: > > A 'negative delta' value can only happen when the clocksource is not read > before it advanced more than mask/2. For jiffies this means 2^31 > ticks. That would be ~248 days for HZ=100 or ~24 days for HZ=1000. > > > clocksource: 'tsc-early' cs_now: 52c3918b89d6 cs_last: 52c31d736d2e > > 0x52c3918b89d6 - 0x52c31d736d2e = 1.94774e+09 > > Again nothing is treated negative here, but the point is that the TSC > advanced by ~2e9 cycles while jiffies advanced by 497. > > How that's related, I can't tell because I don't know the TSC frequency of > your machine. HZ is probably 1000 as the watchdog period is HZ/2. > > > mask: > > tsc: Marking TSC unstable due to clocksource watchdog > > Even if the watchdog is not read out for a quite some time, the math in > there and in clocksource_delta() can handle pretty large deltas. > > The watchdog triggers when > > abs(delta_watchdog - delta_tsc) > 0.0625 seconds > > So that has absolutely nothing to do with CPU being busy and watchdog not > being serviced. jiffies and TSC drift apart for some reason, and that > reason wants to be documented in the changelog. > > That said, I have no objections against the patch itself, but I'm not going > to apply a patch with a fairy tale changelog. > > Thanks, > > tglx > Thanks for taking a look. I agree that the commit message explanation is bogus; I had incorrectly assumed that the issue was similar to what I've seen with acpi_pm based watchdog before and didn't check the numbers carefully. I'll rework the commit message and resubmit. Thanks, ~ Michael smime.p7s Description: S/MIME cryptographic signature
Re: [PATCH 06/18] add support for Clang's Shadow Call Stack (SCS)
On Fri, Oct 18, 2019 at 10:33 PM Nick Desaulniers wrote: > > Sami pointed out to me off thread that __has_attribute would only > check `no_sanitize`, not `shadow-call-stack`. So maybe best to keep > the definition here (include/linux/compiler-clang.h), but wrapped in a > `__has_feature` check so that Clang 6.0 doesn't start complaining. Ah, good point -- agreed! Cheers, Miguel
Re: [PATCH AUTOSEL 5.3 50/89] kbuild: fix build error of 'make nsdeps' in clean tree
On Sat, Oct 19, 2019 at 7:04 AM Sasha Levin wrote: > > From: Masahiro Yamada > > [ Upstream commit d85103ac78a6d8573b21348b36f4cca2e1839a31 ] > > Running 'make nsdeps' in a clean source tree fails as follows: > > $ make -s clean; make -s defconfig; make nsdeps >[ snip ] > awk: fatal: cannot open file `init/modules.order' for reading (No such file > or directory) > make: *** [Makefile;1307: modules.order] Error 2 > make: *** Deleting file 'modules.order' > make: *** Waiting for unfinished jobs > > The cause of the error is 'make nsdeps' does not build modules at all. > Set KBUILD_MODULES to fix it. > > Reviewed-by: Matthias Maennich > Signed-off-by: Masahiro Yamada > Signed-off-by: Jessica Yu > Signed-off-by: Sasha Levin > --- nsdeps was introduced in v5.4 Please do not backport this commit. > Makefile | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/Makefile b/Makefile > index d7469f0926a67..62b9640d007a0 100644 > --- a/Makefile > +++ b/Makefile > @@ -594,7 +594,7 @@ endif > # in addition to whatever we do anyway. > # Just "make" or "make all" shall build modules as well > > -ifneq ($(filter all _all modules,$(MAKECMDGOALS)),) > +ifneq ($(filter all _all modules nsdeps,$(MAKECMDGOALS)),) >KBUILD_MODULES := 1 > endif > > -- > 2.20.1 > -- Best Regards Masahiro Yamada
Re: [PATCH AUTOSEL 4.14 39/56] kbuild: fix build error of 'make nsdeps' in clean tree
On Sat, Oct 19, 2019 at 7:15 AM Sasha Levin wrote: > > From: Masahiro Yamada > > [ Upstream commit d85103ac78a6d8573b21348b36f4cca2e1839a31 ] > > Running 'make nsdeps' in a clean source tree fails as follows: > > $ make -s clean; make -s defconfig; make nsdeps >[ snip ] > awk: fatal: cannot open file `init/modules.order' for reading (No such file > or directory) > make: *** [Makefile;1307: modules.order] Error 2 > make: *** Deleting file 'modules.order' > make: *** Waiting for unfinished jobs > > The cause of the error is 'make nsdeps' does not build modules at all. > Set KBUILD_MODULES to fix it. > > Reviewed-by: Matthias Maennich > Signed-off-by: Masahiro Yamada > Signed-off-by: Jessica Yu > Signed-off-by: Sasha Levin > --- nsdeps was introduced in v5.4 Please do not backport this commit. > Makefile | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/Makefile b/Makefile > index 93c3467eeb8c9..731a2ce8a749a 100644 > --- a/Makefile > +++ b/Makefile > @@ -554,7 +554,7 @@ endif > # in addition to whatever we do anyway. > # Just "make" or "make all" shall build modules as well > > -ifneq ($(filter all _all modules,$(MAKECMDGOALS)),) > +ifneq ($(filter all _all modules nsdeps,$(MAKECMDGOALS)),) >KBUILD_MODULES := 1 > endif > > -- > 2.20.1 > -- Best Regards Masahiro Yamada
Re: [PATCH AUTOSEL 4.19 077/100] kbuild: fix build error of 'make nsdeps' in clean tree
Hi Sasha, On Sat, Oct 19, 2019 at 7:18 AM Sasha Levin wrote: > > From: Masahiro Yamada > > [ Upstream commit d85103ac78a6d8573b21348b36f4cca2e1839a31 ] > > Running 'make nsdeps' in a clean source tree fails as follows: > > $ make -s clean; make -s defconfig; make nsdeps >[ snip ] > awk: fatal: cannot open file `init/modules.order' for reading (No such file > or directory) > make: *** [Makefile;1307: modules.order] Error 2 > make: *** Deleting file 'modules.order' > make: *** Waiting for unfinished jobs > > The cause of the error is 'make nsdeps' does not build modules at all. > Set KBUILD_MODULES to fix it. > > Reviewed-by: Matthias Maennich > Signed-off-by: Masahiro Yamada > Signed-off-by: Jessica Yu > Signed-off-by: Sasha Levin > --- nsdeps was introduced in v5.4 Please do not backport this commit. Thanks. > Makefile | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/Makefile b/Makefile > index 4d29c7370b464..80f169534c4a7 100644 > --- a/Makefile > +++ b/Makefile > @@ -566,7 +566,7 @@ endif > # in addition to whatever we do anyway. > # Just "make" or "make all" shall build modules as well > > -ifneq ($(filter all _all modules,$(MAKECMDGOALS)),) > +ifneq ($(filter all _all modules nsdeps,$(MAKECMDGOALS)),) >KBUILD_MODULES := 1 > endif > > -- > 2.20.1 > -- Best Regards Masahiro Yamada
[PATCH] mtd: rawnand: brcmnand: Fix sparse warning in has_flash_dma()
Sparse rightfully complained about has_flash_dma():
+drivers/mtd/nand/brcmnand/brcmnand.c:951:40: warning: Using plain integer as
NULL pointer [sparse]
Fixes: 27c5b17cd1b1 ("mtd: nand: add NAND driver "library" for Broadcom STB
NAND controller")
Signed-off-by: Florian Fainelli
---
drivers/mtd/nand/raw/brcmnand/brcmnand.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mtd/nand/raw/brcmnand/brcmnand.c
b/drivers/mtd/nand/raw/brcmnand/brcmnand.c
index 15ef30b368a5..73f7a0945399 100644
--- a/drivers/mtd/nand/raw/brcmnand/brcmnand.c
+++ b/drivers/mtd/nand/raw/brcmnand/brcmnand.c
@@ -909,7 +909,7 @@ static inline void brcmnand_set_wp(struct
brcmnand_controller *ctrl, bool en)
static inline bool has_flash_dma(struct brcmnand_controller *ctrl)
{
- return ctrl->flash_dma_base;
+ return ctrl->flash_dma_base != NULL;
}
static inline void disable_ctrl_irqs(struct brcmnand_controller *ctrl)
--
2.17.1
Re: [PATCH v2] ftgmac100: Disable HW checksum generation on AST2500
On Fri, 2019-10-18 at 22:50 +, Vijay Khemka wrote: > I don't have much understanding of IP Stack but I went through code details > and > you are right and found that it should fallback to SW calculation for IPV6 > but it doesn't > happen because ftgmac100_hard_start_xmit checks for CHECKSUM_PARTIAL before > setting HW checksum and calling ftgmac100_prep_tx_csum function. And in my > understanding, this value is set CHECKSUM_PARTIAL in IP stack. I looked up IP > stack for > IPV6, file net/ipv6/ip6_output.c, function __ip6_append_data: here it sets > CHECKSUM_PARTIAL only for UDP packets not for TCP packets. Please look at line > number 1880. This could be an issue we are seeing here as why > ftgmac100_prep_tx_csum is not getting triggered for IPV6 with TCP. Please > correct > me if my understanding is wrong. > Not entirely sure. tcp_v6_send_response() in tcp_ipv6.c does set CHECKSUM_PARTIAL as well. I don't really know how things are being handled in that part of the network stack though. >From a driver perspective, if the value of ip_summed is not CHECKSUM_PARTIAL it means we should not have to calculate any checksum. At least that's my understanding here. You may need to add some traces to the driver to see what you get in there, what protocol indication etc... and analyze the corresponding packets with something like tcpdump or wireshark on the other end. Cheers, Ben.
Re: [PATCH 03/15] riscv: abstract out CSR names for supervisor vs machine mode
On Thu, 17 Oct 2019, Christoph Hellwig wrote: > Many of the privileged CSRs exist in a supervisor and machine version > that are used very similarly. Provide a new X-naming layer so that > we don't have to ifdef everywhere for M-mode Linux support. > > Contains contributions from Damien Le Moal . > > Signed-off-by: Christoph Hellwig > Reviewed-by: Atish Patra The basic idea looks good to me, but some of the X-prefixing can make the code difficult to read. The Xret macro looks fine to me, as do the XIE_XTIE macros. But I think it would be better if the X-prefixes on the rest of the macros and structure members could be dropped. This also aligns with the way that these registers often are discussed at the architectural level; e.g., we'd talk about the "epc" registers, not the "xepc" registers. Just for reference, your v4 patch with that change implemented is below. I've been testing with here. - Paul From: Christoph Hellwig Date: Mon, 19 Aug 2019 12:30:23 +0200 Subject: [PATCH] riscv: abstract out CSR names for supervisor vs machine mode Many of the privileged CSRs exist in a supervisor and machine version that are used very similarly. Provide a new X-naming layer so that we don't have to ifdef everywhere for M-mode Linux support. Contains contributions from Damien Le Moal . Signed-off-by: Christoph Hellwig Reviewed-by: Atish Patra [paul.walms...@sifive.com: removed X in most macros/variables; fixed bug in start_thread; updated to apply] --- arch/riscv/Kconfig | 4 ++ arch/riscv/include/asm/asm.h | 6 +++ arch/riscv/include/asm/csr.h | 58 -- arch/riscv/include/asm/irqflags.h | 12 +++--- arch/riscv/include/asm/processor.h | 2 +- arch/riscv/include/asm/ptrace.h| 16 arch/riscv/include/asm/switch_to.h | 10 ++--- arch/riscv/kernel/asm-offsets.c| 8 ++-- arch/riscv/kernel/entry.S | 66 -- arch/riscv/kernel/fpu.S| 8 ++-- arch/riscv/kernel/head.S | 12 +++--- arch/riscv/kernel/irq.c| 4 +- arch/riscv/kernel/process.c| 15 +++ arch/riscv/kernel/signal.c | 21 +- arch/riscv/kernel/traps.c | 18 arch/riscv/lib/uaccess.S | 12 +++--- arch/riscv/mm/extable.c| 4 +- arch/riscv/mm/fault.c | 6 +-- drivers/clocksource/timer-riscv.c | 8 ++-- drivers/irqchip/irq-sifive-plic.c | 4 +- 20 files changed, 181 insertions(+), 113 deletions(-) diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig index 8eebbc8860bb..86b7e8b0471c 100644 --- a/arch/riscv/Kconfig +++ b/arch/riscv/Kconfig @@ -72,6 +72,10 @@ config ARCH_MMAP_RND_BITS_MAX default 24 if 64BIT # SV39 based default 17 +# set if we run in machine mode, cleared if we run in supervisor mode +config RISCV_M_MODE + bool + config MMU def_bool y diff --git a/arch/riscv/include/asm/asm.h b/arch/riscv/include/asm/asm.h index 9c992a88d858..e362fb741c76 100644 --- a/arch/riscv/include/asm/asm.h +++ b/arch/riscv/include/asm/asm.h @@ -66,4 +66,10 @@ #error "Unexpected __SIZEOF_SHORT__" #endif +#ifdef CONFIG_RISCV_M_MODE +# define Xret mret +#else +# define Xret sret +#endif + #endif /* _ASM_RISCV_ASM_H */ diff --git a/arch/riscv/include/asm/csr.h b/arch/riscv/include/asm/csr.h index a18923fa23c8..583be1861ff1 100644 --- a/arch/riscv/include/asm/csr.h +++ b/arch/riscv/include/asm/csr.h @@ -11,8 +11,11 @@ /* Status register flags */ #define SR_SIE _AC(0x0002, UL) /* Supervisor Interrupt Enable */ +#define SR_MIE _AC(0x0008, UL) /* Machine Interrupt Enable */ #define SR_SPIE_AC(0x0020, UL) /* Previous Supervisor IE */ +#define SR_MPIE_AC(0x0080, UL) /* Previous Machine IE */ #define SR_SPP _AC(0x0100, UL) /* Previously Supervisor */ +#define SR_MPP _AC(0x1800, UL) /* Previously Machine */ #define SR_SUM _AC(0x0004, UL) /* Supervisor User Memory Access */ #define SR_FS _AC(0x6000, UL) /* Floating-point Status */ @@ -44,8 +47,8 @@ #define SATP_MODE SATP_MODE_39 #endif -/* SCAUSE */ -#define SCAUSE_IRQ_FLAG(_AC(1, UL) << (__riscv_xlen - 1)) +/* *CAUSE */ +#define CAUSE_IRQ_FLAG (_AC(1, UL) << (__riscv_xlen - 1)) #define IRQ_U_SOFT 0 #define IRQ_S_SOFT 1 @@ -67,11 +70,26 @@ #define EXC_LOAD_PAGE_FAULT13 #define EXC_STORE_PAGE_FAULT 15 -/* SIE (Interrupt Enable) and SIP (Interrupt Pending) flags */ +/* SIE/SIP (Machine Interrupt Enable/Pending) flags */ +#define MIE_MSIE (_AC(0x1, UL) << IRQ_M_SOFT) +#define MIE_MTIE (_AC(0x1, UL) << IRQ_M_TIMER) +#define MIE_MEIE (_AC(0x1, UL) << IRQ_M_EXT) + +/* SIE/SIP (Supervisor Interrupt Enable/Pending) flags */ #define SIE_SSIE (_AC(0x1, UL) << IRQ_S_SOFT) #define SIE_STIE
Re: RISC-V nommu support v5
On Fri, 18 Oct 2019, Christoph Hellwig wrote: > On Thu, Oct 17, 2019 at 08:29:59PM -0700, Paul Walmsley wrote: > > On Fri, 18 Oct 2019, Anup Patel wrote: > > > > > It will be really cool to have this series for Linux-5.4-rcX. > > > > It's way too big to go in via the -rc series. I'm hoping to have it ready > > to go for v5.5-rc1. > > Yes, this is 5.5 material. Btw, the buildbot found two issues that > require one liner fixes, so I'll resend again this weekend. OK, will wait for the next version. I do have one significant request for the patch "riscv: abstract out CSR names for supervisor vs machine mode" for that next release. Will follow up with a comment on that patch. - Paul
Re: WARNING: ODEBUG bug in del_timer
Hi
The customizations are related to driver fuzzing.
We added some more descriptions of USB driver & narrowed the
constraints (targeted fuzzing).
And sorry about I have not much time to make patches of these bugs.
On Fri, Oct 18, 2019 at 2:33 AM Dmitry Vyukov wrote:
>
> On Wed, Oct 16, 2019 at 11:59 AM zzoru wrote:
> >
> > We found the following crash on Linux 5.4-rc1 (Not patched in currnet
> > HEAD commit 3b1f00aceb7a67bf079a5a64aa5c6baf78a8f442)
> > with our customized syzkaller.
>
> Hi zzoru,
>
> Do you mind sharing what customizations you did to syzkaller? Are
> these related to USB? I've noticed several reports were related to USB
> subsystem.
>
> > ODEBUG: assert_init not available (active state 0) object type:
> > timer_list hint: 0x0
> > WARNING: CPU: 0 PID: 141 at linux/lib/debugobjects.c:484
> > debug_print_object+0x15e/0x220 linux/lib/debugobjects.c:481
> > Kernel panic - not syncing: panic_on_warn set ...
> > CPU: 0 PID: 141 Comm: kworker/0:3 Not tainted 5.4.0-rc1 #5
> > Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
> > rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org 04/01/2014
> > Workqueue: usb_hub_wq hub_event
> > Call Trace:
> > __dump_stack linux/lib/dump_stack.c:77 [inline]
> > dump_stack+0x7c/0xbb linux/lib/dump_stack.c:113
> > panic+0x205/0x48e linux/kernel/panic.c:220
> > __warn+0x19c/0x1c0 linux/kernel/panic.c:581
> > report_bug+0x1a9/0x2b0 linux/lib/bug.c:195
> > fixup_bug.part.11+0x32/0x80 linux/arch/x86/kernel/traps.c:179
> > fixup_bug linux/arch/x86/include/asm/irqflags.h:54 [inline]
> > do_error_trap+0xf5/0x160 linux/arch/x86/kernel/traps.c:272
> > do_invalid_op+0x31/0x40 linux/arch/x86/kernel/traps.c:291
> > invalid_op+0x23/0x30 linux/arch/x86/entry/entry_64.S:1028
> > RIP: 0010:debug_print_object+0x15e/0x220 linux/lib/debugobjects.c:481
> > Code: 3c dd 80 05 9a 85 48 89 fa 48 c1 ea 03 80 3c 02 00 75 7f 48 8b
> > 14 dd 80 05 9a 85 4c 89 ee 48 c7 c7 00 fb 99 85 e8 d2 a7 43 ff <0f> 0b
> > 83 05 cd bd 70 05 01 48 83 c4 18 5b 5d 41 5c 41 5d 41 5e c3
> > RSP: 0018:888017017668 EFLAGS: 00010282
> > RAX: RBX: 0005 RCX: 814153b0
> > RDX: RSI: 0008 RDI: 88801a41f730
> > RBP: 0001 R08: ed1003483ee7 R09: ed1003483ee7
> > R10: 0001 R11: ed1003483ee6 R12: 86908460
> > R13: 859a01a0 R14: 812b6bc0 R15: 888017fb0420
> > debug_object_assert_init+0x290/0x430 linux/lib/debugobjects.c:866
> > debug_timer_assert_init linux/kernel/time/timer.c:729 [inline]
> > debug_assert_init linux/kernel/time/timer.c:774 [inline]
> > del_timer+0x67/0xf0 linux/kernel/time/timer.c:1196
> > realtek_cr_destructor+0x5a/0x90 linux/drivers/usb/storage/realtek_cr.c:937
> > usb_stor_release_resources linux/drivers/usb/storage/usb.c:817 [inline]
> > release_everything+0xc0/0x2c0 linux/drivers/usb/storage/usb.c:879
> > usb_unbind_interface+0x19f/0x810 linux/drivers/usb/core/driver.c:423
> > __device_release_driver linux/drivers/base/dd.c:1134 [inline]
> > device_release_driver_internal+0x429/0x4f0 linux/drivers/base/dd.c:1165
> > bus_remove_device+0x2d1/0x490 linux/drivers/base/bus.c:532
> > device_del+0x403/0xaa0 linux/drivers/base/core.c:2375
> > usb_disable_device+0x1d7/0x5f0 linux/drivers/usb/core/message.c:1237
> > usb_disconnect+0x25a/0x840 linux/drivers/usb/core/hub.c:2199
> > hub_port_connect linux/drivers/usb/core/hub.c:4949 [inline]
> > hub_port_connect_change linux/drivers/usb/core/hub.c:5213 [inline]
> > port_event linux/drivers/usb/core/hub.c:5359 [inline]
> > hub_event+0x11f5/0x3610 linux/drivers/usb/core/hub.c:5441
> > process_one_work+0x8b5/0x17c0 linux/kernel/workqueue.c:2269
> > worker_thread+0x82/0xb80 linux/kernel/workqueue.c:2415
> > kthread+0x325/0x3e0 linux/kernel/kthread.c:255
> > ret_from_fork+0x24/0x30 linux/arch/x86/entry/entry_64.S:352
> > Dumping ftrace buffer:
> >(ftrace buffer empty)
> > Kernel Offset: disabled
> >
> > Following is my analysis of this bug (Just add some comments in source
> > code):
> > https://github.com/torvalds/linux/blob/e0703556644a531e50b5dc61b9f6ea83af5f6604/drivers/usb/storage/realtek_cr.c#L887-L891
> > static int realtek_cr_autosuspend_setup(struct us_data *us)
> > {
> > ...
> > if (retval != STATUS_SUCCESS) {
> > usb_stor_dbg(us, "Read status fail\n");
> > return -EIO; // Error!
> > }
> > ...
> > timer_setup(&chip->rts51x_suspend_timer, rts51x_suspend_timer_fn,
> > 0); // rts51x_suspend_timer wasn't be initialized. When
> > realtek_cr_autosuspend_setup just returns an error.
> > }
> >
> >
> > https://github.com/torvalds/linux/blob/e0703556644a531e50b5dc61b9f6ea83af5f6604/drivers/usb/storage/realtek_cr.c#L1010-L1012
> >
> > #ifdef CONFIG_REALTEK_AUTOPM
> > if (ss_en)
> > realtek_cr_autosuspend_setup(us); // There isn't any check about
> > return code.
> > #endif
> >
> > https://github.com/torvalds/linux/blob/e0703556644a531e50b5dc61b9f6ea83a
[GIT PULL] RISC-V updates for v5.4-rc4
Linus, The following changes since commit 4f5cafb5cb8471e54afdc9054d973535614f7675: Linux 5.4-rc3 (2019-10-13 16:37:36 -0700) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux.git tags/riscv/for-v5.4-rc4 for you to fetch changes up to 5bf4e52ff0317db083fafee010dc806f8d4cb0cb: RISC-V: fix virtual address overlapped in FIXADDR_START and VMEMMAP_START (2019-10-15 22:47:41 -0700) RISC-V updates for v5.4-rc4 Some RISC-V fixes for v5.4-rc4: - Fix the virtual memory layout so the fixaddr region doesn't overlap with other regions. (This was originally intended to go in as part of an earlier patch, but I inadvertently dropped it during a rebase.) - Add the DT chosen/stdout-path property to the HiFive Unleashed DT file. This is so "earlycon" can be specified with no arguments on the kernel command line, and the correct UART will be automatically selected. And two cleanup patches: - Simplify the code in our breakpoint trap handler. - Drop a comment in our TLB flush code that has caused some confusion. Greentime Hu (1): RISC-V: fix virtual address overlapped in FIXADDR_START and VMEMMAP_START Paul Walmsley (2): riscv: dts: HiFive Unleashed: add default chosen/stdout-path riscv: tlbflush: remove confusing comment on local_flush_tlb_all() Vincent Chen (1): riscv: remove the switch statement in do_trap_break() .../riscv/boot/dts/sifive/hifive-unleashed-a00.dts | 1 + arch/riscv/include/asm/pgtable.h | 16 arch/riscv/include/asm/tlbflush.h | 4 arch/riscv/kernel/traps.c | 22 +++--- 4 files changed, 20 insertions(+), 23 deletions(-)
[PATCH] ARM: dt: add lsm9ds1 iio imu/magn support to gw553x
Add one node for the accel/gyro i2c device and another for the separate
magnetometer device in the lsm9ds1.
Signed-off-by: Robert Jones
---
arch/arm/boot/dts/imx6qdl-gw553x.dtsi | 31 +++
1 file changed, 31 insertions(+)
diff --git a/arch/arm/boot/dts/imx6qdl-gw553x.dtsi
b/arch/arm/boot/dts/imx6qdl-gw553x.dtsi
index a106689..55e6922 100644
--- a/arch/arm/boot/dts/imx6qdl-gw553x.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-gw553x.dtsi
@@ -173,6 +173,25 @@
pinctrl-0 = <&pinctrl_i2c2>;
status = "okay";
+ lsm9ds1_ag@6a {
+ compatible = "st,lsm9ds1-imu";
+ reg = <0x6a>;
+ st,drdy-int-pin = <1>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_acc_gyro>;
+ interrupt-parent = <&gpio7>;
+ interrupts = <13 IRQ_TYPE_LEVEL_HIGH>;
+ };
+
+ lsm9ds1_m@1c {
+ compatible = "st,lsm9ds1-magn";
+ reg = <0x1c>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_mag>;
+ interrupt-parent = <&gpio1>;
+ interrupts = <2 IRQ_TYPE_EDGE_RISING>;
+ };
+
ltc3676: pmic@3c {
compatible = "lltc,ltc3676";
reg = <0x3c>;
@@ -462,6 +481,18 @@
>;
};
+ pinctrl_acc_gyro: acc_gyrogrp {
+ fsl,pins = <
+ MX6QDL_PAD_GPIO_18__GPIO7_IO13 0x1b0b0
+ >;
+ };
+
+ pinctrl_mag: maggrp {
+ fsl,pins = <
+ MX6QDL_PAD_GPIO_2__GPIO1_IO02 0x1b0b0
+ >;
+ };
+
pinctrl_pps: ppsgrp {
fsl,pins = <
MX6QDL_PAD_ENET_RXD1__GPIO1_IO260x1b0b1
--
2.9.2
[PATCH] ARM: dt: add fxos8700 on gateworks boards
Add fxos8700 iio imu entries for Gateworks SBCs.
Signed-off-by: Robert Jones
---
arch/arm/boot/dts/imx6qdl-gw52xx.dtsi | 5 +
arch/arm/boot/dts/imx6qdl-gw53xx.dtsi | 5 +
arch/arm/boot/dts/imx6qdl-gw54xx.dtsi | 5 +
3 files changed, 15 insertions(+)
diff --git a/arch/arm/boot/dts/imx6qdl-gw52xx.dtsi
b/arch/arm/boot/dts/imx6qdl-gw52xx.dtsi
index 1a9a9d9..ffc4449 100644
--- a/arch/arm/boot/dts/imx6qdl-gw52xx.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-gw52xx.dtsi
@@ -306,6 +306,11 @@
VDDIO-supply = <®_3p3v>;
};
+ fxos8700@1e {
+ compatible = "nxp,fxos8700";
+ reg = <0x1e>;
+ };
+
touchscreen: egalax_ts@4 {
compatible = "eeti,egalax_ts";
reg = <0x04>;
diff --git a/arch/arm/boot/dts/imx6qdl-gw53xx.dtsi
b/arch/arm/boot/dts/imx6qdl-gw53xx.dtsi
index 54b2bea..ebbd1c8 100644
--- a/arch/arm/boot/dts/imx6qdl-gw53xx.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-gw53xx.dtsi
@@ -297,6 +297,11 @@
VDDIO-supply = <®_3p3v>;
};
+ fxos8700@1e {
+ compatible = "nxp,fxos8700";
+ reg = <0x1e>;
+ };
+
touchscreen: egalax_ts@4 {
compatible = "eeti,egalax_ts";
reg = <0x04>;
diff --git a/arch/arm/boot/dts/imx6qdl-gw54xx.dtsi
b/arch/arm/boot/dts/imx6qdl-gw54xx.dtsi
index 1b6c133..67d4725 100644
--- a/arch/arm/boot/dts/imx6qdl-gw54xx.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-gw54xx.dtsi
@@ -354,6 +354,11 @@
VDDIO-supply = <®_3p3v>;
};
+ fxos8700@1e {
+ compatible = "nxp,fxos8700";
+ reg = <0x1e>;
+ };
+
touchscreen: egalax_ts@4 {
compatible = "eeti,egalax_ts";
reg = <0x04>;
--
2.9.2
[PATCH 1/2] platform/x86: Adding support for Acer Aspire 7551
From: Peter Feuerer
platform/x86: Adding support for Acer Aspire 7551
Cc: Darren Hart
Cc: Andy Shevchenko
Signed-off-by: Peter Feuerer
---
drivers/platform/x86/acerhdf.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/platform/x86/acerhdf.c b/drivers/platform/x86/acerhdf.c
index 5ea8da5f0f70..d40f365d8d7a 100644
--- a/drivers/platform/x86/acerhdf.c
+++ b/drivers/platform/x86/acerhdf.c
@@ -224,6 +224,8 @@ static const struct bios_settings bios_tbl[] __initconst = {
{"Acer", "Aspire 5739G", "V1.3311", 0x55, 0x58, {0x20, 0x00}, 0},
/* Acer TravelMate 7730 */
{"Acer", "TravelMate 7730G", "v0.3509", 0x55, 0x58, {0xaf, 0x00}, 0},
+ /* Acer Aspire 7551 */
+ {"Acer", "Aspire 7551", "V1.18", 0x93, 0xa8, {0x14, 0x04}, 1},
/* Acer TravelMate TM8573T */
{"Acer", "TM8573T", "V1.13", 0x93, 0xa8, {0x14, 0x04}, 1},
/* Gateway */
@@ -815,6 +817,7 @@ MODULE_ALIAS("dmi:*:*Acer*:pnAspire*5739G:");
MODULE_ALIAS("dmi:*:*Acer*:pnAspire*One*753:");
MODULE_ALIAS("dmi:*:*Acer*:pnAspire*5315:");
MODULE_ALIAS("dmi:*:*Acer*:TravelMate*7730G:");
+MODULE_ALIAS("dmi:*:*Acer*:pnAspire*7551:");
MODULE_ALIAS("dmi:*:*Acer*:TM8573T:");
MODULE_ALIAS("dmi:*:*Gateway*:pnAOA*:");
MODULE_ALIAS("dmi:*:*Gateway*:pnLT31*:");
--
2.23.0
[PATCH 2/2] treewide: Rename Peter Feuerer to Peter Kaestle
treewide: Rename Peter Feuerer to Peter Kaestle
Cc: Darren Hart
Cc: Andy Shevchenko
Cc: Zhang Rui
Cc: Eduardo Valentin
Cc: Greg Kroah-Hartman
Signed-off-by: Peter Kaestle
---
MAINTAINERS | 2 +-
drivers/platform/x86/acerhdf.c | 4 ++--
drivers/thermal/gov_bang_bang.c | 2 +-
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 0154674cbad3..a907670c5e79 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -295,7 +295,7 @@ S: Maintained
F: drivers/net/ethernet/alteon/acenic*
ACER ASPIRE ONE TEMPERATURE AND FAN DRIVER
-M: Peter Feuerer
+M: Peter Kaestle
L: platform-driver-...@vger.kernel.org
W: http://piie.net/?section=acerhdf
S: Maintained
diff --git a/drivers/platform/x86/acerhdf.c b/drivers/platform/x86/acerhdf.c
index d40f365d8d7a..8cc86f4e3ac1 100644
--- a/drivers/platform/x86/acerhdf.c
+++ b/drivers/platform/x86/acerhdf.c
@@ -4,7 +4,7 @@
* of the aspire one netbook, turns on/off the fan
* as soon as the upper/lower threshold is reached.
*
- * (C) 2009 - Peter Feuerer peter (a) piie.net
+ * (C) 2009 - Peter Kaestle peter (a) piie.net
* http://piie.net
* 2009 Borislav Petkovbp (a) alien8.de
*
@@ -803,7 +803,7 @@ static void __exit acerhdf_exit(void)
}
MODULE_LICENSE("GPL");
-MODULE_AUTHOR("Peter Feuerer");
+MODULE_AUTHOR("Peter Kaestle");
MODULE_DESCRIPTION("Aspire One temperature and fan driver");
MODULE_ALIAS("dmi:*:*Acer*:pnAOA*:");
MODULE_ALIAS("dmi:*:*Acer*:pnAO751h*:");
diff --git a/drivers/thermal/gov_bang_bang.c b/drivers/thermal/gov_bang_bang.c
index e0575d29023a..b831fc77cf64 100644
--- a/drivers/thermal/gov_bang_bang.c
+++ b/drivers/thermal/gov_bang_bang.c
@@ -2,7 +2,7 @@
/*
* gov_bang_bang.c - A simple thermal throttling governor using hysteresis
*
- * Copyright (C) 2014 Peter Feuerer
+ * Copyright (C) 2014 Peter Kaestle
*
* Based on step_wise.c with following Copyrights:
* Copyright (C) 2012 Intel Corp
--
2.23.0
Re: [PATCH] Bluetooth: hci_qca: Add delay for wcn3990 stability
On Fri, Oct 18, 2019 at 04:36:23PM -0600, Jeffrey Hugo wrote:
> On Fri, Oct 18, 2019 at 3:33 PM Matthias Kaehlcke wrote:
> >
> > On Fri, Oct 18, 2019 at 01:51:39PM -0600, Jeffrey Hugo wrote:
> > > On Fri, Oct 18, 2019 at 1:40 PM Matthias Kaehlcke
> > > wrote:
> > > >
> > > > On Fri, Oct 18, 2019 at 12:30:09PM -0600, Jeffrey Hugo wrote:
> > > > > On Fri, Oct 18, 2019 at 12:03 PM Matthias Kaehlcke
> > > > > wrote:
> > > > > >
> > > > > > On Thu, Oct 17, 2019 at 02:29:55PM -0700, Jeffrey Hugo wrote:
> > > > > > > On the msm8998 mtp, the response to the baudrate change command
> > > > > > > is never
> > > > > > > received. On the Lenovo Miix 630, the response to the baudrate
> > > > > > > change
> > > > > > > command is corrupted - "Frame reassembly failed (-84)".
> > > > > > >
> > > > > > > Adding a 50ms delay before re-enabling flow to receive the
> > > > > > > baudrate change
> > > > > > > command response from the wcn3990 addesses both issues, and allows
> > > > > > > bluetooth to become functional.
> > > > > >
> > > > > > From my earlier debugging on sdm845 I don't think this is what
> > > > > > happens.
> > > > > > The problem is that the wcn3990 sends the response to the baudrate
> > > > > > change
> > > > > > command using the new baudrate, while the UART on the SoC still
> > > > > > operates
> > > > > > with the prior speed (for details see 2faa3f15fa2f ("Bluetooth:
> > > > > > hci_qca:
> > > > > > wcn3990: Drop baudrate change vendor event"))
> > > > > >
> > > > > > IIRC the 50ms delay causes the HCI core to discard the received
> > > > > > data,
> > > > > > which is why the "Frame reassembly failed" message disappears, not
> > > > > > because the response was received. In theory commit 78e8fa2972e5
> > > > > > ("Bluetooth: hci_qca: Deassert RTS while baudrate change command")
> > > > > > should have fixed those messages, do you know if CTS/RTS are
> > > > > > connected
> > > > > > on the Bluetooth UART of the Lenovo Miix 630?
> > > > >
> > > > > I was testing with 5.4-rc1 which contains the indicated RTS fix.
> > > > >
> > > > > Yes, CTS/RTS are connected on the Lenovo Miix 630.
> > > > >
> > > > > I added debug statements which indicated that data was received,
> > > > > however it was corrupt, and the packet type did not match what was
> > > > > expected, hence the frame reassembly errors.
> > > >
> > > > Do you know if any data is received during the delay? In theory that
> > > > shouldn't be the case since RTS is deasserted, just double-checking.
> > >
> > > I don't think so, but I've run so many tests, I'm not 100% positive.
> > > Let me go double check and get back to you.
>
> Apparently I'd be wrong. I instrumented the uart driver so that it
> would indicate when it got data from the bam. Apparently its getting
> the data during the 50ms sleep, approximately right after the host
> baud rate is set.
Good finding!
> > >
> > > >
> > > > What happens if you add a longer delay (e.g. 1s) before/after setting
> > > > the host baudrate?
> > >
> > > Hmm, not exactly sure. I will test.
>
> Adding a 1 second delay before setting the host baud rate did not
> change the observed results - still received the data during the 50ms
> sleep after the host baud rate set operation.
> Adding a 1 second delay after setting the host baud rate did not
> change when the data was received.
Thanks for testing!
> > >
> > > >
> > > > > In response to this patch, Balakrishna pointed me to a bug report
> > > > > which indicated that some of the UART GPIO lines need to have a bias
> > > > > applied to prevent errant data from floating lines -
> > > > >
> > > > > https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/1391888
> > > >
> > > > Yeah, that was another source of frame reassembly errors that we were
> > > > seeing on SDM845.
> > > >
> > > > Balakrishna, please post these kind of replies on-list, so that
> > > > everybody can benefit from possible solutions or contribute to the
> > > > discussion.
> > > >
> > > > > It turns out this fix was never applied to msm8998. Applying the fix
> > > > > does cause the the frame reassembly errors to go away, however then
> > > > > the host SoC never receives the baud rate change response (I increased
> > > > > the timeout from 2faa3f15fa2f ("Bluetooth: hci_qca: wcn3990: Drop
> > > > > baudrate change vendor event") to 5 seconds). As of now, this patch
> > > > > is still required.
> > > >
> > > > Interesting.
> > > >
> > > > FTR, this is the full UART pin configuration for cheza (SDM845):
> > > >
> > > > &qup_uart6_default {
> > > > /* Change pinmux to all 4 pins since CTS and RTS are connected
> > > > */
> > > > pinmux {
> > > > pins = "gpio45", "gpio46",
> > > >"gpio47", "gpio48";
> > > > };
> > > >
> > > > pinconf-cts {
> > > > /*
> > > > * Configure a pull-down on 45 (CTS) to match the pull
> > > > of
> > > >
Re: [dax] 23c84eb783: fio.write_bw_MBps -61.6% regression
On Fri, Oct 18, 2019 at 2:48 AM Jan Kara wrote:
>
> Hello!
>
> On Fri 18-10-19 16:23:54, kernel test robot wrote:
> > FYI, we noticed a -61.6% regression of fio.write_bw_MBps due to commit:
> >
> >
> > commit: 23c84eb7837514e16d79ed6d849b13745e0ce688 ("dax: Fix missed wakeup
> > with PMD faults")
> > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git master
>
> Thanks for report! Please check whether commit 61c30c98ef17 "dax: Fix
> missed wakeup in put_unlocked_entry()" influences the throughput. Because
> without that fix, the identified commit may result in processes sleeping
> unnecessarily long on entry locks.
I've got several reports of v5.3 performance regressions tracking back
to this change. I instrumented the ndctl "dax.sh" unit test to
validate that it is getting huge page faults and it always falls back
to 4K starting with these commits. It looks like the xa_is_internal()
returns true for any DAX_LOCKED entry.
RE:PERSONAL LETTER FROM MRS RASHIA AMIRA
Greetings My name is Barrister Hans Erich. I have a client who is interested to invest in your country, she is a well known politician in her country and deserve a lucrative investment partnership with you outside her country without any delay Please can you manage such investment please Kindly reply for further details. Your full names - Your urgent response will be appreciated Thank you and God bless you. Barrister Hans Erich Yours sincerely, Barrister Hans Erich
Re: [PATCH] random: make try_to_generate_entropy() more robust
On Fri, Oct 18, 2019 at 4:42 PM Jörn Engel wrote: > > Sorry for coming late to the discussion. I generally like the approach > in try_to_generate_entropy(), but I think we can do a little better > still. Would something like this work? Hmm. I'm not convinced that the register set is all that random in general if you have attackers (or - in the absence of an attack - if it hits in the idle loop a lot), but I do like it for this particular use where we have that timeout while doing entropy work. So I think this is potentially a good way to at least improve on the situation when there is no TSC. Which would remove one worry about getrandom() on other platforms than the usual development ones. I'm on a plane at 38,933 ft right now according to the flight tracker, and about to lose internet access again, but I like it and will take another look when I'm on the ground and at a hotel. Linus
Re: [PATCH v2] ftgmac100: Disable HW checksum generation on AST2500
On 10/17/19, 5:33 PM, "Benjamin Herrenschmidt" wrote: On Fri, 2019-10-18 at 00:06 +, Vijay Khemka wrote: > > > This is not a matter of unsupported csum, it is broken hw csum. > > That's why we disable hw checksum. My guess is once we disable > > Hw checksum, it will use sw checksum. So I am just disabling hw > > Checksum. > > I don't understand what you are saying. You reported a problem with > IPV6 checksums generation. The HW doesn't support it. What's "not a > matter of unsupported csum" ? > > Your patch uses a *deprecated* bit to tell the network stack to only do > HW checksum generation on IPV4. > > This bit is deprecated for a reason, again, see skbuff.h. The right > approach, *which the driver already does*, is to tell the stack that we > support HW checksuming using NETIF_F_HW_CSUM, and then, in the transmit > handler, to call skb_checksum_help() to have the SW calculate the > checksum if it's not a supported type. > > My understanding was when we enable NETIF_F_HW_CSUM means network > stack enables HW checksum and doesn't calculate SW checksum. But as per > this supported types HW checksum are used only for IPV4 and not for IPV6 even > though driver enabled NETIF_F_HW_CSUM. For IPV6 it is always a SW generated > checksum, please correct me here. Have you actually read the comments in skbuff.h that I pointed you to ? And the rest of my email for that matter ? Yes, I went through comments in skbuff.h and your comments as well. I knew about this deprecated bit that's why I have disabled NETIF_F_HW_CSUM completely in my V1 patch. Then Florian gave a comment and asked me to disable only IPV6 not IPV4 as it is working for IPV4 and issue with only IPV6. That's why I sent patch V2 accommodating his feedback. I don't have much understanding of IP Stack but I went through code details and you are right and found that it should fallback to SW calculation for IPV6 but it doesn't happen because ftgmac100_hard_start_xmit checks for CHECKSUM_PARTIAL before setting HW checksum and calling ftgmac100_prep_tx_csum function. And in my understanding, this value is set CHECKSUM_PARTIAL in IP stack. I looked up IP stack for IPV6, file net/ipv6/ip6_output.c, function __ip6_append_data: here it sets CHECKSUM_PARTIAL only for UDP packets not for TCP packets. Please look at line number 1880. This could be an issue we are seeing here as why ftgmac100_prep_tx_csum is not getting triggered for IPV6 with TCP. Please correct me if my understanding is wrong. > This is exactly what ftgmac100_prep_tx_csum() does. It only enables HW > checksum generation on supported types and uses skb_checksum_help() > otherwise, supported types being protocol ETH_P_IP and IP protocol > being raw IP, TCP and UDP. > > > So this *should* have fallen back to SW for IPV6. So either something > in my code there is making an incorrect assumption, or something is > broken in skb_checksum_help() for IPV6 (which I somewhat doubt) or > something else I can't think of, but setting a *deprecated* flag is > definitely not the right answer, neither is completely disabling HW > checksumming. > > So can you investigate what's going on a bit more closely please ? I > can try myself, though I have very little experience with IPV6 and > probably won't have time before next week. > > Cheers, > Ben. > > > The driver should have handled unsupported csum via SW fallback > > already in ftgmac100_prep_tx_csum() > > > > Can you check why this didn't work for you ? > > > > Cheers, > > Ben. > > > > > Signed-off-by: Vijay Khemka > > > --- > > > Changes since v1: > > > Enabled IPV4 hw checksum generation as it works for IPV4. > > > > > > drivers/net/ethernet/faraday/ftgmac100.c | 13 - > > > 1 file changed, 12 insertions(+), 1 deletion(-) > > > > > > diff --git a/drivers/net/ethernet/faraday/ftgmac100.c > > > b/drivers/net/ethernet/faraday/ftgmac100.c > > > index 030fed65393e..0255a28d2958 100644 > > > --- a/drivers/net/ethernet/faraday/ftgmac100.c > > > +++ b/drivers/net/ethernet/faraday/ftgmac100.c > > > @@ -1842,8 +1842,19 @@ static int ftgmac100_probe(struct > > > platform_device *pdev) > > > /* AST2400 doesn't have working HW checksum generation */ > > > if (np && (of_device_is_compatible(np, "aspeed,ast2400-mac"))) > > > netdev->hw_features
Re: [GIT PULL] usercopy for v5.4-rc4
The pull request you sent on Fri, 18 Oct 2019 17:33:13 +0200: > g...@gitolite.kernel.org:pub/scm/linux/kernel/git/brauner/linux > tags/copy-struct-from-user-v5.4-rc4 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/8eb4b3b0dd9ae3e5399ff902da87d13740a2b70f Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [GIT PULL] Ceph fixes for 5.4-rc4
The pull request you sent on Fri, 18 Oct 2019 20:15:11 +0200: > https://github.com/ceph/ceph-client.git tags/ceph-for-5.4-rc4 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/6b95cf9b8bb3cb647d9f43109a9c50a234b39781 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
[PATCH 1/2] platform/x86: huawei-wmi: Stricter battery thresholds set
Check if battery thresholds are within 0 and 100. --- drivers/platform/x86/huawei-wmi.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/platform/x86/huawei-wmi.c b/drivers/platform/x86/huawei-wmi.c index 5837d1b8693d..26041d44286a 100644 --- a/drivers/platform/x86/huawei-wmi.c +++ b/drivers/platform/x86/huawei-wmi.c @@ -345,7 +345,7 @@ static int huawei_wmi_battery_set(int start, int end) union hwmi_arg arg; int err; - if (start < 0 || end > 100) + if (start < 0 || end < 0 || start > 100 || end > 100) return -EINVAL; arg.cmd = BATTERY_THRESH_SET; base-commit: fd13c8622a5ad4f7317b64de4f6aa2de1962220e -- 2.21.0
[PATCH 2/2] platform/x86: huawei-wmi: No need to check for battery name
No need to check for battery name, we already check if the WMI function is
available in huawei_wmi_battery_setup.
---
drivers/platform/x86/huawei-wmi.c | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/platform/x86/huawei-wmi.c
b/drivers/platform/x86/huawei-wmi.c
index 26041d44286a..7373a65a61d3 100644
--- a/drivers/platform/x86/huawei-wmi.c
+++ b/drivers/platform/x86/huawei-wmi.c
@@ -471,10 +471,6 @@ static DEVICE_ATTR_RW(charge_control_thresholds);
static int huawei_wmi_battery_add(struct power_supply *battery)
{
- /* Huawei laptops come with one battery only */
- if (strcmp(battery->desc->name, "BAT") != 1)
- return -ENODEV;
-
device_create_file(&battery->dev,
&dev_attr_charge_control_start_threshold);
device_create_file(&battery->dev,
&dev_attr_charge_control_end_threshold);
--
2.21.0
Re: [PATCH -next] Bluetooth: btusb: Remove return statement in btintel_reset_to_bootloader
On Fri, Oct 18, 2019 at 3:29 PM Nathan Chancellor
wrote:
>
> When building with Clang and CONFIG_BT_INTEL unset, the following error
> occurs:
>
> In file included from drivers/bluetooth/hci_ldisc.c:34:
> drivers/bluetooth/btintel.h:188:2: error: void function
> 'btintel_reset_to_bootloader' should not return a value [-Wreturn-type]
> return -EOPNOTSUPP;
> ^ ~~~
> 1 error generated.
>
> Remove the unneeded return statement to fix this.
>
> Fixes: b9a2562f4918 ("Bluetooth: btusb: Trigger Intel FW download error
> recovery")
> Link: https://github.com/ClangBuiltLinux/linux/issues/743
> Reported-by:
> Reported-by: Stephen Rothwell
> Signed-off-by: Nathan Chancellor
> ---
> drivers/bluetooth/btintel.h | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/bluetooth/btintel.h b/drivers/bluetooth/btintel.h
> index d2311156f778..a69ea8a87b9b 100644
> --- a/drivers/bluetooth/btintel.h
> +++ b/drivers/bluetooth/btintel.h
> @@ -185,6 +185,5 @@ static inline int btintel_download_firmware(struct
> hci_dev *dev,
>
> static inline void btintel_reset_to_bootloader(struct hci_dev *hdev)
> {
> - return -EOPNOTSUPP;
The existing structure of this code is fishy, but I see what is going on with:
65 #if IS_ENABLED(CONFIG_BT_INTEL)
drivers/bluetooth/btintel.h
Thanks for the patch
Reviewed-by: Nick Desaulniers
> }
> #endif
--
Thanks,
~Nick Desaulniers
[PATCH] MIPS: tlbex: Fix build_restore_pagemask KScratch restore
build_restore_pagemask() will restore the value of register $1/$at when
its restore_scratch argument is non-zero, and aims to do so by filling a
branch delay slot. Commit 0b24cae4d535 ("MIPS: Add missing EHB in mtc0
-> mfc0 sequence.") added an EHB instruction (Execution Hazard Barrier)
prior to restoring $1 from a KScratch register, in order to resolve a
hazard that can result in stale values of the KScratch register being
observed. In particular, P-class CPUs from MIPS with out of order
execution pipelines such as the P5600 & P6600 are affected.
Unfortunately this EHB instruction was inserted in the branch delay slot
causing the MFC0 instruction which performs the restoration to no longer
execute along with the branch. The result is that the $1 register isn't
actually restored, ie. the TLB refill exception handler clobbers it -
which is exactly the problem the EHB is meant to avoid for the P-class
CPUs.
Similarly build_get_pgd_vmalloc() will restore the value of $1/$at when
its mode argument equals refill_scratch, and suffers from the same
problem.
Fix this by in both cases moving the EHB earlier in the emitted code.
There's no reason it needs to immediately precede the MFC0 - it simply
needs to be between the MTC0 & MFC0.
This bug only affects Cavium Octeon systems which use
build_fast_tlb_refill_handler().
Signed-off-by: Paul Burton
Fixes: 0b24cae4d535 ("MIPS: Add missing EHB in mtc0 -> mfc0 sequence.")
Cc: Dmitry Korotin
Cc: sta...@vger.kernel.org # v3.15+
---
arch/mips/mm/tlbex.c | 23 +++
1 file changed, 15 insertions(+), 8 deletions(-)
diff --git a/arch/mips/mm/tlbex.c b/arch/mips/mm/tlbex.c
index e01cb33bfa1a..41bb91f05688 100644
--- a/arch/mips/mm/tlbex.c
+++ b/arch/mips/mm/tlbex.c
@@ -653,6 +653,13 @@ static void build_restore_pagemask(u32 **p, struct
uasm_reloc **r,
int restore_scratch)
{
if (restore_scratch) {
+ /*
+* Ensure the MFC0 below observes the value written to the
+* KScratch register by the prior MTC0.
+*/
+ if (scratch_reg >= 0)
+ uasm_i_ehb(p);
+
/* Reset default page size */
if (PM_DEFAULT_MASK >> 16) {
uasm_i_lui(p, tmp, PM_DEFAULT_MASK >> 16);
@@ -667,12 +674,10 @@ static void build_restore_pagemask(u32 **p, struct
uasm_reloc **r,
uasm_i_mtc0(p, 0, C0_PAGEMASK);
uasm_il_b(p, r, lid);
}
- if (scratch_reg >= 0) {
- uasm_i_ehb(p);
+ if (scratch_reg >= 0)
UASM_i_MFC0(p, 1, c0_kscratch(), scratch_reg);
- } else {
+ else
UASM_i_LW(p, 1, scratchpad_offset(0), 0);
- }
} else {
/* Reset default page size */
if (PM_DEFAULT_MASK >> 16) {
@@ -921,6 +926,10 @@ build_get_pgd_vmalloc64(u32 **p, struct uasm_label **l,
struct uasm_reloc **r,
}
if (mode != not_refill && check_for_high_segbits) {
uasm_l_large_segbits_fault(l, *p);
+
+ if (mode == refill_scratch && scratch_reg >= 0)
+ uasm_i_ehb(p);
+
/*
* We get here if we are an xsseg address, or if we are
* an xuseg address above (PGDIR_SHIFT+PGDIR_BITS) boundary.
@@ -939,12 +948,10 @@ build_get_pgd_vmalloc64(u32 **p, struct uasm_label **l,
struct uasm_reloc **r,
uasm_i_jr(p, ptr);
if (mode == refill_scratch) {
- if (scratch_reg >= 0) {
- uasm_i_ehb(p);
+ if (scratch_reg >= 0)
UASM_i_MFC0(p, 1, c0_kscratch(), scratch_reg);
- } else {
+ else
UASM_i_LW(p, 1, scratchpad_offset(0), 0);
- }
} else {
uasm_i_nop(p);
}
--
2.23.0
Re: [PATCH] Bluetooth: hci_qca: Add delay for wcn3990 stability
On Fri, Oct 18, 2019 at 3:33 PM Matthias Kaehlcke wrote:
>
> On Fri, Oct 18, 2019 at 01:51:39PM -0600, Jeffrey Hugo wrote:
> > On Fri, Oct 18, 2019 at 1:40 PM Matthias Kaehlcke wrote:
> > >
> > > On Fri, Oct 18, 2019 at 12:30:09PM -0600, Jeffrey Hugo wrote:
> > > > On Fri, Oct 18, 2019 at 12:03 PM Matthias Kaehlcke
> > > > wrote:
> > > > >
> > > > > On Thu, Oct 17, 2019 at 02:29:55PM -0700, Jeffrey Hugo wrote:
> > > > > > On the msm8998 mtp, the response to the baudrate change command is
> > > > > > never
> > > > > > received. On the Lenovo Miix 630, the response to the baudrate
> > > > > > change
> > > > > > command is corrupted - "Frame reassembly failed (-84)".
> > > > > >
> > > > > > Adding a 50ms delay before re-enabling flow to receive the baudrate
> > > > > > change
> > > > > > command response from the wcn3990 addesses both issues, and allows
> > > > > > bluetooth to become functional.
> > > > >
> > > > > From my earlier debugging on sdm845 I don't think this is what
> > > > > happens.
> > > > > The problem is that the wcn3990 sends the response to the baudrate
> > > > > change
> > > > > command using the new baudrate, while the UART on the SoC still
> > > > > operates
> > > > > with the prior speed (for details see 2faa3f15fa2f ("Bluetooth:
> > > > > hci_qca:
> > > > > wcn3990: Drop baudrate change vendor event"))
> > > > >
> > > > > IIRC the 50ms delay causes the HCI core to discard the received data,
> > > > > which is why the "Frame reassembly failed" message disappears, not
> > > > > because the response was received. In theory commit 78e8fa2972e5
> > > > > ("Bluetooth: hci_qca: Deassert RTS while baudrate change command")
> > > > > should have fixed those messages, do you know if CTS/RTS are connected
> > > > > on the Bluetooth UART of the Lenovo Miix 630?
> > > >
> > > > I was testing with 5.4-rc1 which contains the indicated RTS fix.
> > > >
> > > > Yes, CTS/RTS are connected on the Lenovo Miix 630.
> > > >
> > > > I added debug statements which indicated that data was received,
> > > > however it was corrupt, and the packet type did not match what was
> > > > expected, hence the frame reassembly errors.
> > >
> > > Do you know if any data is received during the delay? In theory that
> > > shouldn't be the case since RTS is deasserted, just double-checking.
> >
> > I don't think so, but I've run so many tests, I'm not 100% positive.
> > Let me go double check and get back to you.
Apparently I'd be wrong. I instrumented the uart driver so that it
would indicate when it got data from the bam. Apparently its getting
the data during the 50ms sleep, approximately right after the host
baud rate is set.
> >
> > >
> > > What happens if you add a longer delay (e.g. 1s) before/after setting
> > > the host baudrate?
> >
> > Hmm, not exactly sure. I will test.
Adding a 1 second delay before setting the host baud rate did not
change the observed results - still received the data during the 50ms
sleep after the host baud rate set operation.
Adding a 1 second delay after setting the host baud rate did not
change when the data was received.
> >
> > >
> > > > In response to this patch, Balakrishna pointed me to a bug report
> > > > which indicated that some of the UART GPIO lines need to have a bias
> > > > applied to prevent errant data from floating lines -
> > > >
> > > > https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/1391888
> > >
> > > Yeah, that was another source of frame reassembly errors that we were
> > > seeing on SDM845.
> > >
> > > Balakrishna, please post these kind of replies on-list, so that
> > > everybody can benefit from possible solutions or contribute to the
> > > discussion.
> > >
> > > > It turns out this fix was never applied to msm8998. Applying the fix
> > > > does cause the the frame reassembly errors to go away, however then
> > > > the host SoC never receives the baud rate change response (I increased
> > > > the timeout from 2faa3f15fa2f ("Bluetooth: hci_qca: wcn3990: Drop
> > > > baudrate change vendor event") to 5 seconds). As of now, this patch
> > > > is still required.
> > >
> > > Interesting.
> > >
> > > FTR, this is the full UART pin configuration for cheza (SDM845):
> > >
> > > &qup_uart6_default {
> > > /* Change pinmux to all 4 pins since CTS and RTS are connected */
> > > pinmux {
> > > pins = "gpio45", "gpio46",
> > >"gpio47", "gpio48";
> > > };
> > >
> > > pinconf-cts {
> > > /*
> > > * Configure a pull-down on 45 (CTS) to match the pull of
> > > * the Bluetooth module.
> > > */
> > > pins = "gpio45";
> > > bias-pull-down;
> > > };
> > >
> > > pinconf-rts-tx {
> > > /* We'll drive 46 (RTS) and 47 (TX), so no pull */
> > > pins = "gpio46", "gpio47";
> > > drive-strength = <2>;
> > >
[PATCH -next] Bluetooth: btusb: Remove return statement in btintel_reset_to_bootloader
When building with Clang and CONFIG_BT_INTEL unset, the following error
occurs:
In file included from drivers/bluetooth/hci_ldisc.c:34:
drivers/bluetooth/btintel.h:188:2: error: void function
'btintel_reset_to_bootloader' should not return a value [-Wreturn-type]
return -EOPNOTSUPP;
^ ~~~
1 error generated.
Remove the unneeded return statement to fix this.
Fixes: b9a2562f4918 ("Bluetooth: btusb: Trigger Intel FW download error
recovery")
Link: https://github.com/ClangBuiltLinux/linux/issues/743
Reported-by:
Reported-by: Stephen Rothwell
Signed-off-by: Nathan Chancellor
---
drivers/bluetooth/btintel.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/bluetooth/btintel.h b/drivers/bluetooth/btintel.h
index d2311156f778..a69ea8a87b9b 100644
--- a/drivers/bluetooth/btintel.h
+++ b/drivers/bluetooth/btintel.h
@@ -185,6 +185,5 @@ static inline int btintel_download_firmware(struct hci_dev
*dev,
static inline void btintel_reset_to_bootloader(struct hci_dev *hdev)
{
- return -EOPNOTSUPP;
}
#endif
--
2.23.0
[PATCH AUTOSEL 5.3 07/89] perf jevents: Fix period for Intel fixed counters
From: Andi Kleen
[ Upstream commit 6bdfd9f118bd59cf0f85d3bf4b72b586adea17c1 ]
The Intel fixed counters use a special table to override the JSON
information.
During this override the period information from the JSON file got
dropped, which results in inst_retired.any and similar running with
frequency mode instead of a period.
Just specify the expected period in the table.
Signed-off-by: Andi Kleen
Cc: Jiri Olsa
Link: http://lore.kernel.org/lkml/20190927233546.11533-2-a...@firstfloor.org
Signed-off-by: Arnaldo Carvalho de Melo
Signed-off-by: Sasha Levin
---
tools/perf/pmu-events/jevents.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/tools/perf/pmu-events/jevents.c b/tools/perf/pmu-events/jevents.c
index d413761621b09..fa85e33762f72 100644
--- a/tools/perf/pmu-events/jevents.c
+++ b/tools/perf/pmu-events/jevents.c
@@ -449,12 +449,12 @@ static struct fixed {
const char *name;
const char *event;
} fixed[] = {
- { "inst_retired.any", "event=0xc0" },
- { "inst_retired.any_p", "event=0xc0" },
- { "cpu_clk_unhalted.ref", "event=0x0,umask=0x03" },
- { "cpu_clk_unhalted.thread", "event=0x3c" },
- { "cpu_clk_unhalted.core", "event=0x3c" },
- { "cpu_clk_unhalted.thread_any", "event=0x3c,any=1" },
+ { "inst_retired.any", "event=0xc0,period=203" },
+ { "inst_retired.any_p", "event=0xc0,period=203" },
+ { "cpu_clk_unhalted.ref", "event=0x0,umask=0x03,period=203" },
+ { "cpu_clk_unhalted.thread", "event=0x3c,period=203" },
+ { "cpu_clk_unhalted.core", "event=0x3c,period=203" },
+ { "cpu_clk_unhalted.thread_any", "event=0x3c,any=1,period=203" },
{ NULL, NULL},
};
--
2.20.1
[PATCH AUTOSEL 5.3 04/89] perf tests: Avoid raising SEGV using an obvious NULL dereference
From: Ian Rogers
[ Upstream commit e3e2cf3d5b1fe800b032e14c0fdcd9a6fb20cf3b ]
An optimized build such as:
make -C tools/perf CLANG=1 CC=clang EXTRA_CFLAGS="-O3
will turn the dereference operation into a ud2 instruction, raising a
SIGILL rather than a SIGSEGV. Use raise(..) for correctness and clarity.
Similar issues were addressed in Numfor Mbiziwo-Tiapo's patch:
https://lkml.org/lkml/2019/7/8/1234
Committer testing:
Before:
[root@quaco ~]# perf test hooks
55: perf hooks: Ok
[root@quaco ~]# perf test -v hooks
55: perf hooks:
--- start ---
test child forked, pid 17092
SIGSEGV is observed as expected, try to recover.
Fatal error (SEGFAULT) in perf hook 'test'
test child finished with 0
end
perf hooks: Ok
[root@quaco ~]#
After:
[root@quaco ~]# perf test hooks
55: perf hooks: Ok
[root@quaco ~]# perf test -v hooks
55: perf hooks:
--- start ---
test child forked, pid 17909
SIGSEGV is observed as expected, try to recover.
Fatal error (SEGFAULT) in perf hook 'test'
test child finished with 0
end
perf hooks: Ok
[root@quaco ~]#
Fixes: a074865e60ed ("perf tools: Introduce perf hooks")
Signed-off-by: Ian Rogers
Tested-by: Arnaldo Carvalho de Melo
Cc: Alexander Shishkin
Cc: Andi Kleen
Cc: Jiri Olsa
Cc: Namhyung Kim
Cc: Peter Zijlstra
Cc: Stephane Eranian
Cc: Wang Nan
Link: http://lore.kernel.org/lkml/20190925195924.152834-2-irog...@google.com
Signed-off-by: Arnaldo Carvalho de Melo
Signed-off-by: Sasha Levin
---
tools/perf/tests/perf-hooks.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/tools/perf/tests/perf-hooks.c b/tools/perf/tests/perf-hooks.c
index a693bcf017ea2..44c16fd11bf6e 100644
--- a/tools/perf/tests/perf-hooks.c
+++ b/tools/perf/tests/perf-hooks.c
@@ -20,12 +20,11 @@ static void sigsegv_handler(int sig __maybe_unused)
static void the_hook(void *_hook_flags)
{
int *hook_flags = _hook_flags;
- int *p = NULL;
*hook_flags = 1234;
/* Generate a segfault, test perf_hooks__recover */
- *p = 0;
+ raise(SIGSEGV);
}
int test__perf_hooks(struct test *test __maybe_unused, int subtest
__maybe_unused)
--
2.20.1
[PATCH AUTOSEL 5.3 05/89] perf map: Fix overlapped map handling
From: Steve MacLean [ Upstream commit ee212d6ea20887c0ef352be8563ca13dbf965906 ] Whenever an mmap/mmap2 event occurs, the map tree must be updated to add a new entry. If a new map overlaps a previous map, the overlapped section of the previous map is effectively unmapped, but the non-overlapping sections are still valid. maps__fixup_overlappings() is responsible for creating any new map entries from the previously overlapped map. It optionally creates a before and an after map. When creating the after map the existing code failed to adjust the map.pgoff. This meant the new after map would incorrectly calculate the file offset for the ip. This results in incorrect symbol name resolution for any ip in the after region. Make maps__fixup_overlappings() correctly populate map.pgoff. Add an assert that new mapping matches old mapping at the beginning of the after map. Committer-testing: Validated correct parsing of libcoreclr.so symbols from .NET Core 3.0 preview9 (which didn't strip symbols). Preparation: ~/dotnet3.0-preview9/dotnet new webapi -o perfSymbol cd perfSymbol ~/dotnet3.0-preview9/dotnet publish perf record ~/dotnet3.0-preview9/dotnet \ bin/Debug/netcoreapp3.0/publish/perfSymbol.dll ^C Before: perf script --show-mmap-events 2>&1 | grep -e MMAP -e unknown |\ grep libcoreclr.so | head -n 4 dotnet 1907 373352.698780: PERF_RECORD_MMAP2 1907/1907: \ [0x7fe615726000(0x768000) @ 0 08:02 5510620 765057155]: \ r-xp .../3.0.0-preview9-19423-09/libcoreclr.so dotnet 1907 373352.701091: PERF_RECORD_MMAP2 1907/1907: \ [0x7fe615974000(0x1000) @ 0x24e000 08:02 5510620 765057155]: \ rwxp .../3.0.0-preview9-19423-09/libcoreclr.so dotnet 1907 373352.701241: PERF_RECORD_MMAP2 1907/1907: \ [0x7fe615c42000(0x1000) @ 0x51c000 08:02 5510620 765057155]: \ rwxp .../3.0.0-preview9-19423-09/libcoreclr.so dotnet 1907 373352.705249: 25 cpu-clock: \ 7fe6159a1f99 [unknown] \ (.../3.0.0-preview9-19423-09/libcoreclr.so) After: perf script --show-mmap-events 2>&1 | grep -e MMAP -e unknown |\ grep libcoreclr.so | head -n 4 dotnet 1907 373352.698780: PERF_RECORD_MMAP2 1907/1907: \ [0x7fe615726000(0x768000) @ 0 08:02 5510620 765057155]: \ r-xp .../3.0.0-preview9-19423-09/libcoreclr.so dotnet 1907 373352.701091: PERF_RECORD_MMAP2 1907/1907: \ [0x7fe615974000(0x1000) @ 0x24e000 08:02 5510620 765057155]: \ rwxp .../3.0.0-preview9-19423-09/libcoreclr.so dotnet 1907 373352.701241: PERF_RECORD_MMAP2 1907/1907: \ [0x7fe615c42000(0x1000) @ 0x51c000 08:02 5510620 765057155]: \ rwxp .../3.0.0-preview9-19423-09/libcoreclr.so All the [unknown] symbols were resolved. Signed-off-by: Steve MacLean Tested-by: Brian Robbins Acked-by: Jiri Olsa Cc: Alexander Shishkin Cc: Andi Kleen Cc: Davidlohr Bueso Cc: Eric Saint-Etienne Cc: John Keeping Cc: John Salem Cc: Leo Yan Cc: Mark Rutland Cc: Namhyung Kim Cc: Peter Zijlstra Cc: Song Liu Cc: Stephane Eranian Cc: Tom McDonald Link: http://lore.kernel.org/lkml/bn8pr21mb136270949f22a6a02335c238f7...@bn8pr21mb1362.namprd21.prod.outlook.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin --- tools/perf/util/map.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/tools/perf/util/map.c b/tools/perf/util/map.c index 7666206d06fa7..f18113581cf03 100644 --- a/tools/perf/util/map.c +++ b/tools/perf/util/map.c @@ -1,5 +1,6 @@ // SPDX-License-Identifier: GPL-2.0 #include "symbol.h" +#include #include #include #include @@ -847,6 +848,8 @@ static int maps__fixup_overlappings(struct maps *maps, struct map *map, FILE *fp } after->start = map->end; + after->pgoff += map->end - pos->start; + assert(pos->map_ip(pos, map->end) == after->map_ip(after, map->end)); __map_groups__insert(pos->groups, after); if (verbose >= 2 && !use_browser) map__fprintf(after, fp); -- 2.20.1
[PATCH AUTOSEL 5.3 03/89] libsubcmd: Make _FORTIFY_SOURCE defines dependent on the feature
From: Ian Rogers
[ Upstream commit 4b0b2b096da9d296e0e5668cdfba8613bd6f5bc8 ]
Unconditionally defining _FORTIFY_SOURCE can break tools that don't work
with it, such as memory sanitizers:
https://github.com/google/sanitizers/wiki/AddressSanitizer#faq
Fixes: 4b6ab94eabe4 ("perf subcmd: Create subcmd library")
Signed-off-by: Ian Rogers
Cc: Alexander Shishkin
Cc: Andi Kleen
Cc: Jiri Olsa
Cc: Josh Poimboeuf
Cc: Namhyung Kim
Cc: Peter Zijlstra
Cc: Stephane Eranian
Link: http://lore.kernel.org/lkml/20190925195924.152834-1-irog...@google.com
Signed-off-by: Arnaldo Carvalho de Melo
Signed-off-by: Sasha Levin
---
tools/lib/subcmd/Makefile | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/tools/lib/subcmd/Makefile b/tools/lib/subcmd/Makefile
index ed61fb3a46c08..5b2cd5e58df09 100644
--- a/tools/lib/subcmd/Makefile
+++ b/tools/lib/subcmd/Makefile
@@ -20,7 +20,13 @@ MAKEFLAGS += --no-print-directory
LIBFILE = $(OUTPUT)libsubcmd.a
CFLAGS := $(EXTRA_WARNINGS) $(EXTRA_CFLAGS)
-CFLAGS += -ggdb3 -Wall -Wextra -std=gnu99 -U_FORTIFY_SOURCE
-D_FORTIFY_SOURCE=2 -fPIC
+CFLAGS += -ggdb3 -Wall -Wextra -std=gnu99 -fPIC
+
+ifeq ($(DEBUG),0)
+ ifeq ($(feature-fortify-source), 1)
+CFLAGS += -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2
+ endif
+endif
ifeq ($(CC_NO_CLANG), 0)
CFLAGS += -O3
--
2.20.1
[PATCH AUTOSEL 5.3 08/89] perf tools: Propagate get_cpuid() error
From: Arnaldo Carvalho de Melo
[ Upstream commit f67001a4a08eb124197ed4376941e1da9cf94b42 ]
For consistency, propagate the exact cause for get_cpuid() to have
failed.
Cc: Adrian Hunter
Cc: Jiri Olsa
Cc: Namhyung Kim
Link: https://lkml.kernel.org/n/tip-9ig269f7ktnhh99g4l15v...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo
Signed-off-by: Sasha Levin
---
tools/perf/arch/powerpc/util/header.c | 3 ++-
tools/perf/arch/s390/util/header.c| 9 +
tools/perf/arch/x86/util/header.c | 3 ++-
tools/perf/builtin-kvm.c | 7 ---
4 files changed, 13 insertions(+), 9 deletions(-)
diff --git a/tools/perf/arch/powerpc/util/header.c
b/tools/perf/arch/powerpc/util/header.c
index 0b242664f5ea7..e46be9ef5a688 100644
--- a/tools/perf/arch/powerpc/util/header.c
+++ b/tools/perf/arch/powerpc/util/header.c
@@ -1,5 +1,6 @@
// SPDX-License-Identifier: GPL-2.0
#include
+#include
#include
#include
#include
@@ -31,7 +32,7 @@ get_cpuid(char *buffer, size_t sz)
buffer[nb-1] = '\0';
return 0;
}
- return -1;
+ return ENOBUFS;
}
char *
diff --git a/tools/perf/arch/s390/util/header.c
b/tools/perf/arch/s390/util/header.c
index 8b0b018d896ab..7933f6871c818 100644
--- a/tools/perf/arch/s390/util/header.c
+++ b/tools/perf/arch/s390/util/header.c
@@ -8,6 +8,7 @@
*/
#include
+#include
#include
#include
#include
@@ -54,7 +55,7 @@ int get_cpuid(char *buffer, size_t sz)
sysinfo = fopen(SYSINFO, "r");
if (sysinfo == NULL)
- return -1;
+ return errno;
while ((read = getline(&line, &line_sz, sysinfo)) != -1) {
if (!strncmp(line, SYSINFO_MANU, strlen(SYSINFO_MANU))) {
@@ -89,7 +90,7 @@ int get_cpuid(char *buffer, size_t sz)
/* Missing manufacturer, type or model information should not happen */
if (!manufacturer[0] || !type[0] || !model[0])
- return -1;
+ return EINVAL;
/*
* Scan /proc/service_levels and return the CPU-MF counter facility
@@ -133,14 +134,14 @@ int get_cpuid(char *buffer, size_t sz)
else
nbytes = snprintf(buffer, sz, "%s,%s,%s", manufacturer, type,
model);
- return (nbytes >= sz) ? -1 : 0;
+ return (nbytes >= sz) ? ENOBUFS : 0;
}
char *get_cpuid_str(struct perf_pmu *pmu __maybe_unused)
{
char *buf = malloc(128);
- if (buf && get_cpuid(buf, 128) < 0)
+ if (buf && get_cpuid(buf, 128))
zfree(&buf);
return buf;
}
diff --git a/tools/perf/arch/x86/util/header.c
b/tools/perf/arch/x86/util/header.c
index af9a9f2600be4..a089af60906a0 100644
--- a/tools/perf/arch/x86/util/header.c
+++ b/tools/perf/arch/x86/util/header.c
@@ -1,5 +1,6 @@
// SPDX-License-Identifier: GPL-2.0
#include
+#include
#include
#include
#include
@@ -57,7 +58,7 @@ __get_cpuid(char *buffer, size_t sz, const char *fmt)
buffer[nb-1] = '\0';
return 0;
}
- return -1;
+ return ENOBUFS;
}
int
diff --git a/tools/perf/builtin-kvm.c b/tools/perf/builtin-kvm.c
index b33c834891208..44ff3ea1da23f 100644
--- a/tools/perf/builtin-kvm.c
+++ b/tools/perf/builtin-kvm.c
@@ -699,14 +699,15 @@ static int process_sample_event(struct perf_tool *tool,
static int cpu_isa_config(struct perf_kvm_stat *kvm)
{
- char buf[64], *cpuid;
+ char buf[128], *cpuid;
int err;
if (kvm->live) {
err = get_cpuid(buf, sizeof(buf));
if (err != 0) {
- pr_err("Failed to look up CPU type\n");
- return err;
+ pr_err("Failed to look up CPU type: %s\n",
+ str_error_r(err, buf, sizeof(buf)));
+ return -err;
}
cpuid = buf;
} else
--
2.20.1
[PATCH AUTOSEL 5.3 15/89] staging: rtl8188eu: fix null dereference when kzalloc fails
From: Connor Kuehl
[ Upstream commit 955c1532a34305f2f780b47f0c40cc7c65500810 ]
If kzalloc() returns NULL, the error path doesn't stop the flow of
control from entering rtw_hal_read_chip_version() which dereferences the
null pointer. Fix this by adding a 'goto' to the error path to more
gracefully handle the issue and avoid proceeding with initialization
steps that we're no longer prepared to handle.
Also update the debug message to be more consistent with the other debug
messages in this function.
Addresses-Coverity: ("Dereference after null check")
Signed-off-by: Connor Kuehl
Link: https://lore.kernel.org/r/20190927214415.899-1-connor.ku...@canonical.com
Signed-off-by: Greg Kroah-Hartman
Signed-off-by: Sasha Levin
---
drivers/staging/rtl8188eu/os_dep/usb_intf.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/rtl8188eu/os_dep/usb_intf.c
b/drivers/staging/rtl8188eu/os_dep/usb_intf.c
index 664d93a7f90df..4fac9dca798e8 100644
--- a/drivers/staging/rtl8188eu/os_dep/usb_intf.c
+++ b/drivers/staging/rtl8188eu/os_dep/usb_intf.c
@@ -348,8 +348,10 @@ static struct adapter *rtw_usb_if1_init(struct dvobj_priv
*dvobj,
}
padapter->HalData = kzalloc(sizeof(struct hal_data_8188e), GFP_KERNEL);
- if (!padapter->HalData)
- DBG_88E("cant not alloc memory for HAL DATA\n");
+ if (!padapter->HalData) {
+ DBG_88E("Failed to allocate memory for HAL data\n");
+ goto free_adapter;
+ }
/* step read_chip_version */
rtw_hal_read_chip_version(padapter);
--
2.20.1
[PATCH AUTOSEL 5.3 14/89] perf annotate: Don't return -1 for error when doing BPF disassembly
From: Arnaldo Carvalho de Melo
[ Upstream commit 11aad897f6d1a28eae3b7e5b293647c522d65819 ]
Return errno when open_memstream() fails and add two new speciall error
codes for when an invalid, non BPF file or one without BTF is passed to
symbol__disassemble_bpf(), so that its callers can rely on
symbol__strerror_disassemble() to convert that to a human readable error
message that can help figure out what is wrong, with hints even.
Cc: Russell King - ARM Linux admin
Cc: Song Liu
Cc: Alexei Starovoitov
Cc: Daniel Borkmann
Cc: Adrian Hunter
Cc: Alexander Shishkin
Cc: Jiri Olsa
Cc: Namhyung Kim
Cc: Peter Zijlstra ,
Cc: Will Deacon
Link: https://lkml.kernel.org/n/tip-usevw9r2gcipfcrbpaueu...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo
Signed-off-by: Sasha Levin
---
tools/perf/util/annotate.c | 19 +++
tools/perf/util/annotate.h | 2 ++
2 files changed, 17 insertions(+), 4 deletions(-)
diff --git a/tools/perf/util/annotate.c b/tools/perf/util/annotate.c
index ab7851ec0ce53..fb8756026a805 100644
--- a/tools/perf/util/annotate.c
+++ b/tools/perf/util/annotate.c
@@ -1631,6 +1631,13 @@ int symbol__strerror_disassemble(struct symbol *sym
__maybe_unused, struct map *
case SYMBOL_ANNOTATE_ERRNO__ARCH_INIT_CPUID_PARSING:
scnprintf(buf, buflen, "Problems while parsing the CPUID in the
arch specific initialization.");
break;
+ case SYMBOL_ANNOTATE_ERRNO__BPF_INVALID_FILE:
+ scnprintf(buf, buflen, "Invalid BPF file: %s.", dso->long_name);
+ break;
+ case SYMBOL_ANNOTATE_ERRNO__BPF_MISSING_BTF:
+ scnprintf(buf, buflen, "The %s BPF file has no BTF section,
compile with -g or use pahole -J.",
+ dso->long_name);
+ break;
default:
scnprintf(buf, buflen, "Internal error: Invalid %d error
code\n", errnum);
break;
@@ -1713,13 +1720,13 @@ static int symbol__disassemble_bpf(struct symbol *sym,
char tpath[PATH_MAX];
size_t buf_size;
int nr_skip = 0;
- int ret = -1;
char *buf;
bfd *bfdf;
+ int ret;
FILE *s;
if (dso->binary_type != DSO_BINARY_TYPE__BPF_PROG_INFO)
- return -1;
+ return SYMBOL_ANNOTATE_ERRNO__BPF_INVALID_FILE;
pr_debug("%s: handling sym %s addr %" PRIx64 " len %" PRIx64 "\n",
__func__,
sym->name, sym->start, sym->end - sym->start);
@@ -1732,8 +1739,10 @@ static int symbol__disassemble_bpf(struct symbol *sym,
assert(bfd_check_format(bfdf, bfd_object));
s = open_memstream(&buf, &buf_size);
- if (!s)
+ if (!s) {
+ ret = errno;
goto out;
+ }
init_disassemble_info(&info, s,
(fprintf_ftype) fprintf);
@@ -1742,8 +1751,10 @@ static int symbol__disassemble_bpf(struct symbol *sym,
info_node = perf_env__find_bpf_prog_info(dso->bpf_prog.env,
dso->bpf_prog.id);
- if (!info_node)
+ if (!info_node) {
+ return SYMBOL_ANNOTATE_ERRNO__BPF_MISSING_BTF;
goto out;
+ }
info_linear = info_node->info_linear;
sub_id = dso->bpf_prog.sub_id;
diff --git a/tools/perf/util/annotate.h b/tools/perf/util/annotate.h
index a1191995fe77e..2004e2cf0211b 100644
--- a/tools/perf/util/annotate.h
+++ b/tools/perf/util/annotate.h
@@ -372,6 +372,8 @@ enum symbol_disassemble_errno {
SYMBOL_ANNOTATE_ERRNO__NO_LIBOPCODES_FOR_BPF,
SYMBOL_ANNOTATE_ERRNO__ARCH_INIT_CPUID_PARSING,
SYMBOL_ANNOTATE_ERRNO__ARCH_INIT_REGEXP,
+ SYMBOL_ANNOTATE_ERRNO__BPF_INVALID_FILE,
+ SYMBOL_ANNOTATE_ERRNO__BPF_MISSING_BTF,
__SYMBOL_ANNOTATE_ERRNO__END,
};
--
2.20.1
[PATCH AUTOSEL 5.3 20/89] RDMA/iwcm: Fix a lock inversion issue
From: Bart Van Assche
[ Upstream commit b66f31efbdad95ec274345721d99d1d835e6de01 ]
This patch fixes the lock inversion complaint:
WARNING: possible recursive locking detected
5.3.0-rc7-dbg+ #1 Not tainted
kworker/u16:6/171 is trying to acquire lock:
035c6e6c (&id_priv->handler_mutex){+.+.}, at:
rdma_destroy_id+0x78/0x4a0 [rdma_cm]
but task is already holding lock:
bc7c307d (&id_priv->handler_mutex){+.+.}, at:
iw_conn_req_handler+0x151/0x680 [rdma_cm]
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0
lock(&id_priv->handler_mutex);
lock(&id_priv->handler_mutex);
*** DEADLOCK ***
May be due to missing lock nesting notation
3 locks held by kworker/u16:6/171:
#0: e2eaa773 ((wq_completion)iw_cm_wq){+.+.}, at:
process_one_work+0x472/0xac0
#1: 1efd357b ((work_completion)(&work->work)#3){+.+.}, at:
process_one_work+0x476/0xac0
#2: bc7c307d (&id_priv->handler_mutex){+.+.}, at:
iw_conn_req_handler+0x151/0x680 [rdma_cm]
stack backtrace:
CPU: 3 PID: 171 Comm: kworker/u16:6 Not tainted 5.3.0-rc7-dbg+ #1
Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
Workqueue: iw_cm_wq cm_work_handler [iw_cm]
Call Trace:
dump_stack+0x8a/0xd6
__lock_acquire.cold+0xe1/0x24d
lock_acquire+0x106/0x240
__mutex_lock+0x12e/0xcb0
mutex_lock_nested+0x1f/0x30
rdma_destroy_id+0x78/0x4a0 [rdma_cm]
iw_conn_req_handler+0x5c9/0x680 [rdma_cm]
cm_work_handler+0xe62/0x1100 [iw_cm]
process_one_work+0x56d/0xac0
worker_thread+0x7a/0x5d0
kthread+0x1bc/0x210
ret_from_fork+0x24/0x30
This is not a bug as there are actually two lock classes here.
Link: https://lore.kernel.org/r/20190930231707.48259-3-bvanass...@acm.org
Fixes: de910bd92137 ("RDMA/cma: Simplify locking needed for serialization of
callbacks")
Signed-off-by: Bart Van Assche
Reviewed-by: Jason Gunthorpe
Signed-off-by: Jason Gunthorpe
Signed-off-by: Sasha Levin
---
drivers/infiniband/core/cma.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/infiniband/core/cma.c b/drivers/infiniband/core/cma.c
index a68d0ccf67a43..2e48b59926c19 100644
--- a/drivers/infiniband/core/cma.c
+++ b/drivers/infiniband/core/cma.c
@@ -2396,9 +2396,10 @@ static int iw_conn_req_handler(struct iw_cm_id *cm_id,
conn_id->cm_id.iw = NULL;
cma_exch(conn_id, RDMA_CM_DESTROYING);
mutex_unlock(&conn_id->handler_mutex);
+ mutex_unlock(&listen_id->handler_mutex);
cma_deref_id(conn_id);
rdma_destroy_id(&conn_id->id);
- goto out;
+ return ret;
}
mutex_unlock(&conn_id->handler_mutex);
--
2.20.1
[PATCH AUTOSEL 5.3 23/89] selftests/kselftest/runner.sh: Add 45 second timeout per test
From: Kees Cook
[ Upstream commit 852c8cbf34d3b3130a05c38064dd98614f97d3a8 ]
Commit a745f7af3cbd ("selftests/harness: Add 30 second timeout per
test") solves the problem of kselftest_harness.h-using binary tests
possibly hanging forever. However, scripts and other binaries can still
hang forever. This adds a global timeout to each test script run.
To make this configurable (e.g. as needed in the "rtc" test case),
include a new per-test-directory "settings" file (similar to "config")
that can contain kselftest-specific settings. The first recognized field
is "timeout".
Additionally, this splits the reporting for timeouts into a specific
"TIMEOUT" not-ok (and adds exit code reporting in the remaining case).
Signed-off-by: Kees Cook
Signed-off-by: Shuah Khan
Signed-off-by: Sasha Levin
---
tools/testing/selftests/kselftest/runner.sh | 36 +++--
tools/testing/selftests/rtc/settings| 1 +
2 files changed, 34 insertions(+), 3 deletions(-)
create mode 100644 tools/testing/selftests/rtc/settings
diff --git a/tools/testing/selftests/kselftest/runner.sh
b/tools/testing/selftests/kselftest/runner.sh
index 00c9020bdda8b..84de7bc74f2cf 100644
--- a/tools/testing/selftests/kselftest/runner.sh
+++ b/tools/testing/selftests/kselftest/runner.sh
@@ -3,9 +3,14 @@
#
# Runs a set of tests in a given subdirectory.
export skip_rc=4
+export timeout_rc=124
export logfile=/dev/stdout
export per_test_logging=
+# Defaults for "settings" file fields:
+# "timeout" how many seconds to let each test run before failing.
+export kselftest_default_timeout=45
+
# There isn't a shell-agnostic way to find the path of a sourced file,
# so we must rely on BASE_DIR being set to find other tools.
if [ -z "$BASE_DIR" ]; then
@@ -24,6 +29,16 @@ tap_prefix()
fi
}
+tap_timeout()
+{
+ # Make sure tests will time out if utility is available.
+ if [ -x /usr/bin/timeout ] ; then
+ /usr/bin/timeout "$kselftest_timeout" "$1"
+ else
+ "$1"
+ fi
+}
+
run_one()
{
DIR="$1"
@@ -32,6 +47,18 @@ run_one()
BASENAME_TEST=$(basename $TEST)
+ # Reset any "settings"-file variables.
+ export kselftest_timeout="$kselftest_default_timeout"
+ # Load per-test-directory kselftest "settings" file.
+ settings="$BASE_DIR/$DIR/settings"
+ if [ -r "$settings" ] ; then
+ while read line ; do
+ field=$(echo "$line" | cut -d= -f1)
+ value=$(echo "$line" | cut -d= -f2-)
+ eval "kselftest_$field"="$value"
+ done < "$settings"
+ fi
+
TEST_HDR_MSG="selftests: $DIR: $BASENAME_TEST"
echo "# $TEST_HDR_MSG"
if [ ! -x "$TEST" ]; then
@@ -44,14 +71,17 @@ run_one()
echo "not ok $test_num $TEST_HDR_MSG"
else
cd `dirname $TEST` > /dev/null
- (./$BASENAME_TEST 2>&1; echo $? >&3) |
+ ( tap_timeout ./$BASENAME_TEST 2>&1; echo $? >&3) |
tap_prefix >&4) 3>&1) |
(read xs; exit $xs)) 4>>"$logfile" &&
echo "ok $test_num $TEST_HDR_MSG") ||
- (if [ $? -eq $skip_rc ]; then \
+ (rc=$?; \
+ if [ $rc -eq $skip_rc ]; then \
echo "not ok $test_num $TEST_HDR_MSG # SKIP"
+ elif [ $rc -eq $timeout_rc ]; then \
+ echo "not ok $test_num $TEST_HDR_MSG # TIMEOUT"
else
- echo "not ok $test_num $TEST_HDR_MSG"
+ echo "not ok $test_num $TEST_HDR_MSG # exit=$rc"
fi)
cd - >/dev/null
fi
diff --git a/tools/testing/selftests/rtc/settings
b/tools/testing/selftests/rtc/settings
new file mode 100644
index 0..ba4d85f74cd6b
--- /dev/null
+++ b/tools/testing/selftests/rtc/settings
@@ -0,0 +1 @@
+timeout=90
--
2.20.1
[PATCH AUTOSEL 5.3 16/89] crypto: arm/aes-ce - add dependency on AES library
From: Ard Biesheuvel [ Upstream commit f703964fc66804e6049f2670fc11045aa8359b1a ] The ARM accelerated AES driver depends on the new AES library for its non-SIMD fallback so express this in its Kconfig declaration. Signed-off-by: Ard Biesheuvel Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin --- arch/arm/crypto/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/crypto/Kconfig b/arch/arm/crypto/Kconfig index a95322b59799f..8ecbca3e0c787 100644 --- a/arch/arm/crypto/Kconfig +++ b/arch/arm/crypto/Kconfig @@ -98,6 +98,7 @@ config CRYPTO_AES_ARM_CE tristate "Accelerated AES using ARMv8 Crypto Extensions" depends on KERNEL_MODE_NEON select CRYPTO_BLKCIPHER + select CRYPTO_LIB_AES select CRYPTO_SIMD help Use an implementation of AES in CBC, CTR and XTS modes that uses -- 2.20.1
[PATCH AUTOSEL 5.3 24/89] nfs: Fix nfsi->nrequests count error on nfs_inode_remove_request
From: ZhangXiaoxu
[ Upstream commit 33ea5aaa87cdae0f9af4d6b7ee4f650a1a36fd1d ]
When xfstests testing, there are some WARNING as below:
WARNING: CPU: 0 PID: 6235 at fs/nfs/inode.c:122 nfs_clear_inode+0x9c/0xd8
Modules linked in:
CPU: 0 PID: 6235 Comm: umount.nfs
Hardware name: linux,dummy-virt (DT)
pstate: 6005 (nZCv daif -PAN -UAO)
pc : nfs_clear_inode+0x9c/0xd8
lr : nfs_evict_inode+0x60/0x78
sp : fc000f68fc00
x29: fc000f68fc00 x28: fe00c53155c0
x27: fe00c5315000 x26: fc0009a63748
x25: fc000f68fd18 x24: fc000bfaaf40
x23: fc000936d3c0 x22: fe00c4ff5e20
x21: fc000bfaaf40 x20: fe00c4ff5d10
x19: fc000c056000 x18: 003c
x17: x16:
x15: 0040 x14: 0228
x13: fc000c3a2000 x12: 0045
x11: x10:
x9 : x8 :
x7 : x6 : fc00084b027c
x5 : fc0009a64000 x4 : fe00c0e77400
x3 : fc000c0563a8 x2 : fffb
x1 : 764e x0 : 0001
Call trace:
nfs_clear_inode+0x9c/0xd8
nfs_evict_inode+0x60/0x78
evict+0x108/0x380
dispose_list+0x70/0xa0
evict_inodes+0x194/0x210
generic_shutdown_super+0xb0/0x220
nfs_kill_super+0x40/0x88
deactivate_locked_super+0xb4/0x120
deactivate_super+0x144/0x160
cleanup_mnt+0x98/0x148
__cleanup_mnt+0x38/0x50
task_work_run+0x114/0x160
do_notify_resume+0x2f8/0x308
work_pending+0x8/0x14
The nrequest should be increased/decreased only if PG_INODE_REF flag
was setted.
But in the nfs_inode_remove_request function, it maybe decrease when
no PG_INODE_REF flag, this maybe lead nrequests count error.
Reported-by: Hulk Robot
Signed-off-by: ZhangXiaoxu
Signed-off-by: Anna Schumaker
Signed-off-by: Sasha Levin
---
fs/nfs/write.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/fs/nfs/write.c b/fs/nfs/write.c
index 85ca49549b39b..52cab65f91cf0 100644
--- a/fs/nfs/write.c
+++ b/fs/nfs/write.c
@@ -786,7 +786,6 @@ static void nfs_inode_remove_request(struct nfs_page *req)
struct nfs_inode *nfsi = NFS_I(inode);
struct nfs_page *head;
- atomic_long_dec(&nfsi->nrequests);
if (nfs_page_group_sync_on_bit(req, PG_REMOVE)) {
head = req->wb_head;
@@ -799,8 +798,10 @@ static void nfs_inode_remove_request(struct nfs_page *req)
spin_unlock(&mapping->private_lock);
}
- if (test_and_clear_bit(PG_INODE_REF, &req->wb_flags))
+ if (test_and_clear_bit(PG_INODE_REF, &req->wb_flags)) {
nfs_release_request(req);
+ atomic_long_dec(&nfsi->nrequests);
+ }
}
static void
--
2.20.1
[PATCH AUTOSEL 5.3 21/89] HID: hyperv: Use in-place iterator API in the channel callback
From: Dexuan Cui
[ Upstream commit 6a297c90efa68b2864483193b8bfb0d19478600c ]
Simplify the ring buffer handling with the in-place API.
Also avoid the dynamic allocation and the memory leak in the channel
callback function.
Signed-off-by: Dexuan Cui
Acked-by: Jiri Kosina
Signed-off-by: Sasha Levin
---
drivers/hid/hid-hyperv.c | 56 +++-
1 file changed, 10 insertions(+), 46 deletions(-)
diff --git a/drivers/hid/hid-hyperv.c b/drivers/hid/hid-hyperv.c
index 7795831d37c21..f363163200759 100644
--- a/drivers/hid/hid-hyperv.c
+++ b/drivers/hid/hid-hyperv.c
@@ -314,60 +314,24 @@ static void mousevsc_on_receive(struct hv_device *device,
static void mousevsc_on_channel_callback(void *context)
{
- const int packet_size = 0x100;
- int ret;
struct hv_device *device = context;
- u32 bytes_recvd;
- u64 req_id;
struct vmpacket_descriptor *desc;
- unsigned char *buffer;
- int bufferlen = packet_size;
-
- buffer = kmalloc(bufferlen, GFP_ATOMIC);
- if (!buffer)
- return;
-
- do {
- ret = vmbus_recvpacket_raw(device->channel, buffer,
- bufferlen, &bytes_recvd, &req_id);
-
- switch (ret) {
- case 0:
- if (bytes_recvd <= 0) {
- kfree(buffer);
- return;
- }
- desc = (struct vmpacket_descriptor *)buffer;
-
- switch (desc->type) {
- case VM_PKT_COMP:
- break;
-
- case VM_PKT_DATA_INBAND:
- mousevsc_on_receive(device, desc);
- break;
-
- default:
- pr_err("unhandled packet type %d, tid %llx len
%d\n",
- desc->type, req_id, bytes_recvd);
- break;
- }
+ foreach_vmbus_pkt(desc, device->channel) {
+ switch (desc->type) {
+ case VM_PKT_COMP:
break;
- case -ENOBUFS:
- kfree(buffer);
- /* Handle large packet */
- bufferlen = bytes_recvd;
- buffer = kmalloc(bytes_recvd, GFP_ATOMIC);
-
- if (!buffer)
- return;
+ case VM_PKT_DATA_INBAND:
+ mousevsc_on_receive(device, desc);
+ break;
+ default:
+ pr_err("Unhandled packet type %d, tid %llx len %d\n",
+ desc->type, desc->trans_id, desc->len8 * 8);
break;
}
- } while (1);
-
+ }
}
static int mousevsc_connect_to_vsp(struct hv_device *device)
--
2.20.1
[PATCH AUTOSEL 5.3 17/89] RDMA/siw: Fix serialization issue in write_space()
From: Krishnamraju Eraparaju
[ Upstream commit df791c54d627bae53c9be3be40a69594c55de487 ]
In siw_qp_llp_write_space(), 'sock' members should be accessed with
sk_callback_lock held, otherwise, it could race with
siw_sk_restore_upcalls(). And this could cause "NULL deref" panic. Below
panic is due to the NULL cep returned from sk_to_cep(sk):
Call Trace:
siw_qp_llp_write_space+0x11/0x40 [siw]
tcp_check_space+0x4c/0xf0
tcp_rcv_established+0x52b/0x630
tcp_v4_do_rcv+0xf4/0x1e0
tcp_v4_rcv+0x9b8/0xab0
ip_protocol_deliver_rcu+0x2c/0x1c0
ip_local_deliver_finish+0x44/0x50
ip_local_deliver+0x6b/0xf0
? ip_protocol_deliver_rcu+0x1c0/0x1c0
ip_rcv+0x52/0xd0
? ip_rcv_finish_core.isra.14+0x390/0x390
__netif_receive_skb_one_core+0x83/0xa0
netif_receive_skb_internal+0x73/0xb0
napi_gro_frags+0x1ff/0x2b0
t4_ethrx_handler+0x4a7/0x740 [cxgb4]
process_responses+0x2c9/0x590 [cxgb4]
? t4_sge_intr_msix+0x1d/0x30 [cxgb4]
? handle_irq_event_percpu+0x51/0x70
? handle_irq_event+0x41/0x60
? handle_edge_irq+0x97/0x1a0
napi_rx_handler+0x14/0xe0 [cxgb4]
net_rx_action+0x2af/0x410
__do_softirq+0xda/0x2a8
do_softirq_own_stack+0x2a/0x40
do_softirq+0x50/0x60
__local_bh_enable_ip+0x50/0x60
ip_finish_output2+0x18f/0x520
ip_output+0x6e/0xf0
? __ip_finish_output+0x1f0/0x1f0
__ip_queue_xmit+0x14f/0x3d0
? __slab_alloc+0x4b/0x58
__tcp_transmit_skb+0x57d/0xa60
tcp_write_xmit+0x23b/0xfd0
__tcp_push_pending_frames+0x2e/0xf0
tcp_sendmsg_locked+0x939/0xd50
tcp_sendmsg+0x27/0x40
sock_sendmsg+0x57/0x80
siw_tx_hdt+0x894/0xb20 [siw]
? find_busiest_group+0x3e/0x5b0
? common_interrupt+0xa/0xf
? common_interrupt+0xa/0xf
? common_interrupt+0xa/0xf
siw_qp_sq_process+0xf1/0xe60 [siw]
? __wake_up_common_lock+0x87/0xc0
siw_sq_resume+0x33/0xe0 [siw]
siw_run_sq+0xac/0x190 [siw]
? remove_wait_queue+0x60/0x60
kthread+0xf8/0x130
? siw_sq_resume+0xe0/0xe0 [siw]
? kthread_bind+0x10/0x10
ret_from_fork+0x35/0x40
Fixes: f29dd55b0236 ("rdma/siw: queue pair methods")
Link: https://lore.kernel.org/r/20190923101112.32685-1-krish...@chelsio.com
Signed-off-by: Krishnamraju Eraparaju
Reviewed-by: Bernard Metzler
Signed-off-by: Jason Gunthorpe
Signed-off-by: Sasha Levin
---
drivers/infiniband/sw/siw/siw_qp.c | 15 +++
1 file changed, 11 insertions(+), 4 deletions(-)
diff --git a/drivers/infiniband/sw/siw/siw_qp.c
b/drivers/infiniband/sw/siw/siw_qp.c
index 430314c8abd94..52d402f39df93 100644
--- a/drivers/infiniband/sw/siw/siw_qp.c
+++ b/drivers/infiniband/sw/siw/siw_qp.c
@@ -182,12 +182,19 @@ void siw_qp_llp_close(struct siw_qp *qp)
*/
void siw_qp_llp_write_space(struct sock *sk)
{
- struct siw_cep *cep = sk_to_cep(sk);
+ struct siw_cep *cep;
- cep->sk_write_space(sk);
+ read_lock(&sk->sk_callback_lock);
+
+ cep = sk_to_cep(sk);
+ if (cep) {
+ cep->sk_write_space(sk);
- if (!test_bit(SOCK_NOSPACE, &sk->sk_socket->flags))
- (void)siw_sq_start(cep->qp);
+ if (!test_bit(SOCK_NOSPACE, &sk->sk_socket->flags))
+ (void)siw_sq_start(cep->qp);
+ }
+
+ read_unlock(&sk->sk_callback_lock);
}
static int siw_qp_readq_init(struct siw_qp *qp, int irq_size, int orq_size)
--
2.20.1
[PATCH AUTOSEL 5.3 22/89] kselftest: exclude failed TARGETS from runlist
From: Cristian Marussi [ Upstream commit 131b30c94fbc0adb15f911609884dd39dada8f00 ] A TARGET which failed to be built/installed should not be included in the runlist generated inside the run_kselftest.sh script. Signed-off-by: Cristian Marussi Signed-off-by: Shuah Khan Signed-off-by: Sasha Levin --- tools/testing/selftests/Makefile | 4 1 file changed, 4 insertions(+) diff --git a/tools/testing/selftests/Makefile b/tools/testing/selftests/Makefile index 25b43a8c2b159..1779923d7a7b8 100644 --- a/tools/testing/selftests/Makefile +++ b/tools/testing/selftests/Makefile @@ -198,8 +198,12 @@ ifdef INSTALL_PATH echo " cat /dev/null > \$$logfile" >> $(ALL_SCRIPT) echo "fi" >> $(ALL_SCRIPT) + @# While building run_kselftest.sh skip also non-existent TARGET dirs: + @# they could be the result of a build failure and should NOT be + @# included in the generated runlist. for TARGET in $(TARGETS); do \ BUILD_TARGET=$$BUILD/$$TARGET; \ + [ ! -d $$INSTALL_PATH/$$TARGET ] && echo "Skipping non-existent dir: $$TARGET" && continue; \ echo "[ -w /dev/kmsg ] && echo \"kselftest: Running tests in $$TARGET\" >> /dev/kmsg" >> $(ALL_SCRIPT); \ echo "cd $$TARGET" >> $(ALL_SCRIPT); \ echo -n "run_many" >> $(ALL_SCRIPT); \ -- 2.20.1
[PATCH AUTOSEL 5.3 27/89] arm64: ftrace: Ensure synchronisation in PLT setup for Neoverse-N1 #1542419
From: James Morse [ Upstream commit dd8a1f13488438c6c220b7cafa500baaf21a6e53 ] CPUs affected by Neoverse-N1 #1542419 may execute a stale instruction if it was recently modified. The affected sequence requires freshly written instructions to be executable before a branch to them is updated. There are very few places in the kernel that modify executable text, all but one come with sufficient synchronisation: * The module loader's flush_module_icache() calls flush_icache_range(), which does a kick_all_cpus_sync() * bpf_int_jit_compile() calls flush_icache_range(). * Kprobes calls aarch64_insn_patch_text(), which does its work in stop_machine(). * static keys and ftrace both patch between nops and branches to existing kernel code (not generated code). The affected sequence is the interaction between ftrace and modules. The module PLT is cleaned using __flush_icache_range() as the trampoline shouldn't be executable until we update the branch to it. Drop the double-underscore so that this path runs kick_all_cpus_sync() too. Signed-off-by: James Morse Signed-off-by: Will Deacon Signed-off-by: Sasha Levin --- arch/arm64/kernel/ftrace.c | 12 +--- 1 file changed, 9 insertions(+), 3 deletions(-) diff --git a/arch/arm64/kernel/ftrace.c b/arch/arm64/kernel/ftrace.c index 1717732579742..06e56b4703153 100644 --- a/arch/arm64/kernel/ftrace.c +++ b/arch/arm64/kernel/ftrace.c @@ -121,10 +121,16 @@ int ftrace_make_call(struct dyn_ftrace *rec, unsigned long addr) /* * Ensure updated trampoline is visible to instruction -* fetch before we patch in the branch. +* fetch before we patch in the branch. Although the +* architecture doesn't require an IPI in this case, +* Neoverse-N1 erratum #1542419 does require one +* if the TLB maintenance in module_enable_ro() is +* skipped due to rodata_enabled. It doesn't seem worth +* it to make it conditional given that this is +* certainly not a fast-path. */ - __flush_icache_range((unsigned long)&dst[0], -(unsigned long)&dst[1]); + flush_icache_range((unsigned long)&dst[0], + (unsigned long)&dst[1]); } addr = (unsigned long)dst; #else /* CONFIG_ARM64_MODULE_PLTS */ -- 2.20.1
[PATCH AUTOSEL 5.3 34/89] RDMA/cm: Fix memory leak in cm_add/remove_one
From: Jack Morgenstein
[ Upstream commit 94635c36f3854934a46d9e812e028d4721bbb0e6 ]
In the process of moving the debug counters sysfs entries, the commit
mentioned below eliminated the cm_infiniband sysfs directory.
This sysfs directory was tied to the cm_port object allocated in procedure
cm_add_one().
Before the commit below, this cm_port object was freed via a call to
kobject_put(port->kobj) in procedure cm_remove_port_fs().
Since port no longer uses its kobj, kobject_put(port->kobj) was eliminated.
This, however, meant that kfree was never called for the cm_port buffers.
Fix this by adding explicit kfree(port) calls to functions cm_add_one()
and cm_remove_one().
Note: the kfree call in the first chunk below (in the cm_add_one error
flow) fixes an old, undetected memory leak.
Fixes: c87e65cfb97c ("RDMA/cm: Move debug counters to be under relevant IB
device")
Link: https://lore.kernel.org/r/20190916071154.20383-2-l...@kernel.org
Signed-off-by: Jack Morgenstein
Signed-off-by: Leon Romanovsky
Reviewed-by: Jason Gunthorpe
Signed-off-by: Jason Gunthorpe
Signed-off-by: Sasha Levin
---
drivers/infiniband/core/cm.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/infiniband/core/cm.c b/drivers/infiniband/core/cm.c
index da10e6ccb43cd..5920c0085d35b 100644
--- a/drivers/infiniband/core/cm.c
+++ b/drivers/infiniband/core/cm.c
@@ -4399,6 +4399,7 @@ static void cm_add_one(struct ib_device *ib_device)
error1:
port_modify.set_port_cap_mask = 0;
port_modify.clr_port_cap_mask = IB_PORT_CM_SUP;
+ kfree(port);
while (--i) {
if (!rdma_cap_ib_cm(ib_device, i))
continue;
@@ -4407,6 +4408,7 @@ static void cm_add_one(struct ib_device *ib_device)
ib_modify_port(ib_device, port->port_num, 0, &port_modify);
ib_unregister_mad_agent(port->mad_agent);
cm_remove_port_fs(port);
+ kfree(port);
}
free:
kfree(cm_dev);
@@ -4460,6 +4462,7 @@ static void cm_remove_one(struct ib_device *ib_device,
void *client_data)
spin_unlock_irq(&cm.state_lock);
ib_unregister_mad_agent(cur_mad_agent);
cm_remove_port_fs(port);
+ kfree(port);
}
kfree(cm_dev);
--
2.20.1
[PATCH AUTOSEL 5.3 25/89] arm64: cpufeature: Effectively expose FRINT capability to userspace
From: Julien Grall
[ Upstream commit 7230f7e99fecc684180322b056fad3853d1029d3 ]
The HWCAP framework will detect a new capability based on the sanitized
version of the ID registers.
Sanitization is based on a whitelist, so any field not described will end
up to be zeroed.
At the moment, ID_AA64ISAR1_EL1.FRINTTS is not described in
ftr_id_aa64isar1. This means the field will be zeroed and therefore the
userspace will not be able to see the HWCAP even if the hardware
supports the feature.
This can be fixed by describing the field in ftr_id_aa64isar1.
Fixes: ca9503fc9e98 ("arm64: Expose FRINT capabilities to userspace")
Signed-off-by: Julien Grall
Cc: mark.br...@arm.com
Signed-off-by: Will Deacon
Signed-off-by: Sasha Levin
---
arch/arm64/kernel/cpufeature.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
index 9323bcc40a58a..cabebf1a79768 100644
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c
@@ -136,6 +136,7 @@ static const struct arm64_ftr_bits ftr_id_aa64isar0[] = {
static const struct arm64_ftr_bits ftr_id_aa64isar1[] = {
ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE,
ID_AA64ISAR1_SB_SHIFT, 4, 0),
+ ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE,
ID_AA64ISAR1_FRINTTS_SHIFT, 4, 0),
ARM64_FTR_BITS(FTR_VISIBLE_IF_IS_ENABLED(CONFIG_ARM64_PTR_AUTH),
FTR_STRICT, FTR_LOWER_SAFE, ID_AA64ISAR1_GPI_SHIFT, 4,
0),
ARM64_FTR_BITS(FTR_VISIBLE_IF_IS_ENABLED(CONFIG_ARM64_PTR_AUTH),
--
2.20.1
[PATCH AUTOSEL 5.3 32/89] misc: fastrpc: prevent memory leak in fastrpc_dma_buf_attach
From: Navid Emamdoost
[ Upstream commit fc739a058d99c9297ef6bfd923b809d85855b9a9 ]
In fastrpc_dma_buf_attach if dma_get_sgtable fails the allocated memory
for a should be released.
Signed-off-by: Navid Emamdoost
Link: https://lore.kernel.org/r/20190925152742.16258-1-navid.emamdo...@gmail.com
Signed-off-by: Greg Kroah-Hartman
Signed-off-by: Sasha Levin
---
drivers/misc/fastrpc.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/misc/fastrpc.c b/drivers/misc/fastrpc.c
index 98603e235cf04..a76b6c6fd660f 100644
--- a/drivers/misc/fastrpc.c
+++ b/drivers/misc/fastrpc.c
@@ -499,6 +499,7 @@ static int fastrpc_dma_buf_attach(struct dma_buf *dmabuf,
FASTRPC_PHYS(buffer->phys), buffer->size);
if (ret < 0) {
dev_err(buffer->dev, "failed to get scatterlist from DMA
API\n");
+ kfree(a);
return -EINVAL;
}
--
2.20.1
[PATCH AUTOSEL 5.3 35/89] RDMA/cxgb4: Do not dma memory off of the stack
From: Greg KH
[ Upstream commit 3840c5b78803b2b6cc1ff820100a74a092c40cbb ]
Nicolas pointed out that the cxgb4 driver is doing dma off of the stack,
which is generally considered a very bad thing. On some architectures it
could be a security problem, but odds are none of them actually run this
driver, so it's just a "normal" bug.
Resolve this by allocating the memory for a message off of the heap
instead of the stack. kmalloc() always will give us a proper memory
location that DMA will work correctly from.
Link: https://lore.kernel.org/r/20191001165611.ga3542...@kroah.com
Reported-by: Nicolas Waisman
Signed-off-by: Greg Kroah-Hartman
Tested-by: Potnuri Bharat Teja
Signed-off-by: Jason Gunthorpe
Signed-off-by: Sasha Levin
---
drivers/infiniband/hw/cxgb4/mem.c | 28 +---
1 file changed, 17 insertions(+), 11 deletions(-)
diff --git a/drivers/infiniband/hw/cxgb4/mem.c
b/drivers/infiniband/hw/cxgb4/mem.c
index aa772ee0706f9..35c284af574da 100644
--- a/drivers/infiniband/hw/cxgb4/mem.c
+++ b/drivers/infiniband/hw/cxgb4/mem.c
@@ -275,13 +275,17 @@ static int write_tpt_entry(struct c4iw_rdev *rdev, u32
reset_tpt_entry,
struct sk_buff *skb, struct c4iw_wr_wait *wr_waitp)
{
int err;
- struct fw_ri_tpte tpt;
+ struct fw_ri_tpte *tpt;
u32 stag_idx;
static atomic_t key;
if (c4iw_fatal_error(rdev))
return -EIO;
+ tpt = kmalloc(sizeof(*tpt), GFP_KERNEL);
+ if (!tpt)
+ return -ENOMEM;
+
stag_state = stag_state > 0;
stag_idx = (*stag) >> 8;
@@ -291,6 +295,7 @@ static int write_tpt_entry(struct c4iw_rdev *rdev, u32
reset_tpt_entry,
mutex_lock(&rdev->stats.lock);
rdev->stats.stag.fail++;
mutex_unlock(&rdev->stats.lock);
+ kfree(tpt);
return -ENOMEM;
}
mutex_lock(&rdev->stats.lock);
@@ -305,28 +310,28 @@ static int write_tpt_entry(struct c4iw_rdev *rdev, u32
reset_tpt_entry,
/* write TPT entry */
if (reset_tpt_entry)
- memset(&tpt, 0, sizeof(tpt));
+ memset(tpt, 0, sizeof(*tpt));
else {
- tpt.valid_to_pdid = cpu_to_be32(FW_RI_TPTE_VALID_F |
+ tpt->valid_to_pdid = cpu_to_be32(FW_RI_TPTE_VALID_F |
FW_RI_TPTE_STAGKEY_V((*stag & FW_RI_TPTE_STAGKEY_M)) |
FW_RI_TPTE_STAGSTATE_V(stag_state) |
FW_RI_TPTE_STAGTYPE_V(type) | FW_RI_TPTE_PDID_V(pdid));
- tpt.locread_to_qpid = cpu_to_be32(FW_RI_TPTE_PERM_V(perm) |
+ tpt->locread_to_qpid = cpu_to_be32(FW_RI_TPTE_PERM_V(perm) |
(bind_enabled ? FW_RI_TPTE_MWBINDEN_F : 0) |
FW_RI_TPTE_ADDRTYPE_V((zbva ? FW_RI_ZERO_BASED_TO :
FW_RI_VA_BASED_TO))|
FW_RI_TPTE_PS_V(page_size));
- tpt.nosnoop_pbladdr = !pbl_size ? 0 : cpu_to_be32(
+ tpt->nosnoop_pbladdr = !pbl_size ? 0 : cpu_to_be32(
FW_RI_TPTE_PBLADDR_V(PBL_OFF(rdev, pbl_addr)>>3));
- tpt.len_lo = cpu_to_be32((u32)(len & 0xUL));
- tpt.va_hi = cpu_to_be32((u32)(to >> 32));
- tpt.va_lo_fbo = cpu_to_be32((u32)(to & 0xUL));
- tpt.dca_mwbcnt_pstag = cpu_to_be32(0);
- tpt.len_hi = cpu_to_be32((u32)(len >> 32));
+ tpt->len_lo = cpu_to_be32((u32)(len & 0xUL));
+ tpt->va_hi = cpu_to_be32((u32)(to >> 32));
+ tpt->va_lo_fbo = cpu_to_be32((u32)(to & 0xUL));
+ tpt->dca_mwbcnt_pstag = cpu_to_be32(0);
+ tpt->len_hi = cpu_to_be32((u32)(len >> 32));
}
err = write_adapter_mem(rdev, stag_idx +
(rdev->lldi.vr->stag.start >> 5),
- sizeof(tpt), &tpt, skb, wr_waitp);
+ sizeof(*tpt), tpt, skb, wr_waitp);
if (reset_tpt_entry) {
c4iw_put_resource(&rdev->resource.tpt_table, stag_idx);
@@ -334,6 +339,7 @@ static int write_tpt_entry(struct c4iw_rdev *rdev, u32
reset_tpt_entry,
rdev->stats.stag.cur -= 32;
mutex_unlock(&rdev->stats.lock);
}
+ kfree(tpt);
return err;
}
--
2.20.1
[PATCH AUTOSEL 5.3 28/89] tty: serial: owl: Fix the link time qualifier of 'owl_uart_exit()'
From: Christophe JAILLET
[ Upstream commit 6264dab6efd6069f0387efb078a9960b5642377b ]
'exit' functions should be marked as __exit, not __init.
Fixes: fc60a8b675bd ("tty: serial: owl: Implement console driver")
Signed-off-by: Christophe JAILLET
Link:
https://lore.kernel.org/r/20190910041129.6978-1-christophe.jail...@wanadoo.fr
Signed-off-by: Greg Kroah-Hartman
Signed-off-by: Sasha Levin
---
drivers/tty/serial/owl-uart.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/tty/serial/owl-uart.c b/drivers/tty/serial/owl-uart.c
index 29a6dc6a8d23c..73fcc6bdb0312 100644
--- a/drivers/tty/serial/owl-uart.c
+++ b/drivers/tty/serial/owl-uart.c
@@ -742,7 +742,7 @@ static int __init owl_uart_init(void)
return ret;
}
-static void __init owl_uart_exit(void)
+static void __exit owl_uart_exit(void)
{
platform_driver_unregister(&owl_uart_platform_driver);
uart_unregister_driver(&owl_uart_driver);
--
2.20.1
[PATCH AUTOSEL 5.3 30/89] serial/sifive: select SERIAL_EARLYCON
From: Christoph Hellwig [ Upstream commit 7e2a165de5a52003d10a611ee3884cdb5c44e8cd ] The sifive serial driver implements earlycon support, but unless another driver is built in that supports earlycon support it won't be usable. Explicitly select SERIAL_EARLYCON instead. Signed-off-by: Christoph Hellwig Reviewed-by: Paul Walmsley Link: https://lore.kernel.org/r/20190910055923.28384-1-...@lst.de Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin --- drivers/tty/serial/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig index 3083dbae35f7e..3b436ccd29dad 100644 --- a/drivers/tty/serial/Kconfig +++ b/drivers/tty/serial/Kconfig @@ -1075,6 +1075,7 @@ config SERIAL_SIFIVE_CONSOLE bool "Console on SiFive UART" depends on SERIAL_SIFIVE=y select SERIAL_CORE_CONSOLE + select SERIAL_EARLYCON help Select this option if you would like to use a SiFive UART as the system console. -- 2.20.1
[PATCH AUTOSEL 5.3 33/89] RDMA/core: Fix an error handling path in 'res_get_common_doit()'
From: Christophe JAILLET
[ Upstream commit ab59ca3eb4e7059727df85eee68bda169d26c8f8 ]
According to surrounding error paths, it is likely that 'goto err_get;' is
expected here. Otherwise, a call to 'rdma_restrack_put(res);' would be
missing.
Fixes: c5dfe0ea6ffa ("RDMA/nldev: Add resource tracker doit callback")
Link:
https://lore.kernel.org/r/20190818091044.8845-1-christophe.jail...@wanadoo.fr
Signed-off-by: Christophe JAILLET
Reviewed-by: Jason Gunthorpe
Signed-off-by: Jason Gunthorpe
Signed-off-by: Sasha Levin
---
drivers/infiniband/core/nldev.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/infiniband/core/nldev.c b/drivers/infiniband/core/nldev.c
index 020c269765584..91e2cc9ddb9f8 100644
--- a/drivers/infiniband/core/nldev.c
+++ b/drivers/infiniband/core/nldev.c
@@ -1230,7 +1230,7 @@ static int res_get_common_doit(struct sk_buff *skb,
struct nlmsghdr *nlh,
msg = nlmsg_new(NLMSG_DEFAULT_SIZE, GFP_KERNEL);
if (!msg) {
ret = -ENOMEM;
- goto err;
+ goto err_get;
}
nlh = nlmsg_put(msg, NETLINK_CB(skb).portid, nlh->nlmsg_seq,
--
2.20.1
[PATCH AUTOSEL 5.3 38/89] RDMA/mlx5: Order num_pending_prefetch properly with synchronize_srcu
From: Jason Gunthorpe
[ Upstream commit aa116b810ac9077a263ed8679fb4d595f180e0eb ]
During destroy setting live = 0 and then synchronize_srcu() prevents
num_pending_prefetch from incrementing, and also, ensures that all work
holding that count is queued on the WQ. Testing before causes races of the
form:
CPU0 CPU1
dereg_mr()
mlx5_ib_advise_mr_prefetch()
srcu_read_lock()
num_pending_prefetch_inc()
if (!live)
live = 0
atomic_read() == 0
// skip flush_workqueue()
atomic_inc()
queue_work();
srcu_read_unlock()
WARN_ON(atomic_read()) // Fails
Swap the order so that the synchronize_srcu() prevents this.
Fixes: a6bc3875f176 ("IB/mlx5: Protect against prefetch of invalid MR")
Link: https://lore.kernel.org/r/20191001153821.23621-5-...@ziepe.ca
Reviewed-by: Artemy Kovalyov
Signed-off-by: Jason Gunthorpe
Signed-off-by: Sasha Levin
---
drivers/infiniband/hw/mlx5/mr.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/infiniband/hw/mlx5/mr.c b/drivers/infiniband/hw/mlx5/mr.c
index c4ba8838d2c46..96c8a6835592d 100644
--- a/drivers/infiniband/hw/mlx5/mr.c
+++ b/drivers/infiniband/hw/mlx5/mr.c
@@ -1591,13 +1591,14 @@ static void dereg_mr(struct mlx5_ib_dev *dev, struct
mlx5_ib_mr *mr)
*/
mr->live = 0;
+ /* Wait for all running page-fault handlers to finish. */
+ synchronize_srcu(&dev->mr_srcu);
+
/* dequeue pending prefetch requests for the mr */
if (atomic_read(&mr->num_pending_prefetch))
flush_workqueue(system_unbound_wq);
WARN_ON(atomic_read(&mr->num_pending_prefetch));
- /* Wait for all running page-fault handlers to finish. */
- synchronize_srcu(&dev->mr_srcu);
/* Destroy all page mappings */
if (umem_odp->page_list)
mlx5_ib_invalidate_range(umem_odp,
--
2.20.1
[PATCH AUTOSEL 5.3 37/89] RDMA/mlx5: Do not allow rereg of a ODP MR
From: Jason Gunthorpe
[ Upstream commit 880505cfef1d086d18b59d2920eb2160429ffa1f ]
This code is completely broken, the umem of a ODP MR simply cannot be
discarded without a lot more locking, nor can an ODP mkey be blithely
destroyed via destroy_mkey().
Fixes: 6aec21f6a832 ("IB/mlx5: Page faults handling infrastructure")
Link: https://lore.kernel.org/r/20191001153821.23621-2-...@ziepe.ca
Reviewed-by: Artemy Kovalyov
Signed-off-by: Jason Gunthorpe
Signed-off-by: Sasha Levin
---
drivers/infiniband/hw/mlx5/mr.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/infiniband/hw/mlx5/mr.c b/drivers/infiniband/hw/mlx5/mr.c
index 3401f5f6792e6..c4ba8838d2c46 100644
--- a/drivers/infiniband/hw/mlx5/mr.c
+++ b/drivers/infiniband/hw/mlx5/mr.c
@@ -1423,6 +1423,9 @@ int mlx5_ib_rereg_user_mr(struct ib_mr *ib_mr, int flags,
u64 start,
if (!mr->umem)
return -EINVAL;
+ if (is_odp_mr(mr))
+ return -EOPNOTSUPP;
+
if (flags & IB_MR_REREG_TRANS) {
addr = virt_addr;
len = length;
@@ -1468,8 +1471,6 @@ int mlx5_ib_rereg_user_mr(struct ib_mr *ib_mr, int flags,
u64 start,
}
mr->allocated_from_cache = 0;
- if (IS_ENABLED(CONFIG_INFINIBAND_ON_DEMAND_PAGING))
- mr->live = 1;
} else {
/*
* Send a UMR WQE
@@ -1498,7 +1499,6 @@ int mlx5_ib_rereg_user_mr(struct ib_mr *ib_mr, int flags,
u64 start,
set_mr_fields(dev, mr, npages, len, access_flags);
- update_odp_mr(mr);
return 0;
err:
--
2.20.1
[PATCH AUTOSEL 5.3 40/89] gpio: max77620: Use correct unit for debounce times
From: Thierry Reding [ Upstream commit fffa6af94894126994a7600c6f6f09b892e89fa9 ] The gpiod_set_debounce() function takes the debounce time in microseconds. Adjust the switch/case values in the MAX77620 GPIO to use the correct unit. Signed-off-by: Thierry Reding Link: https://lore.kernel.org/r/20191002122825.3948322-1-thierry.red...@gmail.com Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin --- drivers/gpio/gpio-max77620.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/gpio/gpio-max77620.c b/drivers/gpio/gpio-max77620.c index b7d89e30131e2..06e8caaafa811 100644 --- a/drivers/gpio/gpio-max77620.c +++ b/drivers/gpio/gpio-max77620.c @@ -192,13 +192,13 @@ static int max77620_gpio_set_debounce(struct max77620_gpio *mgpio, case 0: val = MAX77620_CNFG_GPIO_DBNC_None; break; - case 1 ... 8: + case 1000 ... 8000: val = MAX77620_CNFG_GPIO_DBNC_8ms; break; - case 9 ... 16: + case 9000 ... 16000: val = MAX77620_CNFG_GPIO_DBNC_16ms; break; - case 17 ... 32: + case 17000 ... 32000: val = MAX77620_CNFG_GPIO_DBNC_32ms; break; default: -- 2.20.1
[PATCH AUTOSEL 5.3 56/89] ocfs2: clear zero in unaligned direct IO
From: Jia Guo [ Upstream commit 7a243c82ea527cd1da47381ad9cd646844f3b693 ] Unused portion of a part-written fs-block-sized block is not set to zero in unaligned append direct write.This can lead to serious data inconsistencies. Ocfs2 manage disk with cluster size(for example, 1M), part-written in one cluster will change the cluster state from UN-WRITTEN to WRITTEN, VFS(function dio_zero_block) doesn't do the cleaning because bh's state is not set to NEW in function ocfs2_dio_wr_get_block when we write a WRITTEN cluster. For example, the cluster size is 1M, file size is 8k and we direct write from 14k to 15k, then 12k~14k and 15k~16k will contain dirty data. We have to deal with two cases: 1.The starting position of direct write is outside the file. 2.The starting position of direct write is located in the file. We need set bh's state to NEW in the first case. In the second case, we need mapped twice because bh's state of area out file should be set to NEW while area in file not. [a...@linux-foundation.org: coding style fixes] Link: http://lkml.kernel.org/r/5292e287-8f1a-fd4a-1a14-661e555e0...@huawei.com Signed-off-by: Jia Guo Reviewed-by: Yiwen Jiang Cc: Mark Fasheh Cc: Joel Becker Cc: Junxiao Bi Cc: Joseph Qi Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin --- fs/ocfs2/aops.c | 22 +- 1 file changed, 21 insertions(+), 1 deletion(-) diff --git a/fs/ocfs2/aops.c b/fs/ocfs2/aops.c index a4c905d6b5755..3e0a93e799ea1 100644 --- a/fs/ocfs2/aops.c +++ b/fs/ocfs2/aops.c @@ -2139,13 +2139,30 @@ static int ocfs2_dio_wr_get_block(struct inode *inode, sector_t iblock, struct ocfs2_dio_write_ctxt *dwc = NULL; struct buffer_head *di_bh = NULL; u64 p_blkno; - loff_t pos = iblock << inode->i_sb->s_blocksize_bits; + unsigned int i_blkbits = inode->i_sb->s_blocksize_bits; + loff_t pos = iblock << i_blkbits; + sector_t endblk = (i_size_read(inode) - 1) >> i_blkbits; unsigned len, total_len = bh_result->b_size; int ret = 0, first_get_block = 0; len = osb->s_clustersize - (pos & (osb->s_clustersize - 1)); len = min(total_len, len); + /* +* bh_result->b_size is count in get_more_blocks according to write +* "pos" and "end", we need map twice to return different buffer state: +* 1. area in file size, not set NEW; +* 2. area out file size, set NEW. +* +* iblockendblk +* ||-|-|- +* |<---area in file--->| +*/ + + if ((iblock <= endblk) && + ((iblock + ((len - 1) >> i_blkbits)) > endblk)) + len = (endblk - iblock + 1) << i_blkbits; + mlog(0, "get block of %lu at %llu:%u req %u\n", inode->i_ino, pos, len, total_len); @@ -2229,6 +2246,9 @@ static int ocfs2_dio_wr_get_block(struct inode *inode, sector_t iblock, if (desc->c_needs_zero) set_buffer_new(bh_result); + if (iblock > endblk) + set_buffer_new(bh_result); + /* May sleep in end_io. It should not happen in a irq context. So defer * it to dio work queue. */ set_buffer_defer_completion(bh_result); -- 2.20.1
[PATCH AUTOSEL 5.3 47/89] arm64: vdso32: Don't use KBUILD_CPPFLAGS unconditionally
From: Will Deacon [ Upstream commit c71e88c437962c1ec43d4d23a0ebf4c9cf9bee0d ] KBUILD_CPPFLAGS is defined differently depending on whether the main compiler is clang or not. This means that it is not possible to build the compat vDSO with GCC if the rest of the kernel is built with clang. Define VDSO_CPPFLAGS directly to break this dependency and allow a clang kernel to build a compat vDSO with GCC: $ make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- \ CROSS_COMPILE_COMPAT=arm-linux-gnueabihf- CC=clang \ COMPATCC=arm-linux-gnueabihf-gcc Acked-by: Catalin Marinas Signed-off-by: Will Deacon Signed-off-by: Sasha Levin --- arch/arm64/kernel/vdso32/Makefile | 6 ++ 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/arch/arm64/kernel/vdso32/Makefile b/arch/arm64/kernel/vdso32/Makefile index 77aa613403747..aa171b043287b 100644 --- a/arch/arm64/kernel/vdso32/Makefile +++ b/arch/arm64/kernel/vdso32/Makefile @@ -25,11 +25,9 @@ cc32-as-instr = $(call try-run,\ # arm64 one. # As a result we set our own flags here. -# From top-level Makefile -# NOSTDINC_FLAGS -VDSO_CPPFLAGS := -nostdinc -isystem $(shell $(COMPATCC) -print-file-name=include) +# KBUILD_CPPFLAGS and NOSTDINC_FLAGS from top-level Makefile +VDSO_CPPFLAGS := -D__KERNEL__ -nostdinc -isystem $(shell $(COMPATCC) -print-file-name=include) VDSO_CPPFLAGS += $(LINUXINCLUDE) -VDSO_CPPFLAGS += $(KBUILD_CPPFLAGS) # Common C and assembly flags # From top-level Makefile -- 2.20.1
[PATCH AUTOSEL 5.3 44/89] serial: mctrl_gpio: Check for NULL pointer
From: Adam Ford
[ Upstream commit 37e3ab00e4734acc15d96b2926aab55c894f4d9c ]
When using mctrl_gpio_to_gpiod, it dereferences gpios into a single
requested GPIO. This dereferencing can break if gpios is NULL,
so this patch adds a NULL check before dereferencing it. If
gpios is NULL, this function will also return NULL.
Signed-off-by: Adam Ford
Reviewed-by: Yegor Yefremov
Link: https://lore.kernel.org/r/20191006163314.23191-1-aford...@gmail.com
Signed-off-by: Greg Kroah-Hartman
Signed-off-by: Sasha Levin
---
drivers/tty/serial/serial_mctrl_gpio.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/tty/serial/serial_mctrl_gpio.c
b/drivers/tty/serial/serial_mctrl_gpio.c
index 2b400189be911..54c43e02e3755 100644
--- a/drivers/tty/serial/serial_mctrl_gpio.c
+++ b/drivers/tty/serial/serial_mctrl_gpio.c
@@ -61,6 +61,9 @@ EXPORT_SYMBOL_GPL(mctrl_gpio_set);
struct gpio_desc *mctrl_gpio_to_gpiod(struct mctrl_gpios *gpios,
enum mctrl_gpio_idx gidx)
{
+ if (gpios == NULL)
+ return NULL;
+
return gpios->gpio[gidx];
}
EXPORT_SYMBOL_GPL(mctrl_gpio_to_gpiod);
--
2.20.1
[PATCH AUTOSEL 5.3 52/89] riscv: avoid kernel hangs when trapped in BUG()
From: Vincent Chen
[ Upstream commit 8b04825ed205da38754f86f4c07ea8600d8c2a65 ]
When the CONFIG_GENERIC_BUG is disabled by disabling CONFIG_BUG, if a
kernel thread is trapped by BUG(), the whole system will be in the
loop that infinitely handles the ebreak exception instead of entering the
die function. To fix this problem, the do_trap_break() will always call
the die() to deal with the break exception as the type of break is
BUG_TRAP_TYPE_BUG.
Signed-off-by: Vincent Chen
Reviewed-by: Christoph Hellwig
Signed-off-by: Paul Walmsley
Signed-off-by: Sasha Levin
---
arch/riscv/kernel/traps.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/riscv/kernel/traps.c b/arch/riscv/kernel/traps.c
index 424eb72d56b10..055a937aca70a 100644
--- a/arch/riscv/kernel/traps.c
+++ b/arch/riscv/kernel/traps.c
@@ -124,23 +124,23 @@ static inline unsigned long
get_break_insn_length(unsigned long pc)
asmlinkage void do_trap_break(struct pt_regs *regs)
{
-#ifdef CONFIG_GENERIC_BUG
if (!user_mode(regs)) {
enum bug_trap_type type;
type = report_bug(regs->sepc, regs);
switch (type) {
+#ifdef CONFIG_GENERIC_BUG
case BUG_TRAP_TYPE_NONE:
break;
case BUG_TRAP_TYPE_WARN:
regs->sepc += get_break_insn_length(regs->sepc);
break;
case BUG_TRAP_TYPE_BUG:
+#endif /* CONFIG_GENERIC_BUG */
+ default:
die(regs, "Kernel BUG");
}
}
-#endif /* CONFIG_GENERIC_BUG */
-
force_sig_fault(SIGTRAP, TRAP_BRKPT, (void __user *)(regs->sepc));
}
--
2.20.1
[PATCH AUTOSEL 5.3 41/89] fs: cifs: mute -Wunused-const-variable message
From: Austin Kim
[ Upstream commit dd19c106a36690b47bb1acc68372f2b472b495b8 ]
After 'Initial git repository build' commit,
'mapping_table_ERRHRD' variable has not been used.
So 'mapping_table_ERRHRD' const variable could be removed
to mute below warning message:
fs/cifs/netmisc.c:120:40: warning: unused variable 'mapping_table_ERRHRD'
[-Wunused-const-variable]
static const struct smb_to_posix_error mapping_table_ERRHRD[] = {
^
Signed-off-by: Austin Kim
Signed-off-by: Steve French
Signed-off-by: Sasha Levin
---
fs/cifs/netmisc.c | 4
1 file changed, 4 deletions(-)
diff --git a/fs/cifs/netmisc.c b/fs/cifs/netmisc.c
index ed92958e842d3..657f409d4de06 100644
--- a/fs/cifs/netmisc.c
+++ b/fs/cifs/netmisc.c
@@ -117,10 +117,6 @@ static const struct smb_to_posix_error
mapping_table_ERRSRV[] = {
{0, 0}
};
-static const struct smb_to_posix_error mapping_table_ERRHRD[] = {
- {0, 0}
-};
-
/*
* Convert a string containing text IPv4 or IPv6 address to binary form.
*
--
2.20.1
[PATCH AUTOSEL 5.3 46/89] arm64: Default to building compat vDSO with clang when CONFIG_CC_IS_CLANG
From: Will Deacon [ Upstream commit 24ee01a927bfe56c66429ec4b1df6955a814adc8 ] Rather than force the use of GCC for the compat cross-compiler, instead extract the target from CROSS_COMPILE_COMPAT and pass it to clang if the main compiler is clang. Acked-by: Catalin Marinas Signed-off-by: Will Deacon Signed-off-by: Sasha Levin --- arch/arm64/Makefile | 4 1 file changed, 4 insertions(+) diff --git a/arch/arm64/Makefile b/arch/arm64/Makefile index 9743b50bdee7d..5858d6e449268 100644 --- a/arch/arm64/Makefile +++ b/arch/arm64/Makefile @@ -47,7 +47,11 @@ $(warning Detected assembler with broken .inst; disassembly will be unreliable) endif endif +ifeq ($(CONFIG_CC_IS_CLANG), y) +COMPATCC ?= $(CC) --target=$(notdir $(CROSS_COMPILE_COMPAT:%-=%)) +else COMPATCC ?= $(CROSS_COMPILE_COMPAT)gcc +endif export COMPATCC ifeq ($(CONFIG_GENERIC_COMPAT_VDSO), y) -- 2.20.1
[PATCH AUTOSEL 5.3 64/89] sched/vtime: Fix guest/system mis-accounting on task switch
From: Frederic Weisbecker
[ Upstream commit 68e7a4d66b0ce04bf18ff2ffded5596ab3618585 ]
vtime_account_system() assumes that the target task to account cputime
to is always the current task. This is most often true indeed except on
task switch where we call:
vtime_common_task_switch(prev)
vtime_account_system(prev)
Here prev is the scheduling-out task where we account the cputime to. It
doesn't match current that is already the scheduling-in task at this
stage of the context switch.
So we end up checking the wrong task flags to determine if we are
accounting guest or system time to the previous task.
As a result the wrong task is used to check if the target is running in
guest mode. We may then spuriously account or leak either system or
guest time on task switch.
Fix this assumption and also turn vtime_guest_enter/exit() to use the
task passed in parameter as well to avoid future similar issues.
Signed-off-by: Frederic Weisbecker
Signed-off-by: Peter Zijlstra (Intel)
Cc: Linus Torvalds
Cc: Peter Zijlstra
Cc: Rik van Riel
Cc: Thomas Gleixner
Cc: Wanpeng Li
Fixes: 2a42eb9594a1 ("sched/cputime: Accumulate vtime on top of nsec
clocksource")
Link: https://lkml.kernel.org/r/20190925214242.21873-1-frede...@kernel.org
Signed-off-by: Ingo Molnar
Signed-off-by: Sasha Levin
---
kernel/sched/cputime.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/kernel/sched/cputime.c b/kernel/sched/cputime.c
index 2305ce89a26cf..46ed4e1383e21 100644
--- a/kernel/sched/cputime.c
+++ b/kernel/sched/cputime.c
@@ -740,7 +740,7 @@ void vtime_account_system(struct task_struct *tsk)
write_seqcount_begin(&vtime->seqcount);
/* We might have scheduled out from guest path */
- if (current->flags & PF_VCPU)
+ if (tsk->flags & PF_VCPU)
vtime_account_guest(tsk, vtime);
else
__vtime_account_system(tsk, vtime);
@@ -783,7 +783,7 @@ void vtime_guest_enter(struct task_struct *tsk)
*/
write_seqcount_begin(&vtime->seqcount);
__vtime_account_system(tsk, vtime);
- current->flags |= PF_VCPU;
+ tsk->flags |= PF_VCPU;
write_seqcount_end(&vtime->seqcount);
}
EXPORT_SYMBOL_GPL(vtime_guest_enter);
@@ -794,7 +794,7 @@ void vtime_guest_exit(struct task_struct *tsk)
write_seqcount_begin(&vtime->seqcount);
vtime_account_guest(tsk, vtime);
- current->flags &= ~PF_VCPU;
+ tsk->flags &= ~PF_VCPU;
write_seqcount_end(&vtime->seqcount);
}
EXPORT_SYMBOL_GPL(vtime_guest_exit);
--
2.20.1
[PATCH AUTOSEL 5.3 68/89] drm/amdgpu: fix memory leak
From: Nirmoy Das
[ Upstream commit 083164dbdb17c5ea4ad92c1782b59c9d75567790 ]
cleanup error handling code and make sure temporary info array
with the handles are freed by amdgpu_bo_list_put() on
idr_replace()'s failure.
Signed-off-by: Nirmoy Das
Reviewed-by: Christian König
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/amdgpu/amdgpu_bo_list.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_bo_list.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_bo_list.c
index 7bcf86c619995..61e38e43ad1d5 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_bo_list.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_bo_list.c
@@ -270,7 +270,7 @@ int amdgpu_bo_list_ioctl(struct drm_device *dev, void *data,
r = amdgpu_bo_create_list_entry_array(&args->in, &info);
if (r)
- goto error_free;
+ return r;
switch (args->in.operation) {
case AMDGPU_BO_LIST_OP_CREATE:
@@ -283,8 +283,7 @@ int amdgpu_bo_list_ioctl(struct drm_device *dev, void *data,
r = idr_alloc(&fpriv->bo_list_handles, list, 1, 0, GFP_KERNEL);
mutex_unlock(&fpriv->bo_list_lock);
if (r < 0) {
- amdgpu_bo_list_put(list);
- return r;
+ goto error_put_list;
}
handle = r;
@@ -306,9 +305,8 @@ int amdgpu_bo_list_ioctl(struct drm_device *dev, void *data,
mutex_unlock(&fpriv->bo_list_lock);
if (IS_ERR(old)) {
- amdgpu_bo_list_put(list);
r = PTR_ERR(old);
- goto error_free;
+ goto error_put_list;
}
amdgpu_bo_list_put(old);
@@ -325,8 +323,10 @@ int amdgpu_bo_list_ioctl(struct drm_device *dev, void
*data,
return 0;
+error_put_list:
+ amdgpu_bo_list_put(list);
+
error_free:
- if (info)
- kvfree(info);
+ kvfree(info);
return r;
}
--
2.20.1
[PATCH AUTOSEL 5.3 62/89] x86/cpu: Add Comet Lake to the Intel CPU models header
From: Kan Liang [ Upstream commit 8d7c6ac3b2371eb1cbc9925a88f4d10efff374de ] Comet Lake is the new 10th Gen Intel processor. Add two new CPU model numbers to the Intel family list. The CPU model numbers are not published in the SDM yet but they come from an authoritative internal source. [ bp: Touch up commit message. ] Signed-off-by: Kan Liang Signed-off-by: Borislav Petkov Reviewed-by: Tony Luck Cc: a...@linux.intel.com Cc: "H. Peter Anvin" Cc: Ingo Molnar Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: x86-ml Link: https://lkml.kernel.org/r/1570549810-25049-2-git-send-email-kan.li...@linux.intel.com Signed-off-by: Sasha Levin --- arch/x86/include/asm/intel-family.h | 3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/x86/include/asm/intel-family.h b/arch/x86/include/asm/intel-family.h index 9ae1c0f05fd2d..3525014c71da9 100644 --- a/arch/x86/include/asm/intel-family.h +++ b/arch/x86/include/asm/intel-family.h @@ -76,6 +76,9 @@ #define INTEL_FAM6_TIGERLAKE_L 0x8C #define INTEL_FAM6_TIGERLAKE 0x8D +#define INTEL_FAM6_COMETLAKE 0xA5 +#define INTEL_FAM6_COMETLAKE_L 0xA6 + /* "Small Core" Processors (Atom) */ #define INTEL_FAM6_ATOM_BONNELL0x1C /* Diamondville, Pineview */ -- 2.20.1
[PATCH AUTOSEL 5.3 65/89] perf/core: Rework memory accounting in perf_mmap()
From: Song Liu
[ Upstream commit d44248a41337731a111374822d7d4451b64e73e4 ]
perf_mmap() always increases user->locked_vm. As a result, "extra" could
grow bigger than "user_extra", which doesn't make sense. Here is an
example case:
(Note: Assume "user_lock_limit" is very small.)
| # of perf_mmap calls |vma->vm_mm->pinned_vm|user->locked_vm|
| 0| 0 | 0 |
| 1| user_extra | user_extra|
| 2| 3 * user_extra | 2 * user_extra|
| 3| 6 * user_extra | 3 * user_extra|
| 4| 10 * user_extra | 4 * user_extra|
Fix this by maintaining proper user_extra and extra.
Reviewed-By: Hechao Li
Reported-by: Hechao Li
Signed-off-by: Song Liu
Signed-off-by: Peter Zijlstra (Intel)
Cc:
Cc: Jie Meng
Cc: Linus Torvalds
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Link: https://lkml.kernel.org/r/20190904214618.3795672-1-songliubrav...@fb.com
Signed-off-by: Ingo Molnar
Signed-off-by: Sasha Levin
---
kernel/events/core.c | 17 +++--
1 file changed, 15 insertions(+), 2 deletions(-)
diff --git a/kernel/events/core.c b/kernel/events/core.c
index 0463c1151baeb..a0120bdbce177 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -5585,7 +5585,8 @@ static void perf_mmap_close(struct vm_area_struct *vma)
* undo the VM accounting.
*/
- atomic_long_sub((size >> PAGE_SHIFT) + 1, &mmap_user->locked_vm);
+ atomic_long_sub((size >> PAGE_SHIFT) + 1 - mmap_locked,
+ &mmap_user->locked_vm);
atomic64_sub(mmap_locked, &vma->vm_mm->pinned_vm);
free_uid(mmap_user);
@@ -5729,8 +5730,20 @@ static int perf_mmap(struct file *file, struct
vm_area_struct *vma)
user_locked = atomic_long_read(&user->locked_vm) + user_extra;
- if (user_locked > user_lock_limit)
+ if (user_locked <= user_lock_limit) {
+ /* charge all to locked_vm */
+ } else if (atomic_long_read(&user->locked_vm) >= user_lock_limit) {
+ /* charge all to pinned_vm */
+ extra = user_extra;
+ user_extra = 0;
+ } else {
+ /*
+* charge locked_vm until it hits user_lock_limit;
+* charge the rest from pinned_vm
+*/
extra = user_locked - user_lock_limit;
+ user_extra -= extra;
+ }
lock_limit = rlimit(RLIMIT_MEMLOCK);
lock_limit >>= PAGE_SHIFT;
--
2.20.1
[PATCH AUTOSEL 5.3 53/89] riscv: avoid sending a SIGTRAP to a user thread trapped in WARN()
From: Vincent Chen [ Upstream commit e0c0fc18f10d5080cddde0e81505fd3e952c20c4 ] On RISC-V, when the kernel runs code on behalf of a user thread, and the kernel executes a WARN() or WARN_ON(), the user thread will be sent a bogus SIGTRAP. Fix the RISC-V kernel code to not send a SIGTRAP when a WARN()/WARN_ON() is executed. Signed-off-by: Vincent Chen Reviewed-by: Christoph Hellwig [paul.walms...@sifive.com: fixed subject] Signed-off-by: Paul Walmsley Signed-off-by: Sasha Levin --- arch/riscv/kernel/traps.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/riscv/kernel/traps.c b/arch/riscv/kernel/traps.c index 055a937aca70a..82f42a55451eb 100644 --- a/arch/riscv/kernel/traps.c +++ b/arch/riscv/kernel/traps.c @@ -134,7 +134,7 @@ asmlinkage void do_trap_break(struct pt_regs *regs) break; case BUG_TRAP_TYPE_WARN: regs->sepc += get_break_insn_length(regs->sepc); - break; + return; case BUG_TRAP_TYPE_BUG: #endif /* CONFIG_GENERIC_BUG */ default: -- 2.20.1
[PATCH AUTOSEL 5.3 58/89] fs: ocfs2: fix a possible null-pointer dereference in ocfs2_write_end_nolock()
From: Jia-Ju Bai [ Upstream commit 583fee3e12df0e6f1f66f063b989d8e7fed0e65a ] In ocfs2_write_end_nolock(), there are an if statement on lines 1976, 2047 and 2058, to check whether handle is NULL: if (handle) When handle is NULL, it is used on line 2045: ocfs2_update_inode_fsync_trans(handle, inode, 1); oi->i_sync_tid = handle->h_transaction->t_tid; Thus, a possible null-pointer dereference may occur. To fix this bug, handle is checked before calling ocfs2_update_inode_fsync_trans(). This bug is found by a static analysis tool STCheck written by us. Link: http://lkml.kernel.org/r/20190726033705.32307-1-baijiaju1...@gmail.com Signed-off-by: Jia-Ju Bai Reviewed-by: Joseph Qi Cc: Mark Fasheh Cc: Joel Becker Cc: Junxiao Bi Cc: Changwei Ge Cc: Gang He Cc: Jun Piao Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin --- fs/ocfs2/aops.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/fs/ocfs2/aops.c b/fs/ocfs2/aops.c index 3e0a93e799ea1..9b827143a3504 100644 --- a/fs/ocfs2/aops.c +++ b/fs/ocfs2/aops.c @@ -2042,7 +2042,8 @@ int ocfs2_write_end_nolock(struct address_space *mapping, inode->i_mtime = inode->i_ctime = current_time(inode); di->i_mtime = di->i_ctime = cpu_to_le64(inode->i_mtime.tv_sec); di->i_mtime_nsec = di->i_ctime_nsec = cpu_to_le32(inode->i_mtime.tv_nsec); - ocfs2_update_inode_fsync_trans(handle, inode, 1); + if (handle) + ocfs2_update_inode_fsync_trans(handle, inode, 1); } if (handle) ocfs2_journal_dirty(handle, wc->w_di_bh); -- 2.20.1
[PATCH AUTOSEL 5.3 61/89] arm64: armv8_deprecated: Checking return value for memory allocation
From: Yunfeng Ye
[ Upstream commit 3e7c93bd04edfb0cae7dad1215544c9350254b8f ]
There are no return value checking when using kzalloc() and kcalloc() for
memory allocation. so add it.
Signed-off-by: Yunfeng Ye
Signed-off-by: Will Deacon
Signed-off-by: Sasha Levin
---
arch/arm64/kernel/armv8_deprecated.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm64/kernel/armv8_deprecated.c
b/arch/arm64/kernel/armv8_deprecated.c
index 2ec09debc2bb1..ca158be21f833 100644
--- a/arch/arm64/kernel/armv8_deprecated.c
+++ b/arch/arm64/kernel/armv8_deprecated.c
@@ -174,6 +174,9 @@ static void __init register_insn_emulation(struct
insn_emulation_ops *ops)
struct insn_emulation *insn;
insn = kzalloc(sizeof(*insn), GFP_KERNEL);
+ if (!insn)
+ return;
+
insn->ops = ops;
insn->min = INSN_UNDEF;
@@ -233,6 +236,8 @@ static void __init register_insn_emulation_sysctl(void)
insns_sysctl = kcalloc(nr_insn_emulated + 1, sizeof(*sysctl),
GFP_KERNEL);
+ if (!insns_sysctl)
+ return;
raw_spin_lock_irqsave(&insn_emulation_lock, flags);
list_for_each_entry(insn, &insn_emulation, node) {
--
2.20.1
[PATCH AUTOSEL 5.3 71/89] iio: accel: adxl372: Fix push to buffers lost samples
From: Stefan Popa
[ Upstream commit 62df81b74393079debf04961c48cb22268fc5fab ]
One in two sample sets was lost by multiplying fifo_set_size with
sizeof(u16). Also, the double number of available samples were pushed to
the iio buffers.
Signed-off-by: Stefan Popa
Fixes: f4f55ce38e5f ("iio:adxl372: Add FIFO and interrupts support")
Cc:
Signed-off-by: Jonathan Cameron
Signed-off-by: Sasha Levin
---
drivers/iio/accel/adxl372.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/iio/accel/adxl372.c b/drivers/iio/accel/adxl372.c
index 863fe61a371fb..fbad4b45fe42d 100644
--- a/drivers/iio/accel/adxl372.c
+++ b/drivers/iio/accel/adxl372.c
@@ -553,8 +553,7 @@ static irqreturn_t adxl372_trigger_handler(int irq, void
*p)
goto err;
/* Each sample is 2 bytes */
- for (i = 0; i < fifo_entries * sizeof(u16);
-i += st->fifo_set_size * sizeof(u16))
+ for (i = 0; i < fifo_entries; i += st->fifo_set_size)
iio_push_to_buffers(indio_dev, &st->fifo_buf[i]);
}
err:
--
2.20.1
[PATCH AUTOSEL 5.3 57/89] fs: ocfs2: fix possible null-pointer dereferences in ocfs2_xa_prepare_entry()
From: Jia-Ju Bai
[ Upstream commit 56e94ea132bb5c2c1d0b60a6aeb34dcb7d71a53d ]
In ocfs2_xa_prepare_entry(), there is an if statement on line 2136 to
check whether loc->xl_entry is NULL:
if (loc->xl_entry)
When loc->xl_entry is NULL, it is used on line 2158:
ocfs2_xa_add_entry(loc, name_hash);
loc->xl_entry->xe_name_hash = cpu_to_le32(name_hash);
loc->xl_entry->xe_name_offset = cpu_to_le16(loc->xl_size);
and line 2164:
ocfs2_xa_add_namevalue(loc, xi);
loc->xl_entry->xe_value_size = cpu_to_le64(xi->xi_value_len);
loc->xl_entry->xe_name_len = xi->xi_name_len;
Thus, possible null-pointer dereferences may occur.
To fix these bugs, if loc-xl_entry is NULL, ocfs2_xa_prepare_entry()
abnormally returns with -EINVAL.
These bugs are found by a static analysis tool STCheck written by us.
[a...@linux-foundation.org: remove now-unused ocfs2_xa_add_entry()]
Link: http://lkml.kernel.org/r/20190726101447.9153-1-baijiaju1...@gmail.com
Signed-off-by: Jia-Ju Bai
Reviewed-by: Joseph Qi
Cc: Mark Fasheh
Cc: Joel Becker
Cc: Junxiao Bi
Cc: Changwei Ge
Cc: Gang He
Cc: Jun Piao
Cc: Stephen Rothwell
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
Signed-off-by: Sasha Levin
---
fs/ocfs2/xattr.c | 56
1 file changed, 23 insertions(+), 33 deletions(-)
diff --git a/fs/ocfs2/xattr.c b/fs/ocfs2/xattr.c
index 90c830e3758e2..d8507972ee135 100644
--- a/fs/ocfs2/xattr.c
+++ b/fs/ocfs2/xattr.c
@@ -1490,18 +1490,6 @@ static int ocfs2_xa_check_space(struct ocfs2_xa_loc *loc,
return loc->xl_ops->xlo_check_space(loc, xi);
}
-static void ocfs2_xa_add_entry(struct ocfs2_xa_loc *loc, u32 name_hash)
-{
- loc->xl_ops->xlo_add_entry(loc, name_hash);
- loc->xl_entry->xe_name_hash = cpu_to_le32(name_hash);
- /*
-* We can't leave the new entry's xe_name_offset at zero or
-* add_namevalue() will go nuts. We set it to the size of our
-* storage so that it can never be less than any other entry.
-*/
- loc->xl_entry->xe_name_offset = cpu_to_le16(loc->xl_size);
-}
-
static void ocfs2_xa_add_namevalue(struct ocfs2_xa_loc *loc,
struct ocfs2_xattr_info *xi)
{
@@ -2133,29 +2121,31 @@ static int ocfs2_xa_prepare_entry(struct ocfs2_xa_loc
*loc,
if (rc)
goto out;
- if (loc->xl_entry) {
- if (ocfs2_xa_can_reuse_entry(loc, xi)) {
- orig_value_size = loc->xl_entry->xe_value_size;
- rc = ocfs2_xa_reuse_entry(loc, xi, ctxt);
- if (rc)
- goto out;
- goto alloc_value;
- }
+ if (!loc->xl_entry) {
+ rc = -EINVAL;
+ goto out;
+ }
- if (!ocfs2_xattr_is_local(loc->xl_entry)) {
- orig_clusters = ocfs2_xa_value_clusters(loc);
- rc = ocfs2_xa_value_truncate(loc, 0, ctxt);
- if (rc) {
- mlog_errno(rc);
- ocfs2_xa_cleanup_value_truncate(loc,
- "overwriting",
- orig_clusters);
- goto out;
- }
+ if (ocfs2_xa_can_reuse_entry(loc, xi)) {
+ orig_value_size = loc->xl_entry->xe_value_size;
+ rc = ocfs2_xa_reuse_entry(loc, xi, ctxt);
+ if (rc)
+ goto out;
+ goto alloc_value;
+ }
+
+ if (!ocfs2_xattr_is_local(loc->xl_entry)) {
+ orig_clusters = ocfs2_xa_value_clusters(loc);
+ rc = ocfs2_xa_value_truncate(loc, 0, ctxt);
+ if (rc) {
+ mlog_errno(rc);
+ ocfs2_xa_cleanup_value_truncate(loc,
+ "overwriting",
+ orig_clusters);
+ goto out;
}
- ocfs2_xa_wipe_namevalue(loc);
- } else
- ocfs2_xa_add_entry(loc, name_hash);
+ }
+ ocfs2_xa_wipe_namevalue(loc);
/*
* If we get here, we have a blank entry. Fill it. We grow our
--
2.20.1
[PATCH AUTOSEL 5.3 73/89] iio: imu: adis16400: release allocated memory on failure
From: Navid Emamdoost
[ Upstream commit ab612b1daf415b62c58e130cb3d0f30b255a14d0 ]
In adis_update_scan_mode, if allocation for adis->buffer fails,
previously allocated adis->xfer needs to be released.
Signed-off-by: Navid Emamdoost
Reviewed-by: Alexandru Ardelean
Signed-off-by: Jonathan Cameron
Signed-off-by: Sasha Levin
---
drivers/iio/imu/adis_buffer.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/iio/imu/adis_buffer.c b/drivers/iio/imu/adis_buffer.c
index 9ac8356d9a954..f446ff4978091 100644
--- a/drivers/iio/imu/adis_buffer.c
+++ b/drivers/iio/imu/adis_buffer.c
@@ -78,8 +78,11 @@ int adis_update_scan_mode(struct iio_dev *indio_dev,
return -ENOMEM;
adis->buffer = kcalloc(indio_dev->scan_bytes, 2, GFP_KERNEL);
- if (!adis->buffer)
+ if (!adis->buffer) {
+ kfree(adis->xfer);
+ adis->xfer = NULL;
return -ENOMEM;
+ }
rx = adis->buffer;
tx = rx + scan_count;
--
2.20.1
[PATCH AUTOSEL 5.3 70/89] iio: accel: adxl372: Fix/remove limitation for FIFO samples
From: Stefan Popa
[ Upstream commit d202ce4787e446556c6b9d01f84734c3f8174ba3 ]
Currently, the driver sets the FIFO_SAMPLES register with the number of
sample sets (maximum of 170 for 3 axis data, 256 for 2-axis and 512 for
single axis). However, the FIFO_SAMPLES register should store the number
of samples, regardless of how the FIFO format is configured.
Signed-off-by: Stefan Popa
Fixes: f4f55ce38e5f ("iio:adxl372: Add FIFO and interrupts support")
Cc:
Signed-off-by: Jonathan Cameron
Signed-off-by: Sasha Levin
---
drivers/iio/accel/adxl372.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers/iio/accel/adxl372.c b/drivers/iio/accel/adxl372.c
index 055227cb3d43c..863fe61a371fb 100644
--- a/drivers/iio/accel/adxl372.c
+++ b/drivers/iio/accel/adxl372.c
@@ -474,12 +474,17 @@ static int adxl372_configure_fifo(struct adxl372_state
*st)
if (ret < 0)
return ret;
- fifo_samples = st->watermark & 0xFF;
+ /*
+* watermark stores the number of sets; we need to write the FIFO
+* registers with the number of samples
+*/
+ fifo_samples = (st->watermark * st->fifo_set_size);
fifo_ctl = ADXL372_FIFO_CTL_FORMAT_MODE(st->fifo_format) |
ADXL372_FIFO_CTL_MODE_MODE(st->fifo_mode) |
- ADXL372_FIFO_CTL_SAMPLES_MODE(st->watermark);
+ ADXL372_FIFO_CTL_SAMPLES_MODE(fifo_samples);
- ret = regmap_write(st->regmap, ADXL372_FIFO_SAMPLES, fifo_samples);
+ ret = regmap_write(st->regmap,
+ ADXL372_FIFO_SAMPLES, fifo_samples & 0xFF);
if (ret < 0)
return ret;
--
2.20.1
