Received: by 2002:a17:90b:8d0:0:0:0:0 with SMTP id ds16csp378453pjb; Wed, 22 Jul 2020 02:12:53 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwyp+xMSV5/RVHY5Z6qCwNc1HEIjf5+zQkoJ1LJBlISVCoKwmaVBlOHsucGgrrTl0WYwyoh X-Received: by 2002:a17:906:6d56:: with SMTP id a22mr30487918ejt.440.1595409172755; Wed, 22 Jul 2020 02:12:52 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1595409172; cv=none; d=google.com; s=arc-20160816; b=kgvStUMAbBEMKxON2GHExAk5frD9rYAj8Wfk7OvPGV7O8zumFYanInQqD7QqM/I7LG 4165wLGYJ/FfzfoAkBMLUBvkS0X3CjvXdBfiAHZY5q4fzcPB93vx+v0iyG3Lfy72qxzF gtYHgKsWD5XNGJQvFoTEXVoTMuJpS9Mshg4HoAzjfJB063os/GVUTa5DZGchblzEsWXz tLsW0qWldxzmT8IPztjH3ogVauqZ6yy0yOjxkexWWAMHJcziXYZqjNGiq+v9P2uESrv5 Zp1UHwsv/eiF0o6rduvziazj/u2dk5mdXO2/HWt6CFv4bJwxNsr9adqNFjX1s8YOOWaH 8ajA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:date:cc:to:from:subject :message-id:dkim-signature; bh=NzcEIWaSLdd63tVnMlQ4l8CfKkfEyUhff3HORkpk1pw=; b=Iz2WvdJ+DD/gLRjX++3X+e7yTV7OhJTzK4LNqMFDc0DapywIKFOk0vXMDGtWrdS8Za Vk0VnFvjbB6ReE5SEuQ/G0VrzvaAySxRsnNP5I1IOMLz4ZTtc3mdLUJtPMK32fj5Y3eP rWnZcxsVcjvIwy/HoyhLtmTkhCt0+VKNMvj0M+bSYTam7dFz+j6cJq5BAE5SW2UtBAcW wjEL9lbRQ8v8bcT4dCg4MS74u1HHH4fs2cgvh+fsj3lTZfT19I/GdMhTvO7R/0EUHyWc SPZ2gJnISkjNAh6p3nQNChka9ETnM+96w3hf6APN+FFmcckPQiaJCa2kbRqQPTGsaSl2 tB8w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=b8dBzOj0; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id b5si14212294edy.563.2020.07.22.02.12.28; Wed, 22 Jul 2020 02:12:52 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=b8dBzOj0; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726153AbgGVJLn (ORCPT + 99 others); Wed, 22 Jul 2020 05:11:43 -0400 Received: from us-smtp-delivery-1.mimecast.com ([205.139.110.120]:31015 "EHLO us-smtp-1.mimecast.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726147AbgGVJLm (ORCPT ); Wed, 22 Jul 2020 05:11:42 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1595409100; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=NzcEIWaSLdd63tVnMlQ4l8CfKkfEyUhff3HORkpk1pw=; b=b8dBzOj024FywY5Penqxp9mkStAXHSUSvE0NXHrAhTSsV6PWTD8143jgEO36fVYNYozMUl 0+u20vnIhrZUqhVffNNVe8BMhW/mu8GqGpNzjqujDPDflU+8UdT6Xnh3mPwUmQoQwb0rch W1HFKDXUNYtlRxvdwMabiI8Vu9wtORQ= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-318-W9xiyZCdNjaZWfNh6eB9Eg-1; Wed, 22 Jul 2020 05:11:36 -0400 X-MC-Unique: W9xiyZCdNjaZWfNh6eB9Eg-1 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id C1173C746E; Wed, 22 Jul 2020 09:11:33 +0000 (UTC) Received: from fedora-32-enviroment (unknown [10.35.206.213]) by smtp.corp.redhat.com (Postfix) with ESMTP id 477AC5C1C3; Wed, 22 Jul 2020 09:11:18 +0000 (UTC) Message-ID: Subject: Re: [PATCH 02/10] block: virtio-blk: check logical block size From: Maxim Levitsky To: "Martin K. Petersen" , Christoph Hellwig Cc: linux-kernel@vger.kernel.org, Keith Busch , Josef Bacik , "open list:BLOCK LAYER" , Sagi Grimberg , Jens Axboe , "open list:NVM EXPRESS DRIVER" , "open list:SCSI CDROM DRIVER" , Tejun Heo , Bart Van Assche , Damien Le Moal , Jason Wang , Maxim Levitsky , Stefan Hajnoczi , Colin Ian King , "Michael S. Tsirkin" , Paolo Bonzini , Ulf Hansson , Ajay Joshi , Ming Lei , "open list:SONY MEMORYSTICK SUBSYSTEM" , Satya Tangirala , "open list:NETWORK BLOCK DEVICE (NBD)" , Hou Tao , Jens Axboe , "open list:VIRTIO CORE AND NET DRIVERS" , "James E.J. Bottomley" , Alex Dubov Date: Wed, 22 Jul 2020 12:11:17 +0300 In-Reply-To: References: <20200721105239.8270-1-mlevitsk@redhat.com> <20200721105239.8270-3-mlevitsk@redhat.com> <20200721151437.GB10620@lst.de> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.36.2 (3.36.2-1.fc32) MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 2020-07-21 at 22:55 -0400, Martin K. Petersen wrote: > Christoph, > > > Hmm, I wonder if we should simply add the check and warning to > > blk_queue_logical_block_size and add an error in that case. Then > > drivers only have to check the error return, which might add a lot > > less boiler plate code. > > Yep, I agree. > I also agree that this would be cleaner (I actually tried to implement this the way you suggest), but let me explain my reasoning for doing it this way. The problem is that most current users of blk_queue_logical_block_size (43 uses in the tree, out of which only 9 use constant block size) check for the block size relatively early, often store it in some internal struct etc, prior to calling blk_queue_logical_block_size thus making them only to rely on blk_queue_logical_block_size as the check for block size validity will need non-trivial changes in their code. Instead of this adding blk_is_valid_logical_block_size allowed me to trivially convert most of the uses. For RFC I converted only some drivers that I am more familiar with and/or can test but I can remove the driver's own checks in most other drivers with low chance of introducing a bug, even if I can't test the driver. What do you think? I can also both make blk_queue_logical_block_size return an error value, and have blk_is_valid_logical_block_size and use either of these checks, depending on the driver with eventual goal of un-exporting blk_is_valid_logical_block_size. Also note that I did add WARN_ON to blk_queue_logical_block_size. Best regards, Maxim Levitsky