* Re: [PATCH v2] blkdev: Replace blksize_bits() with ilog2()
From: Matthew Wilcox @ 2020-05-29 20:27 UTC (permalink / raw)
To: Kaitao Cheng
Cc: axboe, hch, sth, viro, clm, jaegeuk, hch, mark, dhowells, balbi,
damien.lemoal, bvanassche, ming.lei, martin.petersen, satyat,
chaitanya.kulkarni, houtao1, asml.silence, ajay.joshi,
linux-kernel, songmuchun, hoeppner, heiko.carstens, gor,
borntraeger, linux-s390, sagi, linux-nvme, gregkh, linux-usb,
josef, dsterba, linux-btrfs, chao, linux-f2fs-devel, darrick.wong,
linux-xfs, linux-fsdevel, jlbec, joseph.qi, ocfs2-devel,
deepa.kernel
In-Reply-To: <20200529141100.37519-1-pilgrimtao@gmail.com>
On Fri, May 29, 2020 at 10:11:00PM +0800, Kaitao Cheng wrote:
> There is a function named ilog2() exist which can replace blksize.
> The generated code will be shorter and more efficient on some
> architecture, such as arm64. And ilog2() can be optimized according
> to different architecture.
We'd get the same benefit from a smaller patch with just:
--- a/include/linux/blkdev.h
+++ b/include/linux/blkdev.h
@@ -1502,15 +1502,9 @@ static inline int blk_rq_aligned(struct request_queue *q, unsigned long addr,
return !(addr & alignment) && !(len & alignment);
}
-/* assumes size > 256 */
static inline unsigned int blksize_bits(unsigned int size)
{
- unsigned int bits = 8;
- do {
- bits++;
- size >>= 1;
- } while (size > 256);
- return bits;
+ return ilog2(size);
}
static inline unsigned int block_size(struct block_device *bdev)
^ permalink raw reply
* [Ocfs2-devel] [PATCH v2] blkdev: Replace blksize_bits() with ilog2()
From: Matthew Wilcox @ 2020-05-29 20:27 UTC (permalink / raw)
To: Kaitao Cheng
Cc: axboe, hch, sth, viro, clm, jaegeuk, hch, mark, dhowells, balbi,
damien.lemoal, bvanassche, ming.lei, martin.petersen, satyat,
chaitanya.kulkarni, houtao1, asml.silence, ajay.joshi,
linux-kernel, songmuchun, hoeppner, heiko.carstens, gor,
borntraeger, linux-s390, sagi, linux-nvme, gregkh, linux-usb,
josef, dsterba, linux-btrfs, chao, linux-f2fs-devel, darrick.wong,
linux-xfs, linux-fsdevel, jlbec, joseph.qi, ocfs2-devel,
deepa.kernel
In-Reply-To: <20200529141100.37519-1-pilgrimtao@gmail.com>
On Fri, May 29, 2020 at 10:11:00PM +0800, Kaitao Cheng wrote:
> There is a function named ilog2() exist which can replace blksize.
> The generated code will be shorter and more efficient on some
> architecture, such as arm64. And ilog2() can be optimized according
> to different architecture.
We'd get the same benefit from a smaller patch with just:
--- a/include/linux/blkdev.h
+++ b/include/linux/blkdev.h
@@ -1502,15 +1502,9 @@ static inline int blk_rq_aligned(struct request_queue *q, unsigned long addr,
return !(addr & alignment) && !(len & alignment);
}
-/* assumes size > 256 */
static inline unsigned int blksize_bits(unsigned int size)
{
- unsigned int bits = 8;
- do {
- bits++;
- size >>= 1;
- } while (size > 256);
- return bits;
+ return ilog2(size);
}
static inline unsigned int block_size(struct block_device *bdev)
^ permalink raw reply
* Re: [PATCH] drm/selftests/mm: reduce per-function stack usage
From: Chris Wilson @ 2020-05-29 20:26 UTC (permalink / raw)
To: Christian König, Arnd Bergmann, Daniel Vetter, David Airlie,
Nirmoy Das
Cc: linux-kernel, dri-devel, kbuild test robot, Arnd Bergmann,
Tvrtko Ursulin
In-Reply-To: <20200529201534.474853-1-arnd@arndb.de>
Quoting Arnd Bergmann (2020-05-29 21:15:26)
> The check_reserve_boundaries() function has a large array on the stack,
> over 500 bytes. It gets inlined into __igt_reserve, which has multiple
> other large structures as well but stayed just under the stack size
> warning limit of 1024 bytes until one more member got added to struct
> drm_mm_node, causing a warning:
>
> drivers/gpu/drm/selftests/test-drm_mm.c:371:12: error:
> stack frame size of 1032 bytes in function '__igt_reserve' [-Werror,-Wframe-larger-than=]
>
> As far as I can tell, this is not nice but will not be called from
> a context that is already low for the kernel stack, so just annotate
> the inner function as noinline_for_stack to ensure that each function
> by itself stays under the warning limit.
>
> Fixes: 0cdea4455acd ("drm/mm: optimize rb_hole_addr rbtree search")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> drivers/gpu/drm/selftests/test-drm_mm.c | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/selftests/test-drm_mm.c b/drivers/gpu/drm/selftests/test-drm_mm.c
> index 9aabe82dcd3a..30108c330db8 100644
> --- a/drivers/gpu/drm/selftests/test-drm_mm.c
> +++ b/drivers/gpu/drm/selftests/test-drm_mm.c
> @@ -323,9 +323,8 @@ static bool expect_reserve_fail(struct drm_mm *mm, struct drm_mm_node *node)
> return false;
> }
>
> -static bool check_reserve_boundaries(struct drm_mm *mm,
> - unsigned int count,
> - u64 size)
> +static noinline_for_stack bool
> +check_reserve_boundaries(struct drm_mm *mm, unsigned int count, u64 size)
> {
> const struct boundary {
It's this const [] right? Hmm, if we felt adventurous that could be a
small set of multiplication factors (0, -1, 1, count, count+1, ...) and
made static.
-Chris
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH 1/9] staging: media: atomisp: fix incorrect NULL pointer check
From: Arnd Bergmann @ 2020-05-29 20:23 UTC (permalink / raw)
To: Nick Desaulniers
Cc: Mauro Carvalho Chehab, Sakari Ailus, Linux Media Mailing List,
driverdevel, LKML, clang-built-linux, Nathan Chancellor
In-Reply-To: <CAKwvOdnND7XFgr7W9PvZAikJB1nKxB4K5N-oP0YrBT74oX_C9g@mail.gmail.com>
On Fri, May 29, 2020 at 10:04 PM 'Nick Desaulniers' via Clang Built
Linux <clang-built-linux@googlegroups.com> wrote:
>
> See also Nathan's 7 patch series.
> https://lore.kernel.org/lkml/20200527071150.3381228-1-natechancellor@gmail.com/
>
> Might be some overlap between series?
>
Probably. I really should have checked when I saw the number of warnings.
At least this gives Mauro a chance to double-check the changes and see if
Nathan and I came to different conclusions on any of them.
Arnd
^ permalink raw reply
* Re: [PATCH 3/4] selftests/lkdtm: Reset WARN_ONCE to avoid false negatives
From: Shuah Khan @ 2020-05-29 20:22 UTC (permalink / raw)
To: Kees Cook, Greg Kroah-Hartman
Cc: Prasad Sodagudi, Sami Tolvanen, Amit Daniel Kachhap,
linux-kselftest, clang-built-linux, linux-kernel, Shuah Khan
In-Reply-To: <20200529200347.2464284-4-keescook@chromium.org>
On 5/29/20 2:03 PM, Kees Cook wrote:
> Since we expect to see warnings every time for many tests, just reset
> the WARN_ONCE flags each time the script runs.
>
> Signed-off-by: Kees Cook <keescook@chromium.org>
> ---
> tools/testing/selftests/lkdtm/run.sh | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/tools/testing/selftests/lkdtm/run.sh b/tools/testing/selftests/lkdtm/run.sh
> index ee64ff8df8f4..8383eb89d88a 100755
> --- a/tools/testing/selftests/lkdtm/run.sh
> +++ b/tools/testing/selftests/lkdtm/run.sh
> @@ -8,6 +8,7 @@
> #
> set -e
> TRIGGER=/sys/kernel/debug/provoke-crash/DIRECT
> +CLEAR_ONCE=/sys/kernel/debug/clear_warn_once
> KSELFTEST_SKIP_TEST=4
>
> # Verify we have LKDTM available in the kernel.
> @@ -67,6 +68,11 @@ cleanup() {
> }
> trap cleanup EXIT
>
> +# Reset WARN_ONCE counters so we trip it each time this runs.
> +if [ -w $CLEAR_ONCE ] ; then
> + echo 1 > $CLEAR_ONCE
> +fi
> +
> # Save existing dmesg so we can detect new content below
> dmesg > "$DMESG"
>
>
Acked-by: Shuah Khan <skhan@linuxfoundation.org>
thanks,
-- Shuah
^ permalink raw reply
* Re: Lost PCIe PME after a914ff2d78ce ("PCI/ASPM: Don't select CONFIG_PCIEASPM by default")
From: Bjorn Helgaas @ 2020-05-29 20:21 UTC (permalink / raw)
To: Heiner Kallweit
Cc: Rafael J. Wysocki, Bjorn Helgaas, linux-pci@vger.kernel.org,
linux-kernel, linux-acpi, Matthew Garrett
In-Reply-To: <bdc33be8-1db6-b147-cbc4-90fa0dc3d999@gmail.com>
[+cc Matthew]
On Fri, May 29, 2020 at 10:09:08PM +0200, Heiner Kallweit wrote:
> On 29.05.2020 21:40, Heiner Kallweit wrote:
> > On 29.05.2020 21:21, Bjorn Helgaas wrote:
> >> On Fri, May 29, 2020 at 08:50:46PM +0200, Heiner Kallweit wrote:
> >>> On 28.05.2020 23:44, Heiner Kallweit wrote:
> >>>> For whatever reason with this change (and losing ASPM control) I also
> >>>> loose the PCIe PME interrupts. This prevents my network card from
> >>>> resuming from runtime-suspend.
> >>>> Reverting the change brings back ASPM control and the PCIe PME irq's.
> >>>>
> >>>> Affected system is a Zotac MiniPC with a N3450 CPU:
> >>>> PCI bridge: Intel Corporation Celeron N3350/Pentium N4200/Atom E3900 Series PCI Express Port A #1 (rev fb)
> >>>>
> >>> I checked a little bit further and w/o ASPM control the root ports
> >>> don't have the PME service bit set in their capabilities.
> >>> Not sure whether this is a chipset bug or whether there's a better
> >>> explanation. However more chipsets may have such a behavior.
> >>
> >> Hmm. Is the difference simply changing the PCIEASPM config symbol, or
> >> are you booting with command-line arguments like "pcie_aspm=off"?
> >>
> > Only difference is the config symbol. My command line is plain and simple:
> >
> > Command line: initrd=\intel-ucode.img initrd=\initramfs-linux.img root=/dev/sda2 rw
> >
> >> What's the specific PME bit that changes in the root ports? Can you
> >> collect the "sudo lspci -vvxxxx" output with and without ASPM?
> >>
> >> The capability bits are generally read-only as far as the PCI spec is
> >> concerned, but devices have implementation-specific knobs that the
> >> BIOS may use to change things. Without CONFIG_PCIEASPM, Linux will
> >> not request control of LTR, and that could cause the BIOS to change
> >> something. You should be able to see the LTR control difference in
> >> the dmesg logging about _OSC.
> >>
> >>> W/o the "default y" for ASPM control we also have the situation now
> >>> that the config option description says "When in doubt, say Y."
> >>> but it takes the EXPERT mode to enable it. This seems to be a little
> >>> bit inconsistent.
> >>
> >> We should probably remove the "if EXPERT" from the PCIEASPM kconfig.
> >> But I would expect PME to work correctly regardless of PCIEASPM, so
> >> removing "if EXPERT" doesn't solve the underlying problem.
> >>
> >> Rafael, does this ring any bells for you? I don't remember a
> >> connection between PME and ASPM, but maybe there is one.
> >>
> >>> To cut a long story short:
> >>> At least on some systems this change has unwanted side effects.
> >
> > lspci output w/ and w/o ASPM is attached incl. a diff.
> > Here comes the _OSC difference.
> >
> > w/o ASPM
> >
> > [ 0.386063] acpi PNP0A08:00: _OSC: OS supports [ExtendedConfig Segments MSI HPX-Type3]
> > [ 0.386918] acpi PNP0A08:00: _OSC: not requesting OS control; OS requires [ExtendedConfig ASPM ClockPM MSI]
> >
> > w/ ASPM
> > [ 0.388141] acpi PNP0A08:00: _OSC: OS supports [ExtendedConfig ASPM ClockPM Segments MSI HPX-Type3]
> > [ 0.393648] acpi PNP0A08:00: _OSC: OS now controls [PME AER PCIeCapability LTR]
> >
> > It's at least interesting that w/o ASPM OS doesn't control PME and AER.
> >
>
> This was the right entry point, also w/o ASPM control OS states to ACPI that it
> needs ASPM and ClockPM. The following patch fixes the PME issue for me.
> See also the _OSC part below.
>
>
> diff --git a/drivers/acpi/pci_root.c b/drivers/acpi/pci_root.c
> index 9e235c1a7..8df1fa728 100644
> --- a/drivers/acpi/pci_root.c
> +++ b/drivers/acpi/pci_root.c
> @@ -38,10 +38,15 @@ static int acpi_pci_root_scan_dependent(struct acpi_device *adev)
> return 0;
> }
>
> +#ifdef CONFIG_PCIEASPM
> #define ACPI_PCIE_REQ_SUPPORT (OSC_PCI_EXT_CONFIG_SUPPORT \
> | OSC_PCI_ASPM_SUPPORT \
> | OSC_PCI_CLOCK_PM_SUPPORT \
> | OSC_PCI_MSI_SUPPORT)
> +#else
> +#define ACPI_PCIE_REQ_SUPPORT (OSC_PCI_EXT_CONFIG_SUPPORT \
> + | OSC_PCI_MSI_SUPPORT)
> +#endif
Yeah, that makes sense. I can't remember the details, but I'm pretty
sure there's a reason why we ask for the whole set of things. Seems
like it solved some problem. I think Matthew Garrett might have been
involved in that.
^ permalink raw reply
* + swap-reduce-lock-contention-on-swap-cache-from-swap-slots-allocation-v4.patch added to -mm tree
From: akpm @ 2020-05-29 20:21 UTC (permalink / raw)
To: daniel.m.jordan, hughd, mhocko, minchan, mm-commits, tim.c.chen,
ying.huang
The patch titled
Subject: swap-reduce-lock-contention-on-swap-cache-from-swap-slots-allocation-v4
has been added to the -mm tree. Its filename is
swap-reduce-lock-contention-on-swap-cache-from-swap-slots-allocation-v4.patch
This patch should soon appear at
http://ozlabs.org/~akpm/mmots/broken-out/swap-reduce-lock-contention-on-swap-cache-from-swap-slots-allocation-v4.patch
and later at
http://ozlabs.org/~akpm/mmotm/broken-out/swap-reduce-lock-contention-on-swap-cache-from-swap-slots-allocation-v4.patch
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/process/submit-checklist.rst when testing your code ***
The -mm tree is included into linux-next and is updated
there every 3-4 working days
------------------------------------------------------
From: Huang Ying <ying.huang@intel.com>
Subject: swap-reduce-lock-contention-on-swap-cache-from-swap-slots-allocation-v4
- Fix wrong ALIGN() usage with ALIGN_DOWN(). Thanks Daniel's comments!
- Add some comments. Thanks Daniel's comments!
Link: http://lkml.kernel.org/r/20200529010840.928819-1-ying.huang@intel.com
Signed-off-by: "Huang, Ying" <ying.huang@intel.com>
Reviewed-by: Daniel Jordan <daniel.m.jordan@oracle.com>
Cc: Michal Hocko <mhocko@suse.com>
Cc: Minchan Kim <minchan@kernel.org>
Cc: Tim Chen <tim.c.chen@linux.intel.com>
Cc: Hugh Dickins <hughd@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
mm/swapfile.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
--- a/mm/swapfile.c~swap-reduce-lock-contention-on-swap-cache-from-swap-slots-allocation-v4
+++ a/mm/swapfile.c
@@ -613,7 +613,8 @@ new_cluster:
} else if (!cluster_list_empty(&si->discard_clusters)) {
/*
* we don't have free cluster but have some clusters in
- * discarding, do discard now and reclaim them
+ * discarding, do discard now and reclaim them, then
+ * reread cluster_next_cpu since we dropped si->lock
*/
swap_do_scheduled_discard(si);
*scan_base = this_cpu_read(*si->cluster_next_cpu);
@@ -745,7 +746,7 @@ static void set_cluster_next(struct swap
return;
next = si->lowest_bit +
prandom_u32_max(si->highest_bit - si->lowest_bit + 1);
- next = ALIGN(next, SWAP_ADDRESS_SPACE_PAGES);
+ next = ALIGN_DOWN(next, SWAP_ADDRESS_SPACE_PAGES);
next = max_t(unsigned int, next, si->lowest_bit);
}
this_cpu_write(*si->cluster_next_cpu, next);
_
Patches currently in -mm which might be from ying.huang@intel.com are
swap-try-to-scan-more-free-slots-even-when-fragmented.patch
mm-swap-use-prandom_u32_max.patch
swap-reduce-lock-contention-on-swap-cache-from-swap-slots-allocation.patch
swap-reduce-lock-contention-on-swap-cache-from-swap-slots-allocation-v3.patch
swap-reduce-lock-contention-on-swap-cache-from-swap-slots-allocation-v4.patch
proc-pid-smaps-add-pmd-migration-entry-parsing.patch
^ permalink raw reply
* [MPTCP] Re: Crashers on netnext with apache-benchmark
From: Christoph Paasch @ 2020-05-29 20:19 UTC (permalink / raw)
To: mptcp
[-- Attachment #1: Type: text/plain, Size: 5322 bytes --]
On 05/29/20 - 13:11, Christoph Paasch wrote:
> On 05/29/20 - 22:04, Paolo Abeni wrote:
> > On Tue, 2020-05-26 at 17:28 -0700, Christoph Paasch wrote:
> > > And another one:
> > >
> > > [ 62.586401] ==================================================================
> > > [ 62.588813] BUG: KASAN: use-after-free in inet_twsk_bind_unhash+0x5f/0xe0
> > > [ 62.589975] Write of size 8 at addr ffff88810f155a20 by task ksoftirqd/2/21
> > > [ 62.591194]
> > > [ 62.591485] CPU: 2 PID: 21 Comm: ksoftirqd/2 Kdump: loaded Not tainted 5.7.0-rc6.mptcp #36
> > > [ 62.593067] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org 04/01/2014
> > > [ 62.595268] Call Trace:
> > > [ 62.595775] dump_stack+0x76/0xa0
> > > [ 62.596448] print_address_description.constprop.0+0x3a/0x60
> > > [ 62.600581] __kasan_report.cold+0x20/0x3b
> > > [ 62.602968] kasan_report+0x38/0x50
> > > [ 62.603561] inet_twsk_bind_unhash+0x5f/0xe0
> > > [ 62.604282] inet_twsk_kill+0x195/0x200
> > > [ 62.604945] inet_twsk_deschedule_put+0x25/0x30
> > > [ 62.605731] tcp_v4_rcv+0xa79/0x15e0
> > > [ 62.607139] ip_protocol_deliver_rcu+0x37/0x270
> > > [ 62.607980] ip_local_deliver_finish+0xb0/0xd0
> > > [ 62.608758] ip_local_deliver+0x1c9/0x1e0
> > > [ 62.611162] ip_sublist_rcv_finish+0x84/0xa0
> > > [ 62.611894] ip_sublist_rcv+0x22c/0x320
> > > [ 62.616143] ip_list_rcv+0x1e4/0x225
> > > [ 62.619427] __netif_receive_skb_list_core+0x439/0x460
> > > [ 62.622771] netif_receive_skb_list_internal+0x3ea/0x570
> > > [ 62.625320] gro_normal_list.part.0+0x14/0x50
> > > [ 62.626088] napi_gro_receive+0x6a/0xb0
> > > [ 62.626787] receive_buf+0x371/0x1d50
> > > [ 62.632092] virtnet_poll+0x2be/0x5b0
> > > [ 62.634099] net_rx_action+0x1ec/0x4c0
> > > [ 62.636132] __do_softirq+0xfc/0x29c
> > > [ 62.638180] run_ksoftirqd+0x15/0x30
> > > [ 62.638787] smpboot_thread_fn+0x1fc/0x380
> > > [ 62.642009] kthread+0x1f1/0x210
> > > [ 62.643478] ret_from_fork+0x35/0x40
> > > [ 62.644094]
> > > [ 62.644371] Allocated by task 1355:
> > > [ 62.644980] save_stack+0x1b/0x40
> > > [ 62.645539] __kasan_kmalloc.constprop.0+0xc2/0xd0
> > > [ 62.646347] kmem_cache_alloc+0xb8/0x190
> > > [ 62.647006] getname_flags+0x6b/0x2b0
> > > [ 62.647627] user_path_at_empty+0x1b/0x40
> > > [ 62.648306] vfs_statx+0xba/0x140
> > > [ 62.648875] __do_sys_newstat+0x8c/0xf0
> > > [ 62.649518] do_syscall_64+0xbc/0x790
> > > [ 62.650199] entry_SYSCALL_64_after_hwframe+0x44/0xa9
> > > [ 62.651091]
> > > [ 62.651360] Freed by task 1355:
> > > [ 62.651903] save_stack+0x1b/0x40
> > > [ 62.652460] __kasan_slab_free+0x12f/0x180
> > > [ 62.653147] kmem_cache_free+0x87/0x240
> > > [ 62.653795] filename_lookup+0x183/0x250
> > > [ 62.654447] vfs_statx+0xba/0x140
> > > [ 62.655001] __do_sys_newstat+0x8c/0xf0
> > > [ 62.655640] do_syscall_64+0xbc/0x790
> > > [ 62.656246] entry_SYSCALL_64_after_hwframe+0x44/0xa9
> > > [ 62.657089]
> > > [ 62.657351] The buggy address belongs to the object at ffff88810f155500
> > > which belongs to the cache names_cache of size 4096
> > > [ 62.659420] The buggy address is located 1312 bytes inside of
> > > 4096-byte region [ffff88810f155500, ffff88810f156500)
> > > [ 62.661358] The buggy address belongs to the page:
> > > [ 62.662175] page:ffffea00043c5400 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 head:ffffea00043c5400 order:3 compound_mapcount:0 compound_pincount:0
> > > [ 62.664523] flags: 0x8000000000010200(slab|head)
> > > [ 62.665342] raw: 8000000000010200 0000000000000000 0000000400000001 ffff88811ac772c0
> > > [ 62.666713] raw: 0000000000000000 0000000000070007 00000001ffffffff 0000000000000000
> > > [ 62.667984] page dumped because: kasan: bad access detected
> > > [ 62.668904]
> > > [ 62.669171] Memory state around the buggy address:
> > > [ 62.669975] ffff88810f155900: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> > > [ 62.671163] ffff88810f155980: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> > > [ 62.672363] >ffff88810f155a00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> > > [ 62.673559] ^
> > > [ 62.674349] ffff88810f155a80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> > > [ 62.675531] ffff88810f155b00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> > > [ 62.676723] ==================================================================
> >
> > Could you please try booting with "slab_nomerge" on the kernel command
> > line?
> >
> > Possibly kasan could track better the really relevant UAF cycle that
> > way.
> >
> > Thanks!
>
> Sure, will try that!
>
> Some more info from my crash-analysis: the next-pointer in the bindhash-table
> is pointing to free'd memory. That free'd memory seems to be a tcp_sock in state CLOSED.
>
>
> So, I guess the bind_node is not unlinked when a socket is being free'd. I'm
> adding debugging code to see if that is true.
I also just hit a "bad option size" again :-/
server login: [ 40.845318] MPTCP: MP_JOIN bad option size
Christoph
^ permalink raw reply
* Re: [PATCH 1/2] perf build: Group the NO_SYSCALL_TABLE logic
From: Arnaldo Carvalho de Melo @ 2020-05-29 20:19 UTC (permalink / raw)
To: Jiri Olsa, Namhyung Kim
Cc: Ingo Molnar, Thomas Gleixner, Clark Williams, linux-kernel,
linux-perf-users, Arnaldo Carvalho de Melo, Adrian Hunter
In-Reply-To: <20200529155552.463-2-acme@kernel.org>
Em Fri, May 29, 2020 at 12:55:51PM -0300, Arnaldo Carvalho de Melo escreveu:
> From: Arnaldo Carvalho de Melo <acme@redhat.com>
>
> To help in allowing to disable it from the make command line.
>
> Cc: Adrian Hunter <adrian.hunter@intel.com>
> Cc: Jiri Olsa <jolsa@kernel.org>
> Cc: Namhyung Kim <namhyung@kernel.org>
> Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
> ---
> tools/perf/Makefile.config | 23 +++++++++++++++--------
> 1 file changed, 15 insertions(+), 8 deletions(-)
>
> diff --git a/tools/perf/Makefile.config b/tools/perf/Makefile.config
> index ae325f79e598..93fb7510a9a9 100644
> --- a/tools/perf/Makefile.config
> +++ b/tools/perf/Makefile.config
> @@ -23,12 +23,26 @@ include $(srctree)/tools/scripts/Makefile.arch
> $(call detected_var,SRCARCH)
>
> NO_PERF_REGS := 1
> +
> NO_SYSCALL_TABLE := 1
>
> +ifeq ($(SRCARCH),x86)
> + ifeq (${IS_64_BIT}, 1)
> + NO_SYSCALL_TABLE := 0
> + endif
> +else
> + ifneq ($(SRCARCH),$(filter $(SRCARCH),powerpc arm64 s390))
The above should've been a ifeq, to see if SRCARCH is one of those,
detected in the cross build tests, fixed.
- Arnaldo
> + NO_SYSCALL_TABLE := 0
> + endif
> +endif
> +
> +ifneq ($(NO_SYSCALL_TABLE),1)
> + CFLAGS += -DHAVE_SYSCALL_TABLE_SUPPORT
> +endif
> +
> # Additional ARCH settings for ppc
> ifeq ($(SRCARCH),powerpc)
> NO_PERF_REGS := 0
> - NO_SYSCALL_TABLE := 0
> CFLAGS += -I$(OUTPUT)arch/powerpc/include/generated
> LIBUNWIND_LIBS := -lunwind -lunwind-ppc64
> endif
> @@ -37,7 +51,6 @@ endif
> ifeq ($(SRCARCH),x86)
> $(call detected,CONFIG_X86)
> ifeq (${IS_64_BIT}, 1)
> - NO_SYSCALL_TABLE := 0
> CFLAGS += -DHAVE_ARCH_X86_64_SUPPORT -I$(OUTPUT)arch/x86/include/generated
> ARCH_INCLUDE = ../../arch/x86/lib/memcpy_64.S ../../arch/x86/lib/memset_64.S
> LIBUNWIND_LIBS = -lunwind-x86_64 -lunwind -llzma
> @@ -55,7 +68,6 @@ endif
>
> ifeq ($(SRCARCH),arm64)
> NO_PERF_REGS := 0
> - NO_SYSCALL_TABLE := 0
> CFLAGS += -I$(OUTPUT)arch/arm64/include/generated
> LIBUNWIND_LIBS = -lunwind -lunwind-aarch64
> endif
> @@ -70,7 +82,6 @@ endif
>
> ifeq ($(ARCH),s390)
> NO_PERF_REGS := 0
> - NO_SYSCALL_TABLE := 0
> CFLAGS += -fPIC -I$(OUTPUT)arch/s390/include/generated
> endif
>
> @@ -78,10 +89,6 @@ ifeq ($(NO_PERF_REGS),0)
> $(call detected,CONFIG_PERF_REGS)
> endif
>
> -ifneq ($(NO_SYSCALL_TABLE),1)
> - CFLAGS += -DHAVE_SYSCALL_TABLE_SUPPORT
> -endif
> -
> # So far there's only x86 and arm libdw unwind support merged in perf.
> # Disable it on all other architectures in case libdw unwind
> # support is detected in system. Add supported architectures
> --
> 2.25.3
>
--
- Arnaldo
^ permalink raw reply
* Re: [PATCH linux-rcu] docs/litmus-tests: add BPF ringbuf MPSC litmus tests
From: Andrii Nakryiko @ 2020-05-29 20:18 UTC (permalink / raw)
To: Joel Fernandes
Cc: Andrii Nakryiko, bpf, Networking, Paul E . McKenney, Alan Stern,
parri.andrea, will, Peter Ziljstra, Boqun Feng, npiggin, dhowells,
j.alglave, luc.maranget, Akira Yokosawa, dlustig, open list,
linux-arch, Kernel Team
In-Reply-To: <20200529173432.GC196085@google.com>
On Fri, May 29, 2020 at 10:34 AM Joel Fernandes <joel@joelfernandes.org> wrote:
>
> Hi Andrii,
>
> On Thu, May 28, 2020 at 10:50:30PM -0700, Andrii Nakryiko wrote:
> > > [...]
> > > > diff --git a/Documentation/litmus-tests/bpf-rb/bpf-rb+1p1c+bounded.litmus b/Documentation/litmus-tests/bpf-rb/bpf-rb+1p1c+bounded.litmus
> > > > new file mode 100644
> > > > index 000000000000..558f054fb0b4
> > > > --- /dev/null
> > > > +++ b/Documentation/litmus-tests/bpf-rb/bpf-rb+1p1c+bounded.litmus
> > > > @@ -0,0 +1,91 @@
> > > > +C bpf-rb+1p1c+bounded
> > > > +
> > > > +(*
> > > > + * Result: Always
> > > > + *
> > > > + * This litmus test validates BPF ring buffer implementation under the
> > > > + * following assumptions:
> > > > + * - 1 producer;
> > > > + * - 1 consumer;
> > > > + * - ring buffer has capacity for only 1 record.
> > > > + *
> > > > + * Expectations:
> > > > + * - 1 record pushed into ring buffer;
> > > > + * - 0 or 1 element is consumed.
> > > > + * - no failures.
> > > > + *)
> > > > +
> > > > +{
> > > > + atomic_t dropped;
> > > > +}
> > > > +
> > > > +P0(int *lenFail, int *len1, int *cx, int *px)
> > > > +{
> > > > + int *rLenPtr;
> > > > + int rLen;
> > > > + int rPx;
> > > > + int rCx;
> > > > + int rFail;
> > > > +
> > > > + rFail = 0;
> > > > +
> > > > + rCx = smp_load_acquire(cx);
> > > > + rPx = smp_load_acquire(px);
> > >
> > > Is it possible for you to put some more comments around which ACQUIRE is
> > > paired with which RELEASE? And, in general more comments around the reason
> > > for a certain memory barrier and what pairs with what. In the kernel sources,
> > > the barriers needs a comment anyway.
>
> This was the comment earlier that was missed.
Right, I'll follow up extending kernel implementation comments, and
will add some more to litmus tests.
>
> > > > + if (rCx < rPx) {
> > > > + if (rCx == 0) {
> > > > + rLenPtr = len1;
> > > > + } else {
> > > > + rLenPtr = lenFail;
> > > > + rFail = 1;
> > > > + }
> > > > +
> > > > + rLen = smp_load_acquire(rLenPtr);
> > > > + if (rLen == 0) {
> > > > + rFail = 1;
> > > > + } else if (rLen == 1) {
> > > > + rCx = rCx + 1;
> > > > + smp_store_release(cx, rCx);
> > > > + }
> > > > + }
> > > > +}
> > > > +
> > > > +P1(int *lenFail, int *len1, spinlock_t *rb_lock, int *px, int *cx, atomic_t *dropped)
> > > > +{
> > > > + int rPx;
> > > > + int rCx;
> > > > + int rFail;
> > > > + int *rLenPtr;
> > > > +
> > > > + rFail = 0;
> > > > +
> > > > + rCx = smp_load_acquire(cx);
> > > > + spin_lock(rb_lock);
> > > > +
> > > > + rPx = *px;
> > > > + if (rPx - rCx >= 1) {
> > > > + atomic_inc(dropped);
> > >
> > > Why does 'dropped' need to be atomic if you are always incrementing under a
> > > lock?
> >
> > It doesn't, strictly speaking, but making it atomic in litmus test was
> > just more convenient, especially that I initially also had a lock-less
> > variant of this algorithm.
>
> Ok, that's fine.
>
> > >
> > > > + spin_unlock(rb_lock);
> > > > + } else {
> > > > + if (rPx == 0) {
> > > > + rLenPtr = len1;
> > > > + } else {
> > > > + rLenPtr = lenFail;
> > > > + rFail = 1;
> > > > + }
> > > > +
> > > > + *rLenPtr = -1;
> > >
> > > Clarify please the need to set the length intermittently to -1. Thanks.
> >
> > This corresponds to setting a "busy bit" in kernel implementation.
> > These litmus tests are supposed to be correlated with in-kernel
> > implementation, I'm not sure I want to maintain extra 4 copies of
> > comments here and in kernel code. Especially for 2-producer cases,
> > there are 2 identical P1 and P2, which is unfortunate, but I haven't
> > figured out how to have a re-usable pieces of code with litmus tests
> > :)
>
> I disagree that comments related to memory ordering are optional. IMHO, the
> documentation should be clear from a memory ordering standpoint. After all,
> good Documentation/ always clarifies something / some concept to the reader
> right? :-) Please have mercy on me, I am just trying to learn *your*
> Documentation ;-)
My point was that reading litmus test without also reading ringbuf
implementation is pointless and is harder than necessary. I'll add few
comments to litmus tests, but ultimately I view kernel implementation
as the source of truth and litmus test as a simplified model of it. So
having extensive comments in litmus test is just a maintenance burden
and more chance to get confusing, out-of-sync documentation.
>
> > > > diff --git a/Documentation/litmus-tests/bpf-rb/bpf-rb+2p1c+bounded.litmus b/Documentation/litmus-tests/bpf-rb/bpf-rb+2p1c+bounded.litmus
> [...]
> > > > +P1(int *lenFail, int *len1, spinlock_t *rb_lock, int *px, int *cx, atomic_t *dropped)
> > > > +{
> > > > + int rPx;
> > > > + int rCx;
> > > > + int rFail;
> > > > + int *rLenPtr;
> > > > +
> > > > + rFail = 0;
> > > > + rLenPtr = lenFail;
> > > > +
> > > > + rCx = smp_load_acquire(cx);
> > > > + spin_lock(rb_lock);
> > > > +
> > > > + rPx = *px;
> > > > + if (rPx - rCx >= 1) {
> > > > + atomic_inc(dropped);
> > > > + spin_unlock(rb_lock);
> > > > + } else {
> > > > + if (rPx == 0) {
> > > > + rLenPtr = len1;
> > > > + } else if (rPx == 1) {
> > > > + rLenPtr = len1;
> > > > + } else {
> > > > + rLenPtr = lenFail;
> > > > + rFail = 1;
> > > > + }
> > > > +
> > > > + *rLenPtr = -1;
> > > > + smp_store_release(px, rPx + 1);
> > > > +
> > > > + spin_unlock(rb_lock);
> > > > +
> > > > + smp_store_release(rLenPtr, 1);
> > >
> > > I ran a test replacing the last 2 statements above with the following and it
> > > still works:
> > >
> > > spin_unlock(rb_lock);
> > > WRITE_ONCE(*rLenPtr, 1);
> > >
> > > Wouldn't you expect the test to catch an issue? The spin_unlock is already a
> > > RELEASE barrier.
> >
> > Well, apparently it's not an issue and WRITE_ONCE would work as well
> > :) My original version actually used WRITE_ONCE here. See [0] and
> > discussion in [1] after which I removed all the WRITE_ONCE/READ_ONCE
> > in favor of store_release/load_acquire for consistency.
> >
> > [0] https://patchwork.ozlabs.org/project/netdev/patch/20200513192532.4058934-3-andriin@fb.com/
> > [1] https://patchwork.ozlabs.org/project/netdev/patch/20200513192532.4058934-2-andriin@fb.com/
>
> Huh. So you are replacing the test to use WRITE_ONCE instead? Why did you
> favor the acquire/release memory barriers over the _ONCE annotations, if that
> was not really needed then?
I replaced WRITE_ONCE with store_release. There was a request on
initial version to keep it simple and use store_release/load_acquire
pairings consistently and not mix up WRITE_ONCE and load_acquire, so
that's what I did. As I mentioned elsewhere, this might not be the
weakest possible set of orderings and we might improve that, but it
seems to work well.
>
> > > Suggestion: It is hard to review the patch because it is huge, it would be
> > > good to split this up into 4 patches for each of the tests. But upto you :)
> >
> > Those 4 files are partial copies of each other, not sure splitting
> > them actually would be easier. If anyone else thinks the same, though,
> > I'll happily split.
>
> I personally disagree. It would be much easier IMHO to review 4 different
> files since some of them are also quite dissimilar. I frequently keep jumping
> between diffs to find a different file and it makes the review that much
> harder. But anything the LKMM experts decide in this regard is acceptable to me :)
>
> thanks,
>
> - Joel
>
^ permalink raw reply
* Re: [PATCH v6 08/12] mmap locking API: add MMAP_LOCK_INITIALIZER
From: Daniel Jordan @ 2020-05-29 20:17 UTC (permalink / raw)
To: Michel Lespinasse
Cc: Andrew Morton, linux-mm, LKML, Peter Zijlstra, Laurent Dufour,
Vlastimil Babka, Matthew Wilcox, Liam Howlett, Jerome Glisse,
Davidlohr Bueso, David Rientjes, Hugh Dickins, Ying Han,
Jason Gunthorpe, Daniel Jordan, John Hubbard
In-Reply-To: <20200520052908.204642-9-walken@google.com>
On Tue, May 19, 2020 at 10:29:04PM -0700, Michel Lespinasse wrote:
> Define a new initializer for the mmap locking api.
> Initially this just evaluates to __RWSEM_INITIALIZER as the API
> is defined as wrappers around rwsem.
>
> Signed-off-by: Michel Lespinasse <walken@google.com>
> Reviewed-by: Laurent Dufour <ldufour@linux.ibm.com>
> Reviewed-by: Vlastimil Babka <vbabka@suse.cz>
Reviewed-by: Daniel Jordan <daniel.m.jordan@oracle.com>
^ permalink raw reply
* [PATCH] opp: avoid uninitialized-variable use
From: Arnd Bergmann @ 2020-05-29 20:17 UTC (permalink / raw)
To: Viresh Kumar, Nishanth Menon, Stephen Boyd, Georgi Djakov
Cc: Arnd Bergmann, Sibi Sankar, Viresh Kumar, Matthias Kaehlcke,
Rajendra Nayak, linux-pm, linux-kernel
An uninitialized pointer is passed into another function but
ignored there:
drivers/opp/core.c:875:32: error: variable 'opp' is uninitialized when used here [-Werror,-Wuninitialized]
ret = _set_opp_bw(opp_table, opp, dev, true);
^~~
drivers/opp/core.c:849:34: note: initialize the variable 'opp' to silence this warning
struct dev_pm_opp *old_opp, *opp;
^
gcc no longer warns about this, but it seems it really should,
so change the code to just pass a NULL pointer here.
See-also: 78a5255ffb6a ("Stop the ad-hoc games with -Wno-maybe-initialized")
Fixes: c57afacc9270 ("opp: Remove bandwidth votes when target_freq is zero")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
drivers/opp/core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/opp/core.c b/drivers/opp/core.c
index df12c3804533..7302f2631f8d 100644
--- a/drivers/opp/core.c
+++ b/drivers/opp/core.c
@@ -872,7 +872,7 @@ int dev_pm_opp_set_rate(struct device *dev, unsigned long target_freq)
goto put_opp_table;
}
- ret = _set_opp_bw(opp_table, opp, dev, true);
+ ret = _set_opp_bw(opp_table, NULL, dev, true);
if (ret)
return ret;
--
2.26.2
^ permalink raw reply related
* [PATCH] ARM: omap2: fix omap5_realtime_timer_init definition
From: Arnd Bergmann @ 2020-05-29 20:16 UTC (permalink / raw)
To: soc, Tony Lindgren, Arnd Bergmann
Cc: Olof Johansson, Stefan Agner, linux-arm-kernel, linux-omap,
linux-kernel
There is one more regression introduced by the last build fix:
arch/arm/mach-omap2/timer.c:170:6: error: attribute declaration must precede definition [-Werror,-Wignored-attributes]
void __init omap5_realtime_timer_init(void)
^
arch/arm/mach-omap2/common.h:118:20: note: previous definition is here
static inline void omap5_realtime_timer_init(void)
^
arch/arm/mach-omap2/timer.c:170:13: error: redefinition of 'omap5_realtime_timer_init'
void __init omap5_realtime_timer_init(void)
^
arch/arm/mach-omap2/common.h:118:20: note: previous definition is here
static inline void omap5_realtime_timer_init(void)
Address this by removing the now obsolete #ifdefs in that file and
just building the entire file based on the flag that controls the
omap5_realtime_timer_init function declaration.
Fixes: d86ad463d670 ("ARM: OMAP2+: Fix regression for using local timer on non-SMP SoCs")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
If this looks ok, I'd apply it directly on top again for the merge window.
---
arch/arm/mach-omap2/Makefile | 6 +++---
arch/arm/mach-omap2/timer.c | 10 ----------
2 files changed, 3 insertions(+), 13 deletions(-)
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 40898b1fd7da..732e614c56b2 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -46,9 +46,9 @@ obj-$(CONFIG_SOC_OMAP5) += $(omap-4-5-common) $(smp-y) sleep44xx.o
obj-$(CONFIG_SOC_AM43XX) += $(omap-4-5-common)
obj-$(CONFIG_SOC_DRA7XX) += $(omap-4-5-common) $(smp-y) sleep44xx.o
-omap5-dra7-common = timer.o
-obj-$(CONFIG_SOC_OMAP5) += $(omap5-dra7-common)
-obj-$(CONFIG_SOC_DRA7XX) += $(omap5-dra7-common)
+omap5-dra7-common-$(CONFIG_SOC_HAS_REALTIME_COUNTER) = timer.o
+obj-$(CONFIG_SOC_OMAP5) += $(omap5-dra7-common-y)
+obj-$(CONFIG_SOC_DRA7XX) += $(omap5-dra7-common-y)
# Functions loaded to SRAM
obj-$(CONFIG_SOC_OMAP2420) += sram242x.o
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index c1737e737a94..620ba69c8f11 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -39,8 +39,6 @@
#define INCREMENTER_DENUMERATOR_RELOAD_OFFSET 0x14
#define NUMERATOR_DENUMERATOR_MASK 0xfffff000
-#ifdef CONFIG_SOC_HAS_REALTIME_COUNTER
-
static unsigned long arch_timer_freq;
void set_cntfreq(void)
@@ -159,14 +157,6 @@ static void __init realtime_counter_init(void)
iounmap(base);
}
-#else
-
-static inline void realtime_counter_init(void)
-{
-}
-
-#endif /* CONFIG_SOC_HAS_REALTIME_COUNTER */
-
void __init omap5_realtime_timer_init(void)
{
omap_clk_init();
--
2.26.2
^ permalink raw reply related
* [PATCH] ARM: omap2: fix omap5_realtime_timer_init definition
From: Arnd Bergmann @ 2020-05-29 20:16 UTC (permalink / raw)
To: soc, Tony Lindgren, Arnd Bergmann
Cc: Olof Johansson, linux-omap, linux-arm-kernel, Stefan Agner,
linux-kernel
There is one more regression introduced by the last build fix:
arch/arm/mach-omap2/timer.c:170:6: error: attribute declaration must precede definition [-Werror,-Wignored-attributes]
void __init omap5_realtime_timer_init(void)
^
arch/arm/mach-omap2/common.h:118:20: note: previous definition is here
static inline void omap5_realtime_timer_init(void)
^
arch/arm/mach-omap2/timer.c:170:13: error: redefinition of 'omap5_realtime_timer_init'
void __init omap5_realtime_timer_init(void)
^
arch/arm/mach-omap2/common.h:118:20: note: previous definition is here
static inline void omap5_realtime_timer_init(void)
Address this by removing the now obsolete #ifdefs in that file and
just building the entire file based on the flag that controls the
omap5_realtime_timer_init function declaration.
Fixes: d86ad463d670 ("ARM: OMAP2+: Fix regression for using local timer on non-SMP SoCs")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
If this looks ok, I'd apply it directly on top again for the merge window.
---
arch/arm/mach-omap2/Makefile | 6 +++---
arch/arm/mach-omap2/timer.c | 10 ----------
2 files changed, 3 insertions(+), 13 deletions(-)
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 40898b1fd7da..732e614c56b2 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -46,9 +46,9 @@ obj-$(CONFIG_SOC_OMAP5) += $(omap-4-5-common) $(smp-y) sleep44xx.o
obj-$(CONFIG_SOC_AM43XX) += $(omap-4-5-common)
obj-$(CONFIG_SOC_DRA7XX) += $(omap-4-5-common) $(smp-y) sleep44xx.o
-omap5-dra7-common = timer.o
-obj-$(CONFIG_SOC_OMAP5) += $(omap5-dra7-common)
-obj-$(CONFIG_SOC_DRA7XX) += $(omap5-dra7-common)
+omap5-dra7-common-$(CONFIG_SOC_HAS_REALTIME_COUNTER) = timer.o
+obj-$(CONFIG_SOC_OMAP5) += $(omap5-dra7-common-y)
+obj-$(CONFIG_SOC_DRA7XX) += $(omap5-dra7-common-y)
# Functions loaded to SRAM
obj-$(CONFIG_SOC_OMAP2420) += sram242x.o
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index c1737e737a94..620ba69c8f11 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -39,8 +39,6 @@
#define INCREMENTER_DENUMERATOR_RELOAD_OFFSET 0x14
#define NUMERATOR_DENUMERATOR_MASK 0xfffff000
-#ifdef CONFIG_SOC_HAS_REALTIME_COUNTER
-
static unsigned long arch_timer_freq;
void set_cntfreq(void)
@@ -159,14 +157,6 @@ static void __init realtime_counter_init(void)
iounmap(base);
}
-#else
-
-static inline void realtime_counter_init(void)
-{
-}
-
-#endif /* CONFIG_SOC_HAS_REALTIME_COUNTER */
-
void __init omap5_realtime_timer_init(void)
{
omap_clk_init();
--
2.26.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH] refperf: work around 64-bit division
From: Arnd Bergmann @ 2020-05-29 20:15 UTC (permalink / raw)
To: Paul E. McKenney, Josh Triplett
Cc: Arnd Bergmann, Joel Fernandes (Google), Steven Rostedt,
Mathieu Desnoyers, Lai Jiangshan, Stephen Rothwell, rcu,
linux-kernel
A 64-bit division was introduced in refperf, breaking compilation
on all 32-bit architectures:
kernel/rcu/refperf.o: in function `main_func':
refperf.c:(.text+0x57c): undefined reference to `__aeabi_uldivmod'
Work it by using div_u64 to mark the expensive operation.
Fixes: bd5b16d6c88d ("refperf: Allow decimal nanoseconds")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
kernel/rcu/refperf.c | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/kernel/rcu/refperf.c b/kernel/rcu/refperf.c
index 47df72c492b3..c2366648981d 100644
--- a/kernel/rcu/refperf.c
+++ b/kernel/rcu/refperf.c
@@ -386,7 +386,7 @@ static int main_func(void *arg)
if (torture_must_stop())
goto end;
- result_avg[exp] = 1000 * process_durations(nreaders) / (nreaders * loops);
+ result_avg[exp] = div_u64(1000 * process_durations(nreaders), nreaders * loops);
}
// Print the average of all experiments
@@ -397,9 +397,14 @@ static int main_func(void *arg)
strcat(buf, "Threads\tTime(ns)\n");
for (exp = 0; exp < nruns; exp++) {
+ u64 avg;
+ u32 rem;
+
if (errexit)
break;
- sprintf(buf1, "%d\t%llu.%03d\n", exp + 1, result_avg[exp] / 1000, (int)(result_avg[exp] % 1000));
+
+ avg = div_s64_rem(result_avg[exp], 1000, &rem);
+ sprintf(buf1, "%d\t%llu.%03d\n", exp + 1, avg, rem);
strcat(buf, buf1);
}
--
2.26.2
^ permalink raw reply related
* [meta-oe][PATCH v2] dfu-util-native: Remove DEPLOY_DIR_TOOLS from sstate-outputdirs
From: Khem Raj @ 2020-05-29 20:16 UTC (permalink / raw)
To: openembedded-devel; +Cc: Khem Raj, Robert P . J . Day, Jacob Kroon
In commit 1ef92d2423d6d6546e4f0585478540212b26f3a0 deploying the native
tool was changed to use DEPLOYDIR, so setting DEPLOY_DIR_TOOLS for sstate-outputdir
dependency should have been changed as well.
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Cc: Robert P. J. Day <rpjday@crashcourse.ca>
Cc: Jacob Kroon <jacob.kroon@gmail.com>
---
v2: Remove setting sstate-outputdirs it is not needed
meta-oe/recipes-support/dfu-util/dfu-util-native_0.9.bb | 1 -
1 file changed, 1 deletion(-)
diff --git a/meta-oe/recipes-support/dfu-util/dfu-util-native_0.9.bb b/meta-oe/recipes-support/dfu-util/dfu-util-native_0.9.bb
index feb16fa730..4305e3b408 100644
--- a/meta-oe/recipes-support/dfu-util/dfu-util-native_0.9.bb
+++ b/meta-oe/recipes-support/dfu-util/dfu-util-native_0.9.bb
@@ -16,7 +16,6 @@ do_deploy() {
addtask deploy before do_package after do_install
-do_deploy[sstate-outputdirs] = "${DEPLOY_DIR_TOOLS}"
# cleandirs should possibly be in deploy.bbclass but we need it
do_deploy[cleandirs] = "${DEPLOYDIR}"
# clear stamp-extra-info since MACHINE_ARCH is normally put there by
--
2.26.2
^ permalink raw reply related
* Re: [net-next 10/11] net/mlx5e: kTLS, Add kTLS RX resync support
From: Jakub Kicinski @ 2020-05-29 20:16 UTC (permalink / raw)
To: Saeed Mahameed; +Cc: David S. Miller, netdev, Tariq Toukan
In-Reply-To: <20200529194641.243989-11-saeedm@mellanox.com>
On Fri, 29 May 2020 12:46:40 -0700 Saeed Mahameed wrote:
> /* Re-sync */
> +static struct mlx5_wqe_ctrl_seg *
> +resync_post_get_progress_params(struct mlx5e_icosq *sq,
> + struct mlx5e_ktls_offload_context_rx *priv_rx)
> +{
> + struct mlx5e_ktls_rx_resync_ctx *resync = &priv_rx->resync;
> + struct mlx5e_get_tls_progress_params_wqe *wqe;
> + struct mlx5_wqe_ctrl_seg *cseg;
> + struct mlx5_seg_get_psv *psv;
> + u16 pi;
> +
> + dma_sync_single_for_device(resync->priv->mdev->device,
> + resync->dma_addr,
> + PROGRESS_PARAMS_PADDED_SIZE,
> + DMA_FROM_DEVICE);
> + BUILD_BUG_ON(MLX5E_KTLS_GET_PROGRESS_WQEBBS != 1);
> + if (unlikely(!mlx5e_wqc_has_room_for(&sq->wq, sq->cc, sq->pc, 1)))
> + return ERR_PTR(-ENOSPC);
I thought you said that resync requests are guaranteed to never fail?
> + pi = mlx5e_icosq_get_next_pi(sq, 1);
> + wqe = MLX5E_TLS_FETCH_GET_PROGRESS_PARAMS_WQE(sq, pi);
> +
> +#define GET_PSV_DS_CNT (DIV_ROUND_UP(sizeof(*wqe), MLX5_SEND_WQE_DS))
> +
> + cseg = &wqe->ctrl;
> + cseg->opmod_idx_opcode =
> + cpu_to_be32((sq->pc << 8) | MLX5_OPCODE_GET_PSV |
> + (MLX5_OPC_MOD_TLS_TIR_PROGRESS_PARAMS << 24));
> + cseg->qpn_ds =
> + cpu_to_be32((sq->sqn << MLX5_WQE_CTRL_QPN_SHIFT) | GET_PSV_DS_CNT);
> +
> + psv = &wqe->psv;
> + psv->num_psv = 1 << 4;
> + psv->l_key = sq->channel->mkey_be;
> + psv->psv_index[0] = cpu_to_be32(priv_rx->tirn);
> + psv->va = cpu_to_be64(priv_rx->resync.dma_addr);
> +
> + icosq_fill_wi(sq, pi, MLX5E_ICOSQ_WQE_GET_PSV_TLS, 1, priv_rx);
> + sq->pc++;
> +
> + return cseg;
> +}
^ permalink raw reply
* + ubsan-entirely-disable-alignment-checks-under-ubsan_trap.patch added to -mm tree
From: akpm @ 2020-05-29 20:16 UTC (permalink / raw)
To: dvyukov, jpoimboe, keescook, lenaptr, mm-commits, rdunlap
The patch titled
Subject: ubsan: entirely disable alignment checks under UBSAN_TRAP
has been added to the -mm tree. Its filename is
ubsan-entirely-disable-alignment-checks-under-ubsan_trap.patch
This patch should soon appear at
http://ozlabs.org/~akpm/mmots/broken-out/ubsan-entirely-disable-alignment-checks-under-ubsan_trap.patch
and later at
http://ozlabs.org/~akpm/mmotm/broken-out/ubsan-entirely-disable-alignment-checks-under-ubsan_trap.patch
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/process/submit-checklist.rst when testing your code ***
The -mm tree is included into linux-next and is updated
there every 3-4 working days
------------------------------------------------------
From: Kees Cook <keescook@chromium.org>
Subject: ubsan: entirely disable alignment checks under UBSAN_TRAP
Commit 8d58f222e85f ("ubsan: disable UBSAN_ALIGNMENT under COMPILE_TEST")
tried to fix the pathological results of UBSAN_ALIGNMENT with UBSAN_TRAP
(which objtool would rightly scream about), but it made an assumption
about how COMPILE_TEST gets set (it is not set for randconfig). As a
result, we need a bigger hammer here: just don't allow the alignment
checks with the trap mode.
Link: http://lkml.kernel.org/r/202005291236.000FCB6@keescook
Link: https://lore.kernel.org/lkml/742521db-1e8c-0d7a-1ed4-a908894fb497@infradead.org/
Fixes: 8d58f222e85f ("ubsan: disable UBSAN_ALIGNMENT under COMPILE_TEST")
Signed-off-by: Kees Cook <keescook@chromium.org>
Reported-by: Randy Dunlap <rdunlap@infradead.org>
Acked-by: Randy Dunlap <rdunlap@infradead.org>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Dmitry Vyukov <dvyukov@google.com>
Cc: Elena Petrova <lenaptr@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
lib/Kconfig.ubsan | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/lib/Kconfig.ubsan~ubsan-entirely-disable-alignment-checks-under-ubsan_trap
+++ a/lib/Kconfig.ubsan
@@ -63,7 +63,7 @@ config UBSAN_SANITIZE_ALL
config UBSAN_ALIGNMENT
bool "Enable checks for pointers alignment"
default !HAVE_EFFICIENT_UNALIGNED_ACCESS
- depends on !X86 || !COMPILE_TEST
+ depends on !UBSAN_TRAP
help
This option enables the check of unaligned memory accesses.
Enabling this option on architectures that support unaligned
_
Patches currently in -mm which might be from keescook@chromium.org are
ubsan-entirely-disable-alignment-checks-under-ubsan_trap.patch
exec-change-uselib2-is_sreg-failure-to-eacces.patch
exec-relocate-s_isreg-check.patch
exec-relocate-path_noexec-check.patch
fs-include-fmode_exec-when-converting-flags-to-f_mode.patch
^ permalink raw reply
* [PATCH] drm/selftests/mm: reduce per-function stack usage
From: Arnd Bergmann @ 2020-05-29 20:15 UTC (permalink / raw)
To: David Airlie, Daniel Vetter, Christian König, Nirmoy Das,
Chris Wilson
Cc: linux-kernel, dri-devel, kbuild test robot, Arnd Bergmann,
Tvrtko Ursulin
The check_reserve_boundaries() function has a large array on the stack,
over 500 bytes. It gets inlined into __igt_reserve, which has multiple
other large structures as well but stayed just under the stack size
warning limit of 1024 bytes until one more member got added to struct
drm_mm_node, causing a warning:
drivers/gpu/drm/selftests/test-drm_mm.c:371:12: error:
stack frame size of 1032 bytes in function '__igt_reserve' [-Werror,-Wframe-larger-than=]
As far as I can tell, this is not nice but will not be called from
a context that is already low for the kernel stack, so just annotate
the inner function as noinline_for_stack to ensure that each function
by itself stays under the warning limit.
Fixes: 0cdea4455acd ("drm/mm: optimize rb_hole_addr rbtree search")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
drivers/gpu/drm/selftests/test-drm_mm.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/selftests/test-drm_mm.c b/drivers/gpu/drm/selftests/test-drm_mm.c
index 9aabe82dcd3a..30108c330db8 100644
--- a/drivers/gpu/drm/selftests/test-drm_mm.c
+++ b/drivers/gpu/drm/selftests/test-drm_mm.c
@@ -323,9 +323,8 @@ static bool expect_reserve_fail(struct drm_mm *mm, struct drm_mm_node *node)
return false;
}
-static bool check_reserve_boundaries(struct drm_mm *mm,
- unsigned int count,
- u64 size)
+static noinline_for_stack bool
+check_reserve_boundaries(struct drm_mm *mm, unsigned int count, u64 size)
{
const struct boundary {
u64 start, size;
--
2.26.2
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply related
* [PATCH] drm/selftests/mm: reduce per-function stack usage
From: Arnd Bergmann @ 2020-05-29 20:15 UTC (permalink / raw)
To: David Airlie, Daniel Vetter, Christian König, Nirmoy Das,
Chris Wilson
Cc: Arnd Bergmann, kbuild test robot, Tvrtko Ursulin, dri-devel,
linux-kernel
The check_reserve_boundaries() function has a large array on the stack,
over 500 bytes. It gets inlined into __igt_reserve, which has multiple
other large structures as well but stayed just under the stack size
warning limit of 1024 bytes until one more member got added to struct
drm_mm_node, causing a warning:
drivers/gpu/drm/selftests/test-drm_mm.c:371:12: error:
stack frame size of 1032 bytes in function '__igt_reserve' [-Werror,-Wframe-larger-than=]
As far as I can tell, this is not nice but will not be called from
a context that is already low for the kernel stack, so just annotate
the inner function as noinline_for_stack to ensure that each function
by itself stays under the warning limit.
Fixes: 0cdea4455acd ("drm/mm: optimize rb_hole_addr rbtree search")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
drivers/gpu/drm/selftests/test-drm_mm.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/selftests/test-drm_mm.c b/drivers/gpu/drm/selftests/test-drm_mm.c
index 9aabe82dcd3a..30108c330db8 100644
--- a/drivers/gpu/drm/selftests/test-drm_mm.c
+++ b/drivers/gpu/drm/selftests/test-drm_mm.c
@@ -323,9 +323,8 @@ static bool expect_reserve_fail(struct drm_mm *mm, struct drm_mm_node *node)
return false;
}
-static bool check_reserve_boundaries(struct drm_mm *mm,
- unsigned int count,
- u64 size)
+static noinline_for_stack bool
+check_reserve_boundaries(struct drm_mm *mm, unsigned int count, u64 size)
{
const struct boundary {
u64 start, size;
--
2.26.2
^ permalink raw reply related
* Re: [Intel-gfx] [PATCH 2/2] drm/i915/gem: Give each object class a friendly name
From: Matthew Auld @ 2020-05-29 20:15 UTC (permalink / raw)
To: Chris Wilson; +Cc: Intel Graphics Development, Matthew Auld
In-Reply-To: <20200529183204.16850-2-chris@chris-wilson.co.uk>
On Fri, 29 May 2020 at 19:32, Chris Wilson <chris@chris-wilson.co.uk> wrote:
>
> Name the object classes and their offspring for easier lockdep
> debugging.
>
> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* Re: [PATCH v2 1/3] seccomp: Add find_notification helper
From: Kees Cook @ 2020-05-29 20:14 UTC (permalink / raw)
To: Sargun Dhillon
Cc: christian.brauner, containers, cyphar, jannh, jeffv, linux-api,
linux-kernel, palmer, rsesek, tycho, Matt Denton
In-Reply-To: <20200529174037.GA11153@ircssh-2.c.rugged-nimbus-611.internal>
On Fri, May 29, 2020 at 05:40:38PM +0000, Sargun Dhillon wrote:
> >
> > While the comment is good, let's actually enforce this with:
> >
> > if (WARN_ON(!mutex_is_locked(&filter->notif_lock)))
> > return NULL;
> >
> I don't see much use of lockdep in seccomp (well, any), but
> wouldn't a stronger statement be to use lockdep, and just have:
>
> lockdep_assert_held(&filter->notify_lock);
>
> As that checks that the lock is held by the current task.
/me slaps his forehead
Yes. I need more coffee or something. Yes, I meant
lockdep_assert_held(), and now I need to go fix my pstore series since I
confused myself into the wrong function and using it so many times in
pstore overwrote the correct function in my head. Thank you!
> Although, that does put this check behind lockdep, which means
> that running in "normal" circumstances is less safe (but faster?).
Now, that's fine. The check needs to be "am *I* holding this mutex?" and
I don't think anything except lockdep can do that.
--
Kees Cook
^ permalink raw reply
* [PATCH] block: add 'struct gendisk' declaration
From: Arnd Bergmann @ 2020-05-29 20:14 UTC (permalink / raw)
To: Konstantin Khlebnikov, Jens Axboe
Cc: Arnd Bergmann, Christoph Hellwig, Damien Le Moal, Bart Van Assche,
Martin K. Petersen, Ming Lei, Ajay Joshi, linux-kernel
The added disk_start_io_acct() function declaration causes a warning
when CONFIG_BLOCK is disabled:
include/linux/blkdev.h:1895:41: error: declaration of 'struct gendisk' will not be visible outside of this function [-Werror,-Wvisibility]
Declare the struct tag before the function to suppress that warning.
Fixes: 956d510ee78c ("block: add disk/bio-based accounting helpers")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
include/linux/blkdev.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/linux/blkdev.h b/include/linux/blkdev.h
index 36568c9d030a..96cf7af86b73 100644
--- a/include/linux/blkdev.h
+++ b/include/linux/blkdev.h
@@ -1892,6 +1892,7 @@ static inline void blk_wake_io_task(struct task_struct *waiter)
wake_up_process(waiter);
}
+struct gendisk;
unsigned long disk_start_io_acct(struct gendisk *disk, unsigned int sectors,
unsigned int op);
void disk_end_io_acct(struct gendisk *disk, unsigned int op,
--
2.26.2
^ permalink raw reply related
* Re: mmotm 2020-05-13-20-30 uploaded (objtool warnings)
From: Al Viro @ 2020-05-29 20:14 UTC (permalink / raw)
To: Linus Torvalds
Cc: Josh Poimboeuf, Peter Zijlstra, Christoph Hellwig, Randy Dunlap,
Andrew Morton, Mark Brown, linux-fsdevel,
Linux Kernel Mailing List, Linux-MM, Linux Next Mailing List,
Michal Hocko, mm-commits, Stephen Rothwell,
the arch/x86 maintainers, Steven Rostedt
In-Reply-To: <20200529200856.GG23230@ZenIV.linux.org.uk>
On Fri, May 29, 2020 at 09:08:56PM +0100, Al Viro wrote:
> On Fri, May 29, 2020 at 12:31:04PM -0700, Linus Torvalds wrote:
> > On Fri, May 29, 2020 at 9:50 AM Josh Poimboeuf <jpoimboe@redhat.com> wrote:
> > >
> > > From staring at the asm I think the generated code is correct, it's just
> > > that the nested likelys with ftrace profiling cause GCC to converge the
> > > error/success paths. But objtool doesn't do register value tracking so
> > > it's not smart enough to know that it's safe.
> >
> > I'm surprised that gcc doesn't end up doing the obvious CSE and then
> > branch following and folding it all away in the end, but your patch is
> > obviously the right thing to do regardless, so ack on that.
> >
> > Al - I think this had best go into your uaccess cleanup branch with
> > that csum-wrapper update, to avoid any unnecessary conflicts or
> > dependencies.
>
> Sure, just let me verify that other branches don't introduce anything
> of that sort...
... they don't.
OK, folded, rebuild #for-next, pushed both out...
^ permalink raw reply
* [PATCH] flow_dissector: work around stack frame size warning
From: Arnd Bergmann @ 2020-05-29 20:13 UTC (permalink / raw)
To: Jamal Hadi Salim, Cong Wang, Jiri Pirko, David S. Miller,
Jakub Kicinski, Guillaume Nault
Cc: Arnd Bergmann, Vlad Buslov, Xin Long, Pablo Neira Ayuso, netdev,
linux-kernel
The fl_flow_key structure is around 500 bytes, so having two of them
on the stack in one function now exceeds the warning limit after an
otherwise correct change:
net/sched/cls_flower.c:298:12: error: stack frame size of 1056 bytes in function 'fl_classify' [-Werror,-Wframe-larger-than=]
I suspect the fl_classify function could be reworked to only have one
of them on the stack and modify it in place, but I could not work out
how to do that.
As a somewhat hacky workaround, move one of them into an out-of-line
function to reduce its scope. This does not necessarily reduce the stack
usage of the outer function, but at least the second copy is removed
from the stack during most of it and does not add up to whatever is
called from there.
I now see 552 bytes of stack usage for fl_classify(), plus 528 bytes
for fl_mask_lookup().
Fixes: 58cff782cc55 ("flow_dissector: Parse multiple MPLS Label Stack Entries")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
net/sched/cls_flower.c | 17 ++++++++---------
1 file changed, 8 insertions(+), 9 deletions(-)
diff --git a/net/sched/cls_flower.c b/net/sched/cls_flower.c
index 96f5999281e0..030896eadd11 100644
--- a/net/sched/cls_flower.c
+++ b/net/sched/cls_flower.c
@@ -272,14 +272,16 @@ static struct cls_fl_filter *fl_lookup_range(struct fl_flow_mask *mask,
return NULL;
}
-static struct cls_fl_filter *fl_lookup(struct fl_flow_mask *mask,
- struct fl_flow_key *mkey,
- struct fl_flow_key *key)
+static noinline_for_stack
+struct cls_fl_filter *fl_mask_lookup(struct fl_flow_mask *mask, struct fl_flow_key *key)
{
+ struct fl_flow_key mkey;
+
+ fl_set_masked_key(&mkey, key, mask);
if ((mask->flags & TCA_FLOWER_MASK_FLAGS_RANGE))
- return fl_lookup_range(mask, mkey, key);
+ return fl_lookup_range(mask, &mkey, key);
- return __fl_lookup(mask, mkey);
+ return __fl_lookup(mask, &mkey);
}
static u16 fl_ct_info_to_flower_map[] = {
@@ -299,7 +301,6 @@ static int fl_classify(struct sk_buff *skb, const struct tcf_proto *tp,
struct tcf_result *res)
{
struct cls_fl_head *head = rcu_dereference_bh(tp->root);
- struct fl_flow_key skb_mkey;
struct fl_flow_key skb_key;
struct fl_flow_mask *mask;
struct cls_fl_filter *f;
@@ -319,9 +320,7 @@ static int fl_classify(struct sk_buff *skb, const struct tcf_proto *tp,
ARRAY_SIZE(fl_ct_info_to_flower_map));
skb_flow_dissect(skb, &mask->dissector, &skb_key, 0);
- fl_set_masked_key(&skb_mkey, &skb_key, mask);
-
- f = fl_lookup(mask, &skb_mkey, &skb_key);
+ f = fl_mask_lookup(mask, &skb_key);
if (f && !tc_skip_sw(f->flags)) {
*res = f->res;
return tcf_exts_exec(skb, &f->exts, res);
--
2.26.2
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.