All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Biggers <ebiggers@kernel.org>
To: Matthew Wilcox <willy@infradead.org>
Cc: linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	linux-f2fs-devel@lists.sourceforge.net, stable@vger.kernel.org,
	Al Viro <viro@zeniv.linux.org.uk>,
	Daniel Rosenberg <drosen@google.com>,
	Gabriel Krisman Bertazi <krisman@collabora.co.uk>
Subject: Re: [PATCH] ext4: avoid utf8_strncasecmp() with unstable name
Date: Mon, 1 Jun 2020 00:05:26 -0700	[thread overview]
Message-ID: <20200601070526.GD11054@sol.localdomain> (raw)
In-Reply-To: <20200530204132.GE19604@bombadil.infradead.org>

On Sat, May 30, 2020 at 01:41:32PM -0700, Matthew Wilcox wrote:
> On Sat, May 30, 2020 at 10:35:47AM -0700, Eric Biggers wrote:
> > On Sat, May 30, 2020 at 10:18:14AM -0700, Matthew Wilcox wrote:
> > > On Fri, May 29, 2020 at 11:02:16PM -0700, Eric Biggers wrote:
> > > > +	if (len <= DNAME_INLINE_LEN - 1) {
> > > > +		unsigned int i;
> > > > +
> > > > +		for (i = 0; i < len; i++)
> > > > +			strbuf[i] = READ_ONCE(str[i]);
> > > > +		strbuf[len] = 0;
> > > 
> > > This READ_ONCE is going to force the compiler to use byte accesses.
> > > What's wrong with using a plain memcpy()?
> > > 
> > 
> > It's undefined behavior when the source can be concurrently modified.
> > 
> > Compilers can assume that it's not, and remove the memcpy() (instead just using
> > the source data directly) if they can prove that the destination array is never
> > modified again before it goes out of scope.
> > 
> > Do you have any suggestions that don't involve undefined behavior?
> 
> void *memcpy_unsafe(void *dst, volatile void *src, __kernel_size_t);
> 
> It can just call memcpy() of course, but the compiler can't reason about
> this function because it's not a stdlib function.

The compiler can still reason about it if it's in the same file, if it's an
inline function, or if link-time-optimization is enabled.  (LTO isn't yet
supported by the mainline kernel, but people have been working on it.)

Also, as I mentioned to Al, it's necessary to cast away 'volatile' to call
memcpy().  So the 'volatile' serves no purpose.

How about using barrier(), which expands to  asm("" : : : "memory") to tell the
compiler that memory was clobbered?

        if (len <= DNAME_INLINE_LEN - 1) {
                memcpy(strbuf, str, len);
                strbuf[len] = 0;
                /* prevent compiler from optimizing out the temporary buffer */
                barrier();
        }

I think it's still technically undefined to call memcpy() on concurrently
modified memory at all, but I think the above would be okay in practice...

Using 'noinline' could be another option.

- Eric

WARNING: multiple messages have this Message-ID (diff)
From: Eric Biggers <ebiggers@kernel.org>
To: Matthew Wilcox <willy@infradead.org>
Cc: Daniel Rosenberg <drosen@google.com>,
	stable@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net,
	Al Viro <viro@zeniv.linux.org.uk>,
	linux-fsdevel@vger.kernel.org, linux-ext4@vger.kernel.org,
	Gabriel Krisman Bertazi <krisman@collabora.co.uk>
Subject: Re: [f2fs-dev] [PATCH] ext4: avoid utf8_strncasecmp() with unstable name
Date: Mon, 1 Jun 2020 00:05:26 -0700	[thread overview]
Message-ID: <20200601070526.GD11054@sol.localdomain> (raw)
In-Reply-To: <20200530204132.GE19604@bombadil.infradead.org>

On Sat, May 30, 2020 at 01:41:32PM -0700, Matthew Wilcox wrote:
> On Sat, May 30, 2020 at 10:35:47AM -0700, Eric Biggers wrote:
> > On Sat, May 30, 2020 at 10:18:14AM -0700, Matthew Wilcox wrote:
> > > On Fri, May 29, 2020 at 11:02:16PM -0700, Eric Biggers wrote:
> > > > +	if (len <= DNAME_INLINE_LEN - 1) {
> > > > +		unsigned int i;
> > > > +
> > > > +		for (i = 0; i < len; i++)
> > > > +			strbuf[i] = READ_ONCE(str[i]);
> > > > +		strbuf[len] = 0;
> > > 
> > > This READ_ONCE is going to force the compiler to use byte accesses.
> > > What's wrong with using a plain memcpy()?
> > > 
> > 
> > It's undefined behavior when the source can be concurrently modified.
> > 
> > Compilers can assume that it's not, and remove the memcpy() (instead just using
> > the source data directly) if they can prove that the destination array is never
> > modified again before it goes out of scope.
> > 
> > Do you have any suggestions that don't involve undefined behavior?
> 
> void *memcpy_unsafe(void *dst, volatile void *src, __kernel_size_t);
> 
> It can just call memcpy() of course, but the compiler can't reason about
> this function because it's not a stdlib function.

The compiler can still reason about it if it's in the same file, if it's an
inline function, or if link-time-optimization is enabled.  (LTO isn't yet
supported by the mainline kernel, but people have been working on it.)

Also, as I mentioned to Al, it's necessary to cast away 'volatile' to call
memcpy().  So the 'volatile' serves no purpose.

How about using barrier(), which expands to  asm("" : : : "memory") to tell the
compiler that memory was clobbered?

        if (len <= DNAME_INLINE_LEN - 1) {
                memcpy(strbuf, str, len);
                strbuf[len] = 0;
                /* prevent compiler from optimizing out the temporary buffer */
                barrier();
        }

I think it's still technically undefined to call memcpy() on concurrently
modified memory at all, but I think the above would be okay in practice...

Using 'noinline' could be another option.

- Eric


_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel

  reply	other threads:[~2020-06-01  7:05 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-30  6:02 [PATCH] ext4: avoid utf8_strncasecmp() with unstable name Eric Biggers
2020-05-30  6:02 ` [f2fs-dev] " Eric Biggers
2020-05-30  6:17 ` Gabriel Krisman Bertazi
2020-05-30  6:17   ` [f2fs-dev] " Gabriel Krisman Bertazi
2020-05-30  6:44   ` Eric Biggers
2020-05-30  6:44     ` [f2fs-dev] " Eric Biggers
2020-05-30  6:52     ` Gabriel Krisman Bertazi
2020-05-30 17:18 ` Matthew Wilcox
2020-05-30 17:18   ` [f2fs-dev] " Matthew Wilcox
2020-05-30 17:35   ` Eric Biggers
2020-05-30 17:35     ` [f2fs-dev] " Eric Biggers
2020-05-30 17:59     ` Al Viro
2020-05-30 17:59       ` [f2fs-dev] " Al Viro
2020-06-01  6:45       ` Eric Biggers
2020-06-01  6:45         ` [f2fs-dev] " Eric Biggers
2020-05-30 20:41     ` Matthew Wilcox
2020-05-30 20:41       ` [f2fs-dev] " Matthew Wilcox
2020-06-01  7:05       ` Eric Biggers [this message]
2020-06-01  7:05         ` Eric Biggers

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=20200601070526.GD11054@sol.localdomain \
    --to=ebiggers@kernel.org \
    --cc=drosen@google.com \
    --cc=krisman@collabora.co.uk \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-f2fs-devel@lists.sourceforge.net \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=stable@vger.kernel.org \
    --cc=viro@zeniv.linux.org.uk \
    --cc=willy@infradead.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.