Received: by 2002:a17:90a:1609:0:0:0:0 with SMTP id n9csp3646616pja; Tue, 31 Mar 2020 02:44:09 -0700 (PDT) X-Google-Smtp-Source: ADFU+vuNPtgjY/EdzE9e9mkMO6rNgX9y7+dxQo9HCgK4T+QRwTkfkOS1i49BLnIVkdOSRCvoKmbe X-Received: by 2002:a9d:7c88:: with SMTP id q8mr12916037otn.282.1585647848899; Tue, 31 Mar 2020 02:44:08 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1585647848; cv=none; d=google.com; s=arc-20160816; b=FI6q4Sqq3fGV1zte3vthD+Xz1MeFoQnjcdjjyQcLc9Ejb2FmKEz/F0TyP989OAIdXi hngSjMsoWIYVSam6p6hwXlOAmNqEys7+QYNcTRsvITmitlA1kYAiqxV9uAS2ewalb38Q rTmZ0iCk4tXdEh6i7IZ8P6GX2GsuyvuU9ifJTcU1iSkGMa5imQHdrhdB/cInuUiHWiF1 CbahQl1H1nruxgGw+W+P7v++O/6iwoGO9m4sSIftKpEup+KvD37hVhGYdGLnzBd+VgPD QF5FFIOe9l5QsbWOFvYj3h+vmugarmrvVIy/H7EWkJxC2LGYkn9Br7XauhQbnvbKPSz3 Vl2A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:references:in-reply-to:message-id:date :subject:cc:to:from; bh=WNiF4C8nja4R8cblC8gUmUpvk8/5tvk6jklUyAaMn48=; b=OO+Qu/hwBlKXIs9AyDaR1CfJSA8XJKvfGTCpgjtoCYd2C3IqrCeaWV5L+3x+2hv8+j DZE69s0vu48YjX55CpsL0j2eZ9TA8pUONMy27sklRGs+9TwqvRygQUPAXLPIm8Gwqt8o Fxp9zgS/K2IZVtaDziOQxNqCtkqERQpvToKne36WexZjjrG7WwbptuIxVLbLrbSpXX9K tchZrYuOo5mfGa/l8oqV+o1HLyRlmGy/r4fJYOdNwIRLGiRNXzRQupkAdnuclvgVXpIG GHZxgE1eP9ipFYcZ1DORZwwlD/5PyxcBlBtkzmP9o85lZoW6B9zBN0r5e/bQwF2FEC3E PwQg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id r7si7652114oth.222.2020.03.31.02.43.56; Tue, 31 Mar 2020 02:44:08 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730477AbgCaJnI (ORCPT + 99 others); Tue, 31 Mar 2020 05:43:08 -0400 Received: from wtarreau.pck.nerim.net ([62.212.114.60]:34177 "EHLO 1wt.eu" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730273AbgCaJnH (ORCPT ); Tue, 31 Mar 2020 05:43:07 -0400 Received: (from willy@localhost) by pcw.home.local (8.15.2/8.15.2/Submit) id 02V9f76u024532; Tue, 31 Mar 2020 11:41:07 +0200 From: Willy Tarreau To: Denis Efremov Cc: Jens Axboe , linux-block@vger.kernel.org, linux-kernel@vger.kernel.org, Willy Tarreau Subject: [PATCH 23/23] floppy: cleanup: add a few comments about expectations in certain functions Date: Tue, 31 Mar 2020 11:40:54 +0200 Message-Id: <20200331094054.24441-24-w@1wt.eu> X-Mailer: git-send-email 2.9.0 In-Reply-To: <20200331094054.24441-1-w@1wt.eu> References: <20200331094054.24441-1-w@1wt.eu> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org The locking in the driver is far from being obvious, with unlocking automatically happening at end of operations scheduled by interrupt, especially for the error paths where one does not necessarily expect that such an interrupt may be triggered. Let's add a few comments about what to expect at certain places to avoid misdetecting bugs which are not. Signed-off-by: Willy Tarreau --- drivers/block/floppy.c | 14 +++++++++++++- 1 file changed, 13 insertions(+), 1 deletion(-) diff --git a/drivers/block/floppy.c b/drivers/block/floppy.c index 77bb9a5fcd33..07218f8b17f9 100644 --- a/drivers/block/floppy.c +++ b/drivers/block/floppy.c @@ -1791,7 +1791,9 @@ static void reset_interrupt(void) /* * reset is done by pulling bit 2 of DOR low for a while (old FDCs), - * or by setting the self clearing bit 7 of STATUS (newer FDCs) + * or by setting the self clearing bit 7 of STATUS (newer FDCs). + * This WILL trigger an interrupt, causing the handlers in the current + * cont's ->redo() to be called via reset_interrupt(). */ static void reset_fdc(void) { @@ -2003,6 +2005,9 @@ static const struct cont_t intr_cont = { .done = (done_f)empty }; +/* schedules handler, waiting for completion. May be interrupted, will then + * return -EINTR, in which case the driver will automatically be unlocked. + */ static int wait_til_done(void (*handler)(void), bool interruptible) { int ret; @@ -2842,6 +2847,9 @@ static int set_next_request(void) return current_req != NULL; } +/* Starts or continues processing request. Will automatically unlock the + * driver at end of request. + */ static void redo_fd_request(void) { int drive; @@ -2916,6 +2924,7 @@ static const struct cont_t rw_cont = { .done = request_done }; +/* schedule the request and automatically unlock the driver on completion */ static void process_fd_request(void) { cont = &rw_cont; @@ -3005,6 +3014,9 @@ static int user_reset_fdc(int drive, int arg, bool interruptible) if (arg == FD_RESET_ALWAYS) fdc_state[current_fdc].reset = 1; if (fdc_state[current_fdc].reset) { + /* note: reset_fdc will take care of unlocking the driver + * on completion. + */ cont = &reset_cont; ret = wait_til_done(reset_fdc, interruptible); if (ret == -EINTR) -- 2.20.1