Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

[question] zero-copy support/example #223

Open
alagalah opened this issue Sep 8, 2016 · 5 comments
Open

[question] zero-copy support/example #223

alagalah opened this issue Sep 8, 2016 · 5 comments

Comments

@alagalah
Copy link

alagalah commented Sep 8, 2016

If there is a mailing list to ask questions please feel free to redirect and close.

Is there an example of using LKL for socket zero-copy operations as per http://netdevconf.org/1.2/session.html?jerry-chu ?

Are there examples of using HIJACK with this?
@ghost
Copy link

ghost commented Sep 8, 2016

Mailing list is located at https://www.freelists.org/list/linux-kernel-library, but I don't mind continuing the discussion here.

zero-copy is something that @hkchu has been looking into, I'll let him answer that.

@hkchu
Copy link

hkchu commented Sep 10, 2016

Unfortunately we hit some road block so this is still WIP. Please stay tuned.

@alagalah
Copy link
Author

Can you share the issue? Best I have been able to come up with is single memcopy between containers.

1 similar comment
@alagalah
Copy link
Author

Can you share the issue? Best I have been able to come up with is single memcopy between containers.

@alagalah alagalah reopened this Sep 10, 2016
@hkchu
Copy link

hkchu commented Sep 10, 2016

On Sat, Sep 10, 2016 at 3:53 PM, Alagalah (Keith Burns) <
[email protected]> wrote:

Can you share the issue? Best I have been able to come up with is single
memcopy between containers.

It depends on what configuration you have and which copy you're referring
to.
E.g., one of the configurations we use involves 6 copy operations for each
byte transferred. Different copy operation poses different challenge...

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#223 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AR3_fdUD8X29L4U7_5ShUxiOcr3QkL6pks5qozT7gaJpZM4J4AI9
.

@linhua55 linhua55 mentioned this issue Sep 9, 2017
Open
phhusson pushed a commit to phhusson/linux that referenced this issue Feb 14, 2023
@mpe
powerpc/kexec_file: Fix division by zero in extra size estimation
7294194 
In kexec_extra_fdt_size_ppc64() there's logic to estimate how much
extra space will be needed in the device tree for some memory related
properties.

That logic uses the size of RAM divided by drmem_lmb_size() to do the
estimation. However drmem_lmb_size() can be zero if the machine has no
hotpluggable memory configured, which is the case when booting with qemu
and no maxmem=x parameter is passed (the default).

The division by zero is reported by UBSAN, and can also lead to an
overflow and a warning from kvmalloc, and kdump kernel loading fails:

  WARNING: CPU: 0 PID: 133 at mm/util.c:596 kvmalloc_node+0x15c/0x160
  Modules linked in:
  CPU: 0 PID: 133 Comm: kexec Not tainted 6.2.0-rc5-03455-g07358bd97810 lkl#223
  Hardware name: IBM pSeries (emulated by qemu) POWER9 (raw) 0x4e1200 0xf000005 of:SLOF,git-dd0dca pSeries
  NIP:  c00000000041ff4c LR: c00000000041fe58 CTR: 0000000000000000
  REGS: c0000000096ef750 TRAP: 0700   Not tainted  (6.2.0-rc5-03455-g07358bd97810)
  MSR:  800000000282b033 <SF,VEC,VSX,EE,FP,ME,IR,DR,RI,LE>  CR: 24248242  XER: 2004011e
  CFAR: c00000000041fed0 IRQMASK: 0
  ...
  NIP kvmalloc_node+0x15c/0x160
  LR  kvmalloc_node+0x68/0x160
  Call Trace:
    kvmalloc_node+0x68/0x160 (unreliable)
    of_kexec_alloc_and_setup_fdt+0xb8/0x7d0
    elf64_load+0x25c/0x4a0
    kexec_image_load_default+0x58/0x80
    sys_kexec_file_load+0x5c0/0x920
    system_call_exception+0x128/0x330
    system_call_vectored_common+0x15c/0x2ec

To fix it, skip the calculation if drmem_lmb_size() is zero.

Fixes: 2377c92 ("powerpc/kexec_file: fix FDT size estimation for kdump kernel")
Cc: [email protected] # v5.12+
Signed-off-by: Michael Ellerman <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@alagalah @hkchu