Re: svn commit: r304505 - head/release/doc/en_US.ISO8859-1/hardware

On Fri, Aug 19, 2016 at 5:13 PM, John Baldwin wrote: > Author: jhb > Date: Fri Aug 19 22:13:01 2016 > New Revision: 304505 > URL: https://svnweb.freebsd.org/changeset/base/304505 > > Log: > Remove mentions of the mcd(4), scd(4), and si(4) drivers. > Hmm, looks like ie(4)

svn commit: r304552 - head/sys/mips/mips

Author: adrian Date: Sun Aug 21 00:48:41 2016 New Revision: 304552 URL: https://svnweb.freebsd.org/changeset/base/304552 Log: [mips] add support for the "creative" GNU extensions and IRIX hilarity around MIPS LO16/HI16 relocations. This was .. an interesting headache. There are two

Re: svn commit: r304436 - in head: . sys/netinet

On Sun, Aug 21, 2016 at 12:25:46AM +0100, Bruce Simpson wrote: > 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

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

Re: svn commit: r304436 - in head: . sys/netinet

[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? thanks, -adrian ___ svn-src-head@freebsd.org mailing list

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

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: 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

svn commit: r304548 - head/sys/netinet

Author: zec Date: Sat Aug 20 22:12:26 2016 New Revision: 304548 URL: https://svnweb.freebsd.org/changeset/base/304548 Log: Permit disabling net.inet.udp.require_l2_bcast in VIMAGE kernels. The default value of the tunable introduced in r304436 couldn't be effectively overrided on VIMAGE

Re: svn commit: r304436 - in head: . sys/netinet

On Sat, Aug 20, 2016 at 10:17:27PM +0100, Bruce Simpson wrote: > 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.

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

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

svn commit: r304545 - head/sys/netinet6

Author: karels Date: Sat Aug 20 20:46:53 2016 New Revision: 304545 URL: https://svnweb.freebsd.org/changeset/base/304545 Log: Disable L2 caching for UDP over IPv6 The ip6_output routine is missing L2 cache invalication as done in ip_output. Even with that code, some problems with UDP

Re: svn commit: r304436 - in head: . sys/netinet

On Sat, Aug 20, 2016 at 09:34:06PM +0100, Bruce Simpson wrote: > 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

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.

svn commit: r304544 - in head/sys: kern security/audit

Author: rwatson Date: Sat Aug 20 20:28:08 2016 New Revision: 304544 URL: https://svnweb.freebsd.org/changeset/base/304544 Log: Audit the accepted (or rejected) username argument to setlogin(2). (NB: This was likely a mismerge from XNU in audit support, where the text argument to

svn commit: r304543 - head/sys/netinet

Author: tuexen Date: Sat Aug 20 20:15:36 2016 New Revision: 304543 URL: https://svnweb.freebsd.org/changeset/base/304543 Log: Unbreak sctp_connectx(). MFC after: 3 days Modified: head/sys/netinet/sctputil.c Modified: head/sys/netinet/sctputil.c

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 > 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

Re: svn commit: r304513 - in head: . share/man/man4/man4.i386 sys/conf sys/dev/ie sys/i386/conf sys/modules sys/modules/ie sys/pc98/conf

In message <20160820152406.ga8...@lonesome.com>, Mark Linimon writes: > On Sat, Aug 20, 2016 at 07:51:55AM -0700, John Baldwin wrote: > > - aha (ISA) > > - bt (ISA / EISA / PCI) > > If anyone complains, tell them I'll ship them cards. > > If they consider that a threat ... so be it :-) > >

Re: svn commit: r304513 - in head: . share/man/man4/man4.i386 sys/conf sys/dev/ie sys/i386/conf sys/modules sys/modules/ie sys/pc98/conf

In message <1699917.hhfokya...@ralph.baldwin.cx>, John Baldwin writes: > On Saturday, August 20, 2016 12:49:30 AM John Baldwin wrote: > > Author: jhb > > Date: Sat Aug 20 00:49:29 2016 > > New Revision: 304513 > > URL: https://svnweb.freebsd.org/changeset/base/304513 > > > > Log: > > Remove the

Re: svn commit: r304436 - in head: . sys/netinet

On Sat, Aug 20, 2016 at 02:57:36PM -0400, Ryan Stone wrote: > On Sat, Aug 20, 2016 at 2:45 PM, Slawa Olhovchenkov 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

Re: svn commit: r304436 - in head: . sys/netinet

On Sat, Aug 20, 2016 at 2:45 PM, Slawa Olhovchenkov 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

svn commit: r304537 - head/sys/kern

Author: rwatson Date: Sat Aug 20 18:51:48 2016 New Revision: 304537 URL: https://svnweb.freebsd.org/changeset/base/304537 Log: Audit additional vnode information in the implementation of the ftruncate(2) system call. This was not required by the Common Criteria, which needed only open-time

Re: svn commit: r304436 - in head: . sys/netinet

On Sat, Aug 20, 2016 at 02:02:16PM -0400, 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

Re: svn commit: r304506 - in head: . release/doc/en_US.ISO8859-1/hardware share/man/man4/man4.i386 sys/conf sys/dev/wl sys/i386/conf sys/modules sys/modules/wl targets/pseudo/userland tools/build/mk t

On Sat, Aug 20, 2016 at 12:14 PM, Adrian Chadd wrote: > [snip] > > I ... may do some kind of anniversary related work to fix up wi support again. > > Because - and this is pretty god damned hilarious - the same stack > features (no raw frames, 802.3 encapsulation,

Re: svn commit: r304436 - in head: . sys/netinet

On Sat, Aug 20, 2016 at 2:09 PM, Adrian Chadd wrote: > Hi, > > So why not fix those paths? > > > > -adrian > Is there even a fix that can be done there? I wouldn't expect a point-to-point protocol like PPP to have any need to explicitly signal that a packet is a broadcast.

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

Re: svn commit: r304506 - in head: . release/doc/en_US.ISO8859-1/hardware share/man/man4/man4.i386 sys/conf sys/dev/wl sys/i386/conf sys/modules sys/modules/wl targets/pseudo/userland tools/build/mk t

[snip] I ... may do some kind of anniversary related work to fix up wi support again. Because - and this is pretty god damned hilarious - the same stack features (no raw frames, 802.3 encapsulation, scan/join/etc done via commands only, etc) that I need to 'fix' for wi are also required for

Re: svn commit: r304436 - in head: . sys/netinet

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

Re: svn commit: r304436 - in head: . sys/netinet

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

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

Re: svn commit: r304436 - in head: . sys/netinet

On Sat, Aug 20, 2016 at 12:36:58PM -0400, 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

Re: svn commit: r304244 - head/sys/kern

On 8/16/2016 2:55 PM, Gleb Smirnoff wrote: > Author: glebius > Date: Tue Aug 16 21:55:34 2016 > New Revision: 304244 > URL: https://svnweb.freebsd.org/changeset/base/304244 > > Log: > We should not be allowing a timeout to reset when a drain is in progress on > it (either async or sync

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

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.

Re: svn commit: r304436 - in head: . sys/netinet

+ 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

svn commit: r304535 - in head: contrib/dma libexec/dma

Author: bapt Date: Sat Aug 20 16:36:05 2016 New Revision: 304535 URL: https://svnweb.freebsd.org/changeset/base/304535 Log: Import Dragonfly Mail Agent snapshort from 20160806 aka v0.11+ Most important change being: dma - Fix security hole (#46) Affecting DragonFly 4.6 and earlier,

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

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

Re: svn commit: r304513 - in head: . share/man/man4/man4.i386 sys/conf sys/dev/ie sys/i386/conf sys/modules sys/modules/ie sys/pc98/conf

On Sat, Aug 20, 2016 at 8:51 AM, John Baldwin wrote: > On Saturday, August 20, 2016 12:49:30 AM John Baldwin wrote: >> Author: jhb >> Date: Sat Aug 20 00:49:29 2016 >> New Revision: 304513 >> URL: https://svnweb.freebsd.org/changeset/base/304513 >> >> Log: >> Remove the ie(4)

svn commit: r304532 - in head/sys/boot: common efi/loader/arch/amd64 fdt

Author: tsoome Date: Sat Aug 20 16:23:19 2016 New Revision: 304532 URL: https://svnweb.freebsd.org/changeset/base/304532 Log: loader is filling fixed length command_errbuf with sprintf() and is trusting strings provided by user/config files. This update is replacing sprintf with snprintf

Re: svn commit: r304506 - in head: . release/doc/en_US.ISO8859-1/hardware share/man/man4/man4.i386 sys/conf sys/dev/wl sys/i386/conf sys/modules sys/modules/wl targets/pseudo/userland tools/build/mk t

On Sat, Aug 20, 2016 at 8:33 AM, John Baldwin wrote: > On Friday, August 19, 2016 06:38:01 PM Warner Losh wrote: >> On Fri, Aug 19, 2016 at 4:27 PM, John Baldwin wrote: >> > Author: jhb >> > Date: Fri Aug 19 22:27:14 2016 >> > New Revision: 304506 >> > URL:

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

Re: svn commit: r304436 - in head: . sys/netinet

On Sat, Aug 20, 2016 at 11:01 AM, Bruce Simpson wrote: > tun(4) on the other hand is a plain, PPP-like, IP tunnel. > Can you send a broadcast packet through an L3 tunnel? I thought that a L2 tunnel was required. But this mbuf flag is not guaranteed to be set in all

Re: svn commit: r304513 - in head: . share/man/man4/man4.i386 sys/conf sys/dev/ie sys/i386/conf sys/modules sys/modules/ie sys/pc98/conf

On Sat, Aug 20, 2016 at 07:51:55AM -0700, John Baldwin wrote: > - aha (ISA) > - bt (ISA / EISA / PCI) If anyone complains, tell them I'll ship them cards. If they consider that a threat ... so be it :-) (I *am* in the middle of a big decluttering, you know. I can find them ...) mcl

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

Re: svn commit: r304435 - head/sys/netinet

On Sat, Aug 20, 2016 at 6:08 AM, Kubilay Kocak wrote: > Hi Ryan, > > Could you elaborate on any of the potential performance implications of > this? > As if r304437, skipping the call to in_broadcast() means that we avoid an additional (potentially heavily contended) rlock

Re: svn commit: r304506 - in head: . release/doc/en_US.ISO8859-1/hardware share/man/man4/man4.i386 sys/conf sys/dev/wl sys/i386/conf sys/modules sys/modules/wl targets/pseudo/userland tools/build/mk t

On Friday, August 19, 2016 06:38:01 PM Warner Losh wrote: > On Fri, Aug 19, 2016 at 4:27 PM, John Baldwin wrote: > > Author: jhb > > Date: Fri Aug 19 22:27:14 2016 > > New Revision: 304506 > > URL: https://svnweb.freebsd.org/changeset/base/304506 > > > > Log: > > Remove the

Re: svn commit: r304436 - in head: . sys/netinet

On Sat, Aug 20, 2016 at 7:48 AM, Bruce Simpson 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 >

Re: svn commit: r304513 - in head: . share/man/man4/man4.i386 sys/conf sys/dev/ie sys/i386/conf sys/modules sys/modules/ie sys/pc98/conf

On Saturday, August 20, 2016 12:49:30 AM John Baldwin wrote: > Author: jhb > Date: Sat Aug 20 00:49:29 2016 > New Revision: 304513 > URL: https://svnweb.freebsd.org/changeset/base/304513 > > Log: > Remove the ie(4) driver for Intel 82586 ISA Ethernet adapters. > > This driver only supports

svn commit: r304530 - in head: contrib/llvm/lib/Target/ARM/MCTargetDesc lib/clang

Author: dim Date: Sat Aug 20 14:04:51 2016 New Revision: 304530 URL: https://svnweb.freebsd.org/changeset/base/304530 Log: Pull in r265122 from upstream llvm trunk (by James Molloy): Fix for pr24346: arm asm label calculation error in sub Some ARM instructions encode 32-bit

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

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

Re: svn commit: r304435 - head/sys/netinet

On 19/08/2016 8:59 AM, Ryan Stone wrote: > Author: rstone > Date: Thu Aug 18 22:59:00 2016 > New Revision: 304435 > URL: https://svnweb.freebsd.org/changeset/base/304435 > > Log: > Don't iterate over the ifnet addr list in ip_output() > > For almost every packet that is transmitted through

svn commit: r304521 - head/sys/dev/ahci

Author: avg Date: Sat Aug 20 09:13:14 2016 New Revision: 304521 URL: https://svnweb.freebsd.org/changeset/base/304521 Log: JMicron JMB361 has only a single SATA port Discussed with: mav MFC after:3 days Modified: head/sys/dev/ahci/ahci_pci.c Modified:

svn commit: r304520 - head/cddl/contrib/opensolaris/lib/libzfs/common

Author: avg Date: Sat Aug 20 09:12:01 2016 New Revision: 304520 URL: https://svnweb.freebsd.org/changeset/base/304520 Log: fix bug introduced in r297521, set canmount=on doesn't mount filesystem There are two cases where changing canmount should result in an action: - canmount is set to