From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932424AbcHCO0U (ORCPT ); Wed, 3 Aug 2016 10:26:20 -0400 Received: from smtp105.ord1c.emailsrvr.com ([108.166.43.105]:46457 "EHLO smtp105.ord1c.emailsrvr.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932153AbcHCO0S (ORCPT ); Wed, 3 Aug 2016 10:26:18 -0400 X-Greylist: delayed 342 seconds by postgrey-1.27 at vger.kernel.org; Wed, 03 Aug 2016 10:26:17 EDT X-SMTPDoctor-Processed: csmtpprox beta X-Auth-ID: markh@compro.net X-Sender-Id: markh@compro.net Reply-To: markh@compro.net Subject: Re: Resend: Another 4.4 to 4.5 floppy issue References: <577C1856.4010607@compro.net> <5783D1E0.4040503@compro.net> <578630AA.2010105@compro.net> To: Jiri Kosina Cc: Linux-kernel From: Mark Hounschell Organization: Compro Computer Svcs. Message-ID: <123f7090-3374-98b7-f791-2954fc6c56f1@compro.net> Date: Wed, 3 Aug 2016 10:20:12 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 08/02/2016 05:44 AM, Jiri Kosina wrote: > On Wed, 13 Jul 2016, Mark Hounschell wrote: > >>> Alright, so you are basically supplementing O_NDELAY flag in order to >>> avoid check_disk_change() being called. It's rather a coincidence that >>> it has worked this way, but I agree with you that we can't ignore the >>> fact that there is userspace relying on this behavior. >> >> I'm not supplementing anything. The driver _did_ this on its own. > > I mean, you're passing O_NDELAY to open(/dev/fd0) exactly to avoid kernel > issuing check_disk_change(). That's the only semantics O_NDELAY has for > fd. > >> I just expect to be able to open the drive to get a handle without the >> kernel attempting to access the media. My apps manage a disk_change on >> their own. I don't think its check_disk_change that gives me my pain. >> There is some probe happening that fails when a floppy is installed that >> is not a "standard" format. That causes the open to fail which is the >> most pain. Still I should be able to get a handle without any media or >> even unrecognized media installed. > > Yeah, that's check_disk_change(). > >>>> The original behavior of the floppy driver was correct. I have no >>>> idea what BUG these changes were supposed to fix but the "fix" >>>> obviously broke user land. Was this bug reported by some new ROBOT >>>> test or something? The kernel floppy driver has been stable for >>>> years now >>> >>> That's not really true; the code is a racy mess, and this is being >>> uncovered only when virtualized floppy devices started to exist >>> (because they are much faster than a real hardware, and the different >>> timing reveals bugs that were not visible before). >> >> Forgive me here as I'm ignorant about why any virtualized floppy would >> require the real physical kernel floppy driver to be involved at all. > > Because VMs (such as qemu) actually do emulate a FDC on a hardware level, > but don't emulate the timings of the real hardware (which are not mandated > by the spec, but "are just there"). > >>> This particular fix was because syzkaller found a way how easily corrupt >>> kernel memory using O_NDELAY to floppy driver; see >>> >>> https://lkml.org/lkml/2016/2/2/848 >>> >>>> so I am really confused as to why these changes were induced. >>> >>> The floppy driver is in an orphan mode; no new "features" are added "just >>> because". Everything that's happening there is to fix real bugs in the >>> kernel. >>> >>> I'll look into ways how to fix this, but I am afraid this is going to be >>> really tricky. Therefore we'd have to very likely proceed asap with revert >>> of 09954bad448 and coming up with a workaround that'd still avoid the bug >>> reported by syzkaller. >> >> I would be happy to do some testing for you if needed. At least with regard to >> our apps. > > Could you please check whether my last patch that Jens queued in > linux-block.git ("floppy: fix open(O_ACCMODE) for ioctl-only open" in > for-linus branch) remedies at least some of the issues you are seeing? > I'm not sure how to get "for-linus" branch. I don't see it in linux-block.git. A patch for 4.5 would be easy for me though. Mark