From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S967786AbcA0U10 (ORCPT ); Wed, 27 Jan 2016 15:27:26 -0500 Received: from mx2.suse.de ([195.135.220.15]:41268 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S965366AbcA0U1S (ORCPT ); Wed, 27 Jan 2016 15:27:18 -0500 Date: Wed, 27 Jan 2016 21:27:15 +0100 (CET) From: Jiri Kosina X-X-Sender: jkosina@pobox.suse.cz To: Dmitry Vyukov cc: NeilBrown , Takashi Iwai , Jens Axboe , Hannes Reinecke , Rasmus Villemoes , LKML , syzkaller , Kostya Serebryany , Alexander Potapenko , Sasha Levin Subject: Re: floppy: GPF in floppy_rb0_cb In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (LNX 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 27 Jan 2016, Dmitry Vyukov wrote: > > Alright, there is a serious issue with how floppy_revalidate() handles > > error from lock_fdc() (in-depth explanation for the curious: it doesn't). > > > > In case wait_for_event_interruptible() is actually interrupted without > > succesfully claiming fdc, we proceed with revalidation, causing all kinds > > of havoc (because another parallel request is still in progress). > > > > The whole story with the 'interruptible' parameter to lock_fdc() is funny > > as well, because we always wait interruptibly anyway. So it can be nuked. > > Most of the lock_fdc() callsites do properly handle error (and propagate > > EINTR), but floppy_revalidate() and floppy_check_events() don't. > > > > Could you please let syzkaller retest with the patch below? It fixes all > > the oopses I am able to trigger here. > > Done. I will get back to you if I see any other oops. Please also get to me in case you don't see any other oops after the timeframe you have been able to reproduce the original problem, so that we could consider the issue resolved and I can make proper patch from this and send it upstream. Thanks, -- Jiri Kosina SUSE Labs