Re: CVS commit: src/sys/net/npf
Le 07/04/2018 à 23:28, Christos Zoulas a écrit : In article <20180407090627.20058f...@cvs.netbsd.org>, Maxime Villard wrote: -=-=-=-=-=- Module Name:src Committed By: maxv Date: Sat Apr 7 09:06:27 UTC 2018 Modified Files: src/sys/net/npf: npf_inet.c Log Message: Rewrite npf_fetch_tcpopts: * Instead of doing several nbuf_advance/nbuf_ensure_contig and playing with gotos, fetch the TCP options only once, and iterate over the (safe) area. The code is similar to tcp_dooptions. * When handling TCPOPT_MAXSEG and TCPOPT_WINDOW, ensure the length is the one we're expecting. If it isn't, then skip the option. This wasn't done before, and not doing it allowed a packet to bypass the max-mss clamping procedure. Discussed on tech-net@. This seems to break cvs -d cvs.netbsd.org:/cvsroot diff, with write via ssh returning ENETUNREACH. christos My bad (again). Seems like the TCP code is getting me confused all the time.
Re: CVS commit: src/sys/net/npf
In article <20180407090627.20058f...@cvs.netbsd.org>, Maxime Villard wrote: >-=-=-=-=-=- > >Module Name: src >Committed By: maxv >Date: Sat Apr 7 09:06:27 UTC 2018 > >Modified Files: > src/sys/net/npf: npf_inet.c > >Log Message: >Rewrite npf_fetch_tcpopts: > > * Instead of doing several nbuf_advance/nbuf_ensure_contig and > playing with gotos, fetch the TCP options only once, and iterate over > the (safe) area. The code is similar to tcp_dooptions. > > * When handling TCPOPT_MAXSEG and TCPOPT_WINDOW, ensure the length is > the one we're expecting. If it isn't, then skip the option. This > wasn't done before, and not doing it allowed a packet to bypass the > max-mss clamping procedure. Discussed on tech-net@. > This seems to break cvs -d cvs.netbsd.org:/cvsroot diff, with write via ssh returning ENETUNREACH. christos
Re: CVS commit: src/sys/miscfs/procfs
On Apr 7, 9:54pm, hann...@eis.cs.tu-bs.de ("J. Hannken-Illjes") wrote:
-- Subject: Re: CVS commit: src/sys/miscfs/procfs
| Already requested with ticket #702.
Thanks!
christos
Re: CVS commit: src/sys/miscfs/procfs
> On 7. Apr 2018, at 21:27, Christos Zoulas wrote: > > In article <20180407134242.bceb9f...@cvs.netbsd.org>, > Juergen Hannken-Illjes wrote: >> -=-=-=-=-=- >> >> Module Name: src >> Committed By:hannken >> Date:Sat Apr 7 13:42:42 UTC 2018 >> >> Modified Files: >> src/sys/miscfs/procfs: procfs_vnops.c >> >> Log Message: >> Lock the target cwdi and take an additional reference to the >> vnode we are interested in to prevent it from disappearing >> before getcwd_common(). >> >> Should fix PR kern/53096 (netbsd-8 crash on heavy disk I/O) > > Pullup? Already requested with ticket #702. -- J. Hannken-Illjes - hann...@eis.cs.tu-bs.de - TU Braunschweig (Germany)
Re: CVS commit: src/sys/miscfs/procfs
In article <20180407134242.bceb9f...@cvs.netbsd.org>, Juergen Hannken-Illjes wrote: >-=-=-=-=-=- > >Module Name: src >Committed By: hannken >Date: Sat Apr 7 13:42:42 UTC 2018 > >Modified Files: > src/sys/miscfs/procfs: procfs_vnops.c > >Log Message: >Lock the target cwdi and take an additional reference to the >vnode we are interested in to prevent it from disappearing >before getcwd_common(). > >Should fix PR kern/53096 (netbsd-8 crash on heavy disk I/O) Pullup? christos
Re: CVS commit: xsrc/external/mit/xorg-server/dist/hw/xfree86/drivers/modesetting
On Apr 8, 3:28am, r...@nerv.org (Ryo Shimizu) wrote: -- Subject: Re: CVS commit: xsrc/external/mit/xorg-server/dist/hw/xfree86/dri | | Sorry for the late reply. | I got it. I'll revert and apply Joerg's patch. thanks. | | BTW, I have a question. uint64 is defined as unsigned long long on NetBSD/aarch64. | but on other OS (Linux,FreeBSD), it seems that uint64 is defined as unsigned long. | (grep 'AARCH64.*INT64_TYPE' /usr/src/external/bsd/llvm/dist/clang/test/Preprocessor/init.c) | | Linux long | FreeBSDlong | NetBSD long long | OpenBSDlong long | DARWIN long long | | Which type should be better? Please don't revert it. It is just fine. We'll change ours to be long too. christos
Re: CVS commit: xsrc/external/mit/xorg-server/dist/hw/xfree86/drivers/modesetting
>On Wed, Apr 04, 2018 at 10:59:18AM +1000, matthew green wrote: >> Christos Zoulas writes: >> > In article <21473.1522789...@splode.eterna.com.au>, >> > matthew green wrote: >> > >"Ryo Shimizu" writes: >> > >> Module Name:xsrc >> > >> Committed By: ryo >> > >> Date: Tue Apr 3 19:53:57 UTC 2018 >> > >> >> > >> Modified Files: >> > >> >> > >> xsrc/external/mit/xorg-server/dist/hw/xfree86/drivers/modesetting: >> > >> driver.h present.c vblank.c >> > >> >> > >> Log Message: >> > >> Fix compile error on evbarm-aarch64. (incompatible pointer types >> > >initializing 'present_get_ust_msc_ptr') >> > > >> > >sounds like this is a different error. why isn't CARD64 a >> > >uint64_t or similarly compatible for arm64? this sounds >> > >like a problem with the environemnt, and not something to >> > >work around here. >> > > >> > >is _XSERVER64 not defined, or whatever it is? >> > > >> > >thanks. >> > >> > Yes, the problem is the compiler but this is an X bug. >> > >> > uint64_t is defined to be unsigned long long and CARD64 is unsigned long. >> > They are simply not exchangeable and the compiler has the right to define >> > things this way. Well, I've complained to joerg to normalize it and make >> > it like all other _LP64 platforms, but there is an embargo committing to >> > llvm. >> >> can we have a hack in the Makefile for arm64 and not >> touch the sources (for everyone)? > >We can just make the warning non-fatal for now. Like the attached patch. > >Joerg Sorry for the late reply. I got it. I'll revert and apply Joerg's patch. thanks. BTW, I have a question. uint64 is defined as unsigned long long on NetBSD/aarch64. but on other OS (Linux,FreeBSD), it seems that uint64 is defined as unsigned long. (grep 'AARCH64.*INT64_TYPE' /usr/src/external/bsd/llvm/dist/clang/test/Preprocessor/init.c) Linuxlong FreeBSD long NetBSD long long OpenBSD long long DARWIN long long Which type should be better? -- ryo shimizu
