public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Pierre Ossman <drzeus-list@drzeus.cx>
To: Jens Axboe <axboe@suse.de>, Russell King <rmk+lkml@arm.linux.org.uk>
Cc: LKML <linux-kernel@vger.kernel.org>
Subject: Re: How to map high memory for block io
Date: Fri, 27 Jan 2006 13:14:15 +0100	[thread overview]
Message-ID: <43DA0E97.5030504@drzeus.cx> (raw)
In-Reply-To: <20060127104321.GE4311@suse.de>

Jens Axboe wrote:
> On Fri, Jan 27 2006, Pierre Ossman wrote:
>   
>> Jens Axboe wrote:
>>     
>>> On Fri, Jan 27 2006, Pierre Ossman wrote:
>>>   
>>>       
>>>> I'm having some problems getting high memory support to work smoothly in
>>>> my driver. The documentation doesn't indicate what I might be doing
>>>> wrong so I'll have to ask here.
>>>>
>>>> The problem seems to be that kmap & co maps a single page into kernel
>>>> memory. So when I happen to cross page boundaries I start corrupting
>>>> some unrelated parts of the kernel. I would prefer not having to
>>>> consider page boundaries in an already messy PIO loop, so I've been
>>>> trying to find either a routine to map an entire sg entry or some way to
>>>> force the block layer to not give me stuff crossing pages.
>>>>
>>>> As you can guess I have not found anything that can do what I want, so
>>>> some pointers would be nice.
>>>>     
>>>>         
>>> Honestly, just don't bother if you are doing PIO anyways. Just tell the
>>> block layer that you want io bounced for you instead.
>>>
>>>   
>>>       
>> This is the MMC layer so there is some separation between the block
>> layer and the drivers. Also, the transfers won't necessarily be from the
>> block layer so a generic solution is desired. I don't suppose there is
>> some way of accessing the bounce buffer routines in a non-bio context?
>>     
>
> Only the mapping routines are appropriate at that point, or things get
> complicated. You could still do a two-page mapping, if you are careful
> about using different KMAP_ types.
>
>   

That would still make things rather difficult since there is no way to
get both maps into joining vaddrs. Is there no way to say "don't cross
page boundaries"? Setting a segment size of PAGE_SIZE still causes
problems when the offset isn't 0.

Russell, would having a "highmem not supported" flag in the host
structure be an acceptable solution? mmc_block could then use that to
tell the block layer that bounce buffers are needed. As for other,
future, users they would have to take care not to give those drivers
highmem sg lists.

The current buggy code, was modeled after another MMC driver (mmci). So
I suspect there might be more occurrences like this. Perhaps an audit
should be added as a janitor project?

Rgds
Pierre


  reply	other threads:[~2006-01-27 12:14 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-01-27  6:45 How to map high memory for block io Pierre Ossman
2006-01-27 10:26 ` Jens Axboe
2006-01-27 10:33   ` Pierre Ossman
2006-01-27 10:43     ` Jens Axboe
2006-01-27 12:14       ` Pierre Ossman [this message]
2006-01-27 12:39         ` Jens Axboe
2006-01-27 13:16           ` Pierre Ossman
2006-01-27 13:48             ` Pierre Ossman
2006-01-27 14:00               ` Jens Axboe
2006-01-27 14:14                 ` Pierre Ossman
2006-01-27 18:37             ` Pierre Ossman
2006-01-27 19:43         ` Russell King
2006-01-27 20:04           ` Pierre Ossman
2006-01-27 20:10             ` Jens Axboe
2006-01-27 20:14             ` Russell King
2006-01-27 20:22               ` Jens Axboe
2006-01-27 20:26                 ` Russell King
2006-01-27 20:38                   ` Pierre Ossman
2006-01-27 21:58                     ` Pierre Ossman
2006-01-27 22:54                       ` Russell King
2006-01-28 19:17                         ` Jens Axboe
2006-01-28 19:32                           ` Pierre Ossman
2006-01-29 15:22                             ` Jens Axboe
2006-01-30  7:57                               ` Pierre Ossman
2006-01-30  8:09                                 ` Jens Axboe
2006-01-31 18:39                                   ` Pierre Ossman
2006-03-01 23:29                                     ` Russell King
2006-03-02  7:21                                       ` Jens Axboe
2006-03-02  7:26                                       ` Pierre Ossman
2006-03-02  9:41                                         ` Russell King
2006-03-02  9:52                                           ` Pierre Ossman
2006-03-02 10:04                                             ` Russell King
2006-03-02 10:26                                               ` Pierre Ossman
2006-03-02 11:45                                                 ` Russell King
2007-01-30 20:41                                       ` Pierre Ossman
2006-01-27 20:28               ` Pierre Ossman
2006-01-27 20:12           ` Pierre Ossman
2006-01-27 20:16             ` Russell King

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=43DA0E97.5030504@drzeus.cx \
    --to=drzeus-list@drzeus.cx \
    --cc=axboe@suse.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rmk+lkml@arm.linux.org.uk \
    /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