"Michael K. Edwards" <[EMAIL PROTECTED]> writes:
> Thanks Alan, this is really helpful -- I'll see if I can figure out
> kprobes. It is not immediately obvious to me how to use them to
> trace function calls in userspace, but I'll read up.
kprobes does not work with userspace. We in systemtap l
> > gdbstubs is also not terribly SMP aware and for low level work its
> > sometimes easier to have on gdb per processor if you can get your brain
> > around it.
>
> That's a trick I don't know. What do you do, fire up the target
> process, put the whole thing to sleep with a SIGSTOP, and then at
Thanks Alan, this is really helpful -- I'll see if I can figure out
kprobes. It is not immediately obvious to me how to use them to trace
function calls in userspace, but I'll read up.
On 3/13/07, Alan Cox <[EMAIL PROTECTED]> wrote:
> But on that note -- do you have any idea how one might get l
In case anyone cares, this is a snippet of my work-in-progress
read_write.c illustrating how I might handle f_pos. Can anyone point
me to data showing whether it's worth avoiding the spinlock when the
"struct file" is not shared between threads? (In my world,
correctness comes before code-bummin
On 3/13/07, Christoph Hellwig <[EMAIL PROTECTED]> wrote:
Michael, please stop spreading this utter bullshit _now_. You're so
full of half-knowledge that it's not funny anymore, and you try
to insult people knowing a few magniutes more than you left and right.
Thank you Christoph for that infor
Michael, please stop spreading this utter bullshit _now_. You're so
full of half-knowledge that it's not funny anymore, and you try
to insult people knowing a few magniutes more than you left and right.
Can you please select a different mailinglist for your trolling?
-
To unsubscribe from this
Clearly f_pos atomicity has been handled differently in the not-so-distant past:
http://www.mail-archive.com/linux-fsdevel@vger.kernel.org/msg01628.html
And equally clearly the current generic_file_llseek semantics are
erroneous for large offsets, and we shouldn't be taking the inode
mutex in an
On 3/13/07, David Miller <[EMAIL PROTECTED]> wrote:
You're not even safe over standard output, simply run the program over
ssh and you suddenly have socket semantics to deal with.
I'm intimately familiar with this one. Easily worked around by piping
the output through cat or tee. Not that one
On Tue, 2007-03-13 at 02:24 +, Alan Cox wrote:
> > purports to handle short writes but has never been exercised is
> > arguably worse than code that simply bombs on short write. So if I
> > can't shim in an induce-short-writes-randomly-on-purpose mechanism
> > during development, I don't want
> But on that note -- do you have any idea how one might get ltrace to
> work on a multi-threaded program, or how one might enhance it to
> instrument function calls from one shared library to another? Or
I don't know a vast amount about ARM ELF user space so no.
> better yet, can you advise me
From: "Michael K. Edwards" <[EMAIL PROTECTED]>
Date: Mon, 12 Mar 2007 23:25:48 -0800
> Quality means the devices you ship now keep working in the field, and
> the probable cost of later rework if the requirements change does not
> exceed the opportunity cost of over-engineering up front. Economy
On 3/12/07, Alan Cox <[EMAIL PROTECTED]> wrote:
> Writing to a file from multiple processes is not usually the problem.
> Writing to a common "struct file" from multiple threads is.
Not normally because POSIX sensibly invented pread/pwrite. Forgot
preadv/pwritev but they did the basics and end o
> Writing to a file from multiple processes is not usually the problem.
> Writing to a common "struct file" from multiple threads is.
Not normally because POSIX sensibly invented pread/pwrite. Forgot
preadv/pwritev but they did the basics and end of problem
> So what? My products are shipping _n
On 3/12/07, Bodo Eggert <[EMAIL PROTECTED]> wrote:
On Mon, 12 Mar 2007, Michael K. Edwards wrote:
> That's fine when you're doing integration test, and should probably be
> the default during development. But if the race is first exposed in
> the field, or if the developer is trying to concentra
On Mon, 12 Mar 2007, Michael K. Edwards wrote:
> On 3/12/07, Bodo Eggert <[EMAIL PROTECTED]> wrote:
> > Michael K. Edwards <[EMAIL PROTECTED]> wrote:
> > > Actually, I think it would make the kernel (negligibly) faster to bump
> > > f_pos before the vfs_write() call.
> >
> > This is a security ris
On 3/12/07, Bodo Eggert <[EMAIL PROTECTED]> wrote:
Michael K. Edwards <[EMAIL PROTECTED]> wrote:
> Actually, I think it would make the kernel (negligibly) faster to bump
> f_pos before the vfs_write() call.
This is a security risk.
other process:
unlink(secrest_file)
Thread 1:
Michael K. Edwards <[EMAIL PROTECTED]> wrote:
> On 3/8/07, Eric Dumazet <[EMAIL PROTECTED]> wrote:
>> Absolutely not. We dont want to slow down kernel 'just in case a fool might
>> want to do crazy things'
>
> Actually, I think it would make the kernel (negligibly) faster to bump
> f_pos before t
I apologize for throwing around words like "stupid". Whether or not
the current semantics can be improved, that's not a constructive way
to characterize them. I'm sorry.
As three people have ably pointed out :-), the particular case of a
pipe/FIFO isn't seekable and doesn't need the f_pos membe
On Fri, Mar 09, 2007 at 04:19:55AM -0800, Michael K. Edwards wrote:
> On 3/8/07, Benjamin LaHaise <[EMAIL PROTECTED]> wrote:
> >Any number of things can cause a short write to occur, and rewinding the
> >file position after the fact is just as bad. A sane app has to either
> >serialise the writes
On Friday 09 March 2007 13:19, Michael K. Edwards wrote:
> On 3/8/07, Benjamin LaHaise <[EMAIL PROTECTED]> wrote:
> > Any number of things can cause a short write to occur, and rewinding the
> > file position after the fact is just as bad. A sane app has to either
> > serialise the writes itself o
> 1003.1 unless O_NONBLOCK is set. (Not that f_pos is interesting on a
> pipe except as a "bytes sent" indicator -- and in the multi-threaded
f_pos is undefined on a FIFO or similar object.
> As to what a "sane app" has to do: it's just not that unusual to write
> application code that treats a
On 3/8/07, Benjamin LaHaise <[EMAIL PROTECTED]> wrote:
Any number of things can cause a short write to occur, and rewinding the
file position after the fact is just as bad. A sane app has to either
serialise the writes itself or use a thread safe API like pwrite().
Not on a pipe/FIFO. Short w
On 3/8/07, Eric Dumazet <[EMAIL PROTECTED]> wrote:
Dont even try, you *cannot* do that, without breaking the standards, or
without a performance drop.
The only safe way would be to lock the file during the whole read()/write()
syscall, and we dont want this (this would be more expensive than cur
Michael K. Edwards a écrit :
On 3/8/07, Eric Dumazet <[EMAIL PROTECTED]> wrote:
Absolutely not. We dont want to slow down kernel 'just in case a fool
might
want to do crazy things'
Actually, I think it would make the kernel (negligibly) faster to bump
f_pos before the vfs_write() call. Unles
> Actually, I think it would make the kernel (negligibly) faster to bump
> f_pos before the vfs_write() call. Unless fget_light sets fput_needed
> or the write doesn't complete cleanly, you won't have to touch the
> file table entry again after vfs_write() returns. You can adjust
Any number of t
On 3/8/07, Eric Dumazet <[EMAIL PROTECTED]> wrote:
Absolutely not. We dont want to slow down kernel 'just in case a fool might
want to do crazy things'
Actually, I think it would make the kernel (negligibly) faster to bump
f_pos before the vfs_write() call. Unless fget_light sets fput_needed
o
Michael K. Edwards a écrit :
On 3/8/07, Eric Dumazet <[EMAIL PROTECTED]> wrote:
Nothing in the manuals says that write() on same fd should be non racy
: In
particular file pos might be undefined. There is a reason pwrite()
exists.
Kernel doesnt have to enforce thread safety as standard is qui
On 3/8/07, Eric Dumazet <[EMAIL PROTECTED]> wrote:
Nothing in the manuals says that write() on same fd should be non racy : In
particular file pos might be undefined. There is a reason pwrite() exists.
Kernel doesnt have to enforce thread safety as standard is quite clear.
I know the standard
Michael K. Edwards a écrit :
from sys_write():
file = fget_light(fd, &fput_needed);
if (file) {
loff_t pos = file_pos_read(file);
ret = vfs_write(file, buf, count, &pos);
file_pos_write(file, pos);
fput_light(file, fput_ne
> Surely that's racy when two threads write to the same fd and the first
> vfs_write call blocks or is preempted. Or does fget_light take some
> per-file lock that I'm not seeing?
I think you are making assumptions about file position behaviour that are
simply not guaranteed in the standards docu
from sys_write():
file = fget_light(fd, &fput_needed);
if (file) {
loff_t pos = file_pos_read(file);
ret = vfs_write(file, buf, count, &pos);
file_pos_write(file, pos);
fput_light(file, fput_needed);
}
Surely that's
31 matches
Mail list logo