From patchwork Mon Oct 26 10:58:15 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Daniel Vetter X-Patchwork-Id: 286081 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=-12.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH, MAILING_LIST_MULTI, SIGNED_OFF_BY, SPF_HELO_NONE, SPF_PASS, URIBL_BLOCKED, USER_AGENT_GIT autolearn=unavailable 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 CDCEBC64E7A for ; Mon, 26 Oct 2020 10:59:19 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 7FC7922282 for ; Mon, 26 Oct 2020 10:59:19 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=ffwll.ch header.i=@ffwll.ch header.b="IAPjgKcv" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1772909AbgJZK7S (ORCPT ); Mon, 26 Oct 2020 06:59:18 -0400 Received: from mail-wm1-f67.google.com ([209.85.128.67]:52112 "EHLO mail-wm1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1772829AbgJZK6o (ORCPT ); Mon, 26 Oct 2020 06:58:44 -0400 Received: by mail-wm1-f67.google.com with SMTP id v5so11154231wmh.1 for ; Mon, 26 Oct 2020 03:58:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ffwll.ch; s=google; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=r2DrHs8sznEAEmv81CQMiKCncSgZZXtZ6EFyoHCS3Oo=; b=IAPjgKcv++FEEE84FiAz/g3AfnWvmZMpU9H7Fwm1WL4AMstvKx9gvt+rXcwAOTRbDK 6a1AtVrgavJFgYhQUvzJVjH76fwMqfa/xnNnbs3W1DhPD+Bm1dsHsK4sYyrLgyoyHCLf eFIJ8x2oK5YeCTNuA5CDBens+NuAE1+STEad8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=r2DrHs8sznEAEmv81CQMiKCncSgZZXtZ6EFyoHCS3Oo=; b=i7Dlba20RN1IwQ0eh8MtexTCkw07cNzdt+jOU3cMGLc03+pKk5SGsTATEhF07QJD3P qOxnhULL16cF2XpZdDrYB1+izaBkXdvl/3zm0JaiDUc2cZzoCWIavoPOn3xStwaxAdu0 CyDyvD8C5i2rR/Xe4ykcsWwekpP70kzog5K6GXJfes7uHch25O1ZTBnUJDPCe/EvwdO3 MKt70gXmfxlp49VRzuSarVbP2/cm2vYuayT4kGO9PnJFLDkn2bwPwJuDELYviCHNy/c4 nqyy5Y2Ywm3ZG6+U9v0bJ7xT8HgLWyVnZQYKFSvFXRzv1FneFkTsQPtdYjV/XhJ7gzeW Iq0w== X-Gm-Message-State: AOAM530oNyqxKhFJ/SwlZGuLCtctmFx9w0MQQcdWkIWKvDLb2foz50hp 1/Ct1NcwfGzgqEKJH1tuLV0COp4oPJ8o96v4 X-Google-Smtp-Source: ABdhPJwJv3Tt2Tk4//M2w0Xpcu1n8KPpAvO5lQ1RgvLykelcS/PnORqYG+qfi62iuVn2XcVOIRnemw== X-Received: by 2002:a7b:c181:: with SMTP id y1mr15197304wmi.58.1603709922604; Mon, 26 Oct 2020 03:58:42 -0700 (PDT) Received: from phenom.ffwll.local ([2a02:168:57f4:0:efd0:b9e5:5ae6:c2fa]) by smtp.gmail.com with ESMTPSA id w83sm21165156wmg.48.2020.10.26.03.58.41 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 26 Oct 2020 03:58:41 -0700 (PDT) From: Daniel Vetter To: DRI Development , LKML Cc: kvm@vger.kernel.org, linux-mm@kvack.org, linux-arm-kernel@lists.infradead.org, linux-samsung-soc@vger.kernel.org, linux-media@vger.kernel.org, linux-s390@vger.kernel.org, Daniel Vetter , Daniel Vetter , Jason Gunthorpe , Kees Cook , Dan Williams , Andrew Morton , John Hubbard , =?utf-8?b?SsOpcsO0bWUgR2xpc3Nl?= , Jan Kara Subject: [PATCH v4 12/15] /dev/mem: Only set filp->f_mapping Date: Mon, 26 Oct 2020 11:58:15 +0100 Message-Id: <20201026105818.2585306-13-daniel.vetter@ffwll.ch> X-Mailer: git-send-email 2.28.0 In-Reply-To: <20201026105818.2585306-1-daniel.vetter@ffwll.ch> References: <20201026105818.2585306-1-daniel.vetter@ffwll.ch> MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: linux-media@vger.kernel.org When we care about pagecache maintenance, we need to make sure that both f_mapping and i_mapping point at the right mapping. But for iomem mappings we only care about the virtual/pte side of things, so f_mapping is enough. Also setting inode->i_mapping was confusing me as a driver maintainer, since in e.g. drivers/gpu we don't do that. Per Dan this seems to be copypasta from places which do care about pagecache consistency, but not needed. Hence remove it for slightly less confusion. Signed-off-by: Daniel Vetter Cc: Jason Gunthorpe Cc: Kees Cook Cc: Dan Williams Cc: Andrew Morton Cc: John Hubbard Cc: Jérôme Glisse Cc: Jan Kara Cc: Dan Williams Cc: linux-mm@kvack.org Cc: linux-arm-kernel@lists.infradead.org Cc: linux-samsung-soc@vger.kernel.org Cc: linux-media@vger.kernel.org Reviewed-by: Dan Williams Signed-off-by: Daniel Vetter --- drivers/char/mem.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/char/mem.c b/drivers/char/mem.c index abd4ffdc8cde..5502f56f3655 100644 --- a/drivers/char/mem.c +++ b/drivers/char/mem.c @@ -864,7 +864,6 @@ static int open_port(struct inode *inode, struct file *filp) * revocations when drivers want to take over a /dev/mem mapped * range. */ - inode->i_mapping = devmem_inode->i_mapping; filp->f_mapping = inode->i_mapping; return 0;