From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.6 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0855AC0018C for ; Fri, 4 Dec 2020 19:53:35 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 1552D22582 for ; Fri, 4 Dec 2020 19:53:33 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 1552D22582 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=infradead.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 5F9526B0036; Fri, 4 Dec 2020 14:53:33 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 5A95F6B005C; Fri, 4 Dec 2020 14:53:33 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4BDFF6B005D; Fri, 4 Dec 2020 14:53:33 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0128.hostedemail.com [216.40.44.128]) by kanga.kvack.org (Postfix) with ESMTP id 334636B0036 for ; Fri, 4 Dec 2020 14:53:33 -0500 (EST) Received: from smtpin29.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id E2E56181AC553 for ; Fri, 4 Dec 2020 19:53:32 +0000 (UTC) X-FDA: 77556649464.29.kite88_480caaa273c7 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin29.hostedemail.com (Postfix) with ESMTP id A55B7180868DF for ; Fri, 4 Dec 2020 19:53:32 +0000 (UTC) X-HE-Tag: kite88_480caaa273c7 X-Filterd-Recvd-Size: 3780 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf48.hostedemail.com (Postfix) with ESMTP for ; Fri, 4 Dec 2020 19:53:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=tM/EF1zobTNDLoJZIcx9y7SBvpWLPM3jHAoQD68psVI=; b=YtvMInOrdKGP7IEuDjxROBxqvG Qo/9aZd2M5zXOJwEGHYt3O4JxtqvsdzJeMAcecLY8UPwhJlw5a6ipWqovnu0w7TxxySp7e9xS+NHL BND9m8Lqwm8VPsYY4lv1V4B0H8j7cPWc5joVBEhPC6+OaESofuQXI6LQLMuw5wV2jCvwnnvNutSbE zHNCipJHwlwJm4gClmGltUSOP9x6OcBNVYUIryD5bgaIpJxQZl7E0fR07a+1i3lOG/uNDZDIhN1ei HrzC8qcilLc+gPwDgSbFPjFQO99Gq9BVAvsusw0vGOcYF5GxFCfH/Fu4LfZbdbxM/cP+2IGrdbMhb yZgxm0Hg==; Received: from willy by casper.infradead.org with local (Exim 4.92.3 #3 (Red Hat Linux)) id 1klH8s-0003nW-1w; Fri, 04 Dec 2020 19:53:22 +0000 Date: Fri, 4 Dec 2020 19:53:21 +0000 From: Matthew Wilcox To: Jason Gunthorpe Cc: David Hildenbrand , Liu Zixian , akpm@linux-foundation.org, linmiaohe@huawei.com, louhongxiang@huawei.com, linux-mm@kvack.org, hushiyuan@huawei.com, stable@vger.kernel.org, davem@davemloft.net Subject: Re: [PATCH v2] fix mmap return value when vma is merged after call_mmap() Message-ID: <20201204195321.GQ11935@casper.infradead.org> References: <20201203085350.22624-1-liuzixian4@huawei.com> <20201204151028.GZ5487@ziepe.ca> <20201204152535.GP11935@casper.infradead.org> <20201204160451.GC5487@ziepe.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20201204160451.GC5487@ziepe.ca> X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Fri, Dec 04, 2020 at 12:04:51PM -0400, Jason Gunthorpe wrote: > On Fri, Dec 04, 2020 at 03:25:35PM +0000, Matthew Wilcox wrote: > > > This commit makes no sense. I know it's eight years old, so maybe the > > device driver which did this has long been removed from the tree, but > > davem's comment was (iirc) related to a device driver for a graphics > > card that would 256MB-align the user address. Another possibility is > > that userspace always asks for a 256MB-aligned address these days. > > Presumably the latter, otherwise people would be complaining about the > WARN_ON. > > With some grep I could only find this: > > static int mc68x328fb_mmap(struct fb_info *info, struct vm_area_struct *vma) > { > #ifndef MMU > /* this is uClinux (no MMU) specific code */ > > vma->vm_flags |= VM_DONTEXPAND | VM_DONTDUMP; > vma->vm_start = videomemory; > > return 0; > #else > return -EINVAL; > #endif > } > > So it does seem gone I found some buggy, uncompilable code in binder that used to modify it: -#ifdef CONFIG_CPU_CACHE_VIPT - if (cache_is_vipt_aliasing()) { - while (CACHE_COLOUR( - pr_info("%s: %d %lx-%lx maps %pK bad alignment\n", - __func__, - alloc->pid, vma->vm_start, vma->vm_end, - alloc->buffer); - vma->vm_start += PAGE_SIZE; - } - } -#endif pretty sure that even if the syntax error were fixed, it would have done something awful and wrong. It seems like it used to be quite popular to do it for nommu-fb-mmap, but it fell out of favour. If there was a sparc fb driver that did it, it got deleted before 2.6.12-rc2, so I don't really care. So yes, let's turn this into a BUG_ON.