From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 15AC417BA2 for ; Mon, 24 Aug 2026 00:44:08 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787532250; cv=none; b=c0/CVtm1g5pylKMAOWPge1M+oEv+iNl3cd79c7QvzF8qPsHG6r9I+TaCWj9cbAeJpZE84OVC1M99gywX2wnCwMLBwYEWsoLTf1TruArRvlE/sCdnaaCb9TG6DzC2HolNMppK5oZ3SHe3sXk3KhsRG+USCFIEdJ4ixjGj476KbXo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787532250; c=relaxed/simple; bh=X5OixcDPAl6+46DiinXjj7ElLqDP8tKOrABPaHRiR4g=; h=Message-ID:Date:MIME-Version:Cc:Subject:To:References:From: In-Reply-To:Content-Type; b=E7apOSiqXOdDlY72Oyh4vLi2B48sQ8cLlOUW6YvPony7r/ngZDe4HHTEgCE4o3dv0k0ZmiwdH7f9U4fZcvI1zFvQRKglWBxVI3/p8c5ySUUwK7MbqvgiQzptt3yuEfHg6cqHIxhgZ+DWy7kilQOCXApGvRZU+49vG8Sz9V+AWg0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=QGDcNZB+; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="QGDcNZB+" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9B1C11F000E9; Mon, 24 Aug 2026 00:44:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1787532248; bh=mZ5K5rwI7nwTYOQqjFerlZVC7gSCH4r6hGJsHsj3hBw=; h=Date:Cc:Subject:To:References:From:In-Reply-To; b=QGDcNZB+WGe73sFwhClatS6Jyub/qRyUGxGEoiWM27GVPT2mTlKva1/brNI8shfrm VFIocLuDLDkt+UL6Dyk1kW64qaYVDq52dxjR19wtXYv67Zg4ChEZUL2Rz9Z2GIIkYn aeiiJOWSz6nWWRWZN3Fs0VFCpDu9thG74AnOVSpBdhSplAHGmpEE/0y7XppcpaXnxF pU2QSJ7WGiKCN+10cTkDpcP3Ep0e6tzQHVbBtkDlDm7y1UUeZ/+uW6fCfKxtpRTrrZ gRgfOis2Pu5w3jNA2+zdPk6Z0FlLZReu5zArKDJEPjltrxuKAViUL6cdg6/J8yKpxZ BcL89YBpXkLeg== Message-ID: Date: Mon, 24 Aug 2026 08:44:05 +0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Cc: chao@kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2] erofs: support SEEK_HOLE/SEEK_DATA in inode_share mode To: Jingbo Xu , xiang@kernel.org, linux-erofs@lists.ozlabs.org References: <20260820134006.66208-1-jefflexu@linux.alibaba.com> Content-Language: en-US From: Chao Yu In-Reply-To: <20260820134006.66208-1-jefflexu@linux.alibaba.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 8/20/26 21:40, Jingbo Xu wrote: > When inode_share is enabled, erofs_ishare_fops.llseek falls back to > generic_file_llseek, which treats the whole file as data and always > returns i_size for SEEK_HOLE, hiding real holes in sparse files. > > Switch it to erofs_file_llseek instead. For user files f_mapping->host > is always the real erofs inode, so SEEK_HOLE/SEEK_DATA resolve the > per-file on-disk layout via iomap_seek_hole()/iomap_seek_data(). > > Reviewed-by: Gao Xiang > Signed-off-by: Jingbo Xu Reviewed-by: Chao Yu Thanks,