mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Peter T. Breuer" <ptb@it.uc3m.es>
To: paul@paulbristow.net
Cc: linux kernel <linux-kernel@vger.kernel.org>
Subject: floppy driver 2.6.3 question
Date: Wed, 17 Mar 2004 21:02:16 +0100 (MET)	[thread overview]
Message-ID: <200403172002.i2HK2GV10366@oboe.it.uc3m.es> (raw)



In the 2.6.3 floppy driver, when the driver is asked to revalidate by
kernel check_disk_change (after the latter asks and the floppy signalled
media_changed), the floppy driver constructs a read bio for the first
block and submits it via submit_bio, and waits for completion of the
bio.

However, the bio's embedded completion only signals back if the
submitted bio was successful, as far as I can tell:


static int floppy_rb0_complete(struct bio *bio, unsigned int bytes_done, int err)
{
	if (bio->bi_size)
		return 1;

	complete((struct completion*)bio->bi_private);
	return 0;
}

Note that if the bi_size is nonzero, we return without signalling. Now
bi_size starts out nozero

    bio.bi_size = size;

but I _think_ bi_size is zeroed along the way somewhere in end_request
(who knows?) if all goes well, so that nonzero means we still have more
to do in this bio. So if things go badly, completion is never signalled
and the submitted read is waited for forever? (and the result is never
tested).

	submit_bio(READ, &bio);
	generic_unplug_device(bdev_get_queue(bdev));
	process_fd_request();
	wait_for_completion(&complete);

	__free_page(page);

My reading therefore is that we cannot do revalidation until we are
sure that the floppy is there. If we feel sure, but are wrong, the 
test read of the first block will hang during the revalidation.

media_changed is tested using poll_drive(0,0). It's triggered by
kernel check_disk_change, which is run in open on the device.
Therefore I feel that opens may hang if the floppy is not there
when we think it is, such as if we yank it out just after it has been
polled, or if the floppy has bad sectors, or something like that.

Can somebody clear up my worry/confusion over how floppy_rb0_complete
can be correct to sometimes not signal completion?  How can it risk
leaving us waiting forever?  How can it even be called when the bio is
not yet complete?  And if the bio is ended when not complete, don't we
want to know about it, because then we will be able to say that the
floppy is not there, or is invalid? Surely we don't want to wait!?




Peter



             reply	other threads:[~2004-03-17 20:02 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-03-17 20:02 Peter T. Breuer [this message]
2004-03-18  7:14 ` Jens Axboe
2004-03-18  8:23   ` Peter T. Breuer
2004-03-18  9:10     ` Jens Axboe
2004-03-18 10:05       ` Peter T. Breuer
2004-03-18 11:35         ` Jens Axboe
2004-03-18 12:23           ` Peter T. Breuer
2004-03-18 12:28             ` Jens Axboe
2004-03-18 13:25               ` Peter T. Breuer
2004-03-18 13:31                 ` Jens Axboe
2004-03-18 16:06                   ` Peter T. Breuer
2004-03-18 16:16                     ` Jens Axboe
2004-03-18 18:11                       ` Peter T. Breuer
2004-03-18 19:05                         ` Jens Axboe

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=200403172002.i2HK2GV10366@oboe.it.uc3m.es \
    --to=ptb@it.uc3m.es \
    --cc=linux-kernel@vger.kernel.org \
    --cc=paul@paulbristow.net \
    /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

all inboxes | Powered by JetHome®