Re: remove pf_check_congestion()
On Thu, Mar 06, 2014 at 23:56, Lawrence Teo wrote: > pf_check_congestion() simply checks if ifq->ifq_congestion is non-zero, > and returns 1 or 0 accordingly. It is only called by pf_test_rule(). > > Since what pf_check_congestion() does is very trivial and pf_test_rule() > is its only user, would it make sense to remove it and let > pf_test_rule() check ifq->ifq_congestion directly to save a function > call? I think function calls are not so very expensive, and it makes it easier to read imo.
remove pf_check_congestion()
pf_check_congestion() simply checks if ifq->ifq_congestion is non-zero, and returns 1 or 0 accordingly. It is only called by pf_test_rule(). Since what pf_check_congestion() does is very trivial and pf_test_rule() is its only user, would it make sense to remove it and let pf_test_rule() check ifq->ifq_congestion directly to save a function call? Index: pf.c === RCS file: /cvs/src/sys/net/pf.c,v retrieving revision 1.868 diff -u -p -r1.868 pf.c --- pf.c25 Jan 2014 03:39:00 - 1.868 +++ pf.c18 Feb 2014 17:57:42 - @@ -230,7 +230,6 @@ int pf_compare_state_keys(struct pf_s struct pf_state*pf_find_state(struct pfi_kif *, struct pf_state_key_cmp *, u_int, struct mbuf *); int pf_src_connlimit(struct pf_state **); -int pf_check_congestion(struct ifqueue *); int pf_match_rcvif(struct mbuf *, struct pf_rule *); voidpf_step_into_anchor(int *, struct pf_ruleset **, struct pf_rule **, struct pf_rule **); @@ -3159,7 +3158,7 @@ pf_test_rule(struct pf_pdesc *pd, struct ifq = &ip6intrq; #endif - if (pd->dir == PF_IN && pf_check_congestion(ifq)) { + if (pd->dir == PF_IN && ifq->ifq_congestion) { REASON_SET(&reason, PFRES_CONGEST); return (PF_DROP); } @@ -6745,15 +6744,6 @@ done: } return (action); -} - -int -pf_check_congestion(struct ifqueue *ifq) -{ - if (ifq->ifq_congestion) - return (1); - else - return (0); } void
Re: make mandoc -Tlocale the default
Hi Ted, Ted Unangst wrote on Thu, Mar 06, 2014 at 04:46:50PM -0500: > Seems reasonable to me. > I went the man.conf route because it's easier for users to revert, Oh, if somebody really insists in setting LC_CTYPE but wants to see manuals in US-ASCII anyway (huh?), adding -Tascii to mandoc in man.conf(5) will work just fine and isn't hard to do. > but I think there's enough time to shake out the fixes if needed. That's what i think as well. Ingo
Re: make mandoc -Tlocale the default
On Thu, Mar 06, 2014 at 21:36, Ingo Schwarze wrote: > Hi, > > having fixed the accent issues with mandoc -Tutf8, i have checked > the base system for build system issues with switching the default, > the resulting fixes are included in the following patch. > > Anybody wants to check with ports before commit, such that we can do > any necessary cleanup beforehands, as opposed to mopping up > possible fallout afterwards? Seems reasonable to me. I went the man.conf route because it's easier for users to revert, but I think there's enough time to shake out the fixes if needed.
make mandoc -Tlocale the default
Hi, having fixed the accent issues with mandoc -Tutf8, i have checked the base system for build system issues with switching the default, the resulting fixes are included in the following patch. Anybody wants to check with ports before commit, such that we can do any necessary cleanup beforehands, as opposed to mopping up possible fallout afterwards? Any other feedback is welcome as well, of course. Note that unless you have set LC_CTYPE in your shell, this will not change the game for you, or it would be a bug. Yours, Ingo Index: usr.bin/mandoc/main.c === RCS file: /cvs/src/usr.bin/mandoc/main.c,v retrieving revision 1.86 diff -u -p -r1.86 main.c --- usr.bin/mandoc/main.c 6 Jan 2014 00:53:14 - 1.86 +++ usr.bin/mandoc/main.c 6 Mar 2014 20:28:01 - @@ -98,7 +98,7 @@ main(int argc, char *argv[]) memset(&curp, 0, sizeof(struct curparse)); type = MPARSE_AUTO; - curp.outtype = OUTT_ASCII; + curp.outtype = OUTT_LOCALE; curp.wlevel = MANDOCLEVEL_FATAL; defos = NULL; Index: usr.bin/mandoc/mandoc.1 === RCS file: /cvs/src/usr.bin/mandoc/mandoc.1,v retrieving revision 1.56 diff -u -p -r1.56 mandoc.1 --- usr.bin/mandoc/mandoc.1 13 Jul 2013 19:27:46 - 1.56 +++ usr.bin/mandoc/mandoc.1 6 Mar 2014 20:28:07 - @@ -47,7 +47,7 @@ or text from stdin, implying .Fl m Ns Cm andoc , and produces -.Fl T Ns Cm ascii +.Fl T Ns Cm locale output. .Pp The arguments are as follows: @@ -76,7 +76,7 @@ See .Sx Output Formats for available formats. Defaults to -.Fl T Ns Cm ascii . +.Fl T Ns Cm locale . .It Fl V Print version and exit. .It Fl W Ns Ar level @@ -173,7 +173,6 @@ arguments, which correspond to output mo .Bl -tag -width "-Tlocale" .It Fl T Ns Cm ascii Produce 7-bit ASCII output. -This is the default. See .Sx ASCII Output . .It Fl T Ns Cm html @@ -186,6 +185,7 @@ Implies .Fl W Ns Cm warning . .It Fl T Ns Cm locale Encode output using the current locale. +This is the default. See .Sx Locale Output . .It Fl T Ns Cm man @@ -218,8 +218,8 @@ If multiple input files are specified, t corresponding filter in-order. .Ss ASCII Output Output produced by -.Fl T Ns Cm ascii , -which is the default, is rendered in standard 7-bit ASCII documented in +.Fl T Ns Cm ascii +is rendered in standard 7-bit ASCII documented in .Xr ascii 7 . .Pp Font styles are applied by using back-spaced encoding such that an @@ -335,6 +335,8 @@ relative URI. .Ss Locale Output Locale-depending output encoding is triggered with .Fl T Ns Cm locale . +This is the default. +.Pp This option is not available on all systems: systems without locale support, or those whose internal representation is not natively UCS-4, will fall back to Index: sbin/disklabel/Makefile === RCS file: /cvs/src/sbin/disklabel/Makefile,v retrieving revision 1.54 diff -u -p -r1.54 Makefile --- sbin/disklabel/Makefile 31 Oct 2013 22:37:17 - 1.54 +++ sbin/disklabel/Makefile 6 Mar 2014 20:28:07 - @@ -17,7 +17,7 @@ manual.c: echo '};'; echo 'const int manpage_sz = sizeof(manpage);') > manual.c .else disklabel.cat8:disklabel.8 - mandoc ${.ALLSRC} > ${.TARGET} + mandoc -Tascii ${.ALLSRC} > ${.TARGET} manual.c: disklabel.cat8 (echo 'const unsigned char manpage[] = {'; \ Index: sbin/fdisk/Makefile === RCS file: /cvs/src/sbin/fdisk/Makefile,v retrieving revision 1.39 diff -u -p -r1.39 Makefile --- sbin/fdisk/Makefile 31 Oct 2013 22:37:17 - 1.39 +++ sbin/fdisk/Makefile 6 Mar 2014 20:28:07 - @@ -40,7 +40,7 @@ manual.c: echo '};'; echo 'const int manpage_sz = sizeof(manpage);') > manual.c .else fdisk.cat8:fdisk.8 - mandoc ${.ALLSRC} > ${.TARGET} + mandoc -Tascii ${.ALLSRC} > ${.TARGET} manual.c: fdisk.cat8 (echo 'const unsigned char manpage[] = {'; \ Index: regress/usr.bin/mandoc/roff/de/Makefile === RCS file: /cvs/src/regress/usr.bin/mandoc/roff/de/Makefile,v retrieving revision 1.1 diff -u -p -r1.1 Makefile --- regress/usr.bin/mandoc/roff/de/Makefile 2 Jun 2012 23:18:31 - 1.1 +++ regress/usr.bin/mandoc/roff/de/Makefile 6 Mar 2014 20:28:07 - @@ -23,10 +23,10 @@ ascii-diff-opt: TH.mandoc_ascii_opt Dd.m ${DIFF} ${.CURDIR}/Dd.out_ascii_opt Dd.mandoc_ascii_opt TH.mandoc_ascii_opt: TH.in - ${MANDOC} -man ${.ALLSRC} > ${.TARGET} + ${MANDOC} -Tascii -man ${.ALLSRC} > ${.TARGET} Dd.mandoc_ascii_opt: Dd.in - ${MANDOC} -mdoc ${.ALLSRC} > ${.TARGET} + ${MANDOC} -Tascii -mdoc ${.ALLSRC} > ${.TARGET} ascii-clean-opt: rm -f TH.mandoc_ascii_opt Dd.mandoc_ascii_opt
Re: fix seekdir(3)
Hi, back in November 2013, following an idea by guenther@, i cooked up another optimization for seekdir(3), then failed to send out the patch. So here it is. Philip Guenther wrote on Tue, Nov 05, 2013 at 07:57:43PM -0800: > On Wed, 6 Nov 2013, Ingo Schwarze wrote: >> * Worst case: >>opendir; telldir >>then 100.000 times (seekdir; readdir) at that position >> = The entry asked for is the very first entry in the buffer, >> which cannot be found, because each dirent only contains >> the address of the *following* dirent, so each readdir >> triggers getdents anyway, but we still search the whole >> buffer each time. > While caching the offset of the start of the buffer is possible, it's > not obvious that that case will happen often enough to be worth it. > > Hmm, rewinddir() will _always_ be this worst case. Perhaps rewinddir() > should not call seekdir() and just be the two assignments with lseek(), > skipping the scan of the current buffer. That wouldn't be very useful because after lseek(2), getdents(2) is required, which is *much* more expensive than searching the buffer. > It would be assisted by the start-o-buffer cache though. Exactly. Right now, each rewinddir(3) seeks the whole buffer in vain, wasting 5 microseconds on that, then proceeds to the extremely expensive getdents(2) anyway, wasting another 100 microseconds. The patch to cache the cookie of the first directory entry in addition to all the other entries that we already cache is relatively simple, see below. With this patch, rewinddir(3) changes from always being the worst case to often being the best case (now always the best case for directories with less than about 500 entries, or for rewinding before reading less than about 500 entries), no other case becomes any worse, and some other, less important edge cases improve, too. What the patch does is: * Let opendir(3) save the cookie of the first entry of the directory. * Let seekdir(3) use that saved cookie to move the internal pointers to that entry when asked to do so, for example on rewinddir(3). * Let seekdir(3) update that saved cookie when the buffer is exhausted and when consequently, an lseek(2) had to be done. * Let seekdir(3) invalidate the buffer by setting the pointer after its end, instead of to its beginning. * Have readdir(3) refrain from invalidating the buffer when asked to return the first element from it. This comes with only one price: Adding another off_t to the opaque struct _dirdesc (= DIR), which already contains another off_t, two long, two int, and two pointers. That's not much growth, especially since no sane code will allocate large numbers of DIRs. As explained last year, this patch reduced typical execution times of rewinddir(3) on my notebook for about 100 microseconds to about 0.05 microseconds. The /usr/src/regress/lib/libc/telldir/ test suite is still happy, and so are some other, manual tests i have done. Am i right that, the type DIR being opaque, this patch doesn't require any libc bump? Comments, OKs? Ingo Index: opendir.c === RCS file: /cvs/src/lib/libc/gen/opendir.c,v retrieving revision 1.26 diff -u -p -r1.26 opendir.c --- opendir.c 6 Nov 2013 20:35:25 - 1.26 +++ opendir.c 6 Mar 2014 17:14:16 - @@ -76,7 +76,7 @@ fdopendir(int fd) dirp = __fdopendir(fd); if (dirp != NULL) { /* Record current offset for immediate telldir() */ - dirp->dd_curpos = lseek(fd, 0, SEEK_CUR); + dirp->dd_bufpos = dirp->dd_curpos = lseek(fd, 0, SEEK_CUR); /* * POSIX doesn't require fdopendir() to set @@ -116,6 +116,7 @@ __fdopendir(int fd) dirp->dd_fd = fd; dirp->dd_lock = NULL; dirp->dd_curpos = 0; + dirp->dd_bufpos = 0; return (dirp); } Index: readdir.c === RCS file: /cvs/src/lib/libc/gen/readdir.c,v retrieving revision 1.20 diff -u -p -r1.20 readdir.c --- readdir.c 6 Nov 2013 22:26:14 - 1.20 +++ readdir.c 6 Mar 2014 17:14:16 - @@ -43,9 +43,8 @@ _readdir_unlocked(DIR *dirp, struct dire *result = NULL; for (;;) { - if (dirp->dd_loc >= dirp->dd_size) + if (dirp->dd_loc >= dirp->dd_size) { dirp->dd_loc = 0; - if (dirp->dd_loc == 0) { dirp->dd_size = getdents(dirp->dd_fd, dirp->dd_buf, dirp->dd_len); if (dirp->dd_size == 0) Index: seekdir.c === RCS file: /cvs/src/lib/libc/gen/seekdir.c,v retrieving revision 1.11 diff -u -p -r1.11 seekdir.c --- seekdir.c 6 Nov 2013 20:35:25 - 1.11 +++ seekdir.c 6 Mar 2014 17:14:16 - @@ -36,6 +36,13 @@ seekdir(DIR *dirp, long loc)
Re: Sync pthread_set_name_np.3 with pthread_np.h
On Thu, Mar 06, 2014 at 09:02:22AM +0100, Gabriel Linder wrote: > Index: pthread_set_name_np.3 > === > RCS file: /cvs/src/lib/libpthread/man/pthread_set_name_np.3,v > retrieving revision 1.5 > diff -u -p -r1.5 pthread_set_name_np.3 > --- pthread_set_name_np.3 5 Jun 2013 03:44:50 - 1.5 > +++ pthread_set_name_np.3 6 Mar 2014 07:59:58 - > @@ -10,7 +10,7 @@ > .In pthread.h > .In pthread_np.h > .Ft void > -.Fn pthread_set_name_np "pthread_t thread" "char *name" > +.Fn pthread_set_name_np "pthread_t thread" "const char *name" > .Sh DESCRIPTION > The > .Fn pthread_set_name_np > fixed, thanks! jmc
Re: [diff] calendar.birthday
On Wed, Mar 05, 2014 at 08:38:43PM -0800, patrick keshishian wrote: > Index: calendar.birthday > === > RCS file: /cvs/obsd/src/usr.bin/calendar/calendars/calendar.birthday,v > retrieving revision 1.57 > diff -u -p -u -p -r1.57 calendar.birthday > --- calendar.birthday 11 Feb 2014 12:20:34 - 1.57 > +++ calendar.birthday 6 Mar 2014 04:37:08 - > @@ -77,6 +77,7 @@ > 02/17T. J. Watson, Sr. born, 1874 > 02/17Marion Anderson born, 1902 > 02/18Ernst Mach born, 1838, philosopher & optics pioneer > +02/18Michelangelo Buonarroti dies in Rome, Italy, 1564 > 02/19Nicolas Copernicus born in Thorn, Poland, 1473 > 02/20Ludwig Boltzmann born, 1844, atomic physics pioneer > 02/21Alexis De Rochon born, 1838, developed the spyglass > added, thanks! jmc
Re: missing ports.tar.gz in snapshot
previously on this list Shawn K. Quinn contributed: Makes very little difference to me. > I don't use the ports tree at all anymore. That said, I would trust the > empirical evidence (FTP logs) more than any on-list answers you might > get. Is there a pkg* tools equivalent to print-run-depends? -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) In Other Words - Don't design like polkit or systemd ___
Re: missing ports.tar.gz in snapshot
On Thu, Mar 06, 2014 at 07:56:14AM -0700, Theo de Raadt wrote: > [...] > I'd like to ask. Does anyone find it useful? It is not in sync with the > packages beside it. > [...] In the past, I found the tarball quite useful to jump start the ports tree on my local machine. I'd extract it and then use CVS to update it to the repository, because that's usually a lot faster than doing the entire checkout from CVS. I could live with the tarball gone though. -- Gregor Best
Re: missing ports.tar.gz in snapshot
> > So read what I said again. They're not in sync. > > But they are in sync for a release. Or the ports.tar.gz file won't be a > part of a release anymore? Yes, they are in sync for a release. But the Subject says "snapshot".
Re: missing ports.tar.gz in snapshot
On Thu, 6 Mar 2014, Theo de Raadt wrote: I'd like to ask. Does anyone find it useful? It is not in sync with the packages beside it. I thought the packages are being build from the ports tree or am I wrong? Sigh. So I can make a tar file available. At a particular moment in time. But the package builts are not done in an instant; far from that, especially on slower machines. So read what I said again. They're not in sync. But they are in sync for a release. Or the ports.tar.gz file won't be a part of a release anymore? Regards, David
Re: missing ports.tar.gz in snapshot
On Thu, Mar 06, 2014 at 03:18:38PM +, Devin Ceartas wrote: > > Are all the ports in the packages in snapshots? I seem to remember needing to > build some of the things I use to test, but maybe that has changed. There are a few ports not in snapshots, stuff that is not authorized for ftp redistribution. Accidents happen. Sometimes, stuff does not build. That's more frequent on less used architectures. Most builds on amd64 give 100%. All packages referenced in the ports tree that should be on amd64 do build.
Re: missing ports.tar.gz in snapshot
> Personally I'd keep them for releases (which also gives people a base > to speed up updates to -current) but probably drop them for snapshots.. In the next few hours, the file will be there. (Can one of you select yourself to help care & watch this file, and talk just to me about it? I'm changing some stuff as to how it gets updated)
Re: missing ports.tar.gz in snapshot
On 2014/03/06 08:32, Theo de Raadt wrote: > > > > I'd like to ask. Does anyone find it useful? It is not in sync with > > > > the > > > > packages beside it. > > > > > > > > > > I thought the packages are being build from the ports tree or am I wrong? > > Sigh. > > So I can make a tar file available. At a particular moment in time. > > But the package builts are not done in an instant; far from that, especially > on slower machines. > > So read what I said again. They're not in sync. > I think the main use for the tar files is for people who are behind a restrictive firewall that they can't ssh through to use anoncvs (though there are anoncvs servers which run on alternative ports which is often good enough to get around this). They might also be a bit quicker to fetch in bulk than a cvs checkout, which doesn't stream particularly well over slow net for lots of small files. Personally I'd keep them for releases (which also gives people a base to speed up updates to -current) but probably drop them for snapshots..
Re: missing ports.tar.gz in snapshot
> > > > I'd like to ask. Does anyone find it useful? It is not in sync with > > > > the > > > > packages beside it. > > > > > > > > > > I thought the packages are being build from the ports tree or am I wrong? > > Sigh. > > So I can make a tar file available. At a particular moment in time. > > But the package builts are not done in an instant; far from that, especially > on slower machines. > > So read what I said again. They're not in sync. Ahh, I see. Thank you for the explanation.
Re: missing ports.tar.gz in snapshot
On Mar 6, 2014, at 3:34 PM, Theo de Raadt wrote: >>> Are all the ports in the packages in snapshots? > > The best way to get source code from our project is not in tar files, > but using the repository-access methods described on the web site > and in the FAQ. Then it is easier to move your tree forward in time, > rather than downloading files this big, every time. > > -rw-r--r-- 1 deraadt wheel 21.8M Mar 5 13:14 ports.tar.gz > -rw-r--r-- 1 deraadt wheel 160M Mar 5 09:46 src.tar.gz > -rw-r--r-- 1 deraadt wheel 110M Mar 5 09:46 xenocara.tar.gz > OK, sure, cvs update the ports tree. That works for me. Now that I think about it, I'm sure that's what I've done at least some of the time. No problem.
Re: missing ports.tar.gz in snapshot
> > Are all the ports in the packages in snapshots? The best way to get source code from our project is not in tar files, but using the repository-access methods described on the web site and in the FAQ. Then it is easier to move your tree forward in time, rather than downloading files this big, every time. -rw-r--r-- 1 deraadt wheel 21.8M Mar 5 13:14 ports.tar.gz -rw-r--r-- 1 deraadt wheel 160M Mar 5 09:46 src.tar.gz -rw-r--r-- 1 deraadt wheel 110M Mar 5 09:46 xenocara.tar.gz
Re: missing ports.tar.gz in snapshot
> > > I'd like to ask. Does anyone find it useful? It is not in sync with the > > > packages beside it. > > > > > > > I thought the packages are being build from the ports tree or am I wrong? Sigh. So I can make a tar file available. At a particular moment in time. But the package builts are not done in an instant; far from that, especially on slower machines. So read what I said again. They're not in sync.
Re: missing ports.tar.gz in snapshot
On Thu, Mar 06, 2014 at 03:18:38PM +, Devin Ceartas wrote: > On Mar 6, 2014, at 3:13 PM, Vijay Sankar wrote: > > > Quoting Theo de Raadt : > > > >>> is there a reason, why there is no ports.tar.gz in the latest snapshot > >>> folder? > >> > >> At present, it is not being built in the ftp area any more. > >> > >> I'd like to ask. Does anyone find it useful? It is not in sync with the > >> packages beside it. > >> > >> > > > > Are all the ports in the packages in snapshots? I seem to remember needing to > build some of the things I use to test, but maybe that has changed. > > I use snapshots when I have time to test, so whatever direction you want to > give as far as testing goes, just let us know. > > devin > > No, not all ports can be distributed as packages due to license restrictions. -- James Turner
Re: missing ports.tar.gz in snapshot
> Quoting Theo de Raadt : > > >> is there a reason, why there is no ports.tar.gz in the latest > >> snapshot folder? > > > > At present, it is not being built in the ftp area any more. > > > > I'd like to ask. Does anyone find it useful? It is not in sync with the > > packages beside it. > > > > I thought the packages are being build from the ports tree or am I wrong? > > Hi Theo, > > Sometimes, when a dependency package is missing in snapshots or when > the package itself does not work; I have used ports.tar.gz to build > the package and test it. This has helped me with testing openldap. > qemu, and horde. > > I suppose this could also be done with cvsync etc., so this is not a > request to have ports.tar.gz; but it has been useful. > > Thanks, > > Vijay > > Vijay Sankar, M.Eng., P.Eng. > ForeTell Technologies Limited > vsan...@foretell.ca > > - > This message was sent using ForeTell-POST 4.9 > >
Re: missing ports.tar.gz in snapshot
On Mar 6, 2014, at 3:13 PM, Vijay Sankar wrote: > Quoting Theo de Raadt : > >>> is there a reason, why there is no ports.tar.gz in the latest snapshot >>> folder? >> >> At present, it is not being built in the ftp area any more. >> >> I'd like to ask. Does anyone find it useful? It is not in sync with the >> packages beside it. >> >> > Are all the ports in the packages in snapshots? I seem to remember needing to build some of the things I use to test, but maybe that has changed. I use snapshots when I have time to test, so whatever direction you want to give as far as testing goes, just let us know. devin
Re: missing ports.tar.gz in snapshot
Quoting Theo de Raadt : is there a reason, why there is no ports.tar.gz in the latest snapshot folder? At present, it is not being built in the ftp area any more. I'd like to ask. Does anyone find it useful? It is not in sync with the packages beside it. Hi Theo, Sometimes, when a dependency package is missing in snapshots or when the package itself does not work; I have used ports.tar.gz to build the package and test it. This has helped me with testing openldap. qemu, and horde. I suppose this could also be done with cvsync etc., so this is not a request to have ports.tar.gz; but it has been useful. Thanks, Vijay Vijay Sankar, M.Eng., P.Eng. ForeTell Technologies Limited vsan...@foretell.ca - This message was sent using ForeTell-POST 4.9
Re: missing ports.tar.gz in snapshot
On Thu, Mar 6, 2014, at 08:56 AM, Theo de Raadt wrote: > > is there a reason, why there is no ports.tar.gz in the latest snapshot > > folder? > > At present, it is not being built in the ftp area any more. > > I'd like to ask. Does anyone find it useful? It is not in sync with the > packages beside it. I don't use the ports tree at all anymore. That said, I would trust the empirical evidence (FTP logs) more than any on-list answers you might get. -- Shawn K. Quinn skqu...@rushpost.com
Re: missing ports.tar.gz in snapshot
> is there a reason, why there is no ports.tar.gz in the latest snapshot folder? At present, it is not being built in the ftp area any more. I'd like to ask. Does anyone find it useful? It is not in sync with the packages beside it.
missing ports.tar.gz in snapshot
Hi tech, is there a reason, why there is no ports.tar.gz in the latest snapshot folder? fritjof
Re: carp BACKUP and NA
On 06/03/14(Thu) 09:34, Martin Pieuchot wrote: > On 19/02/14(Wed) 12:53, Martin Pieuchot wrote: > > Generally, when a NA is received we check if the receiving interface > > has the target address advertised and if it's the case we warn about > > duplicate addresses and bail. > > > > But in the case of a carp interface in BACKUP state it's different. In > > this case we have a hack that sets the ifa to NULL and continue. This > > hack relies on the fact that no cache entry will be found later on > > (because it was removed when the state switch to BACKUP) or that there > > is no lladdr change in the NA (like it is right now) to work properly. > > > > So instead of expecting such things, simply ignore NAs with matching > > address on carp BACKUP nodes since they are more likely to come from > > the carp MASTER. > > > > Less is more, ok? > > Anybody? And now a correct version without a "typo" (|| should be &&) spotted by sthen@. Here's a freshly retested the diff: Index: netinet6/nd6_nbr.c === RCS file: /home/ncvs/src/sys/netinet6/nd6_nbr.c,v retrieving revision 1.75 diff -u -p -r1.75 nd6_nbr.c --- netinet6/nd6_nbr.c 24 Jan 2014 12:20:22 - 1.75 +++ netinet6/nd6_nbr.c 6 Mar 2014 10:08:17 - @@ -570,9 +570,6 @@ nd6_na_input(struct mbuf *m, int off, in struct rtentry *rt; struct sockaddr_dl *sdl; union nd_opts ndopts; -#if NCARP > 0 - struct sockaddr_dl *proxydl = NULL; -#endif char addr[INET6_ADDRSTRLEN], addr0[INET6_ADDRSTRLEN]; if (ip6->ip6_hlim != 255) { @@ -632,11 +629,6 @@ nd6_na_input(struct mbuf *m, int off, in } ifa = &in6ifa_ifpwithaddr(ifp, &taddr6)->ia_ifa; -#if NCARP > 0 - if (ifp->if_type == IFT_CARP && ifa && - !carp_iamatch6(ifp, lladdr, &proxydl)) - ifa = NULL; -#endif /* * Target address matches one of my interface address. @@ -652,8 +644,18 @@ nd6_na_input(struct mbuf *m, int off, in goto freeit; } - /* Just for safety, maybe unnecessary. */ if (ifa) { +#if NCARP > 0 + struct sockaddr_dl *proxydl = NULL; + + /* +* Ignore NAs silently for carp addresses if we're not +* the CARP master. +*/ + if (ifp->if_type == IFT_CARP && + !carp_iamatch6(ifp, lladdr, &proxydl)) + goto freeit; +#endif log(LOG_ERR, "nd6_na_input: duplicate IP6 address %s\n", inet_ntop(AF_INET6, &taddr6, addr, sizeof(addr)));
Sync pthread_set_name_np.3 with pthread_np.h
Index: pthread_set_name_np.3 === RCS file: /cvs/src/lib/libpthread/man/pthread_set_name_np.3,v retrieving revision 1.5 diff -u -p -r1.5 pthread_set_name_np.3 --- pthread_set_name_np.3 5 Jun 2013 03:44:50 - 1.5 +++ pthread_set_name_np.3 6 Mar 2014 07:59:58 - @@ -10,7 +10,7 @@ .In pthread.h .In pthread_np.h .Ft void -.Fn pthread_set_name_np "pthread_t thread" "char *name" +.Fn pthread_set_name_np "pthread_t thread" "const char *name" .Sh DESCRIPTION The .Fn pthread_set_name_np
Re: if_detach() addresses cleanup
On 22/01/14(Wed) 11:46, Martin Pieuchot wrote: > Network addresses added to the interface local list thought ifa_add() > are the link-local address and the IPv4/6 ones. > > Since if_detach() now calls in_ifdetach(), there should be no address > left on the list apart from the link-layer one at this stage. So the > diff below removes it directly, there's no need for a loop anymore. > > I left a check for safety afterward... > > ok? Still looking for oks... > > Index: net/if.c > === > RCS file: /home/ncvs/src/sys/net/if.c,v > retrieving revision 1.279 > diff -u -p -r1.279 if.c > --- net/if.c 28 Nov 2013 10:16:44 - 1.279 > +++ net/if.c 7 Jan 2014 11:57:09 - > @@ -359,12 +359,10 @@ if_free_sadl(struct ifnet *ifp) > > s = splnet(); > rtinit(ifa, RTM_DELETE, 0); > -#if 0 > ifa_del(ifp, ifa); > + ifafree(ifp->if_lladdr); > ifp->if_lladdr = NULL; > -#endif > ifp->if_sadl = NULL; > - > splx(s); > } > > @@ -587,27 +585,22 @@ do { \ > if (ISSET(ifp->if_xflags, IFXF_TXREADY)) > TAILQ_REMOVE(&iftxlist, ifp, if_txlist); > > - /* > - * Deallocate private resources. > - */ > - while ((ifa = TAILQ_FIRST(&ifp->if_addrlist)) != NULL) { > - ifa_del(ifp, ifa); > - /* XXX if_free_sadl needs this */ > - if (ifa == ifp->if_lladdr) > - continue; > - > - ifa->ifa_ifp = NULL; > - ifafree(ifa); > - } > - > while ((ifg = TAILQ_FIRST(&ifp->if_groups)) != NULL) > if_delgroup(ifp, ifg->ifgl_group->ifg_group); > > if_free_sadl(ifp); > > - ifp->if_lladdr->ifa_ifp = NULL; > - ifafree(ifp->if_lladdr); > - ifp->if_lladdr = NULL; > + /* We should not have any address left at this point. */ > + if (!TAILQ_EMPTY(&ifp->if_addrlist)) { > +#ifdef DIAGNOSTIC > + printf("%s: address list non empty\n", ifp->if_xname); > +#endif > + while ((ifa = TAILQ_FIRST(&ifp->if_addrlist)) != NULL) { > + ifa_del(ifp, ifa); > + ifa->ifa_ifp = NULL; > + ifafree(ifa); > + } > + } > > free(ifp->if_addrhooks, M_TEMP); > free(ifp->if_linkstatehooks, M_TEMP); >
Re: carp BACKUP and NA
On 19/02/14(Wed) 12:53, Martin Pieuchot wrote: > Generally, when a NA is received we check if the receiving interface > has the target address advertised and if it's the case we warn about > duplicate addresses and bail. > > But in the case of a carp interface in BACKUP state it's different. In > this case we have a hack that sets the ifa to NULL and continue. This > hack relies on the fact that no cache entry will be found later on > (because it was removed when the state switch to BACKUP) or that there > is no lladdr change in the NA (like it is right now) to work properly. > > So instead of expecting such things, simply ignore NAs with matching > address on carp BACKUP nodes since they are more likely to come from > the carp MASTER. > > Less is more, ok? Anybody? > > Index: nd6_nbr.c > === > RCS file: /home/ncvs/src/sys/netinet6/nd6_nbr.c,v > retrieving revision 1.75 > diff -u -p -r1.75 nd6_nbr.c > --- nd6_nbr.c 24 Jan 2014 12:20:22 - 1.75 > +++ nd6_nbr.c 13 Feb 2014 11:14:04 - > @@ -570,9 +570,6 @@ nd6_na_input(struct mbuf *m, int off, in > struct rtentry *rt; > struct sockaddr_dl *sdl; > union nd_opts ndopts; > -#if NCARP > 0 > - struct sockaddr_dl *proxydl = NULL; > -#endif > char addr[INET6_ADDRSTRLEN], addr0[INET6_ADDRSTRLEN]; > > if (ip6->ip6_hlim != 255) { > @@ -632,11 +629,6 @@ nd6_na_input(struct mbuf *m, int off, in > } > > ifa = &in6ifa_ifpwithaddr(ifp, &taddr6)->ia_ifa; > -#if NCARP > 0 > - if (ifp->if_type == IFT_CARP && ifa && > - !carp_iamatch6(ifp, lladdr, &proxydl)) > - ifa = NULL; > -#endif > > /* >* Target address matches one of my interface address. > @@ -652,8 +644,18 @@ nd6_na_input(struct mbuf *m, int off, in > goto freeit; > } > > - /* Just for safety, maybe unnecessary. */ > if (ifa) { > +#if NCARP > 0 > + struct sockaddr_dl *proxydl = NULL; > + > + /* > + * Ignore NAs silently for carp addresses if we're not > + * the CARP master. > + */ > + if (ifp->if_type == IFT_CARP || > + !carp_iamatch6(ifp, lladdr, &proxydl)) > + goto freeit; > +#endif > log(LOG_ERR, > "nd6_na_input: duplicate IP6 address %s\n", > inet_ntop(AF_INET6, &taddr6, addr, sizeof(addr))); >