Re: Troubles with netdump(4)
> On 10 Mar 2021, at 10:07, Mamontov Roman wrote: > > Hello. > > I try to use netdump(4) option for transmitting kernel dumps to a remote > server. > When I caused a kernel panic by sysctl debug.kdb.panic I found, that > netdumping > to remote server happens very slow: systat -ifstat on remote side show > speed > around 5KB/s. > > On netdump-client side I have: > root@host-1:/home/roman # uname -mv > FreeBSD 12.2-STABLE GENERIC amd64 > root@host-1:/home/roman # > root@host-1:/home/roman # dumpon -l > em0 > root@host-1:/home/roman # cat /etc/rc.local > #!/bin/sh > /sbin/dumpon -c 192.168.7.11 -s 192.168.7.12 em0 > root@host-1:/home/roman # ifconfig em0 > em0: flags=8943 metric 0 mtu > 1500 > > options=81209b >inet 192.168.7.11 netmask 0xff00 broadcast 192.168.7.255 >media: Ethernet autoselect (1000baseT ) >status: active >nd6 options=29 > root@solution:/home/roman # > > On netdumpd-side: > root@host-2:/home/roman # uname -mv > FreeBSD 12.2-STABLE GENERIC i386 > root@host-2:/home/roman # ifconfig em0 > em0: flags=8843 metric 0 mtu 1500 > > options=81209b >inet 192.168.7.12 netmask 0xff00 broadcast 192.168.7.255 >media: Ethernet autoselect (1000baseT ) >status: active >nd6 options=29 > root@solution-old:/home/roman # > > Both (host-1 and host-2) have the same stable/12 revision: > # cat /usr/src/.gituprevision > stable/12:879039312 > # > > When I try test network bandwith between host-1 and host-2 with iperf3, I > see > next results: > root@host-1:/home/roman # iperf3 -u -b 0 -c 192.168.7.12 > Connecting to host 192.168.7.12, port 5201 > [ 5] local 192.168.7.11 port 37112 connected to 192.168.7.12 port 5201 > [ ID] Interval Transfer Bitrate Total Datagrams > [ 5] 0.00-1.00 sec 346 MBytes 2.90 Gbits/sec 248710 > [ 5] 1.00-2.00 sec 345 MBytes 2.89 Gbits/sec 247750 > [ 5] 2.00-3.00 sec 345 MBytes 2.90 Gbits/sec 247990 > [ 5] 3.00-4.00 sec 331 MBytes 2.78 Gbits/sec 238020 > [ 5] 4.00-5.00 sec 262 MBytes 2.20 Gbits/sec 188260 > [ 5] 5.00-6.00 sec 345 MBytes 2.89 Gbits/sec 247560 > [ 5] 6.00-7.00 sec 345 MBytes 2.89 Gbits/sec 247660 > [ 5] 7.00-8.00 sec 345 MBytes 2.90 Gbits/sec 247980 > [ 5] 8.00-9.00 sec 342 MBytes 2.87 Gbits/sec 245760 > [ 5] 9.00-10.00 sec 344 MBytes 2.88 Gbits/sec 246830 > - - - - - - - - - - - - - - - - - - - - - - - - - > [ ID] Interval Transfer Bitrate JitterLost/Total > Datagrams > [ 5] 0.00-10.00 sec 3.27 GBytes 2.81 Gbits/sec 0.000 ms 0/2406520 > (0%) sender > [ 5] 0.00-10.07 sec 0.00 Bytes 0.00 bits/sec 0.000 ms 0/0 (0%) > receiver > > iperf Done. > root@host-1:/home/roman # > > Capturing traffic between host-1 and host-2 not show anything criminal (as > I > understand). > > Next I try netdumping to another FreeBSD-host (virtual machine on > VMWare > hypervisor): > root@host-3:~ # uname -mv > FreeBSD 12.2-STABLE r369412 GENERIC amd64 > root@host-3:~ # ifconfig em0 > em0: flags=8843 metric 0 mtu 1500 > > options=81009b >inet 192.168.7.18 netmask 0xff00 broadcast 192.168.7.255 >media: Ethernet autoselect (1000baseT ) >status: active >nd6 options=29 > root@host-3:~ # > > And netdumping to this host are still slow (~the same 5KB/s). > > Next step another FreeBSD-host (virtual machine on VirtualBox hypevisor): > root@host-4:~ # uname -mv > FreeBSD 12.2-STABLE r369412 GENERIC amd64 > root@host-4:~ # ifconfig em0 > em0: flags=8843 metric 0 mtu 1500 > > options=81009b >inet 192.168.7.19 netmask 0xff00 broadcast 192.168.7.255 >media: Ethernet autoselect (1000baseT ) >status: active >nd6 options=29 > root@host-4:~ # > > Both (host-3 and host-4) are installed from > FreeBSD-12.2-STABLE-amd64-20210304-r369412-bootonly.iso > When I caused a kernel panic by sysctl debug.kdb.panic on host-4, > netdumping to > host-3 show the same 5 KB/s. netdump requires explicit acks from the other side. Could you try dumping the exchange between the dumping host and the server to verify that acks are sent immediately after receiving the next chunk? > > Is there an particularity in netdump, that can't transmitting crash dumps > over > network faster than 5KB/s? Or this is a "feature" of my test-suite? > > ___ > freebsd-stable@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: option FIB_ALGO and dpdk_lpm4
08.02.2021, 20:10, "Marek Zarychta" :
> W dniu 08.02.2021 o 19:32, Alexander V. Chernikov pisze:
>> 08.02.2021, 14:33, "Marek Zarychta" :
>>> W dniu 08.02.2021 o 13:10, mike tancsa pisze:
>>>> I have been setting up some tests to see if
>>>>
>>>> option FIB_ALGO and dpdk_lpm4.ko
>>>>
>>>> will help with my pkt forwarding needs and large routing tables. So far
>>>> so good. But one thing I noticed, is that its very chatty to dmesg.
>>>> eg
>>>> alloc_nhgrp: new mpath group: num_nhops: 2
>>>> compile_nhgrp: O: 2/2
>>>> compile_nhgrp: OO[0]: 1/1 curr=1 slot_idx=0
>>>> compile_nhgrp: OO[1]: 0/0 curr=1 slot_idx=1
>>>> alloc_nhgrp: new mpath group: num_nhops: 2
>>>> compile_nhgrp: O: 2/2
>>>> compile_nhgrp: OO[0]: 1/1 curr=1 slot_idx=0
>>>> compile_nhgrp: OO[1]: 0/0 curr=1 slot_idx=1
>>>> alloc_nhgrp: new mpath group: num_nhops: 2
>>>> compile_nhgrp: O: 2/2
>>>> compile_nhgrp: OO[0]: 1/1 curr=1 slot_idx=0
>>>> compile_nhgrp: OO[1]: 0/0 curr=1 slot_idx=1
>>>>
>>>> are these debugging messages that forgot to be turned off ? What do they
>>>> mean ?
>>>> Thanks for this work!
>>>>
>>>> 13.0-STABLE #11 stable/13-cc1352c1f-dirty
>>>
>>> Thank you for sharing this Mike. Could you please reveal us how do you
>>> feed your routing tables? Is net/bird{,2} or net/frr7 involved? Any
>>> problems or hints to make the routing daemon working with new routing
>>> stack?
>> Non-multipath should work as before, multipath works for quagga/frr but
>> needs some patches for bird.
>
> Thank you for the clarification, so is with anything but quagga or frr
> the sysctl setting net.route.multipath=0 obligatory now?
>>> The new routing stack looks very promising, please let me also give this
>>> way some appreciations to melifaro@ and other people who worked on it.
>>>
>>> I was also trying to test it with legacy net/bird and multiple fib
>>> tables, but I was early hit by: "KRT: Error sending route x.x.x.x/y to
>>> kernel: Operation not supported"
>> Any chance you could clarify what are these routes? "Operation not
>> supported" looks a bit weird, it shouln't happen.
>>> Setting net.add_net.add_addr_allfibs=1addr_allfibs=1 changed it a bit,
>>> but still some blackhole /32 routes seem to get rejected.
>> Just "blackhole" route in the bird config? /32 or all?
>
> I used for tests the feed from Peter Hessler's OpenBSD spam trapping
> project[1]. On FreeBSD 11.4 I see these routes in net/bird as
> blackholed, for example:
> x.x.x.x/32 blackhole [bgp_spamd 20:20:43 from y.y.y.y] * (100) [AS]
> They work the same was as routes added by route(8) with option "-blackhole"
>
> With new routing stack, these routes are rejected with the message
> above. Now in net/bird, they appear like the example below and import to
> the fib (fib number is not equal to 0 in this case) is blocked:
> x.x.x.x/32 unreachable [SPAM 19:58:18 from y.y.y.y] ! (100/-) [AS]
Does the change in https://reviews.freebsd.org/D28549 fix bird?
>
> Probably it all should be tested in normal peering, but my initial test
> was performed on the old lab setup where multiple fibs and policy
> routing[2] were involved. The config was loosely based on the example by
> Ondrej Filip from the[2].
>
> Once again thank you for implementing all these improvements into
> FreeBSD routing stack and please don't get me wrong, I am just testing
> it a bit before migration from 11.4-STABLE, but not complaining about
> anything.
No problem! Thank you for the report. It's really nice it's been caught before
the release.
>
> [1] http://rs.bgp-spamd.net/client/index.html
> [2] https://gitlab.nic.cz/labs/bird/-/wikis/Policy_routing
>
> --
> Marek Zarychta
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: option FIB_ALGO and dpdk_lpm4
08.02.2021, 14:33, "Marek Zarychta" :
> W dniu 08.02.2021 o 13:10, mike tancsa pisze:
>> I have been setting up some tests to see if
>>
>> option FIB_ALGO and dpdk_lpm4.ko
>>
>> will help with my pkt forwarding needs and large routing tables. So far so
>> good. But one thing I noticed, is that its very chatty to dmesg.
>> eg
>> alloc_nhgrp: new mpath group: num_nhops: 2
>> compile_nhgrp: O: 2/2
>> compile_nhgrp: OO[0]: 1/1 curr=1 slot_idx=0
>> compile_nhgrp: OO[1]: 0/0 curr=1 slot_idx=1
>> alloc_nhgrp: new mpath group: num_nhops: 2
>> compile_nhgrp: O: 2/2
>> compile_nhgrp: OO[0]: 1/1 curr=1 slot_idx=0
>> compile_nhgrp: OO[1]: 0/0 curr=1 slot_idx=1
>> alloc_nhgrp: new mpath group: num_nhops: 2
>> compile_nhgrp: O: 2/2
>> compile_nhgrp: OO[0]: 1/1 curr=1 slot_idx=0
>> compile_nhgrp: OO[1]: 0/0 curr=1 slot_idx=1
>>
>> are these debugging messages that forgot to be turned off ? What do they
>> mean ?
>> Thanks for this work!
>>
>> 13.0-STABLE #11 stable/13-cc1352c1f-dirty
>
> Thank you for sharing this Mike. Could you please reveal us how do you
> feed your routing tables? Is net/bird{,2} or net/frr7 involved? Any
> problems or hints to make the routing daemon working with new routing stack?
Non-multipath should work as before, multipath works for quagga/frr but needs
some patches for bird.
>
> The new routing stack looks very promising, please let me also give this
> way some appreciations to melifaro@ and other people who worked on it.
>
> I was also trying to test it with legacy net/bird and multiple fib
> tables, but I was early hit by: "KRT: Error sending route x.x.x.x/y to
> kernel: Operation not supported"
Any chance you could clarify what are these routes? "Operation not supported"
looks a bit weird, it shouln't happen.
> Setting net.add_net.add_addr_allfibs=1addr_allfibs=1 changed it a bit,
> but still some blackhole /32 routes seem to get rejected.
Just "blackhole" route in the bird config? /32 or all?
>
> --
> Marek Zarychta
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: option FIB_ALGO and dpdk_lpm4
08.02.2021, 12:10, "mike tancsa" : > I have been setting up some tests to see if > > option FIB_ALGO and dpdk_lpm4.ko > > will help with my pkt forwarding needs and large routing tables. So far so > good. But one thing I noticed, is that its very chatty to dmesg. > eg > alloc_nhgrp: new mpath group: num_nhops: 2 > compile_nhgrp: O: 2/2 > compile_nhgrp: OO[0]: 1/1 curr=1 slot_idx=0 > compile_nhgrp: OO[1]: 0/0 curr=1 slot_idx=1 > alloc_nhgrp: new mpath group: num_nhops: 2 > compile_nhgrp: O: 2/2 > compile_nhgrp: OO[0]: 1/1 curr=1 slot_idx=0 > compile_nhgrp: OO[1]: 0/0 curr=1 slot_idx=1 > alloc_nhgrp: new mpath group: num_nhops: 2 > compile_nhgrp: O: 2/2 > compile_nhgrp: OO[0]: 1/1 curr=1 slot_idx=0 > compile_nhgrp: OO[1]: 0/0 curr=1 slot_idx=1 > > are these debugging messages that forgot to be turned off ? What do they mean > ? Yep, these are the remnants of early-day debugging. I'll remove them this week. > Thanks for this work! > > 13.0-STABLE #11 stable/13-cc1352c1f-dirty > > ---Mike > > ___ > freebsd-stable@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: FreeBSD CI Weekly Report 2020-04-12
___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: net.add_addr_allfibs=1 behaviour deprecation
18.07.2020, 14:22, "Alexander V. Chernikov" : > Dear FreeBSD users, > > I would like to make net.add_addr_allfibs=0 as the default system behaviour > and remove net.add_addr_allfibs. > To do so, I would like to collect use cases with net.add_addr_allfibs=1 and > multiple fibs, to ensure they can still be supported after removal. > > Background: > > Multi-fib support was added in r17 [1], 12 years ago. Addition of > interface addresses to all fibs was a feature from day 1. > The `net.add_addr_allfibs` sysctl was added in r180840 [2], 12 years ago. > > Problem: > The goal of the fib support is to provide multiple independent routing > tables, isolated from each other. > `net.add_addr_allfibs` default tries to shift gears in the opposite > direction, unconditionally inserting all addresses to all of the fibs. > > It complicates the logic, kernel code and makes control plane performance > decrease with the number of fibs. > It make impossible to use the same prefixes in multiple fibs, which may be > desired given shortage of IPv4 address space. > > I do understand that there are some cases where such behaviour is desired. > For example, it can be used to achieve VRF route leaking or binding on > address from different fibs. > I would like to collect such cases to consider supporting them in a different > way. > > The goal is to make net.add_addr_allfibs=0 default behaviour and remove > net.add_addr_allfibs. > It will simplify kernel fib-related code and allow bringing more fib-related > features. It will also improve fib scaling. No objections has been received. Next steps: * Switch net.add_addr_allfibs to 0 ( https://reviews.freebsd.org/D26076 ) * Provide an ability to use nexthops from different fibs * Remove net.add_addr_allfibs > Timeline: > Aug 1: summarising feedback and the usecases, decision on proceeding further > Aug 20 (tentative): patches for supported usecases > Sep 15 (tentative): net.add_addr_allfibs removal. > > [1]: [base Contents of > /head/sys/net/route.c](https://svnweb.freebsd.org/base/head/sys/net/route.c?revision=17=markup) > [2]: [base Diff of > /head/sys/net/route.c](https://svnweb.freebsd.org/base/head/sys/net/route.c?r1=180839=180840;) > > /Alexander ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: FreeBSD CI Weekly Report 2020-04-12
15.04.2020, 15:10, "Kristof Provost" : > On 15 Apr 2020, at 15:34, Kristof Provost wrote: >> On 15 Apr 2020, at 0:37, Li-Wen Hsu wrote: >>> (Please send the followup to freebsd-testing@ and note Reply-To is >>> set.) >>> >>> FreeBSD CI Weekly Report 2020-04-12 >>> === >>> >>> Here is a summary of the FreeBSD Continuous Integration results for >>> the period >>> from 2020-04-06 to 2020-04-12. >>> >>> During this period, we have: >>> >>> * 1801 builds (94.0% (+0.4) passed, 6.0% (-0.4) failed) of buildworld >>> and >>> buildkernel (GENERIC and LINT) were executed on aarch64, amd64, >>> armv6, >>> armv7, i386, mips, mips64, powerpc, powerpc64, powerpcspe, riscv64, >>> sparc64 architectures for head, stable/12, stable/11 branches. >>> * 288 test runs (25.1% (-24.6) passed, 29.9% (+10.6) unstable, 45.1% >>> (+14.1) >>> exception) were executed on amd64, i386, riscv64 architectures for >>> head, >>> stable/12, stable/11 branches. >>> * 30 doc and www builds (83.3% (-1.3) passed, 16.7% (+1.3) failed) >>> >>> Test case status (on 2020-04-12 23:59): >>> | Branch/Architecture | Total | Pass | Fail | Skipped >>> | >>> | --- | - | -- | | >>> | >>> | head/amd64 | 7744 (+4) | 7638 (+19) | 14 (+5) | 92 (-20) >>> | >>> | head/i386 | 7742 (+4) | 7628 (+15) | 16 (+5) | 98 (-16) >>> | >>> | 12-STABLE/amd64 | 7508 (0) | 7449 (-3) | 1 (+1) | 58 (+2) >>> | >>> | 12-STABLE/i386 | 7506 (0) | 7425 (-17) | 2 (+2) | 79 (+15) >>> | >>> | 11-STABLE/amd64 | 6882 (0) | 6829 (-6) | 1 (+1) | 52 (+5) >>> | >>> | 11-STABLE/i386 | 6880 (0) | 6749 (-82) | 80 (+80) | 51 (+2) >>> | >>> >>> (The statistics from experimental jobs are omitted) >>> >>> If any of the issues found by CI are in your area of interest or >>> expertise >>> please investigate the PRs listed below. >>> >>> The latest web version of this report is available at >>> https://hackmd.io/@FreeBSD-CI/report-20200412 and archive is >>> available at >>> https://hackmd.io/@FreeBSD-CI/ , any help is welcome. >>> >>> ## News >>> >>> * The test env now loads the required module for firewall tests. >>> >>> * New armv7 job is added (to replace armv6 one): >>> * FreeBSD-head-armv7-testvm >>> The images are available at https://artifact.ci.freebsd.org >>> FreeBSD-head-armv7-test is ready but needs test env update. >>> >>> ## Failing jobs >>> >>> * https://ci.freebsd.org/job/FreeBSD-head-amd64-gcc6_build/ >>> * See console log for the error details. >>> >>> ## Failing tests >>> >>> * https://ci.freebsd.org/job/FreeBSD-head-amd64-test/ >>> * local.kyua.integration.cmd_about_test.topic__authors__installed >>> * sys.netipsec.tunnel.empty.v4 >>> * sys.netipsec.tunnel.empty.v6 >>> * sys.netpfil.common.forward.ipf_v4 >>> * sys.netpfil.common.forward.ipfw_v4 >>> * sys.netpfil.common.forward.pf_v4 >>> * sys.netpfil.common.tos.ipfw_tos >>> * sys.netpfil.common.tos.pf_tos >>> * sys.netpfil.pf.forward.v4 >> I can’t actually reproduce this failure in my test VM, but with the >> ci test VM I can reproduce the problem. >> It’s not related to pf, because the sanity check ping we do before >> we set up pf already fails. >> Or rather pft_ping.py sends an incorrect packet, because `ping` does >> get the packet to go where it’s supposed to go. >> >> Scapy seems to fail to find the source IP address, so we get this: >> >> 12:12:22.152652 IP 0.0.0.0 > 198.51.100.3: ICMP echo request, id 0, >> seq 0, length 12 >> >> I have a vague recollection that we’ve seem this problem before, but >> I can’t remember what we did about it. >> >> In all likelihood most of the other netpfil tests fail for exactly the >> same reason. > > The problem appears to be that > /usr/local/lib/python3.7/site-packages/scapy/arch/unix.py is misparsing > the `netstat -rnW` output. Thanks for the analysis! Sorry for breaking the tests. I should have run tests with userland changes installed. I'll revert the netstat output changes shortly to unbreak the tests. Re longer-term: parsing textual output for the routes does not seem to be a good habit, especially in these days. Structural (libxo) approach looks better, however I guess this will make scapy unusable on the routers with full-view. So far light-weight sysctl-route reader looks like the best option. What do you folks think? > > For reference, this is the output in the test VM: > > Routing tables > > Internet: > Destination Gateway Flags Nhop# Mtu Netif > Expire > 127.0.0.1 link#2 UH 1 16384 lo0 > 192.0.2.0/24 link#4 U 2 1500 epair0a > 192.0.2.1 link#4 UHS 1 16384 lo0 > 198.51.100.0/24 192.0.2.2 UGS 3 1500 epair0a > > Internet6: > Destination Gateway Flags > Nhop# Mtu Netif Expire > ::/96 ::1 UGRS > 4 16384 lo0 > ::1 link#2 UH > 1 16384 lo0 > :::0.0.0.0/96 ::1 UGRS >
Re: table with bug in ipfw
___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: table with bug in ipfw
19.05.2015, 03:22, Marcelo Gondim gon...@bsdinfo.com.br: Hi all, Hi, I see that there is still the following bug in ipfw: # ipfw table 33 add 0.0.0.0/8 # ipfw table 33 list ::/8 0 and # ipfw table 33 add 255.255.255.255 # ipfw table 33 list ::/8 0 The IP 255.255.255.255 not appear but it's there. Look below: # ipfw table 33 add 255.255.255.255 ipfw: setsockopt(IP_FW_TABLE_XADD): File exists This is very ugly to see. As it was not fixed in 10.1, would be expected to 10.2? It was fixed in -head but didn't get to -stable. I'll try to take a look soon. Best regards, Gondim ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: [patch] IPMI KCS can drop the lock while servicing a request
On 25.03.2013 02:38, Alexander V. Chernikov wrote: On 24.03.2013 07:11, Eric van Gyzen wrote: At work, we discovered that our application's IPMI thread would often use a lot of CPU time. The KCS thread uses DELAY to wait for the BMC, so it can run without sleeping for a long time with a slow BMC. It also holds the ipmi_softc.ipmi_lock during this time. When using adaptive mutexes, an application thread that wants to operate on the ipmi_pending_requests list will also spin during this same time. We suffer from the same problem, too. We see no reason that the KCS thread needs to hold the lock while servicing a request. We've been running with the attached patch for a Well, this seems to be true. I'll try to commit something like this patch in several days. Done in r248705. few months, with no ill effects. Eric ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org -- WBR, Alexander ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: [patch] IPMI KCS can drop the lock while servicing a request
On 24.03.2013 07:11, Eric van Gyzen wrote: At work, we discovered that our application's IPMI thread would often use a lot of CPU time. The KCS thread uses DELAY to wait for the BMC, so it can run without sleeping for a long time with a slow BMC. It also holds the ipmi_softc.ipmi_lock during this time. When using adaptive mutexes, an application thread that wants to operate on the ipmi_pending_requests list will also spin during this same time. We suffer from the same problem, too. We see no reason that the KCS thread needs to hold the lock while servicing a request. We've been running with the attached patch for a Well, this seems to be true. I'll try to commit something like this patch in several days. few months, with no ill effects. Eric ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: 8.3: kernel panic in bpf.c catchpacket()
On 10.10.2012 00:36, Guy Helmer wrote: On Oct 8, 2012, at 8:09 AM, Guy Helmer guy.hel...@gmail.com wrote: I'm seeing a consistent new kernel panic in FreeBSD 8.3: I'm not seeing how bd_sbuf would be NULL here. Any ideas? Since I've not had any replies, I hope nobody minds if I reply with more information. This panic seems to be occasionally triggered now that my user land code is changing the packet filter a while after the bpd device has been opened and an initial packet filter was set (previously, my code did not change the filter after it was initially set). I'm focusing on bpf_setf() since that seems to be the place that could be tickling a problem, and I see that bpf_setf() calls reset_d(d) to clear the hold buffer. I have manually verified that the BPFD lock is held during the call to reset_d(), and the lock is held every other place that the buffers are manipulated, so I haven't been able to find any place that seems vulnerable to losing one of the bpf buffers. Still searching, but any help would be appreciated. Can you please check this code on -current? Locking has changed quite significantly some time ago, so there is good chance that you can get rid of this panic (or discover different one which is really new) :). Guy ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org -- WBR, Alexander ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: serious packet routing issue causing ntpd high load?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10.10.2011 13:50, Steven Hartland wrote: - Original Message - From: Li, Qing qing...@bluecoat.com RTM_MISS: Lookup failed on this address: len 184, pid: 0, seq 0, errno 0, flags:DONE locks: inits: sockaddrs: DST ::A.B.C.D I'm unable to reproduce an issue on (nearly) GENERIC 8-S, but I see nearly the same situation on 8.1-S box with FLOWTABLE enabled. Do you have FLOWTABLE option in your kernel config ? Would it be possible for you to email me what exactly does ::A.B.C.D map into WRT your system or infrastructure ? Sorry for the slow reply been out of the country. All the hosts are local machines same /24 connecting to the server for mysql. It seems to be that every packet either to or from for the mysql server is generating an RTM_MISS. And are you able to share your ifconfig -a and netstat -rn output with me privately ? On its way. Regards Steve This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmas...@multiplay.co.uk. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org - -- WBR, Alexander -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6ymoMACgkQwcJ4iSZ1q2meiACeKq4lhzw6scqCKzEyTNEeycxo 31QAn2q5KIRBwJpcF7yOpTe3wOcP3Aak =jfKN -END PGP SIGNATURE- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: 32GB limit per swap device?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Alan Cox wrote: On 08/20/2011 12:41, Kostik Belousov wrote: On Sat, Aug 20, 2011 at 12:33:29PM -0500, Alan Cox wrote: On Thu, Aug 18, 2011 at 3:16 AM, Alexander V. Chernikovmelif...@ipfw.ruwrote: On 10.08.2011 19:16, per...@pluto.rain.com wrote: Chuck Swigercswi...@mac.com wrote: On Aug 9, 2011, at 7:26 AM, Daniel Kalchev wrote: I am trying to set up 64GB partitions for swap for a system that has 64GB of RAM (with the idea to dump kernel core etc). But, on 8-stable as of today I get: WARNING: reducing size to maximum of 67108864 blocks per swap unit Is there workaround for this limitation? Another interesting question: swap pager operates in page blocks (PAGE_SIZE=4k on common arch). Block device size in passed to swaponsomething() in number of _disk_ blocks (e.g. in DEV_BSIZE=512). After that, kernel b-lists (on top of which swap pager is build) maximum objects check is enforced. The (possible) problem is that real object count we will operate on is not the value passed to swaponsomething() since it is calculated in wrong units. we should check b-list limit on (X * DEV_BSIZE512 / PAGE_SIZE) value which is rough (X / 8) so we should be able to address 32*8=256G. The code should look like this: Index: vm/swap_pager.c ==**==**=== --- vm/swap_pager.c (revision 223877) +++ vm/swap_pager.c (working copy) @@ -2129,6 +2129,15 @@ swaponsomething(struct vnode *vp, void *id, u_long u_long mblocks; /* +* nblks is in DEV_BSIZE'd chunks, convert to PAGE_SIZE'd chunks. +* First chop nblks off to page-align it, then convert. +* +* sw-sw_nblks is in page-sized chunks now too. +*/ + nblks= ~(ctodb(1) - 1); + nblks = dbtoc(nblks); + + /* * If we go beyond this, we get overflows in the radix * tree bitmap code. */ @@ -2138,14 +2147,6 @@ swaponsomething(struct vnode *vp, void *id, u_long mblocks); nblks = mblocks; } - /* -* nblks is in DEV_BSIZE'd chunks, convert to PAGE_SIZE'd chunks. -* First chop nblks off to page-align it, then convert. -* -* sw-sw_nblks is in page-sized chunks now too. -*/ - nblks= ~(ctodb(1) - 1); - nblks = dbtoc(nblks); sp = malloc(sizeof *sp, M_VMPGDATA, M_WAITOK | M_ZERO); sp-sw_vp = vp; (move pages recalculation before b-list check) Can someone comment on this? I believe that you are correct. Have you tried testing this change on a large swap device? I will try tomorrow. I probably agree too, but I am in the process of re-reading the swap code, and I do not quite believe in the limit. I'm uncertain whether the current limit, 0x4000 / BLIST_META_RADIX, is exact or not, but I doubt that it is too large. It is not exact. It is rough estimation of sizeof(blmeta_t) * X 4G (blist_create() assumes malloc() not being able to allocate more that 4G. I'm not sure if it is true this days) X is number of blocks we need to store. Actual number, however, it is X / (1 + 1/BLIST_META_RADIX + 1/BLIST_META_RADIX^2 + ...) but it dffers from X not very much. blist can be seen as tree of radix trees, with metainformation for all those radix trees allocated by single allocation which imposes this limit. Metatinformation is used to find free blocks more quickly Single linear allocation is required to advance to next radix tree on the same level very fast: * * * * * ** ** ** ** ** ^^^ Some kind of schema with 3 level in tree and BLIST_META_RADIX=2 (instead of 16). When the initial code was committed, our daddr_t was 32bit, I checked the RELENG_4 sources. Current code uses int64_t for daddr_t. My impression right now is that we only utilize the low 32bits of daddr_t. Esp. interesting looks the following typedef: typedefuint32_tu_daddr_t;/* unsigned disk address */ which (correctly) means that typical mask (u_daddr_t)-1 is 0x. I wonder whether we could just use full 64bit and de-facto remove the limitation on the swap partition size. This will increase struct blmeta_t twice and cause 2*X memory usage for every swap configuration. I would rather argue first that the subr_list code should not be using daddr_t all. The code is abusing daddr_t and defining u_daddr_t to represent things that are not disk addresses. Instead, it should either define its own type or directly use (u)int*_t. Then, as for choosing between 32 and 64 bits, I'm skeptical of using this structure for managing more than 32 bits worth of blocks, given the amount of RAM it will use. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
Re: 32GB limit per swap device?
On 10.08.2011 19:16, per...@pluto.rain.com wrote: Chuck Swigercswi...@mac.com wrote: On Aug 9, 2011, at 7:26 AM, Daniel Kalchev wrote: I am trying to set up 64GB partitions for swap for a system that has 64GB of RAM (with the idea to dump kernel core etc). But, on 8-stable as of today I get: WARNING: reducing size to maximum of 67108864 blocks per swap unit Is there workaround for this limitation? Another interesting question: swap pager operates in page blocks (PAGE_SIZE=4k on common arch). Block device size in passed to swaponsomething() in number of _disk_ blocks (e.g. in DEV_BSIZE=512). After that, kernel b-lists (on top of which swap pager is build) maximum objects check is enforced. The (possible) problem is that real object count we will operate on is not the value passed to swaponsomething() since it is calculated in wrong units. we should check b-list limit on (X * DEV_BSIZE512 / PAGE_SIZE) value which is rough (X / 8) so we should be able to address 32*8=256G. The code should look like this: Index: vm/swap_pager.c === --- vm/swap_pager.c (revision 223877) +++ vm/swap_pager.c (working copy) @@ -2129,6 +2129,15 @@ swaponsomething(struct vnode *vp, void *id, u_long u_long mblocks; /* +* nblks is in DEV_BSIZE'd chunks, convert to PAGE_SIZE'd chunks. +* First chop nblks off to page-align it, then convert. +* +* sw-sw_nblks is in page-sized chunks now too. +*/ + nblks = ~(ctodb(1) - 1); + nblks = dbtoc(nblks); + + /* * If we go beyond this, we get overflows in the radix * tree bitmap code. */ @@ -2138,14 +2147,6 @@ swaponsomething(struct vnode *vp, void *id, u_long mblocks); nblks = mblocks; } - /* -* nblks is in DEV_BSIZE'd chunks, convert to PAGE_SIZE'd chunks. -* First chop nblks off to page-align it, then convert. -* -* sw-sw_nblks is in page-sized chunks now too. -*/ - nblks = ~(ctodb(1) - 1); - nblks = dbtoc(nblks); sp = malloc(sizeof *sp, M_VMPGDATA, M_WAITOK | M_ZERO); sp-sw_vp = vp; (move pages recalculation before b-list check) Can someone comment on this? Apparently, the 32GB swapspace limit is per swap area; you can add up to 4 swap areas so create two or three 32GB swap partitions. Will that enable a 64GB dump? In 8.1, dumpon(8) says: kernel swap pager and dump facility are completely unrelated to each other. The only possible relation is that dumpon rc-script searches first swap device in fstab to notify kernel it should dump on this device. The dumpon utility is used to specify a device where the kernel can save a crash dump in the case of a panic. ... For most systems the size of the specified dump device must be at least the size of physical memory. ... The dumpon utility will refuse to enable a dump device which is smaller than the total amount of physical memory as reported by the hw.physmem sysctl(8) variable. Note the use of the singluar: a device and the specified device. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: commit PR 154469, ftp-proxy(8) bug ?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Kurt Jaeger wrote: Hi! Can someone have a look at http://www.freebsd.org/cgi/query-pr.cgi?pr=154469 and commit it ? So that it ends up in 8.3 8-} ? Does the patch from OpenBSD fix the problem for you? Yes, sure. That why I sent the pr! Yep, the patch does the right thing: Setup: FTP server: 87.51.34.132 (ftp.freebsd.org) FTP client: 10.11.0.8 (stock freebsd ftp client) GW with pf ftp-proxy (FreeBSD 7.3) ext: em0 77.73.232.13 int: vlan3 10.11.0.1 FTP session: 23:50 [0] bibi# ftp -a 87.51.34.132 Connected to 87.51.34.132. 220 ftp.beastie.tdk.net FTP server (Version 6.00LS) ready. 331 Guest login ok, send your email address as password. 230 Guest login ok, access restrictions apply. Remote system type is UNIX. Using binary mode to transfer files. ftp quit TCPDUMP (10.11.0.8 em0): (-lnpAs0 host 87.51.34.132) 23:51:39.487136 IP 10.11.0.8.47376 87.51.34.132.21: Flags [P.], ack 303, win 8326, options [nop,nop,TS val 458938281 ecr 1611018784], length 6 E..:b.@.@.TW ...W3...E... .Z..`.2 QUIT 23:51:39.530414 IP 87.51.34.132.21 10.11.0.8.47376: Flags [F.], seq 303, ack 56, win 4163, options [nop,nop,TS val 1611020954 ecr 458938281], length 0 E..4..@.@...W3. .ECT.. `.:..Z.. Note 'server' silently closing connection TCPDUMP (GW em0): 23:56:20.405425 IP 77.73.232.13.61168 87.51.34.132.21: P 50:56(6) ack 303 win 4163 nop,nop,timestamp 2027802761 1933653527 W3.dn.C... x...sA6.QUIT 23:56:20.448332 IP 87.51.34.132.21 77.73.232.13.61168: . ack 56 win 257 nop,nop,timestamp 1933655700 2027802761 dn sA.x... 23:56:20.448345 IP 87.51.34.132.21 77.73.232.13.61168: P 303:317(14) ack 56 win 257 nop,nop,timestamp 1933655700 2027802761 dn...8. sA.x...221 Goodbye. 23:56:20.448353 IP 87.51.34.132.21 77.73.232.13.61168: F 317:317(0) ack 56 win 257 nop,nop,timestamp 1933655700 2027802761 dn sA.x... Note real server transmits '221 Goodbye' After applying patch: 23:54 [0] bibi# ftp -a 87.51.34.132 Connected to 87.51.34.132. 220 ftp.beastie.tdk.net FTP server (Version 6.00LS) ready. 331 Guest login ok, send your email address as password. 230 Guest login ok, access restrictions apply. Remote system type is UNIX. Using binary mode to transfer files. ftp quit 221 Goodbye. Note '221 Goodvye' received by ftp client -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk4CzWYACgkQwcJ4iSZ1q2lOcwCfYqknB9i1P7bfjgYVpSjkSWP1 Y8wAn3hC2pZ/OHDicCN+o3v1O5YiFZ8W =dqk/ -END PGP SIGNATURE- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: top Segmentation faulting on 8.0p2 amd64 (nss_ldapd problem?)
Harald Schmalzbauer wrote:
Mikolaj Golub schrieb am 22.01.2010 23:26 (localtime):
On Wed, 20 Jan 2010 08:06:23 +0100 Harald Schmalzbauer wrote:
Dear all,
I have no idea why top crashes with segmentation fault on my amd64
machine running FreeBSD 8.0-RELEASE-p2.
If someone wants to have a loot at the core dump:
http://www.schmalzbauer.de/downloads/top.core
core file is useless without binary and libraries. So it is better to
run gdb
on your host, produce backtrace and post here:
gdb /usr/bin/top top.core
bt
And sure a backtrace from the top built with -g would be much better.
cd /usr/src/usr.bin/top
CFLAGS=-g make
Unfortunately nss_ldap seems to be the culprit.
There is some strange problem with TLS and gcc optimization I can't localize
Please try to rebuild port with
post-configure:
@${REINPLACE_CMD} -e 's/^\(CFLAGS .*\)-O2 \(.*\)$$/\1 -O0 \2/'
${WRKSRC}/nss/Makefile
I'll submit updated port later
gdb /usr/bin/top top.core
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and
you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB. Type show warranty for
details.
This GDB was configured as amd64-marcel-freebsd...
Core was generated by `top'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /lib/libncurses.so.8...done.
Loaded symbols for /lib/libncurses.so.8
Reading symbols from /lib/libm.so.5...done.
Loaded symbols for /lib/libm.so.5
Reading symbols from /lib/libkvm.so.5...done.
Loaded symbols for /lib/libkvm.so.5
Reading symbols from /lib/libc.so.7...done.
Loaded symbols for /lib/libc.so.7
Reading symbols from /usr/local/lib/nss_ldap.so.1...done.
Loaded symbols for /usr/local/lib/nss_ldap.so.1
Reading symbols from /libexec/ld-elf.so.1...done.
Loaded symbols for /libexec/ld-elf.so.1
bt:
#0 0x000800d08403 in __nss_compat_gethostbyname () from
/usr/local/lib/nss_ldap.so.1
#0 0x000800d08403 in __nss_compat_gethostbyname () from
/usr/local/lib/nss_ldap.so.1
#1 0x000800d0606f in _nss_ldap_getpwent_r () from
/usr/local/lib/nss_ldap.so.1
#2 0x0008009ffc54 in __nss_compat_getpwent_r () from /lib/libc.so.7
#3 0x000800a84a3d in nsdispatch () from /lib/libc.so.7
#4 0x000800a50976 in getpwent_r () from /lib/libc.so.7
#5 0x000800a50596 in sysctlbyname () from /lib/libc.so.7
#6 0x00406c6d in machine_init (statics=0x7fffea30,
do_unames=1 '\001')
at /usr/src/usr.bin/top/machine.c:257
#7 0x00407a10 in main (argc=1, argv=0x7fffeb08)
at /usr/src/usr.bin/top/../../contrib/top/top.c:458
I'm using nss_ldapd-0.7.2 and there's no way to live without ldap...
Any help highly appreciated!
Thanks,
-Harry
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: top Segmentation faulting on 8.0p2 amd64 (nss_ldapd problem?)
Harald Schmalzbauer wrote:
Alexander V. Chernikov schrieb am 24.01.2010 10:24 (localtime):
...
gdb /usr/bin/top top.core
bt
And sure a backtrace from the top built with -g would be much better.
cd /usr/src/usr.bin/top
CFLAGS=-g make
Unfortunately nss_ldap seems to be the culprit.
There is some strange problem with TLS and gcc optimization I can't
localize
Please try to rebuild port with
post-configure:
@${REINPLACE_CMD} -e 's/^\(CFLAGS .*\)-O2 \(.*\)$$/\1 -O0 \2/'
${WRKSRC}/nss/Makefile
I'll submit updated port later
That indeed fixed the problem. Thank you very much.
But I found another point for improovement:
When deinstalling/installing nss_ldap.conf gets deleted/overwritten. I
think it's better to install nss_ldap.conf.sample like many other
ports do.
I also like the way lighttpd port is managed:
@unexec if cmp -s %D/etc/lighttpd.conf %D/etc/lighttpd.conf.sample;
then rm -f %D/etc/lighttpd.conf; fi
etc/lighttpd.conf.sample
@exec [ -f %B/lighttpd.conf ] || cp %B/%f %B/lighttpd.conf
Thanks,
-Harry
Already noticed that, thanks.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: top Segmentation faulting on 8.0p2 amd64 (nss_ldapd problem?)
Doug Barton wrote:
On 01/24/10 03:02, Harald Schmalzbauer wrote:
Alexander V. Chernikov schrieb am 24.01.2010 10:24 (localtime):
Please try to rebuild port with
post-configure:
@${REINPLACE_CMD} -e 's/^\(CFLAGS .*\)-O2 \(.*\)$$/\1 -O0 \2/'
${WRKSRC}/nss/Makefile
That should be pre- or post- patch, since it's actually modifying
something.
I can't do this before configure -
Makefile.in contains only @CFLAGS@ which needs to be substituted from
configure and CFLAGS cannot be predicted due to
possible environment/make.conf variables
hth,
Doug
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: How to take down a system to the point of requiring a newfs with one line of C (userland)
Daniel Corrigan wrote:
Since this was released to a public mailing list, I can only assume some
less than nice user will attempt this.
The only top level file system I have that can be written to by normal users
is /tmp
Should clear_tmp_enable=YES in /etc/rc.conf prevent this from causing
harm?
/etc/rc.d/cleartmp does /tmp clearing only at startup, after file
systems are mounted.
Dan
On Feb 17, 2008 10:24 PM, Jim Bryant [EMAIL PROTECTED] wrote:
One line summary:
Too many files in a top-level UFS-2 filesystem directory will cause
a panic on mount.
Kern/Critical/High Priority/SW-Bug
Which FreeBSD Release You Are Using:
6.3-STABLE
Environment (output of uname -a on the problem machine):
FreeBSD wahoo.sd67dfl.org 6.3-STABLE FreeBSD 6.3-STABLE #0: Sun Feb
10 21:13:39 CST 2008
[EMAIL PROTECTED]:/usr/obj/usr/src/sys/WAHOO-SMP i386
Note: I just cvsupped earlier, and no changes have been put into
cvsup that would fix this problem.
Full Description:
I was doing a reorganization of my filesystems, and since I do
offline installs, I keep a local distfiles collection (or did until
yesterday when this happened), and in the process, put all of the
distfiles on their own filesystem to be mounted under
/usr/ports/distfiles.
All was fine until I rebooted.
On rebooting, I got a page fault panic on mount of the new distfiles
filesystem.
i booted again, got it again, booted again this time into single-user,
and did a fsck on the filesystem, and it only showed as being dirty,
but otherwise had no problems in the eyes of fsck. booted again,
instant panic.
i booted an older 6.2 CD and mounted the filesystem fine. i then put
that filesystem the way it was by mkdir'ing a distfiles dir and mv'ing
everything into it, but on reboot it still paniced on mount.
only a newfs was able to enable the filesystem to be mounted.
today i did further research, thinking it had to do with the number of
files in the top-level filesystem directory, and found that to be true.
the short c program in the next section (how to repeat the problem)
contains this.
a second test shows that, after a newfs, if this done in any
subdirectory of that filesystem, the panic is averted, and all is well.
apparently this bug only effects top-level directories of a UFS2
filesystem.
I have not attempted this to a non-UFS2 filesystem.
IMHO, a security advisory should be released, since any user with write
access to ANY top level directory of ANY mounted filesystem (most
systems have /tmp as a world writable top level filesystem directory)
can create a panic situation requiring a newfs of the said filesystem.
A malicious user with root access can do this to /. Either way, on
boot, or any attempt to mount said filesystem on a running system, will
cause a panic, which of course will cause an unbootable system on reboot.
How to repeat the problem:
Compile and run the following as instructed:
#include stdio.h
#include stdlib.h
int main(int argc, char **argv) { int i; char buf[1024]; bzero(buf,
1024); for(i = 0; i 1; i++) { sprintf(buf, touch %s%05d\n,
argv[1], i); system((const char *)buf);} return(0);}
/* pass a top-level mountpoint directory name of a mounted filesystem,
with a trailing slash to the above as argv[1], and run.
This will create 10,000 zero-length files in the specified directory.
umount that filesystem.
perform a shitload of sync's to make sure everything outstanding is
flushed to disk on all filesystems.
mount the target filesystem (preferably from a vty or serial console to
catch the messages when it panics, which it will as soon as the mount is
attempted).
*/
Fix to the problem if known:
newfs(8)
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-fs
To unsubscribe, send any mail to [EMAIL PROTECTED]
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
