From: Denis Efremov <efremov@linux.com>
To: "Philip K." <philip@warpmail.net>
Cc: moritzm.mueller@posteo.de, linux-kernel@vger.kernel.org,
linux-block@vger.kernel.org, linux-kernel@i4.cs.fau.de
Subject: Re: [PATCH] floppy: hide invalid floppy disk types
Date: Mon, 9 Dec 2019 20:04:32 +0300 [thread overview]
Message-ID: <04f0dfb9-d25a-d9a3-74cd-538165a8bfa2@linux.com> (raw)
In-Reply-To: <87h82ajzqd.fsf@bulbul>
On 12/9/19 12:04 AM, Philip K. wrote:
> Denis Efremov <yefremov.denis@gmail.com> writes:
>
>> Hi,
>>
>> On 08.12.2019 22:45, Moritz Müller wrote:
>>> In some cases floppy disks are being indexed, even though no actual
>>> device exists. In our case this was caused by the CMOS-RAM having a few
>>> peculiar bits. This caused a non-existent floppy disk of the type 13 to
>>> be registered as an possibly mountable device, even though it could not
>>> be mounted by any user.
>>>
>>> We believe this to be an instance of this bug, as we had similar logs
>>> and issues:
>>>
>>> https://bugzilla.kernel.org/show_bug.cgi?id=13486
>>> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/384579
Well, this is a ten years old bug. It seems like that time it was decided
to fix the problem either by blacklisting the driver or by disabling the
BIOS option. I doubt that many people are facing this problem since then.
I think that more-or-less modern motherboards don't have this issue.
>>>
>>> This patch adds the option FLOPPY_ALLOW_UNKNOWN_TYPES to prevent the
>>> additional check that fixed the issue on our reference system, and
>>> increases the startup time of affected systems by over a minute.
>>
>> Does driver blacklisting solves your problem? Or you have real floppy drives in
>> your system along with these "spurious" ones?
>
> No there were not, and blacklisting would solve the bug too. We just
> thought that fixing the bug this way would prevent the issue from
> appearing in the first place on systems that have the floppy module
> enabled, in the first place.
Hmm, I would say that driver blacklisting is a more proper solution in
this case. I doubt there are people with this issue and real floppy drives
in their setup. Altering the default driver's initialization scheme seems
superfluous to me. This will force users (if there are ones) who depends on this
behavior to rebuild the kernel. blacklisting doesn't require kernel rebuild.
>
>>> Co-developed-by: Philip K. <philip@warpmail.net>
>>> Signed-off-by: Philip K. <philip@warpmail.net>
>>> Signed-off-by: Moritz Müller <moritzm.mueller@posteo.de>
>>> ---
>>> drivers/block/Kconfig | 10 ++++++++++
>>> drivers/block/floppy.c | 6 ++++++
>>> 2 files changed, 16 insertions(+)
>>>
>>> diff --git a/drivers/block/Kconfig b/drivers/block/Kconfig
>>> index 1bb8ec575352..9e6b32c50b67 100644
>>> --- a/drivers/block/Kconfig
>>> +++ b/drivers/block/Kconfig
>>> @@ -72,6 +72,16 @@ config AMIGA_Z2RAM
>>> To compile this driver as a module, choose M here: the
>>> module will be called z2ram.
>>>
>>> +config FLOPPY_ALLOW_UNKNOWN_TYPES
>>> + bool "Allow floppy disks of unknown type to be registered."
>>> + default n
>>> + help
>>> + Select this option if you want the Kernel to register floppy
>>> + disks of an unknown type.
>>> +
>>> + This should usually not be enabled, because of cases where the
>>> + system falsely recognizes a non-existent floppy disk as mountable.
>>> +
>>> config CDROM
>>> tristate
>>> select BLK_SCSI_REQUEST
>>> diff --git a/drivers/block/floppy.c b/drivers/block/floppy.c
>>> index 485865fd0412..9439444d46d0 100644
>>> --- a/drivers/block/floppy.c
>>> +++ b/drivers/block/floppy.c
>>> @@ -3949,7 +3949,9 @@ static void __init config_types(void)
>>> } else
>>> allowed_drive_mask &= ~(1 << drive);
>>> } else {
>>> +#ifdef CONFIG_FLOPPY_ALLOW_UNKNOWN_TYPES
>>> params = &default_drive_params[0].params;
>>> +#endif
>>
>> You can't just skip it with ifdef. This will result in uninitialized
>> pointer dereference down the code.
>>
>> struct floppy_drive_params *params;
>> ...
>>
>> if (type < ARRAY_SIZE(default_drive_params)) {
>> ...
>> } else {
>> #ifdef CONFIG_FLOPPY_ALLOW_UNKNOWN_TYPES
>> params = &default_drive_params[0].params;
>> #endif
>> ...
>> }
>> ...
>> *UDP = *params; // << HERE
>
> Oops, you're right, will fix.
>
>>> snprintf(temparea, sizeof(temparea),
>>> "unknown type %d (usb?)", type);
>>> name = temparea;
>>> @@ -4518,6 +4520,10 @@ static bool floppy_available(int drive)
>>> return false;
>>> if (fdc_state[FDC(drive)].version == FDC_NONE)
>>> return false;
>>> +#ifndef CONFIG_FLOPPY_ALLOW_UNKNOWN_TYPES
>>> + if (type >= ARRAY_SIZE(default_drive_params))
>>> + return false;
>>> +#endif
>>> return true;
>>> }
>>>
>>>
>>
>> Thanks,
>> Denis
>
next prev parent reply other threads:[~2019-12-09 17:04 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-08 19:45 [PATCH] floppy: hide invalid floppy disk types Moritz Müller
2019-12-08 20:16 ` Denis Efremov
2019-12-09 9:32 ` [PATCH v3] " Moritz Müller
2019-12-09 17:03 ` Denis Efremov
[not found] ` <87h82ajzqd.fsf@bulbul>
2019-12-09 17:04 ` Denis Efremov [this message]
2019-12-09 17:30 ` [PATCH] " Philip K.
2019-12-09 0:32 ` kbuild test robot
-- strict thread matches above, loose matches on Subject: below --
2019-12-08 16:59 Moritz Müller
2019-12-08 17:35 ` Randy Dunlap
2019-12-08 19:01 ` kbuild test robot
2019-12-10 5:07 ` 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=04f0dfb9-d25a-d9a3-74cd-538165a8bfa2@linux.com \
--to=efremov@linux.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-kernel@i4.cs.fau.de \
--cc=linux-kernel@vger.kernel.org \
--cc=moritzm.mueller@posteo.de \
--cc=philip@warpmail.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