From: Robin Murphy <robin.murphy@arm.com>
To: Yu Zhao <yuzhao@google.com>, dongli.zhang@oracle.com
Cc: ak@linux.intel.com, akpm@linux-foundation.org,
alexander.sverdlin@nokia.com, andi.kleen@intel.com, bp@alien8.de,
bp@suse.de, cminyard@mvista.com, corbet@lwn.net,
damien.lemoal@opensource.wdc.com, dave.hansen@linux.intel.com,
hch@infradead.org, iommu@lists.linux-foundation.org,
joe.jin@oracle.com, joe@perches.com, keescook@chromium.org,
kirill.shutemov@intel.com, kys@microsoft.com,
linux-doc@vger.kernel.org, linux-hyperv@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-mips@vger.kernel.org,
ltykernel@gmail.com, michael.h.kelley@microsoft.com,
mingo@redhat.com, m.szyprowski@samsung.com,
parri.andrea@gmail.com, paulmck@kernel.org, pmladek@suse.com,
rdunlap@infradead.org, tglx@linutronix.de,
thomas.lendacky@amd.com, Tianyu.Lan@microsoft.com,
tsbogend@alpha.franken.de, vkuznets@redhat.com,
wei.liu@kernel.org, x86@kernel.org
Subject: Re: [PATCH v1 4/4] swiotlb: panic if nslabs is too small
Date: Mon, 22 Aug 2022 10:49:09 +0100 [thread overview]
Message-ID: <f8c743d8-fcbe-4ef7-5f86-d63086552ffd@arm.com> (raw)
In-Reply-To: <20220820012031.1285979-1-yuzhao@google.com>
On 2022-08-20 02:20, Yu Zhao wrote:
>> Panic on purpose if nslabs is too small, in order to sync with the remap
>> retry logic.
>>
>> In addition, print the number of bytes for tlb alloc failure.
>>
>> Signed-off-by: Dongli Zhang <dongli.zhang@oracle.com>
>> ---
>> kernel/dma/swiotlb.c | 6 +++++-
>> 1 file changed, 5 insertions(+), 1 deletion(-)
>>
>> diff --git a/kernel/dma/swiotlb.c b/kernel/dma/swiotlb.c
>> index fd21f4162f4b..1758b724c7a8 100644
>> --- a/kernel/dma/swiotlb.c
>> +++ b/kernel/dma/swiotlb.c
>> @@ -242,6 +242,9 @@ void __init swiotlb_init_remap(bool addressing_limit, unsigned int flags,
>> if (swiotlb_force_disable)
>> return;
>>
>> + if (nslabs < IO_TLB_MIN_SLABS)
>> + panic("%s: nslabs = %lu too small\n", __func__, nslabs);
>
> Hi,
>
> This patch breaks MIPS. Please take a look. Thanks.
Hmm, it's possible this might be quietly fixed by 20347fca71a3, but
either way I'm not sure why we would need to panic *before* we've even
tried to allocate anything, when we could simply return with no harm
done? If we've ended up calculating (or being told) a buffer size which
is too small to be usable, that should be no different to disabling
SWIOTLB entirely.
Historically, passing "swiotlb=1" on the command line has been used to
save memory when the user knows SWIOTLB isn't needed. That should
definitely not be allowed to start panicking.
(once again, another patch which was not CCed to the correct reviewers,
sigh...)
Thanks,
Robin.
> On v5.19.0:
> Linux version 5.19.0 (builder@buildhost) (mips64-openwrt-linux-musl-gcc (OpenWrt GCC 11.2.0 r19590-042d558536) 11.2.0, GNU ld (GNU Binutils) 2.37) #0 SMP Sun Jul 31 15:12:47 2022
> Skipping L2 locking due to reduced L2 cache size
> CVMSEG size: 0 cache lines (0 bytes)
> printk: bootconsole [early0] enabled
> CPU0 revision is: 000d9301 (Cavium Octeon II)
> Kernel sections are not in the memory maps
> Wasting 278528 bytes for tracking 4352 unused pages
> Initrd not found or empty - disabling initrd
> Using appended Device Tree.
> software IO TLB: SWIOTLB bounce buffer size adjusted to 0MB
> software IO TLB: mapped [mem 0x0000000004b0c000-0x0000000004b4c000] (0MB)
>
> On v6.0-rc1, with
> commit 0bf28fc40d89 ("swiotlb: panic if nslabs is too small")
> commit 20347fca71a3 ("swiotlb: split up the global swiotlb lock")
> commit 534ea58b3ceb ("Revert "MIPS: octeon: Remove vestiges of CONFIG_CAVIUM_RESERVE32"")
>
> Linux version 6.0.0-rc1 (builder@buildhost) (mips64-openwrt-linux-musl-gcc (OpenWrt GCC 11.2.0 r19590-042d558536) 11.2.0, GNU ld (GNU Binutils) 2.37) #0 SMP Sun Jul 31 15:12:47 2022
> Failed to allocate CAVIUM_RESERVE32 memory area
> Skipping L2 locking due to reduced L2 cache size
> CVMSEG size: 0 cache lines (0 bytes)
> printk: bootconsole [early0] enabled
> CPU0 revision is: 000d9301 (Cavium Octeon II)
> Kernel sections are not in the memory maps
> Wasting 278528 bytes for tracking 4352 unused pages
> Initrd not found or empty - disabling initrd
> Using appended Device Tree.
> software IO TLB: SWIOTLB bounce buffer size adjusted to 0MB
> software IO TLB: area num 1.
> Kernel panic - not syncing: swiotlb_init_remap: nslabs = 128 too small
>
> On v6.0-rc1, with
> commit 20347fca71a3 ("swiotlb: split up the global swiotlb lock")
> commit 534ea58b3ceb ("Revert "MIPS: octeon: Remove vestiges of CONFIG_CAVIUM_RESERVE32"")
>
> Linux version 6.0.0-rc1+ (builder@buildhost) (mips64-openwrt-linux-musl-gcc (OpenWrt GCC 11.2.0 r19590-042d558536) 11.2.0, GNU ld (GNU Binutils) 2.37) #0 SMP Sun Jul 31 15:12:47 2022
> Failed to allocate CAVIUM_RESERVE32 memory area
> Skipping L2 locking due to reduced L2 cache size
> CVMSEG size: 0 cache lines (0 bytes)
> printk: bootconsole [early0] enabled
> CPU0 revision is: 000d9301 (Cavium Octeon II)
> Kernel sections are not in the memory maps
> Wasting 278528 bytes for tracking 4352 unused pages
> Initrd not found or empty - disabling initrd
> Using appended Device Tree.
> software IO TLB: SWIOTLB bounce buffer size adjusted to 0MB
> software IO TLB: area num 1.
> software IO TLB: mapped [mem 0x0000000004c0c000-0x0000000004c4c000] (0MB)
next prev parent reply other threads:[~2022-08-22 9:49 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-11 8:25 [PATCH v1 0/4] swiotlb: some cleanup Dongli Zhang
2022-06-11 8:25 ` [PATCH v1 1/4] swiotlb: remove unused swiotlb_force Dongli Zhang
2022-06-11 8:25 ` [PATCH v1 2/4] swiotlb: remove useless return Dongli Zhang
2022-06-11 8:25 ` [PATCH v1 3/4] x86/swiotlb: fix param usage in boot-options.rst Dongli Zhang
2022-06-11 8:25 ` [PATCH v1 4/4] swiotlb: panic if nslabs is too small Dongli Zhang
2022-06-13 6:49 ` Dongli Zhang
2022-08-20 1:20 ` Yu Zhao
2022-08-22 9:49 ` Robin Murphy [this message]
2022-08-22 11:26 ` Christoph Hellwig
2022-08-22 12:32 ` Robin Murphy
2022-08-22 22:27 ` Dongli Zhang
2022-08-22 23:10 ` Yu Zhao
2022-08-22 23:47 ` Dongli Zhang
2022-06-22 10:43 ` [PATCH v1 0/4] swiotlb: some cleanup Christoph Hellwig
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=f8c743d8-fcbe-4ef7-5f86-d63086552ffd@arm.com \
--to=robin.murphy@arm.com \
--cc=Tianyu.Lan@microsoft.com \
--cc=ak@linux.intel.com \
--cc=akpm@linux-foundation.org \
--cc=alexander.sverdlin@nokia.com \
--cc=andi.kleen@intel.com \
--cc=bp@alien8.de \
--cc=bp@suse.de \
--cc=cminyard@mvista.com \
--cc=corbet@lwn.net \
--cc=damien.lemoal@opensource.wdc.com \
--cc=dave.hansen@linux.intel.com \
--cc=dongli.zhang@oracle.com \
--cc=hch@infradead.org \
--cc=iommu@lists.linux-foundation.org \
--cc=joe.jin@oracle.com \
--cc=joe@perches.com \
--cc=keescook@chromium.org \
--cc=kirill.shutemov@intel.com \
--cc=kys@microsoft.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-hyperv@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mips@vger.kernel.org \
--cc=ltykernel@gmail.com \
--cc=m.szyprowski@samsung.com \
--cc=michael.h.kelley@microsoft.com \
--cc=mingo@redhat.com \
--cc=parri.andrea@gmail.com \
--cc=paulmck@kernel.org \
--cc=pmladek@suse.com \
--cc=rdunlap@infradead.org \
--cc=tglx@linutronix.de \
--cc=thomas.lendacky@amd.com \
--cc=tsbogend@alpha.franken.de \
--cc=vkuznets@redhat.com \
--cc=wei.liu@kernel.org \
--cc=x86@kernel.org \
--cc=yuzhao@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).