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: 19+ 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-17 22:54 ` [RFC 0/4] fs: support dma-buf backed " shinichiro.kawasaki
2026-10-18 13:32 ` Shin'ichiro Kawasaki
2026-10-18 22:18 ` 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.