Received-SPF: pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Message-ID: <3cb5de6e-6f8f-e46a-96bd-a3d88a871f3a@virtuozzo.com>
Date:   Wed, 19 Jan 2022 08:17:23 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.5.0
Subject: Re: LTP nfslock01 test failing on NFS v3 (lockd: cannot monitor
 10.0.0.2)
Content-Language: en-US
To:     NeilBrown <neilb@suse.de>, Petr Vorel <pvorel@suse.cz>
Cc:     linux-nfs@vger.kernel.org,
        "J. Bruce Fields" <bfields@fieldses.org>,
        Chuck Lever <chuck.lever@oracle.com>,
        Trond Myklebust <trond.myklebust@hammerspace.com>,
        Anna Schumaker <anna.schumaker@netapp.com>,
        Steve Dickson <SteveD@redhat.com>, ltp@lists.linux.it,
        kernel@openvz.org
References: <YebcNQg0u5cU1QyQ@pevik>
 <164254391708.24166.6930987548904227011@noble.neil.brown.name>
From:   Nikita Yushchenko <nikita.yushchenko@virtuozzo.com>
In-Reply-To: <164254391708.24166.6930987548904227011@noble.neil.brown.name>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?MmQwbmdFSGNmODhSekNBbzB2VjdMRGI3VWhQZGg0Ukg2ZnY2ODFLRHlOR25N?=
 =?utf-8?B?TGNtbnp6K1hTT1pEdUpoRU1GMTd0cEFOUU93dFNHNkhzUzRWcjJYYkdld3pr?=
 =?utf-8?B?U05POWxSL1g2SXR6V003VU9wZUMxQ3JvcktiVXpWc3NBOE9oZTNNZUMybU9w?=
 =?utf-8?B?SnZJQWo1RWJFcUE4TS93S3c4QTVOQU9RdFV3dFovbEtrS0xhWXZFbDhmbHZn?=
 =?utf-8?B?aVhWamtmZDdQdVFHamtIbnpRZjh6a21xMkY4ZmFZRXpTRzNZNFRTQUR5NjN5?=
 =?utf-8?B?elpyQzBHeEh4Uys1UVl0UWNmdWg5SDNlZk40YlpTWmpnSDU3cGJnQWpnRncv?=
 =?utf-8?B?UzNBMVlxeThiT2E0dWd3QmtBVm4ydzhicHV4bmo3YmUyQVFvZWZTeU96UWJh?=
 =?utf-8?B?ZmdXV1ZzSjZHNW50dGZLYlhoemMrNjgyVHJuTGM5c2IzSkdTM3pFOGV5VkZB?=
 =?utf-8?B?eE4xb3YvUXBjNkYwN3pxWXZMS2dRYTBrNktCM2NoYWNRZmFNWUlmUlI5QUF4?=
 =?utf-8?B?VzlUdTR1RG5WWVFzelNaWDJnMVVNRG44cU56NC9iMklPWW5qQ1dCK3FvamVF?=
 =?utf-8?B?RnBZQ1ZXMGl3bXBRSkNFUlgrNEhsOFJmb1dwWEYwSkdWa3RodFIra0ZYMmNC?=
 =?utf-8?B?dGhhM0p0T0JoUWVZQzVxcVVEa3gzNk0rcVp5ckNPRlR5eWZNUjVwYTdqYkZH?=
 =?utf-8?B?YlBqOUtVZFg1ODYvT2tVbTBrOXZuaFd3UnJjTCtrT2V6cFVPc1VwQzRIbFBP?=
 =?utf-8?B?WWo3K0lndWZkMU9lRnFTcFZ1SVlsa2M5QlhKcjFEQTlnWG1vNitpb1lVWHhB?=
 =?utf-8?B?REo4L3JlN1VSL1orbm4wUlRpRDlLbS9JaDdYU1ZpMnZQM0d1K0pEMFI1d0JK?=
 =?utf-8?B?cFZrWmQ5OWdyN21zdllEb2JyVGlleXZxWVdXMlh5M1hDQ1VCaVZOeHBIY0hj?=
 =?utf-8?B?NUlOdUM1WThoaFdkek0xWlVyYXhQVU9LbnBhRVlSZFNEN1Z1YUpmM2ZiQ0JB?=
 =?utf-8?B?aEdCdlZvQTlxTGUxT0lsaXp6VGhiNGtWOWdtSlM4eXN6YzJMN213S1ZVV1d2?=
 =?utf-8?B?ckFIdnBlRzMweGJZWmhDWThoT3liQld4a25DRDUzSnZaTHJ0aC9OM2VkZDVl?=
 =?utf-8?B?dHllNmxSQ09GZVdvRXg1WUhaWmtyWHZBNzUrUEFPRnRMNXdHRHhsTEgvL3hD?=
 =?utf-8?B?ZHFLd2VWK0hCeDkrYVQxbFJrUHl1Mkh2QVlsa0FHUE1ORlR2cG5pWjdaeTFF?=
 =?utf-8?B?dWNvRGpVbkFIYktPMTM2Ynk4VVFRNjlKd3BiTU1jWXlUSzBycXJFSW1oK1NZ?=
 =?utf-8?B?N1dJbDhheHltZUUvVHdKTmpqTkUzVmNFS3lVQ2FJS1B5OVVqaVB6bnRSZzB3?=
 =?utf-8?B?b0VHYTArSjl4aXFSZHRuQW5mTEFzT0EzVzQvUnh1WHVNb3JuRVB4RUQwMTZ6?=
 =?utf-8?B?WFhWRi9XMytOYW1SLzFGajZWckNXUlBZZkNacy9MZVR3Y3RpYnNOL25TdUZU?=
 =?utf-8?B?Z1FFclhzUTA4MHdQOGhLRDRKUEZnaW5zeU52Z0VUSjMvd0I1Y29Yak5WSzhG?=
 =?utf-8?B?Zm5mWVpiSFhZTlRrb2RET0wzYVlFTXUvZzk4L1hQd1NaaWg0RCtMTWRUUW52?=
 =?utf-8?B?S1JEOTVkbXA3S2NJUmRZeTZvb2hWYjVZWVZYMisrM1BtVlJINXd2b0FBTEJR?=
 =?utf-8?B?N1M5ampiSEgwcElhRW5mM3hETFF2NHNVUkpiTVY2N3hWMWVEbERBOFQzOUx5?=
 =?utf-8?B?c09CcGtXcmI1MlBob0xXejJxczVWNTNXSUx6dEloTGJlQktJSVV1bTc4Vks5?=
 =?utf-8?B?VUpGYnpsUTdvRU9vMUlabEJZNlVWNWtwZWwzSDZFMVRrOFhLOWNQZzdOR1FT?=
 =?utf-8?B?SjhYaWFCRVA4c3FleWlDOUVJSVJCbnZWbHc0bWtybVlwcWNINTNKbVN6U3lq?=
 =?utf-8?B?YkNPS3JGM3RlYWp2SXpNWFFGS0tiZEZCV0V0RzBRR2FuNGhBQUZNN2xac0xy?=
 =?utf-8?B?OGErSkdMdEdMSVlRL0s5Q050MXpYVmxHZ3RrSEptMHBPVGFaa09OMHZ3S2cr?=
 =?utf-8?B?bmdXOXY1RFcwaHlkaWxCWWozeUcvTVc1Q3hXY0NVV015MkV6TE9XamQwRzgx?=
 =?utf-8?B?NDM4d1JaYktLWlZkVmZvcGVDOUd0dW1MdC9YZjZRQzdxNkd5czJscU12bFN6?=
 =?utf-8?B?Tnd0a09hcHNwOXVSOCtWTzVJZ1dLM3ByYVNLYytXRVBrNWNWcXVmSUZHcDRC?=
 =?utf-8?B?UmRudnlBVFZFektKRGl2cEtjV01nPT0=?=
X-OriginatorOrg: virtuozzo.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 38529308-93d4-43d0-ec8a-08d9db0afb5b
X-MS-Exchange-CrossTenant-AuthSource: VE1PR08MB5630.eurprd08.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Jan 2022 05:17:26.4146
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 0bc7f26d-0264-416e-a6fc-8352af79c58f
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: tCUoUXKas6SuTTk6FydksTtbHZByL++Xtpm+PUJAIAwFE0sGq8zj1DQVWNPeyOc0rOV4XaFfRa8r9sql5qM6cBMsKUq59ybt3iTuJ5fFokI=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VE1PR08MB4766
Precedence: bulk
List-ID: <linux-nfs.vger.kernel.org>
X-Mailing-List: linux-nfs@vger.kernel.org

19.01.2022 01:11, NeilBrown wrote:
> On Wed, 19 Jan 2022, Petr Vorel wrote:
>> Hi all,
>>
>> this is a test failure posted by Nikita Yushchenko [1]. LTP NFS test nfslock01
>> looks to be failing on NFS v3:
>>
>> "not unsharing /var makes AF_UNIX socket for host's rpcbind to become available
>> inside ltpns. Then, at nfs3 mount time, kernel creates an instance of lockd for
>> ltpns, and ports for that instance leak to host's rpcbind and overwrite ports
>> for lockd already active for root namespace. This breaks nfs3 file locking."
> 
> "not unsharing /var" ....  can this be fixed by simply unsharing /var?
> Or is that not simple?

Big picture is - lockd tries to be per-netns, but lockd isn't standalone, it depends on rpcbind, and 
rpcbind isn't guaranteed to be per-netns.

One can argue that it is not kernel's job to provide per-netns rpcbind.

Still, the current situation is - by default, doing an nfs mount from within netns B immediately breaks 
lockd serving nfs mounts exported from different netns A. "By default" = "as long as nfsmount process 
executed in netns B is also in a different mount namespace that has RPCBIND_SOCK_PATHNAME not pointing 
to AF_UNIX socket instance owned by rpcbind serving netns A.

Although in LTP's 'nfslock01' test the "non working locking" is reproduced on the same mount that 
triggered the breakage, the breakage is not limited to that mount. Since that mount operation in netns 
B, any client of nfs exports from netns A will get locking broken - including clients running on 
different physical hosts.

I'd say that using AF_UNIX connection from lockd to rpcbind does not play well with per-netns lockd.

Solution to use AF_UNIX connection to rpcbind only for lockd serving root netns, and using AF_INET 
otherwise - looks more sane.

> On could easily argue that RPCBIND_SOCK_PATHNAME in the kernel should be
> changed to "/run/rpcbind.sock".

It may be a better idea to make it configurable per-netns.

Nikita