Re: sleeping in block device driver

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Re-sending due to failure.

On 9/7/06, Bahadir Balban <bahadir.balban@xxxxxxxxx> wrote:
On 9/7/06, Fawad Lateef <fawadlateef@xxxxxxxxx> wrote:
> On 9/6/06, Bahadir Balban <bahadir.balban@xxxxxxxxx> wrote:
> >
> > In linux device drivers 3, block drivers chapter, for block device io
> > tranfers, a function is defined:
> >
> > int sbull_transfer_bio(struct sbull_dev *dev, struct bio *bio)
> > {
> >    ...
> >    bio_for_each_segment(bvec, bio, i) {
> >       ...
> >       __bio_kmap_atomic(...);
> >       sbull_transfer(...);
> >       __bio_kunmap_atomic(...);
> >       ...
> >     }
> > }
> >
> >
> > Here, the transfer is not done in process context, and
> > sbull_transfer() cannot sleep. How could I implement a sleeping
> > transfer?
> >
>
> The request function of block devices are called in process context
> and they can sleep (but end_io is called in interrupt context).
>

So do you mean in:

sbull_make_request()
{
    sbull_transfer_bio();
    bio_endio();
}

sbull_transfer_bio() can sleep? If so I didn't know that.

Ya, sbull_transfer_bio or sbull_make_request can sleep. Just think in
terms of actual block device: when device driver gets request it put
it-self into sleep (AFAIR might be on the page which currently it is
using) until it is woken up by the interrupt from real hardware device
that data is read/write and now driver can procede furthur. But in the
function called against interrupt from device (end_io) you are not
allowed __or__ at-least not recommended to sleep (through the way
mentioned by Anand).

Are you sure on this? Because in LDD3 page 475 says:

"... The invocation of the request function is entirely asynchronous
with respect to the actions of any user-space process. You cannot
assume that the kernel is running in the context of the process that
initiated the current request."

Perhaps this only applies to "bio_endio()" part of the request then?


Yes :) Although it sometimes might be in the context of file-system or
due to some other module/code __but__ that context is again a process
context not interrupt or any other context. (CMIIW)

--
Fawad Lateef


--
Fawad Lateef

--
Kernelnewbies: Help each other learn about the Linux kernel.
Archive:       http://mail.nl.linux.org/kernelnewbies/
FAQ:           http://kernelnewbies.org/faq/


[Index of Archives]     [Newbies FAQ]     [Linux Kernel Mentors]     [Linux Kernel Development]     [IETF Annouce]     [Git]     [Networking]     [Security]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux SCSI]     [Linux ACPI]
  Powered by Linux