svn commit: r280980 - in head: . lib/csu/i386-elf sys/boot/i386/boot2 sys/boot/i386/gptboot sys/boot/i386/gptzfsboot sys/boot/i386/zfsboot sys/boot/mips/beri/boot2 sys/boot/pc98/boot0 sys/boot/pc98...
Author: dim
Date: Thu Apr 2 06:58:17 2015
New Revision: 280980
URL: https://svnweb.freebsd.org/changeset/base/280980
Log:
Ensure the cross assembler, linker and objcopy are used for the build32
stage, just like for the regular world stage.
Reviewed by: rodrigc, imp, bapt, emaste
MFC after:1 week
Differential Revision: https://reviews.freebsd.org/D2187
Modified:
head/Makefile.inc1
head/lib/csu/i386-elf/Makefile
head/sys/boot/i386/boot2/Makefile
head/sys/boot/i386/gptboot/Makefile
head/sys/boot/i386/gptzfsboot/Makefile
head/sys/boot/i386/zfsboot/Makefile
head/sys/boot/mips/beri/boot2/Makefile
head/sys/boot/pc98/boot0.5/Makefile
head/sys/boot/pc98/boot0/Makefile
head/sys/boot/pc98/boot2/Makefile
Modified: head/Makefile.inc1
==
--- head/Makefile.inc1 Thu Apr 2 03:25:35 2015(r280979)
+++ head/Makefile.inc1 Thu Apr 2 06:58:17 2015(r280980)
@@ -411,8 +411,9 @@ LIB32CPUFLAGS= -march=${TARGET_CPUTYPE}
LIB32WMAKEENV= MACHINE=i386 MACHINE_ARCH=i386 \
MACHINE_CPU=i686 mmx sse sse2
LIB32WMAKEFLAGS= \
- AS=${AS} --32 \
- LD=${LD} -m elf_i386_fbsd -Y P,${LIB32TMP}/usr/lib32
+ AS=${XAS} --32 \
+ LD=${XLD} -m elf_i386_fbsd -Y P,${LIB32TMP}/usr/lib32 \
+ OBJCOPY=${XOBJCOPY}
.elif ${TARGET_ARCH} == powerpc64
.if empty(TARGET_CPUTYPE)
@@ -422,7 +423,8 @@ LIB32CPUFLAGS= -mcpu=${TARGET_CPUTYPE}
.endif
LIB32WMAKEENV= MACHINE=powerpc MACHINE_ARCH=powerpc
LIB32WMAKEFLAGS= \
- LD=${LD} -m elf32ppc_fbsd
+ LD=${XLD} -m elf32ppc_fbsd \
+ OBJCOPY=${XOBJCOPY}
.endif
Modified: head/lib/csu/i386-elf/Makefile
==
--- head/lib/csu/i386-elf/Makefile Thu Apr 2 03:25:35 2015
(r280979)
+++ head/lib/csu/i386-elf/Makefile Thu Apr 2 06:58:17 2015
(r280980)
@@ -35,7 +35,7 @@ crt1_c.o: crt1_c.s
crt1.o:crt1_c.o crt1_s.o
${LD} ${_LDFLAGS} -o crt1.o -r crt1_s.o crt1_c.o
- objcopy --localize-symbol _start1 crt1.o
+ ${OBJCOPY} --localize-symbol _start1 crt1.o
Scrt1_c.s: crt1_c.c
${CC} ${CFLAGS} -fPIC -DPIC -S -o ${.TARGET} ${.CURDIR}/crt1_c.c
@@ -46,7 +46,7 @@ Scrt1_c.o: Scrt1_c.s
Scrt1.o: Scrt1_c.o crt1_s.o
${LD} ${_LDFLAGS} -o Scrt1.o -r crt1_s.o Scrt1_c.o
- objcopy --localize-symbol _start1 Scrt1.o
+ ${OBJCOPY} --localize-symbol _start1 Scrt1.o
realinstall:
${INSTALL} -o ${LIBOWN} -g ${LIBGRP} -m ${LIBMODE} \
Modified: head/sys/boot/i386/boot2/Makefile
==
--- head/sys/boot/i386/boot2/Makefile Thu Apr 2 03:25:35 2015
(r280979)
+++ head/sys/boot/i386/boot2/Makefile Thu Apr 2 06:58:17 2015
(r280980)
@@ -61,7 +61,7 @@ boot: boot1 boot2
CLEANFILES+= boot1 boot1.out boot1.o
boot1: boot1.out
- objcopy -S -O binary boot1.out ${.TARGET}
+ ${OBJCOPY} -S -O binary boot1.out ${.TARGET}
boot1.out: boot1.o
${LD} ${LD_FLAGS} -e start -Ttext ${ORG1} -o ${.TARGET} boot1.o
@@ -82,7 +82,7 @@ boot2.ldr:
dd if=/dev/zero of=${.TARGET} bs=512 count=1
boot2.bin: boot2.out
- objcopy -S -O binary boot2.out ${.TARGET}
+ ${OBJCOPY} -S -O binary boot2.out ${.TARGET}
boot2.out: ${BTXCRT} boot2.o sio.o
${LD} ${LD_FLAGS} -Ttext ${ORG2} -o ${.TARGET} ${.ALLSRC}
Modified: head/sys/boot/i386/gptboot/Makefile
==
--- head/sys/boot/i386/gptboot/Makefile Thu Apr 2 03:25:35 2015
(r280979)
+++ head/sys/boot/i386/gptboot/Makefile Thu Apr 2 06:58:17 2015
(r280980)
@@ -55,7 +55,7 @@ gptboot: gptldr.bin gptboot.bin ${BTXKER
CLEANFILES+= gptldr.bin gptldr.out gptldr.o
gptldr.bin: gptldr.out
- objcopy -S -O binary gptldr.out ${.TARGET}
+ ${OBJCOPY} -S -O binary gptldr.out ${.TARGET}
gptldr.out: gptldr.o
${LD} ${LD_FLAGS} -e start -Ttext ${ORG1} -o ${.TARGET} gptldr.o
@@ -64,7 +64,7 @@ CLEANFILES+= gptboot.bin gptboot.out gpt
cons.o util.o
gptboot.bin: gptboot.out
- objcopy -S -O binary gptboot.out ${.TARGET}
+ ${OBJCOPY} -S -O binary gptboot.out ${.TARGET}
gptboot.out: ${BTXCRT} gptboot.o sio.o gpt.o crc32.o drv.o cons.o util.o
${LD} ${LD_FLAGS} -Ttext ${ORG2} -o ${.TARGET} ${.ALLSRC} ${LIBSTAND}
Modified: head/sys/boot/i386/gptzfsboot/Makefile
==
--- head/sys/boot/i386/gptzfsboot/Makefile Thu Apr 2 03:25:35 2015
(r280979)
+++ head/sys/boot/i386/gptzfsboot/Makefile Thu Apr 2 06:58:17 2015
(r280980)
@@ -53,7 +53,7 @@ gptzfsboot: gptldr.bin gptzfsboot.bin ${
CLEANFILES+= gptldr.bin gptldr.out
Re: svn commit: r280955 - in head/sys: modules/notrandom dev/notrandom
On Wed, Apr 01, 2015 at 07:04:03PM +0100, David Chisnall wrote: This almost certainly does not make people happy: - * Copyright (c) 2000 Mark R. V. Murray Jeroen C. van Gelderen - * Copyright (c) 2001-2004 Mark R. V. Murray - * Copyright (c) 2014 Eitan Adler + * Copyright (c) 2015 Mateusz Guzik * All rights reserved. * + * Some dudes which previously held the copyright: + * Marc V. R. Murray, Jeroen C. van Gelderen, Eytan Adrel + * Please try not to violate copyright in commits to the FreeBSD project. We get cranky when we have to talk to lawyers. [...] I also want to point out that Jeroen's name (all of it) was mistyped; that is disrespectful and rude and should be fixed. ./danfe ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
Re: svn commit: r280955 - in head/sys: modules/notrandom dev/notrandom
On Apr 1, 2015, at 23:15, Alexey Dokuchaev da...@freebsd.org wrote: On Wed, Apr 01, 2015 at 07:04:03PM +0100, David Chisnall wrote: This almost certainly does not make people happy: - * Copyright (c) 2000 Mark R. V. Murray Jeroen C. van Gelderen - * Copyright (c) 2001-2004 Mark R. V. Murray - * Copyright (c) 2014 Eitan Adler + * Copyright (c) 2015 Mateusz Guzik * All rights reserved. * + * Some dudes which previously held the copyright: + * Marc V. R. Murray, Jeroen C. van Gelderen, Eytan Adrel + * Please try not to violate copyright in commits to the FreeBSD project. We get cranky when we have to talk to lawyers. [...] I also want to point out that Jeroen's name (all of it) was mistyped; that is disrespectful and rude and should be fixed. To those who didn’t get the joke earlier, you were April Fool’ed. Cheers... $ svn log -r 280955 ^/head r280955 | kp | 2015-04-01 05:15:01 -0700 (Wed, 01 Apr 2015) | 13 lines Preserve IPv6 fragment IDs accross reassembly and refragmentation When forwarding fragmented IPv6 packets and filtering with PF we reassemble and refragment. That means we generate new fragment headers and a new fragment ID. We already save the fragment IDs so we can do the reassembly so it's straightforward to apply the incoming fragment ID on the refragmented packets. Differential Revision: https://reviews.freebsd.org/D2188 Approved by:gnn (mentor) signature.asc Description: Message signed with OpenPGP using GPGMail
svn commit: r281002 - in head/sys/boot: arm/uboot forth i386/loader mips/beri/loader pc98/loader powerpc/kboot powerpc/ofw powerpc/ps3 sparc64/loader
Author: jkim
Date: Thu Apr 2 20:07:05 2015
New Revision: 281002
URL: https://svnweb.freebsd.org/changeset/base/281002
Log:
Install newly added brand-*.4th and logo-*.4th files and reduce duplication.
Reviewed by: dteske
Pointy hat to:dteske
Added:
head/sys/boot/forth/Makefile.inc (contents, props changed)
Modified:
head/sys/boot/arm/uboot/Makefile
head/sys/boot/i386/loader/Makefile
head/sys/boot/mips/beri/loader/Makefile
head/sys/boot/pc98/loader/Makefile
head/sys/boot/powerpc/kboot/Makefile
head/sys/boot/powerpc/ofw/Makefile
head/sys/boot/powerpc/ps3/Makefile
head/sys/boot/sparc64/loader/Makefile
Modified: head/sys/boot/arm/uboot/Makefile
==
--- head/sys/boot/arm/uboot/MakefileThu Apr 2 19:10:33 2015
(r281001)
+++ head/sys/boot/arm/uboot/MakefileThu Apr 2 20:07:05 2015
(r281002)
@@ -136,12 +136,7 @@ ldscript.generated::
fi
.if !defined(LOADER_ONLY)
-.PATH: ${.CURDIR}/../../forth
-FILES+=loader.help loader.4th support.4th loader.conf
-FILES+=screen.4th frames.4th beastie.4th
-FILES+=brand.4th check-password.4th color.4th delay.4th
-FILES+=menu.4th menu-commands.4th menusets.4th shortcuts.4th
version.4th
-FILESDIR_loader.conf= /boot/defaults
+.include ${.CURDIR}/../../forth/Makefile.inc
# Put sample loader.rc and menu.rc on disk but don't enable them
# by default.
Added: head/sys/boot/forth/Makefile.inc
==
--- /dev/null 00:00:00 1970 (empty, because file is newly added)
+++ head/sys/boot/forth/Makefile.incThu Apr 2 20:07:05 2015
(r281002)
@@ -0,0 +1,26 @@
+# $FreeBSD$
+
+.PATH: ${.CURDIR}/../../forth
+FILES+=beastie.4th
+FILES+=brand.4th
+FILES+=brand-fbsd.4th
+FILES+=check-password.4th
+FILES+=color.4th
+FILES+=delay.4th
+FILES+=frames.4th
+FILES+=loader.4th
+FILES+=loader.conf
+FILES+=loader.help
+FILES+=logo-beastie.4th
+FILES+=logo-beastiebw.4th
+FILES+=logo-fbsdbw.4th
+FILES+=logo-orb.4th
+FILES+=logo-orbbw.4th
+FILES+=menu.4th
+FILES+=menu-commands.4th
+FILES+=menusets.4th
+FILES+=screen.4th
+FILES+=shortcuts.4th
+FILES+=support.4th
+FILES+=version.4th
+FILESDIR_loader.conf= /boot/defaults
Modified: head/sys/boot/i386/loader/Makefile
==
--- head/sys/boot/i386/loader/Makefile Thu Apr 2 19:10:33 2015
(r281001)
+++ head/sys/boot/i386/loader/Makefile Thu Apr 2 20:07:05 2015
(r281002)
@@ -105,13 +105,8 @@ FILES= ${LOADER}
FILESMODE_${LOADER}= ${BINMODE} -b
.if !defined(LOADER_ONLY)
-.PATH: ${.CURDIR}/../../forth
-FILES+=loader.help loader.4th support.4th loader.conf
-FILES+= screen.4th frames.4th beastie.4th
-FILES+= brand.4th check-password.4th color.4th delay.4th
-FILES+= menu.4th menu-commands.4th menusets.4th shortcuts.4th version.4th
-FILES+= pcibios.4th
-FILESDIR_loader.conf= /boot/defaults
+.include ${.CURDIR}/../../forth/Makefile.inc
+FILES+=pcibios.4th
.if !exists(${DESTDIR}/boot/loader.rc)
FILES+=loader.rc
Modified: head/sys/boot/mips/beri/loader/Makefile
==
--- head/sys/boot/mips/beri/loader/Makefile Thu Apr 2 19:10:33 2015
(r281001)
+++ head/sys/boot/mips/beri/loader/Makefile Thu Apr 2 20:07:05 2015
(r281002)
@@ -121,12 +121,7 @@ loader.help: help.common help.mips
cat ${.ALLSRC} | \
awk -f ${.CURDIR}/../../../common/merge_help.awk ${.TARGET}
-.PATH: ${.CURDIR}/../../../forth
-FILES= loader.help loader.4th support.4th loader.conf
-FILES+=screen.4th frames.4th
-FILES+=beastie.4th brand.4th check-password.4th color.4th delay.4th
-FILES+=menu.4th menu-commands.4th menusets.4th shortcuts.4th
version.4th
-FILESDIR_loader.conf= /boot/defaults
+.include ${.CURDIR}/../../forth/Makefile.inc
.if !exists(${DESTDIR}/boot/loader.rc)
FILES+= loader.rc
Modified: head/sys/boot/pc98/loader/Makefile
==
--- head/sys/boot/pc98/loader/Makefile Thu Apr 2 19:10:33 2015
(r281001)
+++ head/sys/boot/pc98/loader/Makefile Thu Apr 2 20:07:05 2015
(r281002)
@@ -86,12 +86,7 @@ FILES= ${LOADER}
# XXX INSTALLFLAGS_loader= -b
FILESMODE_${LOADER}= ${BINMODE} -b
-.PATH: ${.CURDIR}/../../forth
-FILES+=loader.help loader.4th support.4th loader.conf
-FILES+= screen.4th frames.4th beastie.4th
-FILES+= brand.4th check-password.4th color.4th delay.4th
-FILES+= menu.4th menu-commands.4th menusets.4th shortcuts.4th version.4th
-FILESDIR_loader.conf= /boot/defaults
svn commit: r281003 - in head/sys: kern sys
Author: kib
Date: Thu Apr 2 20:14:51 2015
New Revision: 281003
URL: https://svnweb.freebsd.org/changeset/base/281003
Log:
Speed up symbol lookup for the amd64 kernel modules.
Amd64 uses relocatable object files as the modules format. It is good
WRT not having unneeded overhead for PIC code, in particular, due to
absence of useless GOT and PLT. But the cost is that the module
linking process cannot use hash to speed up the symbol lookup, and
that each reference to the symbol requiring a relocation, instead of
single-place relocation in GOT.
Cache the successfull symbol lookup results in the module symbol
table, using the newly allocated SHN_FBSD_CACHED value from
SHN_LOOS-HIOS range as an indicator. The SHN_FBSD_CACHED together
with the non-existent definition of the found symbol are reverted
after successfull relocations, which is done under kld_sx lock, so it
should not be visible to other consumers of the symbol table.
Submitted by: Conrad Meyer
Differential Revision: https://reviews.freebsd.org/D1718
MFC after:3 weeks
Modified:
head/sys/kern/link_elf_obj.c
head/sys/sys/elf_common.h
Modified: head/sys/kern/link_elf_obj.c
==
--- head/sys/kern/link_elf_obj.cThu Apr 2 20:07:05 2015
(r281002)
+++ head/sys/kern/link_elf_obj.cThu Apr 2 20:14:51 2015
(r281003)
@@ -173,6 +173,7 @@ static struct linker_class link_elf_clas
};
static int relocate_file(elf_file_t ef);
+static voidelf_obj_cleanup_globals_cache(elf_file_t);
static void
link_elf_error(const char *filename, const char *s)
@@ -1075,6 +1076,13 @@ relocate_file(elf_file_t ef)
}
}
+ /*
+* Only clean SHN_FBSD_CACHED for successfull return. If we
+* modified symbol table for the object but found an
+* unresolved symbol, there is no reason to roll back.
+*/
+ elf_obj_cleanup_globals_cache(ef);
+
return 0;
}
@@ -1223,6 +1231,21 @@ link_elf_each_function_nameval(linker_fi
return (0);
}
+static void
+elf_obj_cleanup_globals_cache(elf_file_t ef)
+{
+ Elf_Sym *sym;
+ Elf_Size i;
+
+ for (i = 0; i ef-ddbsymcnt; i++) {
+ sym = ef-ddbsymtab + i;
+ if (sym-st_shndx == SHN_FBSD_CACHED) {
+ sym-st_shndx = SHN_UNDEF;
+ sym-st_value = 0;
+ }
+ }
+}
+
/*
* Symbol lookup function that can be used when the symbol index is known (ie
* in relocations). It uses the symbol index instead of doing a fully fledged
@@ -1234,7 +1257,7 @@ static Elf_Addr
elf_obj_lookup(linker_file_t lf, Elf_Size symidx, int deps)
{
elf_file_t ef = (elf_file_t)lf;
- const Elf_Sym *sym;
+ Elf_Sym *sym;
const char *symbol;
Elf_Addr ret;
@@ -1262,7 +1285,22 @@ elf_obj_lookup(linker_file_t lf, Elf_Siz
if (*symbol == 0)
return (0);
ret = ((Elf_Addr)linker_file_lookup_symbol(lf, symbol, deps));
- return ret;
+
+ /*
+* Cache global lookups during module relocation. The failure
+* case is particularly expensive for callers, who must scan
+* through the entire globals table doing strcmp(). Cache to
+* avoid doing such work repeatedly.
+*
+* After relocation is complete, undefined globals will be
+* restored to SHN_UNDEF in elf_obj_cleanup_globals_cache(),
+* above.
+*/
+ if (ret != 0) {
+ sym-st_shndx = SHN_FBSD_CACHED;
+ sym-st_value = ret;
+ }
+ return (ret);
case STB_WEAK:
printf(link_elf_obj: Weak symbols not supported\n);
Modified: head/sys/sys/elf_common.h
==
--- head/sys/sys/elf_common.h Thu Apr 2 20:07:05 2015(r281002)
+++ head/sys/sys/elf_common.h Thu Apr 2 20:14:51 2015(r281003)
@@ -363,6 +363,9 @@ typedef struct {
#defineSHN_LOPROC 0xff00 /* First processor-specific. */
#defineSHN_HIPROC 0xff1f /* Last processor-specific. */
#defineSHN_LOOS0xff20 /* First operating
system-specific. */
+#defineSHN_FBSD_CACHED SHN_LOOS/* Transient, for
sys/kern/link_elf_obj
+ linker only: Cached global in local
+ symtab. */
#defineSHN_HIOS0xff3f /* Last operating
system-specific. */
#defineSHN_ABS 0xfff1 /* Absolute values. */
#defineSHN_COMMON 0xfff2 /* Common data. */
___
Re: svn commit: r280971 - in head: contrib/ipfilter/tools share/man/man4 sys/contrib/ipfilter/netinet sys/netinet sys/netipsec sys/netpfil/pf
On 04/02/15 20:46, Robert Watson wrote: On Thu, 2 Apr 2015, Hans Petter Selasky wrote: Does somebody here know what happens in these two cases: If we are transmitting using TSO, will the network adapter increment the IP ID field somehow? What happens if an outgoing IP packet resulting from a TSO packet get fragmented by a router? Quite possibly -- this is presumably specified by the NIC vendor, but it would be good to do a bit of a survey and see what happens in practice. In ip_fragment() when we create fragments we should increment the ip_id value for each fragment? I'm asking because the code in FreeBSD, since the beginning probably, just copies the IP header, and use the same IP ID for all the fragments ! This just hit my mind after some recent work in this area. I honestly cannot believe you are proposing that. Please go read about how IP fragmentation works. Having an identical IP ID in ip_fragment() is the point of the function! Hi, rwatson: You're right, the more fragment flag gets set there, I overlooked that bit. Sorry. glebius: Given that you admit there is a small chance of an IP ID collision in the previous e-mails exchanged in this thread, why don't we have checks for that in ip_reass() when receiving fragmented IP packets? For example when ip-ip_off == 0 we know the TCP and/or UDP port numbers for TCP and UDP payloads and can check if a new fragment is starting before the previous one is completed. Then we would know if a collision has happened and could discard that packet. Not ideal, but better than data corruption. --HPS ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
svn commit: r281004 - in head/lib/libc: arm/sys mips/sys powerpc powerpc/sys powerpc64 powerpc64/sys sparc64 sparc64/sys sys
Author: emaste Date: Thu Apr 2 21:18:11 2015 New Revision: 281004 URL: https://svnweb.freebsd.org/changeset/base/281004 Log: libc: Eliminate duplicate copies of __vdso_gettc.c Sponsored by: The FreeBSD Foundation Differential Revision:https://reviews.freebsd.org/D2152 Added: head/lib/libc/sys/trivial-vdso_tc.c - copied unchanged from r281003, head/lib/libc/sparc64/sys/__vdso_gettc.c Deleted: head/lib/libc/arm/sys/__vdso_gettc.c head/lib/libc/mips/sys/__vdso_gettc.c head/lib/libc/powerpc/sys/__vdso_gettc.c head/lib/libc/powerpc64/sys/__vdso_gettc.c head/lib/libc/sparc64/sys/__vdso_gettc.c Modified: head/lib/libc/arm/sys/Makefile.inc head/lib/libc/mips/sys/Makefile.inc head/lib/libc/powerpc/Makefile.inc head/lib/libc/powerpc64/Makefile.inc head/lib/libc/sparc64/Makefile.inc Modified: head/lib/libc/arm/sys/Makefile.inc == --- head/lib/libc/arm/sys/Makefile.inc Thu Apr 2 20:14:51 2015 (r281003) +++ head/lib/libc/arm/sys/Makefile.inc Thu Apr 2 21:18:11 2015 (r281004) @@ -1,6 +1,6 @@ # $FreeBSD$ -SRCS+= __vdso_gettc.c +SRCS+= trivial-vdso_tc.c MDASM= Ovfork.S brk.S cerror.S pipe.S ptrace.S sbrk.S shmat.S sigreturn.S syscall.S Modified: head/lib/libc/mips/sys/Makefile.inc == --- head/lib/libc/mips/sys/Makefile.inc Thu Apr 2 20:14:51 2015 (r281003) +++ head/lib/libc/mips/sys/Makefile.inc Thu Apr 2 21:18:11 2015 (r281004) @@ -1,6 +1,6 @@ # $FreeBSD$ -SRCS+= __vdso_gettc.c +SRCS+= trivial-vdso_tc.c MDASM= Ovfork.S brk.S cerror.S exect.S \ fork.S pipe.S ptrace.S sbrk.S syscall.S Modified: head/lib/libc/powerpc/Makefile.inc == --- head/lib/libc/powerpc/Makefile.inc Thu Apr 2 20:14:51 2015 (r281003) +++ head/lib/libc/powerpc/Makefile.inc Thu Apr 2 21:18:11 2015 (r281004) @@ -1,6 +1,6 @@ # $FreeBSD$ -SRCS+= __vdso_gettc.c +SRCS+= trivial-vdso_tc.c # Long double is 64-bits MDSRCS+=machdep_ldisd.c Modified: head/lib/libc/powerpc64/Makefile.inc == --- head/lib/libc/powerpc64/Makefile.incThu Apr 2 20:14:51 2015 (r281003) +++ head/lib/libc/powerpc64/Makefile.incThu Apr 2 21:18:11 2015 (r281004) @@ -1,6 +1,6 @@ # $FreeBSD$ -SRCS+= __vdso_gettc.c +SRCS+= trivial-vdso_tc.c # Long double is 64-bits MDSRCS+=machdep_ldisd.c Modified: head/lib/libc/sparc64/Makefile.inc == --- head/lib/libc/sparc64/Makefile.inc Thu Apr 2 20:14:51 2015 (r281003) +++ head/lib/libc/sparc64/Makefile.inc Thu Apr 2 21:18:11 2015 (r281004) @@ -5,7 +5,7 @@ .include fpu/Makefile.inc -SRCS+= __vdso_gettc.c +SRCS+= trivial-vdso_tc.c # Long double is quad precision GDTOASRCS+=strtorQ.c Copied: head/lib/libc/sys/trivial-vdso_tc.c (from r281003, head/lib/libc/sparc64/sys/__vdso_gettc.c) == --- /dev/null 00:00:00 1970 (empty, because file is newly added) +++ head/lib/libc/sys/trivial-vdso_tc.c Thu Apr 2 21:18:11 2015 (r281004, copy of r281003, head/lib/libc/sparc64/sys/__vdso_gettc.c) @@ -0,0 +1,48 @@ +/*- + * Copyright (c) 2013 Konstantin Belousov k...@freebsd.org + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + *notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + *notice, this list of conditions and the following disclaimer in the + *documentation and/or other materials provided with the distribution. + * + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + */ + +#include sys/cdefs.h +__FBSDID($FreeBSD$); + +#include sys/types.h +#include sys/time.h +#include sys/vdso.h +#include errno.h + +#pragma
Re: svn commit: r281002 - in head/sys/boot: arm/uboot forth i386/loader mips/beri/loader pc98/loader powerpc/kboot powerpc/ofw powerpc/ps3 sparc64/loader
On 02 Apr 2015, at 20:07 , Jung-uk Kim j...@freebsd.org wrote: Author: jkim Date: Thu Apr 2 20:07:05 2015 New Revision: 281002 URL: https://svnweb.freebsd.org/changeset/base/281002 Log: Install newly added brand-*.4th and logo-*.4th files and reduce duplication. Reviewed by: dteske Pointy hat to: dteske Added: head/sys/boot/forth/Makefile.inc (contents, props changed) Modified: head/sys/boot/arm/uboot/Makefile head/sys/boot/i386/loader/Makefile head/sys/boot/mips/beri/loader/Makefile head/sys/boot/pc98/loader/Makefile head/sys/boot/powerpc/kboot/Makefile head/sys/boot/powerpc/ofw/Makefile head/sys/boot/powerpc/ps3/Makefile head/sys/boot/sparc64/loader/Makefile bmake: /scratch/tmp/bz/head.svn/sys/boot/mips/beri/loader/Makefile line 124: Cannot open /scratch/tmp/bz/head.svn/sys/boot/mips/beri/loader/../../forth/Makefile.inc Seems there is an extra ../ missing? — Bjoern A. Zeeb Charles Haddon Spurgeon: Friendship is one of the sweetest joys of life. Many might have failed beneath the bitterness of their trial had they not found a friend. ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
svn commit: r281009 - in head/sys/boot: arm/uboot forth i386/loader mips/beri/loader pc98/loader powerpc/kboot powerpc/ofw sparc64/loader
Author: jkim
Date: Fri Apr 3 02:27:40 2015
New Revision: 281009
URL: https://svnweb.freebsd.org/changeset/base/281009
Log:
Revert .PATH changes to fix mips build.
Reported by: bz
Pointy hat to:jkim
Modified:
head/sys/boot/arm/uboot/Makefile
head/sys/boot/forth/Makefile.inc
head/sys/boot/i386/loader/Makefile
head/sys/boot/mips/beri/loader/Makefile
head/sys/boot/pc98/loader/Makefile
head/sys/boot/powerpc/kboot/Makefile
head/sys/boot/powerpc/ofw/Makefile
head/sys/boot/sparc64/loader/Makefile
Modified: head/sys/boot/arm/uboot/Makefile
==
--- head/sys/boot/arm/uboot/MakefileThu Apr 2 23:12:18 2015
(r281008)
+++ head/sys/boot/arm/uboot/MakefileFri Apr 3 02:27:40 2015
(r281009)
@@ -136,6 +136,7 @@ ldscript.generated::
fi
.if !defined(LOADER_ONLY)
+.PATH: ${.CURDIR}/../../forth
.include ${.CURDIR}/../../forth/Makefile.inc
# Put sample loader.rc and menu.rc on disk but don't enable them
Modified: head/sys/boot/forth/Makefile.inc
==
--- head/sys/boot/forth/Makefile.incThu Apr 2 23:12:18 2015
(r281008)
+++ head/sys/boot/forth/Makefile.incFri Apr 3 02:27:40 2015
(r281009)
@@ -1,6 +1,5 @@
# $FreeBSD$
-.PATH: ${.CURDIR}/../../forth
FILES+=beastie.4th
FILES+=brand.4th
FILES+=brand-fbsd.4th
Modified: head/sys/boot/i386/loader/Makefile
==
--- head/sys/boot/i386/loader/Makefile Thu Apr 2 23:12:18 2015
(r281008)
+++ head/sys/boot/i386/loader/Makefile Fri Apr 3 02:27:40 2015
(r281009)
@@ -105,6 +105,7 @@ FILES= ${LOADER}
FILESMODE_${LOADER}= ${BINMODE} -b
.if !defined(LOADER_ONLY)
+.PATH: ${.CURDIR}/../../forth
.include ${.CURDIR}/../../forth/Makefile.inc
FILES+=pcibios.4th
Modified: head/sys/boot/mips/beri/loader/Makefile
==
--- head/sys/boot/mips/beri/loader/Makefile Thu Apr 2 23:12:18 2015
(r281008)
+++ head/sys/boot/mips/beri/loader/Makefile Fri Apr 3 02:27:40 2015
(r281009)
@@ -121,6 +121,7 @@ loader.help: help.common help.mips
cat ${.ALLSRC} | \
awk -f ${.CURDIR}/../../../common/merge_help.awk ${.TARGET}
+.PATH: ${.CURDIR}/../../../forth
.include ${.CURDIR}/../../forth/Makefile.inc
.if !exists(${DESTDIR}/boot/loader.rc)
Modified: head/sys/boot/pc98/loader/Makefile
==
--- head/sys/boot/pc98/loader/Makefile Thu Apr 2 23:12:18 2015
(r281008)
+++ head/sys/boot/pc98/loader/Makefile Fri Apr 3 02:27:40 2015
(r281009)
@@ -86,6 +86,7 @@ FILES=${LOADER}
# XXX INSTALLFLAGS_loader= -b
FILESMODE_${LOADER}= ${BINMODE} -b
+.PATH: ${.CURDIR}/../../forth
.include ${.CURDIR}/../../forth/Makefile.inc
.if !exists(${DESTDIR}/boot/loader.rc)
Modified: head/sys/boot/powerpc/kboot/Makefile
==
--- head/sys/boot/powerpc/kboot/MakefileThu Apr 2 23:12:18 2015
(r281008)
+++ head/sys/boot/powerpc/kboot/MakefileFri Apr 3 02:27:40 2015
(r281009)
@@ -113,6 +113,7 @@ loader.help: help.common help.kboot ${.C
cat ${.ALLSRC} | \
awk -f ${.CURDIR}/../../common/merge_help.awk ${.TARGET}
+.PATH: ${.CURDIR}/../../forth
.include ${.CURDIR}/../../forth/Makefile.inc
.if !exists(${DESTDIR}/boot/loader.rc)
Modified: head/sys/boot/powerpc/ofw/Makefile
==
--- head/sys/boot/powerpc/ofw/Makefile Thu Apr 2 23:12:18 2015
(r281008)
+++ head/sys/boot/powerpc/ofw/Makefile Fri Apr 3 02:27:40 2015
(r281009)
@@ -108,6 +108,7 @@ loader.help: help.common help.ofw ${.CUR
cat ${.ALLSRC} | \
awk -f ${.CURDIR}/../../common/merge_help.awk ${.TARGET}
+.PATH: ${.CURDIR}/../../forth
.include ${.CURDIR}/../../forth/Makefile.inc
.if !exists(${DESTDIR}/boot/loader.rc)
Modified: head/sys/boot/sparc64/loader/Makefile
==
--- head/sys/boot/sparc64/loader/Makefile Thu Apr 2 23:12:18 2015
(r281008)
+++ head/sys/boot/sparc64/loader/Makefile Fri Apr 3 02:27:40 2015
(r281009)
@@ -95,6 +95,7 @@ loader.help: help.common help.sparc64
cat ${.ALLSRC} | \
awk -f ${.CURDIR}/../../common/merge_help.awk ${.TARGET}
+.PATH: ${.CURDIR}/../../forth
.include ${.CURDIR}/../../forth/Makefile.inc
.if !exists(${DESTDIR}/boot/loader.rc)
___
svn-src-all@freebsd.org mailing list
svn commit: r281011 - head/sys/boot/powerpc/ps3
Author: jkim
Date: Fri Apr 3 02:37:43 2015
New Revision: 281011
URL: https://svnweb.freebsd.org/changeset/base/281011
Log:
Fix powerpc/ps3 build, too.
Modified:
head/sys/boot/powerpc/ps3/Makefile
Modified: head/sys/boot/powerpc/ps3/Makefile
==
--- head/sys/boot/powerpc/ps3/Makefile Fri Apr 3 02:31:59 2015
(r281010)
+++ head/sys/boot/powerpc/ps3/Makefile Fri Apr 3 02:37:43 2015
(r281011)
@@ -110,6 +110,7 @@ loader.help: help.common help.ps3 ${.CUR
cat ${.ALLSRC} | \
awk -f ${.CURDIR}/../../common/merge_help.awk ${.TARGET}
+.PATH: ${.CURDIR}/../../forth
.include ${.CURDIR}/../../forth/Makefile.inc
.if !exists(${DESTDIR}/boot/loader.rc)
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
svn commit: r281008 - head/sys/dev/ciss
Author: peter
Date: Thu Apr 2 23:12:18 2015
New Revision: 281008
URL: https://svnweb.freebsd.org/changeset/base/281008
Log:
Remove redundant mtx_lock/unlock in ciss_name_device. This is a guaranteed
insta-panic on device add/remove. This is only called from the notify
thread which already holds the lock while calling this function.
Modified:
head/sys/dev/ciss/ciss.c
Modified: head/sys/dev/ciss/ciss.c
==
--- head/sys/dev/ciss/ciss.cThu Apr 2 22:42:23 2015(r281007)
+++ head/sys/dev/ciss/ciss.cThu Apr 2 23:12:18 2015(r281008)
@@ -3438,11 +3438,9 @@ ciss_name_device(struct ciss_softc *sc,
target, 0);
if (status == CAM_REQ_CMP) {
- mtx_lock(sc-ciss_mtx);
xpt_path_lock(path);
periph = cam_periph_find(path, NULL);
xpt_path_unlock(path);
- mtx_unlock(sc-ciss_mtx);
xpt_free_path(path);
if (periph != NULL) {
sprintf(sc-ciss_logical[bus][target].cl_name, %s%d,
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
Re: svn commit: r280971 - in head: contrib/ipfilter/tools share/man/man4 sys/contrib/ipfilter/netinet sys/netinet sys/netipsec sys/netpfil/pf
On 04/02/15 23:20, Robert N. M. Watson wrote: On 2 Apr 2015, at 21:54, Hans Petter Selasky h...@selasky.org wrote: I see from the code that if two frags have the same IP offset, the whole fragment list gets dropped, unless the IP payload is zero bytes long. Maybe a last variable should be added? Hi Robert, Are you solving an actual problem you've observed, or is this a speculative proposal? Yes, I saw in the FreeBSD network code that fragments having IP payload 8 are not allowed, after writing this e-mail. I think you would benefit a great deal from reading Stevens Volume I (second edition) before proceeding with further changes to the TCP/IP code stack. I will order and read this book eventually. I appreciate your tip. I would like have a comment on one final issue about the IP ID field. Given two [small] prime numbers: P and Q Assume you have a firewall that separate two networks, called A and B, that are not allowed to communicate. In network A an application pings the firewall and sees the IP ID field changing P steps. In network B an application pings the firewall and sees the IP ID field changing Q steps. If the application in network A always see that the IP ID field is changing P steps, it knows the application in network B did not send any packets. If the application in network B always see that the IP ID field is changing Q steps, it knows the application in network A did not send any packets. Detecting sending and not sending packets can be used as a way of reliable duplex binary communication. I think the current and past implementation of the IP ID field in FreeBSD can be used to leak information between networks, or am I totally wrong? As long as the IP ID counters are shared between two or more secured networks, there will be a problem. Something along the lines of D2211 might be a way to solve such an information leak without too much overhead! --HPS ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
svn commit: r281007 - head/games/fortune/tools
Author: eadler
Date: Thu Apr 2 22:42:23 2015
New Revision: 281007
URL: https://svnweb.freebsd.org/changeset/base/281007
Log:
fortune/tools/do_uniq.py
slight imporvements to do_uniq.py:
- use with open()
- don't depend on sys.argv directly
- fix style
Modified:
head/games/fortune/tools/do_uniq.py
Modified: head/games/fortune/tools/do_uniq.py
==
--- head/games/fortune/tools/do_uniq.py Thu Apr 2 21:55:03 2015
(r281006)
+++ head/games/fortune/tools/do_uniq.py Thu Apr 2 22:42:23 2015
(r281007)
@@ -4,7 +4,8 @@
#
# an aggressive little script for trimming duplicate cookies
-import re, sys
+import argparse
+import re
wordlist = [
'hadnot',
@@ -15,6 +16,7 @@ wordlist = [
'a', 'd', 'i', 'm', 's',
]
+
def hash(fortune):
f = fortune
f = f.lower()
@@ -27,37 +29,40 @@ def hash(fortune):
#f = f[-30:]
return f
+
def edit(datfile):
dups = {}
fortunes = []
fortune =
-for line in file(datfile):
-if line == %\n:
-key = hash(fortune)
-if key not in dups:
-dups[key] = []
-dups[key].append(fortune)
-fortunes.append(fortune)
-fortune =
-else:
-fortune += line
+with open(datfile, r) as datfiledf:
+for line in datfiledf:
+if line == %\n:
+key = hash(fortune)
+if key not in dups:
+dups[key] = []
+dups[key].append(fortune)
+fortunes.append(fortune)
+fortune =
+else:
+fortune += line
for key in list(dups.keys()):
if len(dups[key]) == 1:
del dups[key]
-o = file(datfile + '~', w)
-for fortune in fortunes:
-key = hash(fortune)
-if key in dups:
-print('\n' * 50)
-for f in dups[key]:
-if f != fortune:
-print(f, '%')
-print(fortune, '%')
-if input(Remove last fortune? ) == 'y':
-del dups[key]
-continue
-o.write(fortune + %\n)
-o.close()
+with open(datfile + ~, w) as o:
+for fortune in fortunes:
+key = hash(fortune)
+if key in dups:
+print('\n' * 50)
+for f in dups[key]:
+if f != fortune:
+print(f, '%')
+print(fortune, '%')
+if input(Remove last fortune? ) == 'y':
+del dups[key]
+continue
+o.write(fortune + %\n)
-assert len(sys.argv) == 2
-edit(sys.argv[1])
+parser = argparse.ArgumentParser(description=trimming duplicate cookies)
+parser.add_argument(filename, type=str, nargs=1)
+args = parser.parse_args()
+edit(args.filename[0])
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
Re: svn commit: r281004 - in head/lib/libc: arm/sys mips/sys powerpc powerpc/sys powerpc64 powerpc64/sys sparc64 sparc64/sys sys
On Thu, 2 Apr 2015, Ed Maste wrote:
Log:
libc: Eliminate duplicate copies of __vdso_gettc.c
...
Modified: head/lib/libc/arm/sys/Makefile.inc
==
--- head/lib/libc/arm/sys/Makefile.inc Thu Apr 2 20:14:51 2015
(r281003)
+++ head/lib/libc/arm/sys/Makefile.inc Thu Apr 2 21:18:11 2015
(r281004)
@@ -1,6 +1,6 @@
# $FreeBSD$
-SRCS+= __vdso_gettc.c
+SRCS+= trivial-vdso_tc.c
The new file name is much worse than the old one.
The old one was too long. It didn't even match the name of the single
function that it implements, since it implements several functions. It
has excessive leading underscores. Leading underscores are sometimes
needed in function names to keep them out of the application namespace,
or just to keep layers of them separate, but the equivalent is rarely
needed for function names.
libc previously had just 26 file names with 2 leading underscores.
Almost 1/3 of them for __vdso*:
X ./powerpc64/sys/__vdso_gettc.c
X ./sys/__vdso_gettimeofday.c
X ./sys/__error.c
X ./i386/sys/__vdso_gettc.c
X ./iconv/__iconv_free_list.c
X ./iconv/__iconv.c
X ./iconv/__iconv_get_list.3
X ./iconv/__iconv_get_list.c
X ./arm/gen/__aeabi_read_tp.S
X ./arm/sys/__vdso_gettc.c
X ./sparc64/sys/__sparc_utrap_fp_disabled.S
X ./sparc64/sys/__sparc_sigtramp_setup.c
X ./sparc64/sys/__sparc_utrap_setup.c
X ./sparc64/sys/__sparc_utrap_emul.c
X ./sparc64/sys/__sparc_utrap_install.c
X ./sparc64/sys/__vdso_gettc.c
X ./sparc64/sys/__sparc_utrap_private.h
X ./sparc64/sys/__sparc_utrap_align.c
X ./sparc64/sys/__sparc_utrap.c
X ./sparc64/sys/__sparc_utrap_gen.S
X ./amd64/sys/__vdso_gettc.c
X ./mips/sys/__vdso_gettc.c
X ./gen/__pthread_mutex_init_calloc_cb_stub.c
X ./gen/__xuname.c
X ./gen/__getosreldate.c
X ./powerpc/sys/__vdso_gettc.c
Another 1/3 of these are probably externally-imposed (the sparc64 trap
ones).
The sparc64 names are disgustingly verbose, but not nearly as bad as
the internal spam __pthread_mutex_init_calloc_cb_stub.c (37 characters).
This file contains a single stub function with a not quite equally
bad name. The file name doesn't even match the function name -- the
function name only has 1 leading underscore.
FreeBSD ls -C handles long names especially badly. It uses a tabbed
format with all columns wide enough for the widest file name. 37
is barely less than 40, so it only reduces the number of columns to
2 on terminals of width 80-119. gnu ls aligns to non-tab boundaries
and uses variable-width columns. 1 long file name only bloats the
column that it is in. For more normal short file names (not longer
than 15, with an average of less than 8 from good names like cp),
FreeBSD ls -C always gives 5 columns of width 16 each on an 80-column
terminal, while gnu ls -C usually gives 8-10. The densely packed names
can be hard to read, but not as bad as ones that scroll off due to
the low density.
The new name removes the double underscores. Good, but now it doesn't
match the name of even one of the functions in it.
trivial in the new name doesn't describe what it does. It is not a
trivial (simple) implementation of the functions in it, but a stub
(non-functional) implementation of these functions. Though disgusting,
the name __pthread_mutex_init_calloc_cb_stub.c at least says stub
instead of trivial.
In BSD, words in file names are conventionally separated by underscores.
The new name separates one pair of words with a hyphen instead. This is
gnu-style. A case can be made for using underscores to echo function
names that have them and hyphens for everything else, to keep these
splittings separate. But function names shouldn't be echoed in file
names anyway. Echoing is only possible when the file implements only
a single function (unless you want to make the file name even more
disgusting by making it the concatenation of all the function names,
with exceptions only when the length of this exceeds {NAME_MAX}.
Previously, only 44 names in libc had a hyphen (581 had an underscore):
X ./stdio/printf-pos.c
X ./powerpc64/softfloat/powerpc-gcc.h
X ./iconv/iconv-internal.h
X ./tests/Makefile.netbsd-tests
X ./arm/softfloat/arm-gcc.h
X ./db/mpool/mpool-compat.c
X ./mips/softfloat/mips-gcc.h
X ./gen/trivial-getcontextx.c
X ./gen/fts-compat.h
X ./gen/gen-private.h
X ./gen/fts-compat.c
X ./gen/unvis-compat.c
X ./include/un-namespace.h
X ./compat-43
X ./powerpc/softfloat/powerpc-gcc.h
X ./softfloat/softfloat-for-gcc.h
X ./softfloat/softfloat-specialize
X ./softfloat/templates/softfloat-specialize
X ./softfloat/softfloat-source.txt
X ./softfloat/bits64/softfloat-macros
X ./softfloat/bits32/softfloat-macros
X ./softfloat/softfloat-history.txt
X ./nls/mn_MN.UTF-8.msg
X ./nls/pl_PL.ISO8859-2.msg
X ./nls/ca_ES.ISO8859-1.msg
X ./nls/ru_RU.KOI8-R.msg
X ./nls/nl_NL.ISO8859-1.msg
X ./nls/el_GR.ISO8859-7.msg
X ./nls/it_IT.ISO8859-15.msg
X ./nls/fr_FR.ISO8859-1.msg
X ./nls/gl_ES.ISO8859-1.msg
X ./nls/sk_SK.ISO8859-2.msg
X
svn commit: r281010 - head/sys/boot/mips/beri/loader
Author: jkim
Date: Fri Apr 3 02:31:59 2015
New Revision: 281010
URL: https://svnweb.freebsd.org/changeset/base/281010
Log:
Fix mips build, really. :-(
Modified:
head/sys/boot/mips/beri/loader/Makefile
Modified: head/sys/boot/mips/beri/loader/Makefile
==
--- head/sys/boot/mips/beri/loader/Makefile Fri Apr 3 02:27:40 2015
(r281009)
+++ head/sys/boot/mips/beri/loader/Makefile Fri Apr 3 02:31:59 2015
(r281010)
@@ -122,7 +122,7 @@ loader.help: help.common help.mips
awk -f ${.CURDIR}/../../../common/merge_help.awk ${.TARGET}
.PATH: ${.CURDIR}/../../../forth
-.include ${.CURDIR}/../../forth/Makefile.inc
+.include ${.CURDIR}/../../../forth/Makefile.inc
.if !exists(${DESTDIR}/boot/loader.rc)
FILES+= loader.rc
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
Re: svn commit: r281004 - in head/lib/libc: arm/sys mips/sys powerpc powerpc/sys powerpc64 powerpc64/sys sparc64 sparc64/sys sys
On 2 April 2015 at 19:54, Bruce Evans b...@optusnet.com.au wrote: On Thu, 2 Apr 2015, Ed Maste wrote: Log: libc: Eliminate duplicate copies of __vdso_gettc.c ... Modified: head/lib/libc/arm/sys/Makefile.inc == --- head/lib/libc/arm/sys/Makefile.inc Thu Apr 2 20:14:51 2015 (r281003) +++ head/lib/libc/arm/sys/Makefile.inc Thu Apr 2 21:18:11 2015 (r281004) @@ -1,6 +1,6 @@ # $FreeBSD$ -SRCS+= __vdso_gettc.c +SRCS+= trivial-vdso_tc.c The new file name is much worse than the old one. [snip] I'm happy to rename it if you have a suggestion. ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
svn commit: r280986 - head/sys/arm/arm
Author: andrew Date: Thu Apr 2 12:58:04 2015 New Revision: 280986 URL: https://svnweb.freebsd.org/changeset/base/280986 Log: We may not be using gcc to compile this. Sponsored by: The FreeBSD Foundation Modified: head/sys/arm/arm/generic_timer.c Modified: head/sys/arm/arm/generic_timer.c == --- head/sys/arm/arm/generic_timer.cThu Apr 2 12:56:06 2015 (r280985) +++ head/sys/arm/arm/generic_timer.cThu Apr 2 12:58:04 2015 (r280986) @@ -353,7 +353,7 @@ DELAY(int usec) for (; usec 0; usec--) for (counts = 200; counts 0; counts--) /* -* Prevent gcc from optimizing +* Prevent the compiler from optimizing * out the loop */ cpufunc_nullop(); ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
svn commit: r280987 - head/sys/arm/arm
Author: andrew Date: Thu Apr 2 13:02:25 2015 New Revision: 280987 URL: https://svnweb.freebsd.org/changeset/base/280987 Log: Stop including machine/fdt.h, it's not needed. Sponsored by: The FreeBSD Foundation Modified: head/sys/arm/arm/generic_timer.c Modified: head/sys/arm/arm/generic_timer.c == --- head/sys/arm/arm/generic_timer.cThu Apr 2 12:58:04 2015 (r280986) +++ head/sys/arm/arm/generic_timer.cThu Apr 2 13:02:25 2015 (r280987) @@ -57,7 +57,6 @@ __FBSDID($FreeBSD$); #include dev/ofw/ofw_bus_subr.h #include machine/bus.h -#include machine/fdt.h #defineGT_CTRL_ENABLE (1 0) #defineGT_CTRL_INT_MASK(1 1) ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
svn commit: r280984 - head/usr.bin/iscsictl
Author: trasz
Date: Thu Apr 2 11:52:34 2015
New Revision: 280984
URL: https://svnweb.freebsd.org/changeset/base/280984
Log:
Add IPv6 example to iscsi.conf(5) and tweak ordering.
MFC after:1 month
Sponsored by: The FreeBSD Foundation
Modified:
head/usr.bin/iscsictl/iscsi.conf.5
Modified: head/usr.bin/iscsictl/iscsi.conf.5
==
--- head/usr.bin/iscsictl/iscsi.conf.5 Thu Apr 2 11:41:04 2015
(r280983)
+++ head/usr.bin/iscsictl/iscsi.conf.5 Thu Apr 2 11:52:34 2015
(r280984)
@@ -95,14 +95,14 @@ or
.Qq Ar CRC32C .
Default is
.Qq Ar None .
-.It Cm TargetName
-Sets the target name.
-Not required for discovery sessions.
.It Cm InitiatorName
Sets the initiator name.
By default, the name is concatenation of
.Qq Ar iqn.1994-09.org.freebsd:
with the hostname.
+.It Cm TargetName
+Sets the target name.
+Not required for discovery sessions.
.It Cm TargetAddress
Sets the target address and port, in
.Sy address[:port]
@@ -140,6 +140,12 @@ myiscsi { # nickname
targetaddress = iscsi1
targetname= iqn.1900.com.com:sn.123456
}
+
+myiscsi6 { # nickname
+ targetaddress = [2001:db8::de:ef]:3260
+ targetname= iqn.1900.com.com:sn.123456
+}
+
chaptest {
targetaddress = 10.0.0.1;
targetname= iqn.1900.com.com:sn.123456;
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
svn commit: r280981 - head/sys/compat/linprocfs
Author: trasz
Date: Thu Apr 2 10:19:24 2015
New Revision: 280981
URL: https://svnweb.freebsd.org/changeset/base/280981
Log:
Remove unused code.
Differential Revision:https://reviews.freebsd.org/D2195
Reviewed by: kib@, imp@
MFC after:1 month
Sponsored by: The FreeBSD Foundation
Modified:
head/sys/compat/linprocfs/linprocfs.c
Modified: head/sys/compat/linprocfs/linprocfs.c
==
--- head/sys/compat/linprocfs/linprocfs.c Thu Apr 2 06:58:17 2015
(r280980)
+++ head/sys/compat/linprocfs/linprocfs.c Thu Apr 2 10:19:24 2015
(r280981)
@@ -394,7 +394,6 @@ linprocfs_domtab(PFS_FILL_ARGS)
/*
* Filler function for proc/partitions
- *
*/
static int
linprocfs_dopartitions(PFS_FILL_ARGS)
@@ -402,27 +401,9 @@ linprocfs_dopartitions(PFS_FILL_ARGS)
struct g_class *cp;
struct g_geom *gp;
struct g_provider *pp;
- struct nameidata nd;
- const char *lep;
- char *dlep, *flep;
- size_t lep_len;
- int error;
int major, minor;
- /* resolve symlinks etc. in the emulation tree prefix */
- NDINIT(nd, LOOKUP, FOLLOW, UIO_SYSSPACE, linux_emul_path, td);
- flep = NULL;
- error = namei(nd);
- lep = linux_emul_path;
- if (error == 0) {
- if (vn_fullpath(td, nd.ni_vp, dlep, flep) == 0)
- lep = dlep;
- vrele(nd.ni_vp);
- }
- lep_len = strlen(lep);
-
g_topology_lock();
- error = 0;
sbuf_printf(sb, major minor #blocks name rio rmerge rsect
ruse wio wmerge wsect wuse running use aveq\n);
@@ -448,8 +429,7 @@ linprocfs_dopartitions(PFS_FILL_ARGS)
}
g_topology_unlock();
- free(flep, M_TEMP);
- return (error);
+ return (0);
}
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
Re: svn commit: r280955 - in head/sys: modules/notrandom dev/notrandom
On Wed, Apr 01, 2015 at 11:11:11AM -0700, Jordan Hubbard wrote: On Apr 1, 2015, at 11:04 AM, David Chisnall thera...@freebsd.org wrote: On 1 Apr 2015, at 18:41, Mateusz Guzik mjgu...@gmail.com wrote: I guess you were right, this was bad. I moved the implementation to null.c, I hope this makes everyone happy. https://lists.freebsd.org/pipermail/svn-src-all/2015-April/101876.html This almost certainly does not make people happy: “FreeBSD: Where even April 1st gets a good bike-shedding!” I, personally, am disappointed the 3 BSDs did not merge again this year. Now one has to wonder how obnoxious one has to get so that people think this can't be real. I tried really hard. :) -- Mateusz Guzik mjguzik gmail.com ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
svn commit: r280982 - head/usr.bin/iscsictl
Author: trasz
Date: Thu Apr 2 11:18:43 2015
New Revision: 280982
URL: https://svnweb.freebsd.org/changeset/base/280982
Log:
Rewrite iscsi.conf(5) to better match iscsictl(8).
MFC after:1 month
Sponsored by: The FreeBSD Foundation
Modified:
head/usr.bin/iscsictl/iscsi.conf.5
Modified: head/usr.bin/iscsictl/iscsi.conf.5
==
--- head/usr.bin/iscsictl/iscsi.conf.5 Thu Apr 2 10:19:24 2015
(r280981)
+++ head/usr.bin/iscsictl/iscsi.conf.5 Thu Apr 2 11:18:43 2015
(r280982)
@@ -24,132 +24,111 @@
.\
.\ $FreeBSD$
.\
-.Dd February 4, 2015
+.Dd April 2, 2015
.Dt ISCSI.CONF 5
.Os
.Sh NAME
.Nm iscsi.conf
.Nd iSCSI initiator configuration file
.Sh DESCRIPTION
-The file
-.Nm ,
-is used by the
+The
+.Nm
+configuration file is used by the
.Xr iscsictl 8
and
.Xr iscontrol 8
utilities.
-It contains declarations and parameter/key-options.
-The syntax is very simple,
-.D1 Li variable = value;
-and they can be grouped via a
-.Em block
-declaration:
+The general syntax is:
.Bf Li
.Bd -literal
# this is a comment
- target_1 { # nickname
+ nickname_1 {
variable = value;
...
- } # this must be on a line by itself.
+ }
+ nickname_2 {
+ variable = value;
+ ...
+ }
+ ...
.Ed
.Ef
-.Pp
-The following are specified in the iSCSI RFC 3720,
-for a full description see sections 11/12 of the RFC.
.Bl -tag -width MaxConnections
.It Cm AuthMethod
-currently only supported authentication method is CHAP, with
-digest either MD5 or SHA.
-Default is none.
+Sets the authentication type.
+Type can be either
+.Qq Ar None ,
+or
+.Qq Ar CHAP .
+Default is
+.Qq Ar None .
+When set to
+.Cm CHAP ,
+both
+.Cm chapIName
+and
+.Cm chapSecret
+must be defined.
+.It Cm chapIName
+Login for CHAP authentication.
+.It Cm chapSecret
+Secret for CHAP authentication.
+.It Cm tgtChapName
+Target login for Mutual CHAP authentication.
+.It Cm tgtChapSecret
+Target secret for Mutual CHAP authentication.
.It Cm HeaderDigest
-a
-.Em digest
-is calculated on the header of all iSCSI PDUs, and
-checked.
-Only CRC32C is implemented.
-Default is none.
+Sets the header digest; a checksum calculated over the header of iSCSI
+PDUs, and verified on receive.
+Digest can be either
+.Qq Ar None ,
+or
+.Qq Ar CRC32C .
+Default is
+.Qq Ar None .
.It Cm DataDigest
-same as for HeaderDigest, but on the data part of the iSCSI PDU.
-(not yet tested)
+Sets the data digest; a checksum calculated over the Data Section of iSCSI
+PDUs, and verified on receive.
+Digest can be either
+.Qq Ar None ,
+or
+.Qq Ar CRC32C .
+Default is
+.Qq Ar None .
.It Cm TargetName
-is the name by which the target is known, not to be confused with
-target address, either obtained via the target administrator, or
-from a
-.Em discovery session .
+Sets the target name.
+Not required for discovery sessions.
.It Cm InitiatorName
-if not specified, defaults to
-.Sy iqn.2005-01.il.ac.huji.cs:
-.Aq hostname .
+Sets the initiator name.
+By default, the name is concatenation of
+.Qq Ar iqn.1994-09.org.freebsd:
+with the hostname.
.It Cm TargetAddress
-is of the form
-.Sy domainname[:port][,portal-group-tag]
-to quote the RFC:
-.Bd -ragged -compact
-The domainname can be specified as either a DNS host name, a
-dotted-decimal IPv4 address, or a bracketed IPv6 address as specified
-in [RFC2732].
-.Ed
-Note: portal-group-tag is unused at the moment.
-.Em not implemented yet.
-.It Cm MaxRecvDataSegmentLength
-the maximum data segment length in
-bytes it can receive in an iSCSI PDU, default is 8192.
-.It Cm MaxOutstandingR2T
-is used to calculate/negotiate the
-.Em tag opening ,
-can be overridden by the
-.Sy tag
-option.
+Sets the target address and port, in
+.Sy address[:port]
+format.
+The
+.Sy address
+can be either an IP address, or hostname.
+The optional port defaults to 3260.
.It Cm SessionType
-either Discovery or Normal, default is Normal, see the
-.Fl d
-flag of
-.Cm iscontrol .
-.El
-.sp
-The following are not specified in the
-.Sy RFC 3720
-.Bl -tag -width sockbufsize
-.It Cm offload
+Sets the session type.
+Type can be either
+.Qq Ar Discovery ,
+or
+.Qq Ar Normal .
+Default is
+.Qq Ar Normal .
+For normal sessions, the
+.Sy TargetName
+must be defined.
+Discovery sessions result in the initiator connecting to all the targets
+returned by SendTargets iSCSI discovery with the defined
+.Sy TargetAddress .
+.It Cm Offload
Name of selected iSCSI hardware offload driver.
-.It Cm port
-The iSCSI port used by the iSCSI protocol, defaults to 3260.
-.It Cm tags
-Sets the
-.Em tag opening
-to the value specified.
-.It Cm maxluns
-overrides the compiled value of
-.Sy luns ,
-see
-.Xr iscsi_initiator 4 .
-This value can only be reduced.
-.It Cm sockbufsize
-sets the receiver and transmitter socket buffer size to
-.Em size ,
-in kilobytes.
-The default is 128.
-.El
-.sp
-If
-.Em AuthMethod
-is set to
-.Cm
Re: svn commit: r280955 - in head/sys: modules/notrandom dev/notrandom
On 2 Apr 2015, at 11:22, Mateusz Guzik mjgu...@gmail.com wrote: Now one has to wonder how obnoxious one has to get so that people think this can't be real. I tried really hard. :) Not sure about your locale, but here (where the tradition originated) if you fool someone in the morning then they are an April Fool, if you attempt to fool them in the afternoon then you are the April Fool. Your mail was timestamped 12:36 (ah, the perils of time zones...), though looking back at it I do rather like the commit time: Date: Wed Apr 1 13:37:00 2015 David (Blaming illness for not spotting the joke) ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
Re: svn commit: r280972 - head/sys/netinet
On Thu, Apr 02, 2015 at 12:30:54AM +, Bjoern A. Zeeb wrote: B Author: bz B Date: Thu Apr 2 00:30:53 2015 B New Revision: 280972 B URL: https://svnweb.freebsd.org/changeset/base/280972 B B Log: B Try to unbreak the build after r280971 by providing the missing B #include header for SYSINIT. Hmm, I wonder what wasn't it required for amd64... -- Totus tuus, Glebius. ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
svn commit: r280985 - in head/sys/arm: arm include
Author: andrew
Date: Thu Apr 2 12:56:06 2015
New Revision: 280985
URL: https://svnweb.freebsd.org/changeset/base/280985
Log:
Add the generic timer registers to sysreg.h and cpu-v6.h, and use the
access functions in the generic timer driver.
Differential Revision:https://reviews.freebsd.org/D2198
Sponsored by: The FreeBSD Foundation
Modified:
head/sys/arm/arm/generic_timer.c
head/sys/arm/include/cpu-v6.h
head/sys/arm/include/sysreg.h
Modified: head/sys/arm/arm/generic_timer.c
==
--- head/sys/arm/arm/generic_timer.cThu Apr 2 11:52:34 2015
(r280984)
+++ head/sys/arm/arm/generic_timer.cThu Apr 2 12:56:06 2015
(r280985)
@@ -105,12 +105,7 @@ static struct timecounter arm_tmr_timeco
static int
get_freq(void)
{
- uint32_t val;
-
- /* cntfrq */
- __asm volatile(mrc p15, 0, %0, c14, c0, 0 : =r (val));
-
- return (val);
+ return (cp15_cntfrq_get());
}
static long
@@ -120,11 +115,9 @@ get_cntxct(bool physical)
isb();
if (physical)
- /* cntpct */
- __asm volatile(mrrc p15, 0, %Q0, %R0, c14 : =r (val));
+ val = cp15_cntpct_get();
else
- /* cntvct */
- __asm volatile(mrrc p15, 1, %Q0, %R0, c14 : =r (val));
+ val = cp15_cntvct_get();
return (val);
}
@@ -134,13 +127,9 @@ set_ctrl(uint32_t val, bool physical)
{
if (physical)
- /* cntp_ctl */
- __asm volatile(mcr p15, 0, %[val], c14, c2, 1 : :
- [val] r (val));
+ cp15_cntp_ctl_set(val);
else
- /* cntv_ctl */
- __asm volatile(mcr p15, 0, %[val], c14, c3, 1 : :
- [val] r (val));
+ cp15_cntv_ctl_set(val);
isb();
return (0);
@@ -151,13 +140,9 @@ set_tval(uint32_t val, bool physical)
{
if (physical)
- /* cntp_tval */
- __asm volatile(mcr p15, 0, %[val], c14, c2, 0 : :
- [val] r (val));
+ cp15_cntp_tval_set(val);
else
- /* cntv_tval */
- __asm volatile(mcr p15, 0, %[val], c14, c3, 0 : :
- [val] r (val));
+ cp15_cntv_tval_set(val);
isb();
return (0);
@@ -169,11 +154,9 @@ get_ctrl(bool physical)
uint32_t val;
if (physical)
- /* cntp_ctl */
- __asm volatile(mrc p15, 0, %0, c14, c2, 1 : =r (val));
+ val = cp15_cntp_ctl_get();
else
- /* cntv_ctl */
- __asm volatile(mrc p15, 0, %0, c14, c3, 1 : =r (val));
+ val = cp15_cntv_ctl_get();
return (val);
}
@@ -183,10 +166,10 @@ disable_user_access(void)
{
uint32_t cntkctl;
- __asm volatile(mrc p15, 0, %0, c14, c1, 0 : =r (cntkctl));
+ cntkctl = cp15_cntkctl_get();
cntkctl = ~(GT_CNTKCTL_PL0PTEN | GT_CNTKCTL_PL0VTEN |
GT_CNTKCTL_EVNTEN | GT_CNTKCTL_PL0VCTEN | GT_CNTKCTL_PL0PCTEN);
- __asm volatile(mcr p15, 0, %0, c14, c1, 0 : : r (cntkctl));
+ cp15_cntkctl_set(cntkctl);
isb();
}
Modified: head/sys/arm/include/cpu-v6.h
==
--- head/sys/arm/include/cpu-v6.h Thu Apr 2 11:52:34 2015
(r280984)
+++ head/sys/arm/include/cpu-v6.h Thu Apr 2 12:56:06 2015
(r280985)
@@ -54,6 +54,15 @@ fname(void)
\
return(reg);\
}
+#define _R64F0(fname, aname) \
+static __inline uint64_t \
+fname(void)\
+{ \
+ uint64_t reg; \
+ __asm __volatile(mrrc\t _FX(aname): =r (reg)); \
+ return(reg);\
+}
+
#define _WF0(fname, aname...) \
static __inline void \
fname(void)\
@@ -68,6 +77,13 @@ fname(register_t reg)
\
__asm __volatile(mcr\t _FX(aname):: r (reg)); \
}
+#define _W64F1(fname, aname...)
\
+static __inline void \
+fname(uint64_t reg)\
+{ \
+ __asm __volatile(mcrr\t _FX(aname):: r
svn commit: r280983 - head/lib/libc/sys
Author: trasz Date: Thu Apr 2 11:41:04 2015 New Revision: 280983 URL: https://svnweb.freebsd.org/changeset/base/280983 Log: Update open(2) to make it more obvious that O_NOCTTY and O_TTY_INIT are ignored. MFC after:1 month Sponsored by: The FreeBSD Foundation Modified: head/lib/libc/sys/open.2 Modified: head/lib/libc/sys/open.2 == --- head/lib/libc/sys/open.2Thu Apr 2 11:18:43 2015(r280982) +++ head/lib/libc/sys/open.2Thu Apr 2 11:41:04 2015(r280983) @@ -28,7 +28,7 @@ .\ @(#)open.2 8.2 (Berkeley) 11/16/93 .\ $FreeBSD$ .\ -.Dd February 7, 2013 +.Dd April 2, 2015 .Dt OPEN 2 .Os .Sh NAME @@ -115,8 +115,8 @@ O_DIRECTeliminate or reduce cache effec O_FSYNCsynchronous writes O_SYNC synchronous writes O_NOFOLLOW do not follow symlinks -O_NOCTTY don't assign controlling terminal -O_TTY_INIT restore default terminal attributes +O_NOCTTY ignored +O_TTY_INIT ignored O_DIRECTORYerror if file is not a directory O_CLOEXEC set FD_CLOEXEC upon open .Ed ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
Re: svn commit: r280971 - in head: contrib/ipfilter/tools share/man/man4 sys/contrib/ipfilter/netinet sys/netinet sys/netipsec sys/netpfil/pf
On Wed, Apr 01, 2015 at 05:07:56PM -0600, Ian Lepore wrote:
I Author: glebius
I Date: Wed Apr 1 22:26:39 2015
I New Revision: 280971
I URL: https://svnweb.freebsd.org/changeset/base/280971
I
I Log:
Io Use new function ip_fillid() in all places throughout the kernel,
I where we want to create a new IP datagram.
Io Add support for RFC6864, which allows to set IP ID for atomic IP
I datagrams to any value, to improve performance. The behaviour is
I controlled by net.inet.ip.rfc6864 sysctl knob, which is enabled by
I default.
Io In case if we generate IP ID, use counter(9) to improve performance.
Io Gather all code related to IP ID into ip_id.c.
I
IDifferential Revision: https://reviews.freebsd.org/D2177
IReviewed by: adrian, cy, rpaulo
ITested by: Emeric POUPON emeric.poupon
stormshield.eu
ISponsored by:Netflix
ISponsored by:Nginx, Inc.
IRelnotes:yes
I
I [...]
I +void
I +ip_fillid(struct ip *ip)
I +{
I +
I + /*
I + * Per RFC6864 Section 4
I + *
I + * o Atomic datagrams: (DF==1) (MF==0) (frag_offset==0)
I + * o Non-atomic datagrams: (DF==0) || (MF==1) || (frag_offset0)
I + */
I + if (V_ip_rfc6864 (ip-ip_off htons(IP_DF)) == htons(IP_DF))
I + ip-ip_id = 0;
I + else if (V_ip_do_randomid)
I + ip-ip_id = ip_randomid();
I + else {
I + counter_u64_add(V_ip_id, 1);
I + ip-ip_id = htons((*(uint64_t *)zpcpu_get(V_ip_id)) 0x);
I + }
I +}
I +
I
I This is completely bogus. It's a big opacity violation (it relies on
I what should be opaque private internal implementation details of
I counter(9)). The fact that the counter api doesn't provide a function
I for retrieving one cpu's counter value should be a big clue there -- the
I fact that you know the internals doesn't make it okay to reach behind
I the counter and grab a value like that. It may not even be safe to do
I so on any given architecture; it certainly isn't safe on arm, and that
I line of code above will work only by accident because you're throwing
I way all but 16 bits.
I though about providing that API, but since it isn't safe in general,
I decided to not do that.
I But even more importantly, this WILL result in multiple threads using
I the same value at the same time...
I
I - Thread A on CPU 1 and thread B on CPU 2 both begin executing here at
I the same time, and both get through counter_u64_add().
I - Thread A keeps running and uses CPU 1's new value, call it 27.
I - Thread B gets prempted between counter_u64_add() and zpcpu_get().
I When it resumes it's now on CPU 1, so it retrieves value 27 as well.
This was already discussed in this thread:
https://lists.freebsd.org/pipermail/svn-src-head/2015-March/069864.html
--
Totus tuus, Glebius.
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
Re: svn commit: r280971 - in head: contrib/ipfilter/tools share/man/man4 sys/contrib/ipfilter/netinet sys/netinet sys/netipsec sys/netpfil/pf
On 04/02/15 14:35, Gleb Smirnoff wrote:
On Wed, Apr 01, 2015 at 05:07:56PM -0600, Ian Lepore wrote:
I Author: glebius
I Date: Wed Apr 1 22:26:39 2015
I New Revision: 280971
I URL: https://svnweb.freebsd.org/changeset/base/280971
I
I Log:
Io Use new function ip_fillid() in all places throughout the kernel,
I where we want to create a new IP datagram.
Io Add support for RFC6864, which allows to set IP ID for atomic IP
I datagrams to any value, to improve performance. The behaviour is
I controlled by net.inet.ip.rfc6864 sysctl knob, which is enabled by
I default.
Io In case if we generate IP ID, use counter(9) to improve performance.
Io Gather all code related to IP ID into ip_id.c.
I
IDifferential Revision: https://reviews.freebsd.org/D2177
IReviewed by: adrian, cy, rpaulo
ITested by: Emeric POUPON emeric.poupon stormshield.eu
ISponsored by: Netflix
ISponsored by: Nginx, Inc.
IRelnotes: yes
I
I [...]
I +void
I +ip_fillid(struct ip *ip)
I +{
I +
I +/*
I + * Per RFC6864 Section 4
I + *
I + * o Atomic datagrams: (DF==1) (MF==0) (frag_offset==0)
I + * o Non-atomic datagrams: (DF==0) || (MF==1) || (frag_offset0)
I + */
I +if (V_ip_rfc6864 (ip-ip_off htons(IP_DF)) == htons(IP_DF))
I +ip-ip_id = 0;
I +else if (V_ip_do_randomid)
I +ip-ip_id = ip_randomid();
I +else {
I +counter_u64_add(V_ip_id, 1);
I +ip-ip_id = htons((*(uint64_t *)zpcpu_get(V_ip_id)) 0x);
I +}
I +}
I +
I
I This is completely bogus. It's a big opacity violation (it relies on
I what should be opaque private internal implementation details of
I counter(9)). The fact that the counter api doesn't provide a function
I for retrieving one cpu's counter value should be a big clue there -- the
I fact that you know the internals doesn't make it okay to reach behind
I the counter and grab a value like that. It may not even be safe to do
I so on any given architecture; it certainly isn't safe on arm, and that
I line of code above will work only by accident because you're throwing
I way all but 16 bits.
I though about providing that API, but since it isn't safe in general,
I decided to not do that.
I But even more importantly, this WILL result in multiple threads using
I the same value at the same time...
I
I - Thread A on CPU 1 and thread B on CPU 2 both begin executing here at
I the same time, and both get through counter_u64_add().
I - Thread A keeps running and uses CPU 1's new value, call it 27.
I - Thread B gets prempted between counter_u64_add() and zpcpu_get().
I When it resumes it's now on CPU 1, so it retrieves value 27 as well.
This was already discussed in this thread:
https://lists.freebsd.org/pipermail/svn-src-head/2015-March/069864.html
Hi,
At least the generation of IP IDs is now in a common place. I think the
random likelyhood argument is not acceptable. Also there should be a
critical section around the incrementing of the counter and fetching it.
What if a different CPU is handling the same IP connection, then ID
ranges are are likely to repeat.
What I don't understand is in the following link:
https://tools.ietf.org/html/rfc6864
It says:
is required to be unique within the maximum lifetime for all datagrams
with a given source address/destination address/protocol tuple.
When you have a IP based socket, why is this counter not part of the IP
based socket? Why do we have a global counter?
--HPS
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
svn commit: r281000 - in head/sys/boot: efi/loader/arch/i386 i386/efi
Author: emaste
Date: Thu Apr 2 18:57:35 2015
New Revision: 281000
URL: https://svnweb.freebsd.org/changeset/base/281000
Log:
Move i386/efi files to new home in efi/loader/arch/i386
This was not (and still is not) connected to the build, but the EFI
loader is in the process of being built for other than amd64 so these
files ought to live in their eventual MD location.
Added:
head/sys/boot/efi/loader/arch/i386/
head/sys/boot/efi/loader/arch/i386/bootinfo.c
- copied unchanged from r280999, head/sys/boot/i386/efi/bootinfo.c
head/sys/boot/efi/loader/arch/i386/efimd.c
- copied unchanged from r280999, head/sys/boot/i386/efi/efimd.c
head/sys/boot/efi/loader/arch/i386/elf32_freebsd.c
- copied unchanged from r280999, head/sys/boot/i386/efi/elf32_freebsd.c
head/sys/boot/efi/loader/arch/i386/exec.c
- copied unchanged from r280999, head/sys/boot/i386/efi/exec.c
head/sys/boot/efi/loader/arch/i386/i386_copy.c
- copied unchanged from r280999, head/sys/boot/i386/efi/i386_copy.c
head/sys/boot/efi/loader/arch/i386/ldscript.i386
- copied unchanged from r280999, head/sys/boot/i386/efi/ldscript.i386
head/sys/boot/efi/loader/arch/i386/start.S
- copied unchanged from r280999, head/sys/boot/i386/efi/start.S
Deleted:
head/sys/boot/i386/efi/
Copied: head/sys/boot/efi/loader/arch/i386/bootinfo.c (from r280999,
head/sys/boot/i386/efi/bootinfo.c)
==
--- /dev/null 00:00:00 1970 (empty, because file is newly added)
+++ head/sys/boot/efi/loader/arch/i386/bootinfo.c Thu Apr 2 18:57:35
2015(r281000, copy of r280999, head/sys/boot/i386/efi/bootinfo.c)
@@ -0,0 +1,275 @@
+/*-
+ * Copyright (c) 1998 Michael Smith msm...@freebsd.org
+ * Copyright (c) 2006 Marcel Moolenaar
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in the
+ *documentation and/or other materials provided with the distribution.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
+ * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
+ * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+ * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+ * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+ * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+ * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+ * SUCH DAMAGE.
+ */
+
+#include sys/cdefs.h
+__FBSDID($FreeBSD$);
+
+#include stand.h
+#include string.h
+#include sys/param.h
+#include sys/reboot.h
+#include sys/linker.h
+#include sys/boot.h
+
+#include efi.h
+#include efilib.h
+
+#include bootstrap.h
+#include libi386.h
+#include machine/bootinfo.h
+
+static const char howto_switches[] = aCdrgDmphsv;
+static int howto_masks[] = {
+ RB_ASKNAME, RB_CDROM, RB_KDB, RB_DFLTROOT, RB_GDB, RB_MULTIPLE,
+ RB_MUTE, RB_PAUSE, RB_SERIAL, RB_SINGLE, RB_VERBOSE
+};
+
+int
+bi_getboothowto(char *kargs)
+{
+ const char *sw;
+ char *opts;
+ int howto, i;
+
+ howto = 0;
+
+ /* Get the boot options from the environment first. */
+ for (i = 0; howto_names[i].ev != NULL; i++) {
+ if (getenv(howto_names[i].ev) != NULL)
+ howto |= howto_names[i].mask;
+ }
+
+ /* Parse kargs */
+ if (kargs == NULL)
+ return (howto);
+
+ opts = strchr(kargs, '-');
+ while (opts != NULL) {
+ while (*(++opts) != '\0') {
+ sw = strchr(howto_switches, *opts);
+ if (sw == NULL)
+ break;
+ howto |= howto_masks[sw - howto_switches];
+ }
+ opts = strchr(opts, '-');
+ }
+
+ return (howto);
+}
+
+/*
+ * Copy the environment into the load area starting at (addr).
+ * Each variable is formatted as name=value, with a single nul
+ * separating each variable, and a double nul terminating the environment.
+ */
+vm_offset_t
+bi_copyenv(vm_offset_t start)
+{
+ struct env_var *ep;
+ vm_offset_t addr, last;
+ size_t len;
+
+ addr = last = start;
+
+ /* Traverse the environment. */
+ for (ep = environ; ep != NULL; ep =
svn commit: r281001 - stable/10/sys/vm
Author: alc Date: Thu Apr 2 19:10:33 2015 New Revision: 281001 URL: https://svnweb.freebsd.org/changeset/base/281001 Log: MFC r280238 Fix the root cause of the vm_reserv_populate: reserv address is already promoted panics. PR: 198163 Modified: stable/10/sys/vm/vm_fault.c Directory Properties: stable/10/ (props changed) Modified: stable/10/sys/vm/vm_fault.c == --- stable/10/sys/vm/vm_fault.c Thu Apr 2 18:57:35 2015(r281000) +++ stable/10/sys/vm/vm_fault.c Thu Apr 2 19:10:33 2015(r281001) @@ -101,6 +101,7 @@ __FBSDID($FreeBSD$); #include vm/vm_kern.h #include vm/vm_pager.h #include vm/vm_extern.h +#include vm/vm_reserv.h #define PFBAK 4 #define PFFOR 4 @@ -844,6 +845,14 @@ vnode_locked: unlock_and_deallocate(fs); goto RetryFault; } +#if VM_NRESERVLEVEL 0 + /* +* Rename the reservation. +*/ + vm_reserv_rename(fs.m, fs.first_object, + fs.object, OFF_TO_IDX( + fs.first_object-backing_object_offset)); +#endif vm_page_xbusy(fs.m); fs.first_m = fs.m; fs.m = NULL; ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
svn commit: r280991 - head/sys/netinet
Author: hselasky
Date: Thu Apr 2 15:47:37 2015
New Revision: 280991
URL: https://svnweb.freebsd.org/changeset/base/280991
Log:
Extend fixes made in r278103 and r38754 by copying the complete packet
header and not only partial flags and fields. Firewalls can attach
classification tags to the outgoing mbufs which should be copied to
all the new fragments. Else only the first fragment will be let
through by the firewall. This can easily be tested by sending a large
ping packet through a firewall. It was also discovered that VLAN
related flags and fields should be copied for packets traversing
through VLANs. This is all handled by m_dup_pkthdr().
Regarding the MAC policy check in ip_fragment(), the tag provided by
the originating mbuf is copied instead of using the default one
provided by m_gethdr().
Tested by:Karim Fodil-Lemelin fodillemlinkarim at gmail.com
MFC after:2 weeks
Sponsored by: Mellanox Technologies
PR: 7802
Modified:
head/sys/netinet/ip_output.c
Modified: head/sys/netinet/ip_output.c
==
--- head/sys/netinet/ip_output.cThu Apr 2 14:43:07 2015
(r280990)
+++ head/sys/netinet/ip_output.cThu Apr 2 15:47:37 2015
(r280991)
@@ -774,11 +774,19 @@ smart_frag_failure:
IPSTAT_INC(ips_odropped);
goto done;
}
- /* make sure the flowid is the same for the fragmented mbufs */
- M_HASHTYPE_SET(m, M_HASHTYPE_GET(m0));
- m-m_pkthdr.flowid = m0-m_pkthdr.flowid;
- /* copy multicast flag, if any */
- m-m_flags |= (m0-m_flags M_MCAST);
+ /*
+* Make sure the complete packet header gets copied
+* from the originating mbuf to the newly created
+* mbuf. This also ensures that existing firewall
+* classification(s), VLAN tags and so on get copied
+* to the resulting fragmented packet(s):
+*/
+ if (m_dup_pkthdr(m, m0, M_NOWAIT) == 0) {
+ m_free(m);
+ error = ENOBUFS;
+ IPSTAT_INC(ips_odropped);
+ goto done;
+ }
/*
* In the first mbuf, leave room for the link header, then
* copy the original IP header including options. The payload
@@ -808,11 +816,9 @@ smart_frag_failure:
goto done;
}
m-m_pkthdr.len = mhlen + len;
- m-m_pkthdr.rcvif = NULL;
#ifdef MAC
mac_netinet_fragment(m0, m);
#endif
- m-m_pkthdr.csum_flags = m0-m_pkthdr.csum_flags;
mhip-ip_off = htons(mhip-ip_off);
mhip-ip_sum = 0;
if (m-m_pkthdr.csum_flags CSUM_IP ~if_hwassist_flags) {
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
Re: svn commit: r280971 - in head: contrib/ipfilter/tools share/man/man4 sys/contrib/ipfilter/netinet sys/netinet sys/netipsec sys/netpfil/pf
On Thu, Apr 02, 2015 at 03:35:22PM +0300, Gleb Smirnoff wrote:
On Wed, Apr 01, 2015 at 05:07:56PM -0600, Ian Lepore wrote:
I Author: glebius
I Date: Wed Apr 1 22:26:39 2015
I New Revision: 280971
I URL: https://svnweb.freebsd.org/changeset/base/280971
I
I Log:
Io Use new function ip_fillid() in all places throughout the kernel,
I where we want to create a new IP datagram.
Io Add support for RFC6864, which allows to set IP ID for atomic IP
I datagrams to any value, to improve performance. The behaviour is
I controlled by net.inet.ip.rfc6864 sysctl knob, which is enabled by
I default.
Io In case if we generate IP ID, use counter(9) to improve performance.
Io Gather all code related to IP ID into ip_id.c.
I
IDifferential Revision: https://reviews.freebsd.org/D2177
IReviewed by: adrian, cy, rpaulo
ITested by: Emeric POUPON emeric.poupon
stormshield.eu
ISponsored by: Netflix
ISponsored by: Nginx, Inc.
IRelnotes: yes
I
I [...]
I +void
I +ip_fillid(struct ip *ip)
I +{
I +
I +/*
I + * Per RFC6864 Section 4
I + *
I + * o Atomic datagrams: (DF==1) (MF==0) (frag_offset==0)
I + * o Non-atomic datagrams: (DF==0) || (MF==1) ||
(frag_offset0)
I + */
I +if (V_ip_rfc6864 (ip-ip_off htons(IP_DF)) == htons(IP_DF))
I +ip-ip_id = 0;
I +else if (V_ip_do_randomid)
I +ip-ip_id = ip_randomid();
I +else {
I +counter_u64_add(V_ip_id, 1);
I +ip-ip_id = htons((*(uint64_t *)zpcpu_get(V_ip_id))
0x);
I +}
I +}
I +
I
I This is completely bogus. It's a big opacity violation (it relies on
I what should be opaque private internal implementation details of
I counter(9)). The fact that the counter api doesn't provide a function
I for retrieving one cpu's counter value should be a big clue there -- the
I fact that you know the internals doesn't make it okay to reach behind
I the counter and grab a value like that. It may not even be safe to do
I so on any given architecture; it certainly isn't safe on arm, and that
I line of code above will work only by accident because you're throwing
I way all but 16 bits.
I though about providing that API, but since it isn't safe in general,
I decided to not do that.
I But even more importantly, this WILL result in multiple threads using
I the same value at the same time...
I
I - Thread A on CPU 1 and thread B on CPU 2 both begin executing here at
I the same time, and both get through counter_u64_add().
I - Thread A keeps running and uses CPU 1's new value, call it 27.
I - Thread B gets prempted between counter_u64_add() and zpcpu_get().
I When it resumes it's now on CPU 1, so it retrieves value 27 as well.
This was already discussed in this thread:
https://lists.freebsd.org/pipermail/svn-src-head/2015-March/069864.html
For this particular use-case you never care what CPU you are executing
on, you only want to obtain a unique number.
per-cpu counters can serve this purpose no problem, just provide an
operation which guarantees to return the new value of the counter it
incremented. Should be easily achieved with e.g. just pinning curthread
to the cpu it executes on for the duration of inc + fetch.
--
Mateusz Guzik mjguzik gmail.com
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
Re: svn commit: r280971 - in head: contrib/ipfilter/tools share/man/man4 sys/contrib/ipfilter/netinet sys/netinet sys/netipsec sys/netpfil/pf
On Thu, Apr 02, 2015 at 05:34:20PM +0300, Gleb Smirnoff wrote: On Thu, Apr 02, 2015 at 04:23:18PM +0200, Mateusz Guzik wrote: M Well, a thread migrating to another cpu is the standard thing everyone M sees. How often do you see it right in a particular window of 2 or 3 instructions? If you carefully read the thread I referred to, you would notice that on many arches, save amd64 and i386, all systems stats are prone to mangling the stats due to migration within PCPU_INC. Look here: grep '^#definePCPU_ADD' sys/*/include/pcpu.h Do we have reports on not precise enough statistics, yet? How many non-x86 installations with multiple cpus and high traffic are out there? Also note that stats should be roughly equally distributed amongst CPUs which do the work, so an occasional mismatch is likely to go unnoticed. Would be nice to get this fixed at some point though. M I don't feel that strongly about changing the code. If it stays as it M is, it definitely needs the comment I mentioned explaining why migration M is fine. I just added the comment. Thanks! M If the code was to be changed a machdep counter_u64_fetchadd seems like M the only course of action. If we have more places in kernel, where such API is required, I would do it. Alas, seems like not possible to make it without critical section, even on amd64. Note that counter_u64_add() on amd64 is critical-less. Yeah, but that should be cheap. Worst case on amd64 it could be microoptimised with removal of func call and inline critnest manipulation with compiler barrier. Afair Ian said that on arm they could hack around it nicer with atomics, don't remember atm what's the holdup (if any). tl;dr this should be doable without technical problems and does not have to affect counter_u64_add. -- Mateusz Guzik mjguzik gmail.com ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
Re: svn commit: r280971 - in head: contrib/ipfilter/tools share/man/man4 sys/contrib/ipfilter/netinet sys/netinet sys/netipsec sys/netpfil/pf
On Thu, 2 Apr 2015, Mateusz Guzik wrote: If you carefully read the thread I referred to, you would notice that on many arches, save amd64 and i386, all systems stats are prone to mangling the stats due to migration within PCPU_INC. Look here: grep '^#define PCPU_ADD' sys/*/include/pcpu.h Do we have reports on not precise enough statistics, yet? How many non-x86 installations with multiple cpus and high traffic are out there? Not sure if this was a rhetorical question or not, but: quite a few. We have support for several highly threaded 64-bit MIPS systems including those from Cavium and Broadcom (was NetLogic Micro was RMI). Several reference systems are in the netperf cluster including 16- and 32-thread systems normally deployed in high-performance network products. It's possible that ARMv8 systems will gradually displayce 64-bit MIPS systems in this arena in the future, but hard to say. Either way, it's not x86. :-) Robert ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
Re: svn commit: r280971 - in head: contrib/ipfilter/tools share/man/man4 sys/contrib/ipfilter/netinet sys/netinet sys/netipsec sys/netpfil/pf
On Thu, Apr 02, 2015 at 07:53:07AM -0600, Ian Lepore wrote: I Discussed, but not really resolved, or even reasonably addressed. I I But I guess if you think it's done, more words at this point aren't I going to make you see the problems clearly enough to make the required I changes. I didn't see arguments that would prove the following assertions wrong. 1) There is legitimate case of IP ID reuse withing datagram lifetime, that happens due to overflow of uint16_t. Its probability is X. 2) There is a case of IP ID reuse due to migration between counter_u64_add() and memory fetch. Its probability is Y. 3) Y X 4) Fixing X is impossible. 5) Fixing Y requires additional computing resources per packet. 6) Due to X being considerably high, the modern Internet has learnt to cope with the problem. From this assertions I estimate that speaking of Y: (probability * risk cost) countermeasures cost Please prove wrong my assertions, or the conclusion. P.S. Note that up to this week we had ip_id++ code, which was extremele prone to quick ID reuse. And no one (except Emeric of StormShield) was so worried about the case. But as soon as I made it per-CPU, together with disabling the code for 99% packets (thanks RFC6864), some people got extremely concerned by the possible reuse in the per-CPU case. -- Totus tuus, Glebius. ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
Re: svn commit: r280971 - in head: contrib/ipfilter/tools share/man/man4 sys/contrib/ipfilter/netinet sys/netinet sys/netipsec sys/netpfil/pf
On Thu, 2015-04-02 at 15:51 +0200, Mateusz Guzik wrote:
On Thu, Apr 02, 2015 at 04:42:17PM +0300, Gleb Smirnoff wrote:
On Thu, Apr 02, 2015 at 03:37:51PM +0200, Mateusz Guzik wrote:
M On Thu, Apr 02, 2015 at 03:35:22PM +0300, Gleb Smirnoff wrote:
M On Wed, Apr 01, 2015 at 05:07:56PM -0600, Ian Lepore wrote:
M I Author: glebius
M I Date: Wed Apr 1 22:26:39 2015
M I New Revision: 280971
M I URL: https://svnweb.freebsd.org/changeset/base/280971
M I
M I Log:
M Io Use new function ip_fillid() in all places throughout the
kernel,
M I where we want to create a new IP datagram.
M Io Add support for RFC6864, which allows to set IP ID for atomic
IP
M I datagrams to any value, to improve performance. The behaviour
is
M I controlled by net.inet.ip.rfc6864 sysctl knob, which is
enabled by
M I default.
M Io In case if we generate IP ID, use counter(9) to improve
performance.
M Io Gather all code related to IP ID into ip_id.c.
M I
M IDifferential Revision:
https://reviews.freebsd.org/D2177
M IReviewed by:adrian, cy, rpaulo
M ITested by: Emeric POUPON emeric.poupon
stormshield.eu
M ISponsored by: Netflix
M ISponsored by: Nginx, Inc.
M IRelnotes: yes
M I
M I [...]
M I +void
M I +ip_fillid(struct ip *ip)
M I +{
M I +
M I + /*
M I + * Per RFC6864 Section 4
M I + *
M I + * o Atomic datagrams: (DF==1) (MF==0) (frag_offset==0)
M I + * o Non-atomic datagrams: (DF==0) || (MF==1) ||
(frag_offset0)
M I + */
M I + if (V_ip_rfc6864 (ip-ip_off htons(IP_DF)) == htons(IP_DF))
M I + ip-ip_id = 0;
M I + else if (V_ip_do_randomid)
M I + ip-ip_id = ip_randomid();
M I + else {
M I + counter_u64_add(V_ip_id, 1);
M I + ip-ip_id = htons((*(uint64_t *)zpcpu_get(V_ip_id))
0x);
M I + }
M I +}
M I +
M I
M I This is completely bogus. It's a big opacity violation (it relies
on
M I what should be opaque private internal implementation details of
M I counter(9)). The fact that the counter api doesn't provide a
function
M I for retrieving one cpu's counter value should be a big clue there
-- the
M I fact that you know the internals doesn't make it okay to reach
behind
M I the counter and grab a value like that. It may not even be safe to
do
M I so on any given architecture; it certainly isn't safe on arm, and
that
M I line of code above will work only by accident because you're
throwing
M I way all but 16 bits.
M
M I though about providing that API, but since it isn't safe in general,
M I decided to not do that.
M
M I But even more importantly, this WILL result in multiple threads
using
M I the same value at the same time...
M I
M I - Thread A on CPU 1 and thread B on CPU 2 both begin executing
here at
M I the same time, and both get through counter_u64_add().
M I - Thread A keeps running and uses CPU 1's new value, call it 27.
M I - Thread B gets prempted between counter_u64_add() and zpcpu_get().
M I When it resumes it's now on CPU 1, so it retrieves value 27 as well.
M
M This was already discussed in this thread:
M
M https://lists.freebsd.org/pipermail/svn-src-head/2015-March/069864.html
M
M
M For this particular use-case you never care what CPU you are executing
M on, you only want to obtain a unique number.
M
M per-cpu counters can serve this purpose no problem, just provide an
M operation which guarantees to return the new value of the counter it
M incremented. Should be easily achieved with e.g. just pinning curthread
M to the cpu it executes on for the duration of inc + fetch.
I'd ask to pay attention to this particular email:
https://lists.freebsd.org/pipermail/svn-src-head/2015-March/069966.html
Just to justify probabilities, risks and countermeasures.
For those, who don't believe in theory and prefers practice:
https://lists.freebsd.org/pipermail/svn-src-head/2015-March/070091.html
Note that Emeric was the one who observed collisions for the ip_id++
code, that we used before.
Well in that case this at least deserves a comment in the code. Everyone
spotting that counter_u64_add + zpcpu_get will think it's a bug.
Because it IS a bug. That isn't changed by the fact that it works
reliably on one platform due to what should be an opque implementation
detail, and works by accident on other platforms (at least until the
details of their implementations change in the future).
As soon as somebody sees this code, thinks it's a good way to do things,
and cut and pastes it into another venue and removes the 0x, it
just turns into a bug on every platform except
svn commit: r280990 - head/sys/netinet
Author: jch
Date: Thu Apr 2 14:43:07 2015
New Revision: 280990
URL: https://svnweb.freebsd.org/changeset/base/280990
Log:
Provide better debugging information in tcp_timer_activate() and
tcp_timer_active()
Differential Revision:https://reviews.freebsd.org/D2179
Suggested by: bz
Reviewed by: jhb
Approved by: jhb
Modified:
head/sys/netinet/tcp_timer.c
Modified: head/sys/netinet/tcp_timer.c
==
--- head/sys/netinet/tcp_timer.cThu Apr 2 14:22:59 2015
(r280989)
+++ head/sys/netinet/tcp_timer.cThu Apr 2 14:43:07 2015
(r280990)
@@ -884,7 +884,7 @@ tcp_timer_activate(struct tcpcb *tp, int
f_callout = tcp_timer_2msl;
break;
default:
- panic(bad timer_type);
+ panic(tp %p bad timer_type %#x, tp, timer_type);
}
if (delta == 0) {
callout_stop(t_callout);
@@ -915,7 +915,7 @@ tcp_timer_active(struct tcpcb *tp, int t
t_callout = tp-t_timers-tt_2msl;
break;
default:
- panic(bad timer_type);
+ panic(tp %p bad timer_type %#x, tp, timer_type);
}
return callout_active(t_callout);
}
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
Re: svn commit: r280982 - head/usr.bin/iscsictl
On Apr 2, 2015, at 04:18, Edward Tomasz Napierala tr...@freebsd.org wrote: Author: trasz Date: Thu Apr 2 11:18:43 2015 New Revision: 280982 URL: https://svnweb.freebsd.org/changeset/base/280982 Log: Rewrite iscsi.conf(5) to better match iscsictl(8). MFC after:1 month Sponsored by:The FreeBSD Foundation Relnotes: yes/add an updating entry? ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
Re: svn commit: r280971 - in head: contrib/ipfilter/tools share/man/man4 sys/contrib/ipfilter/netinet sys/netinet sys/netipsec sys/netpfil/pf
On Thu, Apr 02, 2015 at 04:23:18PM +0200, Mateusz Guzik wrote: M Well, a thread migrating to another cpu is the standard thing everyone M sees. How often do you see it right in a particular window of 2 or 3 instructions? If you carefully read the thread I referred to, you would notice that on many arches, save amd64 and i386, all systems stats are prone to mangling the stats due to migration within PCPU_INC. Look here: grep '^#define PCPU_ADD' sys/*/include/pcpu.h Do we have reports on not precise enough statistics, yet? M I don't feel that strongly about changing the code. If it stays as it M is, it definitely needs the comment I mentioned explaining why migration M is fine. I just added the comment. M If the code was to be changed a machdep counter_u64_fetchadd seems like M the only course of action. If we have more places in kernel, where such API is required, I would do it. Alas, seems like not possible to make it without critical section, even on amd64. Note that counter_u64_add() on amd64 is critical-less. -- Totus tuus, Glebius. ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
svn commit: r280988 - head/sbin/ggate/ggatec
Author: wblock (doc committer) Date: Thu Apr 2 13:51:06 2015 New Revision: 280988 URL: https://svnweb.freebsd.org/changeset/base/280988 Log: Add articles, avoid use of you, simplify a few sentences. MFC after:1 week Modified: head/sbin/ggate/ggatec/ggatec.8 Modified: head/sbin/ggate/ggatec/ggatec.8 == --- head/sbin/ggate/ggatec/ggatec.8 Thu Apr 2 13:02:25 2015 (r280987) +++ head/sbin/ggate/ggatec/ggatec.8 Thu Apr 2 13:51:06 2015 (r280988) @@ -24,7 +24,7 @@ .\ .\ $FreeBSD$ .\ -.Dd April 26, 2004 +.Dd April 2, 2015 .Dt GGATEC 8 .Os .Sh NAME @@ -67,29 +67,29 @@ .Sh DESCRIPTION The .Nm -utility is a network client for GEOM Gate class. -It is responsible for creation of +utility is a network client for the GEOM Gate class. +It is responsible for the creation of .Nm ggate -devices and forwarding I/O requests between +devices and forwarding I/O requests between the .Nm geom_gate.ko -kernel module and +kernel module and the .Xr ggated 8 network daemon. Available commands: .Bl -tag -width .Cm destroy .It Cm create -Connect to given +Connect to a .Xr ggated 8 -daemon and create a +daemon on the specified host and create a .Nm ggate -provider related to the given remote file or device. +provider for the specified remote file or device. .It Cm rescue -If +Create a new connection after the .Nm -process died/has been killed, you can save situation with this -command, which creates new connection to the +process has died or been killed. +The new connection to the .Xr ggated 8 -daemon and will handle pending and future requests. +daemon handles pending and future requests. .It Cm destroy Destroy the given .Nm ggate @@ -139,12 +139,11 @@ provider. If not specified, it is taken from device, or set to 512 bytes for files. .It Fl t Ar timeout Number of seconds to wait before an I/O request will be canceled. -0 means no timeout. -Default is 0. +Default is 0, which means no timeout. .It Fl u Ar unit Unit number to use. .It Fl v -Do not fork, run in foreground and print debug informations on standard +Do not fork, run in foreground and print debug information on standard output. .It Ar host Remote host to connect to. @@ -159,7 +158,7 @@ should be called with the .Fl v option. .Sh EXAMPLES -Make use of CD-ROM device from remote host. +Use a CD-ROM device on a remote host. .Bd -literal -offset indent server# cat /etc/gg.exports client RO /dev/acd0 ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
Re: svn commit: r280971 - in head: contrib/ipfilter/tools share/man/man4 sys/contrib/ipfilter/netinet sys/netinet sys/netipsec sys/netpfil/pf
On Thu, Apr 02, 2015 at 04:42:17PM +0300, Gleb Smirnoff wrote:
On Thu, Apr 02, 2015 at 03:37:51PM +0200, Mateusz Guzik wrote:
M On Thu, Apr 02, 2015 at 03:35:22PM +0300, Gleb Smirnoff wrote:
M On Wed, Apr 01, 2015 at 05:07:56PM -0600, Ian Lepore wrote:
M I Author: glebius
M I Date: Wed Apr 1 22:26:39 2015
M I New Revision: 280971
M I URL: https://svnweb.freebsd.org/changeset/base/280971
M I
M I Log:
M Io Use new function ip_fillid() in all places throughout the
kernel,
M I where we want to create a new IP datagram.
M Io Add support for RFC6864, which allows to set IP ID for atomic IP
M I datagrams to any value, to improve performance. The behaviour is
M I controlled by net.inet.ip.rfc6864 sysctl knob, which is enabled
by
M I default.
M Io In case if we generate IP ID, use counter(9) to improve
performance.
M Io Gather all code related to IP ID into ip_id.c.
M I
M IDifferential Revision:
https://reviews.freebsd.org/D2177
M IReviewed by: adrian, cy, rpaulo
M ITested by:Emeric POUPON emeric.poupon
stormshield.eu
M ISponsored by: Netflix
M ISponsored by: Nginx, Inc.
M IRelnotes: yes
M I
M I [...]
M I +void
M I +ip_fillid(struct ip *ip)
M I +{
M I +
M I + /*
M I +* Per RFC6864 Section 4
M I +*
M I +* o Atomic datagrams: (DF==1) (MF==0) (frag_offset==0)
M I +* o Non-atomic datagrams: (DF==0) || (MF==1) ||
(frag_offset0)
M I +*/
M I + if (V_ip_rfc6864 (ip-ip_off htons(IP_DF)) == htons(IP_DF))
M I + ip-ip_id = 0;
M I + else if (V_ip_do_randomid)
M I + ip-ip_id = ip_randomid();
M I + else {
M I + counter_u64_add(V_ip_id, 1);
M I + ip-ip_id = htons((*(uint64_t *)zpcpu_get(V_ip_id))
0x);
M I + }
M I +}
M I +
M I
M I This is completely bogus. It's a big opacity violation (it relies on
M I what should be opaque private internal implementation details of
M I counter(9)). The fact that the counter api doesn't provide a function
M I for retrieving one cpu's counter value should be a big clue there --
the
M I fact that you know the internals doesn't make it okay to reach behind
M I the counter and grab a value like that. It may not even be safe to do
M I so on any given architecture; it certainly isn't safe on arm, and that
M I line of code above will work only by accident because you're throwing
M I way all but 16 bits.
M
M I though about providing that API, but since it isn't safe in general,
M I decided to not do that.
M
M I But even more importantly, this WILL result in multiple threads using
M I the same value at the same time...
M I
M I - Thread A on CPU 1 and thread B on CPU 2 both begin executing here
at
M I the same time, and both get through counter_u64_add().
M I - Thread A keeps running and uses CPU 1's new value, call it 27.
M I - Thread B gets prempted between counter_u64_add() and zpcpu_get().
M I When it resumes it's now on CPU 1, so it retrieves value 27 as well.
M
M This was already discussed in this thread:
M
M https://lists.freebsd.org/pipermail/svn-src-head/2015-March/069864.html
M
M
M For this particular use-case you never care what CPU you are executing
M on, you only want to obtain a unique number.
M
M per-cpu counters can serve this purpose no problem, just provide an
M operation which guarantees to return the new value of the counter it
M incremented. Should be easily achieved with e.g. just pinning curthread
M to the cpu it executes on for the duration of inc + fetch.
I'd ask to pay attention to this particular email:
https://lists.freebsd.org/pipermail/svn-src-head/2015-March/069966.html
Just to justify probabilities, risks and countermeasures.
For those, who don't believe in theory and prefers practice:
https://lists.freebsd.org/pipermail/svn-src-head/2015-March/070091.html
Note that Emeric was the one who observed collisions for the ip_id++
code, that we used before.
Well in that case this at least deserves a comment in the code. Everyone
spotting that counter_u64_add + zpcpu_get will think it's a bug.
--
Mateusz Guzik mjguzik gmail.com
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
Re: svn commit: r280971 - in head: contrib/ipfilter/tools share/man/man4 sys/contrib/ipfilter/netinet sys/netinet sys/netipsec sys/netpfil/pf
On Thu, 2015-04-02 at 15:35 +0300, Gleb Smirnoff wrote:
On Wed, Apr 01, 2015 at 05:07:56PM -0600, Ian Lepore wrote:
I Author: glebius
I Date: Wed Apr 1 22:26:39 2015
I New Revision: 280971
I URL: https://svnweb.freebsd.org/changeset/base/280971
I
I Log:
Io Use new function ip_fillid() in all places throughout the kernel,
I where we want to create a new IP datagram.
Io Add support for RFC6864, which allows to set IP ID for atomic IP
I datagrams to any value, to improve performance. The behaviour is
I controlled by net.inet.ip.rfc6864 sysctl knob, which is enabled by
I default.
Io In case if we generate IP ID, use counter(9) to improve performance.
Io Gather all code related to IP ID into ip_id.c.
I
IDifferential Revision: https://reviews.freebsd.org/D2177
IReviewed by: adrian, cy, rpaulo
ITested by: Emeric POUPON emeric.poupon
stormshield.eu
ISponsored by: Netflix
ISponsored by: Nginx, Inc.
IRelnotes: yes
I
I [...]
I +void
I +ip_fillid(struct ip *ip)
I +{
I +
I +/*
I + * Per RFC6864 Section 4
I + *
I + * o Atomic datagrams: (DF==1) (MF==0) (frag_offset==0)
I + * o Non-atomic datagrams: (DF==0) || (MF==1) ||
(frag_offset0)
I + */
I +if (V_ip_rfc6864 (ip-ip_off htons(IP_DF)) == htons(IP_DF))
I +ip-ip_id = 0;
I +else if (V_ip_do_randomid)
I +ip-ip_id = ip_randomid();
I +else {
I +counter_u64_add(V_ip_id, 1);
I +ip-ip_id = htons((*(uint64_t *)zpcpu_get(V_ip_id))
0x);
I +}
I +}
I +
I
I This is completely bogus. It's a big opacity violation (it relies on
I what should be opaque private internal implementation details of
I counter(9)). The fact that the counter api doesn't provide a function
I for retrieving one cpu's counter value should be a big clue there -- the
I fact that you know the internals doesn't make it okay to reach behind
I the counter and grab a value like that. It may not even be safe to do
I so on any given architecture; it certainly isn't safe on arm, and that
I line of code above will work only by accident because you're throwing
I way all but 16 bits.
I though about providing that API, but since it isn't safe in general,
I decided to not do that.
I But even more importantly, this WILL result in multiple threads using
I the same value at the same time...
I
I - Thread A on CPU 1 and thread B on CPU 2 both begin executing here at
I the same time, and both get through counter_u64_add().
I - Thread A keeps running and uses CPU 1's new value, call it 27.
I - Thread B gets prempted between counter_u64_add() and zpcpu_get().
I When it resumes it's now on CPU 1, so it retrieves value 27 as well.
This was already discussed in this thread:
https://lists.freebsd.org/pipermail/svn-src-head/2015-March/069864.html
Discussed, but not really resolved, or even reasonably addressed.
But I guess if you think it's done, more words at this point aren't
going to make you see the problems clearly enough to make the required
changes.
-- Ian
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
Re: svn commit: r280971 - in head: contrib/ipfilter/tools share/man/man4 sys/contrib/ipfilter/netinet sys/netinet sys/netipsec sys/netpfil/pf
On Thu, Apr 02, 2015 at 07:58:29AM -0600, Ian Lepore wrote: On Thu, 2015-04-02 at 15:51 +0200, Mateusz Guzik wrote: On Thu, Apr 02, 2015 at 04:42:17PM +0300, Gleb Smirnoff wrote: On Thu, Apr 02, 2015 at 03:37:51PM +0200, Mateusz Guzik wrote: M For this particular use-case you never care what CPU you are executing M on, you only want to obtain a unique number. M M per-cpu counters can serve this purpose no problem, just provide an M operation which guarantees to return the new value of the counter it M incremented. Should be easily achieved with e.g. just pinning curthread M to the cpu it executes on for the duration of inc + fetch. I'd ask to pay attention to this particular email: https://lists.freebsd.org/pipermail/svn-src-head/2015-March/069966.html Just to justify probabilities, risks and countermeasures. For those, who don't believe in theory and prefers practice: https://lists.freebsd.org/pipermail/svn-src-head/2015-March/070091.html Note that Emeric was the one who observed collisions for the ip_id++ code, that we used before. Well in that case this at least deserves a comment in the code. Everyone spotting that counter_u64_add + zpcpu_get will think it's a bug. Because it IS a bug. That isn't changed by the fact that it works reliably on one platform due to what should be an opque implementation detail, and works by accident on other platforms (at least until the details of their implementations change in the future). As soon as somebody sees this code, thinks it's a good way to do things, and cut and pastes it into another venue and removes the 0x, it just turns into a bug on every platform except amd64. Well, a thread migrating to another cpu is the standard thing everyone sees. Are you referring to the fact that the counter is 64-bit, so 32-bit arches must perform 2 reads and the thread can be migrated in-between? Indeed that would look like a solid problem, mitigated 'by accident' with 0x. I don't feel that strongly about changing the code. If it stays as it is, it definitely needs the comment I mentioned explaining why migration is fine. If the code was to be changed a machdep counter_u64_fetchadd seems like the only course of action. -- Mateusz Guzik mjguzik gmail.com ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
Re: svn commit: r280971 - in head: contrib/ipfilter/tools share/man/man4 sys/contrib/ipfilter/netinet sys/netinet sys/netipsec sys/netpfil/pf
On 04/02/15 15:04, Hans Petter Selasky wrote: I think the random likelyhood argument is not acceptable. For example if a particular CPU load causes ip_output() to be called 1 time on CPU #0 and 2 times on CPU #1 and this pattern repeats ... --HPS ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
Re: svn commit: r280971 - in head: contrib/ipfilter/tools share/man/man4 sys/contrib/ipfilter/netinet sys/netinet sys/netipsec sys/netpfil/pf
On Thu, Apr 02, 2015 at 03:37:51PM +0200, Mateusz Guzik wrote:
M On Thu, Apr 02, 2015 at 03:35:22PM +0300, Gleb Smirnoff wrote:
M On Wed, Apr 01, 2015 at 05:07:56PM -0600, Ian Lepore wrote:
M I Author: glebius
M I Date: Wed Apr 1 22:26:39 2015
M I New Revision: 280971
M I URL: https://svnweb.freebsd.org/changeset/base/280971
M I
M I Log:
M Io Use new function ip_fillid() in all places throughout the kernel,
M I where we want to create a new IP datagram.
M Io Add support for RFC6864, which allows to set IP ID for atomic IP
M I datagrams to any value, to improve performance. The behaviour is
M I controlled by net.inet.ip.rfc6864 sysctl knob, which is enabled by
M I default.
M Io In case if we generate IP ID, use counter(9) to improve
performance.
M Io Gather all code related to IP ID into ip_id.c.
M I
M IDifferential Revision:
https://reviews.freebsd.org/D2177
M IReviewed by:adrian, cy, rpaulo
M ITested by: Emeric POUPON emeric.poupon
stormshield.eu
M ISponsored by: Netflix
M ISponsored by: Nginx, Inc.
M IRelnotes: yes
M I
M I [...]
M I +void
M I +ip_fillid(struct ip *ip)
M I +{
M I +
M I + /*
M I + * Per RFC6864 Section 4
M I + *
M I + * o Atomic datagrams: (DF==1) (MF==0) (frag_offset==0)
M I + * o Non-atomic datagrams: (DF==0) || (MF==1) ||
(frag_offset0)
M I + */
M I + if (V_ip_rfc6864 (ip-ip_off htons(IP_DF)) == htons(IP_DF))
M I + ip-ip_id = 0;
M I + else if (V_ip_do_randomid)
M I + ip-ip_id = ip_randomid();
M I + else {
M I + counter_u64_add(V_ip_id, 1);
M I + ip-ip_id = htons((*(uint64_t *)zpcpu_get(V_ip_id))
0x);
M I + }
M I +}
M I +
M I
M I This is completely bogus. It's a big opacity violation (it relies on
M I what should be opaque private internal implementation details of
M I counter(9)). The fact that the counter api doesn't provide a function
M I for retrieving one cpu's counter value should be a big clue there -- the
M I fact that you know the internals doesn't make it okay to reach behind
M I the counter and grab a value like that. It may not even be safe to do
M I so on any given architecture; it certainly isn't safe on arm, and that
M I line of code above will work only by accident because you're throwing
M I way all but 16 bits.
M
M I though about providing that API, but since it isn't safe in general,
M I decided to not do that.
M
M I But even more importantly, this WILL result in multiple threads using
M I the same value at the same time...
M I
M I - Thread A on CPU 1 and thread B on CPU 2 both begin executing here at
M I the same time, and both get through counter_u64_add().
M I - Thread A keeps running and uses CPU 1's new value, call it 27.
M I - Thread B gets prempted between counter_u64_add() and zpcpu_get().
M I When it resumes it's now on CPU 1, so it retrieves value 27 as well.
M
M This was already discussed in this thread:
M
M https://lists.freebsd.org/pipermail/svn-src-head/2015-March/069864.html
M
M
M For this particular use-case you never care what CPU you are executing
M on, you only want to obtain a unique number.
M
M per-cpu counters can serve this purpose no problem, just provide an
M operation which guarantees to return the new value of the counter it
M incremented. Should be easily achieved with e.g. just pinning curthread
M to the cpu it executes on for the duration of inc + fetch.
I'd ask to pay attention to this particular email:
https://lists.freebsd.org/pipermail/svn-src-head/2015-March/069966.html
Just to justify probabilities, risks and countermeasures.
For those, who don't believe in theory and prefers practice:
https://lists.freebsd.org/pipermail/svn-src-head/2015-March/070091.html
Note that Emeric was the one who observed collisions for the ip_id++
code, that we used before.
--
Totus tuus, Glebius.
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
svn commit: r280989 - head/sys/netinet
Author: glebius
Date: Thu Apr 2 14:22:59 2015
New Revision: 280989
URL: https://svnweb.freebsd.org/changeset/base/280989
Log:
Provide a comment explaining issues with the counter(9) trick, so that
people won't copy and paste it blindly.
Prodded by: ian
Sponsored by: Nginx, Inc.
Modified:
head/sys/netinet/ip_id.c
Modified: head/sys/netinet/ip_id.c
==
--- head/sys/netinet/ip_id.cThu Apr 2 13:51:06 2015(r280988)
+++ head/sys/netinet/ip_id.cThu Apr 2 14:22:59 2015(r280989)
@@ -254,6 +254,20 @@ ip_fillid(struct ip *ip)
ip-ip_id = ip_randomid();
else {
counter_u64_add(V_ip_id, 1);
+ /*
+* There are two issues about this trick, to be kept in mind.
+* 1) We can migrate between counter_u64_add() and next
+*line, and grab counter from other CPU, resulting in too
+*quick ID reuse. This is tolerable in our particular case,
+*since probability of such event is much lower then reuse
+*of ID due to legitimate overflow, that at modern Internet
+*speeds happens all the time.
+* 2) We are relying on the fact that counter(9) is based on
+*UMA_ZONE_PCPU uma(9) zone. We also take only last
+*sixteen bits of a counter, so we don't care about the
+*fact that machines with 32-bit word update their counters
+*not atomically.
+*/
ip-ip_id = htons((*(uint64_t *)zpcpu_get(V_ip_id)) 0x);
}
}
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
svn commit: r280993 - head/gnu/lib/libgcc
Author: andrew
Date: Thu Apr 2 17:06:15 2015
New Revision: 280993
URL: https://svnweb.freebsd.org/changeset/base/280993
Log:
Exclude the floating-point functions from libgcc_s on arm64, they are
unneeded and will be provided by compiler-rt.
Sponsored by: The FreeBSD Foundation
Modified:
head/gnu/lib/libgcc/Makefile
Modified: head/gnu/lib/libgcc/Makefile
==
--- head/gnu/lib/libgcc/MakefileThu Apr 2 17:03:02 2015
(r280992)
+++ head/gnu/lib/libgcc/MakefileThu Apr 2 17:06:15 2015
(r280993)
@@ -55,7 +55,7 @@ LIB2FUNCS+= _fixuns${mode}si
.endfor
# Likewise double-word routines.
-.if ${TARGET_CPUARCH} != arm
+.if ${TARGET_CPUARCH} != aarch64 ${TARGET_CPUARCH} != arm
# These are implemented in an ARM specific file but will not be filtered out
.for mode in sf df xf tf
LIB2FUNCS+= _fix${mode}di _fixuns${mode}di
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
svn commit: r280992 - head
Author: andrew
Date: Thu Apr 2 17:03:02 2015
New Revision: 280992
URL: https://svnweb.freebsd.org/changeset/base/280992
Log:
Only use the CROSS_BINUTILS_PREFIX tool if it exists.
Reviewed by: emaste
Sponsored by: The FreeBSD Foundation
Modified:
head/Makefile.inc1
Modified: head/Makefile.inc1
==
--- head/Makefile.inc1 Thu Apr 2 15:47:37 2015(r280991)
+++ head/Makefile.inc1 Thu Apr 2 17:03:02 2015(r280992)
@@ -344,7 +344,8 @@ X${COMPILER}?= ${${COMPILER}}
.endfor
XBINUTILS= AS AR LD NM OBJCOPY OBJDUMP RANLIB SIZE STRINGS
.for BINUTIL in ${XBINUTILS}
-.if defined(CROSS_BINUTILS_PREFIX)
+.if defined(CROSS_BINUTILS_PREFIX) \
+exists(${CROSS_BINUTILS_PREFIX}${${BINUTIL}})
X${BINUTIL}?= ${CROSS_BINUTILS_PREFIX}${${BINUTIL}}
.else
X${BINUTIL}?= ${${BINUTIL}}
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
svn commit: r280997 - head/lib/libkvm
Author: andrew
Date: Thu Apr 2 17:30:19 2015
New Revision: 280997
URL: https://svnweb.freebsd.org/changeset/base/280997
Log:
Add stub functions to build libkvm. There will be added, but we need them
now get the toolchain target building.
Differential Revision:https://reviews.freebsd.org/D2185
Sponsored by: The FreeBSD Foundation
Added:
head/lib/libkvm/kvm_aarch64.c (contents, props changed)
Added: head/lib/libkvm/kvm_aarch64.c
==
--- /dev/null 00:00:00 1970 (empty, because file is newly added)
+++ head/lib/libkvm/kvm_aarch64.c Thu Apr 2 17:30:19 2015
(r280997)
@@ -0,0 +1,64 @@
+/*-
+ * Copyright (c) 2014 The FreeBSD Foundation
+ * All rights reserved.
+ *
+ * This software was developed by Andrew Turner under
+ * sponsorship from the FreeBSD Foundation.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in the
+ *documentation and/or other materials provided with the distribution.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
+ * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
+ * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+ * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+ * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+ * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+ * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+ * SUCH DAMAGE.
+ */
+
+#include sys/cdefs.h
+__FBSDID($FreeBSD$);
+
+#include sys/param.h
+
+#include limits.h
+#include kvm.h
+#include stdio.h
+#include stdlib.h
+
+#include kvm_private.h
+
+void
+_kvm_freevtop(kvm_t *kd)
+{
+
+ printf(_kvm_freevtop\n);
+ abort();
+}
+
+int
+_kvm_initvtop(kvm_t *kd)
+{
+
+ printf(_kvm_initvtop\n);
+ abort();
+}
+
+int
+_kvm_kvatop(kvm_t *kd, u_long va, off_t *pa)
+{
+
+ printf(_kvm_kvatop\n);
+ abort();
+}
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
Re: svn commit: r280982 - head/usr.bin/iscsictl
On 0402T0750, Garrett Cooper wrote: On Apr 2, 2015, at 04:18, Edward Tomasz Napierala tr...@freebsd.org wrote: Author: trasz Date: Thu Apr 2 11:18:43 2015 New Revision: 280982 URL: https://svnweb.freebsd.org/changeset/base/280982 Log: Rewrite iscsi.conf(5) to better match iscsictl(8). MFC after:1 month Sponsored by:The FreeBSD Foundation Relnotes: yes/add an updating entry? I'm not sure, it's only a man page update - the file format syntax didn't change. ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
Re: svn commit: r280971 - in head: contrib/ipfilter/tools share/man/man4 sys/contrib/ipfilter/netinet sys/netinet sys/netipsec sys/netpfil/pf
On 2 Apr 2015, at 19:24, Hans Petter Selasky h...@selasky.org wrote: In my sketchup I assume that packets for the same destination will not be re-ordered. I see that the current ip_reass() code does not care about TCP or UDP port numbers at all. Maybe we should add code to check that the packet belongs to the same ports too? Higher-level network headers will appear only in the first fragment, so can't be used in matching later fragments. Does somebody here know what happens in these two cases: If we are transmitting using TSO, will the network adapter increment the IP ID field somehow? What happens if an outgoing IP packet resulting from a TSO packet get fragmented by a router? Quite possibly -- this is presumably specified by the NIC vendor, but it would be good to do a bit of a survey and see what happens in practice. In ip_fragment() when we create fragments we should increment the ip_id value for each fragment? That you are asking this question while hacking on the IP ID code is deeply troubling. Please go read up on how IP fragmentation works before going any further with these changes! Robert ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
Re: svn commit: r280971 - in head: contrib/ipfilter/tools share/man/man4 sys/contrib/ipfilter/netinet sys/netinet sys/netipsec sys/netpfil/pf
Hi Robert, On 04/02/15 20:32, Robert N. M. Watson wrote: On 2 Apr 2015, at 19:24, Hans Petter Selasky h...@selasky.org wrote: In my sketchup I assume that packets for the same destination will not be re-ordered. I see that the current ip_reass() code does not care about TCP or UDP port numbers at all. Maybe we should add code to check that the packet belongs to the same ports too? Higher-level network headers will appear only in the first fragment, so can't be used in matching later fragments. Right. Does somebody here know what happens in these two cases: If we are transmitting using TSO, will the network adapter increment the IP ID field somehow? What happens if an outgoing IP packet resulting from a TSO packet get fragmented by a router? Quite possibly -- this is presumably specified by the NIC vendor, but it would be good to do a bit of a survey and see what happens in practice. In ip_fragment() when we create fragments we should increment the ip_id value for each fragment? I'm asking because the code in FreeBSD, since the beginning probably, just copies the IP header, and use the same IP ID for all the fragments ! This just hit my mind after some recent work in this area. That you are asking this question while hacking on the IP ID code is deeply troubling. Please go read up on how IP fragmentation works before going any further with these changes! I see from ip_reass() how it works. --HPS ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
svn commit: r280999 - head/crypto/openssh
Author: bdrewery Date: Thu Apr 2 18:43:25 2015 New Revision: 280999 URL: https://svnweb.freebsd.org/changeset/base/280999 Log: Use proper CHAN_TCP_PACKET_DEFAULT for agent forwarding when HPN disabled. The use of CHAN_TCP_WINDOW_DEFAULT here was fixed in upstream OpenSSH in CVS 1.4810, git 5baa170d771de9e95cf30b4c469ece684244cf3e: - dtuc...@cvs.openbsd.org 2007/12/28 22:34:47 [clientloop.c] Use the correct packet maximum sizes for remote port and agent forwarding. Prevents the server from killing the connection if too much data is queued and an excessively large packet gets sent. bz #1360, ok djm@. The change was lost due to the the way the original upstream HPN patch modified this code. It was re-adding the original OpenSSH code and never was properly fixed to use the new value. MFC after:2 weeks Modified: head/crypto/openssh/clientloop.c Modified: head/crypto/openssh/clientloop.c == --- head/crypto/openssh/clientloop.cThu Apr 2 18:18:40 2015 (r280998) +++ head/crypto/openssh/clientloop.cThu Apr 2 18:43:25 2015 (r280999) @@ -1923,7 +1923,7 @@ client_request_agent(const char *request if (options.hpn_disabled) c = channel_new(authentication agent connection, SSH_CHANNEL_OPEN, sock, sock, -1, - CHAN_X11_WINDOW_DEFAULT, CHAN_TCP_WINDOW_DEFAULT, 0, + CHAN_X11_WINDOW_DEFAULT, CHAN_TCP_PACKET_DEFAULT, 0, authentication agent connection, 1); else c = channel_new(authentication agent connection, ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
Re: svn commit: r280971 - in head: contrib/ipfilter/tools share/man/man4 sys/contrib/ipfilter/netinet sys/netinet sys/netipsec sys/netpfil/pf
On Thu, 2 Apr 2015, Hans Petter Selasky wrote: Does somebody here know what happens in these two cases: If we are transmitting using TSO, will the network adapter increment the IP ID field somehow? What happens if an outgoing IP packet resulting from a TSO packet get fragmented by a router? Quite possibly -- this is presumably specified by the NIC vendor, but it would be good to do a bit of a survey and see what happens in practice. In ip_fragment() when we create fragments we should increment the ip_id value for each fragment? I'm asking because the code in FreeBSD, since the beginning probably, just copies the IP header, and use the same IP ID for all the fragments ! This just hit my mind after some recent work in this area. I honestly cannot believe you are proposing that. Please go read about how IP fragmentation works. Having an identical IP ID in ip_fragment() is the point of the function! Robert ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
svn commit: r280998 - head/usr.sbin/arp
Author: markj
Date: Thu Apr 2 18:18:40 2015
New Revision: 280998
URL: https://svnweb.freebsd.org/changeset/base/280998
Log:
arp(8): add support for printing and deleting entries of type
IFT_INFINIBAND, used in IPoIB.
PR: 151594
Submitted by: Anthony Cornehl accorn...@gmail.com
Reviewed by: hselasky
MFC after:1 week
Sponsored by: EMC / Isilon Storage Division
Modified:
head/usr.sbin/arp/arp.c
Modified: head/usr.sbin/arp/arp.c
==
--- head/usr.sbin/arp/arp.c Thu Apr 2 17:30:19 2015(r280997)
+++ head/usr.sbin/arp/arp.c Thu Apr 2 18:18:40 2015(r280998)
@@ -282,6 +282,7 @@ valid_type(int type)
switch (type) {
case IFT_ETHER:
case IFT_FDDI:
+ case IFT_INFINIBAND:
case IFT_ISO88023:
case IFT_ISO88024:
case IFT_ISO88025:
@@ -656,6 +657,9 @@ print_entry(struct sockaddr_dl *sdl,
case IFT_BRIDGE:
printf( [bridge]);
break;
+ case IFT_INFINIBAND:
+ printf( [infiniband]);
+ break;
default:
break;
}
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
Re: svn commit: r280971 - in head: contrib/ipfilter/tools share/man/man4 sys/contrib/ipfilter/netinet sys/netinet sys/netipsec sys/netpfil/pf
On 04/02/15 18:00, Robert Watson wrote: On Thu, 2 Apr 2015, Mateusz Guzik wrote: If you carefully read the thread I referred to, you would notice that on many arches, save amd64 and i386, all systems stats are prone to mangling the stats due to migration within PCPU_INC. Look here: grep '^#definePCPU_ADD' sys/*/include/pcpu.h Do we have reports on not precise enough statistics, yet? How many non-x86 installations with multiple cpus and high traffic are out there? Not sure if this was a rhetorical question or not, but: quite a few. We have support for several highly threaded 64-bit MIPS systems including those from Cavium and Broadcom (was NetLogic Micro was RMI). Several reference systems are in the netperf cluster including 16- and 32-thread systems normally deployed in high-performance network products. It's possible that ARMv8 systems will gradually displayce 64-bit MIPS systems in this arena in the future, but hard to say. Either way, it's not x86. :-) Hi, I've sketched up my proposal here, please have a look. https://reviews.freebsd.org/D2211 --HPS ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
Re: svn commit: r280982 - head/usr.bin/iscsictl
On Apr 2, 2015, at 10:09, Edward Tomasz Napierala tr...@freebsd.org wrote: On 0402T0750, Garrett Cooper wrote: On Apr 2, 2015, at 04:18, Edward Tomasz Napierala tr...@freebsd.org wrote: Author: trasz Date: Thu Apr 2 11:18:43 2015 New Revision: 280982 URL: https://svnweb.freebsd.org/changeset/base/280982 Log: Rewrite iscsi.conf(5) to better match iscsictl(8). MFC after:1 month Sponsored by:The FreeBSD Foundation Relnotes: yes/add an updating entry? I'm not sure, it's only a man page update - the file format syntax didn't change. Ah, ok. I thought the format changes. Nevermind :).. ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
Re: svn commit: r280971 - in head: contrib/ipfilter/tools share/man/man4 sys/contrib/ipfilter/netinet sys/netinet sys/netipsec sys/netpfil/pf
On 04/02/15 19:49, Hans Petter Selasky wrote: On 04/02/15 18:00, Robert Watson wrote: On Thu, 2 Apr 2015, Mateusz Guzik wrote: If you carefully read the thread I referred to, you would notice that on many arches, save amd64 and i386, all systems stats are prone to mangling the stats due to migration within PCPU_INC. Look here: grep '^#definePCPU_ADD' sys/*/include/pcpu.h Do we have reports on not precise enough statistics, yet? How many non-x86 installations with multiple cpus and high traffic are out there? Not sure if this was a rhetorical question or not, but: quite a few. We have support for several highly threaded 64-bit MIPS systems including those from Cavium and Broadcom (was NetLogic Micro was RMI). Several reference systems are in the netperf cluster including 16- and 32-thread systems normally deployed in high-performance network products. It's possible that ARMv8 systems will gradually displayce 64-bit MIPS systems in this arena in the future, but hard to say. Either way, it's not x86. :-) Hi, I've sketched up my proposal here, please have a look. https://reviews.freebsd.org/D2211 --HPS Hi, In my sketchup I assume that packets for the same destination will not be re-ordered. I see that the current ip_reass() code does not care about TCP or UDP port numbers at all. Maybe we should add code to check that the packet belongs to the same ports too? Does somebody here know what happens in these two cases: If we are transmitting using TSO, will the network adapter increment the IP ID field somehow? What happens if an outgoing IP packet resulting from a TSO packet get fragmented by a router? In ip_fragment() when we create fragments we should increment the ip_id value for each fragment? --HPS ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
Re: svn commit: r280971 - in head: contrib/ipfilter/tools share/man/man4 sys/contrib/ipfilter/netinet sys/netinet sys/netipsec sys/netpfil/pf
On 04/02/15 22:26, Hans Petter Selasky wrote:
On 04/02/15 20:46, Robert Watson wrote:
On Thu, 2 Apr 2015, Hans Petter Selasky wrote:
Does somebody here know what happens in these two cases:
If we are transmitting using TSO, will the network adapter increment
the IP ID field somehow? What happens if an outgoing IP packet
resulting from a TSO packet get fragmented by a router?
Quite possibly -- this is presumably specified by the NIC vendor, but
it would be good to do a bit of a survey and see what happens in
practice.
In ip_fragment() when we create fragments we should increment the
ip_id value for each fragment?
I'm asking because the code in FreeBSD, since the beginning probably,
just copies the IP header, and use the same IP ID for all the
fragments ! This just hit my mind after some recent work in this area.
I honestly cannot believe you are proposing that.
Please go read about how IP fragmentation works. Having an identical IP
ID in ip_fragment() is the point of the function!
Hi,
rwatson: You're right, the more fragment flag gets set there, I
overlooked that bit. Sorry.
glebius: Given that you admit there is a small chance of an IP ID
collision in the previous e-mails exchanged in this thread, why don't we
have checks for that in ip_reass() when receiving fragmented IP packets?
For example when ip-ip_off == 0 we know the TCP and/or UDP port numbers
for TCP and UDP payloads and can check if a new fragment is starting
before the previous one is completed. Then we would know if a collision
has happened and could discard that packet. Not ideal, but better than
data corruption.
Hi,
I see from the code that if two frags have the same IP offset, the whole
fragment list gets dropped, unless the IP payload is zero bytes long.
Maybe a last variable should be added?
* only n will ever be stored. (n = maxfragsperpacket.)
*
*/
next = 0;
last = -1;
for (p = NULL, q = fp-ipq_frags; q; p = q, q = q-m_nextpkt) {
if (ntohs(GETIP(q)-ip_off) != next ||
+ ntohs(GETIP(q)-ip_off) == last
) {
if (fp-ipq_nfrags V_maxfragsperpacket) {
IPSTAT_ADD(ips_fragdropped, fp-ipq_nfrags);
ip_freef(head, fp);
}
goto done;
}
last = next;
next += ntohs(GETIP(q)-ip_len);
}
--HPS
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
Re: svn commit: r280971 - in head: contrib/ipfilter/tools share/man/man4 sys/contrib/ipfilter/netinet sys/netinet sys/netipsec sys/netpfil/pf
On 2 Apr 2015, at 21:54, Hans Petter Selasky h...@selasky.org wrote:
Please go read about how IP fragmentation works. Having an identical IP
ID in ip_fragment() is the point of the function!
rwatson: You're right, the more fragment flag gets set there, I
overlooked that bit. Sorry.
glebius: Given that you admit there is a small chance of an IP ID
collision in the previous e-mails exchanged in this thread, why don't we
have checks for that in ip_reass() when receiving fragmented IP packets?
For example when ip-ip_off == 0 we know the TCP and/or UDP port numbers
for TCP and UDP payloads and can check if a new fragment is starting
before the previous one is completed. Then we would know if a collision
has happened and could discard that packet. Not ideal, but better than
data corruption.
I see from the code that if two frags have the same IP offset, the whole
fragment list gets dropped, unless the IP payload is zero bytes long. Maybe a
last variable should be added?
Are you solving an actual problem you've observed, or is this a speculative
proposal? RFC 791 requires that the minimum fragment size be 8 octets, and
ip_input() drops fragments below that size, so you shouldn't (in principle) be
able to get a fragment in the reassembly code that has the properties you've
described. If you are, it's a bug elsewhere in the stack. If you are worried,
you could add an assertion at the top of the reassembly function that the size
is = 8 octets.
I think you would benefit a great deal from reading Stevens Volume I (second
edition) before proceeding with further changes to the TCP/IP code stack. A
number of the proposals you have made are contradictory to fundamental design
choices in the protocol. Although there isn't a second edition of Volume II, it
might still be a good idea to skim through the pertinent sections there as well
-- it applies to a much (much) earlier version of the stack, but includes a
detailed exposition of how the implementation tracks the protocol.
Robert
* only n will ever be stored. (n = maxfragsperpacket.)
*
*/
next = 0;
last = -1;
for (p = NULL, q = fp-ipq_frags; q; p = q, q = q-m_nextpkt) {
if (ntohs(GETIP(q)-ip_off) != next ||
+ ntohs(GETIP(q)-ip_off) == last
) {
if (fp-ipq_nfrags V_maxfragsperpacket) {
IPSTAT_ADD(ips_fragdropped, fp-ipq_nfrags);
ip_freef(head, fp);
}
goto done;
}
last = next;
next += ntohs(GETIP(q)-ip_len);
}
--HPS
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
svn commit: r281005 - head/libexec/rtld-elf
Author: emaste
Date: Thu Apr 2 21:35:36 2015
New Revision: 281005
URL: https://svnweb.freebsd.org/changeset/base/281005
Log:
Make die available as rtld_die for use by MD relocation code
Reviewed by: kib
Sponsored by: The FreeBSD Foundation
Differential Revision:https://reviews.freebsd.org/D2213
Modified:
head/libexec/rtld-elf/rtld.c
head/libexec/rtld-elf/rtld.h
Modified: head/libexec/rtld-elf/rtld.c
==
--- head/libexec/rtld-elf/rtld.cThu Apr 2 21:18:11 2015
(r281004)
+++ head/libexec/rtld-elf/rtld.cThu Apr 2 21:35:36 2015
(r281005)
@@ -78,7 +78,6 @@ typedef void * (*path_enum_proc) (const
* Function declarations.
*/
static const char *basename(const char *);
-static void die(void) __dead2;
static void digest_dynamic1(Obj_Entry *, int, const Elf_Dyn **,
const Elf_Dyn **, const Elf_Dyn **);
static void digest_dynamic2(Obj_Entry *, const Elf_Dyn *, const Elf_Dyn *,
@@ -430,7 +429,7 @@ _rtld(Elf_Addr *sp, func_ptr_type *exit_
unsetenv(LD_ DEBUG) || unsetenv(LD_ ELF_HINTS_PATH) ||
unsetenv(LD_ LOADFLTR) || unsetenv(LD_ LIBRARY_PATH_RPATH)) {
_rtld_error(environment corrupt; aborting);
- die();
+ rtld_die();
}
}
ld_debug = getenv(LD_ DEBUG);
@@ -479,7 +478,7 @@ _rtld(Elf_Addr *sp, func_ptr_type *exit_
obj_main = map_object(fd, argv0, NULL);
close(fd);
if (obj_main == NULL)
- die();
+ rtld_die();
max_stack_flags = obj-stack_flags;
} else { /* Main program already loaded. */
const Elf_Phdr *phdr;
@@ -496,7 +495,7 @@ _rtld(Elf_Addr *sp, func_ptr_type *exit_
assert(aux_info[AT_ENTRY] != NULL);
entry = (caddr_t) aux_info[AT_ENTRY]-a_un.a_ptr;
if ((obj_main = digest_phdr(phdr, phnum, entry, argv0)) == NULL)
- die();
+ rtld_die();
}
if (aux_info[AT_EXECPATH] != 0) {
@@ -563,12 +562,12 @@ _rtld(Elf_Addr *sp, func_ptr_type *exit_
dbg(loading LD_PRELOAD libraries);
if (load_preload_objects() == -1)
- die();
+ rtld_die();
preload_tail = obj_tail;
dbg(loading needed objects);
if (load_needed_objects(obj_main, 0) == -1)
- die();
+ rtld_die();
/* Make a list of all objects loaded at startup. */
last_interposer = obj_main;
@@ -584,7 +583,7 @@ _rtld(Elf_Addr *sp, func_ptr_type *exit_
dbg(checking for required versions);
if (rtld_verify_versions(list_main) == -1 !ld_tracing)
- die();
+ rtld_die();
if (ld_tracing) { /* We're done */
trace_loaded_objects(obj_main);
@@ -613,11 +612,11 @@ _rtld(Elf_Addr *sp, func_ptr_type *exit_
if (relocate_objects(obj_main,
ld_bind_now != NULL *ld_bind_now != '\0',
obj_rtld, SYMLOOK_EARLY, NULL) == -1)
- die();
+ rtld_die();
dbg(doing copy relocations);
if (do_copy_relocations(obj_main) == -1)
- die();
+ rtld_die();
if (getenv(LD_ DUMP_REL_POST) != NULL) {
dump_relocations(obj_main);
@@ -649,7 +648,7 @@ _rtld(Elf_Addr *sp, func_ptr_type *exit_
if (resolve_objects_ifunc(obj_main,
ld_bind_now != NULL *ld_bind_now != '\0', SYMLOOK_EARLY,
NULL) == -1)
- die();
+ rtld_die();
if (!obj_main-crt_no_init) {
/*
@@ -716,7 +715,7 @@ _rtld_bind(Obj_Entry *obj, Elf_Size relo
def = find_symdef(ELF_R_SYM(rel-r_info), obj, defobj, true, NULL,
lockstate);
if (def == NULL)
- die();
+ rtld_die();
if (ELF_ST_TYPE(def-st_info) == STT_GNU_IFUNC)
target = (Elf_Addr)rtld_resolve_ifunc(defobj, def);
else
@@ -865,8 +864,8 @@ origin_subst(char *real, const char *ori
return (res4);
}
-static void
-die(void)
+void
+rtld_die(void)
{
const char *msg = dlerror();
@@ -1216,7 +1215,7 @@ digest_dynamic2(Obj_Entry *obj, const El
if (obj-z_origin obj-origin_path == NULL) {
obj-origin_path = xmalloc(PATH_MAX);
if (rtld_dirname_abs(obj-path, obj-origin_path) == -1)
- die();
+ rtld_die();
}
if (dyn_runpath != NULL) {
@@ -1914,7 +1913,7 @@ init_pagesizes(Elf_Auxinfo **aux_info)
}
if (sysctl(mib, len, psa, size, NULL, 0) == -1) {
_rtld_error(sysctl for hw.pagesize(s) failed);
- die();
+ rtld_die();
}
psa_filled:
pagesizes = psa;
@@ -2851,7 +2850,7 @@ search_library_pathfds(const char *name,
if (rtld_snprintf(found, len, #%d/%s, dirfd, name)
0) {
_rtld_error(error generating '%d/%s',
dirfd, name);
- die();
+ rtld_die();
svn commit: r281006 - head/sys/dev/bxe
Author: davidcs
Date: Thu Apr 2 21:55:03 2015
New Revision: 281006
URL: https://svnweb.freebsd.org/changeset/base/281006
Log:
When an mbuf allocation fails in the receive path, the mbuf containing the
received packet is not sent to the host net
work stack and is reused again on the receive ring. Remaining received
packets in the ring are not processed in that
invocation of bxe_rxeof() and defered to the task thread.
MFC after: 5 days
Modified:
head/sys/dev/bxe/bxe.c
Modified: head/sys/dev/bxe/bxe.c
==
--- head/sys/dev/bxe/bxe.c Thu Apr 2 21:35:36 2015(r281005)
+++ head/sys/dev/bxe/bxe.c Thu Apr 2 21:55:03 2015(r281006)
@@ -3246,7 +3246,7 @@ bxe_rxeof(struct bxe_softc*sc,
uint16_t bd_cons, bd_prod, bd_prod_fw, comp_ring_cons;
uint16_t hw_cq_cons, sw_cq_cons, sw_cq_prod;
int rx_pkts = 0;
-int rc;
+int rc = 0;
BXE_FP_RX_LOCK(fp);
@@ -3388,6 +3388,10 @@ bxe_rxeof(struct bxe_softc*sc,
(sc-max_rx_bufs != RX_BD_USABLE) ?
bd_prod : bd_cons);
if (rc != 0) {
+
+/* we simply reuse the received mbuf and don't post it to the
stack */
+m = NULL;
+
BLOGE(sc, mbuf alloc fail for fp[%02d] rx chain (%d)\n,
fp-index, rc);
fp-eth_q_stats.rx_soft_errors++;
@@ -3476,6 +3480,9 @@ next_cqe:
sw_cq_cons = RCQ_NEXT(sw_cq_cons);
/* limit spinning on the queue */
+if (rc != 0)
+break;
+
if (rx_pkts == sc-rx_budget) {
fp-eth_q_stats.rx_budget_reached++;
break;
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
