Re: httpd server configuration evaluation bug
On Mon, Jul 30, 2018 at 10:24:03AM -0600, Base Pr1me wrote:
> Sorry, this time with the correct diff.
>
> On 7/25/18 4:15 PM, Base Pr1me wrote:
> > Hi,
> >
> > I discovered that the wrong server configuration is evaluated in the
> > server_read_http function. Only the first server in httpd.conf is checked.
> > For
> > example, I have five servers setup in httpd.conf and the third server is the
> > only one with connection { max request body } set, because I desire it
> > to
> > accept larger uploads than the other servers. When the upload is initiated,
> > server one dictates the max request body size, globally.
> >
> > The attached diff moves the queue loop out of the server_response function
> > in to
> > its own function, as to not duplicate code.
> >
> > I don't know if this is the only place the wrong information is evaluated.
> > Also,
> > I'm not sure this is the best method to fix the problem, but it should
> > point the
> > powers that be in the right direction.
> >
> > Thanks,
> >
> > Tracey
> >
>
Hello,
I reworked the last sent diff. I missed fixing up the hostname. This was causing
an incorrect 301 on urls not containing an ending slash. I also moved the
srv_conf assignment into the new function.
Again, this is to use the correct server config information from the queue for
server_read_http and remove code duplication.
If anyone is willing to look at this and make suggestions, that'd be great. If
not, that'd be great too! LOL. Have a great weekend.
Thanks,
Tracey
Index: src/usr.sbin/httpd/httpd.h
===
RCS file: /cvs/src/usr.sbin/httpd/httpd.h,v
retrieving revision 1.142
diff -u -p -u -r1.142 httpd.h
--- src/usr.sbin/httpd/httpd.h 11 Oct 2018 09:52:22 - 1.142
+++ src/usr.sbin/httpd/httpd.h 26 Oct 2018 20:52:26 -
@@ -691,6 +691,8 @@ const char *
char *server_http_parsehost(char *, char *, size_t, int *);
ssize_t server_http_time(time_t, char *, size_t);
int server_log_http(struct client *, unsigned int, size_t);
+int server_check_client_config(struct server_config *, struct client *,
+ struct kv *, char *);
/* server_file.c */
int server_file(struct httpd *, struct client *);
Index: src/usr.sbin/httpd/server_http.c
===
RCS file: /cvs/src/usr.sbin/httpd/server_http.c,v
retrieving revision 1.126
diff -u -p -u -r1.126 server_http.c
--- src/usr.sbin/httpd/server_http.c15 Oct 2018 08:16:17 - 1.126
+++ src/usr.sbin/httpd/server_http.c26 Oct 2018 20:52:26 -
@@ -204,7 +204,7 @@ server_read_http(struct bufferevent *bev
char*line = NULL, *key, *value;
const char *errstr;
size_t size, linelen;
- struct kv *hdr = NULL;
+ struct kv *hdr = NULL, kv_key, *host;
getmonotime(>clt_tv_last);
@@ -344,6 +344,15 @@ server_read_http(struct bufferevent *bev
goto abort;
}
+ kv_key.kv_key = "Host";
+ if ((host = kv_find(>http_headers, _key)) !=
+ NULL && host->kv_value == NULL)
+ host = NULL;
+
+ if (server_check_client_config(srv_conf, clt, host,
+ NULL))
+ goto fail;
+
/*
* Need to read data from the client after the
* HTTP header.
@@ -1183,10 +1192,7 @@ server_response(struct httpd *httpd, str
struct server *srv = clt->clt_srv;
struct server_config*srv_conf = >srv_conf;
struct kv *kv, key, *host;
- struct str_find sm;
- int portval = -1, ret;
- char*hostval, *query;
- const char *errstr = NULL;
+ char*query;
/* Decode the URL */
if (desc->http_path == NULL ||
@@ -1234,58 +1240,8 @@ server_response(struct httpd *httpd, str
if (clt->clt_pipelining && clt->clt_toread > 0)
clt->clt_persist = 0;
- /*
-* Do we have a Host header and matching configuration?
-* XXX the Host can also appear in the URL path.
-*/
- if (host != NULL) {
- if ((hostval = server_http_parsehost(host->kv_value,
- hostname, sizeof(hostname), )) == NULL)
- goto fail;
-
- TAILQ_FOREACH(srv_conf, >srv_hosts, entry) {
-#ifdef DEBUG
- if ((srv_conf->flags & SRVFLAG_LOCATION) == 0) {
- DPRINTF("%s: virtual host \"%s:%u\""
- " host \"%s\" (\"%s\")",
- __func__, srv_conf->name,
-
inteldrm(4): uvm write-combining support
Diff below adds support to uvm to create wtite-combining mappings and
uses this to implement support for the I915_MMAP_WC flag in
inteldrm(4). With this diff I can re-enable support for the
I915_PARAM_MMAP_VERSION.
Please test.
Index: dev/pci/drm/i915/i915_dma.c
===
RCS file: /cvs/src/sys/dev/pci/drm/i915/i915_dma.c,v
retrieving revision 1.27
diff -u -p -r1.27 i915_dma.c
--- dev/pci/drm/i915/i915_dma.c 25 Oct 2018 20:29:38 - 1.27
+++ dev/pci/drm/i915/i915_dma.c 26 Oct 2018 19:22:17 -
@@ -156,11 +156,9 @@ static int i915_getparam(struct drm_devi
case I915_PARAM_HAS_COHERENT_PHYS_GTT:
value = 1;
break;
-#ifdef notyet
case I915_PARAM_MMAP_VERSION:
value = 1;
break;
-#endif
case I915_PARAM_SUBSLICE_TOTAL:
value = INTEL_INFO(dev)->subslice_total;
if (!value)
Index: dev/pci/drm/i915/i915_gem.c
===
RCS file: /cvs/src/sys/dev/pci/drm/i915/i915_gem.c,v
retrieving revision 1.113
diff -u -p -r1.113 i915_gem.c
--- dev/pci/drm/i915/i915_gem.c 13 Sep 2018 03:38:15 - 1.113
+++ dev/pci/drm/i915/i915_gem.c 26 Oct 2018 19:22:17 -
@@ -1987,7 +1987,8 @@ i915_gem_mmap_ioctl(struct drm_device *d
addr = 0;
ret = -uvm_map(>p_vmspace->vm_map, , size,
obj->uao, args->offset, 0, UVM_MAPFLAG(PROT_READ | PROT_WRITE,
- PROT_READ | PROT_WRITE, MAP_INHERIT_SHARE, MADV_RANDOM, 0));
+ PROT_READ | PROT_WRITE, MAP_INHERIT_SHARE, MADV_RANDOM,
+ (args->flags & I915_MMAP_WC) ? UVM_FLAG_WC : 0));
if (ret == 0)
uao_reference(obj->uao);
drm_gem_object_unreference_unlocked(obj);
Index: uvm/uvm.h
===
RCS file: /cvs/src/sys/uvm/uvm.h,v
retrieving revision 1.62
diff -u -p -r1.62 uvm.h
--- uvm/uvm.h 12 Apr 2018 17:13:44 - 1.62
+++ uvm/uvm.h 26 Oct 2018 19:22:18 -
@@ -82,14 +82,15 @@ struct uvm {
* vm_map_entry etype bits:
*/
-#define UVM_ET_OBJ 0x01/* it is a uvm_object */
-#define UVM_ET_SUBMAP 0x02/* it is a vm_map submap */
-#define UVM_ET_COPYONWRITE 0x04/* copy_on_write */
-#define UVM_ET_NEEDSCOPY 0x08/* needs_copy */
-#define UVM_ET_HOLE0x10/* no backend */
-#define UVM_ET_NOFAULT 0x20/* don't fault */
-#define UVM_ET_STACK 0x40/* this is a stack */
-#define UVM_ET_FREEMAPPED 0x80/* map entry is on free list (DEBUG) */
+#define UVM_ET_OBJ 0x0001 /* it is a uvm_object */
+#define UVM_ET_SUBMAP 0x0002 /* it is a vm_map submap */
+#define UVM_ET_COPYONWRITE 0x0004 /* copy_on_write */
+#define UVM_ET_NEEDSCOPY 0x0008 /* needs_copy */
+#define UVM_ET_HOLE0x0010 /* no backend */
+#define UVM_ET_NOFAULT 0x0020 /* don't fault */
+#define UVM_ET_STACK 0x0040 /* this is a stack */
+#define UVM_ET_WC 0x0080 /* write combining */
+#define UVM_ET_FREEMAPPED 0x8000 /* map entry is on free list (DEBUG) */
#define UVM_ET_ISOBJ(E)(((E)->etype & UVM_ET_OBJ) != 0)
#define UVM_ET_ISSUBMAP(E) (((E)->etype & UVM_ET_SUBMAP) != 0)
@@ -98,6 +99,7 @@ struct uvm {
#define UVM_ET_ISHOLE(E) (((E)->etype & UVM_ET_HOLE) != 0)
#define UVM_ET_ISNOFAULT(E)(((E)->etype & UVM_ET_NOFAULT) != 0)
#define UVM_ET_ISSTACK(E) (((E)->etype & UVM_ET_STACK) != 0)
+#define UVM_ET_ISWC(E) (((E)->etype & UVM_ET_WC) != 0)
#ifdef _KERNEL
Index: uvm/uvm_extern.h
===
RCS file: /cvs/src/sys/uvm/uvm_extern.h,v
retrieving revision 1.143
diff -u -p -r1.143 uvm_extern.h
--- uvm/uvm_extern.h12 Apr 2018 17:13:44 - 1.143
+++ uvm/uvm_extern.h26 Oct 2018 19:22:18 -
@@ -112,6 +112,7 @@ typedef int vm_prot_t;
#define UVM_FLAG_NOFAULT 0x080 /* don't fault */
#define UVM_FLAG_UNMAP 0x100 /* unmap to make space */
#define UVM_FLAG_STACK 0x200 /* page may contain a stack */
+#define UVM_FLAG_WC 0x400 /* write combining */
/* macros to extract info */
#define UVM_PROTECTION(X) ((X) & PROT_MASK)
Index: uvm/uvm_fault.c
===
RCS file: /cvs/src/sys/uvm/uvm_fault.c,v
retrieving revision 1.93
diff -u -p -r1.93 uvm_fault.c
--- uvm/uvm_fault.c 12 Apr 2018 17:13:44 - 1.93
+++ uvm/uvm_fault.c 26 Oct 2018 19:22:18 -
@@ -497,7 +497,7 @@ uvm_fault(vm_map_t orig_map, vaddr_t vad
int npages, nback, nforw, centeridx, result, lcv, gotpages, ret;
vaddr_t startva, currva;
voff_t uoff;
- paddr_t pa;
+ paddr_t pa, pa_flags;
struct vm_amap *amap;
struct uvm_object *uobj;
struct
Re: unveil ospfd's parent proc
On 2018/10/26 18:15, Remi Locherer wrote: > On Fri, Oct 26, 2018 at 06:01:40PM +0200, Florian Obser wrote: > > This breaks usage of the "include" keyword. Something that all the parse.y > > daemons support. > > > > Oh, of course! > > I guess this is similar to unveil files based on a list of command line args. Similar, but with parse.y daemons, it can change at config reload time too.
Re: i386: build working kernel with lld
On Fri, Oct 26, 2018 at 01:55:08PM +0200, Christian Weisgerber wrote:
> Move the calculation of the entry point to after the description
> of the .text section. LOADADDR(.text) is not available earlier
> with lld.
>
> With this, lld builds working kernels on i386.
>
> Also: Should this be __start_phys? It seems odd that we put a
> non-reserved symbol into the kernel namespace. start_phys is not
> referenced anywhere by the kernel code and this is the only place
> it appears in the source tree.
I think this was used ages ago in hibernate, but we removed that need
later. Probably forgot to clean up all the mess.
-ml
>
> Index: sys/arch/i386/conf/ld.script
> ===
> RCS file: /cvs/src/sys/arch/i386/conf/ld.script,v
> retrieving revision 1.9
> diff -u -p -r1.9 ld.script
> --- sys/arch/i386/conf/ld.script 11 Apr 2018 15:44:08 - 1.9
> +++ sys/arch/i386/conf/ld.script 25 Oct 2018 20:35:18 -
> @@ -41,8 +41,6 @@ __ALIGN_SIZE = 0x1000;
> __kernel_base_virt = 0xd020 + SIZEOF_HEADERS;
> __kernel_base_phys = __kernel_base_virt & 0xfff;
>
> -/* We use physical address to jump to kernel */
> -start_phys = LOADADDR(.text) + (start - __kernel_base_virt);
> ENTRY(start_phys)
> SECTIONS
> {
> @@ -56,6 +54,8 @@ SECTIONS
> locore0.o(.text)
> *(.text .text.*)
> } :text =0x
> + /* We use physical address to jump to kernel */
> + start_phys = LOADADDR(.text) + (start - __kernel_base_virt);
>
> . = ALIGN(__ALIGN_SIZE);
> __kernel_kutext_phys = . & 0xfff;
> --
> Christian "naddy" Weisgerber na...@mips.inka.de
>
Re: unveil ospfd's parent proc
Remi Locherer wrote: > On Fri, Oct 26, 2018 at 06:01:40PM +0200, Florian Obser wrote: > > This breaks usage of the "include" keyword. Something that all the parse.y > > daemons support. > > > > Oh, of course! > > I guess this is similar to unveil files based on a list of command line args. correct. Now that unveil is used in the tree, there are 3 types of programs 1) they use unveil 2) they use pledge, heading close towards "stdio" without a "*path" 3) they access arbitrary files based upon argv this is (3), except not argv, it nested inside the config file Well there are maybe 20 programs beyond that which aren't converted yet, but things are looking pretty good.
Re: unveil ospfd's parent proc
On Fri, Oct 26, 2018 at 06:01:40PM +0200, Florian Obser wrote:
> This breaks usage of the "include" keyword. Something that all the parse.y
> daemons support.
>
Oh, of course!
I guess this is similar to unveil files based on a list of command line args.
> On October 26, 2018 5:26:06 PM GMT+02:00, Remi Locherer
> wrote:
> >Hi,
> >
> >this restricts ospfd's parent process to only read it's config file
> >(reload)
> >and unlink the control socket on exit. I added unveil after the setup
> >of
> >the control socket is done since chmod is used in control_init.
> >
> >OK?
> >
> >Remi
> >
> >
> >Index: ospfd.c
> >===
> >RCS file: /cvs/src/usr.sbin/ospfd/ospfd.c,v
> >retrieving revision 1.100
> >diff -u -p -r1.100 ospfd.c
> >--- ospfd.c 29 Aug 2018 08:43:17 - 1.100
> >+++ ospfd.c 26 Oct 2018 15:10:08 -
> >@@ -278,6 +278,13 @@ main(int argc, char *argv[])
> > fatalx("control socket setup failed");
> > main_imsg_compose_ospfe_fd(IMSG_CONTROLFD, 0, control_fd);
> >
> >+if (unveil(conffile, "r") == -1)
> >+fatal("unveil");
> >+if (unveil(ospfd_conf->csock, "c") == -1)
> >+fatal("unveil");
> >+if (unveil(NULL, NULL) == -1)
> >+fatal("unveil");
> >+
> > if (kr_init(!(ospfd_conf->flags & OSPFD_FLAG_NO_FIB_UPDATE),
> > ospfd_conf->rdomain, ospfd_conf->redist_label_or_prefix) == -1)
> > fatalx("kr_init failed");
>
> --
> Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: unveil ospfd's parent proc
This breaks usage of the "include" keyword. Something that all the parse.y
daemons support.
On October 26, 2018 5:26:06 PM GMT+02:00, Remi Locherer
wrote:
>Hi,
>
>this restricts ospfd's parent process to only read it's config file
>(reload)
>and unlink the control socket on exit. I added unveil after the setup
>of
>the control socket is done since chmod is used in control_init.
>
>OK?
>
>Remi
>
>
>Index: ospfd.c
>===
>RCS file: /cvs/src/usr.sbin/ospfd/ospfd.c,v
>retrieving revision 1.100
>diff -u -p -r1.100 ospfd.c
>--- ospfd.c29 Aug 2018 08:43:17 - 1.100
>+++ ospfd.c26 Oct 2018 15:10:08 -
>@@ -278,6 +278,13 @@ main(int argc, char *argv[])
> fatalx("control socket setup failed");
> main_imsg_compose_ospfe_fd(IMSG_CONTROLFD, 0, control_fd);
>
>+ if (unveil(conffile, "r") == -1)
>+ fatal("unveil");
>+ if (unveil(ospfd_conf->csock, "c") == -1)
>+ fatal("unveil");
>+ if (unveil(NULL, NULL) == -1)
>+ fatal("unveil");
>+
> if (kr_init(!(ospfd_conf->flags & OSPFD_FLAG_NO_FIB_UPDATE),
> ospfd_conf->rdomain, ospfd_conf->redist_label_or_prefix) == -1)
> fatalx("kr_init failed");
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
unveil ospfd's parent proc
Hi,
this restricts ospfd's parent process to only read it's config file (reload)
and unlink the control socket on exit. I added unveil after the setup of
the control socket is done since chmod is used in control_init.
OK?
Remi
Index: ospfd.c
===
RCS file: /cvs/src/usr.sbin/ospfd/ospfd.c,v
retrieving revision 1.100
diff -u -p -r1.100 ospfd.c
--- ospfd.c 29 Aug 2018 08:43:17 - 1.100
+++ ospfd.c 26 Oct 2018 15:10:08 -
@@ -278,6 +278,13 @@ main(int argc, char *argv[])
fatalx("control socket setup failed");
main_imsg_compose_ospfe_fd(IMSG_CONTROLFD, 0, control_fd);
+ if (unveil(conffile, "r") == -1)
+ fatal("unveil");
+ if (unveil(ospfd_conf->csock, "c") == -1)
+ fatal("unveil");
+ if (unveil(NULL, NULL) == -1)
+ fatal("unveil");
+
if (kr_init(!(ospfd_conf->flags & OSPFD_FLAG_NO_FIB_UPDATE),
ospfd_conf->rdomain, ospfd_conf->redist_label_or_prefix) == -1)
fatalx("kr_init failed");
Re: i386: build working kernel with lld
> Date: Fri, 26 Oct 2018 16:38:03 +0200
> From: Christian Weisgerber
>
> Mark Kettenis:
>
> > I wonder though whether we can simply replace ENTRY(start_phys) with
> > ENTRY(start) like we do on amd64. The bootloader strips the high bits
> > from the entry point address already, so using the virtual address as
> > the entry point address should work.
>
> /me builds & boots kernel ...
> Yes, that works.
Works here as well (with ld.bfd) ;)
ok kettenis@
> Index: sys/arch/i386/conf/ld.script
> ===
> RCS file: /cvs/src/sys/arch/i386/conf/ld.script,v
> retrieving revision 1.9
> diff -u -p -r1.9 ld.script
> --- sys/arch/i386/conf/ld.script 11 Apr 2018 15:44:08 - 1.9
> +++ sys/arch/i386/conf/ld.script 26 Oct 2018 14:26:37 -
> @@ -41,9 +41,7 @@ __ALIGN_SIZE = 0x1000;
> __kernel_base_virt = 0xd020 + SIZEOF_HEADERS;
> __kernel_base_phys = __kernel_base_virt & 0xfff;
>
> -/* We use physical address to jump to kernel */
> -start_phys = LOADADDR(.text) + (start - __kernel_base_virt);
> -ENTRY(start_phys)
> +ENTRY(start)
> SECTIONS
> {
> __kernel_text_virt = __kernel_base_virt;
> --
> Christian "naddy" Weisgerber na...@mips.inka.de
>
Re: i386: build working kernel with lld
I am a little surprised, but if it works..
> > I wonder though whether we can simply replace ENTRY(start_phys) with
> > ENTRY(start) like we do on amd64. The bootloader strips the high bits
> > from the entry point address already, so using the virtual address as
> > the entry point address should work.
>
> /me builds & boots kernel ...
> Yes, that works.
>
> Index: sys/arch/i386/conf/ld.script
> ===
> RCS file: /cvs/src/sys/arch/i386/conf/ld.script,v
> retrieving revision 1.9
> diff -u -p -r1.9 ld.script
> --- sys/arch/i386/conf/ld.script 11 Apr 2018 15:44:08 - 1.9
> +++ sys/arch/i386/conf/ld.script 26 Oct 2018 14:26:37 -
> @@ -41,9 +41,7 @@ __ALIGN_SIZE = 0x1000;
> __kernel_base_virt = 0xd020 + SIZEOF_HEADERS;
> __kernel_base_phys = __kernel_base_virt & 0xfff;
>
> -/* We use physical address to jump to kernel */
> -start_phys = LOADADDR(.text) + (start - __kernel_base_virt);
> -ENTRY(start_phys)
> +ENTRY(start)
> SECTIONS
> {
> __kernel_text_virt = __kernel_base_virt;
> --
> Christian "naddy" Weisgerber na...@mips.inka.de
>
Re: i386: build working kernel with lld
Mark Kettenis:
> I wonder though whether we can simply replace ENTRY(start_phys) with
> ENTRY(start) like we do on amd64. The bootloader strips the high bits
> from the entry point address already, so using the virtual address as
> the entry point address should work.
/me builds & boots kernel ...
Yes, that works.
Index: sys/arch/i386/conf/ld.script
===
RCS file: /cvs/src/sys/arch/i386/conf/ld.script,v
retrieving revision 1.9
diff -u -p -r1.9 ld.script
--- sys/arch/i386/conf/ld.script11 Apr 2018 15:44:08 - 1.9
+++ sys/arch/i386/conf/ld.script26 Oct 2018 14:26:37 -
@@ -41,9 +41,7 @@ __ALIGN_SIZE = 0x1000;
__kernel_base_virt = 0xd020 + SIZEOF_HEADERS;
__kernel_base_phys = __kernel_base_virt & 0xfff;
-/* We use physical address to jump to kernel */
-start_phys = LOADADDR(.text) + (start - __kernel_base_virt);
-ENTRY(start_phys)
+ENTRY(start)
SECTIONS
{
__kernel_text_virt = __kernel_base_virt;
--
Christian "naddy" Weisgerber na...@mips.inka.de
Re: Fix i386 kernel build on amd64
> Date: Fri, 26 Oct 2018 14:01:07 +0200
> From: Christian Weisgerber
>
> Correct linker emulation name for lld when building i386 kernels
> on amd64.
ok kettenis@
>
> (Does anybody build i386 kernels on amd64? Apparently nobody has
> since the lld switch.)
Well, I did, and had the same diff in my tree ;).
> Index: sys/arch/i386/conf/Makefile.i386
> ===
> RCS file: /cvs/src/sys/arch/i386/conf/Makefile.i386,v
> retrieving revision 1.128
> diff -u -p -r1.128 Makefile.i386
> --- sys/arch/i386/conf/Makefile.i386 16 Oct 2018 16:39:18 - 1.128
> +++ sys/arch/i386/conf/Makefile.i386 25 Oct 2018 20:35:28 -
> @@ -52,7 +52,7 @@ LINKFLAGS= -T ld.script -X --warn-common
> .if ${MACHINE} == "amd64"
> CFLAGS+= -m32
> AFLAGS+= -m32
> -LDFLAGS= -melf_i386_obsd
> +LDFLAGS= -melf_i386
> LINKFLAGS+= ${LDFLAGS}
> .endif
>
> --
> Christian "naddy" Weisgerber na...@mips.inka.de
>
>
Re: i386: build working kernel with lld
> Date: Fri, 26 Oct 2018 13:55:08 +0200
> From: Christian Weisgerber
>
> Move the calculation of the entry point to after the description
> of the .text section. LOADADDR(.text) is not available earlier
> with lld.
>
> With this, lld builds working kernels on i386.
>
> Also: Should this be __start_phys? It seems odd that we put a
> non-reserved symbol into the kernel namespace. start_phys is not
> referenced anywhere by the kernel code and this is the only place
> it appears in the source tree.
Doesn't really matter for the kernel.
I wonder though whether we can simply replace ENTRY(start_phys) with
ENTRY(start) like we do on amd64. The bootloader strips the high bits
from the entry point address already, so using the virtual address as
the entry point address should work.
> Index: sys/arch/i386/conf/ld.script
> ===
> RCS file: /cvs/src/sys/arch/i386/conf/ld.script,v
> retrieving revision 1.9
> diff -u -p -r1.9 ld.script
> --- sys/arch/i386/conf/ld.script 11 Apr 2018 15:44:08 - 1.9
> +++ sys/arch/i386/conf/ld.script 25 Oct 2018 20:35:18 -
> @@ -41,8 +41,6 @@ __ALIGN_SIZE = 0x1000;
> __kernel_base_virt = 0xd020 + SIZEOF_HEADERS;
> __kernel_base_phys = __kernel_base_virt & 0xfff;
>
> -/* We use physical address to jump to kernel */
> -start_phys = LOADADDR(.text) + (start - __kernel_base_virt);
> ENTRY(start_phys)
> SECTIONS
> {
> @@ -56,6 +54,8 @@ SECTIONS
> locore0.o(.text)
> *(.text .text.*)
> } :text =0x
> + /* We use physical address to jump to kernel */
> + start_phys = LOADADDR(.text) + (start - __kernel_base_virt);
>
> . = ALIGN(__ALIGN_SIZE);
> __kernel_kutext_phys = . & 0xfff;
> --
> Christian "naddy" Weisgerber na...@mips.inka.de
>
>
Fix i386 kernel build on amd64
Correct linker emulation name for lld when building i386 kernels
on amd64.
(Does anybody build i386 kernels on amd64? Apparently nobody has
since the lld switch.)
Index: sys/arch/i386/conf/Makefile.i386
===
RCS file: /cvs/src/sys/arch/i386/conf/Makefile.i386,v
retrieving revision 1.128
diff -u -p -r1.128 Makefile.i386
--- sys/arch/i386/conf/Makefile.i38616 Oct 2018 16:39:18 - 1.128
+++ sys/arch/i386/conf/Makefile.i38625 Oct 2018 20:35:28 -
@@ -52,7 +52,7 @@ LINKFLAGS=-T ld.script -X --warn-common
.if ${MACHINE} == "amd64"
CFLAGS+= -m32
AFLAGS+= -m32
-LDFLAGS= -melf_i386_obsd
+LDFLAGS= -melf_i386
LINKFLAGS+=${LDFLAGS}
.endif
--
Christian "naddy" Weisgerber na...@mips.inka.de
i386: build working kernel with lld
Move the calculation of the entry point to after the description
of the .text section. LOADADDR(.text) is not available earlier
with lld.
With this, lld builds working kernels on i386.
Also: Should this be __start_phys? It seems odd that we put a
non-reserved symbol into the kernel namespace. start_phys is not
referenced anywhere by the kernel code and this is the only place
it appears in the source tree.
Index: sys/arch/i386/conf/ld.script
===
RCS file: /cvs/src/sys/arch/i386/conf/ld.script,v
retrieving revision 1.9
diff -u -p -r1.9 ld.script
--- sys/arch/i386/conf/ld.script11 Apr 2018 15:44:08 - 1.9
+++ sys/arch/i386/conf/ld.script25 Oct 2018 20:35:18 -
@@ -41,8 +41,6 @@ __ALIGN_SIZE = 0x1000;
__kernel_base_virt = 0xd020 + SIZEOF_HEADERS;
__kernel_base_phys = __kernel_base_virt & 0xfff;
-/* We use physical address to jump to kernel */
-start_phys = LOADADDR(.text) + (start - __kernel_base_virt);
ENTRY(start_phys)
SECTIONS
{
@@ -56,6 +54,8 @@ SECTIONS
locore0.o(.text)
*(.text .text.*)
} :text =0x
+ /* We use physical address to jump to kernel */
+ start_phys = LOADADDR(.text) + (start - __kernel_base_virt);
. = ALIGN(__ALIGN_SIZE);
__kernel_kutext_phys = . & 0xfff;
--
Christian "naddy" Weisgerber na...@mips.inka.de
bgpd, add *-set memory usage to the show rib mem output
This adds the memory consumed by any kind of as-set, prefix-set,
origin-set or roa-set to the output of show rib mem.
Here the output of a system that has RPKI ROA loaded.
RDE memory statistics
714982 IPv4 unicast network entries using 27.3M of memory
56393 IPv6 unicast network entries using 3.0M of memory
1526718 rib entries using 93.2M of memory
3053428 prefix entries using 280M of memory
270426 BGP path attribute entries using 28.9M of memory
112881 BGP AS-PATH attribute entries using 5.2M of memory,
and holding 270426 references
18337 BGP attributes entries using 716K of memory
and holding 330395 references
18336 BGP attributes using 252K of memory
61415 as-set elements in 57669 tables using 1.8M of memory
102389 prefix-set elments using 4.3M of memory
RIB using 438M of memory
Sets using 6.0M of memory
--
:wq Claudio
Index: bgpctl/bgpctl.c
===
RCS file: /cvs/src/usr.sbin/bgpctl/bgpctl.c,v
retrieving revision 1.219
diff -u -p -r1.219 bgpctl.c
--- bgpctl/bgpctl.c 1 Oct 2018 23:09:53 - 1.219
+++ bgpctl/bgpctl.c 26 Oct 2018 11:09:07 -
@@ -1875,12 +1875,19 @@ show_rib_memory_msg(struct imsg *imsg)
(long long)stats.attr_refs);
printf("%10lld BGP attributes using %s of memory\n",
(long long)stats.attr_dcnt, fmt_mem(stats.attr_data));
+ printf("%10lld as-set elements in %lld tables using "
+ "%s of memory\n", stats.aset_nmemb, stats.aset_cnt,
+ fmt_mem(stats.aset_size));
+ printf("%10lld prefix-set elments using %s of memory\n",
+ stats.pset_cnt, fmt_mem(stats.pset_size));
printf("RIB using %s of memory\n", fmt_mem(pts +
stats.prefix_cnt * sizeof(struct prefix) +
stats.rib_cnt * sizeof(struct rib_entry) +
stats.path_cnt * sizeof(struct rde_aspath) +
stats.aspath_size + stats.attr_cnt * sizeof(struct attr) +
stats.attr_data));
+ printf("Sets using %s of memory\n", fmt_mem(stats.aset_size +
+ stats.pset_size));
printf("\nRDE hash statistics\n");
break;
case IMSG_CTL_SHOW_RIB_HASH:
Index: bgpd/bgpd.h
===
RCS file: /cvs/src/usr.sbin/bgpd/bgpd.h,v
retrieving revision 1.349
diff -u -p -r1.349 bgpd.h
--- bgpd/bgpd.h 3 Oct 2018 11:36:39 - 1.349
+++ bgpd/bgpd.h 26 Oct 2018 11:23:53 -
@@ -1077,6 +1077,11 @@ struct rde_memstats {
int64_t attr_refs;
int64_t attr_data;
int64_t attr_dcnt;
+ int64_t aset_cnt;
+ int64_t aset_size;
+ int64_t aset_nmemb;
+ int64_t pset_cnt;
+ int64_t pset_size;
};
struct rde_hashstats {
Index: bgpd/rde_sets.c
===
RCS file: /cvs/src/usr.sbin/bgpd/rde_sets.c,v
retrieving revision 1.5
diff -u -p -r1.5 rde_sets.c
--- bgpd/rde_sets.c 20 Sep 2018 11:45:59 - 1.5
+++ bgpd/rde_sets.c 26 Oct 2018 11:01:26 -
@@ -125,6 +125,8 @@ set_new(size_t nmemb, size_t size)
return NULL;
}
+ rdemem.aset_cnt++;
+ rdemem.aset_size += sizeof(*set);
return set;
}
@@ -133,6 +135,10 @@ set_free(struct set_table *set)
{
if (set == NULL)
return;
+ rdemem.aset_cnt--;
+ rdemem.aset_size -= sizeof(*set);
+ rdemem.aset_size -= set->size * set->max;
+ rdemem.aset_nmemb -= set->nmemb;
free(set->set);
free(set);
}
@@ -154,6 +160,7 @@ set_add(struct set_table *set, void *elm
s = reallocarray(set->set, new_size, set->size);
if (s == NULL)
return -1;
+ rdemem.aset_size += set->size * (new_size - set->max);
set->set = s;
set->max = new_size;
}
@@ -161,6 +168,7 @@ set_add(struct set_table *set, void *elm
memcpy((u_int8_t *)set->set + set->nmemb * set->size, elms,
nelms * set->size);
set->nmemb += nelms;
+ rdemem.aset_nmemb += nelms;
return 0;
}
Index: bgpd/rde_trie.c
===
RCS file: /cvs/src/usr.sbin/bgpd/rde_trie.c,v
retrieving revision 1.9
diff -u -p -r1.9 rde_trie.c
--- bgpd/rde_trie.c 29 Sep 2018 08:11:11 - 1.9
+++ bgpd/rde_trie.c 26 Oct 2018 10:49:20 -
@@ -165,6 +165,8 @@ trie_add_v4(struct trie_head *th, struct
*/
if ((b = calloc(1, sizeof(*b))) == NULL)
return NULL;
+ rdemem.pset_cnt++;
+ rdemem.pset_size +=
Mininet Topology
For some reason I am having a hard time running mininet which produces the
forwarding rules.
Anyways here is my code:
import java.io.File;
import java.io.PrintWriter;
import java.io.FileWriter;
import java.util.Collections;
import java.util.LinkedList;
public class Forwarding {
static void dieUsage() {
System.err.println("Usage:");
System.err.println("java Forwarding [dotfile]");
System.err.println("(depth and fanout must be integers >= 1)");
System.exit(1);
}
public static void main(String[] argv) {
int depth = -1;
int fanout = -1;
String filename = null;
if(argv.length >= 2) {
depth = Integer.parseInt(argv[0]);
fanout = Integer.parseInt(argv[1]);
} else dieUsage();
if(depth < 1 || fanout < 1) dieUsage();
if(argv.length >= 3) {
filename = argv[2];
}
TreeNode root = new TreeNode();
root.build(depth, fanout);
System.out.println(root);
if(filename != null) {
root.saveDOT(new File(filename));
}
LinkedList leaves = root.getLeaves(); // these are the
HOSTS
// TODO:
// Go through each unique pair (src,dst) of leaves, and compute the
path from src to dst.
// For a single path, you can use the Interface class to store each
hop on the path (iface can be used for
// the input interface, and iface2 can be used for the output
interface).
System.out.println (sudo dpctl add-flow unix:/tmp/s2
"idle_timeout=0,hard_timeout=0,in_port=1,ip,nw_src=10.0.0.1,nw_dst=10.0.0.3,actions=output:3"
sudo dpctl add-flow unix:/tmp/s1
"idle_timeout=0,hard_timeout=0,in_port=1,ip,nw_src=10.0.0.1,nw_dst=10.0.0.3,actions=output:2"
sudo dpctl add-flow unix:/tmp/s3
"idle_timeout=0,hard_timeout=0,in_port=3,ip,nw_src=10.0.0.1,nw_dst=10.0.0.3,actions=output:1"
sudo dpctl add-flow unix:/tmp/s2
"idle_timeout=0,hard_timeout=0,in_port=1,arp,nw_src=10.0.0.1,nw_dst=10.0.0.3,actions=output:3"
sudo dpctl add-flow unix:/tmp/s1
"idle_timeout=0,hard_timeout=0,in_port=1,arp,nw_src=10.0.0.1,nw_dst=10.0.0.3,actions=output:2"
sudo dpctl add-flow unix:/tmp/s3
"idle_timeout=0,hard_timeout=0,in_port=3,arp,nw_src=10.0.0.1,nw_dst=10.0.0.3,actions=output:1"
sudo dpctl add-flow unix:/tmp/s3
"idle_timeout=0,hard_timeout=0,in_port=1,ip,nw_src=10.0.0.3,nw_dst=10.0.0.1,actions=output:3"
sudo dpctl add-flow unix:/tmp/s1
"idle_timeout=0,hard_timeout=0,in_port=2,ip,nw_src=10.0.0.3,nw_dst=10.0.0.1,actions=output:1"
sudo dpctl add-flow unix:/tmp/s2
"idle_timeout=0,hard_timeout=0,in_port=3,ip,nw_src=10.0.0.3,nw_dst=10.0.0.1,actions=output:1"
sudo dpctl add-flow unix:/tmp/s3
"idle_timeout=0,hard_timeout=0,in_port=1,arp,nw_src=10.0.0.3,nw_dst=10.0.0.1,actions=output:3"
sudo dpctl add-flow unix:/tmp/s1
"idle_timeout=0,hard_timeout=0,in_port=2,arp,nw_src=10.0.0.3,nw_dst=10.0.0.1,actions=output:1"
sudo dpctl add-flow unix:/tmp/s2
"idle_timeout=0,hard_timeout=0,in_port=3,arp,nw_src=10.0.0.3,nw_dst=10.0.0.1,actions=output:1")
public void printAllPaths(int src, int dst)
{
boolean[] isVisited = new boolean[v];
ArrayList pathList = new ArrayList<>();
pathList.add(s);
printAllPathsUtil(src, dst, iface2);
}
}
class Interface {
int iface;
TreeNode node;
private int iface2 = 0;
Interface(TreeNode node) {
this(0, node);
}
Interface(int iface, TreeNode node) {
this.iface = iface;
this.node = node;
}
Interface(int iface1, TreeNode node, int iface2) {
this.iface = iface1;
this.iface2 = iface2;
this.node = node;
}
int getIface2() {
return iface2;
}
void setIface2(int iface2) {
this.iface2 = iface2;
}
public String toString() {
String s;
if(iface2 == 0) s= String.format("(%d->%s)", iface, node.getName());
else s = String.format("(%d->%s->%d)", iface, node.getName(),
iface2);
return s;
}
}
class TreeNode {
private Interface parent;
int id;
LinkedList children = new LinkedList();
boolean isLeaf;
private static int routerId;
private static int hostId;
TreeNode() {
this.parent = null;
this.id = 1;
}
TreeNode(TreeNode parent, int id) {
this(parent, id, false);
}
TreeNode(TreeNode parent, int id, boolean isLeaf) {
this.parent = new Interface(parent);
this.id = id;
this.isLeaf = isLeaf;
updateParent();
}
int getChildInterface(TreeNode child) {
for(Interface i : children) {
if(child.equals(i.node)) return i.iface;
}
return 0;
}
TreeNode getParent() {
return (parent != null ? parent.node : null);
}
int getParentInterface() {
return (parent != null ? parent.iface : 0);
}
void addChild(TreeNode n) {
int i = children.size() +
bgpd, correct object in sizeof()
Found by accident or actually a tree where there is no struct aspath_queue
anymore. pathtable.path_hashtbl is a struct aspath_head.
OK?
--
:wq Claudio
Index: rde_rib.c
===
RCS file: /cvs/src/usr.sbin/bgpd/rde_rib.c,v
retrieving revision 1.180
diff -u -p -r1.180 rde_rib.c
--- rde_rib.c 24 Oct 2018 08:26:37 - 1.180
+++ rde_rib.c 26 Oct 2018 07:00:51 -
@@ -477,7 +477,7 @@ path_init(u_int32_t hashsize)
for (hs = 1; hs < hashsize; hs <<= 1)
;
- pathtable.path_hashtbl = calloc(hs, sizeof(struct aspath_queue));
+ pathtable.path_hashtbl = calloc(hs, sizeof(*pathtable.path_hashtbl));
if (pathtable.path_hashtbl == NULL)
fatal("path_init");
