| Message ID | 20210415033925.1290401-2-dje@google.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | Add support for ipv6 host forwarding | expand |
Hi On Thu, Apr 15, 2021 at 7:41 AM Doug Evans <dje@google.com> wrote: > 5eraph (2): > disable_dns option > limit vnameserver_addr to port 53 > > Akihiro Suda (1): > libslirp.h: fix SlirpConfig v3 documentation > > Doug Evans (11): > Add ipv6 host forward support > tcpx_listen: Pass sizeof(addr) to memset > Reject host forwarding to ipv6 "addr-any" > Add /build/ to .gitignore > New utility slirp_ether_ntoa > m_cleanup_list: make static > New API routine slirp_neighbor_info > Move DEBUG_CALL("if_start") to DEBUG_VERBOSE_CALL > tcpx_listen: tcp_newtcpcb doesn't fail > slirp_add_host*fwd: Ensure all error paths set errno > Perform lazy guest address resolution for IPv6 > > Dr. David Alan Gilbert (1): > ip_stripoptions use memmove > > Giuseppe Scrivano (1): > socket: consume empty packets > > Hafiz Abid Qadeer (1): > Fix a typo that can cause slow socket response on Windows. > > Jindrich Novy (4): > Fix possible infinite loops and use-after-free > Use secure string copy to avoid overflow > Be sure to initialize sockaddr structure > Check lseek() for failure > > Marc-André Lureau (26): > Merge branch 'master' into 'master' > Merge branch 'fix-slirpconfig-3-doc' into 'master' > Fix use-afte-free in ip_reass() (CVE-2020-1983) > Update CHANGELOG > Merge branch 'cve-2020-1983' into 'master' > Release v4.3.0 > Merge branch 'release-v4.3.0' into 'master' > changelog: post-release > util: do not silently truncate > Merge branch 'slirp-fmt-truncate' into 'master' > Release v4.3.1 > Merge branch 'release-v4.3.1' into 'master' > changelog: post-release > .gitlab-ci: add a Coverity stage > Merge branch 'coverity' into 'master' > Merge branch 'ios-support' into 'master' > Merge branch 'master' into 'master' > Remove the QEMU-special make build-system > Merge branch 'qemu' into 'master' > Release v4.4.0 > Merge branch '4.4.0-release' into 'master' > changelog: post-release > Remove some needless (void)casts > Fix unused variables > Merge branch 'gitignore-build' into 'master' > Merge branch 'macos-deployment-target' into 'master' > > Nathaniel Wesley Filardo (1): > fork_exec_child_setup: improve signal handling > > Paolo Bonzini (2): > meson: remove meson-dist script > meson: support compiling as subproject > > Philippe Mathieu-Daudé (3): > Fix win32 builds by using the SLIRP_PACKED definition > Fix constness warnings > Remove unnecessary break > > Prasad J Pandit (1): > slirp: check pkt_len before reading protocol header > > Ralf Haferkamp (2): > Drop bogus IPv6 messages > Fix MTU check > > Samuel Thibault (45): > Merge branch 'ip6_payload_len' into 'master' > Merge branch 'lp1878043' into 'master' > udp, udp6, icmp: handle TTL value > icmp, icmp6: Add icmp_forward_error and icmp6_forward_error > udp, udp6, icmp, icmp6: Enable forwarding errors on Linux > TCPIPHDR_DELTA: Fix potential negative value > sosendoob: better document what urgc is used for > Merge branch 'G_GNUC_PRINTF' into 'master' > Merge branch 'CVE-2020-29129' into 'master' > Merge branch 'ttl' into 'master' > Merge branch 'errors' into 'master' > Merge branch 'consume-empty-packet' into 'master' > Merge branch 'void' into 'master' > Merge branch 'master' into 'master' > Merge branch 'unused' into 'master' > Merge branch 'socket_delay' into 'master' > tcp_subr: simplify code > Merge branch 'ipv6-host-fwd-9-patch' into 'master' > Document the slirp API > Complete timeout documentation > Merge branch 'memset-sizeof' into 'master' > Merge branch 'reject-ipv6-addr-any' into 'master' > ip6_output: fix memory leak on fast-send > Merge branch 'ndp-leak' into 'master' > Merge branch 'memory_leaks' into 'master' > TODO for generalizing the hostfwd calls > socket.h: add missing sbuf.h inclusion > Expose udpx_listen and tcpx_listen as taking sockaddr > Disable polling for PRI on MacOS > Merge branch 'macos-pri' into 'master' > Merge branch 'x_listen' into 'master' > udpx/tcpx_listen: Add missing const qualifier > sockaddr_*: add missing const qualifiers > Merge branch 'm-cleanup-list-prototype' into 'master' > Merge branch 'neighbor-info' into 'master' > udpx/tcpx_listen: Use struct sockaddr * types > Add ipv4/ipv6-agnostic host forwarding functions > hostfwd: Add SLIRP_HOSTFWD_V6ONLY flag > Merge branch 'hostxfwd' into 'master' > Merge branch 'verbose-if-start' into 'master' > Remove slirp_add/remove_ipv6_hostfwd > Merge branch 'listen-errno' into 'master' > Merge branch 'newtcpcb-no-fail' into 'master' > Merge branch 'listen_v6only' into 'master' > Merge branch 'lazy-ipv6-resolution' into 'master' > > Stefan Weil (1): > Add G_GNUC_PRINTF to local function slirp_vsnprintf > > WaluigiWare64 (1): > Set macOS deployment target to macOS 10.4 Without a macOS deployment > target, the resulting library does not work on macOS versions lower than it > was currently built on. For example, if libslirp was built on macOS 10.15, > it would not work on macOS 10.14. > > jeremy marchand (4): > m_free: remove the M_EXT flag after freeing the mbuf extended buffer > refactor m_cleanup as requested in slirp/libslirp!68 > m_cleanup: fix memory leaks > m_cleanup: set qh_link and qh_rlink to the list head > > osy (1): > Add DNS resolving for iOS > > Signed-off-by: Doug Evans <dje@google.com> > --- > > Changes from v5: > > 1/4 slirp: Advance libslirp submodule to current master > NOTE TO REVIEWERS: It may be a better use of everyone's time if a > maintainer takes on advancing QEMU's libslirp to libslirp's master. > Beyond that, I really don't know what to do except submit this patch as > is currently provided. > > Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> It can do, but it should rather be a diff of the commits that are new, those that were not in the stable branch. > slirp | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/slirp b/slirp > index 8f43a99191..4e6444e842 160000 > --- a/slirp > +++ b/slirp > @@ -1 +1 @@ > -Subproject commit 8f43a99191afb47ca3f3c6972f6306209f367ece > +Subproject commit 4e6444e842695a6bfb00e15a8d0edfceb5c4628d > -- > 2.31.1.295.g9ea45b61b8-goog > > >
On Fri, May 7, 2021 at 8:23 AM Marc-André Lureau <marcandre.lureau@gmail.com> wrote: > Hi > > [...] >> >> >> Changes from v5: >> >> 1/4 slirp: Advance libslirp submodule to current master >> NOTE TO REVIEWERS: It may be a better use of everyone's time if a >> maintainer takes on advancing QEMU's libslirp to libslirp's master. >> Beyond that, I really don't know what to do except submit this patch as >> is currently provided. >> >> > Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> > > It can do, but it should rather be a diff of the commits that are new, > those that were not in the stable branch. > Can you elaborate? E.g., Should a new libslirp release be made first, and then update qemu-master to that new release?
Ping. On Fri, May 7, 2021 at 8:46 AM Doug Evans <dje@google.com> wrote: > On Fri, May 7, 2021 at 8:23 AM Marc-André Lureau < > marcandre.lureau@gmail.com> wrote: > >> Hi >> >> [...] >>> >>> >>> Changes from v5: >>> >>> 1/4 slirp: Advance libslirp submodule to current master >>> NOTE TO REVIEWERS: It may be a better use of everyone's time if a >>> maintainer takes on advancing QEMU's libslirp to libslirp's master. >>> Beyond that, I really don't know what to do except submit this patch as >>> is currently provided. >>> >>> >> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> >> >> It can do, but it should rather be a diff of the commits that are new, >> those that were not in the stable branch. >> > > > Can you elaborate? > E.g., Should a new libslirp release be made first, and then update > qemu-master to that new release? > Hey Marc-André and Samuel, What's the next step here (if any)? Would it be preferable to make a new libslirp release instead? [I also don't understand the comment "it should rather be a diff of the commits that are new, ...". I haven't seen this request before (apologies if I missed it), but more importantly isn't it trivial to generate such diffs, without adding them to the email? I could be missing something of course.] At some point a new libslirp release needs to be made, and at some point QEMU needs to be updated to use it. Seems like now is a good time, but maybe there are reasons to prefer not doing so now. I can imagine QEMU wanting to always use a stable branch of libslirp, so I just want to be absolutely clear that switching QEMU to use libslirp's master branch is desired, and if anything more is needed from me. I'm happy with whatever you decide, but I don't want to waste your time guessing and then having to iterate when I guess wrong.
Hi On Wed, May 12, 2021 at 8:43 PM Doug Evans <dje@google.com> wrote: > Ping. > > On Fri, May 7, 2021 at 8:46 AM Doug Evans <dje@google.com> wrote: > >> On Fri, May 7, 2021 at 8:23 AM Marc-André Lureau < >> marcandre.lureau@gmail.com> wrote: >> >>> Hi >>> >>> [...] >>>> >>>> >>>> Changes from v5: >>>> >>>> 1/4 slirp: Advance libslirp submodule to current master >>>> NOTE TO REVIEWERS: It may be a better use of everyone's time if a >>>> maintainer takes on advancing QEMU's libslirp to libslirp's master. >>>> Beyond that, I really don't know what to do except submit this patch as >>>> is currently provided. >>>> >>>> >>> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> >>> >>> It can do, but it should rather be a diff of the commits that are new, >>> those that were not in the stable branch. >>> >> >> >> Can you elaborate? >> E.g., Should a new libslirp release be made first, and then update >> qemu-master to that new release? >> > > > Hey Marc-André and Samuel, > What's the next step here (if any)? > There isn't much point in bumping qemu dependency if it doesn't make use of the new API. Thus first step is to get the rest of the series reviewed/approved imho. Would it be preferable to make a new libslirp release instead? > yes, as I said in some other path review, we would need a libslirp release AND compatiblity with older slirp releases. [I also don't understand the comment "it should rather be a diff of the > commits that are new, ...". > I haven't seen this request before (apologies if I missed it), but more > importantly > isn't it trivial to generate such diffs, without adding them to the email? > I could be missing something of course.] > > At some point a new libslirp release needs to be made, and at some point > QEMU needs to be updated to use it. > Seems like now is a good time, but maybe there are reasons to prefer not > doing so now. > I can imagine QEMU wanting to always use a stable branch of libslirp, > so I just want to be absolutely clear that switching QEMU to use > libslirp's master branch is desired, > and if anything more is needed from me. > I'm happy with whatever you decide, but I don't want to waste your time > guessing and then having to iterate when I guess wrong. > You need to rework the series to be compatible with current libslirp. That may be one of the reason why you don't get more reviews, Jason, the maintainer, may expect you to do that based on feedback received earlier. thanks
On Wed, May 12, 2021 at 10:18 AM Marc-André Lureau < marcandre.lureau@gmail.com> wrote: > Hi > > On Wed, May 12, 2021 at 8:43 PM Doug Evans <dje@google.com> wrote: > >> Ping. >> >> On Fri, May 7, 2021 at 8:46 AM Doug Evans <dje@google.com> wrote: >> >>> On Fri, May 7, 2021 at 8:23 AM Marc-André Lureau < >>> marcandre.lureau@gmail.com> wrote: >>> >>>> Hi >>>> >>>> [...] >>>>> >>>>> >>>>> Changes from v5: >>>>> >>>>> 1/4 slirp: Advance libslirp submodule to current master >>>>> NOTE TO REVIEWERS: It may be a better use of everyone's time if a >>>>> maintainer takes on advancing QEMU's libslirp to libslirp's master. >>>>> Beyond that, I really don't know what to do except submit this patch as >>>>> is currently provided. >>>>> >>>>> >>>> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> >>>> >>>> It can do, but it should rather be a diff of the commits that are new, >>>> those that were not in the stable branch. >>>> >>> >>> >>> Can you elaborate? >>> E.g., Should a new libslirp release be made first, and then update >>> qemu-master to that new release? >>> >> >> >> Hey Marc-André and Samuel, >> What's the next step here (if any)? >> > > There isn't much point in bumping qemu dependency if it doesn't make use > of the new API. Thus first step is to get the rest of the series > reviewed/approved imho. > I'm not suggesting the dependency be bumped prior to the entire series being approved. By "next step" I meant whether this patch (1/4) in the series is done. The question I asked: "Should a new libslirp release be made and then have qemu-master use that (*1)?" was outstanding as it wasn't(isn't) clear whether the plan was indeed to first make a new libslirp release (even taking into account the comments on patch 3/4). (*1): When using QEMU-provided libslirp. When not using QEMU-provided slirp, of course, be compatible with the libslirp that is being used. Thanks for bringing that to my attention btw, it's easy to forget given that QEMU provides its own copy of libslirp and I have completely left that out of v1 to v5. > Would it be preferable to make a new libslirp release instead? >> > > yes, as I said in some other path review, we would need a libslirp release > AND compatiblity with older slirp releases. > Indeed! I was, perhaps errantly, treating them as orthogonal discussions. [On the theory that: - if we resolve all issues for each piece of the current iteration then that will reduce the number of iterations, and I'm not sure patch 1/4 is complete and what happens next for it (given that a separate repo is involved) - discussions of making a new libslirp release can proceed independent of updating patch 3/4 That was the theory anyway.] > [I also don't understand the comment "it should rather be a diff of the >> commits that are new, ...". >> I haven't seen this request before (apologies if I missed it), but more >> importantly >> isn't it trivial to generate such diffs, without adding them to the email? >> I could be missing something of course.] >> >> At some point a new libslirp release needs to be made, and at some point >> QEMU needs to be updated to use it. >> Seems like now is a good time, but maybe there are reasons to prefer not >> doing so now. >> I can imagine QEMU wanting to always use a stable branch of libslirp, >> so I just want to be absolutely clear that switching QEMU to use >> libslirp's master branch is desired, >> and if anything more is needed from me. >> I'm happy with whatever you decide, but I don't want to waste your time >> guessing and then having to iterate when I guess wrong. >> > > You need to rework the series to be compatible with current libslirp. That > may be one of the reason why you don't get more reviews, Jason, the > maintainer, may expect you to do that based on feedback received earlier. > I'm indeed updating v7 in this series to be compatible with current libslirp, but let's get the issue of a new libslirp release resolved too. Btw, can you elaborate on "should rather be a diff of the commits that are new"? Up until now I've been told to provide "git shortlog old..new" output. The patch itself is just a one-liner to update the subproject sha1.
Hi On Wed, May 12, 2021 at 11:51 PM Doug Evans <dje@google.com> wrote: > > Btw, can you elaborate on "should rather be a diff of the commits that are > new"? > Up until now I've been told to provide "git shortlog old..new" output. > The patch itself is just a one-liner to update the subproject sha1. > git modules used by qemu are usually tracking the master branch, so a shortlog works fine and shows the additional comments. But when it's switching branches, the shortlog doesn't provide the diff between the branches, that is the commits that were not already in the branch being tracked. In my last update ( https://patchew.org/QEMU/20210125073427.3970606-1-marcandre.lureau@redhat.com/20210125073427.3970606-2-marcandre.lureau@redhat.com/), I used a tool called git-cherry-diff, but there might be git log arguments to do that I ignore.
diff --git a/slirp b/slirp index 8f43a99191..4e6444e842 160000 --- a/slirp +++ b/slirp @@ -1 +1 @@ -Subproject commit 8f43a99191afb47ca3f3c6972f6306209f367ece +Subproject commit 4e6444e842695a6bfb00e15a8d0edfceb5c4628d
5eraph (2): disable_dns option limit vnameserver_addr to port 53 Akihiro Suda (1): libslirp.h: fix SlirpConfig v3 documentation Doug Evans (11): Add ipv6 host forward support tcpx_listen: Pass sizeof(addr) to memset Reject host forwarding to ipv6 "addr-any" Add /build/ to .gitignore New utility slirp_ether_ntoa m_cleanup_list: make static New API routine slirp_neighbor_info Move DEBUG_CALL("if_start") to DEBUG_VERBOSE_CALL tcpx_listen: tcp_newtcpcb doesn't fail slirp_add_host*fwd: Ensure all error paths set errno Perform lazy guest address resolution for IPv6 Dr. David Alan Gilbert (1): ip_stripoptions use memmove Giuseppe Scrivano (1): socket: consume empty packets Hafiz Abid Qadeer (1): Fix a typo that can cause slow socket response on Windows. Jindrich Novy (4): Fix possible infinite loops and use-after-free Use secure string copy to avoid overflow Be sure to initialize sockaddr structure Check lseek() for failure Marc-André Lureau (26): Merge branch 'master' into 'master' Merge branch 'fix-slirpconfig-3-doc' into 'master' Fix use-afte-free in ip_reass() (CVE-2020-1983) Update CHANGELOG Merge branch 'cve-2020-1983' into 'master' Release v4.3.0 Merge branch 'release-v4.3.0' into 'master' changelog: post-release util: do not silently truncate Merge branch 'slirp-fmt-truncate' into 'master' Release v4.3.1 Merge branch 'release-v4.3.1' into 'master' changelog: post-release .gitlab-ci: add a Coverity stage Merge branch 'coverity' into 'master' Merge branch 'ios-support' into 'master' Merge branch 'master' into 'master' Remove the QEMU-special make build-system Merge branch 'qemu' into 'master' Release v4.4.0 Merge branch '4.4.0-release' into 'master' changelog: post-release Remove some needless (void)casts Fix unused variables Merge branch 'gitignore-build' into 'master' Merge branch 'macos-deployment-target' into 'master' Nathaniel Wesley Filardo (1): fork_exec_child_setup: improve signal handling Paolo Bonzini (2): meson: remove meson-dist script meson: support compiling as subproject Philippe Mathieu-Daudé (3): Fix win32 builds by using the SLIRP_PACKED definition Fix constness warnings Remove unnecessary break Prasad J Pandit (1): slirp: check pkt_len before reading protocol header Ralf Haferkamp (2): Drop bogus IPv6 messages Fix MTU check Samuel Thibault (45): Merge branch 'ip6_payload_len' into 'master' Merge branch 'lp1878043' into 'master' udp, udp6, icmp: handle TTL value icmp, icmp6: Add icmp_forward_error and icmp6_forward_error udp, udp6, icmp, icmp6: Enable forwarding errors on Linux TCPIPHDR_DELTA: Fix potential negative value sosendoob: better document what urgc is used for Merge branch 'G_GNUC_PRINTF' into 'master' Merge branch 'CVE-2020-29129' into 'master' Merge branch 'ttl' into 'master' Merge branch 'errors' into 'master' Merge branch 'consume-empty-packet' into 'master' Merge branch 'void' into 'master' Merge branch 'master' into 'master' Merge branch 'unused' into 'master' Merge branch 'socket_delay' into 'master' tcp_subr: simplify code Merge branch 'ipv6-host-fwd-9-patch' into 'master' Document the slirp API Complete timeout documentation Merge branch 'memset-sizeof' into 'master' Merge branch 'reject-ipv6-addr-any' into 'master' ip6_output: fix memory leak on fast-send Merge branch 'ndp-leak' into 'master' Merge branch 'memory_leaks' into 'master' TODO for generalizing the hostfwd calls socket.h: add missing sbuf.h inclusion Expose udpx_listen and tcpx_listen as taking sockaddr Disable polling for PRI on MacOS Merge branch 'macos-pri' into 'master' Merge branch 'x_listen' into 'master' udpx/tcpx_listen: Add missing const qualifier sockaddr_*: add missing const qualifiers Merge branch 'm-cleanup-list-prototype' into 'master' Merge branch 'neighbor-info' into 'master' udpx/tcpx_listen: Use struct sockaddr * types Add ipv4/ipv6-agnostic host forwarding functions hostfwd: Add SLIRP_HOSTFWD_V6ONLY flag Merge branch 'hostxfwd' into 'master' Merge branch 'verbose-if-start' into 'master' Remove slirp_add/remove_ipv6_hostfwd Merge branch 'listen-errno' into 'master' Merge branch 'newtcpcb-no-fail' into 'master' Merge branch 'listen_v6only' into 'master' Merge branch 'lazy-ipv6-resolution' into 'master' Stefan Weil (1): Add G_GNUC_PRINTF to local function slirp_vsnprintf WaluigiWare64 (1): Set macOS deployment target to macOS 10.4 Without a macOS deployment target, the resulting library does not work on macOS versions lower than it was currently built on. For example, if libslirp was built on macOS 10.15, it would not work on macOS 10.14. jeremy marchand (4): m_free: remove the M_EXT flag after freeing the mbuf extended buffer refactor m_cleanup as requested in slirp/libslirp!68 m_cleanup: fix memory leaks m_cleanup: set qh_link and qh_rlink to the list head osy (1): Add DNS resolving for iOS Signed-off-by: Doug Evans <dje@google.com> --- Changes from v5: 1/4 slirp: Advance libslirp submodule to current master NOTE TO REVIEWERS: It may be a better use of everyone's time if a maintainer takes on advancing QEMU's libslirp to libslirp's master. Beyond that, I really don't know what to do except submit this patch as is currently provided. slirp | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)