Received: by 2002:a05:6a10:9848:0:0:0:0 with SMTP id x8csp147244pxf; Wed, 10 Mar 2021 23:50:30 -0800 (PST) X-Google-Smtp-Source: ABdhPJw9UWsj8knbDgK+ClwI0zpgituIQxHI+kpuR5UmIGturdCKIExBx6Rl1XsWlb/mLQmOJUUr X-Received: by 2002:a17:906:1c41:: with SMTP id l1mr1781135ejg.299.1615449030004; Wed, 10 Mar 2021 23:50:30 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1615449030; cv=none; d=google.com; s=arc-20160816; b=YSnMy4W7yuE20ENzlytYCwgZ9GV5UNsut0uQKSHsbHNTU+dDuPQ553zCjHiWbHsICd NwdFGyNqMgWT341Nex3k5blKC8ohVNuYa+PRcCk9ikJRTJ9a3oowBtrX1VZbEHYIfJ/y 2p8TQ35D+7Bh8foCbhYDjU9g78OwWAN+UPwDVAevLqKXuzTp29TYlkL1Csl18qW2MFNy 3ujEsTCK9xNbiItlFGpVh0p50PxCllPZ5YF2RhJmpQ7W3aCa4E6I3j4sW05E122ZLkH1 5ftMaY/Oa2NM8YxX27dqipul75kb2lSczd1lYdLMmcNJ6SNnejCIxegvDQsn9NSGpGs0 ymgA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:content-transfer-encoding :content-language:accept-language:message-id:date:thread-index :thread-topic:subject:cc:to:from; bh=h7pcgYGhzQazqctjfMMs4BOL90L6//gIc98jXsWdgw8=; b=SPnrNCSYPpmQDhnOFcfGXEGOHwvkXdwU8B57/FR88mpPVn47D1HJEeWZowlCszDVU+ J/TTOiHAdufdCZYyeSSrEiGG22UO9avw7V42rA2yxC0jr3TlodilHmDBRtmZKFkRgGtZ y4J8k/huWHkvhpOPTB3v4X55Wg9Z/vgJkAwrvVEwEJITc7fE0sXmD/EMlWujRy0TWCNQ FDTuKtD5qWz9+nXIo6GYc5q5p8SVHkFKAISEgT1bpYxHOgt4kABdf1kDbX1eE5VhUI9a N0kv9A7zuQC3rGgWJ2Uqtgo3kV/9X3pL0g0uQOBJhhhR2NUKl15//YmxVEJZKL7G8gnE 0dRQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id a22si1272182ejp.696.2021.03.10.23.50.07; Wed, 10 Mar 2021 23:50:29 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230056AbhCKHsx convert rfc822-to-8bit (ORCPT + 99 others); Thu, 11 Mar 2021 02:48:53 -0500 Received: from szxga01-in.huawei.com ([45.249.212.187]:5087 "EHLO szxga01-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230011AbhCKHsg (ORCPT ); Thu, 11 Mar 2021 02:48:36 -0500 Received: from DGGEML402-HUB.china.huawei.com (unknown [172.30.72.55]) by szxga01-in.huawei.com (SkyGuard) with ESMTP id 4Dx1HM4FXxzYHwB; Thu, 11 Mar 2021 15:46:55 +0800 (CST) Received: from DGGEML509-MBS.china.huawei.com ([169.254.4.125]) by DGGEML402-HUB.china.huawei.com ([fe80::fca6:7568:4ee3:c776%31]) with mapi id 14.03.0513.000; Thu, 11 Mar 2021 15:48:25 +0800 From: "chenjun (AM)" To: "linux-kernel@vger.kernel.org" , "linux-fsdevel@vger.kernel.org" CC: Dan Williams , Jan Kara , "Xiangrui (Euler)" , "lizhe (Y)" , yangerkun , "zhangyi (F)" Subject: [question] Panic in dax_writeback_one Thread-Topic: [question] Panic in dax_writeback_one Thread-Index: AdcWSusQwspXlegvQqCtsylm2CuWCw== Date: Thu, 11 Mar 2021 07:48:25 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.174.178.53] Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 X-CFilter-Loop: Reflected Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi I write a driver to simulate memory as a block device (like a ramdisk). and I hope the memory used would not be observed by kernel, becasue of the struct page will take many memory. When I mount ext2 with dax on my ramdisk. Panic will happen when fsync. Call trace: dax_writeback_one+0x330/0x3e4 dax_writeback_mapping_range+0x15c/0x318 ext2_dax_writepages+0x38/0x44 ..... static int dax_writeback_one(struct xa_state *xas, struct dax_device *dax_dev, struct address_space *mapping, void *entry) ----dax_flush(dax_dev, page_address(pfn_to_page(pfn)), count * PAGE_SIZE); The pfn is returned by the driver. In my case, the pfn does not have struct page. so pfn_to_page(pfn) return a wrong address. I noticed the following changes may related to my problem: 1. Before 3fe0791c295cfd3cd735de7a32cc0780949c009f (dax: store pfns in the radix), the radix tree stroes sectors. address which would be flushed is got from driver by passing sector. And the commit assume that all pfn have struct page. 2. CONFIG_FS_DAX_LIMITED (Selected by DCSSBLK [=n] && BLK_DEV [=y] && S390 && BLOCK [=y]) is added to avoid access struct page of pfn. Does anyone have any idea about my problem. -- Regards Chen Jun