linux-kernel - Re: [PATCH] mm-move-mremap-from-file_operations-to-vm_operations

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 17 Jul 2015 20:54:34 +0200
From:	Oleg Nesterov <oleg@...hat.com>
To:	Austin S Hemmelgarn <ahferroin7@...il.com>
Cc:	Benjamin LaHaise <bcrl@...ck.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Joonsoo Kim <js1304@...il.com>,
	Fengguang Wu <fengguang.wu@...el.com>,
	Jeff Moyer <jmoyer@...hat.com>,
	Johannes Weiner <hannes@...xchg.org>,
	Stephen Rothwell <sfr@...b.auug.org.au>,
	linux-next@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH]
	mm-move-mremap-from-file_operations-to-vm_operations_struct-fix

On 07/17, Austin S Hemmelgarn wrote:
>
> On 2015-07-17 14:19, Oleg Nesterov wrote:
>> On 07/17, Austin S Hemmelgarn wrote:
>>>
>>> On 2015-07-17 13:55, Oleg Nesterov wrote:
>>>> On 07/17, Benjamin LaHaise wrote:
>>>>>
>>>>> 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."
>>>>
>>>> There is another interpretation: I think this code must be never called,
>>>> if it is actually called we have a serious problem which should be loudly
>>>> reported.
>>>>
>>> And not compiling it at all _will_ loudly report it, it'll just report
>>> it during linking instead of at run-time, which is a much better time to
>>> shout about it.
>>
>> And how can we do this?
>>
> If a function that isn't defined (for example, you use a #if block to
> comment it out under certain circumstances), then the link will fail
> rather noisily something references it.

This is what we are trying to fix.

> We already know during the
> compile that it's a NOMMU kernel, so anything that calls it on a MMU
> enabled kernel can have a compile time check added

It already has. memory.c is not compiled if NOMMU.

The problem is aio_ring_vm_ops which references this function. And btw
filemap_fault() too.

And just in case, I won't mind to add ifdef(CONFIG_MMU) there, I am
waiting for reply from Benjamin.

> instead of doing the
> check at runtime (or even just calling it without checking), thus even
> further reducing code size.

So what exactly do you suggest to fix the problem?

I agree with any solution which satisfies the maintainers.

Oleg.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/