We got into the current situation for performance reasons, avoiding the costly
reload of CR3 that a hardware task switch would cause. It seems we'll be
loading CR3 now anyway, so it might be time to reconsider hardware
task switches.
The recent patches leave kernel entry/exit code mapped.
We got into the current situation for performance reasons, avoiding the costly
reload of CR3 that a hardware task switch would cause. It seems we'll be
loading CR3 now anyway, so it might be time to reconsider hardware
task switches.
The recent patches leave kernel entry/exit code mapped.
This bug was introduced with SE Linux, 18 years ago. People have been
adding hacks to work around it as the bug bites them, but really the
bug ought to be fixed. Signals related to a tty are supposed to come
from the kernel. This got broken for pty devices. We now act as if
the signal is sent from
This bug was introduced with SE Linux, 18 years ago. People have been
adding hacks to work around it as the bug bites them, but really the
bug ought to be fixed. Signals related to a tty are supposed to come
from the kernel. This got broken for pty devices. We now act as if
the signal is sent from
On Nov 29, 2007 4:40 PM, Eric W. Biederman <[EMAIL PROTECTED]> wrote:
> "Albert Cahalan" <[EMAIL PROTECTED]> writes:
>
> > On Nov 28, 2007 6:31 AM, Eric W. Biederman <[EMAIL PROTECTED]> wrote:
> >> Ingo Molnar <[EMAIL PROTECTED]> wr
On Nov 29, 2007 4:40 PM, Eric W. Biederman [EMAIL PROTECTED] wrote:
Albert Cahalan [EMAIL PROTECTED] writes:
On Nov 28, 2007 6:31 AM, Eric W. Biederman [EMAIL PROTECTED] wrote:
Ingo Molnar [EMAIL PROTECTED] writes:
* Albert Cahalan [EMAIL PROTECTED] wrote:
On Nov 27, 2007 7:49 PM
On Nov 28, 2007 5:46 AM, Ingo Molnar <[EMAIL PROTECTED]> wrote:
> * Albert Cahalan <[EMAIL PROTECTED]> wrote:
> > On Nov 27, 2007 7:49 PM, Guillaume Chazarain <[EMAIL PROTECTED]> wrote:
> > > [EMAIL PROTECTED] wrote:
> > >
> > > > We ma
On Nov 28, 2007 6:31 AM, Eric W. Biederman <[EMAIL PROTECTED]> wrote:
> Ingo Molnar <[EMAIL PROTECTED]> writes:
> > * Albert Cahalan <[EMAIL PROTECTED]> wrote:
> >> On Nov 27, 2007 7:49 PM, Guillaume Chazarain <[EMAIL PROTECTED]> wrote:
> In a lot of w
ms relying on
> this interface will loudly break on older kernels, unlike with the
> proposed interface change.
>
> Ccing Albert Cahalan as he made the change to /proc/self in the first
> place:
Changing /proc/self is somewhat risky, and probably
undesirable anyway. That file has a
, unlike with the
proposed interface change.
Ccing Albert Cahalan as he made the change to /proc/self in the first
place:
Changing /proc/self is somewhat risky, and probably
undesirable anyway. That file has always been used
to represent the process; at one time this also meant
the task
On Nov 28, 2007 6:31 AM, Eric W. Biederman [EMAIL PROTECTED] wrote:
Ingo Molnar [EMAIL PROTECTED] writes:
* Albert Cahalan [EMAIL PROTECTED] wrote:
On Nov 27, 2007 7:49 PM, Guillaume Chazarain [EMAIL PROTECTED] wrote:
In a lot of ways if you access /proc/self and you get back information
On Nov 28, 2007 5:46 AM, Ingo Molnar [EMAIL PROTECTED] wrote:
* Albert Cahalan [EMAIL PROTECTED] wrote:
On Nov 27, 2007 7:49 PM, Guillaume Chazarain [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] wrote:
We may be stuck with the current broken behavior for backwards
compatibility
On 7/14/07, David Miller <[EMAIL PROTECTED]> wrote:
From: "Albert Cahalan" <[EMAIL PROTECTED]>
Date: Sat, 14 Jul 2007 22:48:57 -0400
> A real constant-value PAGE_SIZE is useful and doable.
It's bogus to use it. The kernel can get recompiled
to arbitrary page sizes
Olaf Hering writes:
On Sat, Jul 14, H. Peter Anvin wrote:
Olaf Hering wrote:
Declare PAGE_SIZE as getpagesize() for userspace.
PAGE_SIZE is used in resource.h and shm.h
I would think it would be better to not define it at all.
Several architectures already don't have PAGE_SIZE visible
to
Olaf Hering writes:
On Sat, Jul 14, H. Peter Anvin wrote:
Olaf Hering wrote:
Declare PAGE_SIZE as getpagesize() for userspace.
PAGE_SIZE is used in resource.h and shm.h
I would think it would be better to not define it at all.
Several architectures already don't have PAGE_SIZE visible
to
On 7/14/07, David Miller [EMAIL PROTECTED] wrote:
From: Albert Cahalan [EMAIL PROTECTED]
Date: Sat, 14 Jul 2007 22:48:57 -0400
A real constant-value PAGE_SIZE is useful and doable.
It's bogus to use it. The kernel can get recompiled
to arbitrary page sizes on some architectures, so a constat
On 7/7/07, Satyam Sharma <[EMAIL PROTECTED]> wrote:
On 7/7/07, Albert Cahalan <[EMAIL PROTECTED]> wrote:
I had one share mounted, from XP to Linux, and wanted another.
At first I had an incorrect setting on the XP box, almost
certainly related to permissions. The mount fail
On 7/7/07, Satyam Sharma [EMAIL PROTECTED] wrote:
On 7/7/07, Albert Cahalan [EMAIL PROTECTED] wrote:
I had one share mounted, from XP to Linux, and wanted another.
At first I had an incorrect setting on the XP box, almost
certainly related to permissions. The mount failed of course.
Running
I had one share mounted, from XP to Linux, and wanted another.
At first I had an incorrect setting on the XP box, almost
certainly related to permissions. The mount failed of course.
Running "mount" showed that the filesystem was not mounted,
but apparently it didn't remain fully unmounted
I had one share mounted, from XP to Linux, and wanted another.
At first I had an incorrect setting on the XP box, almost
certainly related to permissions. The mount failed of course.
Running mount showed that the filesystem was not mounted,
but apparently it didn't remain fully unmounted either.
On 6/22/07, Arjan van de Ven <[EMAIL PROTECTED]> wrote:
> > > > and these methods also destroy yourself on any machine with a looser
> > > > cache coherency between I and D-cache
> > > >
> > > > for all but x86 you pretty much have to do the mprotect() between the
> > > > two states to deal
On 6/21/07, Pavel Machek <[EMAIL PROTECTED]> wrote:
> >> It's really not worth getting bothered by. Truth is, big
> >> giant
> >> pathnames break lots of stuff already, both kernel and
> >> userspace.
> >
> >> Just look in /proc for some nice juicy kernel breakage:
> >> cwd, exe, fd/*, maps,
On 6/22/07, Arjan van de Ven <[EMAIL PROTECTED]> wrote:
On Fri, 2007-06-22 at 01:56 -0400, Albert Cahalan wrote:
> On 6/21/07, Arjan van de Ven <[EMAIL PROTECTED]> wrote:
> > On Fri, 2007-06-08 at 02:35 -0400, Albert Cahalan wrote:
> > > Right now, Linux isn't all
On 6/21/07, Pavel Machek [EMAIL PROTECTED] wrote:
It's really not worth getting bothered by. Truth is, big
giant
pathnames break lots of stuff already, both kernel and
userspace.
Just look in /proc for some nice juicy kernel breakage:
cwd, exe, fd/*, maps, mounts, mountstats,
On 6/22/07, Arjan van de Ven [EMAIL PROTECTED] wrote:
On Fri, 2007-06-22 at 01:56 -0400, Albert Cahalan wrote:
On 6/21/07, Arjan van de Ven [EMAIL PROTECTED] wrote:
On Fri, 2007-06-08 at 02:35 -0400, Albert Cahalan wrote:
Right now, Linux isn't all that friendly to JIT emulators.
Here
On 6/22/07, Arjan van de Ven [EMAIL PROTECTED] wrote:
and these methods also destroy yourself on any machine with a looser
cache coherency between I and D-cache
for all but x86 you pretty much have to do the mprotect() between the
two states to deal with the cache
On 6/21/07, Arjan van de Ven <[EMAIL PROTECTED]> wrote:
On Fri, 2007-06-08 at 02:35 -0400, Albert Cahalan wrote:
> Right now, Linux isn't all that friendly to JIT emulators.
> Here are the problems and suggestions to improve the situation.
>
> There is an SE Linux e
On 6/20/07, H. Peter Anvin <[EMAIL PROTECTED]> wrote:
Albert Cahalan wrote:
> Look, let's back up a bit here. At a high level, what exactly do
> you imagine that this behavior was intended for? I suggest you
> list some examples of the attacks that are blocked.
>
On 6/20/07, H. Peter Anvin [EMAIL PROTECTED] wrote:
Albert Cahalan wrote:
Look, let's back up a bit here. At a high level, what exactly do
you imagine that this behavior was intended for? I suggest you
list some examples of the attacks that are blocked.
Can you come up with a reasonable
On 6/21/07, Arjan van de Ven [EMAIL PROTECTED] wrote:
On Fri, 2007-06-08 at 02:35 -0400, Albert Cahalan wrote:
Right now, Linux isn't all that friendly to JIT emulators.
Here are the problems and suggestions to improve the situation.
There is an SE Linux execmem restriction that enforces W^X
On 6/20/07, H. Peter Anvin <[EMAIL PROTECTED]> wrote:
Albert Cahalan wrote:
> Putting this into the security policy was an error born of
> lazyness to begin with. Abuse of the security mechanism
> was easier than hacking the toolchain, ELF loader, etc.
>
> Either a binary ne
on this one.
On Tue, Jun 19, 2007 at 11:16:29PM -0400, Albert Cahalan wrote:
It does and it doesn't. There is not a reasonable way for a
user to mark an app as needing full self-modifying ability.
It's not like the executable stack, which can be set via the
ELF note markings on the executabl
On 6/20/07, H. Peter Anvin <[EMAIL PROTECTED]> wrote:
William Lee Irwin III wrote:
> I presumed an ELF note or extended filesystem attributes were already
> in place for this sort of affair. It may be that the model implemented
> is so restrictive that users are forbidden to create new
On 6/20/07, H. Peter Anvin [EMAIL PROTECTED] wrote:
William Lee Irwin III wrote:
I presumed an ELF note or extended filesystem attributes were already
in place for this sort of affair. It may be that the model implemented
is so restrictive that users are forbidden to create new
.
On Tue, Jun 19, 2007 at 11:16:29PM -0400, Albert Cahalan wrote:
It does and it doesn't. There is not a reasonable way for a
user to mark an app as needing full self-modifying ability.
It's not like the executable stack, which can be set via the
ELF note markings on the executable. (ELF note markings
On 6/20/07, H. Peter Anvin [EMAIL PROTECTED] wrote:
Albert Cahalan wrote:
Putting this into the security policy was an error born of
lazyness to begin with. Abuse of the security mechanism
was easier than hacking the toolchain, ELF loader, etc.
Either a binary needs self-modification
On 6/19/07, William Lee Irwin III <[EMAIL PROTECTED]> wrote:
On Fri, Jun 08, 2007 at 02:35:22AM -0400, Albert Cahalan wrote:
Right now, Linux isn't all that friendly to JIT emulators.
Here are the problems and suggestions to improve the situation.
There is an SE Linux execmem restr
On 6/19/07, William Lee Irwin III [EMAIL PROTECTED] wrote:
On Fri, Jun 08, 2007 at 02:35:22AM -0400, Albert Cahalan wrote:
Right now, Linux isn't all that friendly to JIT emulators.
Here are the problems and suggestions to improve the situation.
There is an SE Linux execmem restriction
On 6/15/07, Pavel Machek <[EMAIL PROTECTED]> wrote:
[Albert Cahalan]
> It's really not worth getting bothered by. Truth is, big
> giant
> pathnames break lots of stuff already, both kernel and
> userspace.
> Just look in /proc for some nice juicy kernel breakage:
&
On 6/15/07, Pavel Machek [EMAIL PROTECTED] wrote:
[Albert Cahalan]
It's really not worth getting bothered by. Truth is, big
giant
pathnames break lots of stuff already, both kernel and
userspace.
Just look in /proc for some nice juicy kernel breakage:
cwd, exe, fd/*, maps, mounts
Christoph Hellwig writes:
On Thu, Jun 14, 2007 at 04:36:09PM +0900, Kentaro Takeda wrote:
We limit the maximum length of any string data (such as
domainname and pathnames) to TOMOYO_MAX_PATHNAME_LEN
(which is 4000) bytes to fit within a single page.
Userland programs can obtain the amount of
Christoph Hellwig writes:
On Thu, Jun 14, 2007 at 04:36:09PM +0900, Kentaro Takeda wrote:
We limit the maximum length of any string data (such as
domainname and pathnames) to TOMOYO_MAX_PATHNAME_LEN
(which is 4000) bytes to fit within a single page.
Userland programs can obtain the amount of
On 6/13/07, Chris Mason <[EMAIL PROTECTED]> wrote:
On Wed, Jun 13, 2007 at 12:14:40PM -0400, Albert Cahalan wrote:
> On 6/13/07, Chris Mason <[EMAIL PROTECTED]> wrote:
> >On Wed, Jun 13, 2007 at 01:45:28AM -0400, Albert Cahalan wrote:
> >> * secure delete via
On 6/13/07, Chris Mason [EMAIL PROTECTED] wrote:
On Wed, Jun 13, 2007 at 12:14:40PM -0400, Albert Cahalan wrote:
On 6/13/07, Chris Mason [EMAIL PROTECTED] wrote:
On Wed, Jun 13, 2007 at 01:45:28AM -0400, Albert Cahalan wrote:
* secure delete via destruction of per-file or per-block random
On 6/13/07, Chris Mason <[EMAIL PROTECTED]> wrote:
On Wed, Jun 13, 2007 at 01:45:28AM -0400, Albert Cahalan wrote:
> The usual wishlist:
>
> * inode-to-pathnames mapping
This one I'll code, it will help with inode link count verification. I
want to be able to det
On 6/13/07, Chris Mason [EMAIL PROTECTED] wrote:
On Wed, Jun 13, 2007 at 01:45:28AM -0400, Albert Cahalan wrote:
The usual wishlist:
* inode-to-pathnames mapping
This one I'll code, it will help with inode link count verification. I
want to be able to detect at run time that an inode
Neat! It's great to see somebody else waking up to the idea that
storage media is NOT to be trusted.
Judging by the design paper, it looks like your structs have some
alignment problems.
The usual wishlist:
* inode-to-pathnames mapping
* a subvolume that is a single file (disk image, database,
Neat! It's great to see somebody else waking up to the idea that
storage media is NOT to be trusted.
Judging by the design paper, it looks like your structs have some
alignment problems.
The usual wishlist:
* inode-to-pathnames mapping
* a subvolume that is a single file (disk image, database,
On 6/8/07, Alan Cox <[EMAIL PROTECTED]> wrote:
> There is an SE Linux execmem restriction that enforces W^X.
This depends on whatever SELinux rulesets you are running. Its just a
good rule to have present that most programs shouldn't be self patching,
and then label those that do differently.
On 6/8/07, Eric Dumazet <[EMAIL PROTECTED]> wrote:
Albert Cahalan a écrit :
> Additions to better support JIT emulators:
>
> a. sysctl to set IPC_RMID by default
Not very good, this will break some apps.
As a sysctl, the admin gets to choose between
compatibility and san
On 6/8/07, Eric W. Biederman <[EMAIL PROTECTED]> wrote:
"Albert Cahalan" <[EMAIL PROTECTED]> writes:
> On 6/7/07, Eric W. Biederman <[EMAIL PROTECTED]> wrote:
>> So it looks to me like we need to do three things:
>> - Fix the inode number
>&g
Right now, Linux isn't all that friendly to JIT emulators.
Here are the problems and suggestions to improve the situation.
There is an SE Linux execmem restriction that enforces W^X.
Assuming you don't wish to just disable SE Linux, there are
two ugly ways around the problem. You can mmap a file
Right now, Linux isn't all that friendly to JIT emulators.
Here are the problems and suggestions to improve the situation.
There is an SE Linux execmem restriction that enforces W^X.
Assuming you don't wish to just disable SE Linux, there are
two ugly ways around the problem. You can mmap a file
On 6/8/07, Eric W. Biederman [EMAIL PROTECTED] wrote:
Albert Cahalan [EMAIL PROTECTED] writes:
On 6/7/07, Eric W. Biederman [EMAIL PROTECTED] wrote:
So it looks to me like we need to do three things:
- Fix the inode number
- Fix the name on the hugetlbfs dentry to hold the key
- Add
On 6/8/07, Eric Dumazet [EMAIL PROTECTED] wrote:
Albert Cahalan a écrit :
Additions to better support JIT emulators:
a. sysctl to set IPC_RMID by default
Not very good, this will break some apps.
As a sysctl, the admin gets to choose between
compatibility and sanity.
I can see
On 6/8/07, Alan Cox [EMAIL PROTECTED] wrote:
There is an SE Linux execmem restriction that enforces W^X.
This depends on whatever SELinux rulesets you are running. Its just a
good rule to have present that most programs shouldn't be self patching,
and then label those that do differently.
A
On 6/7/07, Eric W. Biederman <[EMAIL PROTECTED]> wrote:
So it looks to me like we need to do three things:
- Fix the inode number
- Fix the name on the hugetlbfs dentry to hold the key
- Add a big fat comment that user space programs depend on this
behavior of both the dentry name and the
On 6/7/07, Badari Pulavarty <[EMAIL PROTECTED]> wrote:
BTW, I agree with Eric that its would be nice to use shmid as part
of name instead of forcing to be as inode number. It should be
possible for pmap to workout shmid from "key" or name. Isn't it ?
It is not at all nice.
1. it's
On 6/7/07, Eric W. Biederman [EMAIL PROTECTED] wrote:
So it looks to me like we need to do three things:
- Fix the inode number
- Fix the name on the hugetlbfs dentry to hold the key
- Add a big fat comment that user space programs depend on this
behavior of both the dentry name and the inode
On 6/7/07, Badari Pulavarty [EMAIL PROTECTED] wrote:
BTW, I agree with Eric that its would be nice to use shmid as part
of name instead of forcing to be as inode number. It should be
possible for pmap to workout shmid from key or name. Isn't it ?
It is not at all nice.
1. it's incompatible
On 6/6/07, Andrew Morton <[EMAIL PROTECTED]> wrote:
On Wed, 6 Jun 2007 23:27:01 -0400 "Albert Cahalan" <[EMAIL PROTECTED]> wrote:
> Eric W. Biederman writes:
> > Badari Pulavarty <[EMAIL PROTECTED]> writes:
>
> >> Your recent cleanup to shm
Eric W. Biederman writes:
Badari Pulavarty <[EMAIL PROTECTED]> writes:
Your recent cleanup to shm code, namely
[PATCH] shm: make sysv ipc shared memory use stacked files
took away one of the debugging feature for shm segments.
Originally, shmid were forced to be the inode numbers and
they
Eric W. Biederman writes:
Badari Pulavarty [EMAIL PROTECTED] writes:
Your recent cleanup to shm code, namely
[PATCH] shm: make sysv ipc shared memory use stacked files
took away one of the debugging feature for shm segments.
Originally, shmid were forced to be the inode numbers and
they
On 6/6/07, Andrew Morton [EMAIL PROTECTED] wrote:
On Wed, 6 Jun 2007 23:27:01 -0400 Albert Cahalan [EMAIL PROTECTED] wrote:
Eric W. Biederman writes:
Badari Pulavarty [EMAIL PROTECTED] writes:
Your recent cleanup to shm code, namely
[PATCH] shm: make sysv ipc shared memory use stacked
David Schwartz writes:
[Aaron Wiebe]
open("/somefile", O_WRONLY|O_NONBLOCK|O_CREAT, 0644) = 1621 <0.415147>
How could they make any difference? I can't think of any
conceivable way they could.
Now, I'm a userspace guy so I can be pretty dense, but shouldn't a
call with a nonblocking flag
David Schwartz writes:
[Aaron Wiebe]
open(/somefile, O_WRONLY|O_NONBLOCK|O_CREAT, 0644) = 1621 0.415147
How could they make any difference? I can't think of any
conceivable way they could.
Now, I'm a userspace guy so I can be pretty dense, but shouldn't a
call with a nonblocking flag
Ingo Molnar writes:
looking over the list of our new generic APIs (see further below) i
think there are three important things that are needed for an API to
become widely used:
1) it should solve a real problem (ha ;-), it should be intuitive to
humans and it should fit into existing
Ingo Molnar writes:
looking over the list of our new generic APIs (see further below) i
think there are three important things that are needed for an API to
become widely used:
1) it should solve a real problem (ha ;-), it should be intuitive to
humans and it should fit into existing
On 5/29/07, Eric W. Biederman <[EMAIL PROTECTED]> wrote:
"Albert Cahalan" <[EMAIL PROTECTED]> writes:
> Jan Engelhardt writes:
-if(self_pid==1 && ADOPTED(processes[i]) && forest_type!='u')
+if(ADOPTED(processes[i]) && forest_type!='u'
On 5/29/07, Eric W. Biederman [EMAIL PROTECTED] wrote:
Albert Cahalan [EMAIL PROTECTED] writes:
Jan Engelhardt writes:
-if(self_pid==1 ADOPTED(processes[i]) forest_type!='u')
+if(ADOPTED(processes[i]) forest_type!='u')
That's not compatible because init's children are now
Jan Engelhardt writes:
On Apr 10 2007 17:47, Jan Engelhardt wrote:
On Apr 8 2007 20:57, Oleg Nesterov wrote:
Anyway, re-parenting to swapper breaks pstree, it doesn't
show kernel threads. And if ->parent == /sbin/init, we can't
remove us from ->children (unless we forbid sub-thread-of-init
Robin Holt writes:
On Mon, Apr 09, 2007 at 08:36:21AM -0600, Eric W. Biederman wrote:
Robin Holt <[EMAIL PROTECTED]> writes:
I would say this is more a benefit than a problem. With a couple
of these systems we are testing, the number of kernel threads is
far greater than the number of user
Robin Holt writes:
On Mon, Apr 09, 2007 at 08:36:21AM -0600, Eric W. Biederman wrote:
Robin Holt [EMAIL PROTECTED] writes:
I would say this is more a benefit than a problem. With a couple
of these systems we are testing, the number of kernel threads is
far greater than the number of user
Jan Engelhardt writes:
On Apr 10 2007 17:47, Jan Engelhardt wrote:
On Apr 8 2007 20:57, Oleg Nesterov wrote:
Anyway, re-parenting to swapper breaks pstree, it doesn't
show kernel threads. And if -parent == /sbin/init, we can't
remove us from -children (unless we forbid sub-thread-of-init
Why can we still not do this?
It's a stupid restriction. Security isn't a reason;
we have SE Linux policy and auditing to take
care of any issues. Heck, SE Linux policy could
even deny this feature for the truly paranoid.
Writing to /dev/* to update timestamps is surely
a worse security
Why can we still not do this?
It's a stupid restriction. Security isn't a reason;
we have SE Linux policy and auditing to take
care of any issues. Heck, SE Linux policy could
even deny this feature for the truly paranoid.
Writing to /dev/* to update timestamps is surely
a worse security
On 5/19/07, Segher Boessenkool <[EMAIL PROTECTED]> wrote:
[Albert Cahalan]
> Set MMCR0[TBEE], set MMCR0[PMXE], and choose a TBL bit via
> MMCR0[TBSEL].
That's the performance monitor, which could very well be
in use already (for performance monitoring stuff, who
would
On 5/19/07, Segher Boessenkool [EMAIL PROTECTED] wrote:
[Albert Cahalan]
Set MMCR0[TBEE], set MMCR0[PMXE], and choose a TBL bit via
MMCR0[TBSEL].
That's the performance monitor, which could very well be
in use already (for performance monitoring stuff, who
would have guessed
On 5/18/07, Sergei Shtylyov <[EMAIL PROTECTED]> wrote:
Albert Cahalan wrote:
>>> Sure, but is there any utility in registering more than the
>>> decrementer on PPC?
>> Not yet. I'm not sure I know any other PPC CPU facility fitting
>> for clockevents. In
On 5/18/07, Sergei Shtylyov [EMAIL PROTECTED] wrote:
Albert Cahalan wrote:
Sure, but is there any utility in registering more than the
decrementer on PPC?
Not yet. I'm not sure I know any other PPC CPU facility fitting
for clockevents. In theory, FIT could be used -- but its period
Sergei Shtylyov writes:
Kumar Gala wrote:
[Sergei Shtylyov]
Kumar Gala wrote:
I haven't looked at all the new clock/timer code, is there any
utility in having support for more than one clock source?
Of course, you may register as many as you like.
Sure, but is there any utility in
Sergei Shtylyov writes:
Kumar Gala wrote:
[Sergei Shtylyov]
Kumar Gala wrote:
I haven't looked at all the new clock/timer code, is there any
utility in having support for more than one clock source?
Of course, you may register as many as you like.
Sure, but is there any utility in
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.
-
To unsubscribe from this list: send the line "unsubscribe
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.
-
To unsubscribe from this list: send the line unsubscribe
On 5/9/07, Andrey Borzenkov <[EMAIL PROTECTED]> wrote:
On Wednesday 09 May 2007, Albert Cahalan wrote:
...
On May 8 2007 00:43, Albert Cahalan wrote:
Fix: the vfat driver should use the 8.3 name for such files.
...
It's not appropriate for vfat, HPFS, JFS, or NTFS. All of those
have
On 5/8/07, Jan Engelhardt <[EMAIL PROTECTED]> wrote:
On May 8 2007 00:43, Albert Cahalan wrote:
> Fix: the vfat driver should use the 8.3 name for such files.
Or the 31-character ISO Level 1(?).
That might be appropriate for a similar problem on CD-ROM
filesystems. (wh
On 5/8/07, Jan Engelhardt [EMAIL PROTECTED] wrote:
On May 8 2007 00:43, Albert Cahalan wrote:
Fix: the vfat driver should use the 8.3 name for such files.
Or the 31-character ISO Level 1(?).
That might be appropriate for a similar problem on CD-ROM
filesystems. (when the CD is rockridge
On 5/9/07, Andrey Borzenkov [EMAIL PROTECTED] wrote:
On Wednesday 09 May 2007, Albert Cahalan wrote:
...
On May 8 2007 00:43, Albert Cahalan wrote:
Fix: the vfat driver should use the 8.3 name for such files.
...
It's not appropriate for vfat, HPFS, JFS, or NTFS. All of those
have built
[EMAIL PROTECTED], [EMAIL PROTECTED],
[EMAIL PROTECTED], linux-kernel@vger.kernel.org,
[EMAIL PROTECTED], [EMAIL PROTECTED]
Re: [PATCH 0/2] LogFS take two
You seem to be missing the immutable bit. This is really useful
for dealing with buggy or badly-designed things running as root.
I've used
Andrey Borzenkov writes:
This was posted in one of Russian forums. It was not possible to
archive (under Linux, using tar) vfat directory where files had
long Russian names (really long - over 150 - 170 characters) - tar
returned stat failure. When looking with plain ls, file names
appeared
Andrey Borzenkov writes:
This was posted in one of Russian forums. It was not possible to
archive (under Linux, using tar) vfat directory where files had
long Russian names (really long - over 150 - 170 characters) - tar
returned stat failure. When looking with plain ls, file names
appeared
[EMAIL PROTECTED], [EMAIL PROTECTED],
[EMAIL PROTECTED], linux-kernel@vger.kernel.org,
[EMAIL PROTECTED], [EMAIL PROTECTED]
Re: [PATCH 0/2] LogFS take two
You seem to be missing the immutable bit. This is really useful
for dealing with buggy or badly-designed things running as root.
I've used
john stultz writes:
Indeed. The monotonic clock's behavior around suspend and resume
is poorly defined. When we increased it, folks didn't like the
fact that uptime would increase while a system was suspended.
The uptime really does need to increase during suspend. Otherwise,
things get
Andrew Morton writes:
"Cabot, Mason B" <[EMAIL PROTECTED]> wrote:
I've been testing the NAS performance of ext3/Openfiler 2.2 against
NTFS/WinXP and have found that NTFS significantly outperforms ext3 for
video workloads. The Windows CIFS client will attempt a poor-man's
pre-allocation of the
Andrew Morton writes:
Cabot, Mason B [EMAIL PROTECTED] wrote:
I've been testing the NAS performance of ext3/Openfiler 2.2 against
NTFS/WinXP and have found that NTFS significantly outperforms ext3 for
video workloads. The Windows CIFS client will attempt a poor-man's
pre-allocation of the
john stultz writes:
Indeed. The monotonic clock's behavior around suspend and resume
is poorly defined. When we increased it, folks didn't like the
fact that uptime would increase while a system was suspended.
The uptime really does need to increase during suspend. Otherwise,
things get
On 5/3/07, Jan Engelhardt <[EMAIL PROTECTED]> wrote:
On May 3 2007 02:17, Albert Cahalan wrote:
> Those sizes are unreadable on the 200 dpi OLPC XO screen,
Hm that should have read, for you:
I don't object implementing support for larger sizes.
(But I wonder how that should work w
On 5/2/07, Jan Engelhardt <[EMAIL PROTECTED]> wrote:
On May 1 2007 11:49, Albert Cahalan wrote:
>>
>> Well, I think the consensus is that anything beyond that should be done
>> in userspace; the main such console daemon was Kon2 last I checked.
>
> Font size is not
On 5/2/07, Jan Engelhardt [EMAIL PROTECTED] wrote:
On May 1 2007 11:49, Albert Cahalan wrote:
Well, I think the consensus is that anything beyond that should be done
in userspace; the main such console daemon was Kon2 last I checked.
Font size is not a sane place to draw the line. Features
On 5/3/07, Jan Engelhardt [EMAIL PROTECTED] wrote:
On May 3 2007 02:17, Albert Cahalan wrote:
Those sizes are unreadable on the 200 dpi OLPC XO screen,
Hm that should have read, for you:
I don't object implementing support for larger sizes.
(But I wonder how that should work without FB
1 - 100 of 173 matches
Mail list logo
