NetworkManager fails to start

5 messages, 2 authors, 2021-06-15 · open the first message on its own page

NetworkManager fails to start

From: Leon Romanovsky <leon@kernel.org>
Date: 2021-06-15 16:21:47 

Hi,

The commit 591a22c14d3f ("proc: Track /proc/$pid/attr/ opener mm_struct")
that we got in v5.13-rc6 broke our regression to pieces. The NIC interfaces
fail to start when using NetworkManager.

There is nothing in dmesg except error that NetworkManager failed to start.

Our setups are:
 * VMs with virtio-net NICs
 * Fedora 29

The revert fixes the issue and VMs boot with network working.

Thanks

Re: NetworkManager fails to start

From: Linus Torvalds <torvalds@linux-foundation.org>
Date: 2021-06-15 16:26:41 

On Tue, Jun 15, 2021 at 9:21 AM Leon Romanovsky [off-list ref] wrote:
The commit 591a22c14d3f ("proc: Track /proc/$pid/attr/ opener mm_struct")
that we got in v5.13-rc6 broke our regression to pieces. The NIC interfaces
fail to start when using NetworkManager.
Does the attached patch fix it?

It just makes the open always succeed, and then the private_data that
the open did (that may or may not then have been filled in) is only
used on write.

               Linus

Re: NetworkManager fails to start

From: Leon Romanovsky <leon@kernel.org>
Date: 2021-06-15 16:50:02 

On Tue, Jun 15, 2021 at 09:26:19AM -0700, Linus Torvalds wrote:
On Tue, Jun 15, 2021 at 9:21 AM Leon Romanovsky [off-list ref] wrote:
quoted
The commit 591a22c14d3f ("proc: Track /proc/$pid/attr/ opener mm_struct")
that we got in v5.13-rc6 broke our regression to pieces. The NIC interfaces
fail to start when using NetworkManager.
Does the attached patch fix it?
I pushed it for testing, will update shortly.

Thanks

It just makes the open always succeed, and then the private_data that
the open did (that may or may not then have been filled in) is only
used on write.

               Linus
quoted hunk
 fs/proc/base.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/fs/proc/base.c b/fs/proc/base.c
index 7118ebe38fa6..9cbd915025ad 100644
--- a/fs/proc/base.c
+++ b/fs/proc/base.c
@@ -2676,7 +2676,9 @@ static int proc_pident_readdir(struct file *file, struct dir_context *ctx,
 #ifdef CONFIG_SECURITY
 static int proc_pid_attr_open(struct inode *inode, struct file *file)
 {
-	return __mem_open(inode, file, PTRACE_MODE_READ_FSCREDS);
+	file->private_data = NULL;
+	__mem_open(inode, file, PTRACE_MODE_READ_FSCREDS);
+	return 0;
 }
 
 static ssize_t proc_pid_attr_read(struct file * file, char __user * buf,





  

    
Re: NetworkManager fails to start

    

      From: Leon Romanovsky <leon@kernel.org>

      Date: 2021-06-15 17:45:47 
    

  

  
On Tue, Jun 15, 2021 at 09:26:19AM -0700, Linus Torvalds wrote:
On Tue, Jun 15, 2021 at 9:21 AM Leon Romanovsky [off-list ref] wrote:
quoted
The commit 591a22c14d3f ("proc: Track /proc/$pid/attr/ opener mm_struct")
that we got in v5.13-rc6 broke our regression to pieces. The NIC interfaces
fail to start when using NetworkManager.
Does the attached patch fix it?
Yes, this patch fixed the issue.
Tested-by: Leon Romanovsky <leonro@nvidia.com>

Thanks

It just makes the open always succeed, and then the private_data that
the open did (that may or may not then have been filled in) is only
used on write.

               Linus
quoted hunk
 fs/proc/base.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/fs/proc/base.c b/fs/proc/base.c
index 7118ebe38fa6..9cbd915025ad 100644
--- a/fs/proc/base.c
+++ b/fs/proc/base.c
@@ -2676,7 +2676,9 @@ static int proc_pident_readdir(struct file *file, struct dir_context *ctx,
 #ifdef CONFIG_SECURITY
 static int proc_pid_attr_open(struct inode *inode, struct file *file)
 {
-	return __mem_open(inode, file, PTRACE_MODE_READ_FSCREDS);
+	file->private_data = NULL;
+	__mem_open(inode, file, PTRACE_MODE_READ_FSCREDS);
+	return 0;
 }
 
 static ssize_t proc_pid_attr_read(struct file * file, char __user * buf,





  

    
Re: NetworkManager fails to start

    

      From: Linus Torvalds <torvalds@linux-foundation.org>

      Date: 2021-06-15 18:06:21 
    

  

  
On Tue, Jun 15, 2021 at 10:45 AM Leon Romanovsky [off-list ref] wrote:
Yes, this patch fixed the issue.
Tested-by: Leon Romanovsky <leonro@nvidia.com>
Thanks.

I've committed that minimal fix, although we still seem to have some
unexplained failure in this area for android 7 cm14.1 user space.

This has turned out to be fairly painful, with multiple fixes on top
of fixes, and there's still something odd going on. Grr.

           Linus




    
  

  
    

      

        Keyboard shortcuts
      

      

        
          
hback out one level

          
jnext message in thread

          
kprevious message in thread

          
ldrill in

          
Escclose help / fold thread tree

          
?toggle this help