On 29 Mar, Mateusz Guzik wrote:
On Sat, Mar 29, 2014 at 11:52:09AM +0800, David Xu wrote:
If fsetown handling like this is insecure this would bite us in that
scenario (and few others). In short, if we can avoid giving another way
to corrupt stuff in the kernel to userspace, we should.
I
On 2014/03/29 15:52, Don Lewis wrote:
On 29 Mar, Mateusz Guzik wrote:
On Sat, Mar 29, 2014 at 11:52:09AM +0800, David Xu wrote:
If fsetown handling like this is insecure this would bite us in that
scenario (and few others). In short, if we can avoid giving another way
to corrupt stuff in the
On Mar 29, 2014, at 6:31 AM, David Xu davi...@freebsd.org wrote:
On 2014/03/29 15:52, Don Lewis wrote:
On 29 Mar, Mateusz Guzik wrote:
On Sat, Mar 29, 2014 at 11:52:09AM +0800, David Xu wrote:
If fsetown handling like this is insecure this would bite us in that
scenario (and few others).
On 2014/03/29 23:42, Warner Losh wrote:
On Mar 29, 2014, at 6:31 AM, David Xu davi...@freebsd.org wrote:
On 2014/03/29 15:52, Don Lewis wrote:
On 29 Mar, Mateusz Guzik wrote:
On Sat, Mar 29, 2014 at 11:52:09AM +0800, David Xu wrote:
If fsetown handling like this is insecure this would bite
On 2014/03/28 06:31, Don Lewis wrote:
On 27 Mar, Konstantin Belousov wrote:
On Thu, Mar 27, 2014 at 04:05:12PM +0100, Mateusz Guzik wrote:
On Thu, Mar 27, 2014 at 03:58:19PM +0100, Mateusz Guzik wrote:
On Thu, Mar 27, 2014 at 04:46:57PM +0800, David Xu wrote:
On 2014/03/27 16:37, Mateusz
On 28 Mar, David Xu wrote:
On 2014/03/28 06:31, Don Lewis wrote:
On 27 Mar, Konstantin Belousov wrote:
On Thu, Mar 27, 2014 at 04:05:12PM +0100, Mateusz Guzik wrote:
On Thu, Mar 27, 2014 at 03:58:19PM +0100, Mateusz Guzik wrote:
On Thu, Mar 27, 2014 at 04:46:57PM +0800, David Xu wrote:
On
On Fri, Mar 28, 2014 at 09:13:20AM -0700, Don Lewis wrote:
On 28 Mar, David Xu wrote:
I have tweaked it a bit, is this okay ?
# HG changeset patch
# Parent 53b614ff2cae108f27e4475989d3a86997017268
diff -r 53b614ff2cae sys/kern/subr_bus.c
--- a/sys/kern/subr_bus.c Thu Mar 27
On 2014/03/29 00:13, Don Lewis wrote:
On 28 Mar, David Xu wrote:
On 2014/03/28 06:31, Don Lewis wrote:
On 27 Mar, Konstantin Belousov wrote:
On Thu, Mar 27, 2014 at 04:05:12PM +0100, Mateusz Guzik wrote:
On Thu, Mar 27, 2014 at 03:58:19PM +0100, Mateusz Guzik wrote:
On Thu, Mar 27, 2014 at
On 2014/03/29 10:56, Mateusz Guzik wrote:
On Fri, Mar 28, 2014 at 09:13:20AM -0700, Don Lewis wrote:
On 28 Mar, David Xu wrote:
I have tweaked it a bit, is this okay ?
# HG changeset patch
# Parent 53b614ff2cae108f27e4475989d3a86997017268
diff -r 53b614ff2cae sys/kern/subr_bus.c
---
On Sat, Mar 29, 2014 at 11:09:34AM +0800, David Xu wrote:
On 2014/03/29 10:56, Mateusz Guzik wrote:
But this patch would mean that current consumers (if any) would break -
just calling FIOASYNC would not result in receiving SIGIO.
The old behavior is inconsistent with other piece of code in
On 2014/03/29 11:25, Mateusz Guzik wrote:
On Sat, Mar 29, 2014 at 11:09:34AM +0800, David Xu wrote:
On 2014/03/29 10:56, Mateusz Guzik wrote:
But this patch would mean that current consumers (if any) would break -
just calling FIOASYNC would not result in receiving SIGIO.
The old behavior is
On Sat, Mar 29, 2014 at 11:52:09AM +0800, David Xu wrote:
If fsetown handling like this is insecure this would bite us in that
scenario (and few others). In short, if we can avoid giving another way
to corrupt stuff in the kernel to userspace, we should.
I can not see what you said, where is
On 2014/03/29 12:14, Mateusz Guzik wrote:
I asked if multpiple concurrent calls to fsetown(.., pointer) could
result in some corruption in the kernel - if they could, we would have
a problem in the future. I decided to read the code once more and
fsetown seems to be safe in this regard after
On 2014/03/26 07:30, Mateusz Guzik wrote:
Author: mjg
Date: Tue Mar 25 23:30:35 2014
New Revision: 263755
URL: http://svnweb.freebsd.org/changeset/base/263755
Log:
Document a known problem with handling the process intended to receive
SIGIO in /dev/devctl.
Suggested by:adrian
On Thu, Mar 27, 2014 at 03:45:17PM +0800, David Xu wrote:
I think the async process pointer can be cleared when a process exits
by registering an event handler. please see attached patch.
Sure, but I'm not very fond of this solution.
This is a rather obscure bug you wont hit unless you
On 2014/03/27 16:37, Mateusz Guzik wrote:
On Thu, Mar 27, 2014 at 03:45:17PM +0800, David Xu wrote:
I think the async process pointer can be cleared when a process exits
by registering an event handler. please see attached patch.
Sure, but I'm not very fond of this solution.
This is a
On Thu, Mar 27, 2014 at 04:46:57PM +0800, David Xu wrote:
On 2014/03/27 16:37, Mateusz Guzik wrote:
On Thu, Mar 27, 2014 at 03:45:17PM +0800, David Xu wrote:
I think the async process pointer can be cleared when a process exits
by registering an event handler. please see attached patch.
On Thu, Mar 27, 2014 at 03:58:19PM +0100, Mateusz Guzik wrote:
On Thu, Mar 27, 2014 at 04:46:57PM +0800, David Xu wrote:
On 2014/03/27 16:37, Mateusz Guzik wrote:
On Thu, Mar 27, 2014 at 03:45:17PM +0800, David Xu wrote:
I think the async process pointer can be cleared when a process exits
On Thu, Mar 27, 2014 at 04:05:12PM +0100, Mateusz Guzik wrote:
On Thu, Mar 27, 2014 at 03:58:19PM +0100, Mateusz Guzik wrote:
On Thu, Mar 27, 2014 at 04:46:57PM +0800, David Xu wrote:
On 2014/03/27 16:37, Mateusz Guzik wrote:
On Thu, Mar 27, 2014 at 03:45:17PM +0800, David Xu wrote:
I
On Mar 27, 2014, at 2:37 AM, Mateusz Guzik mjgu...@gmail.com wrote:
On Thu, Mar 27, 2014 at 03:45:17PM +0800, David Xu wrote:
I think the async process pointer can be cleared when a process exits
by registering an event handler. please see attached patch.
Sure, but I'm not very fond of
On Thu, Mar 27, 2014 at 11:08:34AM -0600, Warner Losh wrote:
On Mar 27, 2014, at 2:37 AM, Mateusz Guzik mjgu...@gmail.com wrote:
On Thu, Mar 27, 2014 at 03:45:17PM +0800, David Xu wrote:
I think the async process pointer can be cleared when a process exits
by registering an event
On 27 Mar, Konstantin Belousov wrote:
On Thu, Mar 27, 2014 at 04:05:12PM +0100, Mateusz Guzik wrote:
On Thu, Mar 27, 2014 at 03:58:19PM +0100, Mateusz Guzik wrote:
On Thu, Mar 27, 2014 at 04:46:57PM +0800, David Xu wrote:
On 2014/03/27 16:37, Mateusz Guzik wrote:
On Thu, Mar 27, 2014 at
On 2014/03/27 22:58, Mateusz Guzik wrote:
On Thu, Mar 27, 2014 at 04:46:57PM +0800, David Xu wrote:
On 2014/03/27 16:37, Mateusz Guzik wrote:
On Thu, Mar 27, 2014 at 03:45:17PM +0800, David Xu wrote:
I think the async process pointer can be cleared when a process exits
by registering an event
On 2014/03/28 06:31, Don Lewis wrote:
On 27 Mar, Konstantin Belousov wrote:
On Thu, Mar 27, 2014 at 04:05:12PM +0100, Mateusz Guzik wrote:
On Thu, Mar 27, 2014 at 03:58:19PM +0100, Mateusz Guzik wrote:
On Thu, Mar 27, 2014 at 04:46:57PM +0800, David Xu wrote:
On 2014/03/27 16:37, Mateusz
Author: mjg
Date: Tue Mar 25 23:30:35 2014
New Revision: 263755
URL: http://svnweb.freebsd.org/changeset/base/263755
Log:
Document a known problem with handling the process intended to receive
SIGIO in /dev/devctl.
Suggested by: adrian
MFC after:6 days
Modified:
25 matches
Mail list logo
