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: <a35ebb8b-6e61-8445-cf19-285bf2f875ad@virtuozzo.com>
Date:   Tue, 18 Jan 2022 18:51:27 +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:     Petr Vorel <pvorel@suse.cz>, linux-nfs@vger.kernel.org
Cc:     "J. Bruce Fields" <bfields@fieldses.org>,
        Chuck Lever <chuck.lever@oracle.com>,
        Trond Myklebust <trond.myklebust@hammerspace.com>,
        Anna Schumaker <anna.schumaker@netapp.com>,
        Neil Brown <neilb@suse.de>, Steve Dickson <SteveD@redhat.com>,
        ltp@lists.linux.it, kernel@openvz.org
References: <YebcNQg0u5cU1QyQ@pevik>
From:   Nikita Yushchenko <nikita.yushchenko@virtuozzo.com>
In-Reply-To: <YebcNQg0u5cU1QyQ@pevik>
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?Kyt5Qm1EODlqQ1F6OUlWa250MmdmNzZwS2psVERjZzAyZExKT0RLYUFjWGRi?=
 =?utf-8?B?TnQxc1NVMno1RmlHb2x3L2hJTnprcFdBdzl0N2NyaUhPdXNPb29YQkFQZ2s1?=
 =?utf-8?B?S0oyQTBudUswUFNyY2ZLdVNFZUVkcXovME5Ea1oxL0pLL3BHVk1ublJRb3F4?=
 =?utf-8?B?WVlRUWtwbXdEMVZwSkVsNWdsSzNLSkhlUkFGYmhvYTBTcUVNUjRYM0NyQkV0?=
 =?utf-8?B?aFg0OWdHQ1dySzFMcDhHdEJGcGo4Rk52UGwwVjdudmVybnF0R1d2VHlZbnRn?=
 =?utf-8?B?ZWNFWWJlc0RVSDRUSmNNb3VObGpyS2p0cUkvazZUVkZ3QjM5V1Qyb1BUa1BL?=
 =?utf-8?B?MDdPRS9ydjBtcVJpRUJPaFdabFFGbHVoQ1FTY3JoeC9CR0kzUUt5ck92d1VM?=
 =?utf-8?B?K0JaODZmYmI5aGJlV25hQjQ0Y3lWWFZqRmxKN01pbFMwdEcxeGxSc0xhencr?=
 =?utf-8?B?NjB0VFZRWGhIdHovMHlvS0hCaFliSVNHemtUNUZqWlNmaDF1ckdoMTZub0ZY?=
 =?utf-8?B?bDN4V2tLZjFCLytVZGFiSmt4eDhnbTFqWWo0K0ZvWlh0SndLZ0ZTV2Jkbnhy?=
 =?utf-8?B?K0xkMkcveXFvcW12cGxaTm1qMzRtSDdKZkJWdWNGOWNvZ0M2Q2dTRVBqTEFx?=
 =?utf-8?B?QkNnK2ZPMC9mOWxXWEozVksxUzk0ZFcwNU5LRTVyWnYrV3NVQXV6TUpsdWlD?=
 =?utf-8?B?aUlkQ3YvSkZyanZOTHlmM1FDdVRPWGZjb3FNdnJzSXp3WG8rZkRhcE9XaUVj?=
 =?utf-8?B?UkVDVi9YM2dWRjhuS1RuRGUybUt1K21Yc1pmZTY3QXZlZmJ1Y3pJbTEwb3ZG?=
 =?utf-8?B?NFYxekxLTW5WZ21hVE1hV2dUa0JyUEdDLzY2RnFWNWhiSlRJNGkxM1FxSWZJ?=
 =?utf-8?B?YStOUjVwalRrTXlxMzFzOUlTaTJzV253MUxseDZkdTcwZXZIenBJMGZOV3Zy?=
 =?utf-8?B?RXE3QnZtUzE2MmFud0pxM3hpYmo4Q1VSYzRGdWtiRzJOTkxLSmM0cStNMlcw?=
 =?utf-8?B?RzVDRzBFWndTWVN4cnRGcENTL3pqamphNmRjSnpocm9Bdlk0aTZyWjZxT245?=
 =?utf-8?B?STlIMjRRSTJ0d2F3TTgxNlk2T2xHc1RpK0FGZ0VySGhoSG1WSkwxZFppYVFt?=
 =?utf-8?B?cjM4MVBnOUp1a1YyRHIrYjVyS2VLNFcvV25kcUdQamhIYXRBY1lmY1QxMm1I?=
 =?utf-8?B?b0IvSENTR3VQbVY5YzBYZ0xvaVBWcUtzVWhRWW1wZ1JRcWdNb0plalJKWERI?=
 =?utf-8?B?TlM3MUtWZE9sV0RwNW92Z2czRHZkVng1ZlJjeDBCM2xiSGhOWWcvTEpZYy85?=
 =?utf-8?B?U0h0alFsbG5MT09YSTVraThEZllFSXBMOVptMkh4OUYxd3RwcW9qcG9RZTB2?=
 =?utf-8?B?UklPcGx1WGNhb1B5NHZWWE9GVk9yUDlmdHMxU1JMTnVoRFFKTVk1VUJoWXRw?=
 =?utf-8?B?OUsvOXFzWVhFWlMzZThKVmJwQnliMUk1dEtJWW93a3ljT2JaUFJaL29wYVU1?=
 =?utf-8?B?VUxuU05kNXFGUFltZzRPSndoVzNVTitMaGVueEI2OU9MOElQZjR4S1dZOVI5?=
 =?utf-8?B?NlpYclJhZzZYKzFBZ2hkUi9hOTJQTDdjdG9aMnE3M3l2VVpMdzBpcFgzWWJh?=
 =?utf-8?B?Ky9Dbnd3VWo3SGgwWGordXB4TzNGdEtvNURmU25vU2ZnY2Y3ZFREaVpyL1Nt?=
 =?utf-8?B?L0dNaENNaXhydDk4NnR3Q0ZzUFNhL010WTJHazREOXNpYWFNWWdFOGlYa1hD?=
 =?utf-8?B?R1RTcWZFaXRtUmRUOHZWYjYzQ0dDNXQ0ci92RHVJeHlMVUU5OGlXMmJReDZl?=
 =?utf-8?B?NEcwQ3B4MTd6ZGxhN3FqUUcvU3BzTlZ3cUhpWWl6clhPbVpDd2o3V1c1Z2c2?=
 =?utf-8?B?dmtLOFNNcXNEd1R0VDB1SCtBWUQ4cDJKRWZxM1c2VDlqa0oxZTEyREFybTZw?=
 =?utf-8?B?MjM3Y3VSem1iMjYvK0N5cTRJcVVVZW54TmlIS2dqV3NQREI5M2JCVEQzbVUy?=
 =?utf-8?B?TSs3V3ZtSkNndXVLSUVFK0dpaU5mbU5jTk85aFFNYVVid2ZReEliS3h5UkY3?=
 =?utf-8?B?SkNETTVwd0tQcjQ1TmliNUYvdmpBR0JoTVdxUkRDYnZETFRRTC9UY0FGMnBF?=
 =?utf-8?B?b0YwenBoREt2L1EvRTdLOFF0UDg4TmZ1aGNvUWxjZTk0a0FicjQ2MjlqZG9x?=
 =?utf-8?B?KzJMSHRwMWhxQzVzc2doeWw3d3k4OFRCeHAvSDdOcUNGRHB4c09UVVF5bGpM?=
 =?utf-8?B?MXdUWUxNSWRzMTV6cWNkQXlBd2JnPT0=?=
X-OriginatorOrg: virtuozzo.com
X-MS-Exchange-CrossTenant-Network-Message-Id: e15b8935-786f-4237-b3fa-08d9da9a64f2
X-MS-Exchange-CrossTenant-AuthSource: VE1PR08MB5630.eurprd08.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Jan 2022 15:51:30.5581
 (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: 9vWG/fwaTQkc5M1ZJErVOASdZftTtxbfecDXW22tIY9a/u/xh1x3lpToGxlke1n9iqZPXJDJ7NVuSBdeMZxY4cFg7M9g9b4dYJyenfSybtE=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR08MB3488
Precedence: bulk
List-ID: <linux-nfs.vger.kernel.org>
X-Mailing-List: linux-nfs@vger.kernel.org

18.01.2022 18:26, 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."

What exactly happens is:

Test runs 'mount' in non-root netns, trying to mount a directory from root netns of the same host via nfsv3

(Part of) call chain inside the kernel

nfs_try_get_tree()
  nfs3_create_server()
   nfs_create_server()
    nfs_init_server()
     nfs_start_lockd()
      nlmclnt_init()
       lockd_up()
        svc_bind()
         svc_rpcb_setup()
          rpcb_create_local()

... and at this point it tries AF_UNIX connection to /var/run/rpcbind.sock

AF_UNIX is not netns-aware.
So it connects to host's rpcbind.
And overwrites ports registered in host's rpcbind by lockd instance for root namespace. Since this 
point, lockd instance for root namespace becomes no longer accessible (it still listens but nobody can 
learn the ports). Thus nfs locks don't work.

I'm not sure what is the correct behavior here.

Maybe rpcb_create_local() shall detect that it is not in root netns, and only try AF_INET connection to 
localhost in that case.

Maybe it shall not try AF_UNIX at all. Are there any realistic cases when rpcbind is accessible via 
AF_UNIX only?

Nikita