On Thu, May 07, 2015 at 11:58:49AM +0200, Giovanni Bechis wrote:
On Wed, May 06, 2015 at 09:33:02PM -0400, James Turner wrote:
So I'm not quite sure how to explain this but I'm getting similiar
emails to the one below and it seems like opensmtpd should be rejecting
them as they don't seem
Date: Thu, 7 May 2015 20:58:53 +0200
From: Mike Belopuhov m...@belopuhov.com
As I've pointed out before, on panic we can be running on any
CPU and our disk controller's interrupts can interrupt on the
other one. Since we'll most likely be holding a kernel lock,
dealing with unlocking it
On 2015/05/08 12:12, Gilles Chehade wrote:
I think the proper fix is to reconsider the prepend in the mda case.
If procmail requires custom config, so be it.
Given that people aren't meant to be using procmail anyway, this sounds good to
me.
On 07/05/15(Thu) 20:58, Mike Belopuhov wrote:
As I've pointed out before, on panic we can be running on any
CPU and our disk controller's interrupts can interrupt on the
other one. Since we'll most likely be holding a kernel lock,
dealing with unlocking it might get hairy very fast. Instead
On Fri, May 08, 2015 at 11:23:22AM +0200, Gilles Chehade wrote:
On Thu, May 07, 2015 at 11:58:49AM +0200, Giovanni Bechis wrote:
On Wed, May 06, 2015 at 09:33:02PM -0400, James Turner wrote:
So I'm not quite sure how to explain this but I'm getting similiar
emails to the one below and it
On 8 May 2015 at 11:43, Mark Kettenis mark.kette...@xs4all.nl wrote:
Date: Thu, 7 May 2015 20:58:53 +0200
From: Mike Belopuhov m...@belopuhov.com
As I've pointed out before, on panic we can be running on any
CPU and our disk controller's interrupts can interrupt on the
other one. Since
On 05/08/15 12:30, Stuart Henderson wrote:
On 2015/05/08 12:12, Gilles Chehade wrote:
I think the proper fix is to reconsider the prepend in the mda case.
If procmail requires custom config, so be it.
Given that people aren't meant to be using procmail anyway, this sounds good
to me.
I
Unfortunately, in 2 cases this diff will increase needed variable
for non existing files too. This is the fixed version.
Index: sys/kern/kern_sysctl.c
===
RCS file: /cvs/src/sys/kern/kern_sysctl.c,v
retrieving revision 1.284
diff -u
On Fri, 08 May 2015 12:12:46 +0200, Gilles Chehade wrote:
Now the problem is that if the .forward references a |/path it forks
a mda (which prepends From), and if mda is sendmail then... it ends up
calling mail.local which prepends From again.
I think the proper fix is to reconsider the
On Fri, May 08, 2015 at 12:34 +0200, Mike Belopuhov wrote:
I think tsleep(9) and msleep(9) need to release and re-acquire the
kernel lock in the cold || panicstr case.
Well, it's not hard to do really, but...
We might need this for
handling interrupts during autoconf as soon as we
Date: Fri, 8 May 2015 20:15:58 +0200
From: Mike Belopuhov m...@belopuhov.com
On Fri, May 08, 2015 at 12:34 +0200, Mike Belopuhov wrote:
I think tsleep(9) and msleep(9) need to release and re-acquire the
kernel lock in the cold || panicstr case.
Well, it's not hard to do really,
I have questions about sysctl_file():
1. Looks like sysctl_file() should do the same things for KERN_FILE_BYPID and
KERN_FILE_BYUID cases. But pr-ps_textvp (vnode of executable) will be copied
for KERN_FILE_BYPID case only. Is this copying missing for KERN_FILE_BYUID?
2. (arg -1) check looks be
From: Mike Belopuhov m...@belopuhov.com
Date: Fri, 8 May 2015 13:53:56 +0200
On 8 May 2015 at 12:37, Martin Pieuchot m...@openbsd.org wrote:
On 07/05/15(Thu) 20:58, Mike Belopuhov wrote:
As I've pointed out before, on panic we can be running on any
CPU and our disk controller's
On Fri, May 08, 2015 at 08:27:55PM -0500, Tim Chase wrote:
On 2015-05-08 14:30, Todd C. Miller wrote:
Solaris and Linux also produce x\ny\nz\n so that is likely the
expected behavior.
I bumped against it while testing some scripts across various
platforms where I saw Linux FreeBSD
On 8 May 2015 at 04:51, Masao Uebayashi uebay...@tombiinc.com wrote:
By doing complex VFS shutdown operation, the system's memory image will
be modified a lot since a panic was triggered. I'd totally skip
vfs_shutdown() after a panic [1], then do the best to dump a kernel core
for analysis.
15 matches
Mail list logo
