From: Benjamin LaHaise <bcrl@kvack.org>
To: Oleg Nesterov <oleg@redhat.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Joonsoo Kim <js1304@gmail.com>,
Fengguang Wu <fengguang.wu@intel.com>,
Jeff Moyer <jmoyer@redhat.com>,
Johannes Weiner <hannes@cmpxchg.org>,
Stephen Rothwell <sfr@canb.auug.org.au>,
linux-next@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] mm-move-mremap-from-file_operations-to-vm_operations_struct-fix
Date: Fri, 17 Jul 2015 13:37:57 -0400 [thread overview]
Message-ID: <20150717173757.GD2779@kvack.org> (raw)
In-Reply-To: <20150717172726.GA30443@redhat.com>
On Fri, Jul 17, 2015 at 07:27:26PM +0200, Oleg Nesterov wrote:
> Benjamin,
>
> it seems that we do not understand each other,
...
> >
> > Either try to fix it correctly,
>
> And I think this fix is correct. In a sense that we only add
> filemap_page_mkwrite() to make the linker happy, it can never be called
> and thus we can never hit this BUG().
>
> Please look at filemap_fault() in nommu.c,
>
> int filemap_fault(struct vm_area_struct *vma, struct vm_fault *vmf)
> {
> BUG();
> return 0;
> }
>
> this is the same thing. If nothing else, mm/memory.c is not even compiled
> if NOMMU.
Using BUG() is the wrong approach. If the code is not needed in NOMMU, then
#ifdef it out. Think about it: NOMMU systems are very low memory systems
and they should not have dead code compiled in if it is not needed.
> > or disable the config.
>
> Yes, I think this makes more sense. but see below...
>
> > Making it just
> > compile but be knowingly broken is worse than either of those 2 options.
>
> Why? See above. I think this change makes no difference except it fixes
> the build.
>
> Again, of course I could miss something. Could you explain your point?
Don't add BUG(). It's the equivalent approach of saying "I think this code
isn't needed, but I'm lazy and not going to remove it properly."
> > My point was that it is valid for someone to want to use the functionality
> > on a nommu system, and given that it should have worked before the page
> > migration code was added, It Would Be Nice(tm) to return it to that state.
>
> Perhaps it worked on NOMMU before, I have no idea. But currently, afaics,
> it can not. Even sys_io_setup() can't suceed. So I do not understand why
> do we allow NOMMU && CONFIG_AIO.
>
> But this is another issue. Of course I won't insist, please forget.
As I said in my earlier email: aio on NOMMU was broken by the page migration
code that was added in mid 3.1x. Fixing it should not be that hard.
>
> > Adding a BUG() like that to the code is just plain broken.
>
> Why? Could you explain what I have missed?
It's doing half the job. Either the code should be #if'd out or not.
-ben
> Oleg.
--
"Thought is the essence of where you are now."
next prev parent reply other threads:[~2015-07-17 17:37 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-16 23:14 [PATCH] mm-move-mremap-from-file_operations-to-vm_operations_struct-fix Oleg Nesterov
2015-07-16 23:22 ` Stephen Rothwell
2015-07-16 23:24 ` Andrew Morton
2015-07-16 23:52 ` Oleg Nesterov
2015-07-17 14:06 ` Benjamin LaHaise
2015-07-17 17:27 ` Oleg Nesterov
2015-07-17 17:37 ` Benjamin LaHaise [this message]
2015-07-17 17:55 ` Oleg Nesterov
2015-07-17 18:12 ` Austin S Hemmelgarn
2015-07-17 18:19 ` Oleg Nesterov
2015-07-17 18:39 ` Austin S Hemmelgarn
2015-07-17 18:54 ` Oleg Nesterov
2015-07-17 19:09 ` Austin S Hemmelgarn
2015-07-17 22:56 ` Oleg Nesterov
2015-07-17 22:31 ` Oleg Nesterov
2015-07-20 14:22 ` Jeff Moyer
2015-07-20 17:33 ` Oleg Nesterov
2015-07-20 17:51 ` Benjamin LaHaise
2015-07-20 18:30 ` Jeff Moyer
2015-07-20 18:31 ` Oleg Nesterov
2015-07-20 19:24 ` Oleg Nesterov
2015-07-20 19:39 ` Benjamin LaHaise
2015-07-20 20:03 ` Oleg Nesterov
2015-07-21 15:29 ` [PATCH v2] mm-move-mremap-from-file_operations-to-vm_operations_struct-fix Oleg Nesterov
2015-07-21 15:38 ` Benjamin LaHaise
2015-07-21 16:18 ` Oleg Nesterov
2015-07-21 16:20 ` [PATCH v3] mm-move-mremap-from-file_operations-to-vm_operations_struct-fix Oleg Nesterov
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=20150717173757.GD2779@kvack.org \
--to=bcrl@kvack.org \
--cc=akpm@linux-foundation.org \
--cc=fengguang.wu@intel.com \
--cc=hannes@cmpxchg.org \
--cc=jmoyer@redhat.com \
--cc=js1304@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-next@vger.kernel.org \
--cc=oleg@redhat.com \
--cc=sfr@canb.auug.org.au \
/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).