Re: svn commit: r307326 - head/sys/boot/efi/loader
On 17/10/16 18:40, John Baldwin wrote: I'm a bit hesitant to do all the type parsing in the kernel vs userland. However, I think having smbios(4) export a /dev/smbios that you can either read() or mmap() to access the table would be very convenient and let you keep the bits to parse the table in userland (and not require root if we allow read-only access to mortals on /dev/foo). This is probably a bit left-field, but I'm wondering if both methods (expose-to-loader-kenv and user-space-accessible devfs node) can be re-used for things like the Linux-oriented kernel environment page exported by SYSLINUX/PXELINUX memdisk, which I've used with some success to boot FreeBSD installers in heterogeneous private cloud/lab setups. It exports this information using an ACPI-like table in that BIOS HBA type area in x86 address space, but the table is not DSDT linked (it's not produced by the BIOS). Having a coherent means of dealing with it would be very useful, as such FreeBSD installers (which I've deployed as mfsBSD images) can then basically re-use what's been done for EFI variables for those legacy systems which don't support/can't use EFI network boot. As yet, I've not tried this with 64-bit EFI systems. ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r307326 - head/sys/boot/efi/loader
On 17/10/16 21:23, Bruce Simpson wrote: On 17/10/16 18:40, John Baldwin wrote: I'm a bit hesitant to do all the type parsing in the kernel vs userland. However, I think having smbios(4) export a /dev/smbios that you can either read() or mmap() to access the table would be very convenient and let you keep the bits to parse the table in userland (and not require root if we allow read-only access to mortals on /dev/foo). This is probably a bit left-field, but I'm wondering if both methods (expose-to-loader-kenv and user-space-accessible devfs node) can be re-used for things like the Linux-oriented kernel environment page exported by SYSLINUX/PXELINUX memdisk, which I've used with some success to boot FreeBSD installers in heterogeneous private cloud/lab setups. PS Hit send too soon -- the main reason a FreeBSD installer, or image wrapper for a FreeBSD installer tool (akin to the Debian style of network driven installer), would need access to the memdisk's ACPI-style table (containing boot & textual 'environment' page, filled out by the TFTP boot server, perhaps by scripted means) is... ...where it can't intuit all system configuration settings by reference to its primary MAC address alone, or where it needs network bootstrap information to proceed with other provisioning methods (straight to Puppet/Ansible, and/or fetching a list of pkgng pkgs to grab from some trusted package server). The code required would just pretty much resemble what you guys are doing for EFI right now, but for BIOS-era systems (of which we've got a large installed base, and mass provisioning those would be great, for the sake of recycling.) ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r206452 - head/sys/netinet
On 04/10/10 13:05, Bruce M Simpson wrote: Log: Fix a few issues related to the legacy 4.4 BSD multicast APIs. IPv4 addresses can and do change during normal operation. Testing by pfSense developers exposed an issue where OpenOSPFD was using the IPv4 address to leave the OSPF link-scope multicast groups on a dynamic OpenVPN tun interface, rather than using RFC 3678 with the interface index, which won't be raced when the interface's addresses change. I should point out that IP multicast is counter-intuitive in many areas. It seems that knowledge of how to work with it effectively is not that widespread. People who have a need to use it, often have very specific requirements. IP multicast group membership is always scoped to physical links [1]. The 4.4BSD API originally used the "primary IP address" to identify each link. Unfortunately this is not a persistent identifier, especially so in the use-case which had problems. In the updated API specified in RFC 3678, the primary key for multicast memberships, changes to the interface index. routed(8) in FreeBSD's SVN tree uses this new API; thanks to phk for reviewing and testing my change. In the case of OpenOSPFD+OpenVPN, the issue manifested itself in situations where this "primary IP address" changed. OpenVPN shims address assignment as part of its wire protocol, which is where the address change originates. This is purely a by-product of using an API which depends on using an IPv4 address as a key (IP_ADD_MEMBERSHIP/IP_DROP_MEMBERSHIP), when that key may change at any time. There's some time domain uncertainty with that change. PF_ROUTE is an out-of-band mechanism used by OpenOSPFD to learn about the address change, and it is dispatched separately from the change itself; there may be queueing and context switches involved. It also creates some ambiguity for in_multi instances, which the kernel may not be able to resolve, if that key has been blown away. Fortunately, such ambiguity is private to each socket. Furthermore, this makes IGMP somewhat unreliable, although mechanisms do exist in the protocol to work-around the end-station's identifier being lost in this way. The upstream IGMP querier (usually the mcast router) will hold state based on the end-station's "primary IP address", this will eventually time out due to unanswered queries. MLD side-steps this by always requiring an IPv6 link-scope address in control traffic. Using the more recent multicast RFCs, supported now by Windows, Linux, OpenSolaris, and now FreeBSD, can side-step these issues; it is the preferred API. P.S. HEAD was probably already resilient against this for joins. I plan to MFC a similar version of this change to 8 soon. [1] sendto() to an IP multicast address, without an interface specified, makes no sense -- unless the host is also an mcast forwarder. You can get away with default route resolution through the routing tables up to a point, but if your box is multihomed, all bets are off. ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r206452 - head/sys/netinet
On 04/16/10 09:23, Alexander Leidinger wrote: IP multicast group membership is always scoped to physical links [1]. The 4.4BSD API originally used the "primary IP address" to identify each link. Unfortunately this is not a persistent identifier, especially so in the use-case which had problems. Is/was this the reason why multicast does not work in jails? The above point is totally unrelated to jail. I think the problem with jail is the fact that to receive multicast, sockets normally need to be bound to INADDR_ANY. Obviously, jail changes socket behaviour in interesting ways. This may require refactoring udp_input() considerably. We use the 4.4BSD legacy LIST_FOREACH() loop to deliver, rather than using a fan-in map (which is the Windows/Solaris approach). Linux also has 4.4BSD semantics, but can work around this by examining the SO_BINDTODEVICE option in the same path. ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r191651 - head/usr.sbin/mtest
John, That's news to me. I'm pretty sure I tested this code with and without INET6 when I checked it in, given I was mostly testing without INET6. This was a very long time ago, so I was surprised to receive your message. Could something have changed to have broken mtest? thanks BMS John Baldwin wrote: > On Wednesday, April 29, 2009 5:50:04 am Bruce M Simpson wrote: >> Author: bms >> Date: Wed Apr 29 09:50:04 2009 >> New Revision: 191651 >> URL: http://svn.freebsd.org/changeset/base/191651 >> >> Log: >> Merge IPv6-capable mtest(8) from MLDv2 branch. >> >> Modified: >> head/usr.sbin/mtest/Makefile >> head/usr.sbin/mtest/mtest.8 >> head/usr.sbin/mtest/mtest.c > > This is completely broken as it fails to work if you don't have INET6 > compiled > into the kernel, even if all you want to do is test joining IPv4 multicast > groups. > ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r316435 - in head: sbin/ipfw sys/conf sys/modules sys/modules/ipfw_pmod sys/netpfil/ipfw/pmod
On 03/04/17 15:12, Julian Elischer wrote: > On 3/4/17 11:07 am, Andrey V. Elsukov wrote: >> Author: ae >> Date: Mon Apr 3 03:07:48 2017 >> New Revision: 316435 >> URL: https://svnweb.freebsd.org/changeset/base/316435 > > it was always my intention to hook netgraph modules into ipfw in this way In my humble opinion, in an ideal world, everything warrants a rethink - in terms of "abstract forwarding elements". This is how a lot of the newer integrated routing/switching hardware seems to behave; designs like the FM6000, Juniper's Trio, and so on. For now, we've got several bodies of firewall code available in the FreeBSD base system. The MSS tweak is much appreciated; it makes DSL and Cable access more usable for many. But I appreciate the sentiment of taking what is - on the face of it - a simple network protocol transformation at a FreeBSD hop, as something which really, we'd ideally have a common way of expressing. I struggle to keep track of all of this development, personally. It would be great if we could take the best from all of them, incorporate scalability for LRO and so on, and hybrid forwarding chips, or other offload stack approach, in the same code base somehow. It's worth a trip down to the 1.4Tbit/s Alien Superchannel to see what I'm getting at. Multi-100GBE into 1U is a reality now. ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r316676 - in head/sys/netinet: . tcp_stacks
This is a really good thing to have in. Thanks, Steven and others, for optimizing for this big case. ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r317383 - in head: . etc/mtree include lib/libc/net rescue/rescue sbin sbin/atm sbin/atm/atmconfig share/man/man4 sys/boot/forth sys/conf sys/dev/en sys/dev/fatm sys/dev/hatm sys/dev/p
Hopefully, with packet mode DSL, none of this should be needed again. ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r317383 - in head: . etc/mtree include lib/libc/net rescue/rescue sbin sbin/atm sbin/atm/atmconfig share/man/man4 sys/boot/forth sys/conf sys/dev/en sys/dev/fatm sys/dev/hatm sys/dev/p
On 27/04/17 18:44, Bruce Simpson wrote: > Hopefully, with packet mode DSL, none of this should be needed again. > JFYI I'm referring to ye olde Packet Transfer Mode (PTM) DSL, TR-009... which dispenses with the need for ATM framing on DSL circuits. Some US ISPs have been observed doing this in the wild. DSL isn't going away any time soon, though -- many of us still use it as a backup circuit for other things (vs Metro Ethernet, G.FAST, DOCSIS etc.) ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r304436 - in head: . sys/netinet
Slawa, I'm afraid this may be a bit of a non-sequitur. Sorry.. I seem to be missing something. As I understand it this thread is about Ryan's change to netinet for broadcast. On 26/08/16 15:49, Slawa Olhovchenkov wrote: On Sun, Aug 21, 2016 at 03:04:00AM +0300, Slawa Olhovchenkov wrote: On Sun, Aug 21, 2016 at 12:25:46AM +0100, Bruce Simpson wrote: Whilst I agree with your concerns about multipoint, I support the motivation behind Ryan's original change: optimize the common case. Oh, common case... I am have pmc profiling for TCP output and see on this SVG picture and don't find any simple way. You want to watch too? At time peak network traffic (more then 25K connections, about 20Gbit total traffic) half of cores fully utilised by network stack. This is flamegraph from one core: http://zxy.spb.ru/cpu10.svg This is same, but stack cut of at ixgbe_rxeof for more unified tcp/ip stack view http://zxy.spb.ru/cpu10u.svg ... I appreciate that you've taken the time to post a flamegraph (a fashionable visualization) of relative performance in the FreeBSD networking stack. Sadly, I am mostly out of my depth for looking at stack wide performance for the moment; for the things I look at involving FreeBSD at work just at the moment, I would not generally go down there except for specific performance issues (e.g. with IEEE 1588). It sounds as though perhaps you should raise a wider discussion about your results on -net. I would caution you however that the Function Boundary Trace (FBT) provider for DTrace can introduce a fair amount of noise to the raw performance data because of the trap mechanism it uses. This ruled it out for one of my own studies requiring packet-level accuracy. Whilst raw pmc(4) profiles may require more post-processing, they will provide less equivocal data (and a better fix) on the hot path, due also to being sampled effectively on a PMC interrupt (a gather stage- poll core+uncore MSRs), not purely a software timer interrupt. thanks Bruce ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r306652 - head/usr.sbin/arp
On 03/10/16 20:02, Eric van Gyzen wrote: Author: vangyzen Date: Mon Oct 3 19:02:22 2016 New Revision: 306652 URL: https://svnweb.freebsd.org/changeset/base/306652 Log: Update arp(4) to document the net.link.ether.inet.garp_rexmit_count sysctl. Meh, acronym collision. It's probably obvious in this context that GARP stands here for Gratuitous ARP, but my mental autocomplete reads it as Generic Attribute Registration Protocol (GARP). However, that GARP -- 802.1ak -- is due to be replaced with MRP. ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r306652 - head/usr.sbin/arp
On 03/10/16 20:22, Eric van Gyzen wrote: The collision is unfortunate, but I agree that the context should be enough. Agreed -- other technical writers have also used this version of the GARP acronym in doco. However, that GARP -- 802.1ak -- is due to be replaced with MRP. The "Mental-map Rewriting Protocol"? ;-) Multiple Registration Protocol (MRP) is intended to fill most of the roles GARP/GVRP did, for dynamic VLAN, end-station MAC and L2 multicast registration. (Think Ethernet multicast without IP.) Actually, being reminded of this gave me an idea -- adding a subset of what's needed to support MRP to if_bridge would probably also help for supporting Ethernet rings; those protocols need to call into VLAN registration and port blocking too. It would make for some good junior kernel hacker tasks... ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r267633 - head/sys/sys
On 19/06/2014 21:05, Hans Petter Selasky wrote: Are there any existing C++ kernel modules, or in ports? Even though, C++ kernel modules can be compiled with C files aswell, containing the sysctls. The Click Modular Router is implemented in C++, I have occasionally pitched in with keeping it up to date and building on FreeBSD (although not for a few years now). Putting myself in the shoes of a third party developer, I can see that C++ compatibility would be important, so I hope a solution can be found here. Bruce ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r267633 - head/sys/sys
On 19/06/2014 06:28, Hans Petter Selasky wrote: Author: hselasky Date: Thu Jun 19 05:28:42 2014 New Revision: 267633 URL: http://svnweb.freebsd.org/changeset/base/267633 Log: Initialize sysctl OID structure by record. So, has there been any traction on rethinking / backing out this change (which breaks the compilation of C++ kernel modules) ? ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r268566 - head/usr.bin/users
On 12/07/2014 12:34, Bruce Evans wrote: This joke is bad. The C++ version is worse in every way. I concur with everything you have said in your message. Moral of story: it is very, very easy to introduce bloat using C++, and using a higher level language does not automatically lead to better code quality. ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r268566 - head/usr.bin/users
On 12/07/2014 16:31, Ian Lepore wrote: It is in no way established that any kind of "mess" exists. On the contrary, the metrics and analysis which bde@ has presented seem pretty clear to me. All we have is some people who appear to hate C++ expressing their opinions about how they hate C++. All the whining about how many more bytes the compiled code is or many milliseconds something takes to compile don't add up to any actual problem. Other developers may quite reasonably look out for code quality and preservation of non-functional requirements across the board. I am bemused that you characterize this as "whining", thus taking a technical discussion into "ad hominem" territory. My opinion is that the original commit message was exactly correct: The code was rewritten to be cleaner and easier to understand and maintain. We need more of the same. Metadata is not the same thing as content -- the commit message can be as erudite as one likes, but at the end of the day, if the change is of dubious value, people will call you on it. Bruce ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r268943 - in head: include lib/libc/stdlib
On 21/07/2014 16:22, Pedro F. Giffuni wrote: ] Log: Add re-entrant versions of the hash functions based on the GNU api. What, if anything, can be done about qsort_r() API incompatibility? ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r268943 - in head: include lib/libc/stdlib
On 03/08/2014 15:27, Warner Losh wrote: What, if anything, can be done about qsort_r() API incompatibility? qsort_r is non-standard and we did it first, plus we will want to stay compatible with Apple :). I guess we could do some ugly parameter swapping in the case where _GNU_SOURCE is defined, but I won’t volunteer to do that. Are there any ABI considerations for the change? I'm in agreement with Pedro here. Some form of compile-time checking is the best one can hope for in that situation, as it would be difficult to "ret-con" the qsort_r() ABI itself. The glibc implementation swaps two pointers in its signature. One of those points to executable code. The last time this caused problems for me was when testing the new CScope indexing backend by Elad Lahav on BSD/Mac. He had developed on Linux, however the quick fix was to fall back to using non-reentrant qsort(). ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r269621 - head/sys/boot/common
On 06/08/2014 01:36, Marcel Moolenaar wrote: Log: Optionally include the install command as found on Juniper products like EX and SRX. The install command uses pkgfs to extract a kernel, zero or more modules and a root file system from the specified package and boots the kernel. The name of the kernel, the list of modules and the name of the root file system can be specified by putting a file called "metatags in the package. Nice. This is going to be really useful for people building appliances, both as a low-level recovery mechanism, and/or upgrade mechanism. ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r273274 - head/sys/netpfil/ipfw
On Sun, 19 Oct 2014, at 13:02, Andriy Gapon wrote:
> I think that on platforms where an optimized version of fls() is
> available that
> would work faster than this cool piece of bit magic.
This is a common enough idiom that perhaps a macro should be added:
sys/param.h:
#define roundup(x, y) x)+((y)-1))/(y))*(y)) /* to any y */
#define roundup2(x, y) (((x)+((y)-1))&(~((y)-1))) /* if y is powers of
two */
#define powerof2(x) x)-1)&(x))==0)
sys/amd64/amd64/mp_machdep.c:
/*
* Round up to the next power of two, if necessary, and then
* take log2.
* Returns -1 if argument is zero.
*/
static __inline int
mask_width(u_int x)
{
return (fls(x << (1 - powerof2(x))) - 1);
}
--
BMS (sent via webmail)
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r273855 - head/sys/netinet6
Hello,
This is a really inconvenient time for me (I am up against a deadline)
but I am not 100% comfortable with this change.
On Thu, 30 Oct 2014, at 10:59, Andrey V. Elsukov wrote:
> Log:
> Fix mbuf leak in IPv6 multicast code.
> When multicast capable interface goes away, it leaves multicast groups,
> this leads to generate MLD reports, but MLD code does deffered send and
> MLD reports are queued in the in6_multi's in6m_scq ifq. The problem is
> that in6_multi structures are freed when interface leaves multicast
> groups
> and thread that does deffered send will not take these queued packets.
A few comments:
1) Stylistic -- a change of this kind should probably be part of
inm_purge() itself because it modifies state which is private to the
group membership.
2) Logical -- The patch forces pending (queued) state change record
fragments to be freed when the parent interface is taken down.
Unfortunately, those are pending for a reason; there has been a state
change, and MLD needs to communicate it upstream to on-link routers (and
snooping switches).
So - there is a risk with this approach that upstream MLD listener (e.g.
router, switch) will be inconsistent, at least until the next General
Query.
A better approach might be to force an INCLUDE {} to be sent for the
group (there are other parts of the code which try to do this for
similar events), but if the parent interface has already been taken
down, all bets are off. As of writing - The FreeBSD networking stack
doesn't provide any hints either way about the nature of the teardown.
Perhaps need to be a distinction between use cases where a hasty
teardown is unlikely to have operational impact (e.g. an ephemeral VPN
session between two nodes which is point-to-point in nature, and not
generally used for forwarding traffic), and cases where it may impact
other users (e.g. an MLD membership residing on a wireless interface,
which might result in unwanted multicast traffic being relayed to an
802.11 ESS).
--
BMS (sent via webmail)
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r274017 - head/sys/kern
On Mon, 3 Nov 2014, at 08:21, Julian Elischer wrote:
> I'm open to being persuaded but I think we need to have a discussion
> about stack usage. We used to say that anything greater that, say
> 64 bytes should probably be allocated.
I have to admit the level of stack usage in my current $DAYJOB project
worries me (although I haven't profiled for this).
Every struct in6_addr{} is 16 bytes, and those mount up quickly.
--
BMS (sent via webmail)
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r274672 - in head/contrib/libxo: . libxo xolint
On 20/11/2014 21:10, Craig Rodrigues wrote: Converting these (and other) utilities to use libxo will make it a lot easier to write analysis tools like eagleeye. It'll also make it easier for anyone doing systems-level study. Right now I have a bunch of shell scripts which hoover up command output, use sed/awk/grep for basic post-processing into CSV/TSV, and throw the lot into a tarball. ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r265456 - head/libexec/rtld-elf
Mark, On 06/05/2014 19:07, Mark Johnston wrote: Log: Add a postinit debugger hook to rtld. This will be used by dtrace(1) to halt the victim process before its entry point is called, at which point probes and DOF data are registered with the kernel. I recently had a situation where I had to run gdb on a static (and stripped) Linux binary, under the Linuxolator. Perhaps this change can be used there too? Bruce ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r265456 - head/libexec/rtld-elf
On 07/05/2014 18:31, Mark Johnston wrote: The Linuxulator makes use of Linux's loader rather than rtld; this was the source of the problem fixed in r254018, for example. Static binaries are not invoked through rtld either, so I don't think this change would have helped anyway. I'm aware that the rtld code is otherwise unrelated to how Linux ELF images are activated, and should have been clearer in my original message. Sorry about that. My question is really: is there an easy way of setting a "start of program" breakpoint for such binaries e.g. where "_start" and/or "main" are not exposed in the (nonexistent) symbol table? Currently I have to inspect the ELF load address and set a breakpoint manually in such cases. This is something which might be addressed by a GDB macro, although we may not always be using GDB. ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r276083 - head/etc
On 22/12/2014 21:26, Dmitry Morozovsky wrote: Log: Add VAMI (VMware Appliance Management Interface) port. This is vApp / VMware Studio related; any plans to get FreeBSD guests working? ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r277054 - in head: share/man/man4 sys/modules/cc sys/modules/cc/cc_dctcp sys/netinet sys/netinet/cc
On 12/01/2015 08:33, Hiren Panchasara wrote: Log: DCTCP (Data Center TCP) implementation. Right On Commander! ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r279028 - in head/usr.sbin: . ifmcstat
Gleb, Correct me if I'm wrong -- but doesn't this set of changes remove the ability for the user to see the stack-wide membership filters on each link? The implementation required KVM as it must inspect the SSM filters themselves to obtain this information. On 19/02/2015 22:42, Gleb Smirnoff wrote: Now that IGMP and MLD sysctls provide a clean API structures that do not leak kernel internal stuff, reconnect ifmcstat(1) back to build. The change is well motivated, but the job is only half done. The backend code you have added simply reflects the per-link information to userland as a flat data structure; it does not appear to report what the membership filters are. This would require taking a lock, walking the RB-tree for the in-mode filters, and serializing the data to userland as a variable length structure. regards Bruce ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r279028 - in head/usr.sbin: . ifmcstat
On 21/02/2015 00:50, Gleb Smirnoff wrote: May be you refer to code that was always under #if 0, disabled due to difficulty to go through RB-trees via kvm(3)? My bad - yes - this code was unfinished as of SVN rev 192923, it seems I ran into problems with RB-tree walks through KREAD(). To implement this as a sysctl, one might copy the backend implementation of getsourcefilter(3) and work from there, specifically the internal IP_MSFILTER socket option. Bruce ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r271735 - head/sys/net
On Thu, 18 Sep 2014, at 07:04, Kevin Lo wrote: > Sorry, I overlooked that. Marcelo has a patch with 802.1p tagging > support, > I thought the patch was committed. I agree the comment change should be reverted. I changed if_ethersubr.c many years ago to decode 802.1p tags into the mbuf packet header if they are present. However, to my knowledge, there is no support (e.g. in the form of a DiffServ / IntServ mapping) further up in the stack. If someone plans to add this, great -- that would be needed for any form of tangible 802.1p support. -- BMS (sent via webmail) ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r303574 - head/sys/dev/gpio
On 31/07/16 07:24, Adrian Chadd wrote: [gpioled] add support for inverting the LED polarity. No, this isn't a star trek science joke - sometimes LEDs are wired up to be active low, so this is needed. Actually, just about every bit of hardware I have interacted with on that level recently lights on low. ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r303522 - head/sys/dev/cxgbe
"Yes, I know it's not a typewriter. Why is this command not working?" Perhaps this errno code should be aliased... and strerror() massaged in places... assuming we strictly follow the POSIX. ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r303522 - head/sys/dev/cxgbe
On 01/08/16 17:49, Ian Lepore wrote: ... In addition, the strerror() output for ENOTTY says nothing about a typewriter, the text is "Inappropriate ioctl for device." If that semantic gap has already been plugged, ignore my message. ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r303716 - head/crypto/openssh
DES, I believe this breaks logging into various embedded network devices, unfortunately. E.g. the Netonix WISP Switch, which uses an embedded Linux variant with dropbear 0.51. It is expecting to use DSA not RSA for the key exchange.g Is there a way to revert this change, at least on an ongoing operational basis (e.g. configuration file) for those of us who use FreeBSD to connect directly to such devices? I speculate this might affect folk logging into Cisco UCS IPMI controllers, also. thanks Bruce ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r303716 - head/crypto/openssh
On 07/08/16 11:58, Bruce Simpson wrote: Is there a way to revert this change, at least on an ongoing operational basis (e.g. configuration file) for those of us who use FreeBSD to connect directly to such devices? I was able to override this (somewhat unilateral, to my mind) deprecation of the DH key exchange by using this option: -oKexAlgorithms=+diffie-hellman-group1-sha1 Obviously that is too much of a mouthful for day-to-day operational memory. I shudder to think how a novice SSH user, who is otherwise competent with network switches, is going to cope with this confusion. OK, so deprecating the (unwanted/vulnerable/obsolete for whatever other reason) cipher suite is an ideologically sound move, but the road to hell is paved with good intentions. But surely the operational implications of this on people who use SSH on a daily basis could have been better thought out, given many of these devices cannot just magically be updated to stop using DH? As I've said this may not affect just Netonix devices, but a wide range of network devices which -- let's be frank -- be grateful they even have a basic SSH implementation. I'm staring at $VENDOR_A and $VENDOR_H. Strikes me as foot shooting. Just my 2c. Please, at least add a central knob for overriding this. pfSense took the change too. I couldn't log in to our local Netonix this morning (without booting up a Linux laptop), which violated POLA horribly for me. ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r303716 - head/crypto/openssh
On 07/08/16 12:43, Oliver Pinter wrote: I was able to override this (somewhat unilateral, to my mind) deprecation of the DH key exchange by using this option: -oKexAlgorithms=+diffie-hellman-group1-sha1 You can add this option to /etc/ssh/ssh.conf or ~/.ssh/config too. Can this at least be added (commented out, if you really want to enforce this policy on users out-of-the-box) to the former file in FreeBSD itself? And a note added to UPDATING? Otherwise, it's almost as though those behind the change are assuming that users will just know exactly what to do in their operational situation. That's a good way to cause problems for folk using FreeBSD in IT operations. (systemd epitomises this kind of foot shooting.) I understand already - you want to deprecate a set of key exchanges, and believe in setting an example - but the rest of the world might not be ready for that just yet. ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r303716 - head/crypto/openssh
On 07/08/16 15:40, Warner Losh wrote: That’s a cop-out answer. We, as a project, need to articulate to our users, whom we care about, why this rather obnoxious hit to usability was taken. The answer must be more complete than “We just disabled it because upstream disabled it for reasons we’re too lazy to explain or document how to work around" Alcatel-Lucent OmniSwitch 6800 login broken (pfSense 2.3.2 which accepted the upstream change, workaround no-go) [2.3.2-RELEASE][r...@gw.lab]/root: ssh -l admin -oKexAlgorithms=+diffie-hellman-group1-sha1 192.168.1.XXX Fssh_ssh_dispatch_run_fatal: Connection to 192.168.1.XXX port 22: DH GEX group out of range ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r303716 - head/crypto/openssh
On 07/08/16 18:34, Andrey Chernov wrote: Alcatel-Lucent OmniSwitch 6800 login broken (pfSense 2.3.2 which accepted the upstream change, workaround no-go) [2.3.2-RELEASE][r...@gw.lab]/root: ssh -l admin -oKexAlgorithms=+diffie-hellman-group1-sha1 192.168.1.XXX Fssh_ssh_dispatch_run_fatal: Connection to 192.168.1.XXX port 22: DH GEX group out of range DH prime size must be at least 2048, openssh now refuse lower values. Commonly used DH size 1024 can be easily broken. See https://weakdh.org diffie-hellman-group1-sha1 use DH 1024 and insecure sha1 both. I appreciate that, but what do I as a user do about it? My distribution has changed behaviour I rely on in an operational setting. My initial reaction is likely to be one of confusion, and general dismay. I appreciate that this is done for security reasons, but it could take an arbitrarily long time for a lot of deployed hardware in current use to be updated. (On the other hand, the introduction of, say ED25519 has been more gradual, and has tended to see uptake in e.g. Linux-based ARM products.) ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r303811 - in head/sys: net net80211
On 07/08/16 20:23, Peter Jeremy wrote: On 08/07/16 05:48, Adrian Chadd wrote: +#defineETHER_IS_BROADCAST(addr) \ ... IMHO, Adrian's code is clearer and micro-optimisations like this belong in the complier, not the code. *cough* *cough* 2007 wants its patch back. https://people.freebsd.org/~bms/dump/old/latest-8021p.diff The whole point of using bcmp() was to allow it to be inlined by the compiler for the target arch, rather than forcing it to play guessing games with (lowest-common-denominator machine-word-size) integer accesses. ETHER_IS_MULTICAST(), by contrast, only needs to check a single bit in the 48-bit MAC. ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r303716 - head/crypto/openssh
On 08/08/16 11:36, Dag-Erling Smørgrav wrote: Bruce Simpson writes: Alcatel-Lucent OmniSwitch 6800 login broken ... This patch did not remove weak DH groups. That happened in 7.0p1 back in January. So my reading of this is that PuTTy may be the best workaround for end-users who have to speak to older SSH implementations. That's what I ended up using to get around some of the SSH interop mess with the Proxim AP4000, although much of that was not directly related to the cipher suite! (But ideally it should support X11-headless operation. To my knowledge, and as others have mentioned, it is currently believed to require it.) ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r304436 - in head: . sys/netinet
This potentially breaks reception of IPv4 broadcasts where FreeBSD is
the endpoint at the end of a P2P interface, or other forms of links,
where there is no guarantee that the link layer will set M_BCAST (or
indeed M_MCAST).
On 18/08/16 23:59, Ryan Stone wrote:
Author: rstone
Date: Thu Aug 18 22:59:05 2016
New Revision: 304436
URL: https://svnweb.freebsd.org/changeset/base/304436
Log:
Don't check for broadcast IPs on non-bcast pkts
in_broadcast() can be quite expensive, so skip calling it if the
incoming mbuf wasn't sent to a broadcast L2 address in the first
place.
Reviewed by: gnn
MFC after: 2 months
Sponsored by: EMC / Isilon Storage Division
Differential Revision: https://reviews.freebsd.org/D7309
Modified:
head/UPDATING
head/sys/netinet/udp_usrreq.c
Modified: head/UPDATING
==
--- head/UPDATING Thu Aug 18 22:59:00 2016(r304435)
+++ head/UPDATING Thu Aug 18 22:59:05 2016(r304436)
@@ -32,6 +32,14 @@ NOTE TO PEOPLE WHO THINK THAT FreeBSD 12
"ln -s 'abort:false,junk:false' /etc/malloc.conf".)
20160818:
+ The UDP receive code has been updated to only treat incoming UDP
+ packets that were addressed to an L2 broadcast address as L3
+ broadcast packets. It is not expected that this will affect any
+ standards-conforming UDP application. The new behaviour can be
+ disabled by setting the sysctl net.inet.udp.require_l2_bcast to
+ 0.
+
+20160818:
Remove the openbsd_poll system call.
__FreeBSD_version has been bumped because of this.
Modified: head/sys/netinet/udp_usrreq.c
==
--- head/sys/netinet/udp_usrreq.c Thu Aug 18 22:59:00 2016
(r304435)
+++ head/sys/netinet/udp_usrreq.c Thu Aug 18 22:59:05 2016
(r304436)
@@ -126,6 +126,11 @@ SYSCTL_INT(_net_inet_udp, OID_AUTO, blac
&VNET_NAME(udp_blackhole), 0,
"Do not send port unreachables for refused connects");
+static VNET_DEFINE(int, udp_require_l2_bcast) = 1;
+SYSCTL_INT(_net_inet_udp, OID_AUTO, require_l2_bcast, CTLFLAG_VNET |
CTLFLAG_RW,
+&VNET_NAME(udp_require_l2_bcast), 0,
+"Only treat packets sent to an L2 broadcast address as broadcast packets");
+
u_long udp_sendspace = 9216; /* really max datagram size */
SYSCTL_ULONG(_net_inet_udp, UDPCTL_MAXDGRAM, maxdgram, CTLFLAG_RW,
&udp_sendspace, 0, "Maximum outgoing UDP datagram size");
@@ -523,7 +528,8 @@ udp_input(struct mbuf **mp, int *offp, i
pcbinfo = udp_get_inpcbinfo(proto);
if (IN_MULTICAST(ntohl(ip->ip_dst.s_addr)) ||
- in_broadcast(ip->ip_dst, ifp)) {
+ ((!VNET_NAME(udp_require_l2_bcast) || m->m_flags & M_BCAST) &&
+ in_broadcast(ip->ip_dst, ifp))) {
struct inpcb *last;
struct inpcbhead *pcblist;
struct ip_moptions *imo;
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r304436 - in head: . sys/netinet
On 20/08/16 12:33, Bruce Simpson wrote: This potentially breaks reception of IPv4 broadcasts where FreeBSD is the endpoint at the end of a P2P interface, or other forms of links, where there is no guarantee that the link layer will set M_BCAST (or indeed M_MCAST). I appreciate it probably looks like a quick win, but if it's only been tested with Ethernet (it looks like it has only been written with Ethernet in mind), it does strongly look as if it breaks broadcast for UDP/IPv4 in other situations. So, maybe it should be backed out ASAP. (I haven't tested this code.) It is perfectly legal for broadcast packets to be addressed to the end of a P2P or non-Ethernet link, which may not set M_BCAST or M_MCAST. The classic example is ATM (Non-Broadcast, Multiple Access (NBMA)) but the situation may be readily observed with loopback or tunnels. The same issue doesn't exist in your output path change, which looks sane. The same issue doesn't exist with IPv6 where broadcast is dead. ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r304436 - in head: . sys/netinet
On 20/08/16 15:52, Ryan Stone wrote: It is perfectly legal for broadcast packets to be addressed to the end of a P2P or non-Ethernet link, which may not set M_BCAST or M_MCAST. The classic example is ATM (Non-Broadcast, Multiple Access (NBMA)) but the situation may be readily observed with loopback or tunnels. Can you give an example of a tunneling protocol support by FreeBSD that may be affected? I looked and didn't see any. OpenVPN, as best that I can tell, injects frames into a tap interface, which appears as a Ethernet interface, for example. Potentially any and all PPP, tun(4); any link layer with plain IP on top of it other than Ethernet, which may not set M_BCAST for an IPv4 broadcast packet (or does not distinguish between broadcast and unicast/multicast packets). if_ethersubr.c does set M_BCAST correctly for Ethernet broadcast packets in the receive path. That is guaranteed, and the majority of Ethernet network drivers will pass packets up the stack through it more or less directly. tap(4) is an exception because, as you rightly point out, it is pretty faithfully Ethernet, although I may have had to add code around Ethernet address conditions like this to it in the very distant past. tun(4) on the other hand is a plain, PPP-like, IP tunnel. But this mbuf flag is not guaranteed to be set in all situations; e.g. where the link layer does not have the concept of broadcast being distinct from other kinds of network traffic. PPP and ATM are the most obvious examples. ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r304436 - in head: . sys/netinet
On 20/08/16 16:27, Ryan Stone wrote: Can you send a broadcast packet through an L3 tunnel? I thought that a L2 tunnel was required. Yes. This is perfectly legal and necessary for forwarding of IPv4 broadcasts to work. (it is Internet Protocol after all, not Infernal-ethernet-extension Protocol. ;-)) The change is in UDP input so it will not affect routers. But if a FreeBSD system were at the end of a link layer, and was the final recipient of the IPv4 broadcast packet, then if that link layer is not Ethernet, all bets are off. That situation could occur very easily where FreeBSD is hanging off the end of a PPPoE link: e.g. consumer DSL, microwave, etc. The underlying link layer for the tunnel might be Ethernet, but it will be demuxed as a PPP tunnel. PPP is treated as a bit pipe and does not normally distinguish between unicast, broadcast, multicast. Broadcast destined for the host on its PPP address would be transported inside the tunnel, encapsulated as a normal unicast Ethernet packet. But this mbuf flag is not guaranteed to be set in all situations; e.g. where the link layer does not have the concept of broadcast being distinct from other kinds of network traffic. PPP and ATM are the most obvious examples. We don't support ATM, but PPP is a good example. I hadn't thought of that. Hm, ip_input() already has to check for a broadcast IP. What it set M_BCAST on the mbuf at that time? ATM is one of those things everyone kind of has to support by default in some way because of the ITU ADSL specs. It is literally written into G.992.x. Linux can do it, FreeBSD can't. PPP over ATM is something BT inflicted on the UK all by themselves, though, and we wish it would just go away. Whilst your suggestion may work, it may be dangerous, as you are then stepping on the meaning of the flags. Some of them are intended to be used for one layer to signal another. M_BCAST is pretty rigidly defined in mbuf.h as "The link layer received this as a broadcast / I intended for link layer to send this as a broadcast". M_PROTOFLAGS is normally used to clear flags with different meaning in different protocol layers. M_MCAST also has similar status. On my PhD, I wrote code which uses a private Ethernet link between FreeBSD routers for load distribution; it distributes unicast traffic using IPv6 multicast. It uses multicast both as convenience, and as a way to 'channelise' traffic if the Ethernet link supports it, using multicast groups. (Modern shared memory switches can slice L2 multicast traffic like this quite efficiently. So one slice of unicast traffic could be switched across locations purely at L2. However, the distribution of actual IPv6 multicast was out of scope.) The routers have to very carefully clear M_MCAST on egress, to ensure normal L2 next-hop resolution for IPv6 destinations. ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r304436 - in head: . sys/netinet
On 20/08/16 16:42, Bruce Simpson wrote: On 20/08/16 16:27, Ryan Stone wrote: Can you send a broadcast packet through an L3 tunnel? I thought that a L2 tunnel was required. Yes. This is perfectly legal and necessary for forwarding of IPv4 broadcasts to work. (it is Internet Protocol after all, not Infernal-ethernet-extension Protocol. ;-)) For completeness: This does not hold true for L2 in L2, the most obvious example being Metro Ethernet VMAN style service. There, Ethernet is the transport (link layer), as well as the payload. That's a concrete example of the kind of L2 'tunnel' you may be referring to. Sometimes, specific Ethernet [broad|multi]cast destinations -- notably L2 control protocols, e.g. RSTP within the customer VLAN, may need to be tunnelled (Provider-Backbone-Bridges (PBB) style). Alternatively, the L2 destination MAC may be rewritten for that specific address, to avoid the destination being interpreted by routers in the Metro Ethernet core. It can be considered a crude form of Ethernet NAT, but it's common practice. But, for IP, forwarding IPv4 directed broadcast packets over a non-broadcast link is completely legal (and required for normal operation). ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r304436 - in head: . sys/netinet
On 20/08/16 17:27, Bruce Simpson wrote: Alternatively, the L2 destination MAC may be rewritten for that specific address, to avoid the destination being interpreted by routers in the Metro Ethernet core. s/routers/switches/ -- in some views of the world, they are the same :) PBB is also known as 'MAC-in-MAC' for this reason. There's also L2TP pseudowires, but we're not really there yet. ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r304436 - in head: . sys/netinet
On 20/08/16 17:36, Ryan Stone wrote: + adrian@, who prompted me to look at UDP in the first place I'm really not sure what my next step should be. I'm willing to revert r304436, but I really don't want to revert r304437 because we've seen crashes in the real world due to the missing locking. Unfortunately, reverting r304436 would mean that every UDP packet would incur the overhead of an additional rlock/runlock call, which is what I've been trying to avoid. I don't see a particularly good path forward. Your changes have the same motivations as my historical change to move group-level IP multicast lookups (and locking) out of the output path. Source-specific multicast (SSM) requires support for reception filters on individual sockets, so I moved those multicast-specific input checks into the socket layer. - The if_addr_lock would appear to be an excellent candidate to be converted into an rmlock, but unfortunately we made the mistake of exposing the lock through the ifnet KPI. Fixing that would require rototilling every single Ethernet/WiFi/etc driver in the tree. Oops... - Providing a mechanism for ip_input() to signal to udp_input() that the packet was addressed to an L3 broadcast address would require rototilling the pr_input interface, and I'd have to carefully ensure that if anything might interpose itself between the two layers (IPSec?) that the flag would have to be passed through correctly. - mbuf flags are far too precious to allocate a new one for such a narrow use-case Agree. Then it may be that slipping the definition of M_BCAST to mean 'And IP identified that this is network-layer broadcast' is the most expedient solution. A quick look around suggests you may be able to get away with it. You'd essentially be widening the definition of the existing M_BCAST flag. Given the ultimate consumer of the mbuf in the case you are addressing in the code (bad pun) is udp_input(), that may be fine. (We had to do something similar for ILNPv6, because of how IPv6 input works, so it allocates an unused bit from the IPv6 flow label.) But it has to be qualified very carefully. If L2 is re-entered from IP (e.g. a netgraph IP-level hook), it may have unexpected side-effects. I have not given this the KScope treatment, just a quick fxr.watson.org. ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r304436 - in head: . sys/netinet
On 20/08/16 17:49, Bruce Simpson wrote: - Providing a mechanism for ip_input() to signal to udp_input() that the packet was addressed to an L3 broadcast address would require rototilling the pr_input interface, and I'd have to carefully ensure that if anything might interpose itself between the two layers (IPSec?) that the flag would have to be passed through correctly. (We had to do something similar for ILNPv6, because of how IPv6 input works, so it allocates an unused bit from the IPv6 flow label.) In case anyone's interested, IPSEC is one big reason we had to do this. Performance was another; without marking ILNPv6 traffic, demultiplexing an ILNPv6 packet -- even 'just enough' to forward it -- would have required processing all IPv6 extension headers, and additional state lookups. Using a bit from the flow label means ILNPv6 routers don't need to do any of that, and it got translated into an M_ILNP mbuf flag internally. I shudder to think what gymnastics the FreeBSD stack may have to endure to accommodate modern Ethernet switching capabilities, though. ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r304436 - in head: . sys/netinet
On 20/08/16 18:30, Slawa Olhovchenkov wrote: Anyway, don't should relay on the L2 information, you can recive L3 unicast addressed packets (with alien dst IP address) in L2 broadcas packet. That is exactly what the egress routers in chapter 6 of my PhD do, but in a very controlled way -- by setting and clearing M_MCAST ! http://hdl.handle.net/10023/8681 In Ch6, ILNPv6 packets are effective being routed, using a multicast next-hop address (as distinct from the destination I-LV, which in turn is distinct from an IPv6 destination -- it just uses the same format.) It's counter-intuitive (and should not happen outside of that constrained scenario), but it has real world applications. ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r304436 - in head: . sys/netinet
On 20/08/16 19:09, Adrian Chadd wrote: On 20 August 2016 at 11:02, Ryan Stone wrote: On Sat, Aug 20, 2016 at 1:30 PM, Slawa Olhovchenkov wrote: For host enought have [hidden] alias with broadcsts bits. Anyway, don't should relay on the L2 information, you can recive L3 unicast addressed packets (with alien dst IP address) in L2 broadcas packet. This is still handled correctly. The new code only checks for L3 broadcast addresses on L2 broadcast packets, but we still check the L3 address before treating it as a broadcast. The problem is that I assumed that all paths into the IP stack would set M_BCAST, but as Bruce has pointed out there are cases like PPP which do not. So why not fix those paths? Because it would involve doing something similar to what if_ethersubr.c does right now: a direct comparison with FF:FF:FF:FF:FF:FF. Doing so outside of Ethernet would be invasive and one of those 'bad' layer crossings. This is tricky to get right. NetBSD introduced the M_PROMISC flag to cover situations which can occur when Ethernet can be re-entered by layers 'above' its original invocation. (I merged it here.) Ryan proposes slipping the definition of M_BCAST to include the network layer, inside ip_input() itself. That would not strictly violate layering, but bends the original meaning of the flag somewhat. That may work, provided it doesn't tread on the toes of anything above it. However the situation is somewhat similar to that of M_PROMISC. ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r304436 - in head: . sys/netinet
On 20/08/16 19:57, Ryan Stone wrote: On Sat, Aug 20, 2016 at 2:45 PM, Slawa Olhovchenkov mailto:s...@zxy.spb.ru>> wrote: You also can recive this on ethernet too, IMHO, in case of /32. Receiving L3 broadcst in L2 unicast is legitime (IMHO) and we must be relaxed on this. There is no broadcast address on a /32 network. Independent of my change, we would not treat a packet received on a /32 network as a broadcast here because in_broadcast() will return 0 for it. Hmm. That is not entirely true for /32. Even though the link layer might be Ethernet in that case, in the traditional BSD ifnet sense, while the broadcast address slot may have the same value (and actual location) as the peer end of a P2P (as in generically IFF_PPP, not just pppd(8)) interface), because it's on an Ethernet (IFF_BROADCAST) interface, the host part of the /32's value in in the broadcast address is still valid, and will probably get mapped that way if M_BCAST is set on outgoing traffic. (You are, after all, going to go through ARP on Ethernet, even for a /32, so that mapping will be triggered.) Unless I am missing something crucial here? As far as I can tell, arpresolve() unconditionally resolves L2 next-hop to the value of ifp->if_broadcastaddr. And that is always set to 'etherbroadcastaddr' by default for Ethernet ifnets: FF:FF:FF:FF:FF:FF. Would that not get past the M_BCAST check which replaced the call to in_broadcast()? ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r304436 - in head: . sys/netinet
On 20/08/16 21:05, Bruce Simpson wrote: Unless I am missing something crucial here? As far as I can tell, arpresolve() unconditionally resolves L2 next-hop to the value of ifp->if_broadcastaddr. And that is always set to 'etherbroadcastaddr' by default for Ethernet ifnets: FF:FF:FF:FF:FF:FF. Would that not get past the M_BCAST check which replaced the call to in_broadcast()? Based on my reading of the UDP-and-plumbing layer, it looks like we will only see FF:FF:FF:FF:FF:FF being used by the undirected IPv4 broadcast address, 255.255.255.255. But, in fact, this is probably a far more valid address to use for discovery services than the x.x.x.255-style IPv4 directed broadcast address, as, for Ethernet at least, it is guaranteed not to propagate beyond 1 union-of (on-link broadcast domain (layer 2, hop 1) & other ways that IPv4 subnet is bridged). So, Ryan -- your original reading of how in_broadcast() behaves is correct, modulo the all-ones bypassing it. (I believe dhclient and isc-dhcpd bypass it at BPF injection, though.) ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r304436 - in head: . sys/netinet
On 20/08/16 21:41, Slawa Olhovchenkov wrote: On Sat, Aug 20, 2016 at 09:34:06PM +0100, Bruce Simpson wrote: So, Ryan -- your original reading of how in_broadcast() behaves is correct, modulo the all-ones bypassing it. What purpose to analyse L2 header? I was just checking for possible edge cases for a substitution of the in_broadcast() check with some other way of logically summarising the real broadcast disposition of the interface in bits, given your mGRE example below. Like M_BCAST, but 'This packet is flagged as broadcast, but only by a proxy method, not L2'. Yes, curently FreeBSD don't support multiaccess media other then ethernet (i.e. ATM, FrameRelay), but in case of mGRE L2 header will be absent. Exactly! People forget that certain legitimate multipoint protocols already exist as overlays already. It is easy when all we grow up with is Ethernet. :-) Until we peek under the hood, we may not know. Slawa, you have hit the nail on the head. The situation can naturally arise anywhere we bridge L2/L3 in certain directions, be that in VPN aggregation or PPPoE aggregation. In many ways I regret never being able to have executed work on a design for ng_pppoa in 2005/6. But, given the pain people in the UK are having with BT and VDSL modem provision right now... it comes as no surprise that the next generation of DSL access, for us, can be as bad. For some, multipoint is less important now we have SR-IOV VFs and other means of allocating discrete unicast Ethernet MACs and using them as links, but... Roundabout the time I merged M_PROMISC from NetBSD to FreeBSD in 2006/7, I considered that we should add an abstraction to ifnet to permit multiple unicast (or special) MACs to be bound to existing ifnets, and -- where the card permits it, expedite that MAC in some way. That capability was present on the (legacy) Adaptec Starfire quad 100TX from that era. Today, it exists in e.g. Chelsio T4/5 TCAM filter, or multiple perfect hashes on the previous generations of cards. (Currently the FreeBSD stack does nothing about such.) I suspect it is less important now we have RSS for raw TCP throughput, but, for those of us -- e.g. in internet service provider (ISP) type environments, we have to keep a careful eye on how well FreeBSD plays nice with other Ethernet equipment, with a view to these types of potential optimizations in future. However, we still have to keep the FreeBSD-on-Ethernet ship sailing smoothly. The intent of the original input path change is clearly for performance, but perhaps slipping the M_BCAST tag in the stack is the right way forward. I would also suggest: we add ability to qualify where in the stack M_BCAST was raised (in case of any possible re-entry), by allocating one more MBUF flag to Layer 2. Then, the same M_PROMISC flag trick can be applied... and Ryan's broadcast performance boost could perhaps even carry across L2 bridging tiers, e.g. stacked if_bridge or netgraph, providing we know what direction in the stack it's traveling in (and its absolute ifnet origin). ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r304436 - in head: . sys/netinet
On 20/08/16 22:17, Bruce Simpson wrote: However, we still have to keep the FreeBSD-on-Ethernet ship sailing smoothly. The intent of the original input path change is clearly for performance, but perhaps slipping the M_BCAST tag in the stack is the right way forward. I would also suggest: we add ability to qualify where in the stack M_BCAST was raised (in case of any possible re-entry), by allocating one more MBUF flag to Layer 2. Then, the same M_PROMISC flag trick can be applied... and Ryan's broadcast performance boost could perhaps even carry across L2 bridging tiers, e.g. stacked if_bridge or netgraph, providing we know what direction in the stack it's traveling in (and its absolute ifnet origin) The main motivation for this: retain the original meaning of M_BCAST. (in addition to Ryan's intended new meaning that IP indicate to itself "This is IPv4 broadcast" and to others - it could be used to expedite delivery with some form of map). But, say, let's add a second flag which allows for controlled stacking of L2 in situations like this. Let's call it M_BCPROXY. It can be tracked for the original meaning, i.e. without the new meaning Ryan proposes for M_BCAST. When M_BCAST is set and M_BCPROXY is clear, we know the packet is broadcast, but we don't know for sure that this isn't because IP inspected it, and set the M_BCAST flag due to the destination IPv4 address being identified as such (and valid for its link, if you are enforcing the Strong IP End-Station model, RFC 1122 style, as is the BSD default). However, if we set M_BCPROXY at the same time, then, in situations where we might potentially re-enter the stack holding the same broadcast packet, we know that IP marked the packet as broadcast, and - on entry - can change our routing/switching/allocation/replication strategies accordingly. (This is not information which, on its own, holding the origin ifnet pointer provides; the flag is needed to sense direction in the stack.) So, as the mbuf chain is handed-off between other L2 entities (this can easily happen with stacked VLAN tags, in Q-in-Q and provider environments, which pfSense can service very well) - and, if the node itself determines that it is also a recipient of the broadcast, for correct hand-off if the broadcast does need to be forwarded by some other FreeBSD subsystem. It could also be checked by firewalls: e.g. for a corroborated check, from the mask of these two flags, where in the stack (or link forest) a purported broadcast packet actually originated from. (Pretty much essential for maintaining audit trail if a Smurf-like amplification attack is caught in the act, or if an NTP relay (or other association) terminates in an NTP broadcast association. And, of course, to trace dodgy broadcast Sun-style XDR RPC back to its source.) ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r304436 - in head: . sys/netinet
On 20/08/16 23:05, Slawa Olhovchenkov wrote: I am think this substitution is very bad idea (by design). Also, on transmit side this is must be irrelevant on received L2 header (and this in many cases this is will be L2 unicast packet). For other cases packet will be created on host and don't have any received information. Whilst I agree with your concerns about multipoint, I support the motivation behind Ryan's original change: optimize the common case. On the other hand, I'm suggesting a slight extension to it -- one which would probably require adoption across some L2-exposed subsystems, or anywhere which might reinterpret an M_BCAST from re-entrant encapsulation (i.e. I receive a UDP broadcast packet, but my VPN daemon then decides it needs to be NATted and forwarded somewhere else). Whilst I believe the scope for problems like this are limited (and perhaps to Netgraph permutations), I do believe they exist, and should be defensively coded for. And: If, the logic for this can be factored out into one additional bit, in a conditional branch (or small set of those) in terms of delta to the existing FreeBSD data plane path -- i.e. my suggestion; Then: we should be able to preserve correctness for multipoint configurations, without sacrificing performance. Or, a possible tie-breaker: ...we ensure that M_BCAST is cleared at all times before possible re-entry, and use a separate M_BCASTL3 bit. Let the ethernet protocols decide themselves if re-entered about M_BCAST based on DMAC. On received side for host relaing on L2 information for accepting packet as host targeting sound like security hole. In router case receiving broadcast packet in any way need additional check for dst IP address (host part is all zero or all one? what about handling this broadcast type (RFC talk about conroling variation of this)? what about sysctl control of receiving routed broadcast packets? what about handling 255.255.255.255?) I believe most of this is already special-cased in ip_fastfwd.c (which gnn@ of course has merged, as it's full of sensible FIB-like operators which most router forwarding planes adopt on *their* IP input paths up to the forwarding decision), assuming the Ethernet input path colours packets with the right flags. Although, no direct distinction between IPv4 directed or undirected broadcast is made, until that code (or a full rtalloc()) is hit. In the past, I have tried to "hack around" the issue on the output (send) side, by introducing IP_ONESBCAST from BSD/OS. The fundamental problem there is that the IPv4 socket APIs were never designed to deal with 'with link' as well as 'with destination' particularly well -- i.e. to direct traffic to a particular host, with correct L2 resolution, but over a specific choice of link (or even, class of link). So, for correct behaviour when handling packets like this, the XORP FEA and libfeaclient frameworks would attempt to fully-bind control sockets requiring broadcast input where possible (OLSR being one candidate, but there are also other protocols requiring them). In any way, this is irrelevant to L2 broadcast MAC and present L2 broadcast flags. On the contrary, I believe in teasing as much explanation about the Layer 2 Soup 'out there' and how in FreeBSD it is treated, as this lends much background to the original problem posed by Ryan's change, to those who may not be from a primarily networking-oriented background. ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r304436 - in head: . sys/netinet
On 21/08/16 00:25, Bruce Simpson wrote: [Use a predicted branch in favour of Ethernet to optimize common case comments snipped] ...we ensure that M_BCAST is cleared at all times before possible re-entry, and use a separate M_BCASTL3 bit. Let the ethernet protocols decide themselves if re-entered about M_BCAST based on DMAC. Better still, rename it to M_IPBCAST, because that is exactly what that flag would be. Treat it like M_PROMISC, hands off, use THAT test instead of M_BCAST in the code (but predictive branch the original in_broadcast() call), make sure M_BCAST is cleared before possible Netgraph handoff, but leave M_IPBCAST set. That way, anyone can tell IP set the M_BCAST bit - not Ethernet - just by XORing them together. I'd code this, but I don't have a -CURRENT box. :-( ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r304436 - in head: . sys/netinet
On 21/08/16 00:25, Bruce Simpson wrote: On 20/08/16 23:05, Slawa Olhovchenkov wrote: In router case receiving broadcast packet in any way need additional check for dst IP address (host part is all zero or all one? what about handling this broadcast type (RFC talk about conroling variation of this)? what about sysctl control of receiving routed broadcast packets? what about handling 255.255.255.255?) I believe most of this is already special-cased in ip_fastfwd.c (which gnn@ of course has merged, as it's full of sensible FIB-like operators which most router forwarding planes adopt on *their* IP input paths up to the forwarding decision), assuming the Ethernet input path colours packets with the right flags. Just for reference, many of these 'sensible FIB operators' in the former ip_fastfwd.c came from the experience of James Jun at Towardex Systems. I merged his patch on the job whilst staying in Berkeley, CA and working on XORP at ICSI. I was only too happy to do that on their ticket, as it covered a lot of little performance cases which the pure rtalloc() fallthrough made us wince about. ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r304436 - in head: . sys/netinet
On 21/08/16 00:47, Adrian Chadd wrote: [snip] Just for everyone else on the list, would you mind distilling the original versus now-from-ryan meaning of M_BCAST and M_MCAST ? And how they're supposed to be used? (With my best Liam Neeson 'Dad' voice from Fallout 3) They stay as-is, but IP is allowed to slip the tag. But it has to slip another tag in there, to say it slipped the tag. The rest is M_PROTOFLAG style hand-off hygeine, along the mbuf pipeline. ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r287780 - in head: share/man/man9 sys/kern sys/sys
Ian, To paraphrase what I said privately to the various dramatis personae in January: Changes like this need to be reviewed before they go in. As timing is central to the entire OS, change review has to be meticulous, on par with the virtual memory management. We have a VM tsar; we do not have a timing tsar. On 19/09/15 18:39, Ian Lepore wrote: I'm afraid this message can be interpetted as "reviews are now mandatory for a 'core component of the system' (whatever that means)". If so, this would be a Big Change from the last thing I heard about code reviews, which was basically: as much as some people would like it to be so, they are not mandatory. ... a definition as meaningless and vague as[.] I don't believe for one moment that George is advocating for mandatory reviews. But common sense should apply, _as timing is central to the entire OS_. It touches absolutely everything. Hell, I wouldn't feel comfortable checking anything in to e.g. timecounters without at least running it by phk first. So, +1 from me for backout until the change can be reviewed. But to be fair to all involved, perhaps Hans should set out a timeline for how he wants to proceed, subject to the jitter inherent to an all-volunteer project. thanks Bruce ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r300207 - in head: sbin/camcontrol sys/cam/ata sys/cam/scsi sys/dev/ahci sys/geom sys/geom/eli sys/kern sys/sys usr.sbin usr.sbin/diskinfo usr.sbin/zonectl
Right On Commander! Now here is hoping the random-write issues with OpenZFS are solved... ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r301496 - in head: sbin/ifconfig share/man/man4 sys/net sys/sys
It's good to see this patch being aired out and going into mainline finally. However, what about IP DS mapping and/or application layer mapping? We may not need full-on MPLS style classification, unless we plan to take that code later on. (I'm looking at you, NetBSD.) ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r301496 - in head: sbin/ifconfig share/man/man4 sys/net sys/sys
On 06/06/16 13:48, Marcelo Araujo wrote: We have on ipfw(8) support for DSCP[1], I'm not sure if this is the same/similar case you mentioned for IP DS(DiffServices?). Background: I introduced the code to process VLAN 0 tags inline as normal traffic several years ago for 802.1p. I'm referring to a mapping between IP DS bits and priority bits in the 802.1p header. We have that for 802.11 to some extent already, IIRC. Data point: OS X allows applications to request LEDBAT style congestion control (i.e. BitTorrent-style background traffic) for arbitrary TCP sockets through the priority/DS API there. About the MPLS, the main problem for me is: I have no "network link" with MPLS that I could even make a test, back in 2008 I was looking for options that I could reuse on FreeBSD to have a MPLS router support, nowadays I'm not that keen on MPLS anymore. Yes, it has downsides but there are still potential use cases for it. ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r283424 - in head/sys: amd64/linux modules/linux64
All, The enhancements to the Linux runtime are probably of more interest to folk porting server applications; I am particularly happy to see recvmmsg() and sendmmsg() go in. It might also be wise to emulate the getrandom() API, even if this is only in terms of wrapping the relevant sysctl for now. On 25/05/2015 18:27, Slawa Olhovchenkov wrote: Currenly I don't see any linux in Acrobat Reader support OS: https://get.adobe.com/reader/otherversions/ It got pulled. Of course, support for PDF's forms varies greatly outside of official Adobe product. A better alternative might be the MuPDF backend for KDE Okular, or for Zathura, neither of which are packaged anywhere in the Linux world yet. Of course, this could be built natively, without needing the Linux runtime support. I've noticed that rendering performance seems disappointing in the open source Linux PDF readers, as compared to OS X Preview.app on similar hardware. Bruce ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r284116 - head/sys/boot/ficl
On 07/06/2015 18:06, Garrett Cooper wrote: This commit's explicitly polluting the ficl interpreter with code from x86 on all platforms. +1 ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r284146 - in head/tools/bus_space: . C Python
Marcel, On Mon, 8 Jun 2015, at 04:23, Marcel Moolenaar wrote: > Log: > Add busdma_mem_alloc & busdma_mem_free. Nice! Is there a man page or documentation for this anywhere? Also: is it feasible to extend to build/attach to a VirtIO function? (May be PCI, not MMIO). cheers Bruce -- BMS (sent via webmail) ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r284146 - in head/tools/bus_space: . C Python
Marcel, (Cc: Will as he's expressed interest in this) No problem... still tied up here... On Mon, 8 Jun 2015, at 06:10, Marcel Moolenaar wrote: > > On Jun 7, 2015, at 9:52 PM, Bruce Simpson wrote: > > Nice! Is there a man page or documentation for this anywhere? > > Not yet. I want to flesh it out further before documenting. > I’m not sure the API is stable enough yet. I’m still figure > things out as I go. > > Also: is it feasible to extend to build/attach to a VirtIO function? > > (May be PCI, not MMIO). > > I think so. If there’s an easy environment for me to play > with, I can take a look. I think qemu would do right? If you load a FreeBSD VM into KVM, and turn on host-guest sharing, you'll see a VirtIO function for Plan 9's v9fs exposed on the PCI bus. This speaks a Linux-specific variant of the 9P protocol, 9P2000.L. FreeBSD currently does not understand how to talk to it, nor do our existing 9p ports. BHyve doesn't support host-guest sharing (yet). Note: I neither claim nor argue that this is the most efficient host-guest solution -- there are anecdotal reports that the claims IBM have made in published papers cannot be verified in production -- but it makes sense to re-use (and perhaps improve upon) what IBM have done here, for the sake of interop more than anything else. There is a FUSE-based implementation in Python, py9p, which might serve as the basis for a prototype. NetBSD have a newer alternative but it looks like more work to make it talk to the VirtIO function. -- BMS (sent via webmail) ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r284146 - in head/tools/bus_space: . C Python
On Mon, 8 Jun 2015, at 06:10, Marcel Moolenaar wrote: > > Also: is it feasible to extend to build/attach to a VirtIO function? > > (May be PCI, not MMIO). > > I think so. If there’s an easy environment for me to play > with, I can take a look. I think qemu would do right? I can't speak to the MMIO case, but it may be of interest for CHERI. This was added to VirtIO to support paravirtualization in emulators for non-x86 SoCs (e.g. ARM, MIPS). [See VirtIO spec white paper.] -- BMS (sent via webmail) ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r284198 - head/bin/ls
On 13/06/2015 16:38, David Chisnall wrote: On 13 Jun 2015, at 11:17, Ian Lepore wrote: If you would have told me a year ago that you had a simple scheme that could make 30 years of experience maintaining code for unix-like systems completely worthless I would have been skeptical, but it seems we're well on our way. There is a lot of heckling and unhelpful hyperbole in this thread. Agree -- teething trouble. I am trying to push something out right now based on 8.x, and all the little "gotchas" (e.g. vmstat -z not using a uniform delimiter set) are like little landmines on the highway in front of my Pursuit Special. Personally I prefer the new formats, they're less ambiguous, and closer to the analytics where they actually get used. ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r284198 - head/bin/ls
On 14/06/2015 11:00, Slawa Olhovchenkov wrote: On Sat, Jun 13, 2015 at 05:13:31PM -0700, Craig Rodrigues wrote: The people I talk to use scripting languages like Python or Ruby, and devops frameworks like Ansible, Saltstack, Puppet, and Chef. They may do some quick prototyping and UI work with Javascript and HTML/CSS. Being able to generate JSON directly from system-level tools, and then analyze that in a Python script, You need JSON from system-level tools for analyze that in a Python script? Realy? Not plain text? or tab/space separated? So, I am broadly in favour of keeping libxo -- providing the problems with its introduction are fixed. I'm not even thinking of the "DevOps" space, but the R&D space, where Python and R are king. Man pages are small beer and can be dealt with easily. Control flow and regressions from previous functionality are another issue, and I am not for a moment going to duck out and suggest those responsible for introducing it aren't also responsible for fixing these specific issues. But I have yet to see a coherent argument here -- size(1) numbers, RSS figures etc. -- about how it allegedly adds bloat. Most of what I've seen so far is POLA, NIH resistance, and hand-wavery. If anything it helps to future proof the code as it stands, and make it easier for us to actually engineer the system for performance. I tend to look upon counter-arguments against that last point as "The more we obfuscate, the harder it is to get found out that the code isn't actually that good." So, if you read my previous response to this thread, I've clearly pointed out that: there are specific problems in parsing the output of these system tools as they stand. If you don't believe this, you can have my yesterday morning/afternoon, where I was post-processing the output of 4000 individual "vmstat -z" and "vmstat -m" reports. Another 1000 this morning, with more to follow. "Oh boy," I'd say to myself, "I wish I had libxo!" This argument is not limited to base system utilities. For example: iperf 3.x has had a similar reworking of its reporting format to include JSON. This is a massive improvement over iperf 2.x, which does not even clearly document its CSV fields; you have to read the source for that. JSON actually tags each field. This reduces the time from experiment to analysed result significantly, just because I can easily see what each god damned number means. Given, you need to read the source to understand why its naive sequencing algorithm breaks in multipath networking scenarios, but one should not have to do this just to get basic throughput results tabulated. ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r284198 - head/bin/ls
On 14/06/2015 18:10, Steve Kargl wrote: On Sun, Jun 14, 2015 at 11:22:03AM +0100, Bruce Simpson wrote: But I have yet to see a coherent argument here -- size(1) numbers, RSS figures etc. -- about how it allegedly adds bloat. Most of what I've seen so far is POLA, NIH resistance, and hand-wavery. It is not alleged. I actaully measured the bloat libxo caused when w(1) was converted. ... Here's the bloat with ls(1) ... Steve, that's still less than one 4KB page. OK, so I find it difficult to believe -- in this day and age of pipeline-saving CMOV instructions -- that the overhead is as large as ~2800 bytes, where I would have expected roughly half that. But not knowing what compile options you used, or having information about sizes (and working sets - just listing file sizes is hand waving) across the libxo modified binaries, this still doesn't give a complete picture of the relative cost of the feature. However, that's still a very modest increase, considering the architectural scope of the libxo change and what it provides. Warner suggests that for some targets it is too much, and he might have a point. But if you look at That Other Operating System, this is generally dealt with there by deploying something like BusyBox instead. I can understand why we don't want to go down that road -- in my experience, the choice of BusyBox sacrifices too much usability -- and would support a WITH_LIBXO for that reason alone. The extra bytes might even disappear in the noise after crunchgen. I think it is also fair that the people who advocated for this in the beginning (not I, though I support it in principle) and did the work (not I either, ENOTIME) should have done this work up front. I've had to do it to justify similar changes in other projects. ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r284198 - head/bin/ls
On 15/06/2015 19:49, Warner Losh wrote: I’ve yet to see why ls —libxo is better than a separate program articulated anywhere other than "libxo all the things.” Having a clear statement about why it is needed, why changing it vs having a separate program, etc would help. But is seems overly gratuitous with little benefit. +1, I don't see how libxo-ized ls(1) adds value. e.g. in Python, one can use pathlib and scandir to walk arbitrarily wide and deep hierarchies, much as 'file ... | xargs foo'. It has even (with hard work by koobs) supported FreeBSD's stat.st_flags since 2.3. So anything ls(1) can do, Python could do anyway. ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r285160 - head/sys/conf
On 05/07/15 20:53, Oliver Pinter wrote: Log: Ensure all the required files get built when you include the IPSEC option. +1. IETF position these days is that IPSEC should be a "standard feature". Key management is a separate issue, and support for newer ciphers like ChaCha20 (see NaCL by Daniel Bernstein et al) and authenticated encryption schemes please. Umm.. This looks more like that IPSEC should require that the crypto device be specified instead of fixing it this way... +1. Expressing static dependencies at the granularity of "file" rather than "module" or "subsystem" is a PITA, and leads to having to depth-first enumerate the deps like this, introducing clutter. Is there any way to specify implication rules to config? Ergo if I specify IPSEC without device crypto, then it's auto enable/include. Similar to linux's Kconfig framework.. +1. I know this can be done at "module" granularity, but I have always found the "options" and "files" syntax somewhat arcane. I almost always copy-paste-edit existing stanzas. ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r296261 - in head/sys: kern sys
All, On 01/03/16 10:57, Svatopluk Kraus wrote: Author: skra Date: Tue Mar 1 10:57:29 2016 New Revision: 296261 URL: https://svnweb.freebsd.org/changeset/base/296261 Log: Mark other parts of interrupt framework as INTR_SOLO option specific. IMHO... The general rationalisation of the FreeBSD kernel-mode driver API surface probably warrants updating this document: https://www.freebsd.org/doc/en/books/arch-handbook/ Describing the general case in terms of ISA device drivers is probably confusing these days, although it reflects how the code has evolved. cheers Bruce ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r296826 - in head/sys/arm: conf mv
On 14/03/16 07:14, Wojciech Macek wrote: Log: Add support for USB3.0 on Armada38x Very cool. Do you know if any Armada (or other embedded) XHCI implementations like this support XHCI Debug Port 1.0 ? ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r253841 - head/sys/netinet6
On 01/08/13 17:55, Rui Paulo wrote: On 1 Aug 2013, at 09:27, Alexander V. Chernikov wrote: Because thay aren't really interfaces. All they need is BPF. There is a cleaner approach described here: http://lists.freebsd.org/pipermail/freebsd-net/2012-December/034031.html I don't agree with this patch as-is, but I'll need to spend some time writing an email... To be continued later. +1 with Rui here. A few comments. I would like to see a cleaner approach to the networking data plane, but this would need to be considered in some depth. One place to start might be the "informational" RFC for the Netlink socket API. Whilst the gap between BPF and ifnet is acknowledged, there is still a place for "virtual" interfaces. Lacking other management mechanisms, the ifnet (and its name) ends up being used as a convenient handle. I have code in development which tries to address more general issues of IPvX address dependency by using such an interface. ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r253590 - in head/sys: kern net sys
On 24/07/13 05:24, Marcel Moolenaar wrote: Log: Decouple the UUID generator from network interfaces by having MAC addresses added to the UUID generator using uuid_ether_add(). The UUID generator keeps an arbitrary number of MAC addresses, under the assumption that they are rarely removed (= uuid_ether_del()). This achieves the following: 1. It brings up closer to having the network stack as a loadable module. 2. It allows the UUID generator to filter MAC addresses for best results (= highest chance of uniqeness). 3. MAC addresses can come from anywhere, irrespactive of whether it's used for an interface or not. I like this change, because it's interface agnostic. The fallback behaviour in uuidgen (of choosing the first Ethernet interface) isn't desirable in many situations. Also I like the line of thinking in point 1. In some embedded and niche environments, not having any IP4/6 at all is quite desirable (kernel size, security). ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r253841 - head/sys/netinet6
On 07/08/13 13:05, Gleb Smirnoff wrote: Yes, lack of good management mechanism creates a temptation to create a foo(4) interface for any new FOO protocol, with its own if_ioctl method that will provide a clean entry into its management. I suspect that was one of the reasons to implement carp(4) as interface. My concern is that whilst the BPF change is well intentioned, we may be unravelling a loose thread; other issues loom in the FreeBSD network stack elsewhere. These might be considered artefacts of FreeBSD's fairly informal approach to network stack management. This approach has served us reasonably well for many years -- it is simple and easier to maintain than the somewhat byzantine NDIS/TDI sandwich in Microsoft Windows. This doesn't change the fact that dealing with the venerable PF_ROUTE socket is a royal pain. However we should be careful with refactoring. Changes to network stack management may affect stack elements such as net-snmp, snort, ntop, Netflow collectors, etc. A managed infrastructure might also use SNMP to track network configuration data. I foresee that this change could help in those deployment scenarios; as SNMP is platform agnostic, Netdot (and other management tools) must parse and filter out the "non-proto-bound" ifnets (*) as their statistics are not normally considered useful. In Netdot, a set of heuristics are applied based on the sysObjectID MIB variable. (*) It's entirely possible someone may want to log these things for development purposes, though. What do you mean about "virtual" interfaces? An interface must represent a sink where a route entry can point to and incoming packets can come in. With this definition a vlan(4) is a real interface, but pfsync(4), pflog(4), ipfwlog(4) are not. At the moment we have a model whereby protocol families get bound to ifnets statically (not dynamically). It's OK for ifnets to be in a state of change where they may not have protocols bound to them during early system boot. (I guess my question is: packet sockets - why not?) The specific case I am working with does satisfy this criterion, however it relies on other changes which restore the legacy BSD behaviour where loopback traffic will only appear on the BPF instance specific to the ifnet. E.g. currently FreeBSD will present all locally looped back traffic on lo0 (or the current vnet's "primary" lo(4) instance). The situation with lack of management mechs should be fixed, and BPF providers should be decoupled from ifnet, and no new not-a-true-interface ifnets should be introduced in FreeBSD. All these not-a-true-interfaces require dozens of special handling around the kernel, an example is a commit we are discussing. Agreed. carp(4) does not quite fit the model well at all. FreeBSD's implementation of it relies on ipprotosw[] and some other hooks in ether(4) leading to nested conditionals (my import of M_PROMISC from NetBSD around 2007 may have helped limit code churn here.) ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r204493 - head/lib/libc/stdlib
Hey Jason, Have you looked at ? It is used by pf and the multicast code. cheers Bruce On 02/28/10 22:57, Jason Evans wrote: Author: jasone Date: Sun Feb 28 22:57:13 2010 New Revision: 204493 URL: http://svn.freebsd.org/changeset/base/204493 Log: Rewrite red-black trees to do lazy balance fixup. This improves insert/remove speed by ~30%. ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r204870 - head/sys/modules
On 03/08/10 15:01, Nathan Whitehorn wrote: Log: Enable tmpfs unconditionally on all platforms. No one I spoke to could remember why it was x86 only, and it works just as well on at least powerpc as on x86. Thanks, What with 7.3 coming up and all, this would make for a nice MFC. :-) ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r205024 - head/sys/net
Any objections to making AF_NETLINK Foundation proposal public? Might help FreeBSD get out of the niche a bit more; energy quantum wells are never great. ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r205104 - in head/sys: dev/xen/netback netinet netinet6
On 03/13/10 13:53, Robert N. M. Watson wrote: On Mar 13, 2010, at 1:50 PM, Randall Stewart wrote: I could refactor that this way if you want... it would mean a few more de-ref's and looking to see if its a v4 or v6 packet and then doing the proper offset... This is the sort of thing which M_PROTO* flags are good for. Derefs in the hot path should be amortized whenever that makes sense. ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
