* Getting rid of SHMMAX/SHMALL ?
From: Andi Kleen @ 2005-08-04 11:39 UTC (permalink / raw)
To: linux-kernel; +Cc: cr, linux-mm
I noticed that even 64bit architectures have a ridiculously low
max limit on shared memory segments by default:
#define SHMMAX 0x2000000 /* max shared seg size (bytes) */
#define SHMMNI 4096 /* max num of segs system wide */
#define SHMALL (SHMMAX/PAGE_SIZE*(SHMMNI/16)) /* max shm system wide (pages) */
Even on 32bit architectures it is far too small and doesn't
make much sense. Does anybody remember why we even have this limit?
IMHO per process shm mappings should just be controlled by the normal
process and global mappings with the same heuristics as tmpfs
(by default max memory / 2 or more if shmfs is mounted with more)
Actually I suspect databases will usually want to use more
so it might even make sense to support max memory - 1/8*max_memory
I would propose to get rid of of shmmax completely
and only keep the old shmall sysctl for compatibility.
Comments?
-Andi
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: Can mtd support 10 bytes ECC
From: Thomas Gleixner @ 2005-08-04 11:41 UTC (permalink / raw)
To: Sunil Khandelwal; +Cc: linux-mtd
In-Reply-To: <6.0.1.1.0.20050803093247.0346bf70@mail.neomagic.com>
On Wed, 2005-08-03 at 09:38 +0530, Sunil Khandelwal wrote:
> Hi
>
> NAND Flash controller on our ARM based board has a mode where in, it writes
> 10 bytes of Reed-Solomon code on last 10 Bytes of OOB.
10 bytes RS code for 2048 bytes of data ?
Does the controller write the bytes automatically ?
Is there a datasheet of this controller available ?
> On read it can do
> error correction in the data read before transferring them to buffers. Does
> existing mtd layer can work with such controllers.
It will not work out of the box, but without further information I can
not even tell you which changes are necessary to fix this.
tglx
^ permalink raw reply
* RE: [PATCH 6/7] aacraid: unlock around kfree
From: Salyzyn, Mark @ 2005-08-04 11:33 UTC (permalink / raw)
To: James Bottomley, Mark Haverkamp; +Cc: linux-scsi
Good to know. I went through one too many code reviews and had no
defense against the request.
There is a follow-up to this one not yet submitted to MarkH where I
endeavor to pre-allocate with kmalloc(,GFP_ATOMIC|GFP_KERNEL) a pool
before entering a locked list traversal rather than risking making the
calls with the locks held. The code is in an independent kernel thread
handling deferred actions triggered by the interrupt. Am I barking up
the wrong tree?
Sincerely -- Mark Salyzyn
-----Original Message-----
From: James Bottomley [mailto:James.Bottomley@SteelEye.com]
Sent: Wednesday, August 03, 2005 7:07 PM
To: Mark Haverkamp
Cc: linux-scsi; Salyzyn, Mark
Subject: Re: [PATCH 6/7] aacraid: unlock around kfree
On Wed, 2005-08-03 at 15:39 -0700, Mark Haverkamp wrote:
> kfree has the possibility of sleeping. It is generally considered poor
> manners to hold on to a lock with the possibility of a system call
> induced sleep.
Erm, this isn't true ... we'd have no end of driver issues if kfree
could block.
James
^ permalink raw reply
* Re: Mask error in nandbase.c: nand_scan(): oob_size
From: Thomas Gleixner @ 2005-08-04 11:35 UTC (permalink / raw)
To: Nathan H.; +Cc: linux-mtd
In-Reply-To: <BAY106-F1441981113829DBB9BB23B98C50@phx.gbl>
On Wed, 2005-08-03 at 15:35 -0600, Nathan H. wrote:
> The code line should be:
> mtd->oobsize = (8 << (extid & 0x01)) * (mtd->oobblock / 512);
> ^fix
>
> Reference: Page 31 (Table: 4th ID Data)
> http://www.samsung.com/Products/Semiconductor/Flash/NAND/2Gbit/K9F2G08U0M/ds_k9f2gxxu0m_rev10.pdf
Please look into
http://www.samsung.com/Products/Semiconductor/Flash/NAND/16Gbit/K9WAG08U1M/ds_k9wag08u1m_rev02.pdf
to see why the bits are reserved are why they are guaranteed to be zero.
No error to see here :)
tglx
^ permalink raw reply
* Re: 2.6.13-rc3-mm3
From: Richard Purdie @ 2005-08-04 11:27 UTC (permalink / raw)
To: Christoph Lameter; +Cc: Andrew Morton, linux-kernel, nickpiggin
In-Reply-To: <Pine.LNX.4.62.0508031716001.24733@graphe.net>
On Wed, 2005-08-03 at 17:19 -0700, Christoph Lameter wrote:
> Could you try the following patch? I think the problem was that higher
> addressses were not mappable via the page fault handler. This patch
> inserts the pmd entry into the pgd as necessary if the pud level is
> folded.
I tried this patch against 2.6.13-rc4-mm1 and there was no change - X
still hung in memcpy as before and the cmpxchg_fail_flag_update just
increases...
Richard
^ permalink raw reply
* [ALSA - driver 0000879]: (snd_)opl3sa2 (isa) doesn't work (fails on playback) on 2.6.x kernels
From: bugtrack @ 2005-08-04 11:25 UTC (permalink / raw)
To: alsa-devel
A NOTE has been added to this issue.
======================================================================
<https://bugtrack.alsa-project.org/alsa-bug/view.php?id=879>
======================================================================
Reported By: iive
Assigned To:
======================================================================
Project: ALSA - driver
Issue ID: 879
Category: ISA - opl3sa2
Reproducibility: always
Severity: block
Priority: normal
Status: new
Distribution: Slackware 10
Kernel Version: all 2.6.x kernel version (current 2.6.10)
======================================================================
Date Submitted: 02-03-2005 03:42 CET
Last Modified: 08-04-2005 13:25 CEST
======================================================================
Summary: (snd_)opl3sa2 (isa) doesn't work (fails on playback)
on 2.6.x kernels
Description:
It doesn't work on all 2.6.x kernel I have tried (current 2.6.10)
alsaconf doesn't detect the card as PnP, and fails to find it with
bruteforce.
When module is loaded by hand it shows no error, but on `aplay samle.wav`
I got
"ALSA /work/install/alsa-driver-1.0.5a/alsa-kernel/core/pcm_lib.c:2172:
playback
write error (DMA or IRQ trouble?"
on boot with 2.4.x kernel, everything magically works (alsaconf, aplay
etc..)
the bug is reported 4 months ago on
http://bugzilla.kernel.org/show_bug.cgi?id=3117
that's why some versions are old (but I had tried alsa-1.0.8 before
reposting this bug here)
======================================================================
Relationships ID Summary
----------------------------------------------------------------------
related to 0001296 isapnp is incompatible with pnpbios and...
======================================================================
----------------------------------------------------------------------
ahaning - 08-04-05 12:52
----------------------------------------------------------------------
When I compile all drivers (not just --with-cards=opl3sa2) none of them
work.
I have now enabled kernel and BIOS support for PnP. With
alsa-driver-1.0.9b compiled with --with-cards=opl3sa2, no PnP or PCI cards
are found.
I don't see why I should need drivers other than opl3sa2.
----------------------------------------------------------------------
perex - 08-04-05 13:25
----------------------------------------------------------------------
Please, follow my instructions. I have not written to recompile other
drivers. I meant that in alsaconf should be selected the pnp card not
probing of legacy cards.
Also, follow ALL requests from
https://bugtrack.alsa-project.org/alsa-bug/view.php?id=879#5608 and
https://bugtrack.alsa-project.org/alsa-bug/view.php?id=879#5641. If you do
only partial steps, it avoids me to do proper conclusions. I don't have
opl3sa2 system around, so I rely on your input.
Issue History
Date Modified Username Field Change
======================================================================
02-03-05 03:42 iive New Issue
02-03-05 03:42 iive File Added: isa_opl3sa2.tgz
02-03-05 03:42 iive Distribution => Slackware 10
02-03-05 03:42 iive Kernel Version => all 2.6.x kernel
version (current 2.6.10)
04-13-05 21:59 jdthood Note Added: 0004478
04-14-05 00:02 iive Note Added: 0004485
07-09-05 06:26 ahaning Note Added: 0005438
07-09-05 06:38 ahaning Note Edited: 0005438
07-09-05 11:13 jdthood Note Added: 0005439
07-09-05 11:14 jdthood Note Added: 0005440
07-28-05 05:17 ahaning Note Added: 0005577
08-02-05 00:02 iive Note Added: 0005599
08-02-05 03:00 ahaning Note Added: 0005600
08-02-05 03:05 ahaning Note Added: 0005601
08-02-05 03:05 ahaning Note Deleted: 0005600
08-02-05 22:08 perex File Added: alsaconf-isapnp-2.6.patch
08-02-05 22:14 perex Note Added: 0005607
08-02-05 22:16 perex Note Added: 0005608
08-03-05 02:46 ahaning Note Added: 0005610
08-03-05 11:42 perex File Added: alsaconf
08-03-05 11:42 perex Note Added: 0005615
08-03-05 13:42 ahaning Note Added: 0005625
08-03-05 15:17 ahaning Note Added: 0005631
08-04-05 08:51 perex Note Added: 0005641
08-04-05 08:52 perex Relationship added related to 0001296
08-04-05 12:52 ahaning Note Added: 0005644
08-04-05 13:25 perex Note Added: 0005645
======================================================================
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
^ permalink raw reply
* Re: 2.4.21: Sharing interrupts with serial console
From: linux-os (Dick Johnson) @ 2005-08-04 11:16 UTC (permalink / raw)
To: Chris Budd; +Cc: Linux kernel, linux-serial
In-Reply-To: <92fc8b8105080318367f77fed1@mail.gmail.com>
On Wed, 3 Aug 2005, Chris Budd wrote:
> I have read http://www.tldp.org/HOWTO/Remote-Serial-Console-HOWTO/preparation-setport.html
> and http://www.linux-mips.org/archives/linux-mips/2004-04/msg00134.html
> and other items, but I still have not found the answers to the
> following questions:
>
> 1. The rs_init function in ./linux-2.4.21/drivers/char/serial.c
> explicitly states "The interrupt of the serial console port can't be
> shared." Does this include *ALL* interrupts? The code checks for
> sharing only with other serial devices, not *ALL* types of devices
> like I2C, RTC, etc.
>
> 2. While the presence of the comment about not sharing was nice, it
> does not explain "why?" Why can't we share the serial console
> interrupt? The serial console seems to work when I alter serial.c to
> skip this check for the sharing of interrupts with the serial console.
>
> 3. Does the hardware platform matter? We are running Linux 2.4.21 on
> an embedded XScale(ARM)-based board.
>
> Thanks,
> Chris.
> -
Only LEVEL interrupts can be shared, and all the drivers that
share that one interrupt need to be designed for sharing.
Cheers,
Dick Johnson
Penguin : Linux version 2.6.12 on an i686 machine (5537.79 BogoMips).
Warning : 98.36% of all statistics are fiction.
.
I apologize for the following. I tried to kill it with the above dot :
****************************************************************
The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to DeliveryErrors@analogic.com - and destroy all copies of this information, including any attachments, without reading or disclosing them.
Thank you.
^ permalink raw reply
* Re: 2.4.21: Sharing interrupts with serial console
From: linux-os (Dick Johnson) @ 2005-08-04 11:16 UTC (permalink / raw)
To: Chris Budd; +Cc: Linux kernel, linux-serial
In-Reply-To: <92fc8b8105080318367f77fed1@mail.gmail.com>
On Wed, 3 Aug 2005, Chris Budd wrote:
> I have read http://www.tldp.org/HOWTO/Remote-Serial-Console-HOWTO/preparation-setport.html
> and http://www.linux-mips.org/archives/linux-mips/2004-04/msg00134.html
> and other items, but I still have not found the answers to the
> following questions:
>
> 1. The rs_init function in ./linux-2.4.21/drivers/char/serial.c
> explicitly states "The interrupt of the serial console port can't be
> shared." Does this include *ALL* interrupts? The code checks for
> sharing only with other serial devices, not *ALL* types of devices
> like I2C, RTC, etc.
>
> 2. While the presence of the comment about not sharing was nice, it
> does not explain "why?" Why can't we share the serial console
> interrupt? The serial console seems to work when I alter serial.c to
> skip this check for the sharing of interrupts with the serial console.
>
> 3. Does the hardware platform matter? We are running Linux 2.4.21 on
> an embedded XScale(ARM)-based board.
>
> Thanks,
> Chris.
> -
Only LEVEL interrupts can be shared, and all the drivers that
share that one interrupt need to be designed for sharing.
Cheers,
Dick Johnson
Penguin : Linux version 2.6.12 on an i686 machine (5537.79 BogoMips).
Warning : 98.36% of all statistics are fiction.
.
I apologize for the following. I tried to kill it with the above dot :
****************************************************************
The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to DeliveryErrors@analogic.com - and destroy all copies of this information, including any attachments, without reading or disclosing them.
Thank you.
^ permalink raw reply
* Re: a command "spool", ie queueing commands?
From: Glynn Clements @ 2005-08-04 11:16 UTC (permalink / raw)
To: urgrue; +Cc: linux-admin
In-Reply-To: <1123140368l.3265l.0l@hyttynen>
urgrue wrote:
> > You could try something like:
> >
> > $ command1 && command2 && command3
>
> Better would be command1 ; command2 ; command3, because then it won't
> depend on the previous command coming out true.
Well, whether or not it's better depends upon whether you want to
conditionalise execution of one command upon success of the previous
command.
I find it far more common for scripts to use ";" when they really
should have used "&&" than the converse. A particularly common case
is "cd foo ; dosomething"; this should almost always be using "&&".
--
Glynn Clements <glynn@gclements.plus.com>
^ permalink raw reply
* Re: IDE disk and HPA
From: Alan Cox @ 2005-08-04 11:41 UTC (permalink / raw)
To: Oliver Tennert; +Cc: linux-kernel
In-Reply-To: <200508040914.10810.tennert@science-computing.de>
On Iau, 2005-08-04 at 09:14 +0200, Oliver Tennert wrote:
> partitioning and filesystems. The point is, IF there is an HPA, there MIGHT
> be a partitioning scheme and some filesystems on the disk which rely on the
> size of disk being the native size MINUS the HPA.
Thats fine, Linux is quite happy with such a partitioning table.
> Also there might be some contents in the HPA which is vulnerable to deletion
> if exposed to the OS in such a transparent way.
By opening the raw disk file yes, but that is not a big concern
> Why is the HPA not just left alone?
As I said before - because in most cases the HPA is used just to fool an
old bios into booting a large disk.
^ permalink raw reply
* Re: Starting "Script" when user logs on.
From: Glynn Clements @ 2005-08-04 11:11 UTC (permalink / raw)
To: Md Shanto; +Cc: linux-admin
In-Reply-To: <b30595cd050803033826add037@mail.gmail.com>
Md Shanto wrote:
> Initially I tired with "ttyrec" a tty recorder and failed, as it says
> "Out of pty's - Terminated".
Unless these processes aren't being cleaned up (in which case, you
will probably have over a hundred stale ttyrec processes), it may be
that ttyrec was compiled for BSD-style ptys but your system is using
Unix98 ptys (or vice-versa).
> Now, I tried something like below:
>
> ------------------
> #!/bin/bash -l
> USER=`whoami`
> LOGTIME=`date +%Y-%m-%d-%H:%M:%S`
> /usr/bin/script -q /var/log/commlog/$USER-$LOGTIME
> ------------------
Apart from anything else, you should probably use "exec" for the last
statement, i.e.:
exec /usr/bin/script -q /var/log/commlog/$USER-$LOGTIME
This causes the "script" process to replace the bash process running
the shell script, rather than leaving the bash process hanging around
until script exits.
^ permalink raw reply
* Re: Compiling uClibc with MIPS SDE6
From: Nigel Stephens @ 2005-08-04 11:12 UTC (permalink / raw)
To: colin; +Cc: linux-mips
In-Reply-To: <009b01c598d5$2ede3e20$106215ac@realtek.com.tw>
colin wrote:
>Hi there,
>I encounter a problem when compiling uClibc with SDE6. If compiling with
>debug information enabled, the output executable file of busybox is about
>the same with the one that is compiled with SDE5, but uClibc libraries are
>over 10 times the size of the ones that are compiled with SDE5. I am
>wondering if it is because GCC 3.4.4 of SDE6 has changed some parameters
>setting?
>
>
>
SDE 6 uses Dwarf-2 debug data, whereas SDE 5 used Stabs. That may
explain the difference.
Nigel
--
Nigel Stephens Mailto:nigel@mips.com
_ _ ____ ___ MIPS Technologies Phone.: +44 1223 706200
|\ /|||___)(___ The Fruit Farm Direct: +44 1223 706207
| \/ ||| ____) Ely Road, Chittering Fax...: +44 1223 706250
TECHNOLOGIES UK Cambridge CB5 9PH Cell..: +44 7976 686470
England http://www.mips.com
^ permalink raw reply
* Re: relationship between standard C and gcc compiler suite?
From: Glynn Clements @ 2005-08-04 11:06 UTC (permalink / raw)
To: Robert P. J. Day; +Cc: C programming list
In-Reply-To: <Pine.LNX.4.63.0508030942160.7360@localhost.localdomain>
Robert P. J. Day wrote:
> according to my 5th ed. of H&S, C99 introduced the unsigned integer
> type "_Bool" and refers to the corresponding header file stdbool.h.
> but on my linux system, that header file is not in the standard
> /usr/include directory, where i would have expected it.
>
> rather, it's included with gcc-4.0.1, and it's in this directory:
>
> /usr/lib/gcc/i386-redhat-linux/4.0.1/include
>
> i'm sure the end result is the same in that i can just
>
> #include <stdbool.h>
>
> but is there some kind of overall rationale as to what "standard"
> header files would actually be supplied by gcc itself? just trying to
> figure out the pattern here. obviously, this question generalizes to
> more than just asking about the boolean file.
The rationale is essentially making things work on systems where the
system's libc isn't GNU libc.
If a header is in gcc's private include directory, it usually
indicates that the OS installs its own copy of the header in
/usr/include, but that header won't work with gcc. gcc searches its
private include directory before /usr/include, so gcc-specific headers
override the system's versions.
--
Glynn Clements <glynn@gclements.plus.com>
^ permalink raw reply
* Re: [PATCH 2.6.13-rc4-mm1] Re: Obsolete files in 2.6 tree
From: Jiri Slaby @ 2005-08-04 11:01 UTC (permalink / raw)
To: Jiri Slaby
Cc: Alan Cox, Vojtech Pavlik, Jiri Slaby, Linux Kernel Mailing List,
dri-devel, Andrew Morton, Linus Torvalds
In-Reply-To: <42F14A9B.2050803@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1117 bytes --]
Jiri Slaby napsal(a):
> Alan Cox napsal(a):
>
>>>> drivers/char/drm/gamma_dma.c
>>>> drivers/char/drm/gamma_drv.c
>>>>
>>>
>>
>> Gamma is defunct certainly
>>
>>
> Removes gamma sources, headers and pointers from Kconfig and Makefile.
>
> Signed-off-by: Jiri Slaby <xslaby@fi.muni.cz>
>
> patch is here (about 70 KiB):
> http://www.fi.muni.cz/~xslaby/lnx/gamma.txt
>
Removes gamma line from Documentation/kernel-parameters.txt
Signed-off-by: Jiri Slaby <xslaby@fi.muni.cz>
diff --git a/Documentation/kernel-parameters.txt
b/Documentation/kernel-parameters.txt
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -497,8 +497,6 @@ running once the system is up.
Format: <port#>,<pad1>,<pad2>,<pad3>,<pad4>,<pad5>
See also Documentation/input/joystick-parport.txt
- gamma= [HW,DRM]
-
gdth= [HW,SCSI]
See header of drivers/scsi/gdth.c.
--
Jiri Slaby www.fi.muni.cz/~xslaby
~\-/~ jirislaby@gmail.com ~\-/~
241B347EC88228DE51EE A49C4A73A25004CB2A10
[-- Attachment #2: gamma_doc_rm.txt --]
[-- Type: text/plain, Size: 414 bytes --]
diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -497,8 +497,6 @@ running once the system is up.
Format: <port#>,<pad1>,<pad2>,<pad3>,<pad4>,<pad5>
See also Documentation/input/joystick-parport.txt
- gamma= [HW,DRM]
-
gdth= [HW,SCSI]
See header of drivers/scsi/gdth.c.
^ permalink raw reply
* Re: Running script on 2.6 fails
From: Andrzej Doyle @ 2005-08-04 11:00 UTC (permalink / raw)
To: Mukund JB.; +Cc: linux-newbie
In-Reply-To: <C349E772C72290419567CFD84C26E0170423C7@mail.esn.co.in>
Mukund JB. wrote:
>>>[Error is:]
>>># sh sbull_load
>>>: command not found
>>>' bull_load: line 4: syntax error near unexpected token '{
>>>' bull_load: line 4: '{
>
>Dear Arturas,
>
>Please see the entire sbull_load script below
>
>Regards,
>Mukund Jampala
>
>-------------------------- sbull_load script
>-------------------------------
>
>#!/bin/sh
>
>function make_minors {
>
> let part=1
>
> while (($part < $minors)); do
>
> let minor=$part+$2
>
> mknod $1$part b $major $minor
>
> let part=$part+1
>
> done
>
>}
>
>...
>
>------------------------- sbull_load script ENDS
>--------------------------
>
>
Line 4 of your script is the while(...) do line. Although I'm by no
means an expert in shell scripting, I can see that you're referencing
the variable $minors before either declaring it or initialising it.
Though this might not actually throw an error, it's bad programming
practice, since as well as the possibility of the 'default' value
changing, it also makes your program harder to read. I see you set the
variable in the loop, so you could either change it into a do ... while
loop (if you know you'll be going through it at least once), or just add
another "let minor=$part+$2" line just after the "let part=1" line.
That said, I don't see a single '{' in that area of code that the shell
could be complaining about. Since it's mentioning bull_load, and you've
give us sbull_load (note extra s), are you sure you're running the
script you intended, and not (perhaps) an older version of it? If not,
and bull_load is a short little thing that calls sbull_load to do the
actual work, I'd still need to see bull_load since that's where the
error lies.
Andrzej
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs
^ permalink raw reply
* Re: [PATCH 2.6.12.3] Deny chmod in /proc/<pid>/
From: Johan Veenhuizen @ 2005-08-04 10:59 UTC (permalink / raw)
To: Jan Engelhardt; +Cc: linux-kernel
In-Reply-To: <Pine.LNX.4.61.0508040804540.22272@yvahk01.tjqt.qr>
Jan Engelhardt <jengelh@linux01.gwdg.de> wrote:
>
> >Did you mean "chmod"?
>
> No, I really meant chown - which just turned up another should-not-be:
> no warning is generated when trying to chown;
> chmod is even _persistent_ - for the moment.
>
Did you even bother to read my first mail? Quoting myself:
"The patch does also trigger an EPERM when someone tries
to chown/chgrp an entry (which is currently silently ignored)."
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
and
"... it is currently possible for the owner of a process to
temporarily chmod the entries."
Those are the problems that my patch fixes! And NO, chmod is NOT
persistent. It just appears to be. The permissions are dropped
when the dentry for a file is released (and with it, the reference
to the temporary inode). (You might have understood this.
I don't know what you mean by "for the moment".)
It's a very Bad Thing that the chmod succeeds for a while, because
it gives users the impression that the files can be protected
(e.g. /proc/<pid>/cmdline). As it is now, you'll have to look
at the kernel source to figure out which files will preserve
their permissions...
> >And I don't even have "smaps".
>
> Just take any file.
Not any file exists under /proc, so I'll rather take a file that
is there for my examples.
Johan
^ permalink raw reply
* Re: [patch 8/8] x86_64: Choose physflat for AMD systems only when >8 CPUS.
From: Andi Kleen @ 2005-08-04 10:54 UTC (permalink / raw)
To: Ashok Raj; +Cc: Andrew Morton, zwane, linux-kernel
In-Reply-To: <20050801203011.746098000@araj-em64t>
On Mon, Aug 01, 2005 at 01:20:25PM -0700, Ashok Raj wrote:
> It is not required to choose the physflat mode when CPU hotplug is enabled
> and CPUs <=8 case. Use of genapic_flat with the mask version is capable of
> doing the same, instead of doing the send_IPI_mask_sequence() where its a
> unicast.
>
> This is another change that Andi introduced with the physflat mode.
>
> Andi: Do you think this is acceptable?
Yes it's ok.
-Andi
^ permalink raw reply
* [ALSA - driver 0000879]: (snd_)opl3sa2 (isa) doesn't work (fails on playback) on 2.6.x kernels
From: bugtrack @ 2005-08-04 10:52 UTC (permalink / raw)
To: alsa-devel
A NOTE has been added to this issue.
======================================================================
<https://bugtrack.alsa-project.org/alsa-bug/view.php?id=879>
======================================================================
Reported By: iive
Assigned To:
======================================================================
Project: ALSA - driver
Issue ID: 879
Category: ISA - opl3sa2
Reproducibility: always
Severity: block
Priority: normal
Status: new
Distribution: Slackware 10
Kernel Version: all 2.6.x kernel version (current 2.6.10)
======================================================================
Date Submitted: 02-03-2005 03:42 CET
Last Modified: 08-04-2005 12:52 CEST
======================================================================
Summary: (snd_)opl3sa2 (isa) doesn't work (fails on playback)
on 2.6.x kernels
Description:
It doesn't work on all 2.6.x kernel I have tried (current 2.6.10)
alsaconf doesn't detect the card as PnP, and fails to find it with
bruteforce.
When module is loaded by hand it shows no error, but on `aplay samle.wav`
I got
"ALSA /work/install/alsa-driver-1.0.5a/alsa-kernel/core/pcm_lib.c:2172:
playback
write error (DMA or IRQ trouble?"
on boot with 2.4.x kernel, everything magically works (alsaconf, aplay
etc..)
the bug is reported 4 months ago on
http://bugzilla.kernel.org/show_bug.cgi?id=3117
that's why some versions are old (but I had tried alsa-1.0.8 before
reposting this bug here)
======================================================================
Relationships ID Summary
----------------------------------------------------------------------
related to 0001296 isapnp is incompatible with pnpbios and...
======================================================================
----------------------------------------------------------------------
perex - 08-04-05 08:51
----------------------------------------------------------------------
You are trying configure legacy cards. Don't try that (select only detected
PnP card in alsaconf). The option opl3sa2 line with manual resources
should NOT be present in the generated configuration. Select only detected
card (and try to remove the whole ALSACONF block from modprobe.conf).
----------------------------------------------------------------------
ahaning - 08-04-05 12:52
----------------------------------------------------------------------
When I compile all drivers (not just --with-cards=opl3sa2) none of them
work.
I have now enabled kernel and BIOS support for PnP. With
alsa-driver-1.0.9b compiled with --with-cards=opl3sa2, no PnP or PCI cards
are found.
I don't see why I should need drivers other than opl3sa2.
Issue History
Date Modified Username Field Change
======================================================================
02-03-05 03:42 iive New Issue
02-03-05 03:42 iive File Added: isa_opl3sa2.tgz
02-03-05 03:42 iive Distribution => Slackware 10
02-03-05 03:42 iive Kernel Version => all 2.6.x kernel
version (current 2.6.10)
04-13-05 21:59 jdthood Note Added: 0004478
04-14-05 00:02 iive Note Added: 0004485
07-09-05 06:26 ahaning Note Added: 0005438
07-09-05 06:38 ahaning Note Edited: 0005438
07-09-05 11:13 jdthood Note Added: 0005439
07-09-05 11:14 jdthood Note Added: 0005440
07-28-05 05:17 ahaning Note Added: 0005577
08-02-05 00:02 iive Note Added: 0005599
08-02-05 03:00 ahaning Note Added: 0005600
08-02-05 03:05 ahaning Note Added: 0005601
08-02-05 03:05 ahaning Note Deleted: 0005600
08-02-05 22:08 perex File Added: alsaconf-isapnp-2.6.patch
08-02-05 22:14 perex Note Added: 0005607
08-02-05 22:16 perex Note Added: 0005608
08-03-05 02:46 ahaning Note Added: 0005610
08-03-05 11:42 perex File Added: alsaconf
08-03-05 11:42 perex Note Added: 0005615
08-03-05 13:42 ahaning Note Added: 0005625
08-03-05 15:17 ahaning Note Added: 0005631
08-04-05 08:51 perex Note Added: 0005641
08-04-05 08:52 perex Relationship added related to 0001296
08-04-05 12:52 ahaning Note Added: 0005644
======================================================================
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
^ permalink raw reply
* Re: [patch 5/8] x86_64:Dont do broadcast IPIs when hotplug is enabled in flat mode.
From: Andi Kleen @ 2005-08-04 10:51 UTC (permalink / raw)
To: Ashok Raj; +Cc: Andrew Morton, zwane, linux-kernel
In-Reply-To: <20050801203011.403184000@araj-em64t>
> static void flat_send_IPI_allbutself(int vector)
> {
> +#ifndef CONFIG_HOTPLUG_CPU
> if (((num_online_cpus()) - 1) >= 1)
> __send_IPI_shortcut(APIC_DEST_ALLBUT, vector,APIC_DEST_LOGICAL);
> +#else
> + cpumask_t allbutme = cpu_online_map;
> + int me = get_cpu(); /* Ensure we are not preempted when we clear */
> + cpu_clear(me, allbutme);
> + flat_send_IPI_mask(allbutme, vector);
> + put_cpu();
This still needs the num_online_cpus()s check.
-Andi
^ permalink raw reply
* [PATCH] Keys: Fix key management syscall interface bugs
From: David Howells @ 2005-08-04 10:50 UTC (permalink / raw)
To: torvalds, akpm; +Cc: linux-kernel
The attached patch fixes five bugs in the key management syscall interface:
(1) add_key() returns 0 rather than EINVAL if the key type is "".
Checking the key type isn't "" should be left to lookup_user_key().
(2) request_key() returns ENOKEY rather than EPERM if the key type begins
with a ".".
lookup_user_key() can't do this because internal key types begin with a
".".
(3) Key revocation always returns 0, even if it fails.
(4) Key read can return EAGAIN rather than EACCES under some circumstances.
A key is permitted to by read by a process if it doesn't grant read
access, but it does grant search access and it is in the process's
keyrings. That search returns EAGAIN if it fails, and this needs
translating to EACCES.
(5) request_key() never adds the new key to the destination keyring if one is
supplied.
The wrong macro was being used to test for an error condition: PTR_ERR()
will always return true, whether or not there's an error; this should've
been IS_ERR().
Signed-Off-By: David Howells <dhowells@redhat.com>
---
warthog>diffstat -p1 keys-ui-fixes-2613rc2mm1.diff
security/keys/keyctl.c | 11 +++++++----
security/keys/request_key.c | 2 +-
2 files changed, 8 insertions(+), 5 deletions(-)
diff -uNrp linux-2.6.13-rc2-mm1/security/keys/keyctl.c linux-2.6.13-rc2-mm1-keys/security/keys/keyctl.c
--- linux-2.6.13-rc2-mm1/security/keys/keyctl.c 2005-07-07 22:23:15.000000000 +0100
+++ linux-2.6.13-rc2-mm1-keys/security/keys/keyctl.c 2005-08-04 11:48:12.000000000 +0100
@@ -49,9 +49,6 @@ asmlinkage long sys_add_key(const char _
goto error;
type[31] = '\0';
- if (!type[0])
- goto error;
-
ret = -EPERM;
if (type[0] == '.')
goto error;
@@ -144,6 +141,10 @@ asmlinkage long sys_request_key(const ch
goto error;
type[31] = '\0';
+ ret = -EPERM;
+ if (type[0] == '.')
+ goto error;
+
/* pull the description into kernel space */
ret = -EFAULT;
dlen = strnlen_user(_description, PAGE_SIZE - 1);
@@ -362,7 +363,7 @@ long keyctl_revoke_key(key_serial_t id)
key_put(key);
error:
- return 0;
+ return ret;
} /* end keyctl_revoke_key() */
@@ -685,6 +686,8 @@ long keyctl_read_key(key_serial_t keyid,
goto can_read_key2;
ret = PTR_ERR(skey);
+ if (ret == -EAGAIN)
+ ret = -EACCES;
goto error2;
}
diff -uNrp linux-2.6.13-rc2-mm1/security/keys/request_key.c linux-2.6.13-rc2-mm1-keys/security/keys/request_key.c
--- linux-2.6.13-rc2-mm1/security/keys/request_key.c 2005-07-07 22:23:15.000000000 +0100
+++ linux-2.6.13-rc2-mm1-keys/security/keys/request_key.c 2005-08-04 11:48:12.000000000 +0100
@@ -405,7 +405,7 @@ struct key *request_key_and_link(struct
key_user_put(user);
/* link the new key into the appropriate keyring */
- if (!PTR_ERR(key))
+ if (!IS_ERR(key))
request_key_link(key, dest_keyring);
}
^ permalink raw reply
* Compiling uClibc with MIPS SDE6
From: colin @ 2005-08-04 9:16 UTC (permalink / raw)
To: linux-mips
Hi there,
I encounter a problem when compiling uClibc with SDE6. If compiling with
debug information enabled, the output executable file of busybox is about
the same with the one that is compiled with SDE5, but uClibc libraries are
over 10 times the size of the ones that are compiled with SDE5. I am
wondering if it is because GCC 3.4.4 of SDE6 has changed some parameters
setting?
Regards,
Colin
^ permalink raw reply
* Re: [patch 4/8] x86_64:Fix cluster mode send_IPI_allbutself to use get_cpu()/put_cpu()
From: Andi Kleen @ 2005-08-04 10:43 UTC (permalink / raw)
To: Ashok Raj; +Cc: Andrew Morton, zwane, linux-kernel
In-Reply-To: <20050801203011.290911000@araj-em64t>
On Mon, Aug 01, 2005 at 01:20:21PM -0700, Ashok Raj wrote:
> Need to ensure we dont get prempted when we clear ourself from mask when using
> clustered mode genapic code.
It's not needed I think. If the caller wants to execute code
on the current CPU then it has to have disabled preemption
itself already to avoid races. And if not it doesn't care.
One could argue that this function should be always called
with preemption disabled though. Perhaps better a WARN_ON().
-Andi
^ permalink raw reply
* Re: [patch 3/8] x86_64:Dont call enforce_max_cpus when hotplug is enabled
From: Andi Kleen @ 2005-08-04 10:41 UTC (permalink / raw)
To: Ashok Raj; +Cc: Andrew Morton, zwane, linux-kernel
In-Reply-To: <20050801203011.178499000@araj-em64t>
On Mon, Aug 01, 2005 at 01:20:20PM -0700, Ashok Raj wrote:
> No need to enforce_max_cpus when hotplug code is enabled. This
> nukes out cpu_present_map and cpu_possible_map making it impossible to add
> new cpus in the system.
Hmm - i think there was some reason for this early zeroing,
but I cannot remember it right now.
It might be related to some checks later that check max possible cpus.
So it would be still good to have some way to limit max possible cpus.
Maybe with a new option?
-Andi
^ permalink raw reply
* Re: [patch 2/8] x86_64: create sysfs entries for cpu only for present cpus
From: Andi Kleen @ 2005-08-04 10:37 UTC (permalink / raw)
To: Ashok Raj; +Cc: Andrew Morton, zwane, linux-kernel
In-Reply-To: <20050801203011.065721000@araj-em64t>
On Mon, Aug 01, 2005 at 01:20:19PM -0700, Ashok Raj wrote:
> Need to create sysfs only for cpus that are present. Without which we see
> NR_CPUS entries created when we have CONFIG_HOTPLUG and CONFIG_HOTPLUG_CPU
> enabled.
Thanks looks good.
-Andi
>
> Signed-off-by: Ashok Raj <ashok.raj@intel.com>
> --------------------------------------------------------------
> arch/i386/mach-default/topology.c | 4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> Index: linux-2.6.13-rc3-ak/arch/i386/mach-default/topology.c
> ===================================================================
> --- linux-2.6.13-rc3-ak.orig/arch/i386/mach-default/topology.c
> +++ linux-2.6.13-rc3-ak/arch/i386/mach-default/topology.c
> @@ -76,7 +76,7 @@ static int __init topology_init(void)
> for_each_online_node(i)
> arch_register_node(i);
>
> - for_each_cpu(i)
> + for_each_present_cpu(i)
> arch_register_cpu(i);
> return 0;
> }
> @@ -87,7 +87,7 @@ static int __init topology_init(void)
> {
> int i;
>
> - for_each_cpu(i)
> + for_each_present_cpu(i)
> arch_register_cpu(i);
> return 0;
> }
>
> --
>
^ permalink raw reply
* Re: 2.6.13-rc4 - kernel panic - BUG at net/ipv4/tcp_output.c:918
From: Herbert Xu @ 2005-08-04 10:35 UTC (permalink / raw)
To: Guillaume Pelat; +Cc: davem, akpm, netdev, linux-kernel
In-Reply-To: <20050804033329.GA14501@gondor.apana.org.au>
[-- Attachment #1: Type: text/plain, Size: 413 bytes --]
On Thu, Aug 04, 2005 at 01:33:29PM +1000, herbert wrote:
>
> So I suppose we should reset cwnd_quota after tcp_transmit_skb?
Please try this patch to see if this is really the problem or not.
Thanks,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
[-- Attachment #2: p --]
[-- Type: text/plain, Size: 674 bytes --]
diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
--- a/net/ipv4/tcp_output.c
+++ b/net/ipv4/tcp_output.c
@@ -1027,19 +1027,14 @@ static int tcp_write_xmit(struct sock *s
tcp_minshall_update(tp, mss_now, skb);
sent_pkts++;
- /* Do not optimize this to use tso_segs. If we chopped up
- * the packet above, tso_segs will no longer be valid.
- */
- cwnd_quota -= tcp_skb_pcount(skb);
-
- BUG_ON(cwnd_quota < 0);
- if (!cwnd_quota)
- break;
-
skb = sk->sk_send_head;
if (!skb)
break;
+
tso_segs = tcp_init_tso_segs(sk, skb, mss_now);
+ cwnd_quota = tcp_cwnd_test(tp, skb);
+ if (!cwnd_quota)
+ break;
}
if (likely(sent_pkts)) {
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.