* Correctly locking a Block Device Request Handler
@ 2015-11-16 16:32 Marcel Müller
2015-11-18 6:11 ` Pranay Srivastava
0 siblings, 1 reply; 3+ messages in thread
From: Marcel Müller @ 2015-11-16 16:32 UTC (permalink / raw)
To: kernelnewbies
Hello everyone,
I'm currently writing a block device driver and got stuck at trying to
understand how to correctly handle the locking
in the reqfn one passes to `blk_init_queue`.
My code looks like this:
static DEFINE_SPINLOCK(rblk_lock);
/* Code */
static void rblk_request_handler(struct request_queue *q)
__releases(q->queue_lock) __acquires(q->queue_lock)
{
struct request* req;
unsigned long flags = 0;
printk(KERN_INFO "rblk: Got request(s) \n");
while ((req = blk_fetch_request(q)) != NULL) {
printk(KERN_INFO "rblk: Handling request \n"); // <- Gets
printed
spin_lock_irqsave(q->queue_lock, flags);
blk_end_request_all(req, -ENOTTY);
spin_unlock_irqrestore(q->queue_lock, flags);
printk(KERN_INFO "rblk: Handled request \n"); // <- Does not
get printed
}
}
static in rblk_init() {
/* Get major number, allocate devices */
for (i = 0; i < rblk_cnt; i++) { // For each device
/* alloc_disk, check for allocation fail */
disk->queue = blk_init_queue(rblk_request_handler, &rblk_lock);
}
}
This didn't work, and it was obvious to me that it was hanging in the
spinlock. So I tried
removing the locking, (this SO answer says that the queue is already
locked:
https://stackoverflow.com/questions/19418979/proper-way-to-lock-the-queue-in-a-block-device-driver-while-serving-requests)
however, I still get the problem that the queue locks up and the second
message never hits the message
queue.
What /does/ work is if I invert the order of locking. As in, unlock
first, end_request and then lock again.
However that doesn't seem to be the correct way. What am I doing
completely wrong, what did I misunderstand?
Full code: https://gist.github.com/TheNeikos/8798788defa1a9f316e6
Thanks
^ permalink raw reply [flat|nested] 3+ messages in thread
* Correctly locking a Block Device Request Handler
2015-11-16 16:32 Correctly locking a Block Device Request Handler Marcel Müller
@ 2015-11-18 6:11 ` Pranay Srivastava
2015-11-19 13:56 ` Marcel Müller
0 siblings, 1 reply; 3+ messages in thread
From: Pranay Srivastava @ 2015-11-18 6:11 UTC (permalink / raw)
To: kernelnewbies
Hi
On Mon, Nov 16, 2015 at 10:02 PM, Marcel M?ller <neikos@neikos.email> wrote:
> Hello everyone,
>
> I'm currently writing a block device driver and got stuck at trying to
> understand how to correctly handle the locking
> in the reqfn one passes to `blk_init_queue`.
>
> My code looks like this:
>
> static DEFINE_SPINLOCK(rblk_lock);
>
> /* Code */
>
> static void rblk_request_handler(struct request_queue *q)
> __releases(q->queue_lock) __acquires(q->queue_lock)
as per code, the queue_lock would be held before it enters your
request_func. So no you don't need
to lock it here.
If you must however need to do some stuff that requires the
spin_lock_* to be released, you must
make sure that before you leave this function you have reacquired that lock.
> {
> struct request* req;
> unsigned long flags = 0;
>
> printk(KERN_INFO "rblk: Got request(s) \n");
> while ((req = blk_fetch_request(q)) != NULL) {
> printk(KERN_INFO "rblk: Handling request \n"); // <- Gets
> printed
This isn't required if this is your request_function. Let's say you
just want to consume the requests
but want to actually handle them elsewhere then you may require to
take the spin_lock_* over there.
> spin_lock_irqsave(q->queue_lock, flags);
You are generating error for all requests?
> blk_end_request_all(req, -ENOTTY);
> spin_unlock_irqrestore(q->queue_lock, flags);
> printk(KERN_INFO "rblk: Handled request \n"); // <- Does not
> get printed
> }
> }
>
>
> static in rblk_init() {
> /* Get major number, allocate devices */
> for (i = 0; i < rblk_cnt; i++) { // For each device
> /* alloc_disk, check for allocation fail */
>
> disk->queue = blk_init_queue(rblk_request_handler, &rblk_lock);
> }
> }
>
>
> This didn't work, and it was obvious to me that it was hanging in the
> spinlock. So I tried
> removing the locking, (this SO answer says that the queue is already
> locked:
> https://stackoverflow.com/questions/19418979/proper-way-to-lock-the-queue-in-a-block-device-driver-while-serving-requests)
> however, I still get the problem that the queue locks up and the second
> message never hits the message
> queue.
>
> What /does/ work is if I invert the order of locking. As in, unlock
> first, end_request and then lock again.
> However that doesn't seem to be the correct way. What am I doing
> completely wrong, what did I misunderstand?
>
> Full code: https://gist.github.com/TheNeikos/8798788defa1a9f316e6
You can check one here https://github.com/pranjas/block_driver. No
real device though.
>
> Thanks
>
>
> _______________________________________________
> Kernelnewbies mailing list
> Kernelnewbies at kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
--
---P.K.S
^ permalink raw reply [flat|nested] 3+ messages in thread
* Correctly locking a Block Device Request Handler
2015-11-18 6:11 ` Pranay Srivastava
@ 2015-11-19 13:56 ` Marcel Müller
0 siblings, 0 replies; 3+ messages in thread
From: Marcel Müller @ 2015-11-19 13:56 UTC (permalink / raw)
To: kernelnewbies
On 11/18/2015 07:11 AM, Pranay Srivastava wrote:
> Hi
>
> On Mon, Nov 16, 2015 at 10:02 PM, Marcel M?ller <neikos@neikos.email> wrote:
>> Hello everyone,
>>
>> I'm currently writing a block device driver and got stuck at trying to
>> understand how to correctly handle the locking
>> in the reqfn one passes to `blk_init_queue`.
>>
>> My code looks like this:
>>
>> static DEFINE_SPINLOCK(rblk_lock);
>>
>> /* Code */
>>
>> static void rblk_request_handler(struct request_queue *q)
>> __releases(q->queue_lock) __acquires(q->queue_lock)
> as per code, the queue_lock would be held before it enters your
> request_func. So no you don't need
> to lock it here.
>
> If you must however need to do some stuff that requires the
> spin_lock_* to be released, you must
> make sure that before you leave this function you have reacquired that lock.
>
>> {
>> struct request* req;
>> unsigned long flags = 0;
>>
>> printk(KERN_INFO "rblk: Got request(s) \n");
>> while ((req = blk_fetch_request(q)) != NULL) {
>> printk(KERN_INFO "rblk: Handling request \n"); // <- Gets
>> printed
> This isn't required if this is your request_function. Let's say you
> just want to consume the requests
> but want to actually handle them elsewhere then you may require to
> take the spin_lock_* over there.
>
>
>> spin_lock_irqsave(q->queue_lock, flags);
> You are generating error for all requests?
>
>> blk_end_request_all(req, -ENOTTY);
>> spin_unlock_irqrestore(q->queue_lock, flags);
>> printk(KERN_INFO "rblk: Handled request \n"); // <- Does not
>> get printed
>> }
>> }
>>
>>
>> static in rblk_init() {
>> /* Get major number, allocate devices */
>> for (i = 0; i < rblk_cnt; i++) { // For each device
>> /* alloc_disk, check for allocation fail */
>>
>> disk->queue = blk_init_queue(rblk_request_handler, &rblk_lock);
>> }
>> }
>>
>>
>> This didn't work, and it was obvious to me that it was hanging in the
>> spinlock. So I tried
>> removing the locking, (this SO answer says that the queue is already
>> locked:
>> https://stackoverflow.com/questions/19418979/proper-way-to-lock-the-queue-in-a-block-device-driver-while-serving-requests)
>> however, I still get the problem that the queue locks up and the second
>> message never hits the message
>> queue.
>>
>> What /does/ work is if I invert the order of locking. As in, unlock
>> first, end_request and then lock again.
>> However that doesn't seem to be the correct way. What am I doing
>> completely wrong, what did I misunderstand?
>>
>> Full code: https://gist.github.com/TheNeikos/8798788defa1a9f316e6
> You can check one here https://github.com/pranjas/block_driver. No
> real device though.
>> Thanks
>>
>>
>> _______________________________________________
>> Kernelnewbies mailing list
>> Kernelnewbies at kernelnewbies.org
>> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>
>
Hello,
Thank you! Your explanations and code showed me some new things one can
do, so
that definitely helped!
- Marcel
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2015-11-19 13:56 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2015-11-16 16:32 Correctly locking a Block Device Request Handler Marcel Müller
2015-11-18 6:11 ` Pranay Srivastava
2015-11-19 13:56 ` Marcel Müller
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).