From: Andrew Morton <akpm@linux-foundation.org>
To: Seth Jennings <sjennings@variantweb.net>
Cc: Minchan Kim <minchan@kernel.org>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
Nitin Gupta <ngupta@vflare.org>,
Sergey Senozhatsky <sergey.senozhatsky@gmail.com>,
Dan Streetman <ddstreet@ieee.org>,
Jerome Marchand <jmarchan@redhat.com>
Subject: Re: [PATCH] zsmalloc: correct fragile [kmap|kunmap]_atomic use
Date: Tue, 18 Nov 2014 15:01:38 -0800 [thread overview]
Message-ID: <20141118150138.668c81fda55c3ce39d7b2aac@linux-foundation.org> (raw)
In-Reply-To: <20141114150732.GA2402@cerebellum.variantweb.net>
On Fri, 14 Nov 2014 09:07:32 -0600 Seth Jennings <sjennings@variantweb.net> wrote:
> On Fri, Nov 14, 2014 at 10:11:01AM +0900, Minchan Kim wrote:
> > The kunmap_atomic should use virtual address getting by kmap_atomic.
> > However, some pieces of code in zsmalloc uses modified address,
> > not the one got by kmap_atomic for kunmap_atomic.
> >
> > It's okay for working because zsmalloc modifies the address
> > inner PAGE_SIZE bounday so it works with current kmap_atomic's
> > implementation. But it's still fragile with potential changing
> > of kmap_atomic so let's correct it.
It is a bit alarming, but I've seen code elsewhere in which a modified
pointer is passed to kunmap_atomic(). So the kunmap_atomic() interface
is "kvaddr should point somewhere into the page" and that won't be
changing without a big effort.
> Seems like you could just use PAGE_MASK to get the base page address
> from link like this:
I think Minchan's approach is better: it explicitly retains the
kmap_atomic() return value for passing to kunmap_atomic(). That's
nicer than modifying it and then setting it back again.
I mean, a cleaner way of implementing your suggestion would be
void kunmap_atomic_unaligned(void *p)
{
kunmap_atomic(void *)((unsigned long)p & PAGE_MASK);
}
but then one looks at
void __kunmap_atomic(void *kvaddr)
{
unsigned long vaddr = (unsigned long) kvaddr & PAGE_MASK;
and asks "what the heck".
So I dunno. We could leave the code as-is. I have no strong feelings
either way. Minchan's patch has no effect on zsmalloc.o section sizes
with my compiler.
next prev parent reply other threads:[~2014-11-18 23:01 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-14 1:11 [PATCH] zsmalloc: correct fragile [kmap|kunmap]_atomic use Minchan Kim
2014-11-14 15:07 ` Seth Jennings
2014-11-15 13:20 ` Sergey Senozhatsky
2014-11-18 23:01 ` Andrew Morton [this message]
2014-11-18 23:21 ` Minchan Kim
2014-11-18 23:34 ` Andrew Morton
2014-11-16 11:41 ` Ganesh Mahendran
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=20141118150138.668c81fda55c3ce39d7b2aac@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=ddstreet@ieee.org \
--cc=jmarchan@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=minchan@kernel.org \
--cc=ngupta@vflare.org \
--cc=sergey.senozhatsky@gmail.com \
--cc=sjennings@variantweb.net \
/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).