On 5/1/07, H. Peter Anvin <[EMAIL PROTECTED]> wrote:
Antonino A. Daplas wrote:
>
> And this will entail a lot of work to change (Is it worth it to rework
> the code and remove the limitation?). The linux-console project
> (http://linuxconsole.sourceforge.net/) might have , but I don't know its
>
On 5/1/07, H. Peter Anvin [EMAIL PROTECTED] wrote:
Antonino A. Daplas wrote:
And this will entail a lot of work to change (Is it worth it to rework
the code and remove the limitation?). The linux-console project
(http://linuxconsole.sourceforge.net/) might have , but I don't know its
I'm having problems with a font I just created. It's a rather big one,
intended for a framebuffer console in UTF-8 mode. The strace program
reports that /bin/setfont fails on a KDFONTOP ioctl with EINVAL.
In reading the kernel code, I find this:
vt.c:static int con_font_set(struct vc_data *vc,
I'm having problems with a font I just created. It's a rather big one,
intended for a framebuffer console in UTF-8 mode. The strace program
reports that /bin/setfont fails on a KDFONTOP ioctl with EINVAL.
In reading the kernel code, I find this:
vt.c:static int con_font_set(struct vc_data *vc,
's useful, but the other case is more important.
> Does a parent death signal make most sense between processes that are part of
> a larger program.
That is the only way I can really see it being used. The only actual
example of use I know is what Albert Cahalan reported. To my mind, the
, but the other case is more important.
Does a parent death signal make most sense between processes that are part of
a larger program.
That is the only way I can really see it being used. The only actual
example of use I know is what Albert Cahalan reported. To my mind, the
only semantics that matter
On 2/28/07, Eric W. Biederman <[EMAIL PROTECTED]> wrote:
Chuck Ebbert <[EMAIL PROTECTED]> writes:
> Starting with kernel 2.6.19, the process directories in
> /proc are sorted by number. They were sorted by process
> start time in 2.6.18 and earlier. This makes the output
> of procps come out in
On 2/28/07, Eric W. Biederman [EMAIL PROTECTED] wrote:
Chuck Ebbert [EMAIL PROTECTED] writes:
Starting with kernel 2.6.19, the process directories in
/proc are sorted by number. They were sorted by process
start time in 2.6.18 and earlier. This makes the output
of procps come out in that
On 1/4/07, Segher Boessenkool <[EMAIL PROTECTED]> wrote:
> Adjusting gcc flags to eliminate optimizations is another way to go.
> Adding -fwrapv would be an excellent start. Lack of this flag breaks
> most code which checks for integer wrap-around.
Lack of the flag does not break any valid C
On 1/4/07, Segher Boessenkool [EMAIL PROTECTED] wrote:
Adjusting gcc flags to eliminate optimizations is another way to go.
Adding -fwrapv would be an excellent start. Lack of this flag breaks
most code which checks for integer wrap-around.
Lack of the flag does not break any valid C code,
Linus Torvalds writes:
[probably Mikael Pettersson] writes:
The suggestions I've had so far which I have not yet tried:
- Select a different x86 CPU in the config.
- Unfortunately the C3-2 flags seem to simply tell GCC to
schedule for ppro (like i686) and enabled MMX and SSE
-
There are big nasty bugs related to threaded processes exiting,
especially when involving: zombie leaders, clone w/o SIGCHLD,
and ptrace. I can make tasks that remain until reboot. I've seen
things stuck in "X" state. I've seen pending SIGKILL and even
blocked SIGKILL. I've seen "D" state
Linus Torvalds writes:
So it would appear that for OS X, the
#define _XOPEN_SOURCE_EXTENDED 1 /* AIX 5.3L needs this */
#define _GNU_SOURCE
#define _BSD_SOURCE
sequence actually _disables_ those things.
Yes, of course. The odd one here is glibc.
Normal systems enable
On 12/20/06, David Wragg <[EMAIL PROTECTED]> wrote:
"Albert Cahalan" <[EMAIL PROTECTED]> writes:
> On Mon, Dec 18, 2006 at 11:50:08PM +, David Wragg wrote:
>> This patch (against 2.6.19/2.6.19.1) adds the four context
>> switch values (voluntary con
On 12/20/06, Jan Engelhardt <[EMAIL PROTECTED]> wrote:
>> I've originally thought about util-linux upstream fork,
>> but as usually an fork is bad step. So.. I'd like to start
>> some discussion before this step.
> ...
>> after few weeks I'm pleased to announce a new "util-linux-ng"
>> project.
On 12/20/06, Jan Engelhardt [EMAIL PROTECTED] wrote:
I've originally thought about util-linux upstream fork,
but as usually an fork is bad step. So.. I'd like to start
some discussion before this step.
...
after few weeks I'm pleased to announce a new util-linux-ng
project. This project
On 12/20/06, David Wragg [EMAIL PROTECTED] wrote:
Albert Cahalan [EMAIL PROTECTED] writes:
On Mon, Dec 18, 2006 at 11:50:08PM +, David Wragg wrote:
This patch (against 2.6.19/2.6.19.1) adds the four context
switch values (voluntary context switches, involuntary
context switches
Linus Torvalds writes:
So it would appear that for OS X, the
#define _XOPEN_SOURCE_EXTENDED 1 /* AIX 5.3L needs this */
#define _GNU_SOURCE
#define _BSD_SOURCE
sequence actually _disables_ those things.
Yes, of course. The odd one here is glibc.
Normal systems enable
There are big nasty bugs related to threaded processes exiting,
especially when involving: zombie leaders, clone w/o SIGCHLD,
and ptrace. I can make tasks that remain until reboot. I've seen
things stuck in X state. I've seen pending SIGKILL and even
blocked SIGKILL. I've seen D state pretending
Karel Zak writes:
I've originally thought about util-linux upstream fork,
but as usually an fork is bad step. So.. I'd like to start
some discussion before this step.
...
after few weeks I'm pleased to announce a new "util-linux-ng"
project. This project is a fork of the original util-linux
On 12/20/06, Mike Galbraith <[EMAIL PROTECTED]> wrote:
On Tue, 2006-12-19 at 21:46 -0500, Albert Cahalan wrote:
> Somebody PLEASE try this...
I was having enough fun with cloninator (which was whitespace munged
btw).
Anything stuck? Besides refusing to die, that beast slays debug
David Wragg writes:
Benjamin LaHaise <[EMAIL PROTECTED]> writes:
On Mon, Dec 18, 2006 at 11:50:08PM +, David Wragg wrote:
This patch (against 2.6.19/2.6.19.1) adds the four context
switch values (voluntary context switches, involuntary
context switches, and the same values accumulated
Somebody PLEASE try this...
Normally, when a process dies it becomes a zombie.
If the parent dies (before or after the child), the child
is adopted by init. Init will reap the child.
The program included below DOES NOT get reaped.
Do like so:
gcc -m32 -O2 -std=gnu99 -o foo foo.c
while true;
Somebody PLEASE try this...
Normally, when a process dies it becomes a zombie.
If the parent dies (before or after the child), the child
is adopted by init. Init will reap the child.
The program included below DOES NOT get reaped.
Do like so:
gcc -m32 -O2 -std=gnu99 -o foo foo.c
while true;
David Wragg writes:
Benjamin LaHaise [EMAIL PROTECTED] writes:
On Mon, Dec 18, 2006 at 11:50:08PM +, David Wragg wrote:
This patch (against 2.6.19/2.6.19.1) adds the four context
switch values (voluntary context switches, involuntary
context switches, and the same values accumulated from
On 12/20/06, Mike Galbraith [EMAIL PROTECTED] wrote:
On Tue, 2006-12-19 at 21:46 -0500, Albert Cahalan wrote:
Somebody PLEASE try this...
I was having enough fun with cloninator (which was whitespace munged
btw).
Anything stuck? Besides refusing to die, that beast slays debuggers
left
Karel Zak writes:
I've originally thought about util-linux upstream fork,
but as usually an fork is bad step. So.. I'd like to start
some discussion before this step.
...
after few weeks I'm pleased to announce a new util-linux-ng
project. This project is a fork of the original util-linux
I have a fun little test program for people to try. It creates zombies
that persist until reboot, despite being reparented to init. Sometimes
it creates processes that block SIGKILL, sit around with pending SIGKILL,
or both.
You'll want:
a. either assembly skills or the ability to run 32-bit
I have a fun little test program for people to try. It creates zombies
that persist until reboot, despite being reparented to init. Sometimes
it creates processes that block SIGKILL, sit around with pending SIGKILL,
or both.
You'll want:
a. either assembly skills or the ability to run 32-bit
David Singleton writes:
Add variation of /proc/PID/smaps called /proc/PID/pagemaps.
Shows reference counts for individual pages instead of aggregate totals.
Allows more detailed memory usage information for memory analysis tools.
An example of the output shows the shared text VMA for ld.so and
David Singleton writes:
Add variation of /proc/PID/smaps called /proc/PID/pagemaps.
Shows reference counts for individual pages instead of aggregate totals.
Allows more detailed memory usage information for memory analysis tools.
An example of the output shows the shared text VMA for ld.so and
On Sun, 2005-04-10 at 17:38 +0200, Rene Scharfe wrote:
> Albert, allowing access based on tty sounds nice, but it _is_ expansive.
> More importantly, perhaps, it would "virtualize" /proc: every user would
> see different permissions for certain files in there. That's too comlex
> for my taste.
On Sun, 2005-04-10 at 17:38 +0200, Rene Scharfe wrote:
Albert, allowing access based on tty sounds nice, but it _is_ expansive.
More importantly, perhaps, it would virtualize /proc: every user would
see different permissions for certain files in there. That's too comlex
for my taste.
If you
Linus Torvalds writes:
> NOTE! I detest the centralized SCM model, but if push comes to shove,
> and we just _can't_ get a reasonable parallell merge thing going in
> the short timeframe (ie month or two), I'll use something like SVN
> on a trusted site with just a few committers, and at least
Linus Torvalds writes:
NOTE! I detest the centralized SCM model, but if push comes to shove,
and we just _can't_ get a reasonable parallell merge thing going in
the short timeframe (ie month or two), I'll use something like SVN
on a trusted site with just a few committers, and at least try to
greg k-h writes:
> On Sat, Mar 26, 2005 at 10:30:20PM -0500, Lee Revell wrote:
>> That's the problem, it's not spelled out explicitly anywhere.
>> That file does not address the issue of whether a driver is
>> a "derived work". This is the part he should talk to a lawyer
>> about, right?
>
> How
greg k-h writes:
On Sat, Mar 26, 2005 at 10:30:20PM -0500, Lee Revell wrote:
That's the problem, it's not spelled out explicitly anywhere.
That file does not address the issue of whether a driver is
a derived work. This is the part he should talk to a lawyer
about, right?
How about the
On Sun, 2005-03-20 at 01:22 +0100, Rene Scharfe wrote:
> The permissions of files in /proc/1 (usually belonging to init) are
> kept as they are. The idea is to let system processes be freely
> visible by anyone, just as before. Especially interesting in this
> regard would be instances of
On Sun, 2005-03-20 at 01:22 +0100, Rene Scharfe wrote:
The permissions of files in /proc/1 (usually belonging to init) are
kept as they are. The idea is to let system processes be freely
visible by anyone, just as before. Especially interesting in this
regard would be instances of login. I
On Thu, 2005-03-17 at 16:55 +, Russell King wrote:
> On Tue, Mar 15, 2005 at 10:23:54AM -0500, Albert Cahalan wrote:
> > On Mon, 2005-03-14 at 19:22 -0800, Christoph Lameter wrote:
> > > On Mon, 14 Mar 2005, Albert Cahalan wrote:
> > >
> > > > When the
On Thu, 2005-03-17 at 16:55 +, Russell King wrote:
On Tue, Mar 15, 2005 at 10:23:54AM -0500, Albert Cahalan wrote:
On Mon, 2005-03-14 at 19:22 -0800, Christoph Lameter wrote:
On Mon, 14 Mar 2005, Albert Cahalan wrote:
When the vsyscall page is created, copy the one needed
Better interface:
/sbin/sysctl -w proc.maps=0440
/sbin/sysctl -w proc.cmdline=0444
/sbin/sysctl -w proc.status=0444
The /etc/sysctl.conf file can be used to set these
at boot time.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL
On Wed, 2005-03-16 at 03:39 +0100, Rene Scharfe wrote:
> So, I gather from the feedback I've got that chmod'able /proc/
> would be a bit over the top. 8-) While providing the easiest and most
> intuitive user interface for changing the permissions on those
> directories, it is overkill. Paul is
Russell King, the latest person to notice defects, writes:
> However, the way the kernel is setup today, this seems
> impossible to achieve, which tends to make the whole
> idea of capabilities completely and utterly useless.
>
> How is this stuff supposed to work? Are my ideas of
> what's
On Tue, 2005-03-15 at 15:31 +0100, Bodo Eggert wrote:
> (snipped the CC list - hope that's ok)
>
> On Mon, 14 Mar 2005, Albert Cahalan wrote:
> > On Tue, 2005-03-15 at 00:08 +0100, Bodo Eggert wrote:
> > > On Mon, 14 Mar 2005, Albert Cahalan wrote:
> > Th
On Mon, 2005-03-14 at 19:22 -0800, Christoph Lameter wrote:
> On Mon, 14 Mar 2005, Albert Cahalan wrote:
>
> > When the vsyscall page is created, copy the one needed function
> > into it. The kernel is already self-modifying in many places; this
> > is nothing new.
>
&
On Mon, 2005-03-14 at 19:22 -0800, Christoph Lameter wrote:
On Mon, 14 Mar 2005, Albert Cahalan wrote:
When the vsyscall page is created, copy the one needed function
into it. The kernel is already self-modifying in many places; this
is nothing new.
AFAIK this will only works on ia32
On Tue, 2005-03-15 at 15:31 +0100, Bodo Eggert wrote:
(snipped the CC list - hope that's ok)
On Mon, 14 Mar 2005, Albert Cahalan wrote:
On Tue, 2005-03-15 at 00:08 +0100, Bodo Eggert wrote:
On Mon, 14 Mar 2005, Albert Cahalan wrote:
This really isn't about security.
Information
Russell King, the latest person to notice defects, writes:
However, the way the kernel is setup today, this seems
impossible to achieve, which tends to make the whole
idea of capabilities completely and utterly useless.
How is this stuff supposed to work? Are my ideas of
what's supposed to
On Wed, 2005-03-16 at 03:39 +0100, Rene Scharfe wrote:
So, I gather from the feedback I've got that chmod'able /proc/pid
would be a bit over the top. 8-) While providing the easiest and most
intuitive user interface for changing the permissions on those
directories, it is overkill. Paul is
Better interface:
/sbin/sysctl -w proc.maps=0440
/sbin/sysctl -w proc.cmdline=0444
/sbin/sysctl -w proc.status=0444
The /etc/sysctl.conf file can be used to set these
at boot time.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL
On Tue, 2005-03-15 at 00:08 +0100, Bodo Eggert wrote:
> On Mon, 14 Mar 2005, Albert Cahalan wrote:
> > On Mon, 2005-03-14 at 10:42 +0100, Rene Scharfe wrote:
> > > Albert Cahalan wrote:
>
> > > Why do you think users should not be allowed to chmod their processes'
&
On Mon, 2005-03-14 at 12:27 -0800, Matt Mackall wrote:
> On Mon, Mar 14, 2005 at 12:04:07PM -0800, john stultz wrote:
> > > > > > > > +static inline cycle_t read_timesource(struct timesource_t* ts)
> > > > > > > > +{
> > > > > > > > + switch (ts->type) {
> > > > > > > > + case
On Mon, 2005-03-14 at 10:42 +0100, Rene Scharfe wrote:
> Albert Cahalan wrote:
> > This is a bad idea. Users should not be allowed to
> > make this decision. This is rightly a decision for
> > the admin to make.
>
> Why do you think users should not be allowed to chmo
On Mon, 2005-03-14 at 10:42 +0100, Rene Scharfe wrote:
Albert Cahalan wrote:
This is a bad idea. Users should not be allowed to
make this decision. This is rightly a decision for
the admin to make.
Why do you think users should not be allowed to chmod their processes'
/proc directories
On Mon, 2005-03-14 at 12:27 -0800, Matt Mackall wrote:
On Mon, Mar 14, 2005 at 12:04:07PM -0800, john stultz wrote:
+static inline cycle_t read_timesource(struct timesource_t* ts)
+{
+ switch (ts-type) {
+ case TIMESOURCE_MMIO_32:
+
On Tue, 2005-03-15 at 00:08 +0100, Bodo Eggert wrote:
On Mon, 14 Mar 2005, Albert Cahalan wrote:
On Mon, 2005-03-14 at 10:42 +0100, Rene Scharfe wrote:
Albert Cahalan wrote:
Why do you think users should not be allowed to chmod their processes'
/proc directories? Isn't it similar
> OK, folks, another try to enhance privacy by hiding
> process details from other users. Why not simply use
> chmod to set the permissions of /proc/ directories?
> This patch implements it.
>
> Children processes inherit their parents' proc
> permissions on fork. You can only set (and remove)
>
OK, folks, another try to enhance privacy by hiding
process details from other users. Why not simply use
chmod to set the permissions of /proc/pid directories?
This patch implements it.
Children processes inherit their parents' proc
permissions on fork. You can only set (and remove)
read
On Fri, 2005-03-11 at 19:15 +, Alan Cox wrote:
> > You forgot the PCI domain (a.k.a. hose, phb...) number.
> > Also, you might encode bus,slot,function according to
> > the PCI spec. So that gives:
> >
> > long usr_pci_open(unsigned pcidomain, unsigned devspec, __u64 dmamask);
>
> Still
On Fri, 2005-03-11 at 19:15 +, Alan Cox wrote:
You forgot the PCI domain (a.k.a. hose, phb...) number.
Also, you might encode bus,slot,function according to
the PCI spec. So that gives:
long usr_pci_open(unsigned pcidomain, unsigned devspec, __u64 dmamask);
Still insufficient
Peter Chubb writes:
> There are three new system calls:
>
> long usr_pci_open(int bus, int slot, int function, __u64 dma_mask);
> Returns a filedescriptor for the PCI device described
> by bus,slot,function. It also enables the device, and sets it
> up as a
Lennart Sorensen writes:
> You forgot the very important:
>- Only works on architecture it was compiled for. So anyone not
> using i386 (and maybe later x86-64) is simply out of luck. What do
> nvidia users that want accelerated nvidia drivers for X DRI do
> right now if they
Lennart Sorensen writes:
You forgot the very important:
- Only works on architecture it was compiled for. So anyone not
using i386 (and maybe later x86-64) is simply out of luck. What do
nvidia users that want accelerated nvidia drivers for X DRI do
right now if they have
Peter Chubb writes:
There are three new system calls:
long usr_pci_open(int bus, int slot, int function, __u64 dma_mask);
Returns a filedescriptor for the PCI device described
by bus,slot,function. It also enables the device, and sets it
up as a
Christoph Hellwig writes:
> On Sat, Mar 05, 2005 at 07:40:06PM -0500, Robert Love wrote:
>> On Sun, 2005-03-06 at 00:04 +, Christoph Hellwig wrote:
>>> The user interface is still bogus.
>>
>> I presume you are talking about the ioctl. I have tried to engage you
>> and others on what
Christoph Hellwig writes:
On Sat, Mar 05, 2005 at 07:40:06PM -0500, Robert Love wrote:
On Sun, 2005-03-06 at 00:04 +, Christoph Hellwig wrote:
The user interface is still bogus.
I presume you are talking about the ioctl. I have tried to engage you
and others on what exactly you prefer
On Thu, 2005-02-24 at 22:49 -0800, Chris Wright wrote:
> * Albert Cahalan ([EMAIL PROTECTED]) wrote:
> > Assuming you'd like ps to print the LUID, how about
> > putting it with all the others? There are "Uid:"
> > lines in the /proc/*/status files.
>
>
On Thu, 2005-02-24 at 22:49 -0800, Chris Wright wrote:
* Albert Cahalan ([EMAIL PROTECTED]) wrote:
Assuming you'd like ps to print the LUID, how about
putting it with all the others? There are Uid:
lines in the /proc/*/status files.
It's also set (written) via /proc, so it should
Assuming you'd like ps to print the LUID, how about
putting it with all the others? There are "Uid:"
lines in the /proc/*/status files.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
[quoting various people...]
> Here is a new entry developed for /proc that prints for each process
> memory area (VMA) the size of rss. The maps from original kernel is
> able to present the virtual size for each vma, but not the physical
> size (rss). This entry can provide an additional
[quoting various people...]
Here is a new entry developed for /proc that prints for each process
memory area (VMA) the size of rss. The maps from original kernel is
able to present the virtual size for each vma, but not the physical
size (rss). This entry can provide an additional
Assuming you'd like ps to print the LUID, how about
putting it with all the others? There are Uid:
lines in the /proc/*/status files.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
101 - 173 of 173 matches
Mail list logo
