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=-5.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,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 1AFE0C4361A for ; Fri, 4 Dec 2020 16:04:56 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id A3A9D2223E for ; Fri, 4 Dec 2020 16:04:55 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org A3A9D2223E Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=ziepe.ca Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id EEED46B0068; Fri, 4 Dec 2020 11:04:54 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id EA0CB6B006E; Fri, 4 Dec 2020 11:04:54 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D8ED66B0070; Fri, 4 Dec 2020 11:04:54 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0165.hostedemail.com [216.40.44.165]) by kanga.kvack.org (Postfix) with ESMTP id C3A8C6B0068 for ; Fri, 4 Dec 2020 11:04:54 -0500 (EST) Received: from smtpin04.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 809F0181AEF1F for ; Fri, 4 Dec 2020 16:04:54 +0000 (UTC) X-FDA: 77556073308.04.range32_1a15a83273c5 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin04.hostedemail.com (Postfix) with ESMTP id 5E9FC800CCEB for ; Fri, 4 Dec 2020 16:04:54 +0000 (UTC) X-HE-Tag: range32_1a15a83273c5 X-Filterd-Recvd-Size: 4849 Received: from mail-qk1-f193.google.com (mail-qk1-f193.google.com [209.85.222.193]) by imf17.hostedemail.com (Postfix) with ESMTP for ; Fri, 4 Dec 2020 16:04:53 +0000 (UTC) Received: by mail-qk1-f193.google.com with SMTP id h20so5849967qkk.4 for ; Fri, 04 Dec 2020 08:04:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ziepe.ca; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=t0GCmJXgaqj4UXo3UFBFtaMB4ClFHGw5pCLgLGBtmZQ=; b=KLtoAV9IAem35cnxS9GOLj3tKU9CiXNaFVjcdnv/3irI1S7qPEmZMX6xJw6l2Vwz/g 1M/f1B6XM+eJK1OkWwnXpczProXkASFPpuYD3mgAg50qImcxnaoLhYvUOssCAo+Blc33 aaCV1NbtiAmavvO9eHpxXDG6gDPlt+zKqHBeQFui9gKIOzfBrbzSM28SeDqbzAQg0kAB nu+QQKP3iTlatfydG4ko6auwEpHf+uSbDYK/yCLVdZ0kY4TIwgBz60idtBjPY0q8EgRd m0EVSYVmzFeEULgbtQV4OFiLcVjlOv62xO7+D7SDgtFOLSMs4LJoFGmgZfW7CdsMhJVE f+dA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=t0GCmJXgaqj4UXo3UFBFtaMB4ClFHGw5pCLgLGBtmZQ=; b=eeX4gqI7wYoaAnMfJGNlX0uIalcak0YXWLhiBAP0jkYyNdPRPGO0lSzg4IzndfE71W 1RnTrFTjGxBkok0wPFyMGwNmomu2Hms0n71YgsoviforDcBwlwPCrSndK9ISjaZWGY6S 1UMOmN4nVgdqVTOI0FsDy/i8LbRPikdKLN3o9aXDa8QERUPSu+VhFh0EjKVFRnDVEJbC vCqbIGtoiqZgiIlp0rvNwJ4Qt7a3toSlFSDJlf06ic4+r9Etmepr31tuAPhNAtbu0U9E na3yhkrGJ5SRmcV0911u6EnzXC3grRlRD5q+LRLKp9j5ncuREFaiNYFd2/h76MnE8Q/V pSLg== X-Gm-Message-State: AOAM533VMLLHYpa3YxLBvfVNOW+rDa/CeEysRcrObslLTzspAJveAM+U bOTvqC9MskVgFqcMITEHvx4y1A== X-Google-Smtp-Source: ABdhPJxvFR4PO1GXMK5tgLDtHDnkm5Haqc/tcb8xV0C4LLeKYdLthYihVjco8s/ed2WrWilWaBRdpw== X-Received: by 2002:a37:9d04:: with SMTP id g4mr9419563qke.358.1607097893205; Fri, 04 Dec 2020 08:04:53 -0800 (PST) Received: from ziepe.ca (hlfxns017vw-156-34-48-30.dhcp-dynamic.fibreop.ns.bellaliant.net. [156.34.48.30]) by smtp.gmail.com with ESMTPSA id r8sm5650266qtj.94.2020.12.04.08.04.52 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 04 Dec 2020 08:04:52 -0800 (PST) Received: from jgg by mlx with local (Exim 4.94) (envelope-from ) id 1klDZj-005vUb-9w; Fri, 04 Dec 2020 12:04:51 -0400 Date: Fri, 4 Dec 2020 12:04:51 -0400 From: Jason Gunthorpe To: Matthew Wilcox 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: <20201204160451.GC5487@ziepe.ca> References: <20201203085350.22624-1-liuzixian4@huawei.com> <20201204151028.GZ5487@ziepe.ca> <20201204152535.GP11935@casper.infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20201204152535.GP11935@casper.infradead.org> 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 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 don't understand why prev/rb_link/rb_parent would need to be changed > in this case. It's going to be inserted at the exact same location in > the rbtree, just at a slightly shifted address. If the driver adjust the address, and it doesn't collide with another vma, and it doesn't change the tree position, then it could work But if the driver radically changes the vm_start all bets are off and you end up with an unsorted rb_tree at worst. Banning drivers from adjusting the vm_start/end makes sense to me, at least. How could a driver do this correctly anyhow? Jason