Here's what I think is a better patch. Or maybe just simpler.
However, I'm still unsure what the effect of this patch on
file descriptor passing might be. Reading the prior code,
and the parallel portions/comments in unix_dgram_recvmsg(),
it looks like there's been a lot of uncertainty as to
Here's what I think is a better patch. Or maybe just simpler.
However, I'm still unsure what the effect of this patch on
file descriptor passing might be. Reading the prior code,
and the parallel portions/comments in unix_dgram_recvmsg(),
it looks like there's been a lot of uncertainty as to
the core infrastructure is doing that
* for all net proto families now (2.5.69+)
+ * Brent Casavant : SOCK_STREAM MSG_PEEK should peek
+ * far enough ahead to satisfy th
ream_recvmsg(),
however once I figure that out a patch should be forthcoming.
Brent
--
Brent Casavant All music is folk music. I ain't
[EMAIL PROTECTED]never heard a horse sing a song.
Silicon Graphics, Inc.-- Louis Armstrong
--
To
noted in the comments in the
provided test program.
Brent
--
Brent Casavant All music is folk music. I ain't
[EMAIL PROTECTED]never heard a horse sing a song.
Silicon Graphics, Inc.-- Louis Armstrong
--
To unsubscribe from th
in the
provided test program.
Brent
--
Brent Casavant All music is folk music. I ain't
[EMAIL PROTECTED]never heard a horse sing a song.
Silicon Graphics, Inc.-- Louis Armstrong
--
To unsubscribe from this list: send the line
once I figure that out a patch should be forthcoming.
Brent
--
Brent Casavant All music is folk music. I ain't
[EMAIL PROTECTED]never heard a horse sing a song.
Silicon Graphics, Inc.-- Louis Armstrong
--
To unsubscribe from
infrastructure is doing that
* for all net proto families now (2.5.69+)
+ * Brent Casavant : SOCK_STREAM MSG_PEEK should peek
+ * far enough ahead to satisfy the request
+ * rather
On Tue, 8 Jan 2008, Tom Spink wrote:
> Ach. I *am* missing something... and what I'm missing is my
> understanding of the sendmsg and recvmsg calls.
No problem. We all have those days. :)
Brent
--
Brent Casavant All music is folk music. I ain't
[EMAIL PRO
to flush a bug out of hiding, right? ;)
Brent
--
Brent Casavant All music is folk music. I ain't
[EMAIL PROTECTED]never heard a horse sing a song.
Silicon Graphics, Inc.-- Louis Armstrong
--
To unsubscribe from this list: send
v[i].iov_len = messages[i].length;
The entire "struct sockmsg" is sent across the socket, so the first
size_t in each message contains the length of the entire message
(including the size_t). This size gets picked up at the
recv(...,MSG_PEEK) line in do_consumer().
Thanks,
Brent
--
B
cer failed as a result of the consumer
closing the socket, not the other way around.
Thanks,
Brent Casavant
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#define SOCKNAME "/tmp/peektest.sock"
#define MAXLEN 2048
#defi
as a result of the consumer
closing the socket, not the other way around.
Thanks,
Brent Casavant
#include errno.h
#include stdlib.h
#include stdio.h
#include string.h
#include unistd.h
#include sys/ioctl.h
#include sys/types.h
#include sys/socket.h
#include sys/stat.h
#include sys/time.h
#include sys
--
Brent Casavant All music is folk music. I ain't
[EMAIL PROTECTED]never heard a horse sing a song.
Silicon Graphics, Inc.-- Louis Armstrong
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body
].iov_len = messages[i].length;
The entire struct sockmsg is sent across the socket, so the first
size_t in each message contains the length of the entire message
(including the size_t). This size gets picked up at the
recv(...,MSG_PEEK) line in do_consumer().
Thanks,
Brent
--
Brent Casavant
On Tue, 8 Jan 2008, Tom Spink wrote:
Ach. I *am* missing something... and what I'm missing is my
understanding of the sendmsg and recvmsg calls.
No problem. We all have those days. :)
Brent
--
Brent Casavant All music is folk music. I ain't
[EMAIL PROTECTED
On Thu, 13 Sep 2007, Gabor Gombas wrote:
> On Wed, Sep 12, 2007 at 03:37:44PM -0500, Brent Casavant wrote:
>
> > System V shmem is right out because the IPC key is publicly
> > visible and there is no combination of permissions which
> > will allow sharing the segment wit
On Thu, 13 Sep 2007, Gabor Gombas wrote:
On Wed, Sep 12, 2007 at 03:37:44PM -0500, Brent Casavant wrote:
System V shmem is right out because the IPC key is publicly
visible and there is no combination of permissions which
will allow sharing the segment with just one other process
On Wed, 12 Sep 2007, Brent Casavant wrote:
> On Wed, 12 Sep 2007, Al Viro wrote:
>
> > Give me a break. And learn about ptrace(2). This "unlinking" bullshit
> > buys you zero additional security, both for /proc/*/mem and for /dev/mem
> > (see mknod(2)
On Wed, 12 Sep 2007, Al Viro wrote:
> On Wed, Sep 12, 2007 at 05:44:30PM -0500, Brent Casavant wrote:
>
> > P.S. By the way, there doesn't seem to be a way to remove /proc/#/mem
> > files. That might be an additional nicety -- programs worried about
> > be
On Wed, 12 Sep 2007, Andreas Schwab wrote:
> Brent Casavant <[EMAIL PROTECTED]> writes:
>
> > I could mmap a temporary tmpfs file (tmpfs so that if there is a
> > machine crash no sensitive data persists) which is created with
> > permissions of 0, immediatel
On Wed, 12 Sep 2007, H. Peter Anvin wrote:
> Brent Casavant wrote:
> > http://marc.info/?l=linux-kernel=93032806224160=2
>
> This link talks about file flags handling. I don't see the relevance to
> this problem at all. However, this is a very long thread, so if t
?
Brent
--
Brent Casavant All music is folk music. I ain't
[EMAIL PROTECTED]never heard a horse sing a song.
Silicon Graphics, Inc.-- Louis Armstrong
-
To unsubscribe from this list: send the line "unsubscribe linux-k
?
Brent
--
Brent Casavant All music is folk music. I ain't
[EMAIL PROTECTED]never heard a horse sing a song.
Silicon Graphics, Inc.-- Louis Armstrong
-
To unsubscribe from this list: send the line unsubscribe linux-kernel
On Wed, 12 Sep 2007, H. Peter Anvin wrote:
Brent Casavant wrote:
http://marc.info/?l=linux-kernelm=93032806224160w=2
This link talks about file flags handling. I don't see the relevance to
this problem at all. However, this is a very long thread, so if there
is anything specific
On Wed, 12 Sep 2007, Andreas Schwab wrote:
Brent Casavant [EMAIL PROTECTED] writes:
I could mmap a temporary tmpfs file (tmpfs so that if there is a
machine crash no sensitive data persists) which is created with
permissions of 0, immediately unlink it, and pass the file
descriptor
On Wed, 12 Sep 2007, Al Viro wrote:
On Wed, Sep 12, 2007 at 05:44:30PM -0500, Brent Casavant wrote:
P.S. By the way, there doesn't seem to be a way to remove /proc/#/mem
files. That might be an additional nicety -- programs worried about
being snooped could unlink their own
On Wed, 12 Sep 2007, Brent Casavant wrote:
On Wed, 12 Sep 2007, Al Viro wrote:
Give me a break. And learn about ptrace(2). This unlinking bullshit
buys you zero additional security, both for /proc/*/mem and for /dev/mem
(see mknod(2)).
My (limited) understanding of ptrace
The SGI IOC3 and IOC4 PCI devices implement memory space apertures, not
I/O space apertures. Use the appropriate region management functions.
Signed-off-by: Brent Casavant <[EMAIL PROTECTED]>
---
I'd appreciate a review/ack by the MIPS folks, just in case I'm unaware of
something s
The SGI IOC3 and IOC4 PCI devices implement memory space apertures, not
I/O space apertures. Use the appropriate region management functions.
Signed-off-by: Brent Casavant [EMAIL PROTECTED]
---
I'd appreciate a review/ack by the MIPS folks, just in case I'm unaware of
something special on those
erformance burden to pay when almost no drivers currently benefit
from it.
Otherwise, I also wonder if you have any plans to handle similar
errors experienced under device-initiated DMA, or asynchronous I/O.
It's not clear that there's sufficient infrastructure in the current
patches to adequately h
sufficient infrastructure in the current
patches to adequately handle those situations.
Thank you,
Brent Casavant
--
Brent Casavant If you had nothing to fear,
[EMAIL PROTECTED]how then could you be brave?
Silicon Graphics, Inc
would become
>
> struct extint_device *ed = to_extint_device(filp->f_dentry->d_inode);
OK, no problem, since file_to_extint_device() went away anyway.
Brent
--
Brent Casavant If you had nothing to fear,
[EMAIL PROTECTED]how then cou
struct extint_device *ed = to_extint_device(filp-f_dentry-d_inode);
OK, no problem, since file_to_extint_device() went away anyway.
Brent
--
Brent Casavant If you had nothing to fear,
[EMAIL PROTECTED]how then could you be brave?
Silicon
return -ENXIO;
> ied = extint_get_devdata(ed);
>
> but I don't understand how it can happen anyway. ->remove shoould
> never be called unless ->probe initialized the device fully and
> returned 0
It was just one of many things where I coded defensiv
a lot in linux, unlike other
> unix variants.
Not that it matters anymore, but any ideas for better terminology?
> > +static inline void* extint_get_devdata(const struct extint_device *ed) {
> > + return ed->devdata;
> > +}
>
> minimal style nipick, please put th
extint_device *ed) {
+ return ed-devdata;
+}
minimal style nipick, please put the opening brace on a line of it's own.
Just a goof on my part. Thanks for catching this.
Brent
--
Brent Casavant If you had nothing to fear,
[EMAIL PROTECTED]how
shoould
never be called unless -probe initialized the device fully and
returned 0
It was just one of many things where I coded defensively and intended
to revisit it later. Unfortunately the revisit never took place.
Thanks for the catch -- fixed now.
Thanks,
Brent
--
Brent Casavant
for this on the horizon, but it's not
much more than a tiny indistiguishable dot. I'll have more info in a
day or two. I'll also use that time to fix up the things that
Christoph Hellwig noticed.
Brent
--
Brent Casavant If you had nothing to fear,
[EMAIL PROTECTED]
, and do away with the abstraction layer.
However, that leads to code duplication, which has its own downfalls.
Personally, if I had to pick one poison or the other I'd take
overengineering over maintaining divergent implementations, but the
patch apparently made my predeliction obvious :).
Th
, that leads to code duplication, which has its own downfalls.
Personally, if I had to pick one poison or the other I'd take
overengineering over maintaining divergent implementations, but the
patch apparently made my predeliction obvious :).
Thanks,
Brent Casavant
--
Brent Casavant
, but it's not
much more than a tiny indistiguishable dot. I'll have more info in a
day or two. I'll also use that time to fix up the things that
Christoph Hellwig noticed.
Brent
--
Brent Casavant If you had nothing to fear,
[EMAIL PROTECTED]how
/write system call overhead which is
necessary when going through the abstraction layer class attribute
files.
Signed-off-by: Brent Casavant <[EMAIL PROTECTED]>
Documentation/sgi-ioc4.txt | 177
arch/ia64/configs/sn2_defconfig |1
arch/ia64/defconfig |1
d
bstraction layer provides a mechanism to insulate applications from
the details of the capabilities and mechanisms of a particular external
interrupt device. It also greatly simplifies low-level drivers.
Signed-off-by: Brent Casavant <[EMAIL PROTECTED]>
Documentation/extint.t
s will add their
own low-level external interrupt drivers.
And while I mentioned real time as the primary application of external
interrupts, I'm sure there are other creative uses to be found. My
imagination, however, is limited. :)
Thanks,
Brent Casavant
--
Brent Casavant
their
own low-level external interrupt drivers.
And while I mentioned real time as the primary application of external
interrupts, I'm sure there are other creative uses to be found. My
imagination, however, is limited. :)
Thanks,
Brent Casavant
--
Brent Casavant If you had
/write system call overhead which is
necessary when going through the abstraction layer class attribute
files.
Signed-off-by: Brent Casavant [EMAIL PROTECTED]
Documentation/sgi-ioc4.txt | 177
arch/ia64/configs/sn2_defconfig |1
arch/ia64/defconfig |1
drivers/char
provides a mechanism to insulate applications from
the details of the capabilities and mechanisms of a particular external
interrupt device. It also greatly simplifies low-level drivers.
Signed-off-by: Brent Casavant [EMAIL PROTECTED]
Documentation/extint.txt| 431
/write system call overhead which is
necessary when going through the abstraction layer class attribute
files.
Signed-off-by: Brent Casavant <[EMAIL PROTECTED]>
Documentation/sgi-ioc4.txt | 177
arch/ia64/configs/sn2_defconfig |1
arch/ia64/defconfig |1
d
r creative uses to be found. My
imagination, however, is limited. :)
Brent Casavant
--
Brent Casavant If you had nothing to fear,
[EMAIL PROTECTED]how then could you be brave?
Silicon Graphics, Inc.-- Queen Dama, Source Wars
-
To u
bstraction layer provides a mechanism to insulate applications from
the details of the capabilities and mechanisms of a particular external
interrupt device. It also greatly simplifies low-level drivers.
Signed-off-by: Brent Casavant <[EMAIL PROTECTED]>
Documentation/extint.t
provides a mechanism to insulate applications from
the details of the capabilities and mechanisms of a particular external
interrupt device. It also greatly simplifies low-level drivers.
Signed-off-by: Brent Casavant [EMAIL PROTECTED]
Documentation/extint.txt| 431
to be found. My
imagination, however, is limited. :)
Brent Casavant
--
Brent Casavant If you had nothing to fear,
[EMAIL PROTECTED]how then could you be brave?
Silicon Graphics, Inc.-- Queen Dama, Source Wars
-
To unsubscribe
/write system call overhead which is
necessary when going through the abstraction layer class attribute
files.
Signed-off-by: Brent Casavant [EMAIL PROTECTED]
Documentation/sgi-ioc4.txt | 177
arch/ia64/configs/sn2_defconfig |1
arch/ia64/defconfig |1
drivers/char
as I haven't
determined the technical reason behind the current one-shot design.
Maybe it could be as simple as using another currently unused call
such as read(2) to reset the fd? But I suspect it's harder than
that, otherwise it wouldn't be a one-shot in the first place.
Brent
--
Bren
be as simple as using another currently unused call
such as read(2) to reset the fd? But I suspect it's harder than
that, otherwise it wouldn't be a one-shot in the first place.
Brent
--
Brent Casavant If you had nothing to fear,
[EMAIL PROTECTED]how
56 matches
Mail list logo
