From: Alistair Popple <apopple@nvidia.com>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: Christoph Hellwig <hch@infradead.org>,
Max Ramanouski <max8rr8@gmail.com>,
x86@kernel.org, dave.hansen@linux.intel.com, luto@kernel.org,
peterz@infradead.org, linux-kernel@vger.kernel.org,
jniethe@nvidia.com, jhubbard@nvidia.com, linux-mm@kvack.org
Subject: Re: [PATCH v2] x86/ioremap: Use is_ioremap_addr() in iounmap()
Date: Wed, 14 Aug 2024 22:08:23 +1000 [thread overview]
Message-ID: <87le0zmhdp.fsf@nvdebian.thelocal> (raw)
In-Reply-To: <878qwzpfbi.ffs@tglx>
Thomas Gleixner <tglx@linutronix.de> writes:
> On Tue, Aug 13 2024 at 21:28, Christoph Hellwig wrote:
>> Modulo the fixes discussion (and any commit log adjustments related to
>> that), is_ioremap_addr is the right interface to check for an
>> ioremap address. So for the actual code change:
>
> I'm not opposed to use is_ioremap_addr() as it restricts the check to
> the actual ioremp region.
>
> That said, I'm wondering why iounmap() silently bails out when invoked
> with an address which is outside of the ioremap region. I'd say, any
> invocation with an address outside of it, is broken, but I might be
> missing something as always.
I would tend to agree and had the same thought when we found this. At
least some kind of message (WARN_ON, WARN_ON_ONCE, printk, etc) would
have made the issue we were debugging much more obvious. FWIW I have
tested running with a WARN_ON() there and it never fired except in the
bug scenario.
- Alistair
> Thanks,
>
> tglx
next prev parent reply other threads:[~2024-08-14 12:14 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-12 20:35 [PATCH v2] x86/ioremap: Use is_ioremap_addr() in iounmap() Max Ramanouski
2024-08-12 21:13 ` Thomas Gleixner
2024-08-14 4:28 ` Christoph Hellwig
2024-08-14 10:30 ` Thomas Gleixner
2024-08-14 12:08 ` Alistair Popple [this message]
2024-08-14 12:16 ` Christoph Hellwig
2024-08-14 14:11 ` Thomas Gleixner
2024-08-15 5:02 ` Christoph Hellwig
2024-08-15 13:41 ` Thomas Gleixner
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=87le0zmhdp.fsf@nvdebian.thelocal \
--to=apopple@nvidia.com \
--cc=dave.hansen@linux.intel.com \
--cc=hch@infradead.org \
--cc=jhubbard@nvidia.com \
--cc=jniethe@nvidia.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=luto@kernel.org \
--cc=max8rr8@gmail.com \
--cc=peterz@infradead.org \
--cc=tglx@linutronix.de \
--cc=x86@kernel.org \
/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 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.