Re: Request for testing an alternate branch
6 дек. 2013 г., в 23:40, Justin Hibbits jhibb...@freebsd.org написал(а): On Wed, Dec 4, 2013 at 10:19 PM, Justin Hibbits jhibb...@freebsd.org wrote: I've been working on the projects/pmac_pmu branch for some time now to add suspend/resume as well as CPU speed change for certain PowerPC machines, about a year since I created the branch, and now it's stable enough that I want to merge it into HEAD, hence this request. Thanks for your work! What is the estimated time when it will go HEAD? May I expect that my powerbook4,1 machine will get ability to sleep under the FreeBSD now? However, it does touch several drivers, turning them into early drivers, such that they can be initialized, and suspended and resumed at a different time. Saying that, I do need testing from other architectures, to make sure I haven't broken anything. The technical details: To get proper ordering, I've extended the bus_generic_suspend() and bus_generic_resume() to do multiple passes. Devices which cannot be enabled or disabled at the current pass level would return an EAGAIN. This could possibly cause problems, since it's an addition to an existing API rather than a new API to run along side it, so it needs a great deal of testing. It works fine on PowerPC, but I don't have any i386/amd64 or sparc64 hardware to test it on, so would like others who do to test it. I don't thin Also, any comments are of course welcome. Technical concerns are obviously welcome, and I will try to address everything. Thanks, Justin Thanks to hrs@, images are now available for the pmac_pmu project on allbsd for i386, amd64, sparc64, and ia64: https://pub.allbsd.org/FreeBSD-snapshots/ . I understand that you provided these so people with another archs could test whether it doesn't break anything, but what about actual PPC users? ;) Considering that powerpc is a Tier 2 these days, it's not that easy even to get svn quickly for it to grab your tree, so I would ask adding projects_pmac_pmu to the powerpc building. Thanks. - Justin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: sbuf-related panic
Craig Rodrigues rodr...@freebsd.org writes: On Tue, Mar 17, 2015 at 11:49 AM, Mark Felder f...@freebsd.org wrote: On Mon, Mar 16, 2015, at 13:03, Shawn Webb wrote: On amd64, doing a Poudriere run. On r280133: I appeared to be hitting this on 280130, the most recent CURRENT snapshot. I'm going to build the latest since some sbuf fixes have landed and see if I can finish a poudriere build run. The Jenkins build which boots a VM and runs the kyua tests is kernel panicking in sbuf as well: https://jenkins.freebsd.org/job/FreeBSD_HEAD-tests2/853/console Why those builds do not contain svn revision or git commit? FreeBSD 11.0-CURRENT #26: Tue Mar 17 08:06:04 UTC 2015 jenk...@jenkins-10.freebsd.org:/builds/FreeBSD_HEAD/obj/builds/FreeBSD_HEAD/sys/GENERIC amd64 Maybe I have overlooked something, but with svn or git revision/commit bisection would be very simple. -- Nikola ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Clang 3.6.0 for ARMv7 failure
Hi, every couple of days I rebase to the head of the -current and this time I encountered a problem during toolchain build related probably to the recent compiler changes. As I am mainly interested in building kernel I just switched to kernel-toolchain which worked fine for me, but anyway, this looks like a wider problem. Maybe I am missing some transition option - previous builds were fine - if so I would be happy to hear any pointers to fix it locally. Below is the error report. Thank you, Jakub Palider Unexpected member type for HA UNREACHABLE executed at /root/jpa/anpa-fbsd/lib/clang/libllvmarmcodegen/../../../contrib/llvm/lib/Target/ARM/ARMCallingConv.h:209! Stack dump: 0. Program arguments: /home/jpa/anpa-build/arm.arm/root/jpa/anpa-fbsd/tmp/usr/bin/cc -cc1 -triple armv6--freebsd11.0-gnueabi -emit-obj -disable-free -main-file-name b_tgamma.c -mrelocation-model pic -pic-level 1 -mthread-model posix -mdisable-fp-elim -masm-verbose -mconstructor-aliases -target-cpu arm1176jzf-s -target-feature +soft-float -target-feature +soft-float-abi -target-feature -neon -target-feature -crypto -target-abi aapcs-linux -msoft-float -mfloat-abi soft -dwarf-column-info -coverage-file /home/jpa/anpa-build/arm.arm/root/jpa/anpa-fbsd/lib/msun/b_tgamma.So -resource-dir /home/jpa/anpa-build/arm.arm/root/jpa/anpa-fbsd/tmp/usr/bin/../lib/clang/3.6.0 -D PIC -D ARM_ARCH_6=1 -I /home/jpa/anpa-fbsd/lib/msun/src -I /home/jpa/anpa-fbsd/lib/msun/../libc/include -I /home/jpa/anpa-fbsd/lib/msun/../libc/arm -isysroot /home/jpa/anpa-build/arm.arm/root/jpa/anpa-fbsd/tmp -O2 -Wsystem-headers -Werror -Wno-pointer-sign -Wno-unknown-pragmas -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-varia ble -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -std=gnu99 -fdebug-compilation-dir /home/jpa/anpa-build/arm.arm/root/jpa/anpa-fbsd/lib/msun -ferror-limit 19 -fmessage-length 0 -mstackrealign -fno-signed-char -fobjc-runtime=gnustep -fdiagnostics-show-option -vectorize-loops -vectorize-slp -o b_tgamma.So -x c /home/jpa/anpa-fbsd/lib/msun/bsdsrc/b_tgamma.c ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: What parts of UMA are part of the stable ABI?
On Friday, March 13, 2015 07:48:38 PM Ryan Stone wrote: In this freebsd-hackers thread[1], a user reported that 10.1-RELEASE crashes during boot on a system with 3TB of RAM. As it turns out, when you have that much RAM ZFS autotunes itself to allocate a 6GB hash table. This triggers a nasty 32-bit integer truncation bug in malloc(9). malloc() calls uma_large_malloc(), but uma_large_malloc() accepts an int instead of a size_t and all kinds of hilarity can ensure from there. The user has confirmed that the page in [2] fixed the kernel from instantly panicking once zfs.ko was loaded. I'm a bit concerned about whether the patch as written is an MFC candidate though. uma_large_malloc() calls page_alloc() to actuallly allocate the memory, and page_alloc() also accepts an int size parameter. This is where things get tricky. The signature for page_alloc() is governed by the uma_alloc() typedef, as uma also uses it internally for allocating memory for uma_zones. There is even a uma_zone_set_allocf() API for overriding the default allocation function. So there's definitely an argument to be made the the signature of page_alloc() being a part of the stable ABI. I have no hesitation in saying that uma_large_malloc() is not a stable API and changing it is fair game. If uma_alloc() is a part of the stable API, then it's simple enough to commit a 64-bit safe allocation function for uma_large_malloc() to call and changing page_alloc() to call it instead. That commit can be MFC'ed, and a follow-up commit could convert the UMA APIs to use size_t everywhere. I think uma_zone_set_allocf() is most likely obscure enough to not be used outside of the places in the kernel where it is used. From that, I think you are fine to change uma_alloc()'s signature. While I am at this, I'd like to also change the uma init/fini/ctor/dtor to also use size_t. I'm a little torn on this because this will definitely cause a lot of churn, both in the tree and for downstream consumers, and there's not necessarily going to be a big benefit to it. However, I suppose that the existence of machines where 4GB is less than 1% of system memory may mean that allocating 4GB at a time may not that outlandish. I can definitely be talked out of this though. I do think the normal zone callbacks passed to uma_zcreate() are too public to change. Or at least, you would need to do some crazy ABI shim where you have a uma_zcreate_new() that you map to uma_zcreate() via a #define for the API, but include a legacy uma_zcreate() symbol that older modules can call (and then somehow tag the old function pointers via an internal flag in the zone and patch UMA to cast to the old function signatures for zones with that flag). Note that if you are really paranoid you could do the same thing with uma_zone_set_allocf(). It would break the API, but would preserve the ABI (i.e. leave an existing uma_zone_set_allocf() function that accepts the old prototype but have a uma_zone_set_allocf_new() that gets mapped to uma_zone_set_allocf via a #define). -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [PATCH] Convert the VFS cache lock to an rmlock
On Friday, March 13, 2015 06:32:03 AM Mateusz Guzik wrote: On Thu, Mar 12, 2015 at 06:13:00PM -0500, Alan Cox wrote: Below is partial results from a profile of a parallel (-j7) buildworld on a 6-core machine that I did after the introduction of pmap_advise, so this is not a new profile. The results are sorted by total waiting time and only the top 20 entries are listed. Well, I ran stuff on lynx2 in the zoo on fresh -head with debugging disabled (MALLOC_PRODUCTION included) and got quite different results. The machine is Intel(R) Xeon(R) CPU E5-2680 v2 @ 2.80GHz 2 package(s) x 10 core(s) x 2 SMT threads 32GB of ram Stuff was built in a chroot with world hosted on zfs. max wait_max total wait_total countavg wait_avg cnt_hold cnt_lock name 102720850016292932 1658585700 5297163 3313 0 3313855 kern/vfs_cache.c:629 (rw:Name Cache) 208564186514 19080891106 1129189627 355575930 53 3 0 1323051 kern/vfs_subr.c:2099 (lockmgr:ufs) 169241148057 193721142 41907544913819553 14 30 0 110089 kern/vfs_subr.c:2210 (lockmgr:ufs) 187092191775 1923061952 257319238 328416784 5 0 0 5106537 kern/vfs_cache.c:488 (rw:Name Cache) make -j 12 buildworld on freshly booted system (i.e. the most namecache insertions): 32 292 304201933400306 8419725 0 3 0 2578026 kern/sys_pipe.c:1438 (sleep mutex:pipe mutex) 170608152572 64238574427054977 202605015 3 0 0 1306662 kern/vfs_subr.c:2176 (lockmgr:zfs) You are using ZFS, Alan was using UFS. It would not surprise me that those would perform quite differently, and it would not surprise me that UFS is more efficient in terms of its interactions with the VM. -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: What parts of UMA are part of the stable ABI?
On Wed, Mar 18, 2015 at 10:24 AM, John Baldwin j...@freebsd.org wrote: I do think the normal zone callbacks passed to uma_zcreate() are too public to change. Or at least, you would need to do some crazy ABI shim where you have a uma_zcreate_new() that you map to uma_zcreate() via a #define for the API, but include a legacy uma_zcreate() symbol that older modules can call (and then somehow tag the old function pointers via an internal flag in the zone and patch UMA to cast to the old function signatures for zones with that flag). I really wasn't clear here. I definitely don't think that changing the ctor, etc to accept a size_t is MFC'able, and I don't think that the problem (which is really only theoretical at this point) warrants an MFC to -stable. I was talking about potentially doing it in a separate commit to head, but that does leave -stable and head with a different API. This can be painful for downstream consumers to deal with, which is why I wanted comments. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Request for testing an alternate branch
On Wed, Mar 18, 2015 at 12:12 AM, lausg...@gmail.com wrote: 6 дек. 2013 г., в 23:40, Justin Hibbits jhibb...@freebsd.org написал(а): On Wed, Dec 4, 2013 at 10:19 PM, Justin Hibbits jhibb...@freebsd.org wrote: I've been working on the projects/pmac_pmu branch for some time now to add suspend/resume as well as CPU speed change for certain PowerPC machines, about a year since I created the branch, and now it's stable enough that I want to merge it into HEAD, hence this request. Thanks for your work! What is the estimated time when it will go HEAD? May I expect that my powerbook4,1 machine will get ability to sleep under the FreeBSD now? However, it does touch several drivers, turning them into early drivers, such that they can be initialized, and suspended and resumed at a different time. Saying that, I do need testing from other architectures, to make sure I haven't broken anything. The technical details: To get proper ordering, I've extended the bus_generic_suspend() and bus_generic_resume() to do multiple passes. Devices which cannot be enabled or disabled at the current pass level would return an EAGAIN. This could possibly cause problems, since it's an addition to an existing API rather than a new API to run along side it, so it needs a great deal of testing. It works fine on PowerPC, but I don't have any i386/amd64 or sparc64 hardware to test it on, so would like others who do to test it. I don't thin Also, any comments are of course welcome. Technical concerns are obviously welcome, and I will try to address everything. Thanks, Justin Thanks to hrs@, images are now available for the pmac_pmu project on allbsd for i386, amd64, sparc64, and ia64: https://pub.allbsd.org/FreeBSD-snapshots/ . I understand that you provided these so people with another archs could test whether it doesn't break anything, but what about actual PPC users? ;) Considering that powerpc is a Tier 2 these days, it's not that easy even to get svn quickly for it to grab your tree, so I would ask adding projects_pmac_pmu to the powerpc building. Thanks. There were some design decisions that people took issue with, so I've been working on that. I plan to merge the bulk of the work into HEAD soon, but only the driver suspend/resume routines. The additional updates for suspending the system as a whole won't be made for some time, due to the intrusiveness of the change. I'm still planning for this to be completed for the 11.0 release, and with the bulk of the work completed, that should be feasible. I don't have a PowerBook4,1 to test with, but I think it should work, but some drivers may not resume properly. - Justin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: What parts of UMA are part of the stable ABI?
On Wednesday, March 18, 2015 11:19:21 AM Ryan Stone wrote: On Wed, Mar 18, 2015 at 10:24 AM, John Baldwin j...@freebsd.org wrote: I do think the normal zone callbacks passed to uma_zcreate() are too public to change. Or at least, you would need to do some crazy ABI shim where you have a uma_zcreate_new() that you map to uma_zcreate() via a #define for the API, but include a legacy uma_zcreate() symbol that older modules can call (and then somehow tag the old function pointers via an internal flag in the zone and patch UMA to cast to the old function signatures for zones with that flag). I really wasn't clear here. I definitely don't think that changing the ctor, etc to accept a size_t is MFC'able, and I don't think that the problem (which is really only theoretical at this point) warrants an MFC to -stable. I was talking about potentially doing it in a separate commit to head, but that does leave -stable and head with a different API. This can be painful for downstream consumers to deal with, which is why I wanted comments. I actually think the API change to fix the zone callbacks is fine to change in HEAD. I don't think that is too disruptive for folks who might be sharing code across branches (they can use a local typedef to work around it or some such). -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [PATCH] Convert the VFS cache lock to an rmlock
On Wed, Mar 18, 2015 at 10:17:22AM -0400, John Baldwin wrote: On Friday, March 13, 2015 06:32:03 AM Mateusz Guzik wrote: On Thu, Mar 12, 2015 at 06:13:00PM -0500, Alan Cox wrote: Below is partial results from a profile of a parallel (-j7) buildworld on a 6-core machine that I did after the introduction of pmap_advise, so this is not a new profile. The results are sorted by total waiting time and only the top 20 entries are listed. Well, I ran stuff on lynx2 in the zoo on fresh -head with debugging disabled (MALLOC_PRODUCTION included) and got quite different results. The machine is Intel(R) Xeon(R) CPU E5-2680 v2 @ 2.80GHz 2 package(s) x 10 core(s) x 2 SMT threads 32GB of ram Stuff was built in a chroot with world hosted on zfs. max wait_max total wait_total countavg wait_avg cnt_hold cnt_lock name 102720850016292932 1658585700 5297163 3313 0 3313855 kern/vfs_cache.c:629 (rw:Name Cache) 208564186514 19080891106 1129189627 355575930 53 3 0 1323051 kern/vfs_subr.c:2099 (lockmgr:ufs) 169241148057 193721142 41907544913819553 14 30 0 110089 kern/vfs_subr.c:2210 (lockmgr:ufs) 187092191775 1923061952 257319238 328416784 5 0 0 5106537 kern/vfs_cache.c:488 (rw:Name Cache) make -j 12 buildworld on freshly booted system (i.e. the most namecache insertions): 32 292 304201933400306 8419725 0 3 0 2578026 kern/sys_pipe.c:1438 (sleep mutex:pipe mutex) 170608152572 64238574427054977 202605015 3 0 0 1306662 kern/vfs_subr.c:2176 (lockmgr:zfs) You are using ZFS, Alan was using UFS. It would not surprise me that those would perform quite differently, and it would not surprise me that UFS is more efficient in terms of its interactions with the VM. This is lots of forks + execs and page queue has only one lock. Fwiw, ufs world backed by dedidacted parition, other conditions unchanged First build: 52 411 332757236528102 8508545 0 4 0 2587337 kern/sys_pipe.c:1438 (sleep mutex:pipe mutex) 308102308099 4303481583616 203246241 2 0 0 459200 kern/vfs_subr.c:2176 (lockmgr:ufs) 78 8184430816229968440 165009282 0 0 0 22053854 vm/vm_page.c:1502 (sleep mutex:vm page free queue) 48 2381887240528456578 164327020 0 0 0 22512151 vm/vm_page.c:2294 (sleep mutex:vm page free queue) 208 14866978086317484511 144970085 0 0 0 134429 amd64/amd64/pmap.c:4204 (rw:pmap pv global) 52 126319390169 8186840 142392234 0 0 0 11151398 vm/vm_page.c:2053 (sleep mutex:vm active pagequeue) 27 180119754927 8092312 142403798 0 0 0 9993164 vm/vm_page.c:2097 (sleep mutex:vm active pagequeue) 1145 130019872450 7158951 7690094 2 0 0 269930 vm/vm_fault.c:785 (rw:vm object) 25579 163610955717 596233612620413 0 0 0 96691 vm/vm_map.c:2883 (rw:vm object) 39 54994 1428266 5141221 368787 3 13 0 13391 kern/kern_exec.c:590 (lockmgr:ufs) 31147031151367241105 397135730997102 2 0 0 5094 kern/vfs_lookup.c:509 (lockmgr:ufs) 55 56864300400 3821394 214921016 0 0 0 2699822 kern/vfs_cache.c:487 (rw:Name Cache) 14 2224 31486 3784823 266762 0 14 0 43516 amd64/amd64/pmap.c:3767 (rw:pmap pv global) 15 1179 184521 2651974 2126398 0 1 0 31955 vm/vm_object.c:646 (rw:vm object) 43267 5463556190811 2228815 368787152 6 0 10399 kern/imgact_elf.c:829 (lockmgr:ufs) 1802 327655104622 2042552 142404165 0 0 0 543434 vm/vm_fault.c:997 (sleep mutex:vm page) 295450897307 1792095 199350363 0 0 0 2305326 kern/vfs_cache.c:668 (sleep mutex:vnode interlock) 1051 1252 3640803 1792074 1030592 3 1 0 18897 vm/vm_object.c:1703 (rw:vm object) 17 1389 269455 1778764 2828515 0 0 0 106843 vm/vm_object.c:1222 (rw:vm object) 472 144414742782 1731247 6851167 2 0 0 20011 amd64/amd64/pmap.c:3620 (rw:pmap pv global) reset + rm -r /usr/obj/* 230791100799 40514020851092446 203312369 1 0 0 472299 kern/vfs_subr.c:2176 (lockmgr:ufs) 188 80466999332741591950 144943809 0 0 0 175226 amd64/amd64/pmap.c:4204 (rw:pmap pv global) 76 6474532462435204587 164788099 0 0 0 22749884 vm/vm_page.c:1502 (sleep mutex:vm page free queue) 40 2371942844533209934
Re: What parts of UMA are part of the stable ABI?
On 3/19/15 3:28 AM, Adrian Chadd wrote: On 18 March 2015 at 08:23, John Baldwin j...@freebsd.org wrote: On Wednesday, March 18, 2015 11:19:21 AM Ryan Stone wrote: On Wed, Mar 18, 2015 at 10:24 AM, John Baldwin j...@freebsd.org wrote: I do think the normal zone callbacks passed to uma_zcreate() are too public to change. Or at least, you would need to do some crazy ABI shim where you have a uma_zcreate_new() that you map to uma_zcreate() via a #define for the API, but include a legacy uma_zcreate() symbol that older modules can call (and then somehow tag the old function pointers via an internal flag in the zone and patch UMA to cast to the old function signatures for zones with that flag). I really wasn't clear here. I definitely don't think that changing the ctor, etc to accept a size_t is MFC'able, and I don't think that the problem (which is really only theoretical at this point) warrants an MFC to -stable. I was talking about potentially doing it in a separate commit to head, but that does leave -stable and head with a different API. This can be painful for downstream consumers to deal with, which is why I wanted comments. I actually think the API change to fix the zone callbacks is fine to change in HEAD. I don't think that is too disruptive for folks who might be sharing code across branches (they can use a local typedef to work around it or some such). +1. This isn't exposed to userland, right? So I wouldn't worry about. Kernel progress can't be held back because we're afraid of kernel ABI changes that fix actual bugs. I don't think we've ever aid we'd maintain kernel internal ABI across different code lines. We have said we'd try keep changes to some things easy to fix (e.g. network driver API) but a recompile is pretty much always needed. -adrian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Possible race in IPv6
On 18.03.2015 20:01, Alexandre Martins wrote:
Dear,
I'm facing some crash around manipulations of IPv6 address.
I already found that the commit 275593 will fix my issue.
However, after some code review, i see a possible race in the function
nd6_na_input:
https://svnweb.freebsd.org/base/head/sys/netinet6/nd6_nbr.c?annotate=279676#l750
=-=-=-=-=-=-=-=-=-=
if (ifa
(((struct in6_ifaddr *)ifa)-ia6_flags IN6_IFF_TENTATIVE)) {
ifa_free(ifa);
nd6_dad_na_input(ifa);
goto freeit;
}
=-=-=-=-=-=-=-=-=-=
As you can see, the function drop its reference on the address and pass it to
nd6_dad_na_input.
It should be better to release the reference after the call.
What about you?
Hi,
Actually nd6_dad_na_input() uses ifa only for addresses comparison, so
there shouldn't be some negative impact in this race. But for the better
code logic I'll commit this change. Thanks.
--
WBR, Andrey V. Elsukov
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [PATCH] Convert the VFS cache lock to an rmlock
[snip] Hihi! Do you have a shell script or something that I can run on the power8 box to see if nathan's pmap locking changes eliminate at least that global pmap lock we're seeing on amd64? -a ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: What parts of UMA are part of the stable ABI?
[snip] So yes, I'd like to see this in -HEAD sooner rather than later. You did the great work of chasing it down, so let's get it in -HEAD. :) -a ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Possible race in IPv6
Dear,
I'm facing some crash around manipulations of IPv6 address.
I already found that the commit 275593 will fix my issue.
However, after some code review, i see a possible race in the function
nd6_na_input:
https://svnweb.freebsd.org/base/head/sys/netinet6/nd6_nbr.c?annotate=279676#l750
=-=-=-=-=-=-=-=-=-=
if (ifa
(((struct in6_ifaddr *)ifa)-ia6_flags IN6_IFF_TENTATIVE)) {
ifa_free(ifa);
nd6_dad_na_input(ifa);
goto freeit;
}
=-=-=-=-=-=-=-=-=-=
As you can see, the function drop its reference on the address and pass it to
nd6_dad_na_input.
It should be better to release the reference after the call.
What about you?
Regards
--
Alexandre Martins
STORMSHIELD
smime.p7s
Description: S/MIME cryptographic signature
Re: What parts of UMA are part of the stable ABI?
On 18 March 2015 at 08:23, John Baldwin j...@freebsd.org wrote: On Wednesday, March 18, 2015 11:19:21 AM Ryan Stone wrote: On Wed, Mar 18, 2015 at 10:24 AM, John Baldwin j...@freebsd.org wrote: I do think the normal zone callbacks passed to uma_zcreate() are too public to change. Or at least, you would need to do some crazy ABI shim where you have a uma_zcreate_new() that you map to uma_zcreate() via a #define for the API, but include a legacy uma_zcreate() symbol that older modules can call (and then somehow tag the old function pointers via an internal flag in the zone and patch UMA to cast to the old function signatures for zones with that flag). I really wasn't clear here. I definitely don't think that changing the ctor, etc to accept a size_t is MFC'able, and I don't think that the problem (which is really only theoretical at this point) warrants an MFC to -stable. I was talking about potentially doing it in a separate commit to head, but that does leave -stable and head with a different API. This can be painful for downstream consumers to deal with, which is why I wanted comments. I actually think the API change to fix the zone callbacks is fine to change in HEAD. I don't think that is too disruptive for folks who might be sharing code across branches (they can use a local typedef to work around it or some such). +1. This isn't exposed to userland, right? So I wouldn't worry about. Kernel progress can't be held back because we're afraid of kernel ABI changes that fix actual bugs. -adrian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
