linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@linux-foundation.org>
To: Li Zhijian <lizhijian@cn.fujitsu.com>
Cc: linux-kernel@vger.kernel.org,
	Dominik Brodowski <linux@dominikbrodowski.net>,
	zhijianx.li@intel.com, Philip Li <philip.li@intel.com>
Subject: Re: [PATCH] initramfs: clean old path before creating a hardlink
Date: Mon, 26 Nov 2018 15:34:00 -0800	[thread overview]
Message-ID: <20181126153400.4985207970edfb39cb47eb61@linux-foundation.org> (raw)
In-Reply-To: <1542352368-13299-1-git-send-email-lizhijian@cn.fujitsu.com>

On Fri, 16 Nov 2018 15:12:48 +0800 Li Zhijian <lizhijian@cn.fujitsu.com> wrote:

> Previously, sys_link() will fail due to the new path is already existed.
> this case ofen appears when we use a concated initrd, below is an
> sample:
> 
> 1) prepare a basic rootfs, it contains a regular files rc.local
> lizhijian@:~/yocto-tiny-i386-2016-04-22$ cat etc/rc.local
>  #!/bin/sh
>  echo "Running /etc/rc.local..."
> yocto-tiny-i386-2016-04-22$ find . | sed 's,^\./,,' | cpio -o -H newc | gzip -n -9 >../rootfs.cgz
> 
> 2) create a extra initrd which also includes a etc/rc.local
> lizhijian@:~/lkp-x86_64/etc$ echo "append initrd" >rc.local
> lizhijian@:~/lkp/lkp-x86_64/etc$ cat rc.local
> append initrd
> lizhijian@:~/lkp/lkp-x86_64/etc$ ln rc.local rc.local.hardlink
> append initrd
> lizhijian@:~/lkp/lkp-x86_64/etc$ stat rc.local rc.local.hardlink
>   File: 'rc.local'
>   Size: 14        	Blocks: 8          IO Block: 4096   regular file
> Device: 801h/2049d	Inode: 11296086    Links: 2
> Access: (0664/-rw-rw-r--)  Uid: ( 1002/lizhijian)   Gid: ( 1002/lizhijian)
> Access: 2018-11-15 16:08:28.654464815 +0800
> Modify: 2018-11-15 16:07:57.514903210 +0800
> Change: 2018-11-15 16:08:24.180228872 +0800
>  Birth: -
>   File: 'rc.local.hardlink'
>   Size: 14        	Blocks: 8          IO Block: 4096   regular file
> Device: 801h/2049d	Inode: 11296086    Links: 2
> Access: (0664/-rw-rw-r--)  Uid: ( 1002/lizhijian)   Gid: ( 1002/lizhijian)
> Access: 2018-11-15 16:08:28.654464815 +0800
> Modify: 2018-11-15 16:07:57.514903210 +0800
> Change: 2018-11-15 16:08:24.180228872 +0800
>  Birth: -
> 
> lizhijian@:~/lkp/lkp-x86_64$ find . | sed 's,^\./,,' | cpio -o -H newc | gzip -n -9 >../rc-local.cgz
> lizhijian@:~/lkp/lkp-x86_64$ gzip -dc ../rc-local.cgz | cpio -t
> .
> etc
> etc/rc.local.hardlink <<< it will be extracted first at this initrd
> etc/rc.local
> 
> 3) concate 2 initrds and boot
> lizhijian@:~/lkp$ cat rootfs.cgz rc-local.cgz >concate-initrd.cgz
> lizhijian@:~/lkp$ qemu-system-x86_64 -nographic -enable-kvm -cpu host -smp 1 -m 1024 -kernel ~/lkp/linux/arch/x86/boot/bzImage -append "console=ttyS0 earlyprint=ttyS0 ignore_loglevel" -initrd ./concate-initr.cgz -serial stdio -nodefaults
> 
> In this case, sys_link(2) will fail and return -EEXIST, so we can only
> get the rc.local at rootfs.cgz instead of rc-local.cgz

I can't claim to understand this, but I believe you ;)

How serious is this problem?  Do you think a 4.20 merge is justified? 
Or a -stable backport?  If so, why?

> --- a/init/initramfs.c
> +++ b/init/initramfs.c
> @@ -291,12 +291,16 @@ static int __init do_reset(void)
>  	return 1;
>  }
>  
> +static void __init clean_path(char *path, umode_t fmode);
> +
>  static int __init maybe_link(void)
>  {
>  	if (nlink >= 2) {
>  		char *old = find_link(major, minor, ino, mode, collected);
> -		if (old)
> +		if (old) {
> +			clean_path(collected, 0);
>  			return (ksys_link(old, collected) < 0) ? -1 : 1;
> +		}
>  	}
>  	return 0;
>  }

The forward declaration is unpleasing.  Why not simply move the function?

--- a/init/initramfs.c~initramfs-clean-old-path-before-creating-a-hardlink-fix
+++ a/init/initramfs.c
@@ -291,7 +291,17 @@ static int __init do_reset(void)
 	return 1;
 }
 
-static void __init clean_path(char *path, umode_t fmode);
+static void __init clean_path(char *path, umode_t fmode)
+{
+	struct kstat st;
+
+	if (!vfs_lstat(path, &st) && (st.mode ^ fmode) & S_IFMT) {
+		if (S_ISDIR(st.mode))
+			ksys_rmdir(path);
+		else
+			ksys_unlink(path);
+	}
+}
 
 static int __init maybe_link(void)
 {
@@ -305,18 +315,6 @@ static int __init maybe_link(void)
 	return 0;
 }
 
-static void __init clean_path(char *path, umode_t fmode)
-{
-	struct kstat st;
-
-	if (!vfs_lstat(path, &st) && (st.mode ^ fmode) & S_IFMT) {
-		if (S_ISDIR(st.mode))
-			ksys_rmdir(path);
-		else
-			ksys_unlink(path);
-	}
-}
-
 static __initdata int wfd;
 
 static int __init do_name(void)
_


  parent reply	other threads:[~2018-11-26 23:34 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-16  7:12 [PATCH] initramfs: clean old path before creating a hardlink Li Zhijian
2018-11-22  1:55 ` Li Zhijian
2018-11-26 23:34 ` Andrew Morton [this message]
2018-11-27  4:04   ` Li Zhijian

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20181126153400.4985207970edfb39cb47eb61@linux-foundation.org \
    --to=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@dominikbrodowski.net \
    --cc=lizhijian@cn.fujitsu.com \
    --cc=philip.li@intel.com \
    --cc=zhijianx.li@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).