Steven Rostedt wrote:
> > Yes, and I think if you do use two 16-bit nops, you can even get rid of all
> > the intermediate `sync' operations (I guess you might want one at the end if
> > you want the call to become visible at a particular point).
>
> Wont work. We are replacing a 32bit call with
Steven Rostedt wrote:
Yes, and I think if you do use two 16-bit nops, you can even get rid of all
the intermediate `sync' operations (I guess you might want one at the end if
you want the call to become visible at a particular point).
Wont work. We are replacing a 32bit call with a nop.
Kent Overstreet wrote:
> On Thu, Nov 29, 2012 at 09:54:47PM +0100, Andi Kleen wrote:
> > > > The regular atomic_t is limited in ways that you are not.
> > > > See my original mail.
> > >
> > > I don't follow, can you explain?
> >
> > For most cases the reference count is tied to some object,
Kent Overstreet wrote:
On Thu, Nov 29, 2012 at 09:54:47PM +0100, Andi Kleen wrote:
The regular atomic_t is limited in ways that you are not.
See my original mail.
I don't follow, can you explain?
For most cases the reference count is tied to some object, which are
naturally
Paul E. McKenney wrote:
> > Does some version of gcc, under the options which we insist upon,
> > make such optimizations on any of the architectures which we support?
>
> Pretty much any production-quality compiler will do double-fetch
> and old-value-reuse optimizations, the former especially
Paul E. McKenney wrote:
Does some version of gcc, under the options which we insist upon,
make such optimizations on any of the architectures which we support?
Pretty much any production-quality compiler will do double-fetch
and old-value-reuse optimizations, the former especially on
Jörn Engel wrote:
> On Tue, 26 February 2008 15:28:10 +0000, Jamie Lokier wrote:
> >
> > > One interesting aspect of this comes with COW filesystems like btrfs or
> > > logfs. Writing out data pages is not sufficient, because those will get
> > > lost unless t
Jeff Garzik wrote:
> Nick Piggin wrote:
> >Anyway, the idea of making fsync/fdatasync etc. safe by default is
> >a good idea IMO, and is a bad bug that we don't do that :(
>
> Agreed... it's also disappointing that [unless I'm mistaken] you have
> to hack each filesystem to support barriers.
>
Ric Wheeler wrote:
> >>I was surprised that fsync() doesn't do this already. There was a lot
> >>of effort put into block I/O write barriers during 2.5, so that
> >>journalling filesystems can force correct write ordering, using disk
> >>flush cache commands.
> >>
> >>After all that effort, I was
Jörn Engel wrote:
> On Tue, 26 February 2008 20:16:11 +1100, Nick Piggin wrote:
> > Yeah, sync_file_range has slightly unusual semantics and introduce
> > the new concept, "writeout", to userspace (does "writeout" include
> > "in drive cache"? the kernel doesn't think so, but the only way to
> >
Jörn Engel wrote:
> On Tue, 26 February 2008 20:16:11 +1100, Nick Piggin wrote:
> >
> > Yeah, sync_file_range has slightly unusual semantics and introduce
> > the new concept, "writeout", to userspace (does "writeout" include
> > "in drive cache"? the kernel doesn't think so, but the only way to
Jeff Garzik wrote:
> [snip huge long proposal]
>
> Rather than invent new APIs, we should fix the existing ones to _really_
> flush data to physical media.
Btw, one reason for the length is the current block request API isn't
sufficient even to make fsync() durable with _no_ new APIs.
It
Andrew Morton wrote:
> On Tue, 26 Feb 2008 07:26:50 +0000 Jamie Lokier <[EMAIL PROTECTED]> wrote:
>
> > (It would be nicer if sync_file_range()
> > took a vector of ranges for better elevator scheduling, but let's
> > ignore that :-)
>
> Two passes:
>
Andrew Morton wrote:
On Tue, 26 Feb 2008 07:26:50 + Jamie Lokier [EMAIL PROTECTED] wrote:
(It would be nicer if sync_file_range()
took a vector of ranges for better elevator scheduling, but let's
ignore that :-)
Two passes:
Pass 1: shove each of the segments into the queue
Jeff Garzik wrote:
[snip huge long proposal]
Rather than invent new APIs, we should fix the existing ones to _really_
flush data to physical media.
Btw, one reason for the length is the current block request API isn't
sufficient even to make fsync() durable with _no_ new APIs.
It offers
Jörn Engel wrote:
On Tue, 26 February 2008 20:16:11 +1100, Nick Piggin wrote:
Yeah, sync_file_range has slightly unusual semantics and introduce
the new concept, writeout, to userspace (does writeout include
in drive cache? the kernel doesn't think so, but the only way to
make
Jörn Engel wrote:
On Tue, 26 February 2008 20:16:11 +1100, Nick Piggin wrote:
Yeah, sync_file_range has slightly unusual semantics and introduce
the new concept, writeout, to userspace (does writeout include
in drive cache? the kernel doesn't think so, but the only way to
make
Ric Wheeler wrote:
I was surprised that fsync() doesn't do this already. There was a lot
of effort put into block I/O write barriers during 2.5, so that
journalling filesystems can force correct write ordering, using disk
flush cache commands.
After all that effort, I was very surprised to
Jeff Garzik wrote:
Nick Piggin wrote:
Anyway, the idea of making fsync/fdatasync etc. safe by default is
a good idea IMO, and is a bad bug that we don't do that :(
Agreed... it's also disappointing that [unless I'm mistaken] you have
to hack each filesystem to support barriers.
It
Jörn Engel wrote:
On Tue, 26 February 2008 15:28:10 +, Jamie Lokier wrote:
One interesting aspect of this comes with COW filesystems like btrfs or
logfs. Writing out data pages is not sufficient, because those will get
lost unless their referencing metadata is written as well
Jeff Garzik wrote:
> Jamie Lokier wrote:
> >By durable, I mean that fsync() should actually commit writes to
> >physical stable storage,
>
> Yes, it should.
Glad we agree :-)
> >I was surprised that fsync() doesn't do this already. There was a lot
> >of effort
p on linux-kernel...
The fsync problem
-
Chris Wedgwood wrote:
> On Mon, Feb 25, 2008 at 08:50:40PM +, Jamie Lokier wrote:
>
> > On Linux (and other host OSes), fdatsync() and fsync() don't always
> > commit data to hard storage; it sometimes only commits it to
-
Chris Wedgwood wrote:
On Mon, Feb 25, 2008 at 08:50:40PM +, Jamie Lokier wrote:
On Linux (and other host OSes), fdatsync() and fsync() don't always
commit data to hard storage; it sometimes only commits it to the hard
drive cache.
That's a filesystem bug IMO. People should
Jeff Garzik wrote:
Jamie Lokier wrote:
By durable, I mean that fsync() should actually commit writes to
physical stable storage,
Yes, it should.
Glad we agree :-)
I was surprised that fsync() doesn't do this already. There was a lot
of effort put into block I/O write barriers during 2.5
Pavel Machek wrote:
> > You need to write a log entry indicating the new length of the file.
> > There is no space for new log entries.
> >
> > There is a special case for removal -- 'rm gps.nmea' would work. Perhaps
> > we should add a special case for truncation too, so that it can also use
> >
Pavel Machek wrote:
You need to write a log entry indicating the new length of the file.
There is no space for new log entries.
There is a special case for removal -- 'rm gps.nmea' would work. Perhaps
we should add a special case for truncation too, so that it can also use
the extra
David Weinehall wrote:
> > It is also the filesystem that tries to scale logarithmically, as Arnd
> > has noted. Maybe I should call it Log2 to emphesize this point. Log1
> > would be horrible scalability.
>
> So, log2fs... Sounds great to me.
Why Log2? Logarithmic scaling is just
David Weinehall wrote:
It is also the filesystem that tries to scale logarithmically, as Arnd
has noted. Maybe I should call it Log2 to emphesize this point. Log1
would be horrible scalability.
So, log2fs... Sounds great to me.
Why Log2? Logarithmic scaling is just logarithmic
Jörn Engel wrote:
> > Almost all your static functions start with logfs_, why not this one?
>
> Because after a while I discovered how silly it is to start every
> function with logfs_. That prefix doesn't add much unless the function
> has global scope. What I didn't do was remove the prefix
Jörn Engel wrote:
Almost all your static functions start with logfs_, why not this one?
Because after a while I discovered how silly it is to start every
function with logfs_. That prefix doesn't add much unless the function
has global scope. What I didn't do was remove the prefix from
Artem Bityutskiy wrote:
> On Wed, 2007-05-16 at 12:34 +0100, Jamie Lokier wrote:
> > Jörn Engel wrote:
> > > On Wed, 16 May 2007 12:54:14 +0800, David Woodhouse wrote:
> > > > Personally I'd just go for 'JFFS3'. After all, it has a better claim to
> > > >
Albert Cahalan wrote:
> Please don't forget the immutable bit. ("man lsattr")
> Having both, BSD-style, would be even better.
> The immutable bit is important for working around
> software bugs and "features" that damage files.
>
> I also can't find xattr support.
Imho,
Given that the
Jörn Engel wrote:
> On Wed, 16 May 2007 12:54:14 +0800, David Woodhouse wrote:
> > Personally I'd just go for 'JFFS3'. After all, it has a better claim to
> > the name than either of its predecessors :)
>
> Did you ever see akpm's facial expression when he tried to pronounce
> "JFFS2"? ;)
JFFS3
Jörn Engel wrote:
On Wed, 16 May 2007 12:54:14 +0800, David Woodhouse wrote:
Personally I'd just go for 'JFFS3'. After all, it has a better claim to
the name than either of its predecessors :)
Did you ever see akpm's facial expression when he tried to pronounce
JFFS2? ;)
JFFS3 is a
Albert Cahalan wrote:
Please don't forget the immutable bit. (man lsattr)
Having both, BSD-style, would be even better.
The immutable bit is important for working around
software bugs and features that damage files.
I also can't find xattr support.
Imho,
Given that the filesystem is still
Artem Bityutskiy wrote:
On Wed, 2007-05-16 at 12:34 +0100, Jamie Lokier wrote:
Jörn Engel wrote:
On Wed, 16 May 2007 12:54:14 +0800, David Woodhouse wrote:
Personally I'd just go for 'JFFS3'. After all, it has a better claim to
the name than either of its predecessors :)
Did
Ian Campbell wrote:
> On Tue, 2005-08-23 at 16:23 +0100, Jamie Lokier wrote:
> > ...
> > if (any_dnotify_or_inotify_events_pending) {
> > read_dnotify_or_inotify_events();
> > if (any_events_related_to(file)) {
> > store_in_use
Ian Campbell wrote:
On Tue, 2005-08-23 at 16:23 +0100, Jamie Lokier wrote:
receive some request...
if (any_dnotify_or_inotify_events_pending) {
read_dnotify_or_inotify_events();
if (any_events_related_to(file)) {
store_in_userspace_stat_cache(file
Asser Femø wrote:
> According to the fcntl manual you can cancel a notification by doing
> fcntl(fd, F_NOTIFY, 0) (ie. sending 0 as the notification mask), but
> looking in the kernel code fcntl_dirnotify() immediately calls
> dnotify_flush() with neither telling the vfs module about it. Is there
Asser Femø wrote:
According to the fcntl manual you can cancel a notification by doing
fcntl(fd, F_NOTIFY, 0) (ie. sending 0 as the notification mask), but
looking in the kernel code fcntl_dirnotify() immediately calls
dnotify_flush() with neither telling the vfs module about it. Is there a
Eric Van Hensbergen wrote:
> I'd like to second that I think private-namespaces are the right way
> to solve this sort of problem. It also helps not cluttering the
> global namespace with user-local mounts
>
> >
> > Shared subtrees and more support in userspace tools is needed before
> > private
Eric Van Hensbergen wrote:
I'd like to second that I think private-namespaces are the right way
to solve this sort of problem. It also helps not cluttering the
global namespace with user-local mounts
Shared subtrees and more support in userspace tools is needed before
private
Miklos Szeredi wrote:
> > Yet, the results from stat() don't distinguish the number spaces,
> > and "ls" doesn't map the numbers to names properly in the wrong
> > space.
>
> Well you can use "ls -n". It's up to the tools to present the
> information you want in the way you want it. If a tool
Miklos Szeredi wrote:
> I have a little project to imlement a "userloop" filesystem, which
> works just like "mount -o loop", but you don't need root privs. This
> is really simple to do with FUSE and UML.
That would be a nice way to implement those rarely used old
filesystems that aren't really
Miklos Szeredi wrote:
> > Look up the rather large linux-kernel & linux-fsdevel thread "silent
> > semantic changes with reiser4" and it's followup threads, from last
> > year.
>
> Wow, it's 700+ messages. I got through the first 40, and already feel
> dizzy :)
It's easier if you skip the ones
Miklos Szeredi wrote:
> > > Aren't there some assumptions in VFS that currently make this
> > > impossible?
> >
> > I believe it's OK with VFS, but applications would be confused to death.
> > Well, there really is one issue -- dentries have exactly one parent, so
> > what do you do when opening
> > > A nice implemention of it in FUSE could push it along a bit :)
> >
> > Aren't there some assumptions in VFS that currently make this
> > impossible?
>
> I believe it's OK with VFS, but applications would be confused to death.
> Well, there really is one issue -- dentries have exactly one
A nice implemention of it in FUSE could push it along a bit :)
Aren't there some assumptions in VFS that currently make this
impossible?
I believe it's OK with VFS, but applications would be confused to death.
Well, there really is one issue -- dentries have exactly one parent, so
Miklos Szeredi wrote:
Aren't there some assumptions in VFS that currently make this
impossible?
I believe it's OK with VFS, but applications would be confused to death.
Well, there really is one issue -- dentries have exactly one parent, so
what do you do when opening a file with
Miklos Szeredi wrote:
Look up the rather large linux-kernel linux-fsdevel thread silent
semantic changes with reiser4 and it's followup threads, from last
year.
Wow, it's 700+ messages. I got through the first 40, and already feel
dizzy :)
It's easier if you skip the ones by Hans and
Miklos Szeredi wrote:
I have a little project to imlement a userloop filesystem, which
works just like mount -o loop, but you don't need root privs. This
is really simple to do with FUSE and UML.
That would be a nice way to implement those rarely used old
filesystems that aren't really needed
Miklos Szeredi wrote:
Yet, the results from stat() don't distinguish the number spaces,
and ls doesn't map the numbers to names properly in the wrong
space.
Well you can use ls -n. It's up to the tools to present the
information you want in the way you want it. If a tool can't do that,
Anton Altaparmakov wrote:
> > That said, I would _usually_ prefer that when I enter a tgz, that I
> > see all component files having the same uid/gid/permissions as the tgz
> > file itself - the same as I'd see if I entered a zip file.
>
> As you say _usually_, even you admit that sometimes you
Miklos Szeredi wrote:
> Still can't find it :)
>
> Which kernel? Which file?
I'm looking at linux-2.4.30/fs/nfs/dir.c.
-- Jamie
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
Miklos Szeredi wrote:
> > Indeed, if it can be done with namespaces _and_ mounting on a file
> > (that file-as-directory concept), _and_ automounting, then you could
> > cd into your tgz files and others could too :)
>
> There's still that little problem of accessing the tgz file both as a
> file
Miklos Szeredi wrote:
> The same can be true for tarfs. I mount it for my purpose, others can
> mount it for theirs. Since the daemon providing the filesystem asways
> runs with the same capabilities as the user who did the mount, I and
> others will always get the permissions that we have on
Miklos Szeredi wrote:
> > Yes, for NFSv2, this test in nfs_permssion():
> >
> > if (!NFS_PROTO(inode)->access)
> > goto out;
>
> I've seen that, I just thought that was for some broken servers not
> for all NFSv2 servers.
>
> Anyway that's been fixed in NFSv3, so obviously the
Miklos Szeredi wrote:
> > Note that NFS checks the permissions on _both_ the client and server,
> > for a reason.
>
> Does it? If I read the code correctly the client checks credentials
> supplied by the server (or cached). But the server does the actual
> checking of permissions.
>
> Am I
Miklos Szeredi wrote:
> > If the user wants to edit a read-only file in a tgz owned by himself,
> > why can he not _chmod_ the file and _then_ edit it?
> >
> > That said, I would _usually_ prefer that when I enter a tgz, that I
> > see all component files having the same uid/gid/permissions as
Frank Sorenson wrote:
> > That does not make sense.
> >
> > Are you saying you cannot trust your own sshfs userspace daemon?
>
> The user who wrote the userspace code may be able to, but the system
> shouldn't trust the userspace daemon. Permissions will be enforced by
> the ssh server.
In
Bodo Eggert <[EMAIL PROTECTED]> wrote:
> >> That is exactly the intended effect. If I'm at my work machine (where
> >> I'm not an admin unfortunately) and I mount my home machine with sshfs
> >> (because FUSE is installed fortunately :), then I bloody well don't
> >> want the sysadmin or some
Bodo Eggert <[EMAIL PROTECTED]> wrote:
> Jamie Lokier <[EMAIL PROTECTED]> wrote:
> > Miklos Szeredi wrote:
>
> >> 4) Access should not be further restricted for the owner of the
> >> mount, even if permission bits, uid or gid would suggest
> >
Miklos Szeredi wrote:
> The same is true for the case when you mount an sshfs. Since you
> entered your password (or have a passwordless login to the server) you
> are authorized to browse the files on the server, but only with the
> capabilities you have there as a user. The server does the
>
Miklos Szeredi wrote:
> > It would also be nice to generalise and have virtual filesystems which
> > are able to present different views to different users. Can FUSE do
> > that already - is the userspace part told which user is doing each
> > operation?
>
> Yes.
>
> > With that, the desire for
Miklos Szeredi wrote:
It would also be nice to generalise and have virtual filesystems which
are able to present different views to different users. Can FUSE do
that already - is the userspace part told which user is doing each
operation?
Yes.
With that, the desire for virtual
Miklos Szeredi wrote:
The same is true for the case when you mount an sshfs. Since you
entered your password (or have a passwordless login to the server) you
are authorized to browse the files on the server, but only with the
capabilities you have there as a user. The server does the
Bodo Eggert [EMAIL PROTECTED] wrote:
Jamie Lokier [EMAIL PROTECTED] wrote:
Miklos Szeredi wrote:
4) Access should not be further restricted for the owner of the
mount, even if permission bits, uid or gid would suggest
otherwise
Why? Surely you want to prevent writing
Bodo Eggert [EMAIL PROTECTED] wrote:
That is exactly the intended effect. If I'm at my work machine (where
I'm not an admin unfortunately) and I mount my home machine with sshfs
(because FUSE is installed fortunately :), then I bloody well don't
want the sysadmin or some automated script
Frank Sorenson wrote:
That does not make sense.
Are you saying you cannot trust your own sshfs userspace daemon?
The user who wrote the userspace code may be able to, but the system
shouldn't trust the userspace daemon. Permissions will be enforced by
the ssh server.
In fact that's
Miklos Szeredi wrote:
If the user wants to edit a read-only file in a tgz owned by himself,
why can he not _chmod_ the file and _then_ edit it?
That said, I would _usually_ prefer that when I enter a tgz, that I
see all component files having the same uid/gid/permissions as the tgz
Miklos Szeredi wrote:
Note that NFS checks the permissions on _both_ the client and server,
for a reason.
Does it? If I read the code correctly the client checks credentials
supplied by the server (or cached). But the server does the actual
checking of permissions.
Am I missing
Miklos Szeredi wrote:
Yes, for NFSv2, this test in nfs_permssion():
if (!NFS_PROTO(inode)-access)
goto out;
I've seen that, I just thought that was for some broken servers not
for all NFSv2 servers.
Anyway that's been fixed in NFSv3, so obviously the permission
Miklos Szeredi wrote:
The same can be true for tarfs. I mount it for my purpose, others can
mount it for theirs. Since the daemon providing the filesystem asways
runs with the same capabilities as the user who did the mount, I and
others will always get the permissions that we have on the
Miklos Szeredi wrote:
Still can't find it :)
Which kernel? Which file?
I'm looking at linux-2.4.30/fs/nfs/dir.c.
-- Jamie
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
Miklos Szeredi wrote:
Indeed, if it can be done with namespaces _and_ mounting on a file
(that file-as-directory concept), _and_ automounting, then you could
cd into your tgz files and others could too :)
There's still that little problem of accessing the tgz file both as a
file and a
Anton Altaparmakov wrote:
That said, I would _usually_ prefer that when I enter a tgz, that I
see all component files having the same uid/gid/permissions as the tgz
file itself - the same as I'd see if I entered a zip file.
As you say _usually_, even you admit that sometimes you would
Miklos Szeredi wrote:
> That is exactly the intended effect. If I'm at my work machine (where
> I'm not an admin unfortunately) and I mount my home machine with sshfs
> (because FUSE is installed fortunately :), then I bloody well don't
> want the sysadmin or some automated script of his to go
Miklos Szeredi wrote:
> 1) User must not be able to modify files or directories in a way
> which he otherwise could not do (e.g. mount a filesystem over
> /bin)
>
> 2) Suid and device semantics should be disabled within the mount
>
> 3) No other user should have access to files
Miklos Szeredi wrote:
1) User must not be able to modify files or directories in a way
which he otherwise could not do (e.g. mount a filesystem over
/bin)
2) Suid and device semantics should be disabled within the mount
3) No other user should have access to files under
Miklos Szeredi wrote:
That is exactly the intended effect. If I'm at my work machine (where
I'm not an admin unfortunately) and I mount my home machine with sshfs
(because FUSE is installed fortunately :), then I bloody well don't
want the sysadmin or some automated script of his to go
Lee Revell wrote:
> On Tue, 2005-03-22 at 04:48 +0000, Jamie Lokier wrote:
> > I argued for fixing Glibc on the grounds that the changed kernel
> > behaviour, or more exactly having Glibc depend on it, loses a certain
> > semantic property useful for unusual operation
Lee Revell wrote:
On Tue, 2005-03-22 at 04:48 +, Jamie Lokier wrote:
I argued for fixing Glibc on the grounds that the changed kernel
behaviour, or more exactly having Glibc depend on it, loses a certain
semantic property useful for unusual operations on multiple futexes at
the same
Andrew Morton wrote:
> iirc we ended up deciding that the futex problems around that time were due
> to userspace problems (a version of libc). But then, there's no discussion
> around Seto's patch and it didn't get applied. So I don't know what
> happened to that work - it's all a bit
Lee Revell wrote:
> > iirc we ended up deciding that the futex problems around that time were due
> > to userspace problems (a version of libc). But then, there's no discussion
> > around Seto's patch and it didn't get applied. So I don't know what
> > happened to that work - it's all a bit
Lee Revell wrote:
iirc we ended up deciding that the futex problems around that time were due
to userspace problems (a version of libc). But then, there's no discussion
around Seto's patch and it didn't get applied. So I don't know what
happened to that work - it's all a bit mysterious.
Andrew Morton wrote:
iirc we ended up deciding that the futex problems around that time were due
to userspace problems (a version of libc). But then, there's no discussion
around Seto's patch and it didn't get applied. So I don't know what
happened to that work - it's all a bit mysterious.
Ingo Molnar wrote:
>
> * Jakub Jelinek <[EMAIL PROTECTED]> wrote:
>
> > The futex man pages that have been around for years (certainly since
> > mid 2002) certainly don't document FUTEX_WAIT as token passing
> > operation, but as atomic operation:
> >
> > Say
Ingo Molnar wrote:
* Jakub Jelinek [EMAIL PROTECTED] wrote:
The futex man pages that have been around for years (certainly since
mid 2002) certainly don't document FUTEX_WAIT as token passing
operation, but as atomic operation:
Say
Jakub Jelinek wrote:
> http://www.ussg.iu.edu/hypermail/linux/kernel/0411.2/0953.html
>
> Your argument in November was that you don't want to slow down the
> kernel and that userland must be able to cope with the
> non-atomicity of futex syscall.
Those were two of them.
But my other main
Jakub Jelinek wrote:
http://www.ussg.iu.edu/hypermail/linux/kernel/0411.2/0953.html
Your argument in November was that you don't want to slow down the
kernel and that userland must be able to cope with the
non-atomicity of futex syscall.
Those were two of them.
But my other main concern is
Olof Johansson wrote:
> How's this? I went with get_val_no_fault(), since it isn't really a
> get_user.*() any more (ptr being passed in), and no_paging is a little
> misleading (not all faults are due to paging).
How ironic: I deliberately didn't choose "no_fault" because that
function *does*
Linus Torvalds wrote:
> > I suggest putting it into futex.c, and make it an inline function
> > which takes "u32 __user *".
>
> Agreed, except we've traditionally just made it "int __user *".
The type signatures in futex.c are a bit mixed up - most places say
"int __user *" but sys_futex() says
Olof Johansson wrote:
> On Wed, Feb 23, 2005 at 07:54:06AM -0800, Linus Torvalds wrote:
>
> > > Otherwise, a preempt attempt in get_user would not be seen
> > > until some future preempt_enable was executed.
> >
> > True. I guess we should have a "preempt_check_resched()" there too. That's
> >
Olof Johansson wrote:
On Wed, Feb 23, 2005 at 07:54:06AM -0800, Linus Torvalds wrote:
Otherwise, a preempt attempt in get_user would not be seen
until some future preempt_enable was executed.
True. I guess we should have a preempt_check_resched() there too. That's
what
Linus Torvalds wrote:
I suggest putting it into futex.c, and make it an inline function
which takes u32 __user *.
Agreed, except we've traditionally just made it int __user *.
The type signatures in futex.c are a bit mixed up - most places say
int __user * but sys_futex() says u32 __user
Olof Johansson wrote:
How's this? I went with get_val_no_fault(), since it isn't really a
get_user.*() any more (ptr being passed in), and no_paging is a little
misleading (not all faults are due to paging).
How ironic: I deliberately didn't choose no_fault because that
function *does* take
Linus Torvalds wrote:
> > queue_me(...) etc.
> > current->flags |= PF_MMAP_SEM; <- new
> > ret = get_user(...);
> > current->flags &= PF_MMAP_SEM; <- new
> > /* the rest */
>
> That is uglee.
>
> We really have this already, and it's called
Olof Johansson wrote:
> > That won't work because the vma lock must be help between key
> > calculation and get_user() - otherwise futex is not reliable. It
> > would work if the futex key calculation was inside the loop.
>
> Sure, but that's still true: It's just that the get_user() is done
Chris Friesen wrote:
> > down_read(>mm->mmap_sem);
> > get_futex_key(...) etc.
> > queue_me(...) etc.
> > current->flags |= PF_MMAP_SEM; <- new
> > ret = get_user(...);
> > current->flags &= PF_MMAP_SEM; <- new
> > /* the rest */
>
> Should the
Andrew Morton wrote:
> > This will quickly lock up, since the futex_wait code dows a
> > down_read(mmap_sem), then a get_user().
> >
> > The do_page_fault code on ppc64 (as well as other architectures) needs
> > to take the same semaphore for reading. This is all good until the
> > second thread
1 - 100 of 580 matches
Mail list logo
