public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Baoquan He <bhe@redhat.com>
To: "yang.zhang" <gaoshanliukou@163.com>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>,
	kexec@lists.infradead.org, linux-kernel@vger.kernel.org,
	"yang.zhang" <yang.zhang@hexintek.com>,
	akpm@linux-foundation.org
Subject: Re: [PATCH] kexec: should use uchunk for user buffer increasing
Date: Mon, 19 Feb 2024 10:38:22 +0800	[thread overview]
Message-ID: <ZdK/Hsy1TMB8PlJs@MiWiFi-R3L-srv> (raw)
In-Reply-To: <2a207ca2.1e87.18dbf17ee10.Coremail.gaoshanliukou@163.com>

On 02/19/24 at 10:00am, yang.zhang wrote:
> 
> 
> 
> Thanks for your replies.
> Do you have plans to merge the improving code for clarity, or just keep them unchanged.

You need post v2 to change those two places as Eric has demonstrated.
Please CC Andrew when you post.

> 
> At 2024-02-05 20:27:33, "Eric W. Biederman" <ebiederm@xmission.com> wrote:
> >Baoquan He <bhe@redhat.com> writes:
> >
> >> On 01/30/24 at 06:18pm, yang.zhang wrote:
> >>> From: "yang.zhang" <yang.zhang@hexintek.com>
> >>> 
> >>> Because of alignment requirement in kexec-tools, there is
> >>> no problem for user buffer increasing when loading segments.
> >>> But when coping, the step is uchunk, so we should use uchunk
> >>> not mchunk.
> >>
> >> In theory, ubytes is <= mbytes. So uchunk is always <= mchunk. If ubytes
> >> is exhausted, while there's still remaining mbytes, then uchunk is 0,
> >> there's still mchunk stepping forward. If I understand it correctly,
> >> this is a good catch. Not sure if Eric has comment on this to confirm.
> >
> >As far as I can read the code the proposed change is a noop.
> >
> >I agree it is more correct to not advance the pointers we read from,
> >but since we never read from them after that point it does not
> >matter.
> >
> >>
> >> static int kimage_load_normal_segment(struct kimage *image,
> >>                                          struct kexec_segment *segment)
> >> {
> >> ......
> >>
> >>                 ptr += maddr & ~PAGE_MASK;
> >>                 mchunk = min_t(size_t, mbytes,
> >>                                 PAGE_SIZE - (maddr & ~PAGE_MASK));
> >>                 uchunk = min(ubytes, mchunk);
> >> ......}
> >
> >If we are going to improve the code for clarity.  We probably
> >want to do something like:
> >
> >diff --git a/kernel/kexec_core.c b/kernel/kexec_core.c
> >index d08fc7b5db97..1a8b8ce6bf15 100644
> >--- a/kernel/kexec_core.c
> >+++ b/kernel/kexec_core.c
> >@@ -800,22 +800,24 @@ static int kimage_load_normal_segment(struct kimage *image,
> >                                PAGE_SIZE - (maddr & ~PAGE_MASK));
> >                uchunk = min(ubytes, mchunk);
> > 
> >-               /* For file based kexec, source pages are in kernel memory */
> >-               if (image->file_mode)
> >-                       memcpy(ptr, kbuf, uchunk);
> >-               else
> >-                       result = copy_from_user(ptr, buf, uchunk);
> >+               if (uchunk) {
> >+                       /* For file based kexec, source pages are in kernel memory */
> >+                       if (image->file_mode)
> >+                               memcpy(ptr, kbuf, uchunk);
> >+                       else
> >+                               result = copy_from_user(ptr, buf, uchunk);
> >+                       ubytes -= uchunk;
> >+                       if (image->file_mode)
> >+                               kbuf += uchunk;
> >+                       else
> >+                               buf += uchunk;
> >+               }
> >                kunmap_local(ptr);
> >                if (result) {
> >                        result = -EFAULT;
> >                        goto out;
> >                }
> >-               ubytes -= uchunk;
> >                maddr  += mchunk;
> >-               if (image->file_mode)
> >-                       kbuf += mchunk;
> >-               else
> >-                       buf += mchunk;
> >                mbytes -= mchunk;
> > 
> >                cond_resched();
> >
> >And make it exceedingly clear that all of the copying and the rest
> >only happens before uchunk goes to zero.  Otherwise we are relying
> >on a lot of operations becoming noops when uchunk goes to zero.
> >
> >Eric


  reply	other threads:[~2024-02-19  2:38 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-30 10:18 [PATCH] kexec: should use uchunk for user buffer increasing yang.zhang
2024-02-04  7:38 ` Baoquan He
2024-02-05 12:27   ` Eric W. Biederman
2024-02-05 12:59     ` Baoquan He
2024-02-19  2:00     ` yang.zhang
2024-02-19  2:38       ` Baoquan He [this message]
2024-02-19  9:26         ` yang.zhang

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=ZdK/Hsy1TMB8PlJs@MiWiFi-R3L-srv \
    --to=bhe@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=ebiederm@xmission.com \
    --cc=gaoshanliukou@163.com \
    --cc=kexec@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=yang.zhang@hexintek.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