syslogd include directive reads but disregards all but the last included .conf file

[Mark Martinec]

Could somebody please check why the new 'include' 11.1 feature of 
syslogd

does not work when given more than one file to include...

Any chance of fixing this as a patch release to 11.1 ?



The 11.1 release brought a very desirable feature to syslogd:

$ man syslog.conf :
  A special include keyword can be used to include all files with names
  ending in '.conf' and not beginning with a '.' contained in the 
directory

  following the keyword.

but ...

It turns out that of all the *.conf files found in the included
directory /etc/syslog.d, only entries found in the (alphabetically)
*last* file there are taken into account, all other entries in
remaining included files are just ignored.

[...]

Details at:

  Bug 221742
syslogd include directive reads but disregards all but the last 
included .conf file


  https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221742


Mark
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: mlx4en, timer irq @100%... (11.0 stuck on high network load ???)

[Julien Charbon]

 Hi Ben,

On 8/28/17 10:25 AM, Ben RUBSON wrote:
>> On 16 Aug 2017, at 11:02, Ben RUBSON  wrote:
>>
>>> On 15 Aug 2017, at 23:33, Julien Charbon  wrote:
>>>
>>> On 8/11/17 11:32 AM, Ben RUBSON wrote:
> On 08 Aug 2017, at 13:33, Julien Charbon  wrote:
>
> On 8/8/17 10:31 AM, Hans Petter Selasky wrote:
>>
>> Suggested fix attached.
>
> I agree we your conclusion.  Just for the record, more precisely this
> regression seems to have been introduced with:
> (...)
> Thus good catch, and your patch looks good.  I am going to just verify
> the other in_pcbrele_wlocked() calls in TCP stack.

 Julien, do you plan to make this fix reach 11.0-p12 ?
>>>
>>> I am checking if your issue is another flavor of the issue fixed by:
>>>
>>> https://svnweb.freebsd.org/base?view=revision=307551
>>> https://reviews.freebsd.org/D8211
>>>
>>> This fix in not in 11.0 but in 11.1.  Currently I did not found how an
>>> inp in INP_TIMEWAIT state can have been INP_FREED without having its tw
>>> set to NULL already except the issue fixed by r307551.
>>>
>>> Thus could you try to apply this patch:
>>>
>>> https://github.com/freebsd/freebsd/commit/acb5bfda99b753d9ead3529d04f20087c5f7d0a0.patch
>>>
>>> and see if you can still reproduce this issue?
>>
>> Thank you for your answer Julien.
>> Unfortunately, I'm not sure at all how to reproduce the issue.
>> I have other servers which are 100% identical to this one, same workload,
>> same some-months uptime, but they did not trigger the bug yet.
>>
>> If other network stack experts (I'm not) agree with your analysis,
>> we could then certainly go further with D8211 / r307551.
>>
>> One thing that perhaps might help :
>> # netstat -an | grep TIME_WAIT$ | wc -l
>> 468
>>
>> Note that due to this running bug, sendmail has lots of difficulties to send 
>> outgoing mails.
>> As soon as I run the above netstat command, I receive a lot of stacked mails 
>> (more than 20 this time).
>> As if netstat was able to somehow help...
>>
>> Number of TIME_WAIT connections however does not decrease, but increases.
>>
>>> And in the spirit of r307551 fix and based on Hans patch I will also
>>> propose to add a kernel log describing the issue instead of starting an
>>> infinite loop when INVARIANT is not set.
>>
>> Which should then never be triggered :)
>> Good idea I think !
> 
> What about :
> D8211/r307551
> + Hans' patch
> + Julien's idea of a kernel log (sort of "We should not be here but we are")

 I did this change and I am testing it, on your side did you try this
patch applied on 11.0?

https://github.com/freebsd/freebsd/commit/acb5bfda99b753d9ead3529d04f20087c5f7d0a0.patch

> And backporting all this to 11.0 (and so to 11.1 too) ?
>
> As this bug can impact every FreeBSD machine / server,
> leading to an unavailable / unreachable system (this is how mine ended),
> sounds like it could inevitably be a good thing, for production stability 
> purpose.

 The main fix for your issue is (I believe):

Fix a double-free when an inp transitions to INP_TIMEWAIT state
after having been dropped.
https://svnweb.freebsd.org/base?view=revision=307551

 This fix has been MFC-ed on both stable/11, stable/10 and is already
included in 11.1 and will be in 10.4.  To push in 11.0 release directly,
I guess you have to promote this change to an Errata (never did that
myself):

https://www.freebsd.org/security/notices.html
https://www.freebsd.org/security/security.html#reporting

 While waiting for this errata to be accepted better using the patch.

 My 2 cents.

--
Julien
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: svn commit: r322875 - head/sys/dev/nvme

[Ed Schouten]

2017-08-28 11:02 GMT+02:00 Mark Millard :
> Based on the same main.cc as before . . .
>
> g++7 -std=c++98 main.cc
> g++7 -Wpedantic -std=c++98 main.cc
> g++7 -std=c++03 main.cc
> g++7 -Wpedantic -std=c++03 main.cc
>
> no longer complain (so no error, no
> warning).

Perfect! I've committed this change as r322965. Thanks for testing!


-- 
Ed Schouten 
Nuxi, 's-Hertogenbosch, the Netherlands
KvK-nr.: 62051717
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: svn commit: r322875 - head/sys/dev/nvme

[Mark Millard]

On 2017-Aug-27, at 11:54 PM, Ed Schouten  wrote:

> 2017-08-25 14:53 GMT+02:00 Ed Schouten :
>> 2017-08-25 9:46 GMT+02:00 Mark Millard :
>>> It appears that at least 11.1-STABLE -r322807 does not handle
>>> -std=c++98 styles of use of _Static_assert for g++7 in that
>>> g++7 reports an error:
>> 
>> Maybe we need to do something like this?
>> 
>> Index: sys/sys/cdefs.h
>> ===
>> --- sys/sys/cdefs.h (revision 322887)
>> +++ sys/sys/cdefs.h (working copy)
>> @@ -294,7 +294,7 @@
>> #if (defined(__cplusplus) && __cplusplus >= 201103L) || \
>> __has_extension(cxx_static_assert)
>> #define _Static_assert(x, y) static_assert(x, y)
>> -#elif __GNUC_PREREQ__(4,6)
>> +#elif __GNUC_PREREQ__(4,6) && !defined(__cplusplus)
>> /* Nothing, gcc 4.6 and higher has _Static_assert built-in */
>> #elif defined(__COUNTER__)
>> #define _Static_assert(x, y) __Static_assert(x, __COUNTER__)
> 
> Could you let me know whether this patch fixes the build for you? If
> so, I'll commit it!

As a variant of stable/11 -r322807 . . .

buildworld and buildkernel seem to work fine.
(I did not try any port [re-]builds.)

Based on the same main.cc as before . . .

g++7 -std=c++98 main.cc
g++7 -Wpedantic -std=c++98 main.cc
g++7 -std=c++03 main.cc
g++7 -Wpedantic -std=c++03 main.cc

no longer complain (so no error, no
warning).

clang++ -Wpedantic -std=c++11 main.cc
clang++ -Wpedantic -std=c++98 main.cc
clang++ -Wpedantic -std=c++03 main.cc

each still give the warning but no error.

g++7 -Wpedantic -std=c++11 main.cc
g++7 -std=c++11 main.cc
clang++ -std=c++11 main.cc
clang++ -std=c++98 main.cc
clang++ -std=c++03 main.cc

are still silent, no errors, no warnings.

Note that clang here is version 4 --the
same as in my original report that had the
g++7 rejection example. This is because of
the stable/11 context that I used. (An
intended MFC had been listed.)

If needed I could probably try under some
version of head (and so test clang version
5).

===
Mark Millard
markmi at dsl-only.net

___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: mlx4en, timer irq @100%... (11.0 stuck on high network load ???)

[Ben RUBSON]

> On 16 Aug 2017, at 11:02, Ben RUBSON  wrote:
> 
>> On 15 Aug 2017, at 23:33, Julien Charbon  wrote:
>> 
>> On 8/11/17 11:32 AM, Ben RUBSON wrote:
 On 08 Aug 2017, at 13:33, Julien Charbon  wrote:
 
 On 8/8/17 10:31 AM, Hans Petter Selasky wrote:
> 
> Suggested fix attached.
 
 I agree we your conclusion.  Just for the record, more precisely this
 regression seems to have been introduced with:
 (...)
 Thus good catch, and your patch looks good.  I am going to just verify
 the other in_pcbrele_wlocked() calls in TCP stack.
>>> 
>>> Julien, do you plan to make this fix reach 11.0-p12 ?
>> 
>> I am checking if your issue is another flavor of the issue fixed by:
>> 
>> https://svnweb.freebsd.org/base?view=revision=307551
>> https://reviews.freebsd.org/D8211
>> 
>> This fix in not in 11.0 but in 11.1.  Currently I did not found how an
>> inp in INP_TIMEWAIT state can have been INP_FREED without having its tw
>> set to NULL already except the issue fixed by r307551.
>> 
>> Thus could you try to apply this patch:
>> 
>> https://github.com/freebsd/freebsd/commit/acb5bfda99b753d9ead3529d04f20087c5f7d0a0.patch
>> 
>> and see if you can still reproduce this issue?
> 
> Thank you for your answer Julien.
> Unfortunately, I'm not sure at all how to reproduce the issue.
> I have other servers which are 100% identical to this one, same workload,
> same some-months uptime, but they did not trigger the bug yet.
> 
> If other network stack experts (I'm not) agree with your analysis,
> we could then certainly go further with D8211 / r307551.
> 
> One thing that perhaps might help :
> # netstat -an | grep TIME_WAIT$ | wc -l
> 468
> 
> Note that due to this running bug, sendmail has lots of difficulties to send 
> outgoing mails.
> As soon as I run the above netstat command, I receive a lot of stacked mails 
> (more than 20 this time).
> As if netstat was able to somehow help...
> 
> Number of TIME_WAIT connections however does not decrease, but increases.
> 
>> And in the spirit of r307551 fix and based on Hans patch I will also
>> propose to add a kernel log describing the issue instead of starting an
>> infinite loop when INVARIANT is not set.
> 
> Which should then never be triggered :)
> Good idea I think !

What about :
D8211/r307551
+ Hans' patch
+ Julien's idea of a kernel log (sort of "We should not be here but we are")

And backporting all this to 11.0 (and so to 11.1 too) ?

As this bug can impact every FreeBSD machine / server,
leading to an unavailable / unreachable system (this is how mine ended),
sounds like it could inevitably be a good thing, for production stability 
purpose.

Thank you very much !

Ben

___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: svn commit: r322875 - head/sys/dev/nvme

[Ed Schouten]

Mark,

2017-08-25 14:53 GMT+02:00 Ed Schouten :
> 2017-08-25 9:46 GMT+02:00 Mark Millard :
>> It appears that at least 11.1-STABLE -r322807 does not handle
>> -std=c++98 styles of use of _Static_assert for g++7 in that
>> g++7 reports an error:
>
> Maybe we need to do something like this?
>
> Index: sys/sys/cdefs.h
> ===
> --- sys/sys/cdefs.h (revision 322887)
> +++ sys/sys/cdefs.h (working copy)
> @@ -294,7 +294,7 @@
>  #if (defined(__cplusplus) && __cplusplus >= 201103L) || \
>  __has_extension(cxx_static_assert)
>  #define _Static_assert(x, y) static_assert(x, y)
> -#elif __GNUC_PREREQ__(4,6)
> +#elif __GNUC_PREREQ__(4,6) && !defined(__cplusplus)
>  /* Nothing, gcc 4.6 and higher has _Static_assert built-in */
>  #elif defined(__COUNTER__)
>  #define _Static_assert(x, y) __Static_assert(x, __COUNTER__)

Could you let me know whether this patch fixes the build for you? If
so, I'll commit it!

-- 
Ed Schouten 
Nuxi, 's-Hertogenbosch, the Netherlands
KvK-nr.: 62051717
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"