Received: by 10.213.65.68 with SMTP id h4csp4174701imn; Tue, 10 Apr 2018 10:22:03 -0700 (PDT) X-Google-Smtp-Source: AIpwx48caSL73YzZ+BJmgEovttg0qyCx9GuZChvj0hGQcRZExUppkvLKKcfgVj5SJTYAhLzF0nWG X-Received: by 2002:a17:902:bc06:: with SMTP id n6-v6mr1323661pls.97.1523380923867; Tue, 10 Apr 2018 10:22:03 -0700 (PDT) Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 7-v6si3048114plf.552.2018.04.10.10.21.26; Tue, 10 Apr 2018 10:22:03 -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; dkim=fail header.i=@natalenko.name header.s=dkim-20170712 header.b=YNFJ5mXP; arc=fail (signature failed); 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=natalenko.name Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752535AbeDJRQ4 (ORCPT + 99 others); Tue, 10 Apr 2018 13:16:56 -0400 Received: from vulcan.natalenko.name ([104.207.131.136]:14868 "EHLO vulcan.natalenko.name" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752490AbeDJRQx (ORCPT ); Tue, 10 Apr 2018 13:16:53 -0400 Received: from mail.natalenko.name (vulcan.natalenko.name [IPv6:fe80::5400:ff:fe0c:dfa0]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by vulcan.natalenko.name (Postfix) with ESMTPSA id 12DAB336533; Tue, 10 Apr 2018 19:16:50 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=natalenko.name; s=dkim-20170712; t=1523380610; h=from:sender:reply-to:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:resent-to:resent-cc:resent-from:resent-sender:resent-message-id:in-reply-to:references:list-id:list-owner:list-unsubscribe:list-subscribe:list-post; bh=tGkC1r+TZEazHk91syu7LV0Rok2tVEsKVmkFtWVNI5o=; b=YNFJ5mXPPPTMMpJXTm1Z/uNpIwGAMjLR7LsfsLGbC6oXVHP7UEg2Rqu70vXUkJS7Y+yR+i xRKgfjh9KVmtidra5iu5xjukg3uHGX3hCNUXxjNT+21pRH6GJEEGa8uo1qK7SIGHkaqxsy I+ASFaZHkAmc7E/Ttue4FT0/yPjQXCg= DMARC-Filter: OpenDMARC Filter v1.3.2 vulcan.natalenko.name 12DAB336533 Authentication-Results: vulcan.natalenko.name; dmarc=fail (p=none dis=none) header.from=natalenko.name MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Tue, 10 Apr 2018 19:16:49 +0200 From: Oleksandr Natalenko To: Kees Cook Cc: David Windsor , "James E.J. Bottomley" , "Martin K. Petersen" , linux-scsi@vger.kernel.org, LKML , Christoph Hellwig , Jens Axboe , Hannes Reinecke , Johannes Thumshirn , linux-block@vger.kernel.org, paolo.valente@linaro.org, keescook@google.com Subject: Re: usercopy whitelist woe in scsi_sense_cache In-Reply-To: References: <10360653.ov98egbaqx@natalenko.name> <2679696.GDoj5zcZOu@natalenko.name> <51a7e805058ef7f35b226cbbf0ccc4ff@natalenko.name> <3d7b5a707e216e19eb3defe0586bfbc8@natalenko.name> Message-ID: X-Sender: oleksandr@natalenko.name User-Agent: Roundcube Webmail/1.3.5 ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=natalenko.name; s=arc-20170712; t=1523380610; h=from:sender:reply-to:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:resent-to:resent-cc:resent-from:resent-sender:resent-message-id:in-reply-to:references:list-id:list-owner:list-unsubscribe:list-subscribe:list-post; bh=tGkC1r+TZEazHk91syu7LV0Rok2tVEsKVmkFtWVNI5o=; b=vWXeyBG4VR8M+DOQqC7xqIiupVK/FUktMbTYmXa65sFm110+ELfeq777T5VHe6JGOnNmZK OForm0+D+sCWhCsn2jvvrrOxYyaCDYO9SnfnNlddlbTDwdsDDUoQf49iE0ajtsHVqPRMNE 5E3PntLGAO26/i08kaykioxe8FeEg0g= ARC-Seal: i=1; s=arc-20170712; d=natalenko.name; t=1523380610; a=rsa-sha256; cv=none; b=tOL5Ckw/L3IPhg8DVOMGtHVZJoZV8cjpXgBbmEzMRJa1scBHocbhV+RLCF7W+LqyjWJYwNFhickb1yGhiccXyIDNcyeiSEUGN+k+76vCMAt8GCYhW3Qxx+pFDgGqcFR2O79Sdw+D1Xsa3tueQN6EJH0xeqDYC7+KZtyBz12KPDo= ARC-Authentication-Results: i=1; auth=pass smtp.auth=oleksandr@natalenko.name smtp.mailfrom=oleksandr@natalenko.name Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, Kees, Paolo et al. 10.04.2018 08:53, Kees Cook wrote: > Unfortunately I only had a single hang with no dumps. I haven't been > able to reproduce it since. :( For your convenience I've prepared a VM that contains a reproducer. It consists of 3 disk images (sda.img is for the system, it is Arch-based, sdb/sdc.img are for RAID). They are available (in a compressed form) to download here [1]. RAID is built as RAID10 with far2 layout, on top of it there is a LUKS container (can be opened either with keyfile under the /root or using "qwerty" password). There's one LVM PV, one VG and one volume on top of LUKS containing XFS. RAID is automatically assembled during the boot, so you don't have to worry about it. I run the VM like this: $ qemu-system-x86_64 -display gtk,gl=on -machine q35,accel=kvm -cpu host,+vmx -enable-kvm -netdev user,id=user.0 -device virtio-net,netdev=user.0 -usb -device nec-usb-xhci,id=xhci -device usb-tablet,bus=xhci.0 -serial stdio -smp 4 -m 512 -hda sda.img -hdb sdb.img -hdc sdc.img The system is accessible via both VGA and serial console. The user is "root", the password is "qwerty". Under the /root folder there is a reproducer script (reproducer.sh). It does trivial things like enabling sysrq, opening LUKS device, mounting a volume, running a background I/O (this is an important part, actually, since I wasn't able to trigger the issue without the background I/O) and, finally, running the smartctl in a loop. If you are lucky, within a minute or two you'll get the first warning followed shortly by subsequent bugs and I/O stall (htop is pre-installed for your convenience too). Notable changes in this VM comparing to generic defaults: 1) blk-mq is enabled via kernel cmdline (scsi_mod.use_blk_mq=1 is in /etc/default/grub) 2) BFQ is set via udev (check /etc/udev/rules.d/10-io-scheduler.rules file) Again, I wasn't able to reproduce the usercopy warning/bug and I/O hang without all these components being involved. Hope you enjoy it. P.S. I haven't tested Linus' master branch yet. For now, this VM runs v4.16 kernel. Regards, Oleksandr [1] https://natalenko.name/myfiles/usercopy_bfq_woe/