* [Question] Editing a bio write request
@ 2022-05-18 10:56 Jasper Surmont
2022-05-18 18:33 ` Eric Biggers
0 siblings, 1 reply; 3+ messages in thread
From: Jasper Surmont @ 2022-05-18 10:56 UTC (permalink / raw)
To: linux-block
I'm writing a device-mapper which has to edit incoming writes, for
example: Incoming bio request contains a biovec with a page full of 0
bytes, and I want to change it to all 0xFF bytes.
I tried using bvec_kmap_local() to get the page address, to then read
the data and if needed adjust it using memcpy or similar. Initial
tests seemed to work, but if I execute things like mkfs on the created
dm, I get a lot of segmentation faults. I narrowed down the problem
that this only happens if I actually write something to the mapped
page. However, I see no reason why it should cause this fault as I
(after checking probably 100 times) don't access invalid memory. I'm
wondering whether my method of editing the write is actually correct,
or if I am doing something else very stupid.
Any help is appreciated
Thanks!
Cheers, Jasper
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [Question] Editing a bio write request
2022-05-18 10:56 [Question] Editing a bio write request Jasper Surmont
@ 2022-05-18 18:33 ` Eric Biggers
2022-05-18 19:08 ` Jasper Surmont
0 siblings, 1 reply; 3+ messages in thread
From: Eric Biggers @ 2022-05-18 18:33 UTC (permalink / raw)
To: Jasper Surmont; +Cc: linux-block
On Wed, May 18, 2022 at 01:56:31PM +0300, Jasper Surmont wrote:
> I'm writing a device-mapper which has to edit incoming writes, for
> example: Incoming bio request contains a biovec with a page full of 0
> bytes, and I want to change it to all 0xFF bytes.
>
> I tried using bvec_kmap_local() to get the page address, to then read
> the data and if needed adjust it using memcpy or similar. Initial
> tests seemed to work, but if I execute things like mkfs on the created
> dm, I get a lot of segmentation faults. I narrowed down the problem
> that this only happens if I actually write something to the mapped
> page. However, I see no reason why it should cause this fault as I
> (after checking probably 100 times) don't access invalid memory. I'm
> wondering whether my method of editing the write is actually correct,
> or if I am doing something else very stupid.
Data in bios can't be modified in-place, as submitters of writes (e.g.,
filesystems) expect that their data buffers aren't modified. To modify the data
you'd need to allocate a new bio with new pages and submit that instead. See
dm-crypt for an example of a device-mapper target which does this.
What sort of device-mapper target are you trying to implement, anyway? If
you're trying to do encryption, dm-crypt already solves that problem.
- Eric
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [Question] Editing a bio write request
2022-05-18 18:33 ` Eric Biggers
@ 2022-05-18 19:08 ` Jasper Surmont
0 siblings, 0 replies; 3+ messages in thread
From: Jasper Surmont @ 2022-05-18 19:08 UTC (permalink / raw)
To: Eric Biggers; +Cc: linux-block
> Data in bios can't be modified in-place, as submitters of writes (e.g.,
> filesystems) expect that their data buffers aren't modified. To modify the data
> you'd need to allocate a new bio with new pages and submit that instead.
Oh wow thanks! I feel stupid. Just to be sure so that I don't send
'noob' questions like this in the future; could I have found this
anywhere in the documentation? The block layer is a lot to take in and I
don't always find the right stuff online.
> What sort of device-mapper target are you trying to implement, anyway? If
> you're trying to do encryption, dm-crypt already solves that problem.
It's more of an experiment, using compression!
Thanks!
Cheers, Jasper
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2022-05-18 19:08 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2022-05-18 10:56 [Question] Editing a bio write request Jasper Surmont
2022-05-18 18:33 ` Eric Biggers
2022-05-18 19:08 ` Jasper Surmont
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox