From: Pavel Begunkov <asml.silence@gmail.com>
To: Christoph Hellwig <hch@lst.de>
Cc: Anuj Gupta <anuj1072538@gmail.com>,
djwong@kernel.org, cem@kernel.org, brauner@kernel.org,
axboe@kernel.dk, linux-block@vger.kernel.org,
linux-xfs@vger.kernel.org, linux-fsdevel@vger.kernel.org,
joshi.k@samsung.com, anuj20.g@samsung.com, nj.shetty@samsung.com
Subject: Re: [RFC 0/4] fs: support dma-buf backed direct I/O
Date: Thu, 29 Oct 2026 11:34:07 +0000 [thread overview]
Message-ID: <69f1290c-1650-4ce4-bc0f-e8a3c03a5d14@gmail.com> (raw)
In-Reply-To: <20261028162900.GA22640@lst.de>
On 10/28/26 16:29, Christoph Hellwig wrote:
> On Sun, Oct 18, 2026 at 11:18:27PM +0100, Pavel Begunkov wrote:
>> file_ref_t f_ref;
>> /* --- cacheline 3 boundary (192 bytes) --- */
>> +
>> + /*
>> + * A tag representing the underlying subsystem for dma-buf I/O.
>> + * See struct dma_buf_io_ctx::importer_tag.
>> + */
>> + unsigned long f_dma_io_tag;
>> } __randomize_layout
>
> Growing strut file into a new cacheline just for dmabufs is a no-go..
I didn't check last time but there is space to spare. Maybe I don't
know about all production enabled options growing mutexes.
struct file {
spinlock_t f_lock __attribute__((__aligned__(4))); /* 0 4 */
fmode_t f_mode; /* 4 4 */
const struct file_operations * f_op; /* 8 8 */
struct address_space * f_mapping; /* 16 8 */
void * private_data; /* 24 8 */
struct inode * f_inode; /* 32 8 */
unsigned int f_flags; /* 40 4 */
unsigned int f_iocb_flags; /* 44 4 */
const struct cred * f_cred; /* 48 8 */
struct fown_struct * f_owner; /* 56 8 */
/* --- cacheline 1 boundary (64 bytes) --- */
union {
const struct path f_path; /* 64 16 */
struct path __f_path; /* 64 16 */
}; /* 64 16 */
union {
struct mutex f_pos_lock __attribute__((__aligned__(8))); /* 80 24 */
u64 f_pipe; /* 80 8 */
} __attribute__((__aligned__(8))); /* 80 24 */
loff_t f_pos; /* 104 8 */
void * f_security; /* 112 8 */
errseq_t f_wb_err; /* 120 4 */
errseq_t f_sb_err; /* 124 4 */
/* --- cacheline 2 boundary (128 bytes) --- */
struct hlist_head * f_ep; /* 128 8 */
union {
struct callback_head f_task_work __attribute__((__aligned__(8))); /* 136 16 */
struct llist_node f_llist; /* 136 8 */
struct file_ra_state f_ra; /* 136 32 */
freeptr_t f_freeptr; /* 136 8 */
} __attribute__((__aligned__(8))); /* 136 32 */
file_ref_t f_ref; /* 168 8 */
/* size: 176, cachelines: 3, members: 19 */
/* forced alignments: 3 */
/* last cacheline: 48 bytes */
} __attribute__((__aligned__(8)));
> Also note that a file can be placed on multiple block devices when
> using RAID or just btrfs placements (not sure about f2fs).
Filesystems should set it to a super block or something similar.
It's "unsigned long" for that exact reason. Shouldn't be a problem
for md either.
--
Pavel Begunkov
prev parent reply other threads:[~2026-10-29 11:34 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-16 9:19 [RFC 0/4] fs: support dma-buf backed direct I/O Anuj Gupta
2026-10-16 9:19 ` [RFC 1/4] block: factor out bdev_init_dma_buf_io_ctx() Anuj Gupta
2026-10-16 9:23 ` Christoph Hellwig
2026-10-16 9:19 ` [RFC 2/4] block: refuse a dma-buf bio for a disk the buffer was not registered on Anuj Gupta
2026-10-16 9:24 ` Christoph Hellwig
2026-10-21 15:12 ` Pavel Begunkov
2026-10-22 13:00 ` Nitesh Shetty
2026-10-16 9:19 ` [RFC 3/4] iomap: add dma-buf direct I/O guards and registration helper Anuj Gupta
2026-10-16 9:26 ` Christoph Hellwig
2026-10-16 9:19 ` [RFC 4/4] xfs: support dma-buf registered buffers for direct I/O Anuj Gupta
2026-10-16 9:28 ` Christoph Hellwig
2026-10-17 18:19 ` Kanchan Joshi
2026-10-18 22:28 ` Pavel Begunkov
2026-10-19 10:29 ` Anuj gupta
2026-10-18 22:18 ` [RFC 0/4] fs: support dma-buf backed " Pavel Begunkov
2026-10-28 16:29 ` Christoph Hellwig
2026-10-29 11:34 ` Pavel Begunkov [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=69f1290c-1650-4ce4-bc0f-e8a3c03a5d14@gmail.com \
--to=asml.silence@gmail.com \
--cc=anuj1072538@gmail.com \
--cc=anuj20.g@samsung.com \
--cc=axboe@kernel.dk \
--cc=brauner@kernel.org \
--cc=cem@kernel.org \
--cc=djwong@kernel.org \
--cc=hch@lst.de \
--cc=joshi.k@samsung.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-xfs@vger.kernel.org \
--cc=nj.shetty@samsung.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox