Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp3810872ybl; Mon, 13 Jan 2020 03:04:55 -0800 (PST) X-Google-Smtp-Source: APXvYqzZw57obBPDsYKLnGGU+StswGSXgRuvej/EjjFeEo7JFjBZHIKSMJRKEJNfSQ58lxOhM8CD X-Received: by 2002:a05:6830:1e30:: with SMTP id t16mr12794732otr.220.1578913495008; Mon, 13 Jan 2020 03:04:55 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1578913495; cv=none; d=google.com; s=arc-20160816; b=US5SvFtBymwF7pI4Wvt3ctFYUA8o5kJ4ZiuOAn/wse5hDl7KuOTETI4CuKCpoUOHA0 lffCBhhLP+oFTrez/B+iE0i3pPNeA5MGb7+h9tvYnw0UfPGyUARXmhb7piFLeuclr20O kUMw3i0Mn/OqNCZVNmFQdCxQj/XRrDFFwAYEEk1sPTLmTOW8G2zPXqYKhR8Z/Nx0DdBE 8kYKtWNWS3MEZluSOzDlCM6hhh+PoIzJ2r0c3nfXlNHdO5TDUcDIqFjitxIaKA6Cc1zb fk+HpjZ5iweTKas9QO8GdNYIjUuaKiBli1LkdsrFX16GAlUQLxME6rKKNkWkqNyz+pD8 DYrA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:message-id:content-transfer-encoding :mime-version:date:subject:cc:to:from; bh=zSUHTcP7h555X3YP5/2xW6SGXX2Bwpz5YFauPDJjLAE=; b=Ja7pdr732pt8PLnNRVmWMXIJ0Kj8oej3U19mioXz+JCFsTw6U9dCz2nqHvuzyF3KcQ O2JeYizLNQryMQ5nv+a9fJZDq+E3QoylZNx1jJ8fpPn50cqTFdCez/4DkGxQ+RUbE+IQ WvfIzxsrOsIAv/v3maoDUfziqdL+yPqMejQo5n8ftBYQdB1MuEewQIhIrBpyJeMN6aDd ze3vSspdCc5taD2ivepNryI5oCLJ1BNxGvW9pVJtRXM+dxgOUbiP3YJlApBlEKNqUroW Zsirp3zXTXJWaok8PwtbPVa3PfIByWqzBBjRKPgTDXei/tn+EeBJfjOMtjfhziYvxFi1 4ntw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-ext4-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=ibm.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id v5si5643215oix.197.2020.01.13.03.04.32; Mon, 13 Jan 2020 03:04:54 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-ext4-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-ext4-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=ibm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726127AbgAMLEc (ORCPT + 99 others); Mon, 13 Jan 2020 06:04:32 -0500 Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:46514 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725992AbgAMLEc (ORCPT ); Mon, 13 Jan 2020 06:04:32 -0500 Received: from pps.filterd (m0098410.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 00DAvkSD121645 for ; Mon, 13 Jan 2020 06:04:30 -0500 Received: from e06smtp05.uk.ibm.com (e06smtp05.uk.ibm.com [195.75.94.101]) by mx0a-001b2d01.pphosted.com with ESMTP id 2xfbs7n5d6-1 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=NOT) for ; Mon, 13 Jan 2020 06:04:30 -0500 Received: from localhost by e06smtp05.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Mon, 13 Jan 2020 11:04:28 -0000 Received: from b06avi18626390.portsmouth.uk.ibm.com (9.149.26.192) by e06smtp05.uk.ibm.com (192.168.101.135) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; (version=TLSv1/SSLv3 cipher=AES256-GCM-SHA384 bits=256/256) Mon, 13 Jan 2020 11:04:26 -0000 Received: from d06av24.portsmouth.uk.ibm.com (d06av24.portsmouth.uk.ibm.com [9.149.105.60]) by b06avi18626390.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 00DB3a2B35127708 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 13 Jan 2020 11:03:37 GMT Received: from d06av24.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 535874204C; Mon, 13 Jan 2020 11:04:25 +0000 (GMT) Received: from d06av24.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 5B27F42045; Mon, 13 Jan 2020 11:04:24 +0000 (GMT) Received: from dhcp-9-199-159-93.in.ibm.com (unknown [9.199.159.93]) by d06av24.portsmouth.uk.ibm.com (Postfix) with ESMTP; Mon, 13 Jan 2020 11:04:24 +0000 (GMT) From: Ritesh Harjani To: linux-ext4@vger.kernel.org Cc: tytso@mit.edu, jack@suse.cz, Ritesh Harjani Subject: [RFC 0/2] ext4: Fix stale data read exposure problem with DIO read/page_mkwrite Date: Mon, 13 Jan 2020 16:34:20 +0530 X-Mailer: git-send-email 2.21.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-TM-AS-GCONF: 00 x-cbid: 20011311-0020-0000-0000-000003A034CA X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 20011311-0021-0000-0000-000021F7A37B Message-Id: X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138,18.0.572 definitions=2020-01-13_03:2020-01-13,2020-01-13 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 phishscore=0 priorityscore=1501 mlxlogscore=969 suspectscore=0 adultscore=0 clxscore=1011 bulkscore=0 malwarescore=0 impostorscore=0 mlxscore=0 lowpriorityscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1910280000 definitions=main-2001130094 Sender: linux-ext4-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org Hello All, Sorry for the delay on this patchset. I guess it's because there were lot of other context switches while working at it. Please note that this is a RFC patch and also a WIP (due to a open problem listed below). There is also another thread going on where making dioread_nolock as default mount opt [1] is being discussed. That approach should also solve the given race at hand. But since nothing is finalized yet, so I wanted to get this patch out for early review/discussion. About patch =========== Currently there is a small race window as pointed out by Jan [2] where, when ext4 tries to allocate a written block for mapped files and if DIO read is in progress, then this may result into stale data read exposure problem. This patch tries to fix the mentioned issue by: 1. For non-delalloc path, page_mkwrite will use unwritten blocks by default for extent based files. 2. For delalloc path, we check if DIO is in progress during writeback. If yes, then we use unwritten blocks method to avoid this race. Patch-1: This moves the inode_dio_begin() call before calling for filemap_write_and_wait_range. Patch-2: This implementes the points (1) & (2) mentioned above. Testing: ======== xfstests "-g auto" ran fine except one warn_on issue. Below tests are giving kernel WARN_ON from "ext4_journalled_invalidatepage()", with 1024 blocksize, 4K pagesize & with "nodelalloc,data=journal" mount opt. - generic/013, generic/269, generic/270 In case if someone has any pointers around this, I could dig more deeper into this. References ========== [1] https://www.spinics.net/lists/linux-ext4/msg69224.html [2] https://lore.kernel.org/linux-ext4/20190926134726.GA28555@quack2.suse.cz/ Ritesh Harjani (2): iomap: direct-io: Move inode_dio_begin before filemap_write_and_wait_range ext4: Fix stale data read issue with DIO read & ext4_page_mkwrite path fs/ext4/inode.c | 45 +++++++++++++++++++++++++++++++------------- fs/iomap/direct-io.c | 17 +++++++++++++---- 2 files changed, 45 insertions(+), 17 deletions(-) -- 2.21.0