Received: by 2002:ac0:a5b6:0:0:0:0:0 with SMTP id m51-v6csp1804810imm; Thu, 14 Jun 2018 04:15:44 -0700 (PDT) X-Google-Smtp-Source: ADUXVKJfAwN23dTx1d3aYwcMqT6TVbGebDGAiyIhFPjQlj1UU9zFXI1wSIy6fI3OzWN3of7OPZ1R X-Received: by 2002:a17:902:9a9:: with SMTP id 38-v6mr2589419pln.114.1528974944240; Thu, 14 Jun 2018 04:15:44 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1528974944; cv=none; d=google.com; s=arc-20160816; b=nlumVZ6IrKINqWU1iBy8pD9v+1A/mM9OehcDpWUEeOJnKbSC96oMt4NhS3eias30cS ViYQltPANVh+CMAOogEJuNOwhLuJkMXkVE2x9jQfIb6LcnlxsFzbzFWTtdX4HSNZj3is +EdPi5kBAxMvc53HgkI+gEvLZ38a0rCT+ZAP+LnTVcD5MoEzsTQZQK2/1z+ez8HFEvsM 1NXwTvaM66qmyTNzsw6WmzxVJ17apv9GgvfJTFckNI2QJmzx5Et9iddJzHxqw5OafUZl kFDGi4PTwe57V7C1J+EN8xQapzgHUq56Wv1tYhVgI2Bb32DaXITbTn7k5XoUyzOM/owz 8Q8g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:arc-authentication-results; bh=hQj9tkDalsxdi7ljHLvhWWfhSdlO2sTUn/87NfTGeZI=; b=FF87zrvRDAXIE9DnZjkr32P2AooRHIVvbRDVXE5TLdvJFw/hfyBRiEGPzQHqT8xlMs KwBZLjXLmNBxk/ujE8CV+KxyqQNwAtrNibdcJJcfXGrL3xuQ5oNdc1VtgbnJk57iAE6F g4NuQBzCu91BzgKsvN9KWjww/atUXcGpVAD+01RLHxWbNOan1+XlJH6ipUCXGHimwwU7 Gi62Zj3sSpxFLY5jNsu47un8EAuc0neE8WpTVWjAsqJGcKtm9dvNb+Oi3qpU+NzvfMR7 AaiEWL/f4wpGmbjittLJIJqdNexwNTfjOzcbepJXOHFlQfJ3rNpRVNb7mHSvGgqVdgdo RO0w== 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 f28-v6si5297189pfk.107.2018.06.14.04.15.30; Thu, 14 Jun 2018 04:15:44 -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 S964865AbeFNLNu (ORCPT + 99 others); Thu, 14 Jun 2018 07:13:50 -0400 Received: from mx3-rdu2.redhat.com ([66.187.233.73]:56868 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S964838AbeFNLNq (ORCPT ); Thu, 14 Jun 2018 07:13:46 -0400 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.rdu2.redhat.com [10.11.54.3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 0CA7A859A8; Thu, 14 Jun 2018 11:13:46 +0000 (UTC) Received: from [10.10.66.2] (ovpn-66-2.rdu2.redhat.com [10.10.66.2]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 2FCAD111D3CB; Thu, 14 Jun 2018 11:13:45 +0000 (UTC) From: "Benjamin Coddington" To: "Konstantin Khorenko" , "Jeff Layton" Cc: "Kirill Gorkunov" , "Andrey Vagin" , "J. Bruce Fields" , "Alexander Viro" , "Vasily Averin" , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 0/2] fs/lock: show locks info owned by dead/invisible processes Date: Thu, 14 Jun 2018 07:13:22 -0400 Message-ID: <98D5E5F1-65D6-44C1-9E7C-C5A9043BC29F@redhat.com> In-Reply-To: <20180608142712.32460-1-khorenko@virtuozzo.com> References: <20180608142712.32460-1-khorenko@virtuozzo.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Scanned-By: MIMEDefang 2.78 on 10.11.54.3 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.2]); Thu, 14 Jun 2018 11:13:46 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.2]); Thu, 14 Jun 2018 11:13:46 +0000 (UTC) for IP:'10.11.54.3' DOMAIN:'int-mx03.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'bcodding@redhat.com' RCPT:'' Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 8 Jun 2018, at 10:27, Konstantin Khorenko wrote: > The behavior has been changed after 9d5b86ac13c5 ("fs/locks: Remove > fl_nspid > and use fs-specific l_pid for remote locks") > and now /proc/$PID/fdinfo/$FD does not show the info about the lock > * if the flock owner process is dead and its pid has been already > freed > or > * if the lock owner is not visible in current pidns. > > CRIU uses this interface to store locks info during dump and thus can > break > on v4.13 and newer. > > So let's show info about locks anyway in described cases (like it was > before > 9d5b86ac13c5), but show pid number saved in file_lock struct if we are > in > init_pid_ns (patch 1) or just zero otherwise (patch 2) like we do with > SID. > > Reproducer: > process A process A1 process A2 > fork()---------> > exit() open() > flock() > fork()---------> > exit() sleep() > > Before the patch: > ================ > (root@vz7)/: cat /proc/${PID_A2}/fdinfo/3 > pos: 4 > flags: 02100002 > mnt_id: 257 > lock: (root@vz7)/: > > After the patch: > =============== > (root@vz7)/:cat /proc/${PID_A2}/fdinfo/3 > pos: 4 > flags: 02100002 > mnt_id: 295 > lock: 1: FLOCK ADVISORY WRITE ${PID_A1} b6:f8a61:529946 0 EOF > > =============== > # cat flock1.c > > #include > #include > #include > #include > #include > #include > #include > > int main(void) > { > int fd; > int err; > pid_t child_pid; > > child_pid = fork(); > if (child_pid == -1) > perror("fork failed"); > if (child_pid) { > exit(0); > } > > fd = open("/tmp/a", O_CREAT | O_RDWR); > if (fd == -1) > perror("Failed to open the file"); > > err = flock(fd, LOCK_EX); > if (err == -1) > perror("flock failed"); > > child_pid = fork(); > if (child_pid == -1) > perror("fork failed"); > if (child_pid) > exit(0); > > sleep(10000); > > return 0; > } > > Konstantin Khorenko (2): > fs/lock: skip lock owner pid translation in case we are in > init_pid_ns > fs/lock: show locks taken by processes from another pidns These look good to me too. It makes sense that we treat pid numbers out of our namespace in the same way we'd treat remote pids, by returning 0 instead of skipping their display altogether. You can add my Reviewed-by: Benjamin Coddington to these two. Ben