* Understanding kmap/kunmap
@ 2011-12-01 17:49 Kai Meyer
2011-12-01 20:05 ` Kai Meyer
0 siblings, 1 reply; 2+ messages in thread
From: Kai Meyer @ 2011-12-01 17:49 UTC (permalink / raw)
To: kernelnewbies
I want to be able to copy data into a struct bio *, so I use
bio_for_each_segment to loop through each bvec, like so:
void some_function(struct bio *bio, char *some_data) {
struct bio_vec *bvec;
int i;
unsigned int bio_so_far = 0;
bio_for_each_segment(bvec, bio, i) {
char *bio_buffer = __bio_kmap_atomic(bio, i, KM_USER0);
memcpy(bio_buffer, some_data + bio_so_far, bvec->bv_len);
__bio_kunmap_atomic(bio, KM_USER0);
bio_so_far += bvec->bv_len;
}
}
There's lots more to the function, but this is basically the distilled
version with out any extra stuff.
What I'm finding is that when the bio has multiple bvecs that share the
same page, only the first bvec's data actually gets copied back up to
user-space, the rest is garbage or null (meaning, what was there
already). For instance, I see a lot of bios from vfat that are 4096
bytes long but are comprised of 8 bvecs that are 512 bytes long that all
have an offset to the same page.
I've tried doing just one kmap_atomic on the page by keeping track of
what the last page I kmap'ed was, but that didn't fix the problem either.
Any documentation or high level explanation of kmap/kunmap or other
ideas to try are welcome.
-Kai Meyer
^ permalink raw reply [flat|nested] 2+ messages in thread
* Understanding kmap/kunmap
2011-12-01 17:49 Understanding kmap/kunmap Kai Meyer
@ 2011-12-01 20:05 ` Kai Meyer
0 siblings, 0 replies; 2+ messages in thread
From: Kai Meyer @ 2011-12-01 20:05 UTC (permalink / raw)
To: kernelnewbies
Correction. The problem occurs when 8 bios of size 512 with 1 bvec each
all share the same page. I made a bad assumption previously.
-Kai Meyer
On 12/01/2011 10:49 AM, Kai Meyer wrote:
> I want to be able to copy data into a struct bio *, so I use
> bio_for_each_segment to loop through each bvec, like so:
>
> void some_function(struct bio *bio, char *some_data) {
> struct bio_vec *bvec;
> int i;
> unsigned int bio_so_far = 0;
> bio_for_each_segment(bvec, bio, i) {
> char *bio_buffer = __bio_kmap_atomic(bio, i, KM_USER0);
> memcpy(bio_buffer, some_data + bio_so_far, bvec->bv_len);
> __bio_kunmap_atomic(bio, KM_USER0);
> bio_so_far += bvec->bv_len;
> }
> }
>
> There's lots more to the function, but this is basically the distilled
> version with out any extra stuff.
>
> What I'm finding is that when the bio has multiple bvecs that share the
> same page, only the first bvec's data actually gets copied back up to
> user-space, the rest is garbage or null (meaning, what was there
> already). For instance, I see a lot of bios from vfat that are 4096
> bytes long but are comprised of 8 bvecs that are 512 bytes long that all
> have an offset to the same page.
>
> I've tried doing just one kmap_atomic on the page by keeping track of
> what the last page I kmap'ed was, but that didn't fix the problem either.
>
> Any documentation or high level explanation of kmap/kunmap or other
> ideas to try are welcome.
>
> -Kai Meyer
>
> _______________________________________________
> Kernelnewbies mailing list
> Kernelnewbies at kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2011-12-01 20:05 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-12-01 17:49 Understanding kmap/kunmap Kai Meyer
2011-12-01 20:05 ` Kai Meyer
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).