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) also needs removal (in
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 ha
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 un
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
[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
https://lists.freebs
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
thi
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-ente
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
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 k
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.
>
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
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 ca
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 ove
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
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.
Wou
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 setlogin(
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
==
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
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 :-)
>
> (
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
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 on this.
> >
>
> T
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 of my change,
we
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
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 packets (with ali
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, scan/join/etc done via
> commands
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. Is the information e
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 packe
[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
almos
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
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 co
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 se
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 w
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 drain).
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 t
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. U
+ 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
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, M
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
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,
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) driver for Intel 82
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 for
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: https://svnweb.freebsd.org/changeset/ba
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 Protoc
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 situations; e.g.
> where the
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
___
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 obse
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 acquire and release on
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 wl(4) driver and wlco
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
> situation may be rea
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
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 immedia
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
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
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
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: head/sys/dev/ahci/ahci_
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 o
56 matches
Mail list logo
