Received: by 2002:a05:6a10:a0d1:0:0:0:0 with SMTP id j17csp376699pxa; Tue, 4 Aug 2020 07:44:59 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzBXcbmB672AF4kHYAIeInJkYS7jqAHFdexz+c3YqJ5+CTQ/P9ZLEPQH9gPIzZ5hgmzNgHW X-Received: by 2002:a17:906:c056:: with SMTP id bm22mr22744014ejb.444.1596552299643; Tue, 04 Aug 2020 07:44:59 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1596552299; cv=none; d=google.com; s=arc-20160816; b=DpHGjNamL3uMxcqtCg+Ye9WtP/I3ehlNrehr4ig2AHtp2kjMp7RHZJi5RxKrO0WqaY 8AZvC2nH4q4Bwgk/7bU+VqvdtRdeMD0rZgyWjNgUnKkwpSKofh7Ou/MJJ3ddXeL7qzZk 1xbje/8El32h/0l8eiD6L6Tw2OlXx5d0NvlzjySKqooflu2utxjh8LFOfdAnABYdmAiJ JtTacGUpxotIzCV1ajc0+5i1WOIVV1AzS8+/OQL+20whrvSRfXpeNEAQwpeoYWjzoU+x Ib9hMGvmDaRJuqJH5Pu7lX3YCqEFmQ9lu/nG0WIFrLpw3dv/0Aj0JvpDuyPyXRoxbg6s jRBg== 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 :content-language:in-reply-to:mime-version:user-agent:date :message-id:subject:autocrypt:from:references:cc:to; bh=AKPe54tQjFTyOYLU2uUG8a99QXRpeQOsh9UtDT6iuaY=; b=GIrRQGw4ypdiNqU9WY3Xsb5G1LB2fpziqCjHFNucsXMexxXGDqqiAL63W/7XBEwdrc wN3tfMly9xSXU+bZ28fnBGVq2oYgsGXjVpTk1gbiKLL6lB3eNpmIl5905a70wUdkg2bP c14ziaML/Lq5GjgEWlvAwicJVl97XbyofzpBQ1XTEoKMXq8yEsJtCEkaBZ2Q9TCCP/dD 0wn9g3Zdx93hQe4XtiskQuO8K2/r6vNA9fZ7tg/Tvo1x9M85o+clOjP+WiIkQehgtaw8 8gTUuuJtFT2JKkmKvPdEXirxdQuzsv6cVdgIz+mAPyxSRj1uHO96Tm2/ZfyO8+X1+i90 rbsw== ARC-Authentication-Results: i=1; mx.google.com; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id se13si12117161ejb.718.2020.08.04.07.44.37; Tue, 04 Aug 2020 07:44:59 -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; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728912AbgHDOoJ (ORCPT + 99 others); Tue, 4 Aug 2020 10:44:09 -0400 Received: from mx2.suse.de ([195.135.220.15]:59030 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725904AbgHDOn7 (ORCPT ); Tue, 4 Aug 2020 10:43:59 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 516D9AB7D; Tue, 4 Aug 2020 14:44:14 +0000 (UTC) To: Johannes Thumshirn , "linux-block@vger.kernel.org" Cc: "linux-bcache@vger.kernel.org" , "linux-kernel@vger.kernel.org" , Ming Lei , Hannes Reinecke , Xiao Ni , Bart Van Assche , Christoph Hellwig , Enzo Matsumiya , Jens Axboe , Evan Green References: <20200804142332.29961-1-colyli@suse.de> From: Coly Li Autocrypt: addr=colyli@suse.de; keydata= mQINBFYX6S8BEAC9VSamb2aiMTQREFXK4K/W7nGnAinca7MRuFUD4JqWMJ9FakNRd/E0v30F qvZ2YWpidPjaIxHwu3u9tmLKqS+2vnP0k7PRHXBYbtZEMpy3kCzseNfdrNqwJ54A430BHf2S GMVRVENiScsnh4SnaYjFVvB8SrlhTsgVEXEBBma5Ktgq9YSoy5miatWmZvHLFTQgFMabCz/P j5/xzykrF6yHo0rHZtwzQzF8rriOplAFCECp/t05+OeHHxjSqSI0P/G79Ll+AJYLRRm9til/ K6yz/1hX5xMToIkYrshDJDrUc8DjEpISQQPhG19PzaUf3vFpmnSVYprcWfJWsa2wZyyjRFkf J51S82WfclafNC6N7eRXedpRpG6udUAYOA1YdtlyQRZa84EJvMzW96iSL1Gf+ZGtRuM3k49H 1wiWOjlANiJYSIWyzJjxAd/7Xtiy/s3PRKL9u9y25ftMLFa1IljiDG+mdY7LyAGfvdtIkanr iBpX4gWXd7lNQFLDJMfShfu+CTMCdRzCAQ9hIHPmBeZDJxKq721CyBiGAhRxDN+TYiaG/UWT 7IB7LL4zJrIe/xQ8HhRO+2NvT89o0LxEFKBGg39yjTMIrjbl2ZxY488+56UV4FclubrG+t16 r2KrandM7P5RjR+cuHhkKseim50Qsw0B+Eu33Hjry7YCihmGswARAQABtBhDb2x5IExpIDxj b2x5bGlAc3VzZS5kZT6JAlYEEwEIAEACGyMHCwkIBwMCAQYVCAIJCgsEFgIDAQIeAQIXgBYh BOo+RS/0+Uhgjej60Mc5B5Nrffj8BQJcR84dBQkY++fuAAoJEMc5B5Nrffj8ixcP/3KAKg1X EcoW4u/0z+Ton5rCyb/NpAww8MuRjNW82UBUac7yCi1y3OW7NtLjuBLw5SaVG5AArb7IF3U0 qTOobqfl5XHsT0o5wFHZaKUrnHb6y7V3SplsJWfkP3JmOooJsQB3z3K96ZTkFelsNb0ZaBRu gV+LA4MomhQ+D3BCDR1it1OX/tpvm2uaDF6s/8uFtcDEM9eQeqATN/QAJ49nvU/I8zDSY9rc 0x9mP0x+gH4RccbnoPu/rUG6Fm1ZpLrbb6NpaYBBJ/V1BC4lIOjnd24bsoQrQmnJn9dSr60X 1MY60XDszIyzRw7vbJcUn6ZzPNFDxFFT9diIb+wBp+DD8ZlD/hnVpl4f921ZbvfOSsXAJrKB 1hGY17FPwelp1sPcK2mDT+pfHEMV+OQdZzD2OCKtza/5IYismJJm3oVUYMogb5vDNAw9X2aP XgwUuG+FDEFPamFMUwIfzYHcePfqf0mMsaeSgtA/xTxzx/0MLjUJHl46Bc0uKDhv7QUyGz0j Ywgr2mHTvG+NWQ/mDeHNGkcnsnp3IY7koDHnN2xMFXzY4bn9m8ctqKo2roqjCzoxD/njoAhf KBzdybLHATqJG/yiZSbCxDA1n/J4FzPyZ0rNHUAJ/QndmmVspE9syFpFCKigvvyrzm016+k+ FJ59Q6RG4MSy/+J565Xj+DNY3/dCuQINBFYX6S8BEADZP+2cl4DRFaSaBms08W8/smc5T2CO YhAoygZn71rB7Djml2ZdvrLRjR8Qbn0Q/2L2gGUVc63pJnbrjlXSx2LfAFE0SlfYIJ11aFdF 9w7RvqWByQjDJor3Z0fWvPExplNgMvxpD0U0QrVT5dIGTx9hadejCl/ug09Lr6MPQn+a4+qs aRWwgCSHaIuDkH3zI1MJXiqXXFKUzJ/Fyx6R72rqiMPHH2nfwmMu6wOXAXb7+sXjZz5Po9GJ g2OcEc+rpUtKUJGyeQsnCDxUcqJXZDBi/GnhPCcraQuqiQ7EGWuJfjk51vaI/rW4bZkA9yEP B9rBYngbz7cQymUsfxuTT8OSlhxjP3l4ZIZFKIhDaQeZMj8pumBfEVUyiF6KVSfgfNQ/5PpM R4/pmGbRqrAAElhrRPbKQnCkGWDr8zG+AjN1KF6rHaFgAIO7TtZ+F28jq4reLkur0N5tQFww wFwxzROdeLHuZjL7eEtcnNnzSkXHczLkV4kQ3+vr/7Gm65mQfnVpg6JpwpVrbDYQeOFlxZ8+ GERY5Dag4KgKa/4cSZX2x/5+KkQx9wHwackw5gDCvAdZ+Q81nm6tRxEYBBiVDQZYqO73stgT ZyrkxykUbQIy8PI+g7XMDCMnPiDncQqgf96KR3cvw4wN8QrgA6xRo8xOc2C3X7jTMQUytCz9 0MyV1QARAQABiQI8BBgBCAAmAhsMFiEE6j5FL/T5SGCN6PrQxzkHk2t9+PwFAlxHziAFCRj7 5/EACgkQxzkHk2t9+PxgfA//cH5R1DvpJPwraTAl24SUcG9EWe+NXyqveApe05nk15zEuxxd e4zFEjo+xYZilSveLqYHrm/amvQhsQ6JLU+8N60DZHVcXbw1Eb8CEjM5oXdbcJpXh1/1BEwl 4phsQMkxOTns51bGDhTQkv4lsZKvNByB9NiiMkT43EOx14rjkhHw3rnqoI7ogu8OO7XWfKcL CbchjJ8t3c2XK1MUe056yPpNAT2XPNF2EEBPG2Y2F4vLgEbPv1EtpGUS1+JvmK3APxjXUl5z 6xrxCQDWM5AAtGfM/IswVjbZYSJYyH4BQKrShzMb0rWUjkpXvvjsjt8rEXpZEYJgX9jvCoxt oqjCKiVLpwje9WkEe9O9VxljmPvxAhVqJjX62S+TGp93iD+mvpCoHo3+CcvyRcilz+Ko8lfO hS9tYT0HDUiDLvpUyH1AR2xW9RGDevGfwGTpF0K6cLouqyZNdhlmNciX48tFUGjakRFsxRmX K0Jx4CEZubakJe+894sX6pvNFiI7qUUdB882i5GR3v9ijVPhaMr8oGuJ3kvwBIA8lvRBGVGn 9xvzkQ8Prpbqh30I4NMp8MjFdkwCN6znBKPHdjNTwE5PRZH0S9J0o67IEIvHfH0eAWAsgpTz +jwc7VKH7vkvgscUhq/v1/PEWCAqh9UHy7R/jiUxwzw/288OpgO+i+2l11Y= Subject: Re: [PATCH] block: tolerate 0 byte discard_granularity in __blkdev_issue_discard() Message-ID: <2f70177e-4964-0fce-14bf-506b0821128b@suse.de> Date: Tue, 4 Aug 2020 22:43:53 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2020/8/4 22:37, Johannes Thumshirn wrote: > On 04/08/2020 16:34, Coly Li wrote: >> On 2020/8/4 22:31, Johannes Thumshirn wrote: >>> On 04/08/2020 16:23, Coly Li wrote: >>>> This is the procedure to reproduce the panic, >>>> # modprobe scsi_debug delay=0 dev_size_mb=2048 max_queue=1 >>>> # losetup -f /dev/nvme0n1 --direct-io=on >>>> # blkdiscard /dev/loop0 -o 0 -l 0x200 >>> >>> losetup -f /dev/sdX isn't it? >>> >> >> In my case, I use a NVMe SSD as the backing device of the loop device. >> Because I don't have a scsi lun. >> >> And loading scsi_debug module seems necessary, otherwise the discard >> process just hang and I cannot see the kernel panic (I don't know why yet). > > OK, now that's highly interesting. Does it also happen if you back loop with > a file? loop_config_discard() has different cases for the different backing devices/files. S > No, for a file backing, q->limits.discard_granularity is set to inode->i_sb->s_blocksize. And the encrypted loop device does not support discard. Such issue just only happens on a device backing loop device which announces supporting discard. Without Ming's fix to loop device driver, discard on LBA 0 will trigger the BUG() panic in my setup (Maybe it is more easier to trigger this BUG() panic with scsi lun). Coly Li