Re: OpenBSD OpenCL 2.x support perspective
On Tue, Dec 12, 2017 at 10:18:51AM +0300, Denis wrote: > Interesting in perspectives about OpenCL 2.x support in OpenBSD natively. > > Especially interesting in what does Theo think about it. > > Thanks I am not Theo, But as a former heavy OpenCL developer, my advice is to just use Windows (or if you are forced to Linux) for any OpenCL development. Besides the kernel support, all the tools are there. Paul
syspatch / reorder_kernel
Quick thought (I don't have time to look further now but I just noticed this and wanted to get it down before I forget). I just upgraded an Alix to 6.2 release and then wanted to run syspatch afterwards. I logged in just after ssh had started, so reorder_kernel was still running in the background - it didn't finish until uptime=8 mins. It's not going to be a problem for systems with faster storage, but there are likely still plenty of machines like this around just plodding along. Thinking about users who may not realise about the background reorder_kernel, is this enough of a problem to be worth adding some kind of interlock to prevent syspatch from running before reorder_kernel finished?
remove one bug, add three
Hi, While attempting to fix one bug, the recent commit to sed regarding the `y' command has introduced three new problems. The first one is that it happily uses a plain `char' as the index for the array `check', which obviously leads to havoc as soon as one tries to translate non-ASCII characters, whereby sed, overwriting its own memory, either fails with bogus error messages $ ./sed $(printf 'y/\220/a/') sed: 1: "y/\x90/a/": Repeated character in source string $ ./sed $(printf 'y/\360/a/') sed: 1: "y/\xf0/a/": unexpected EOF (pending }'s) or merely dumps core. $ ./sed $(printf 'y/\222/a/') Segmentation fault (core dumped) The second bug is that, even if one were to cast the said index to an unsigned value, the `check' array would still be off by one, as it is declared to have a length of 255 instead of 256, once again causing trivial one-byte buffer overflows. The third bug is more of a behavioural one: while the `y' command was previously slightly diverging from its description by POSIX, at least both `s' and `y' were compiled in the same way, such that the two similar commands `yn\nnXn' and `sn\nnXn' were handled consistently, as one would expect. With this commit, however, these two commands now have exactly the opposite behaviour, thus making the poor sed even more incoherent than it ever was. As an aside, in case the irony is not overwhelming enough already, I would also like to point out how the first submitted diff addressing this issue decided to change the comment /* We assume characters are 8 bits */ into // We assume characters are 8 bits after which it was objected that this modification was not justified and hence should not be part of the final patch. However, at no point did someone realize that the code is in fact not assuming anything regarding the number of bits in a character, and hence that this comment, wether written in one style or the other, is actually quite ridiculous anyway. Perhaps the worst part of all this, though, is how the change of behaviour, which made sed fail hard where it previously handled input in a perfectly defined and reasonable way, was apparently approved because "implementations do vary in how they handle [it], so throwing an error is probably best". Following the same kind of reasoning, I think OpenBSD should also modify the `echo' command to fail if given an argument like `-E', as its behaviour in that case differs from system to system, hence the current implementation is likewise "just creating a trap for the user", and surely this is unacceptable and therefore ought to be fixed, right? Having thus shown that this commit was not only misguided technically but also conceptually, rather than applying yet another misguided patch on top of it in an attempt to repair this whole mess, I would like to request that it instead be completely reverted, after which I would be able to provide a proper and definitive fix to deal with this issue (and, at the same time, many other unrelated bugs). Regards, kshe
Re: syspatch / reorder_kernel
On Tue, Dec 12, 2017 at 11:56:20AM +, Stuart Henderson wrote: > Quick thought (I don't have time to look further now but I just noticed > this and wanted to get it down before I forget). > > I just upgraded an Alix to 6.2 release and then wanted to run syspatch > afterwards. I logged in just after ssh had started, so reorder_kernel was > still running in the background - it didn't finish until uptime=8 mins. > > It's not going to be a problem for systems with faster storage, but there are > likely still plenty of machines like this around just plodding along. Thinking > about users who may not realise about the background reorder_kernel, is this > enough of a problem to be worth adding some kind of interlock to prevent > syspatch from running before reorder_kernel finished? I suppose I could add such a check if we want it. -- Antoine
Re: remove one bug, add three
On Tue, 12 Dec 2017 11:57:58 +, kshe wrote: > Perhaps the worst part of all this, though, is how the change of > behaviour, which made sed fail hard where it previously handled input in > a perfectly defined and reasonable way, was apparently approved because > "implementations do vary in how they handle [it], so throwing an error > is probably best". Following the same kind of reasoning, I think > OpenBSD should also modify the `echo' command to fail if given an > argument like `-E', as its behaviour in that case differs from system to > system, hence the current implementation is likewise "just creating a > trap for the user", and surely this is unacceptable and therefore ought > to be fixed, right? It's not really the same situation. The question is what to do in cases where POSIX leaves the behavior undefined and where there is no consensus among implementations. Is it best for sed to be as consistent as possible, knowing that other commonly used implementations will produce different results, or is it better to produce an error for the unwary user? This is not just theoretical, we run into issues all the time with scripts that "work fine" on Linux but fail in odd ways on other systems that don't use the GNU utilities. Most users will have no way to determine the source of the problem. At least if the undefined behavior results in an error they have something to go on. - todd
Re: remove one bug, add three
On Tue, 12 Dec 2017 12:44:03 +, Todd C. Miller wrote: > On Tue, 12 Dec 2017 11:57:58 +, kshe wrote: > > > Perhaps the worst part of all this, though, is how the change of > > behaviour, which made sed fail hard where it previously handled input in > > a perfectly defined and reasonable way, was apparently approved because > > "implementations do vary in how they handle [it], so throwing an error > > is probably best". Following the same kind of reasoning, I think > > OpenBSD should also modify the `echo' command to fail if given an > > argument like `-E', as its behaviour in that case differs from system to > > system, hence the current implementation is likewise "just creating a > > trap for the user", and surely this is unacceptable and therefore ought > > to be fixed, right? > > It's not really the same situation. The question is what to do in > cases where POSIX leaves the behavior undefined and where there is > no consensus among implementations. Is it best for sed to be as > consistent as possible, knowing that other commonly used implementations > will produce different results, or is it better to produce an error > for the unwary user? This is not just theoretical, we run into > issues all the time with scripts that "work fine" on Linux but fail > in odd ways on other systems that don't use the GNU utilities. > > Most users will have no way to determine the source of the problem. > At least if the undefined behavior results in an error they have > something to go on. Trying to prevent the unwary user from being unwary is a noble but impossible task to accomplish. There are so many ways to introduce non-portability in shell scripts that replacing historical behaviour by hard failures in an attempt to improve this situation is likely to be counterproductive, especially when such attempt goes against the internal consistency of the affected commands. Regards, kshe
net80211: set 'any channel' pointer to NULL
If we're going to crash in the wireless stack because of a bogus channel pointer, let that pointer be a NULL pointer to avoid head-scratching every time someone runs into this. Index: ieee80211_var.h === RCS file: /cvs/src/sys/net80211/ieee80211_var.h,v retrieving revision 1.82 diff -u -p -r1.82 ieee80211_var.h --- ieee80211_var.h 8 Dec 2017 21:16:01 - 1.82 +++ ieee80211_var.h 12 Dec 2017 14:14:26 - @@ -52,7 +52,7 @@ #defineIEEE80211_CHAN_MAX 255 #defineIEEE80211_CHAN_ANY 0x /* token for ``any channel'' */ #defineIEEE80211_CHAN_ANYC \ - ((struct ieee80211_channel *) IEEE80211_CHAN_ANY) + ((struct ieee80211_channel *) NULL) #defineIEEE80211_TXPOWER_MAX 100 /* max power */ #defineIEEE80211_TXPOWER_MIN -50 /* kill radio (if possible) */
Re: iked, don't return NULL in print_host
On Wed, Nov 29, 2017 at 07:50:21PM +0100, Claudio Jeker wrote:
> More or less. It seems that msg_local is garbage:
> $3 = {msg_data = 0x1b4e541fa4c0, msg_offset = 0, msg_local = {
> ss_len = 128 '\200', ss_family = 192 'À',
> __ss_pad1 = 0x7f7da8c2 "Ì]\001", __ss_pad2 = 30024042514159,
> __ss_pad3 = 0x7f7da8d0 "Ьýÿ\177\177"}, msg_locallen = 128,
> msg_peer = {ss_len = 16 '\020', ss_family = 2 '\002',
> __ss_pad1 = 0x7f7da9ca "\001ô>0\036\005", __ss_pad2 = 0,
> __ss_pad3 = 0x7f7da9d8 ""}, msg_peerlen = 16,
>
> Why so I don't know.
I found it. socket_getaddr is called to retrieve information about the
socket behind the file descriptor. If I understand correctly, we need
to pass the length of the struct to getsockname() so that it knows how
far it can fill the struct. So far we always passed stack garbage, so
sometimes it worked, sometimes not. Then getsockname() does not change
the struct, so sockaddr_storage ss is still stack garbarge, and that
ends up in msg_local.
I think recvfromto() suffers the same. The caller ikev2_msg_cb() does
pass the correct size to recvfromto(), but then recvfromto() uncondi-
tionally overwrites it with zero before calling getsockname().
Opinions?
Patrick
diff --git a/sbin/iked/iked.h b/sbin/iked/iked.h
index 9deca37f2d0..a2e4a16fd89 100644
--- a/sbin/iked/iked.h
+++ b/sbin/iked/iked.h
@@ -939,7 +939,7 @@ int socket_af(struct sockaddr *, in_port_t);
in_port_t
socket_getport(struct sockaddr *);
int socket_setport(struct sockaddr *, in_port_t);
-int socket_getaddr(int, struct sockaddr_storage *);
+int socket_getaddr(int, struct sockaddr_storage *, socklen_t);
int socket_bypass(int, struct sockaddr *);
int udp_bind(struct sockaddr *, in_port_t);
ssize_t sendtofrom(int, void *, size_t, int, struct sockaddr *,
diff --git a/sbin/iked/ikev2.c b/sbin/iked/ikev2.c
index 411c6751c37..fcace627136 100644
--- a/sbin/iked/ikev2.c
+++ b/sbin/iked/ikev2.c
@@ -944,7 +944,7 @@ ikev2_init_ike_sa_peer(struct iked *env, struct iked_policy
*pol,
goto closeonly;
if (pol->pol_local.addr.ss_family == AF_UNSPEC) {
- if (socket_getaddr(sock->sock_fd, &ss) == -1)
+ if (socket_getaddr(sock->sock_fd, &ss, sizeof(ss)) == -1)
goto closeonly;
} else
memcpy(&ss, &pol->pol_local.addr, pol->pol_local.addr.ss_len);
diff --git a/sbin/iked/util.c b/sbin/iked/util.c
index 1d4cee2c424..babbce8ac9e 100644
--- a/sbin/iked/util.c
+++ b/sbin/iked/util.c
@@ -91,10 +91,8 @@ socket_setport(struct sockaddr *sa, in_port_t port)
}
int
-socket_getaddr(int s, struct sockaddr_storage *ss)
+socket_getaddr(int s, struct sockaddr_storage *ss, socklen_t sslen)
{
- socklen_t sslen;
-
return (getsockname(s, (struct sockaddr *)ss, &sslen));
}
@@ -366,7 +364,6 @@ recvfromto(int s, void *buf, size_t len, int flags, struct
sockaddr *from,
return (-1);
*fromlen = from->sa_len;
- *tolen = 0;
if (getsockname(s, to, tolen) != 0)
*tolen = 0;
Re: iked, don't return NULL in print_host
On Tue, Dec 12, 2017 at 03:32:50PM +0100, Patrick Wildt wrote:
> On Wed, Nov 29, 2017 at 07:50:21PM +0100, Claudio Jeker wrote:
> > More or less. It seems that msg_local is garbage:
> > $3 = {msg_data = 0x1b4e541fa4c0, msg_offset = 0, msg_local = {
> > ss_len = 128 '\200', ss_family = 192 'À',
> > __ss_pad1 = 0x7f7da8c2 "Ì]\001", __ss_pad2 = 30024042514159,
> > __ss_pad3 = 0x7f7da8d0 "Ьýÿ\177\177"}, msg_locallen = 128,
> > msg_peer = {ss_len = 16 '\020', ss_family = 2 '\002',
> > __ss_pad1 = 0x7f7da9ca "\001ô>0\036\005", __ss_pad2 = 0,
> > __ss_pad3 = 0x7f7da9d8 ""}, msg_peerlen = 16,
> >
> > Why so I don't know.
>
> I found it. socket_getaddr is called to retrieve information about the
> socket behind the file descriptor. If I understand correctly, we need
> to pass the length of the struct to getsockname() so that it knows how
> far it can fill the struct. So far we always passed stack garbage, so
> sometimes it worked, sometimes not. Then getsockname() does not change
> the struct, so sockaddr_storage ss is still stack garbarge, and that
> ends up in msg_local.
>
> I think recvfromto() suffers the same. The caller ikev2_msg_cb() does
> pass the correct size to recvfromto(), but then recvfromto() uncondi-
> tionally overwrites it with zero before calling getsockname().
>
> Opinions?
>
> Patrick
Markus points out that socket_getaddr() is promised a pointer to a
sockaddr_storage, so we don't need to pass the length and can just
initialize sslen correctly.
diff --git a/sbin/iked/util.c b/sbin/iked/util.c
index 1d4cee2c424..e67dae27d8a 100644
--- a/sbin/iked/util.c
+++ b/sbin/iked/util.c
@@ -93,7 +93,7 @@ socket_setport(struct sockaddr *sa, in_port_t port)
int
socket_getaddr(int s, struct sockaddr_storage *ss)
{
- socklen_t sslen;
+ socklen_t sslen = sizeof(*ss);
return (getsockname(s, (struct sockaddr *)ss, &sslen));
}
@@ -366,7 +366,6 @@ recvfromto(int s, void *buf, size_t len, int flags, struct
sockaddr *from,
return (-1);
*fromlen = from->sa_len;
- *tolen = 0;
if (getsockname(s, to, tolen) != 0)
*tolen = 0;
net80211: only trigger bgscan in RUN state
The checkrssi crash on bugs@ exposed another issue:
We should only try to trigger a background scan while in RUN state.
The != SCAN condition was inherited from old code. It seems what
was really intended was > SCAN because it makes no sense to
update RSSI information in INIT state.
Index: ieee80211_input.c
===
RCS file: /cvs/src/sys/net80211/ieee80211_input.c,v
retrieving revision 1.197
diff -u -p -r1.197 ieee80211_input.c
--- ieee80211_input.c 8 Dec 2017 21:16:01 - 1.197
+++ ieee80211_input.c 12 Dec 2017 15:06:55 -
@@ -263,18 +263,20 @@ ieee80211_input(struct ifnet *ifp, struc
}
*orxseq = nrxseq;
}
- if (ic->ic_state != IEEE80211_S_SCAN) {
+ if (ic->ic_state > IEEE80211_S_SCAN) {
ni->ni_rssi = rxi->rxi_rssi;
ni->ni_rstamp = rxi->rxi_tstamp;
ni->ni_inact = 0;
- /* Cancel or start background scan based on RSSI. */
- if ((*ic->ic_node_checkrssi)(ic, ni))
- timeout_del(&ic->ic_bgscan_timeout);
- else if (!timeout_pending(&ic->ic_bgscan_timeout) &&
- (ic->ic_flags & IEEE80211_F_BGSCAN) == 0)
- timeout_add_msec(&ic->ic_bgscan_timeout,
- 500 * (ic->ic_bgscan_fail + 1));
+ if (ic->ic_state == IEEE80211_S_RUN) {
+ /* Cancel or start background scan based on RSSI. */
+ if ((*ic->ic_node_checkrssi)(ic, ni))
+ timeout_del(&ic->ic_bgscan_timeout);
+ else if (!timeout_pending(&ic->ic_bgscan_timeout) &&
+ (ic->ic_flags & IEEE80211_F_BGSCAN) == 0)
+ timeout_add_msec(&ic->ic_bgscan_timeout,
+ 500 * (ic->ic_bgscan_fail + 1));
+ }
}
#ifndef IEEE80211_STA_ONLY
net80211: panic if node's channel pointer is bogus
A node's channel pointer had better be pointing to a valid channel or ANYC.
Otherwise something has gone seriously wrong and there is no good
reason to continue running the program.
Index: ieee80211.c
===
RCS file: /cvs/src/sys/net80211/ieee80211.c,v
retrieving revision 1.64
diff -u -p -r1.64 ieee80211.c
--- ieee80211.c 8 Dec 2017 21:16:01 - 1.64
+++ ieee80211.c 12 Dec 2017 14:51:44 -
@@ -238,14 +238,8 @@ ieee80211_chan2ieee(struct ieee80211com
return c - ic->ic_channels;
else if (c == IEEE80211_CHAN_ANYC)
return IEEE80211_CHAN_ANY;
- else if (c != NULL) {
- printf("%s: invalid channel freq %u flags %x\n",
- ifp->if_xname, c->ic_freq, c->ic_flags);
- return 0; /* XXX */
- } else {
- printf("%s: invalid channel (NULL)\n", ifp->if_xname);
- return 0; /* XXX */
- }
+
+ panic("%s: bogus channel pointer\n", ifp->if_xname);
}
/*
Re: remove one bug, add three
> Following the same kind of reasoning, I think OpenBSD should also > modify the `echo' command to fail if given an argument like `-E', as > its behaviour in that case differs from system to system, hence the > current implementation is likewise "just creating a trap for the > user", and surely this is unacceptable and therefore ought to be > fixed, right? Following the same kind of reasoning, you should now stand on your head and do a foot dance. Such non-sequiturs related to other commands don't help the argument. sed is sed. Let's make sed awesome.
Re: remove one bug, add three
On 12/12/17 15:02, kshe wrote:
> On Tue, 12 Dec 2017 12:44:03 +, Todd C. Miller wrote:
>> On Tue, 12 Dec 2017 11:57:58 +, kshe wrote:
>>
>>> Perhaps the worst part of all this, though, is how the change of
>>> behaviour, which made sed fail hard where it previously handled input in
>>> a perfectly defined and reasonable way, was apparently approved because
>>> "implementations do vary in how they handle [it], so throwing an error
>>> is probably best". Following the same kind of reasoning, I think
>>> OpenBSD should also modify the `echo' command to fail if given an
>>> argument like `-E', as its behaviour in that case differs from system to
>>> system, hence the current implementation is likewise "just creating a
>>> trap for the user", and surely this is unacceptable and therefore ought
>>> to be fixed, right?
>>
>> It's not really the same situation. The question is what to do in
>> cases where POSIX leaves the behavior undefined and where there is
>> no consensus among implementations. Is it best for sed to be as
>> consistent as possible, knowing that other commonly used implementations
>> will produce different results, or is it better to produce an error
>> for the unwary user? This is not just theoretical, we run into
>> issues all the time with scripts that "work fine" on Linux but fail
>> in odd ways on other systems that don't use the GNU utilities.
>>
>> Most users will have no way to determine the source of the problem.
>> At least if the undefined behavior results in an error they have
>> something to go on.
>
> Trying to prevent the unwary user from being unwary is a noble but
> impossible task to accomplish. There are so many ways to introduce
> non-portability in shell scripts that replacing historical behaviour by
> hard failures in an attempt to improve this situation is likely to be
> counterproductive, especially when such attempt goes against the
> internal consistency of the affected commands.
>
> Regards,
>
> kshe
>
Funny that you use echo as an example here[0]:
The echo utility has not been made obsolescent because of its extremely
widespread use in historical applications.
and
New applications are encouraged to use printf instead of echo.
and
It is not possible to use echo portably across all POSIX systems unless
both -n (as the first argument) and escape sequences are omitted.
So even POSIX says that this tool should be avoided and only there for
backwards compatibility.
As for the discrepancy between \n between the y and s command, this is
how POSIX actually specifies things[1].
s: Within the BRE and the replacement, the BRE delimiter itself can be
used as a literal character if it is preceded by a .
s: The meaning of an unescaped immediately followed by any
character other than '&', , a digit, , or the
delimiter character used for this command, is unspecified.
y: If a followed by an 'n' appear in string1 or string2, the
two characters shall be handled as a single .
As for the "a perfectly defined and reasonable way": It's undefined
behaviour according to POSIX and our manual never mentioned anything
about this behaviour if the backslash is used anywhere else, so it's
not defined.
Also the reasonable way is debatable because it's behaviour
actually changes on the BRE side if you use n as a separator and gsed
has an identical quirk on the replacement side:
$ printf '\n\n' | sed 'N;s/\n/a/'
a
$ printf '\n\n' | gsed 'N;s/\n/a/'
a
$ printf '\n\n' | sed 'N;sn\nnan'
$ printf '\n\n' | gsed 'N;sn\nnan'
a
$ printf 'a\n' | sed 's/a/\n/'
n
$ printf 'a\n' | gsed 's/a/\n/'
$ printf 'a\n' | sed 'snan\nn'
n
$ printf 'a\n' | gsed 'snan\nn'
n
Maybe we should pull the s command also a little closer to what POSIX
states (see defined behaviour above) and do something similar as y.
Do note that:
$ printf '\n\n' | ./sed 'N;s/\n/a/'
$ printf 'n\n' | ./sed 's/\n/a/'
a
Because the \n becomes part of the regex, which *does* define it in
re_format(7):
\c Any backslash-escaped character c, except for ‘{’, ‘}’, ‘(’, and
‘)’, matches itself.
Patch to do so below. Not asking for OKs (yet), since compile_re is used
in more places and whipped up in about a minute.
martijn@
[0] http://pubs.opengroup.org/onlinepubs/009695399/utilities/echo.html
[1] http://pubs.opengroup.org/onlinepubs/9699919799/utilities/sed.html
Index: compile.c
===
RCS file: /cvs/src/usr.bin/sed/compile.c,v
retrieving revision 1.44
diff -u -r1.44 compile.c
--- compile.c 11 Dec 2017 13:25:57 - 1.44
+++ compile.c 12 Dec 2017 15:42:55 -
@@ -58,7 +58,6 @@
} *labels[LHSZ];
static char *compile_addr(char *, struct s_addr *);
-static char *compile_ccl(char **, char *);
static char *compile_delimited(char *, char *);
static char *compile_flags(char *, struct s_subst *);
static char *compile_re(char *, regex_t **);
@@ -353,31 +352,17 @@
static char *
compile_delimited(char *p, char *d)
Re: OpenBSD OpenCL 2.x support perspective
Thanks Paul for you answer. Still no answer about OpenCL kernel integration and tools for Linux but not OpenBSD. Could you advise how to use the same computation power as for Linux in OpenBSD using OpenCL. Thanks. On 12/12/2017 11:39 AM, Paul Irofti wrote: > On Tue, Dec 12, 2017 at 10:18:51AM +0300, Denis wrote: >> Interesting in perspectives about OpenCL 2.x support in OpenBSD natively. >> >> Especially interesting in what does Theo think about it. >> >> Thanks > I am not Theo, > > But as a former heavy OpenCL developer, my advice is to just use Windows > (or if you are forced to Linux) for any OpenCL development. Besides the > kernel support, all the tools are there. > > Paul
sign of char on arm64
Hi,
While working on porting rust to arm64, I found something that seems a
bit odd for me, and I would like to have confirmation that it is
expected: the signess of char on arm64.
In order to test the sign of 'char' (unsigned or signed), I use the
following C program:
$ cat sign-of-char.c
#include
int
main(int argc, char *argv[])
{
printf("char: %d\n", ((char) -1) < 0);
printf("signed char: %d\n", ((signed char) -1) < 0);
printf("unsigned char: %d\n", ((unsigned char) -1) < 0);
return 0;
}
on amd64, it reports:
amd64$ cc sign-of-char.c -o sign-of-char && ./sign-of-char
char: 1
signed char: 1
unsigned char: 0
so on amd64, 'char' is signed.
but on arm64, I get:
arm64$ cc sign-of-char.c -o sign-of-char && ./sign-of-char
char: 0
signed char: 1
unsigned char: 0
so on arm64 (aarch64), 'char' is unsigned.
Per se, it isn't a problem. And if I correctly understood, the standard
defines 3 distinct types ('char', 'signed char', and 'unsigned char')
and the signess of 'char' is implementation defined.
Also, several architecture-OS already has char unsigned, for example:
- aarch64-android
- powerpc-linux
- arm-linux
But I would like confirmation because for all BSD where I have the
information, I always have a signed char (aarch64-freebsd,
powerpc-netbsd, arm-netbsd, ...), except arm64 on OpenBSD.
Is it expected ?
--
Sebastien Marie
Re: sign of char on arm64
It is an artifact of the processor, not the operating system.
As a general rule (at least in the old days) this had to do with
how condition codes are updated, based upon each operation or
upon extra specific instructions... and this looseness fell out
of that.
> While working on porting rust to arm64, I found something that seems a
> bit odd for me, and I would like to have confirmation that it is
> expected: the signess of char on arm64.
>
> In order to test the sign of 'char' (unsigned or signed), I use the
> following C program:
>
> $ cat sign-of-char.c
> #include
>
> int
> main(int argc, char *argv[])
> {
> printf("char: %d\n", ((char) -1) < 0);
> printf("signed char: %d\n", ((signed char) -1) < 0);
> printf("unsigned char: %d\n", ((unsigned char) -1) < 0);
> return 0;
> }
>
> on amd64, it reports:
> amd64$ cc sign-of-char.c -o sign-of-char && ./sign-of-char
> char: 1
> signed char: 1
> unsigned char: 0
>
> so on amd64, 'char' is signed.
>
> but on arm64, I get:
> arm64$ cc sign-of-char.c -o sign-of-char && ./sign-of-char
> char: 0
> signed char: 1
> unsigned char: 0
>
> so on arm64 (aarch64), 'char' is unsigned.
>
>
> Per se, it isn't a problem. And if I correctly understood, the standard
> defines 3 distinct types ('char', 'signed char', and 'unsigned char')
> and the signess of 'char' is implementation defined.
>
> Also, several architecture-OS already has char unsigned, for example:
> - aarch64-android
> - powerpc-linux
> - arm-linux
>
> But I would like confirmation because for all BSD where I have the
> information, I always have a signed char (aarch64-freebsd,
> powerpc-netbsd, arm-netbsd, ...), except arm64 on OpenBSD.
>
> Is it expected ?
> --
> Sebastien Marie
>
ksh: stop emitting carriage return twice
Hi,
Here's a little nit that has been bugging me while writing tests for
Emacs editing mode in ksh. Since the map-CR-to-NL (ONLCR) output mode is
enabled by default on the tty, emitting a newline gets translated into a
carriage return (CR) followed by newline (NL). Parts of the Emacs
related code emits a explicit CR prior to NL causing two CR characters
to be emitted. The diff below disables ONLCR and explicitly ensures a CR
is present prior to every emitted NL. Vi mode already does this. I find
this approach more favorable and explicit as opposed of keeping ONLCR
enabled and removing the double CRs.
Comments? OK?
Index: edit.c
===
RCS file: /cvs/src/bin/ksh/edit.c,v
retrieving revision 1.57
diff -u -p -r1.57 edit.c
--- edit.c 8 Sep 2016 12:12:40 - 1.57
+++ edit.c 11 Dec 2017 20:10:00 -
@@ -178,6 +178,7 @@ x_mode(bool onoff)
edchars.werase = cb.c_cc[VWERASE];
cb.c_iflag &= ~(INLCR|ICRNL);
cb.c_lflag &= ~(ISIG|ICANON|ECHO);
+ cb.c_oflag &= ~(ONLCR);
/* osf/1 processes lnext when ~icanon */
cb.c_cc[VLNEXT] = _POSIX_VDISABLE;
/* sunos 4.1.x & osf/1 processes discard(flush) when ~icanon */
Index: emacs.c
===
RCS file: /cvs/src/bin/ksh/emacs.c,v
retrieving revision 1.75
diff -u -p -r1.75 emacs.c
--- emacs.c 26 Nov 2017 20:34:15 - 1.75
+++ emacs.c 11 Dec 2017 20:10:00 -
@@ -881,7 +881,7 @@ x_search_hist(int c)
*p = '\0';
while (1) {
if (offset < 0) {
- x_e_puts("\nI-search: ");
+ x_e_puts("\r\nI-search: ");
x_e_puts(pat);
}
x_flush();
@@ -943,8 +943,10 @@ x_search(char *pat, int sameline, int of
for (hp = x_histp - (sameline ? 0 : 1) ; hp >= history; --hp) {
i = x_match(*hp, pat);
if (i >= 0) {
- if (offset < 0)
+ if (offset < 0) {
+ x_e_putc('\r');
x_e_putc('\n');
+ }
x_load_hist(hp);
x_goto(xbuf + i + strlen(pat) - (*pat == '^'));
return i;
@@ -1018,10 +1020,9 @@ x_redraw(int limit)
char*cp;
x_adj_ok = 0;
+ x_e_putc('\r');
if (limit == -1)
x_e_putc('\n');
- else
- x_e_putc('\r');
x_flush();
if (xbp == xbuf) {
x_col = promptlen(prompt, NULL);
@@ -1171,7 +1172,7 @@ x_yank(int c)
killtp = killsp;
killtp --;
if (killstack[killtp] == 0) {
- x_e_puts("\nnothing to yank");
+ x_e_puts("\r\nnothing to yank");
x_redraw(-1);
return KSTD;
}
@@ -1187,7 +1188,7 @@ x_meta_yank(int c)
if ((x_last_command != x_yank && x_last_command != x_meta_yank) ||
killstack[killtp] == 0) {
killtp = killsp;
- x_e_puts("\nyank something first");
+ x_e_puts("\r\nyank something first");
x_redraw(-1);
return KSTD;
}
Re: sign of char on arm64
On Tue, Dec 12, 2017 at 10:44 AM, Sebastien Marie wrote: > > While working on porting rust to arm64, I found something that seems a > bit odd for me, and I would like to have confirmation that it is > expected: the signess of char on arm64. ... > But I would like confirmation because for all BSD where I have the > information, I always have a signed char (aarch64-freebsd, > powerpc-netbsd, arm-netbsd, ...), except arm64 on OpenBSD. > > Is it expected ? > Yes. Note that powerpc-openbsd has char as unsigned. Philip Guenther
Re: sign of char on arm64
On Tue, Dec 12 2017, Sebastien Marie wrote: [...] > But I would like confirmation because for all BSD where I have the > information, I always have a signed char (aarch64-freebsd, > powerpc-netbsd, arm-netbsd, ...), except arm64 on OpenBSD. > > Is it expected ? I would certainly not expect NetBSD and FreeBSD to have "char" signed by default. afaik the powerpc, arm and arm64 ABIs define "char" as unsigned. FreeBSD documents those architectures as using unsigned char: https://www.freebsd.org/cgi/man.cgi?query=arch&apropos=0&sektion=7&manpath=FreeBSD+12-current&arch=default&format=html afaik with clang and gcc you can just test whether __CHAR_UNSIGNED__ is defined. -- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
disable hw vlan tagging support in ix(4)
im still looking at vlan performance problems, as discussed by mpi@
at http://www.grenadille.net/post/2017/02/13/What-happened-to-my-vlan.
recently it occurred to me that we're making an implicit assumption
that having the chip handle the injection of vlan tags has zero
cost, and that all the loss in performance is purely a software
problem. to test this assumption i knocked up the diff below to
disable hw vlan tagging in ix(4), which was used in the tests mpi
and hrvoje did.
hrvoje tested this diff for me and noted a 10% improvement in pps
when forwarding between vlan interfaces on ix(4). to quote hrvoje:
without diff
send - receive
vlan - vlan = 830Kpps
with diff
send - receive
vlan - vlan = 995Kpps
my conclusion is that assumption that nics are fast at offloads is
wrong. therefore id like to put this in. unfortunately 10% doesnt
account for the entire loss in forwarding over vlan, but it does
help a bit.
would anyone else like to test? or ok it?
dlg
Index: if_ix.c
===
RCS file: /cvs/src/sys/dev/pci/if_ix.c,v
retrieving revision 1.152
diff -u -p -r1.152 if_ix.c
--- if_ix.c 22 Jun 2017 02:44:37 - 1.152
+++ if_ix.c 12 Dec 2017 23:39:41 -
@@ -154,8 +154,6 @@ voidixgbe_set_ivar(struct ix_softc *, u
void ixgbe_configure_ivars(struct ix_softc *);
uint8_t*ixgbe_mc_array_itr(struct ixgbe_hw *, uint8_t **, uint32_t *);
-void ixgbe_setup_vlan_hw_support(struct ix_softc *);
-
/* Support for pluggable optic modules */
void ixgbe_setup_optics(struct ix_softc *);
void ixgbe_handle_mod(struct ix_softc *);
@@ -702,9 +700,6 @@ ixgbe_init(void *arg)
IXGBE_WRITE_REG(&sc->hw, IXGBE_RDT(i), rxr->last_desc_filled);
}
- /* Set up VLAN support and filter */
- ixgbe_setup_vlan_hw_support(sc);
-
/* Enable Receive engine */
rxctrl = IXGBE_READ_REG(&sc->hw, IXGBE_RXCTRL);
if (sc->hw.mac.type == ixgbe_mac_82598EB)
@@ -1621,10 +1616,6 @@ ixgbe_setup_interface(struct ix_softc *s
ifp->if_capabilities = IFCAP_VLAN_MTU;
-#if NVLAN > 0
- ifp->if_capabilities |= IFCAP_VLAN_HWTAGGING;
-#endif
-
#ifdef IX_CSUM_OFFLOAD
ifp->if_capabilities |= IFCAP_CSUM_TCPv4 | IFCAP_CSUM_UDPv4;
#endif
@@ -2922,12 +2913,6 @@ ixgbe_rxeof(struct ix_queue *que)
/* first desc of a non-ps chain */
sendmp = mp;
sendmp->m_pkthdr.len = mp->m_len;
-#if NVLAN > 0
- if (staterr & IXGBE_RXD_STAT_VP) {
- sendmp->m_pkthdr.ether_vtag = vtag;
- sendmp->m_flags |= M_VLANTAG;
- }
-#endif
}
/* Pass the head pointer on */
@@ -2989,44 +2974,6 @@ ixgbe_rx_checksum(uint32_t staterr, stru
if (!(errors & IXGBE_RXD_ERR_TCPE))
mp->m_pkthdr.csum_flags |=
M_TCP_CSUM_IN_OK | M_UDP_CSUM_IN_OK;
- }
-}
-
-void
-ixgbe_setup_vlan_hw_support(struct ix_softc *sc)
-{
- uint32_tctrl;
- int i;
-
- /*
-* A soft reset zero's out the VFTA, so
-* we need to repopulate it now.
-*/
- for (i = 0; i < IXGBE_VFTA_SIZE; i++) {
- if (sc->shadow_vfta[i] != 0)
- IXGBE_WRITE_REG(&sc->hw, IXGBE_VFTA(i),
- sc->shadow_vfta[i]);
- }
-
- ctrl = IXGBE_READ_REG(&sc->hw, IXGBE_VLNCTRL);
-#if 0
- /* Enable the Filter Table if enabled */
- if (ifp->if_capenable & IFCAP_VLAN_HWFILTER) {
- ctrl &= ~IXGBE_VLNCTRL_CFIEN;
- ctrl |= IXGBE_VLNCTRL_VFE;
- }
-#endif
- if (sc->hw.mac.type == ixgbe_mac_82598EB)
- ctrl |= IXGBE_VLNCTRL_VME;
- IXGBE_WRITE_REG(&sc->hw, IXGBE_VLNCTRL, ctrl);
-
- /* On 82599 the VLAN enable is per/queue in RXDCTL */
- if (sc->hw.mac.type != ixgbe_mac_82598EB) {
- for (i = 0; i < sc->num_queues; i++) {
- ctrl = IXGBE_READ_REG(&sc->hw, IXGBE_RXDCTL(i));
- ctrl |= IXGBE_RXDCTL_VME;
- IXGBE_WRITE_REG(&sc->hw, IXGBE_RXDCTL(i), ctrl);
- }
}
}
Re: iked, don't return NULL in print_host
On Tue, Dec 12 2017, Patrick Wildt wrote:
> On Tue, Dec 12, 2017 at 03:32:50PM +0100, Patrick Wildt wrote:
>> On Wed, Nov 29, 2017 at 07:50:21PM +0100, Claudio Jeker wrote:
>> > More or less. It seems that msg_local is garbage:
>> > $3 = {msg_data = 0x1b4e541fa4c0, msg_offset = 0, msg_local = {
>> > ss_len = 128 '\200', ss_family = 192 'À',
>> > __ss_pad1 = 0x7f7da8c2 "Ì]\001", __ss_pad2 = 30024042514159,
>> > __ss_pad3 = 0x7f7da8d0 "Ьýÿ\177\177"}, msg_locallen = 128,
>> > msg_peer = {ss_len = 16 '\020', ss_family = 2 '\002',
>> > __ss_pad1 = 0x7f7da9ca "\001ô>0\036\005", __ss_pad2 = 0,
>> > __ss_pad3 = 0x7f7da9d8 ""}, msg_peerlen = 16,
>> >
>> > Why so I don't know.
>>
>> I found it. socket_getaddr is called to retrieve information about the
>> socket behind the file descriptor. If I understand correctly, we need
>> to pass the length of the struct to getsockname() so that it knows how
>> far it can fill the struct. So far we always passed stack garbage, so
>> sometimes it worked, sometimes not. Then getsockname() does not change
>> the struct, so sockaddr_storage ss is still stack garbarge, and that
>> ends up in msg_local.
>>
>> I think recvfromto() suffers the same. The caller ikev2_msg_cb() does
>> pass the correct size to recvfromto(), but then recvfromto() uncondi-
>> tionally overwrites it with zero before calling getsockname().
... and then cmsg handling should update *tolen.
>> Opinions?
The getsockname(2) doesn't seem to perform anything useful: the ikev2
process gets a fully initialized sockaddr (len, family, address,
port) along with the socket, and recvfromto() could just care about
filling the address using cmsg parsing.
>> Patrick
>
> Markus points out that socket_getaddr() is promised a pointer to a
> sockaddr_storage, so we don't need to pass the length and can just
> initialize sslen correctly.
ok jca@ for socket_getaddr(), also ok for recvfromto() since the code is
confusing as is, but if I'm not mistaken we could just remove the
getsockname(2) call.
> diff --git a/sbin/iked/util.c b/sbin/iked/util.c
> index 1d4cee2c424..e67dae27d8a 100644
> --- a/sbin/iked/util.c
> +++ b/sbin/iked/util.c
> @@ -93,7 +93,7 @@ socket_setport(struct sockaddr *sa, in_port_t port)
> int
> socket_getaddr(int s, struct sockaddr_storage *ss)
> {
> - socklen_t sslen;
> + socklen_t sslen = sizeof(*ss);
>
> return (getsockname(s, (struct sockaddr *)ss, &sslen));
> }
> @@ -366,7 +366,6 @@ recvfromto(int s, void *buf, size_t len, int flags,
> struct sockaddr *from,
> return (-1);
>
> *fromlen = from->sa_len;
> - *tolen = 0;
>
> if (getsockname(s, to, tolen) != 0)
> *tolen = 0;
>
--
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
relayd and PUT
Hi!
If you http PUT a "big" file through relayd, server<>relay read side
will eventually get a EVBUFFER_TIMEOUT. Nothing comes back from the
server until the PUT is done. I disabled server read timeouts for PUT
requests.
While trying to fix the issue I managed to trigger another problem. For
HTTP relays we open relay<>server connection only after the first
request is completely read from the client. If http PUT is the the
first request and is big enough we will run out of memory and
eventually out of swap. To avoid the issue I will open relay<>server
connection earlyer and let relayd to start sending the stuff to the
server.
And another one I don't know how to fix. If relayd fills all memory and
swap with buffers kernel enters infinite loop. relayd is in flt_noram
state and pagedaemon constantly tries to free something without any
luck. userland scheduling halts. bgp looses its peers but carp still
happily sends its hellos...
Rivo
Index: usr.sbin/relayd/relay.c
===
RCS file: /cvs/src/usr.sbin/relayd/relay.c,v
retrieving revision 1.236
diff -u -p -r1.236 relay.c
--- usr.sbin/relayd/relay.c 28 Nov 2017 01:51:47 - 1.
236
+++ usr.sbin/relayd/relay.c 13 Dec 2017 00:05:33 -
@@ -723,7 +723,8 @@ relay_connected(int fd, short sig, void
relay_tls_connected(out);
bufferevent_settimeout(bev,
- rlay->rl_conf.timeout.tv_sec, rlay-
>rl_conf.timeout.tv_sec);
+ con->se_out.writeonly ? 0 : rlay->rl_conf.timeout.tv_sec,
+ rlay->rl_conf.timeout.tv_sec);
bufferevent_setwatermark(bev, EV_WRITE,
RELAY_MIN_PREFETCHED * proto->tcpbufsiz, 0);
bufferevent_enable(bev, EV_READ|EV_WRITE);
Index: usr.sbin/relayd/relay_http.c
===
RCS file: /cvs/src/usr.sbin/relayd/relay_http.c,v
retrieving revision 1.70
diff -u -p -r1.70 relay_http.c
--- usr.sbin/relayd/relay_http.c27 Nov 2017 16:25:50 -
1.70
+++ usr.sbin/relayd/relay_http.c13 Dec 2017 00:05:33 -
@@ -439,6 +439,10 @@ relay_read_http(struct bufferevent *bev,
case HTTP_METHOD_OPTIONS:
case HTTP_METHOD_POST:
case HTTP_METHOD_PUT:
+ con->se_out.writeonly = 1;
+ if(cre->dst->state == STATE_CONNECTED)
+ bufferevent_settimeout(bev,
+ 0, rlay->rl_conf.timeout.tv_sec);
case HTTP_METHOD_RESPONSE:
/* WebDAV methods */
case HTTP_METHOD_PROPFIND:
@@ -569,6 +573,9 @@ relay_read_httpcontent(struct buffereven
goto fail;
cre->toread -= size;
}
+ if (cre->dst->writeonly && cre->dst->state !=
STATE_CONNECTED)
+ if (relay_connect(con) == -1)
+ goto fail;
DPRINTF("%s: done, size %lu, to read %lld", __func__,
size, cre->toread);
}
Index: usr.sbin/relayd/relayd.h
===
RCS file: /cvs/src/usr.sbin/relayd/relayd.h,v
retrieving revision 1.248
diff -u -p -r1.248 relayd.h
--- usr.sbin/relayd/relayd.h28 Nov 2017 18:25:53 - 1
.248
+++ usr.sbin/relayd/relayd.h13 Dec 2017 00:05:33 -
@@ -218,6 +218,7 @@ struct ctl_relay_event {
int line;
int done;
int timedout;
+ int writeonly;
enum relay_state state;
enum direction dir;
Re: Removal of PIM support in kernel
Thanks for the info! Forgot about few such examples, such as sources don't signal so there is a timeout counter for (s,g) that need to be monitored, traffic utilization that might trigger SFP and I guess many more On Mon, Dec 11, 2017 at 11:33 PM, Claudio Jeker wrote: > On Tue, Dec 12, 2017 at 02:32:06PM +1000, David Gwynne wrote: > > > > > On 12 Dec 2017, at 02:41, Dan Shechter wrote: > > > > > > I know I am about to be hammered here but... > > > > > > Without reading the sources, and being a Cisco admin, I am asking this > > > question: What PIM got to do with the kernel? PIM is just a > > > signaling/routing protocol, like OSPF/BGP. It should just update the > mroute > > > tables. > > > > i have wondered that too. maybe it still works? > > > > The problem is that multicast needs a bit more then just a lookup table. > The signaling includes joining and leaving of groups but also traffic flow > information. PIM extended the ioctl interface that mrouted used to enable > some of the advanced features (and maybe also to just be a bit > better/different). I'm for sure no fan of the ioctl() interface used for > those protocols and would prefer to use a routing socket for that (but > that's just my opinion). > > > > > > > Is it about the register unicast? > > > > > > On Sun, Dec 10, 2017 at 8:59 AM, Joachim Nilsson > > > wrote: > > > > > >> Hi, > > >> > > >> my name i Joachim and I'm the current upstream maintainer of the > > >> original pimd[1] and mrouted[2] multicast routing daemons. > > >> > > >> First of all, I'd like to give a huge thank you to the OpenBSD team > > >> for all the hard work you put in with Stanford to relicense mrouted > > >> under a BSD license[4]! I don't think you know this, but your work > > >> also freed pimd[1], which in large parts is based on mrouted. > > >> > > >> Now, I've got a few worried questions recently about the removal[3] > > >> of PIM support in OpenBSD, so I thought I'd ask here. Why have you > > >> removed it? I'd be very happy if someone could just fill me in, or > > >> provide a pointer to a mailing list discussion (I couldn't find any). > > >> At the very least I'd like to have up to date information to provide > > >> my users. > > >> > > >> There are currently three major open source PIM implementations for > > >> UNIX that I know of: pimd[1] which today supports both PIM-SM and > > >> PIM-SSM, Xorp pimd[5] (PIM-SM only), and the Quagga PIM-SSM only > > >> pimd[6]. All of them support(ed) OpenBSD, and at least I tested > > >> regularly on OpenBSD. I think the community could greatly benefit > > >> from keeping the PIM kernel support, however, I do understand that > > >> you primarily only support your in-tree applications, like mrouted. > > >> > > >> Best regards > > >> /Joachim Nilsson > > >> > > >> [1]: https://github.com/troglobit/pimd/ > > >> [2]: https://github.com/troglobit/mrouted/ > > >> [3]: https://marc.info/?l=openbsd-cvs&m=148240469327159 > > >> [4]: http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.sbin/ > mrouted/LICE > > >> NSE > > >> [5]: https://github.com/greearb/xorp.ct/ > > >> [6]: https://github.com/FRRouting/frr/ > > >> > > >> > > > > -- > :wq Claudio >
Re: relayd and PUT
Hi!
Without text mangling this time...
Rivo
Index: usr.sbin/relayd/relay.c
===
RCS file: /cvs/src/usr.sbin/relayd/relay.c,v
retrieving revision 1.236
diff -u -p -r1.236 relay.c
--- usr.sbin/relayd/relay.c 28 Nov 2017 01:51:47 - 1.236
+++ usr.sbin/relayd/relay.c 13 Dec 2017 00:05:33 -
@@ -723,7 +723,8 @@ relay_connected(int fd, short sig, void
relay_tls_connected(out);
bufferevent_settimeout(bev,
- rlay->rl_conf.timeout.tv_sec, rlay->rl_conf.timeout.tv_sec);
+ con->se_out.writeonly ? 0 : rlay->rl_conf.timeout.tv_sec,
+ rlay->rl_conf.timeout.tv_sec);
bufferevent_setwatermark(bev, EV_WRITE,
RELAY_MIN_PREFETCHED * proto->tcpbufsiz, 0);
bufferevent_enable(bev, EV_READ|EV_WRITE);
Index: usr.sbin/relayd/relay_http.c
===
RCS file: /cvs/src/usr.sbin/relayd/relay_http.c,v
retrieving revision 1.70
diff -u -p -r1.70 relay_http.c
--- usr.sbin/relayd/relay_http.c27 Nov 2017 16:25:50 - 1.70
+++ usr.sbin/relayd/relay_http.c13 Dec 2017 00:05:33 -
@@ -439,6 +439,10 @@ relay_read_http(struct bufferevent *bev,
case HTTP_METHOD_OPTIONS:
case HTTP_METHOD_POST:
case HTTP_METHOD_PUT:
+ con->se_out.writeonly = 1;
+ if(cre->dst->state == STATE_CONNECTED)
+ bufferevent_settimeout(bev,
+ 0, rlay->rl_conf.timeout.tv_sec);
case HTTP_METHOD_RESPONSE:
/* WebDAV methods */
case HTTP_METHOD_PROPFIND:
@@ -569,6 +573,9 @@ relay_read_httpcontent(struct buffereven
goto fail;
cre->toread -= size;
}
+ if (cre->dst->writeonly && cre->dst->state != STATE_CONNECTED)
+ if (relay_connect(con) == -1)
+ goto fail;
DPRINTF("%s: done, size %lu, to read %lld", __func__,
size, cre->toread);
}
Index: usr.sbin/relayd/relayd.h
===
RCS file: /cvs/src/usr.sbin/relayd/relayd.h,v
retrieving revision 1.248
diff -u -p -r1.248 relayd.h
--- usr.sbin/relayd/relayd.h28 Nov 2017 18:25:53 - 1.248
+++ usr.sbin/relayd/relayd.h13 Dec 2017 00:05:33 -
@@ -218,6 +218,7 @@ struct ctl_relay_event {
int line;
int done;
int timedout;
+ int writeonly;
enum relay_state state;
enum direction dir;
begin-base64 644 relayd_put.diff
SW5kZXg6IHVzci5zYmluL3JlbGF5ZC9yZWxheS5jCj09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KUkNTIGZpbGU6IC9jdnMv
c3JjL3Vzci5zYmluL3JlbGF5ZC9yZWxheS5jLHYKcmV0cmlldmluZyByZXZpc2lvbiAxLjIzNgpk
aWZmIC11IC1wIC1yMS4yMzYgcmVsYXkuYwotLS0gdXNyLnNiaW4vcmVsYXlkL3JlbGF5LmMJMjgg
Tm92IDIwMTcgMDE6NTE6NDcgLTAwMDAJMS4yMzYKKysrIHVzci5zYmluL3JlbGF5ZC9yZWxheS5j
CTEzIERlYyAyMDE3IDAwOjA1OjMzIC0wMDAwCkBAIC03MjMsNyArNzIzLDggQEAgcmVsYXlfY29u
bmVjdGVkKGludCBmZCwgc2hvcnQgc2lnLCB2b2lkIAogCQlyZWxheV90bHNfY29ubmVjdGVkKG91
dCk7CiAKIAlidWZmZXJldmVudF9zZXR0aW1lb3V0KGJldiwKLQkgICAgcmxheS0+cmxfY29uZi50
aW1lb3V0LnR2X3NlYywgcmxheS0+cmxfY29uZi50aW1lb3V0LnR2X3NlYyk7CisJICAgIGNvbi0+
c2Vfb3V0LndyaXRlb25seSA/IDAgOiBybGF5LT5ybF9jb25mLnRpbWVvdXQudHZfc2VjLAorCSAg
ICBybGF5LT5ybF9jb25mLnRpbWVvdXQudHZfc2VjKTsKIAlidWZmZXJldmVudF9zZXR3YXRlcm1h
cmsoYmV2LCBFVl9XUklURSwKIAkJUkVMQVlfTUlOX1BSRUZFVENIRUQgKiBwcm90by0+dGNwYnVm
c2l6LCAwKTsKIAlidWZmZXJldmVudF9lbmFibGUoYmV2LCBFVl9SRUFEfEVWX1dSSVRFKTsKSW5k
ZXg6IHVzci5zYmluL3JlbGF5ZC9yZWxheV9odHRwLmMKPT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQpSQ1MgZmlsZTogL2N2
cy9zcmMvdXNyLnNiaW4vcmVsYXlkL3JlbGF5X2h0dHAuYyx2CnJldHJpZXZpbmcgcmV2aXNpb24g
MS43MApkaWZmIC11IC1wIC1yMS43MCByZWxheV9odHRwLmMKLS0tIHVzci5zYmluL3JlbGF5ZC9y
ZWxheV9odHRwLmMJMjcgTm92IDIwMTcgMTY6MjU6NTAgLTAwMDAJMS43MAorKysgdXNyLnNiaW4v
cmVsYXlkL3JlbGF5X2h0dHAuYwkxMyBEZWMgMjAxNyAwMDowNTozMyAtMDAwMApAQCAtNDM5LDYg
KzQzOSwxMCBAQCByZWxheV9yZWFkX2h0dHAoc3RydWN0IGJ1ZmZlcmV2ZW50ICpiZXYsCiAJCWNh
c2UgSFRUUF9NRVRIT0RfT1BUSU9OUzoKIAkJY2FzZSBIVFRQX01FVEhPRF9QT1NUOgogCQljYXNl
IEhUVFBfTUVUSE9EX1BVVDoKKwkJCWNvbi0+c2Vfb3V0LndyaXRlb25seSA9IDE7CisJCQlpZihj
cmUtPmRzdC0+c3RhdGUgPT0gU1RBVEVfQ09OTkVDVEVEKQorCQkJCWJ1ZmZlcmV2ZW50X3NldHRp
bWVvdXQoYmV2LAorCQkJCSAgICAwLCBybGF5LT5ybF9jb25mLnRpbWVvdXQudHZfc2VjKTsgCiAJ
CWNhc2UgSFRUUF9NRVRIT0RfUkVTUE9OU0U6CiAJCS8qIFdlYkRBViBtZXRob2RzICovCiAJCWNh
c2UgSFRUUF9NRVRIT0RfUFJPUEZJTkQ6CkBAIC01NjksNiArNTczLDkgQEAgcmVsYXlfcmVhZF9o
dHRwY29udGVudChzdHJ1Y3QgYnVmZmVyZXZlbgogCQkJCWdvdG8gZmFpbDsKIAkJCWNyZS0+dG9y
ZWFkIC09IHNpemU7CiAJCX0KKwkJaWYgKGNyZS0+
faq14.html minor patch
$ diff -u faq14.html faq14.html.orig --- faq14.html Tue Dec 12 21:50:14 2017 +++ faq14.html.orig Tue Dec 12 21:50:03 2017 @@ -391,7 +391,7 @@ Here is an example /etc/fstab line: -0123456789abcdef.k /home ffs rw,nodev,nosuid,userquota 1 2 +0123456789abcdef.k /home ffs rw,nodev,nosuid,userquota 1 1 To set the users' quotas, use According to fstab(5) The root filesystem should be specified with a fs_passno of 1, and other filesystems should have a fs_passno of 2.
Re: sign of char on arm64
First, thanks to all people that answered, off-list or not. On Tue, Dec 12, 2017 at 10:01:14PM +0100, Jeremie Courreges-Anglas wrote: > On Tue, Dec 12 2017, Sebastien Marie wrote: > > [...] > > > But I would like confirmation because for all BSD where I have the > > information, I always have a signed char (aarch64-freebsd, > > powerpc-netbsd, arm-netbsd, ...), except arm64 on OpenBSD. > > > > Is it expected ? > > I would certainly not expect NetBSD and FreeBSD to have "char" signed by > default. afaik the powerpc, arm and arm64 ABIs define "char" as > unsigned. > > FreeBSD documents those architectures as using unsigned char: > > > https://www.freebsd.org/cgi/man.cgi?query=arch&apropos=0&sektion=7&manpath=FreeBSD+12-current&arch=default&format=html So it means the Rust libc definition for them is currently wrong, as 'char' is defined as 'i8' (signed byte) instead of 'u8' (unsigned byte). I will report it to FreeBSD people. > afaik with clang and gcc you can just test whether __CHAR_UNSIGNED__ is > defined. Rust is a wonderfull land where all the standard libc definition has to be rewritten by hand (and kept in sync), so I haven't access to such compilation variable... Thanks ! -- Sebastien Marie
Re: remove one bug, add three
Hi again, I would like to mention that the committed patch for the trivial bugs that I reported is not even complete: there are still two problematic instructions literally one line above the one that did get fixed correctly (and I actually find this mildly amusing, especially considering the last paragraph of my first message). On Tue, 12 Dec 2017 16:09:36 +, Martijn van Duren wrote: > Also the reasonable way is debatable because it's behaviour > actually changes on the BRE side if you use n as a separator and gsed > has an identical quirk on the replacement side: Ah, so now you notice that there are even more incompatibilities between this version and GNU sed where POSIX leaves the behaviour undefined; would you also want to transform these cases into hard errors, then? Please go right ahead, at least I am sure millert@ would like it. > Patch to do so below. Not asking for OKs (yet), since compile_re is used > in more places and whipped up in about a minute. I understand that you may be busy with many other things at once, but rushing out absurd diffs like this one or committing half-baked patches on top of less than half-baked patches is not a very efficient approach. I am happy to wait until you find enough time for a proper evaluation of the issue at stake; this is not a race. Regards, kshe
Re: relayd and PUT
On Wed, Dec 13, 2017 at 12:25:39AM +, Rivo Nurges wrote:
> Hi!
>
> If you http PUT a "big" file through relayd, server<>relay read side
> will eventually get a EVBUFFER_TIMEOUT. Nothing comes back from the
> server until the PUT is done. I disabled server read timeouts for PUT
> requests.
>
> While trying to fix the issue I managed to trigger another problem. For
> HTTP relays we open relay<>server connection only after the first
> request is completely read from the client. If http PUT is the the
> first request and is big enough we will run out of memory and
> eventually out of swap. To avoid the issue I will open relay<>server
> connection earlyer and let relayd to start sending the stuff to the
> server.
>
> And another one I don't know how to fix. If relayd fills all memory and
> swap with buffers kernel enters infinite loop. relayd is in flt_noram
> state and pagedaemon constantly tries to free something without any
> luck. userland scheduling halts. bgp looses its peers but carp still
> happily sends its hellos...
>
I have seen something similar and came to the conclusion that the timeout
handling of relayd is not correct. As long as traffic is flowing the
timeout should be reset (at least that is what every other implementation
does). This is not really happening in relayd. I have seen this on GET
requests that are huge (timeout hits in the middle of the transimit and
kills the session).
Because of this I think the diff is a workaround and does not solve the
real underlying problem.
> Rivo
>
> Index: usr.sbin/relayd/relay.c
> ===
> RCS file: /cvs/src/usr.sbin/relayd/relay.c,v
> retrieving revision 1.236
> diff -u -p -r1.236 relay.c
> --- usr.sbin/relayd/relay.c 28 Nov 2017 01:51:47 - 1.
> 236
> +++ usr.sbin/relayd/relay.c 13 Dec 2017 00:05:33 -
> @@ -723,7 +723,8 @@ relay_connected(int fd, short sig, void
> relay_tls_connected(out);
>
> bufferevent_settimeout(bev,
> - rlay->rl_conf.timeout.tv_sec, rlay-
> >rl_conf.timeout.tv_sec);
> + con->se_out.writeonly ? 0 : rlay->rl_conf.timeout.tv_sec,
> + rlay->rl_conf.timeout.tv_sec);
> bufferevent_setwatermark(bev, EV_WRITE,
> RELAY_MIN_PREFETCHED * proto->tcpbufsiz, 0);
> bufferevent_enable(bev, EV_READ|EV_WRITE);
> Index: usr.sbin/relayd/relay_http.c
> ===
> RCS file: /cvs/src/usr.sbin/relayd/relay_http.c,v
> retrieving revision 1.70
> diff -u -p -r1.70 relay_http.c
> --- usr.sbin/relayd/relay_http.c 27 Nov 2017 16:25:50 -
> 1.70
> +++ usr.sbin/relayd/relay_http.c 13 Dec 2017 00:05:33 -
> @@ -439,6 +439,10 @@ relay_read_http(struct bufferevent *bev,
> case HTTP_METHOD_OPTIONS:
> case HTTP_METHOD_POST:
> case HTTP_METHOD_PUT:
> + con->se_out.writeonly = 1;
> + if(cre->dst->state == STATE_CONNECTED)
> + bufferevent_settimeout(bev,
> + 0, rlay->rl_conf.timeout.tv_sec);
> case HTTP_METHOD_RESPONSE:
> /* WebDAV methods */
> case HTTP_METHOD_PROPFIND:
> @@ -569,6 +573,9 @@ relay_read_httpcontent(struct buffereven
> goto fail;
> cre->toread -= size;
> }
> + if (cre->dst->writeonly && cre->dst->state !=
> STATE_CONNECTED)
> + if (relay_connect(con) == -1)
> + goto fail;
> DPRINTF("%s: done, size %lu, to read %lld", __func__,
> size, cre->toread);
> }
> Index: usr.sbin/relayd/relayd.h
> ===
> RCS file: /cvs/src/usr.sbin/relayd/relayd.h,v
> retrieving revision 1.248
> diff -u -p -r1.248 relayd.h
> --- usr.sbin/relayd/relayd.h 28 Nov 2017 18:25:53 - 1
> .248
> +++ usr.sbin/relayd/relayd.h 13 Dec 2017 00:05:33 -
> @@ -218,6 +218,7 @@ struct ctl_relay_event {
> int line;
> int done;
> int timedout;
> + int writeonly;
> enum relay_state state;
> enum direction dir;
>
--
:wq Claudio
Re: faq14.html minor patch
On Tue, Dec 12, 2017 at 09:53:09PM -0600, Edgar Pettijohn wrote: > $ diff -u faq14.html faq14.html.orig > > fixed, thanks. could you please do diffs the other way around? it took me a moment to see what's wrong :)
