From: Michael Schmitz <schmitzmic@gmail.com>
To: Christoph Hellwig <hch@lst.de>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
Geert Uytterhoeven <geert@linux-m68k.org>,
linux-m68k <linux-m68k@lists.linux-m68k.org>
Subject: Re: [PATCH RFC v2] m68k: remove get_fs()/set_fs()
Date: Fri, 9 Jul 2021 12:31:45 +1200 [thread overview]
Message-ID: <21557cf4-e1a7-69c3-7c67-c7d4e5a6fbf7@gmail.com> (raw)
In-Reply-To: <bf4ad0a4-5cd4-4e82-8513-64ab47d5e522@gmail.com>
Hi Christoph,
On 9/07/21 7:28 am, Michael Schmitz wrote:
>
> On 9/07/21 12:57 am, Christoph Hellwig wrote:
>> I've force pushed a new version to the branch, can you give it a spin?
>
> Still the same fault (can't start init). But as Linus pointed out,
> your __constant_copy_to_user() is still broken.
Forget that - got my git am munged up (applied yesterday's patch a
second time, eek).
That patch works fine on a casual test. What you did to
__constant_copy_to_user() does not appear to matter - but I haven't put
the system under any kind of stress yet. I'm a little reluctant to do
that (recovering from a trashed boot disk is a little dicey), I'll
probably only try that with your changes to __constant_copy_to_user()
from commit d36105c942e0 backed out.
That still leaves the issue of __constant_copy_to_user() possibly
returning -EFAULT instead of the number of residual bytes to copy, but
we can probably live with that for now (__constant_copy_to_user_asm()
doesn't actually calculate the residual but just sets it to the number
of bytes originally to be copied, which is the best we can do with the
scheme used there).
Cheers,
Michael
next prev parent reply other threads:[~2021-07-09 0:31 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-07-08 1:48 [PATCH RFC v2] m68k: remove get_fs()/set_fs() Michael Schmitz
2021-07-08 2:51 ` Linus Torvalds
2021-07-08 3:01 ` Linus Torvalds
2021-07-08 3:37 ` Michael Schmitz
2021-07-08 4:31 ` Christoph Hellwig
2021-07-08 4:33 ` Michael Schmitz
2021-07-08 4:58 ` Christoph Hellwig
2021-07-08 5:48 ` Michael Schmitz
2021-07-08 12:57 ` Christoph Hellwig
2021-07-08 18:20 ` Linus Torvalds
2021-07-09 0:05 ` Michael Schmitz
2021-07-08 19:28 ` Michael Schmitz
2021-07-09 0:31 ` Michael Schmitz [this message]
2021-07-09 4:22 ` Christoph Hellwig
2021-07-09 5:47 ` Michael Schmitz
2021-07-09 7:29 ` Geert Uytterhoeven
2021-07-09 8:34 ` Michael Schmitz
2021-07-09 8:53 ` Christoph Hellwig
2021-07-09 9:00 ` Michael Schmitz
2021-07-09 11:20 ` Geert Uytterhoeven
2021-07-09 19:25 ` Michael Schmitz
2021-07-09 19:52 ` Michael Schmitz
2021-07-09 20:03 ` Linus Torvalds
2021-07-09 20:13 ` Linus Torvalds
2021-07-09 19:53 ` Linus Torvalds
2021-07-09 21:08 ` Michael Schmitz
2021-07-09 21:18 ` Linus Torvalds
2021-07-10 2:30 ` Michael Schmitz
2021-07-09 11:35 ` Geert Uytterhoeven
2021-07-08 7:36 ` Andreas Schwab
2021-07-08 4:28 ` 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=21557cf4-e1a7-69c3-7c67-c7d4e5a6fbf7@gmail.com \
--to=schmitzmic@gmail.com \
--cc=geert@linux-m68k.org \
--cc=hch@lst.de \
--cc=linux-m68k@lists.linux-m68k.org \
--cc=torvalds@linux-foundation.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 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).