as i understand, kernel relinking currently used object file and installs new kernel. what i do not understand is how could it 'rollback' kernel changes done during compilation, if it using current object files which arre built during compilation.
Just one note, i not yet rebooted after re-linking done, because of created domains are working (the traffic on them), just userland does not, and im afraid they will fail to create after reboot and i should repeat userland rebuild again. вт, 19 мая 2020 г. в 11:21, Bars Bars <[email protected]>: > it seems i figured out why userland was 'broken' on recompiled kernel > with changed RT_TABLEID_MAX. > I dont think things are really broken, may be i dont them right way, > please advice. > > I could reproduce the issue (all steps are done exactly as in openbsd.org > faq). > I changed RT_TABLEID_MAX, recompiled the kernel, booted from it, and > change didnt work on userland. > Then i rebuilt userland, rebooted, all works now. > Now if i apply some patch from errata, there is kernel re-linking done, > and just after that kernel change doesnt work. > Is it expected behavior? How can i fix it? syspacth -r doesnt help. > > > > пн, 18 мая 2020 г. в 13:31, Bars Bars <[email protected]>: > >> To be more convinient, when i said about that its limit became shorter >> its relevant to sys/net/rtable.c struct dommp. >> struct dommp { >> unsigned int limit; >> /* >> * Array to get the routing domain and loopback interface related >> to >> * a routing table. Format: >> * >> * 8 unused bits | 16 bits for loopback index | 8 bits for rdomain >> */ >> unsigned int *value; >> }; >> >> In past the maxumum value was limited to u_int16_t in some deep places, >> but nowadays there is only 8 bits allocated to it based on the struct + 8 >> unused bits which i hop i can safely add to allocation. >> I worried these unused bits are not guaranteed to users, so actually the >> limit is 8 bits instead of 16 in earlier releases. >> >> >> >> пн, 18 мая 2020 г. в 11:51, Bars Bars <[email protected]>: >> >>> Hi, Claudio >>> >>> I mean these in sys/socket.h >>> /* >>> * Maximum number of alternate routing tables >>> */ >>> #define RT_TABLEID_MAX 8000 >>> #define RT_TABLEID_BITS 16 >>> #define RT_TABLEID_MASK 0xffff >>> >>> >>> пн, 18 мая 2020 г. в 10:18, Claudio Jeker <[email protected]>: >>> >>>> On Sun, May 17, 2020 at 10:16:28PM +0300, Bars Bars wrote: >>>> > it seems the things work just when i rebuild userland completely (im >>>> pretty >>>> > sure i did it only with compiling kernel in past, correct me if i >>>> wrong?). >>>> > >>>> > btw, questions for the Devs. >>>> > Looking at the cvs history, i really worried that you do not expand >>>> > rt_tableid_max limit for the years, moreover now its actually 8 bits >>>> > shorter than it was before loopback to rdomain map. There are many >>>> people >>>> > with more than such a number of vpns, for example if they setup >>>> centralized >>>> > vpns setup, or border inter AS router role on the box. >>>> >>>> Sorry your mail is incredibly inprecise and unclear. There is no >>>> rt_tableid_max in OpenBSD at least not in my tree (grep -r >>>> rt_tableid_max >>>> returned nothing). So I have no idea what you are talking about and am >>>> therefor not able to give you a better answer. >>>> >>>> > вс, 17 мая 2020 г., 10:25 Bars Bars <[email protected]>: >>>> > >>>> > > Hey, guys. >>>> > > >>>> > > I always used the rt_tableid_max expanded to 16 bit range in past >>>> releases >>>> > > 5.x and after rebuilding the kernel it worked immediately. >>>> > > But now I installed 6.6 on the new system, and after changing >>>> > > rt_tableid_max (and new rt_tableid_mask and bits values too), my >>>> whole >>>> > > userland throw an rtable / rdomain too large error. >>>> > > Is there behaviour change? >>>> > > The only thing changed (as i know) it is news net/trable.c struct >>>> to map >>>> > > loopback to domain, where there is only 8 unused bits to which i >>>> can expand >>>> > > tableid value. >>>> > > >>>> > > >>>> >>>> -- >>>> :wq Claudio >>>> >>>
