Received: by 2002:ac0:a581:0:0:0:0:0 with SMTP id m1-v6csp4479537imm; Mon, 25 Jun 2018 16:59:50 -0700 (PDT) X-Google-Smtp-Source: ADUXVKIstNQXcBGMmU6xQob2mLEjGnY12chhR6PizFdORG2QbB3Ve1BB1MtJUM4qcR6b/TLUXQ33 X-Received: by 2002:a65:4a4d:: with SMTP id a13-v6mr12329645pgu.161.1529971190672; Mon, 25 Jun 2018 16:59:50 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1529971190; cv=none; d=google.com; s=arc-20160816; b=U5CYXOUiaJi8La/80KcJFqZlltpaX8Y4NLwl2jQxKy09HLMFOEYPoRFCdNfaR0zvnd KAw7Ic02MHOHoA3N4WKRcXHAdkKn3e/5qdDUocV2kEUpBGaX7kwDyiBBlVvfIzm1eHWF w710lyuJ4AAagy+ymgibDwfiBZPoyDQUr+Np3mV1KHOqXOXaLJGou0ovXkGvz8x0ohWf KDD09DckV3q91nmkkIYnnHKUCqw1UtThVTnAlzon0zXrRLr6hGWp/QWhiMNHZampZ2YC nPqNQh+dFK7TPdV8Z3Y4J5TiYI0VLuo3bRPp50j23Y+1HMsPpxoANIW3Qd0ceOjFemWK yTjA== 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:mime-version:user-agent:date:message-id:subject :from:cc:to:arc-authentication-results; bh=T6M1Ea2lWkKI1m2JpBOt5Tj3Hp17bPAid1z2zbwPNFo=; b=AP5xKXn3ys/ZdIvpjpazdmSecKdn2CDXiw57LdKH+Q0G9/9Mu078udIbTUEUJpr0q6 M2w3GcPu1M691zuUpjqT/IS+M5eC2m4OmoYFxBm6fWq8bA1YZ8u/oFRl7AI0kwyHcM+Y 52DLlrlAZGGQI8CfnGzIFsUx4CbU3HhhSpNv3lORi/mCEuKu/OnjHwIwwyhZWN2zsGIM 5LIH60tl01h8gfvBZq1ucbIdX5KB4n8KsMEkkRHBWgTIDx/ba/i7CyNMoMkyrE/I2cjG dCooUdbvpHeLo+QK+Xuu6klfLbbRXO49YDieD2PaCZqd158iak9m3Os+0Hbkzuj7w7GR fATA== 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id b184-v6si216212pfa.167.2018.06.25.16.59.35; Mon, 25 Jun 2018 16:59:50 -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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933730AbeFYX6b (ORCPT + 99 others); Mon, 25 Jun 2018 19:58:31 -0400 Received: from mail-oi0-f50.google.com ([209.85.218.50]:39354 "EHLO mail-oi0-f50.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754330AbeFYX6a (ORCPT ); Mon, 25 Jun 2018 19:58:30 -0400 Received: by mail-oi0-f50.google.com with SMTP id 18-v6so4752053oiq.6 for ; Mon, 25 Jun 2018 16:58:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:cc:from:subject:message-id:date:user-agent :mime-version:content-language:content-transfer-encoding; bh=T6M1Ea2lWkKI1m2JpBOt5Tj3Hp17bPAid1z2zbwPNFo=; b=e9SALJMUdA0jVt7+iu8VPX7SiKeFBAtuxOBQHaigljkB/CTQVrK2vLlXnrQYtcjArA +L3OrhOXQiiGqeY5jTKWGxn9cJ9U+AWXkjMB4wXIALq3cA7oJhpS8SwYF5iX++lB7+iK pcZBYcRUiERD9v3W5wL8ETAC5u6yMvCdpltuXMiPZlKXW13spvm/JMGTrrGr1OPQ7L6O i8GlVrbE8CybQSBLhSS63QAfzoEA22TAqvFR5ihMIUeVEhtVVHrViqFY7bK2vcL8n/FL bQbl1EtPs4AtT36D8VWe3cPqqb8UCo2QiQb4wzvgDwdYsYcsX+L4HYDAkaGx/2etennZ qG3g== X-Gm-Message-State: APt69E133jfQ93kTfkFzjUMSZEV/UCzd55gKt50K9YLuc//6FE/FOeAb vMZbi2J5f0z24vCWO/kAvvZ/xA== X-Received: by 2002:aca:66db:: with SMTP id m88-v6mr355297oik.141.1529971109497; Mon, 25 Jun 2018 16:58:29 -0700 (PDT) Received: from ?IPv6:2601:602:9802:a8dc::f0c1? ([2601:602:9802:a8dc::f0c1]) by smtp.gmail.com with ESMTPSA id 5-v6sm103100oid.50.2018.06.25.16.58.27 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 25 Jun 2018 16:58:28 -0700 (PDT) To: Steve French , linux-cifs@vger.kernel.org Cc: samba-technical@lists.samba.org, linux-kernel@vger.kernel.org, Adam Williamson From: Laura Abbott Subject: F_OFD_GETLK implemented wrong with CIFS protocol version 2.0+ Message-ID: <77967693-040b-734a-8e18-be95d97478b3@redhat.com> Date: Mon, 25 Jun 2018 16:58:26 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, A while back, someone reported a failure on Fedora when trying to boot a QEMU image off of a CIFS share. The issue was reduced down to a test case (https://bugzilla.redhat.com/show_bug.cgi?id=1484130#c8) # cat test-ofd-lock.c #define _GNU_SOURCE #include #include #include #include int main(int argc, char **argv) { int ret; int fd; struct flock fl = { .l_whence = SEEK_SET, .l_start = 0, .l_len = 0, .l_type = F_RDLCK, }; if (argc < 2) { fprintf(stderr, "Usage: %s \n", argv[0]); return 1; } fd = open(argv[1], O_RDWR); if (fd < 0) { perror("open"); return errno; } ret = fcntl(fd, F_OFD_SETLK, &fl); if (ret) { perror("setlk"); return errno; } fl.l_type = F_WRLCK; ret = fcntl(fd, F_OFD_GETLK, &fl); if (ret) { perror("getlk"); return errno; } if (fl.l_type != F_UNLCK) { fprintf(stderr, "get lock test failed\n"); return 1; } return 0; } [root@localhost ~]# make test-ofd-lock cc test-ofd-lock.c -o test-ofd-lock [root@localhost ~]# touch /tmp/test && ./test-ofd-lock /tmp/test [root@localhost ~]# echo $? 0 [root@localhost ~]# touch /mnt/test && ./test-ofd-lock /mnt/test get lock test failed [root@localhost ~]# mount | grep /mnt //192.168.31.1/tddownload on /mnt type cifs (rw,relatime,vers=3.0, cache=strict,username=admin,domain=,uid=0, noforceuid,gid=0,noforcegid,addr=192.168.31.1,file_mode=0755, dir_mode=0755,nounix,serverino,mapposix,rsize=1048576, wsize=1048576,echo_interval=60,actimeo=1,user=admin) As explained by one of the QEMU developers (https://bugzilla.redhat.com/show_bug.cgi?id=1484130#c37) ''' It is a kernel bug. The code snippet in comment 8 shows clearly that the kernel is doing the wrong thing, which cannot be fixed/worked around by QEMU. In man 2 fcntl: F_OFD_GETLK (struct flock *) On input to this call, lock describes an open file description lock we would like to place on the file. If the lock could be placed, fcntl() does not actually place it, but returns F_UNLCK in the l_type field of lock and leaves the other fields of the structure unchanged. If one or more incompatible locks would prevent this lock being placed, then details about one of these locks are returned via lock, as described above for F_GETLK. which is not the case with the new CIFS behaviour. '' You can read the full context at https://bugzilla.redhat.com/show_bug.cgi?id=1484130 Any suggestions? Thanks, Laura