On 2014/03/29 23:42, Warner Losh wrote:
On Mar 29, 2014, at 6:31 AM, David Xu 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
On Mar 29, 2014, at 6:31 AM, David Xu 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). In
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 k
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
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 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,
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: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
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
--- a/sys/ke
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 T
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 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
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 Guzi
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 Guzi
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 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, Ma
On Thu, Mar 27, 2014 at 11:08:34AM -0600, Warner Losh wrote:
>
> On Mar 27, 2014, at 2:37 AM, 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. plea
On Mar 27, 2014, at 2:37 AM, 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 solut
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 wro
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 proce
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 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 rather
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 exp
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
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:
head/sys/kern/sub
25 matches
Mail list logo
