* Re: Freezing.. (was Re: Intel P6 vs P7 system call performance)
From: Alan Cox @ 2002-12-19 1:09 UTC (permalink / raw)
To: John Bradford
Cc: Larry McVoy, lm, alan, Linus Torvalds, davej, vonbrand,
Linux Kernel Mailing List, akpm
In-Reply-To: <200212182237.gBIMbQmk000479@darkstar.example.net>
On Wed, 2002-12-18 at 22:37, John Bradford wrote:
> I was trying to point out in an amusing way that a repeat of the BK
> flamewar we've seen on LKML was inappropriate.
I got the joke but I don't have a US postal address 8)
More seriously we have defect tracking now - > bugzilla.kernel.org
We have an advanced scalable groupware communication environment (email)
How the actual patches get applied really isnt relevant. I know Linus
hated jitterbug, Im guessing he hates bugzilla too ?
^ permalink raw reply
* Re: [PATCH]: fix compiler warnings in the math-emulator
From: Ralf Baechle @ 2002-12-19 0:20 UTC (permalink / raw)
To: Maciej W. Rozycki; +Cc: Juan Quintela, linux mips mailing list
In-Reply-To: <Pine.GSO.3.96.1021218173810.5977D-100000@delta.ds2.pg.gda.pl>
On Wed, Dec 18, 2002 at 05:43:34PM +0100, Maciej W. Rozycki wrote:
> Is it needed? The part that returns .mx should be optimized away by the
> compiler automagically if unused.
Functionally these two patches are more or less equivalent but I think
Juan's patch is more readable. Don't change the fact that the whole FP
emulator could need some heavy polishing ...
Ralf
^ permalink raw reply
* Re: 2.5.52: PDC20268 failure
From: Alan Cox @ 2002-12-19 1:03 UTC (permalink / raw)
To: Frank van de Pol; +Cc: Linux Kernel Mailing List
In-Reply-To: <20021218232901.GA20290@idefix.fvdpol.home.nl>
On Wed, 2002-12-18 at 23:28, Frank van de Pol wrote:
>
> the 2.5 series of kernels (since early ide changes) fails on my machine when
> configuring the harddisks.
Can you tell me if 2.4.21-pre does - that has the IDE changes without
the other stuff so is a good test of which bit is involved
Also try 2.5.52 with ACPI disabled
^ permalink raw reply
* After Uncompresseing Linux..., what's next
From: Prakash kanthi @ 2002-12-19 0:14 UTC (permalink / raw)
To: LinuxPPC
In-Reply-To: <200212180101.gBI11p816867@p2.parker.boston.ma.us>
Hi there,
I was trying to load linuxppc_2_4_devel onto my board.
It goes through the board info read, UART init and
Uncompressing the linux kernel. But after that, i do
not see any messages and board hangs.
Here is the UART output:
------------------------------------
OS Booting...
loaded at: 00400000 0060D1CC
board data at: 00000030 00000044
relocated to: 00405C24 00405C38
zimage at: 00406290 004A08FF
initrd at: 004A1000 006097CA
avail ram: 0060E000 007F8000
Linux/PPC load: console=ttyS0,9600 console=tty1 ip=on
root=/dev/xsysace/disc0/pa
rt3 rw
Uncompressing Linux...done.
Now booting the kernel
-------------------------------------------
After the last line, it hangs. I get a feeling that,
the uncompressing process is not writing in the memory
starting from 0x00000000 and, after uncompressing, it
is jumping into 0x00000000 and is not able to find
anything.
My questions are,
1. How can i make sure that, the uncompressing process
is going to start writing the data from 0x00000000.
2. How big a space this uncompressing process needs?
And also how much overall memory is required for
running linux. I just have 8MB SDRAM.
3. What is the next step in the booting process? Which
Device (eth, pci, ide, ???) Initialization?
Your help is appreciated.
thanks,
Prakash
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* Re: Patch(2.5.52): Add missing PCI ID's for nVidia IDE and PlanB frame grabber
From: Alan Cox @ 2002-12-19 1:02 UTC (permalink / raw)
To: Adam J. Richter
Cc: mj, axboe, Andre Hedrick, mlan, toe, kraxel,
Linux Kernel Mailing List
In-Reply-To: <20021218153535.A9491@baldur.yggdrasil.com>
On Wed, 2002-12-18 at 23:35, Adam J. Richter wrote:
> Hi Martin,
>
> This patch adds two pci device id definitions needed to make
> a couple of drivers compile in 2.5.52:
>
> drivers/ide/pci/nvidia.c needs PCI_DEVICE_IDE_NVIDIA_NFORCE_IDE
> drivers/media/video/planb.c needs PCI_DEVICE_IDE_APPLE_PLANB
>
> If nobody complains, could you please forward these changes to
> Linus and confirm to me that you have done this (so I can have a
> better idea of what to do if they not appear in 2.5.53)? Thanks in
> advance.
The NVIDIA one is right, someoen removed it from Linus tree by accident
in 2.5.51 or so when adding other Nvidia bits.
^ permalink raw reply
* [PATCH] namespace pollution in ide-probe.c
From: Arnd Bergmann @ 2002-12-19 0:12 UTC (permalink / raw)
To: kernel-janitor-discuss; +Cc: Trivial Patches, linux-ide
In-Reply-To: <200212190106.47973.arnd@bergmann-dalldorf.de>
The function init_irq is only used in ide-probe.c, so it should
better be static.
===== drivers/ide/ide-probe.c 1.30 vs edited =====
--- 1.30/drivers/ide/ide-probe.c Mon Dec 2 19:19:20 2002
+++ edited/drivers/ide/ide-probe.c Wed Dec 18 18:00:31 2002
@@ -848,7 +848,7 @@
* but anything else has led to problems on some machines. We re-enable
* interrupts as much as we can safely do in most places.
*/
-int init_irq (ide_hwif_t *hwif)
+static int init_irq (ide_hwif_t *hwif)
{
unsigned long flags;
unsigned int index;
@@ -993,8 +993,6 @@
printk("\n");
return 0;
}
-
-EXPORT_SYMBOL(init_irq);
static int ata_lock(dev_t dev, void *data)
{
^ permalink raw reply
* Re: Freezing.. (was Re: Intel P6 vs P7 system call performance)
From: Alan Cox @ 2002-12-19 0:18 UTC (permalink / raw)
To: Larry McVoy; +Cc: Alan Cox, torvalds, davej, linux-kernel
In-Reply-To: <20021218161506.M7976@work.bitmover.com>
> > > I can understand it when we're discussing BK; other than that, it's pretty
> > > friggin lame. If that's what was behind your posts, Alan, there is an
> > > easy procmail fix for that.
> >
> > It wasnt me who brought up bitkeeper
>
> PLONK. Into kernel-spam you go. I've had it with ax grinders.
Oh dear me. Larry McVoy has flipped
I'm now being added to his spam list for *not* mentioning bitkeeper
Poor Larry, I hope has a nice christmas break, he clearly needs it
^ permalink raw reply
* Re: gettimeofday() moving backwards
From: Pavel Machek @ 2002-12-19 0:09 UTC (permalink / raw)
To: Paul Richards; +Cc: acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
In-Reply-To: <1040241199.3e00d22fe594b-Y3tGgqFSo3OFxr2TtlUqVg@public.gmane.org>
Hi!
> I am using linux kernel v2.4.20 with ACPI patch dated 2002-12-05.
>
> I have noticed that if my processor changes state (800Mhz up to 1200Mhz say)
> then gettimeofday() behaves weirdly. It runs smoothly but every now and again
> (on the order of 10 times a second) it makes a correction. If I have gone from
> 800Mhz to 1200Mhz then the correction is backwards, otherwise it makes a forward
> jump..
>
> I presume that this is because the kernel hasn't noticed that the cpu state has
> changed and hasn't corrected the variables that control how the time is
> calculated using the tsc.
>
> Is there a patch for this..? It doesn't sound like *too* big a thing.. ie just
> recalculate a cpl of timing variables when the cpu state changes.. but ofc I
> don't know the details :)
Its actually pretty hard to do... Because at least at APM cpu can
change clock any time. And recalibration of delay loop takes quite
long... Still it might be good idea to recalibrate after clock change.
Pavel
--
Worst form of spam? Adding advertisment signatures ala sourceforge.net.
What goes next? Inserting advertisment *into* email?
-------------------------------------------------------
This SF.NET email is sponsored by: Geek Gift Procrastinating?
Get the perfect geek gift now! Before the Holidays pass you by.
T H I N K G E E K . C O M http://www.thinkgeek.com/sf/
^ permalink raw reply
* BBS - recommendations?
From: mvw @ 2002-12-19 0:09 UTC (permalink / raw)
To: Linux Hams mailing list
In-Reply-To: <Pine.LNX.4.44.0212122258110.4719-100000@oh2bns.ampr.org>
Hello all,
I want a simple message system on my packet boxes. Either ax.25 based or
TCP/IP based.
I do not need heavy all-encompassing OS-like systems - all I want is a
simple BBS-style system. Any recomemndations for what works well for you
all, and is simple to install and maintain?
Background: I already have the system itself and ax.25 and TCP/IP over
ax.25 working. Just need a BBS on top!
Michael
^ permalink raw reply
* get_pteptr mystery
From: Hollis Blanchard @ 2002-12-19 0:06 UTC (permalink / raw)
To: devel list
I need to mark the first kernel code page writeable because I need to
write to 0xc00000fc. Can someone tell me why the following code fails?
get_pteptr returns 0.
addr = 0xc00000fc;
if (0 != get_pteptr(&init_mm, addr, &ptep)) {
/* mark it writable */
*ptep = pte_mkwrite(*ptep);
/* flush this page from hw TLB */
flush_tlb_range(&init_mm, addr, addr+1);
} else {
printk(KERN_ERR "couldn't get PTE!\n");
}
I've also tried using pgd_offset_k/pmd_offset/pte_offset by hand, but it
seems that the first time any error checking is done is in pte_offset,
and that fails. Specifically
pmd_offset(pgd_offset_k(0xc00000fc)) = c0158000
but
((pmd *)c0158000)->pmd = 0
My code runs at init time, after mm initialization but before init. Does
that mean I can't use init_mm...?
All I want is the pte pointer for 0xc00000fc. Advice welcome. :)
-Hollis
--
PowerPC Linux
IBM Linux Technology Center
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* (no subject)
From: Kyle Mestery @ 2002-12-19 0:11 UTC (permalink / raw)
To: linux-mips
ubscribe linux-mips
^ permalink raw reply
* Re: Via KT400
From: Tupshin Harper @ 2002-12-19 0:12 UTC (permalink / raw)
To: Matthew D. Pitts; +Cc: linux-kernel
In-Reply-To: <001301c2a6ed$d9e7c3e0$0100a8c0@pcs686>
Matthew D. Pitts wrote:
>Has anyone on the list used a motherboard that uses the Via KT400 AGPset? I
>just purchased a Gigabyte GA-7VAX that has it.
>
>Matthew D. Pitts
>
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" 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.tux.org/lkml/
>
>
I'm using exactly that motherboard with no problems. There was an issue
with DMA not being enabled on the IDE controller, but at the time, using
kernel 2.4.19-rc2-ac3 fixed it. I'm not sure if this fix went into
2.4.20 or if you still need an ac kernel.
-Tupshin
^ permalink raw reply
* Re: [PATCH 2.5.52] Use __set_current_state() instead of current->state = (take 1)
From: Robert Love @ 2002-12-19 0:11 UTC (permalink / raw)
To: Inaky Perez-Gonzalez; +Cc: torvalds, linux-kernel
In-Reply-To: <E18Oo3e-0007gl-00@milikk>
On Wed, 2002-12-18 at 18:56, Inaky Perez-Gonzalez wrote:
> In fs/*.c, many functions manually set the task state directly
> accessing current->state, or with a macro, kind of
> inconsistently. This patch changes all of them to use
> [__]set_current_state().
Some of these should probably be set_current_state(). I realize the
current code is equivalent to __set_current_state() but it might as well
be done right.
> diff -u fs/locks.c:1.1.1.6 fs/locks.c:1.1.1.1.6.2
> --- fs/locks.c:1.1.1.6 Wed Dec 11 11:13:35 2002
> +++ fs/locks.c Wed Dec 18 13:20:24 2002
> @@ -571,7 +571,7 @@
> int result = 0;
> DECLARE_WAITQUEUE(wait, current);
>
> - current->state = TASK_INTERRUPTIBLE;
> + __set_current_state (TASK_INTERRUPTIBLE);
> add_wait_queue(fl_wait, &wait);
> if (timeout == 0)
At least this guy should be set_current_state(), on quick glance.
When in doubt just use set_current_state()..
Robert Love
^ permalink raw reply
* Re: [LARTC] PRIO type qdisc
From: Paul C. Diem @ 2002-12-19 0:01 UTC (permalink / raw)
To: lartc
In-Reply-To: <marc-lartc-104010520627418@msgid-missing>
On Wed, 18 Dec 2002, Hayden Myers wrote:
> > > > I'm looking for a PRIO type qdisc which will prioritize packets (either
> > > > based on DS or filters). Unlike PRIO, I need all the classes to flow into
> > > > a single qdisc (HTB). For example:
> > > >
> > > > PRIO
> > > >
> > > > +--------+--------+
> > > >
> > > > Band0 Band1 Band2
> > > >
> > > > +--------+--------+
> > > >
> > > > HTB
> > > >
> > > > Does such a qdisc exist or is there a way to get all the PRIO classes to
> > > > flow into a single qdisc?
> > > There is no such qdisc. And I don't think there is such way.
> > >
> > > But why do you want to do this?
> >
> I had wanted to do similar things a while back before 10 other things beat
> me over the head and set me back. It's funny because the above topology
> is exactly what I had envisioned but read that it was impossible. My
> setup is to have a number of users who have bandwidth limiting based on an
> ip but also does priority shaping as well. I finally decided that I could
> have a top level htb qdisc for the total box bandwidth with seperate
> classes for the users below the box bandwidth qdisc. Underneath each
> user's class I thought that I could possibly attach a prio qdisc to do
> independent priority scheduling. I don't know if this works. It was just
> a thought I had. If think the manpage shows that you can attach a prio
> to any class. Does this work and is it a feasable setup?
Right now we have one htb qdisc at the root and a class under it for each
user. We could put a prio qdisc at the root and use htb under each of
prio's band classes. This gets ridiculously complex though as you get more
link levels. I'd really like to be able to priorize the packets at each
node though so that higher priority packets take precendence at each link
(not just at the main link).
Paul C. Diem
PCDiem@FoxValley.net
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
^ permalink raw reply
* Re: Freezing.. (was Re: Intel P6 vs P7 system call performance)
From: Alan Cox @ 2002-12-19 0:08 UTC (permalink / raw)
To: Larry McVoy
Cc: John Bradford, Larry McVoy, alan, torvalds, davej, vonbrand,
linux-kernel, akpm
In-Reply-To: <20021218140845.L7976@work.bitmover.com>
> I don't understand why BK is part of the conversation. It has nothing to
> do with it. If every time I post to this list the assumption is that it's
> "time to beat larry up about BK" then it's time for me to get off the list.
>
> I can understand it when we're discussing BK; other than that, it's pretty
> friggin lame. If that's what was behind your posts, Alan, there is an
> easy procmail fix for that.
It wasnt me who brought up bitkeeper
^ permalink raw reply
* Re: [parisc-linux] still problems with PCI IDE controller
From: Grant Grundler @ 2002-12-18 23:59 UTC (permalink / raw)
To: Joerg Steindlberger; +Cc: parisc-linux
In-Reply-To: <courier.3E00F419.0000601B@server01>
On Wed, Dec 18, 2002 at 11:18:14PM +0100, Joerg Steindlberger wrote:
...
> Okay. I now set hdparm -c 1 /dev/... and hdparm -d 1 /dev/... -- before
> starting the softwareRAID. The RAID1 is syncing this moment with about 2
> Mbyte/s.
Excellent!
TBH, I wasn't expecting that to work.
> I think I'll stop it now and mount the shorter 80pin cable again and
> play with some speed settings. My earlier problem with DMA was, that the
> kernal crashed when setting the CONFIG_IDEDMA_AUTO=y.
My guess is the IDE code is poking at registers that don't exist.
Did you post console output from the crash?
I'm just curious if it was an HPMC or kernel trap (data page fault).
> > Nope. IDE is EEEeevil ;^)
> Yes, I know. But what would You pay for two 80 GB disks?
The pro/cons of both are well documented.
I'm not going to re-hash them here. :^)
grant
ps. To answer your question: Nothing. I collect 20 or so 9GB 10K rpm SCSI
drives from the scrap area and setup raid0/1 as needed. ;^)
^ permalink raw reply
* Re: [PATCH][2.4] generic cluster APIC support for systems with more than 8 CPUs
From: Martin J. Bligh @ 2002-12-18 23:59 UTC (permalink / raw)
To: Christoph Hellwig, Pallipadi, Venkatesh
Cc: Linux Kernel, John Stultz, Nakajima, Jun, jamesclv,
Mallick, Asit K, Saxena, Sunil
In-Reply-To: <20021218232640.A1746@infradead.org>
> - if (clustered_apic_mode == CLUSTERED_APIC_NUMAQ) {
> + if (clustered_apic_mode &&
> + (configured_platform_type == CONFIGURED_PLATFORM_NUMA) ) {
Arrrggh - no. Let's not create even more of an unholy mess than is there
already. The above is just vile.
> Except of that the patch looks fine, but IMHO something like that should
> get testing in 2.5 first.
Do it under subarch, in 2.5, and please wait until I merge the NUMA-Q
and Summit support that's working as is first. I'll send it out within
a week.
M.
PS. if people could change the email headers when replying to other
branches of this thread from mbligh@us.ibm.com to mbligh@aracnet.com,
I'd much appreciate it.
^ permalink raw reply
* [PATCH 2.5.52] Use __set_current_state() instead of current->state = (take 1)
From: Inaky Perez-Gonzalez @ 2002-12-18 23:56 UTC (permalink / raw)
To: torvalds, linux-kernel
Hi all
In fs/*.c, many functions manually set the task state directly
accessing current->state, or with a macro, kind of
inconsistently. This patch changes all of them to use
[__]set_current_state().
Changelog:
- Ported forward to 2.5.52
diff -u fs/dquot.c:1.1.1.4 fs/dquot.c:1.1.1.1.6.2
--- fs/dquot.c:1.1.1.4 Wed Dec 11 11:13:35 2002
+++ fs/dquot.c Wed Dec 18 13:20:24 2002
@@ -264,7 +264,7 @@
goto repeat;
}
remove_wait_queue(&dquot->dq_wait_lock, &wait);
- current->state = TASK_RUNNING;
+ __set_current_state(TASK_RUNNING);
}
static inline void wait_on_dquot(struct dquot *dquot)
@@ -298,7 +298,7 @@
goto repeat;
}
remove_wait_queue(&dquot->dq_wait_free, &wait);
- current->state = TASK_RUNNING;
+ __set_current_state(TASK_RUNNING);
}
/* Wait for all duplicated dquot references to be dropped */
@@ -314,7 +314,7 @@
goto repeat;
}
remove_wait_queue(&dquot->dq_wait_free, &wait);
- current->state = TASK_RUNNING;
+ __set_current_state(TASK_RUNNING);
}
static int read_dqblk(struct dquot *dquot)
diff -u fs/exec.c:1.1.1.8 fs/exec.c:1.1.1.1.6.2
--- fs/exec.c:1.1.1.8 Mon Dec 16 18:44:31 2002
+++ fs/exec.c Wed Dec 18 13:20:24 2002
@@ -587,7 +587,7 @@
count = 1;
while (atomic_read(&oldsig->count) > count) {
oldsig->group_exit_task = current;
- current->state = TASK_UNINTERRUPTIBLE;
+ __set_current_state(TASK_UNINTERRUPTIBLE);
spin_unlock_irq(&oldsig->siglock);
schedule();
spin_lock_irq(&oldsig->siglock);
diff -u fs/inode.c:1.1.1.6 fs/inode.c:1.1.1.1.6.2
--- fs/inode.c:1.1.1.6 Mon Dec 16 18:44:31 2002
+++ fs/inode.c Wed Dec 18 13:20:24 2002
@@ -1195,7 +1195,7 @@
goto repeat;
}
remove_wait_queue(wq, &wait);
- current->state = TASK_RUNNING;
+ __set_current_state(TASK_RUNNING);
}
void wake_up_inode(struct inode *inode)
diff -u fs/locks.c:1.1.1.6 fs/locks.c:1.1.1.1.6.2
--- fs/locks.c:1.1.1.6 Wed Dec 11 11:13:35 2002
+++ fs/locks.c Wed Dec 18 13:20:24 2002
@@ -571,7 +571,7 @@
int result = 0;
DECLARE_WAITQUEUE(wait, current);
- current->state = TASK_INTERRUPTIBLE;
+ __set_current_state (TASK_INTERRUPTIBLE);
add_wait_queue(fl_wait, &wait);
if (timeout == 0)
schedule();
@@ -580,7 +580,7 @@
if (signal_pending(current))
result = -ERESTARTSYS;
remove_wait_queue(fl_wait, &wait);
- current->state = TASK_RUNNING;
+ __set_current_state (TASK_RUNNING);
return result;
}
diff -u fs/namei.c:1.1.1.6 fs/namei.c:1.1.1.1.6.2
--- fs/namei.c:1.1.1.6 Wed Dec 11 11:13:35 2002
+++ fs/namei.c Wed Dec 18 13:20:24 2002
@@ -410,7 +410,7 @@
if (current->total_link_count >= 40)
goto loop;
if (need_resched()) {
- current->state = TASK_RUNNING;
+ __set_current_state(TASK_RUNNING);
schedule();
}
err = security_inode_follow_link(dentry, nd);
diff -u fs/select.c:1.1.1.3 fs/select.c:1.1.1.1.6.2
--- fs/select.c:1.1.1.3 Wed Dec 11 11:10:14 2002
+++ fs/select.c Wed Dec 18 13:20:24 2002
@@ -235,7 +235,7 @@
}
__timeout = schedule_timeout(__timeout);
}
- current->state = TASK_RUNNING;
+ __set_current_state (TASK_RUNNING);
poll_freewait(&table);
@@ -417,7 +417,7 @@
break;
timeout = schedule_timeout(timeout);
}
- current->state = TASK_RUNNING;
+ __set_current_state (TASK_RUNNING);
return count;
}
--
Inaky Perez-Gonzalez -- Not speaking for Intel - opinions are my own [or my fault]
^ permalink raw reply
* Re: Intel P6 vs P7 system call performance
From: billyrose @ 2002-12-18 23:51 UTC (permalink / raw)
To: root; +Cc: linux-kernel
Richard B. Johnson wrote:
> The number of CPU clocks necessary to make the 'far' or
> full-pointer call by pushing the segment register, the offset,
> then issuing a 'lret' is 33 clocks on a Pentium II.
>
> longcall clocks = 46
> call clocks = 13
> actual full-pointer call clocks = 33
this is not correct. the assumed target (of a _far_ call) would issue a far
return and only an offset would be left on the stack to return to (oops). the
code segment of the orginal caller needs pushed to create the seg:off pair and
hence a far return would land back at the original calling routine. this is a
very convoluted method of making the orginal call being far, as simply calling
far in the first pace should issue much faster. OTOH, if you are making a
workaround to an already existing piece of code, this works beautifully (with
the additional seg pushed on the stack).
b.
^ permalink raw reply
* [RFC] more security hooks for System V IPC
From: Greg KH @ 2002-12-18 23:47 UTC (permalink / raw)
To: linux-kernel; +Cc: linux-security-module
In-Reply-To: <200212182023.PAA02233@moss-shockers.ncsc.mil>
Hi all,
Here's a patch against 2.5.52 that adds the remaining needed LSM hooks
for the System V IPC code. This patch was split out of the LSM tree by
Stephen Smalley, and he writes:
On Wed, Dec 18, 2002 at 03:23:58PM -0500, Stephen D. Smalley wrote:
>
> [This patch] proceeds to add the remaining System V IPC
> hooks, including the inline documentation for them in security.h. This
> includes a restored sem_semop hook, as it does seem to be necessary to
> support fine-grained access.
>
> All of these System V IPC hooks are used by SELinux. The SELinux System V IPC
> access controls were originally described in the technical report available from
> http://www.nsa.gov/selinux/slinux-abs.html, and the LSM-based implementation is
> described in the technical report available from
> http://www.nsa.gov/selinux/module-abs.html.
If anyone has any objections to these hooks being added please let me
know, otherwise I'll send this patch off to Linus in a few days.
thanks,
greg k-h
include/linux/msg.h | 1
include/linux/security.h | 244 +++++++++++++++++++++++++++++++++++++++++++++++
ipc/msg.c | 41 +++++++
ipc/sem.c | 32 +++++-
ipc/shm.c | 41 +++++++
security/dummy.c | 77 ++++++++++++++
6 files changed, 428 insertions(+), 8 deletions(-)
diff -X /home/sds/dontdiff -ru 2.5.52-lsm-dummy/include/linux/msg.h 2.5.52-lsm-ipc/include/linux/msg.h
--- 2.5.52-lsm-dummy/include/linux/msg.h Sun Dec 15 21:08:09 2002
+++ 2.5.52-lsm-ipc/include/linux/msg.h Wed Dec 18 13:36:54 2002
@@ -69,6 +69,7 @@
long m_type;
int m_ts; /* message text size */
struct msg_msgseg* next;
+ void *security;
/* the actual message follows immediately */
};
diff -X /home/sds/dontdiff -ru 2.5.52-lsm-dummy/include/linux/security.h 2.5.52-lsm-ipc/include/linux/security.h
--- 2.5.52-lsm-dummy/include/linux/security.h Sun Dec 15 21:08:13 2002
+++ 2.5.52-lsm-ipc/include/linux/security.h Wed Dec 18 14:10:50 2002
@@ -594,6 +594,17 @@
* @flag contains the desired (requested) permission set
* Return 0 if permission is granted.
*
+ * Security hooks for individual messages held in System V IPC message queues
+ * @msg_msg_alloc_security:
+ * Allocate and attach a security structure to the msg->security field.
+ * The security field is initialized to NULL when the structure is first
+ * created.
+ * @msg contains the message structure to be modified.
+ * Return 0 if operation was successful and permission is granted.
+ * @msg_msg_free_security:
+ * Deallocate the security structure for this message.
+ * @msg contains the message structure to be modified.
+ *
* Security hooks for System V IPC Message Queues
*
* @msg_queue_alloc_security:
@@ -605,6 +616,39 @@
* @msg_queue_free_security:
* Deallocate security structure for this message queue.
* @msq contains the message queue structure to be modified.
+ * @msg_queue_associate:
+ * Check permission when a message queue is requested through the
+ * msgget system call. This hook is only called when returning the
+ * message queue identifier for an existing message queue, not when a
+ * new message queue is created.
+ * @msq contains the message queue to act upon.
+ * @msqflg contains the operation control flags.
+ * Return 0 if permission is granted.
+ * @msg_queue_msgctl:
+ * Check permission when a message control operation specified by @cmd
+ * is to be performed on the message queue @msq.
+ * The @msq may be NULL, e.g. for IPC_INFO or MSG_INFO.
+ * @msq contains the message queue to act upon. May be NULL.
+ * @cmd contains the operation to be performed.
+ * Return 0 if permission is granted.
+ * @msg_queue_msgsnd:
+ * Check permission before a message, @msg, is enqueued on the message
+ * queue, @msq.
+ * @msq contains the message queue to send message to.
+ * @msg contains the message to be enqueued.
+ * @msqflg contains operational flags.
+ * Return 0 if permission is granted.
+ * @msg_queue_msgrcv:
+ * Check permission before a message, @msg, is removed from the message
+ * queue, @msq. The @target task structure contains a pointer to the
+ * process that will be receiving the message (not equal to the current
+ * process when inline receives are being performed).
+ * @msq contains the message queue to retrieve message from.
+ * @msg contains the message destination.
+ * @target contains the task structure for recipient process.
+ * @type contains the type of message requested.
+ * @mode contains the operational flags.
+ * Return 0 if permission is granted.
*
* Security hooks for System V Shared Memory Segments
*
@@ -617,6 +661,29 @@
* @shm_free_security:
* Deallocate the security struct for this memory segment.
* @shp contains the shared memory structure to be modified.
+ * @shm_associate:
+ * Check permission when a shared memory region is requested through the
+ * shmget system call. This hook is only called when returning the shared
+ * memory region identifier for an existing region, not when a new shared
+ * memory region is created.
+ * @shp contains the shared memory structure to be modified.
+ * @shmflg contains the operation control flags.
+ * Return 0 if permission is granted.
+ * @shm_shmctl:
+ * Check permission when a shared memory control operation specified by
+ * @cmd is to be performed on the shared memory region @shp.
+ * The @shp may be NULL, e.g. for IPC_INFO or SHM_INFO.
+ * @shp contains shared memory structure to be modified.
+ * @cmd contains the operation to be performed.
+ * Return 0 if permission is granted.
+ * @shm_shmat:
+ * Check permissions prior to allowing the shmat system call to attach the
+ * shared memory segment @shp to the data segment of the calling process.
+ * The attaching address is specified by @shmaddr.
+ * @shp contains the shared memory structure to be modified.
+ * @shmaddr contains the address to attach memory region to.
+ * @shmflg contains the operational flags.
+ * Return 0 if permission is granted.
*
* Security hooks for System V Semaphores
*
@@ -629,6 +696,30 @@
* @sem_free_security:
* deallocate security struct for this semaphore
* @sma contains the semaphore structure.
+ * @sem_associate:
+ * Check permission when a semaphore is requested through the semget
+ * system call. This hook is only called when returning the semaphore
+ * identifier for an existing semaphore, not when a new one must be
+ * created.
+ * @sma contains the semaphore structure.
+ * @semflg contains the operation control flags.
+ * Return 0 if permission is granted.
+ * @sem_semctl:
+ * Check permission when a semaphore operation specified by @cmd is to be
+ * performed on the semaphore @sma. The @sma may be NULL, e.g. for
+ * IPC_INFO or SEM_INFO.
+ * @sma contains the semaphore structure. May be NULL.
+ * @cmd contains the operation to be performed.
+ * Return 0 if permission is granted.
+ * @sem_semop
+ * Check permissions before performing operations on members of the
+ * semaphore set @sma. If the @alter flag is nonzero, the semaphore set
+ * may be modified.
+ * @sma contains the semaphore structure.
+ * @sops contains the operations to perform.
+ * @nsops contains the number of operations to perform.
+ * @alter contains the flag indicating whether changes are to be made.
+ * Return 0 if permission is granted.
*
* @ptrace:
* Check permission before allowing the @parent process to trace the
@@ -828,14 +919,33 @@
int (*ipc_permission) (struct kern_ipc_perm * ipcp, short flag);
+ int (*msg_msg_alloc_security) (struct msg_msg * msg);
+ void (*msg_msg_free_security) (struct msg_msg * msg);
+
int (*msg_queue_alloc_security) (struct msg_queue * msq);
void (*msg_queue_free_security) (struct msg_queue * msq);
+ int (*msg_queue_associate) (struct msg_queue * msq, int msqflg);
+ int (*msg_queue_msgctl) (struct msg_queue * msq, int cmd);
+ int (*msg_queue_msgsnd) (struct msg_queue * msq,
+ struct msg_msg * msg, int msqflg);
+ int (*msg_queue_msgrcv) (struct msg_queue * msq,
+ struct msg_msg * msg,
+ struct task_struct * target,
+ long type, int mode);
int (*shm_alloc_security) (struct shmid_kernel * shp);
void (*shm_free_security) (struct shmid_kernel * shp);
+ int (*shm_associate) (struct shmid_kernel * shp, int shmflg);
+ int (*shm_shmctl) (struct shmid_kernel * shp, int cmd);
+ int (*shm_shmat) (struct shmid_kernel * shp,
+ char *shmaddr, int shmflg);
int (*sem_alloc_security) (struct sem_array * sma);
void (*sem_free_security) (struct sem_array * sma);
+ int (*sem_associate) (struct sem_array * sma, int semflg);
+ int (*sem_semctl) (struct sem_array * sma, int cmd);
+ int (*sem_semop) (struct sem_array * sma,
+ struct sembuf * sops, unsigned nsops, int alter);
/* allow module stacking */
int (*register_security) (const char *name,
@@ -1334,6 +1444,16 @@
return security_ops->ipc_permission (ipcp, flag);
}
+static inline int security_msg_msg_alloc (struct msg_msg * msg)
+{
+ return security_ops->msg_msg_alloc_security (msg);
+}
+
+static inline void security_msg_msg_free (struct msg_msg * msg)
+{
+ security_ops->msg_msg_free_security(msg);
+}
+
static inline int security_msg_queue_alloc (struct msg_queue *msq)
{
return security_ops->msg_queue_alloc_security (msq);
@@ -1344,6 +1464,31 @@
security_ops->msg_queue_free_security (msq);
}
+static inline int security_msg_queue_associate (struct msg_queue * msq,
+ int msqflg)
+{
+ return security_ops->msg_queue_associate (msq, msqflg);
+}
+
+static inline int security_msg_queue_msgctl (struct msg_queue * msq, int cmd)
+{
+ return security_ops->msg_queue_msgctl (msq, cmd);
+}
+
+static inline int security_msg_queue_msgsnd (struct msg_queue * msq,
+ struct msg_msg * msg, int msqflg)
+{
+ return security_ops->msg_queue_msgsnd (msq, msg, msqflg);
+}
+
+static inline int security_msg_queue_msgrcv (struct msg_queue * msq,
+ struct msg_msg * msg,
+ struct task_struct * target,
+ long type, int mode)
+{
+ return security_ops->msg_queue_msgrcv (msq, msg, target, type, mode);
+}
+
static inline int security_shm_alloc (struct shmid_kernel *shp)
{
return security_ops->shm_alloc_security (shp);
@@ -1354,6 +1499,23 @@
security_ops->shm_free_security (shp);
}
+static inline int security_shm_associate (struct shmid_kernel * shp,
+ int shmflg)
+{
+ return security_ops->shm_associate(shp, shmflg);
+}
+
+static inline int security_shm_shmctl (struct shmid_kernel * shp, int cmd)
+{
+ return security_ops->shm_shmctl (shp, cmd);
+}
+
+static inline int security_shm_shmat (struct shmid_kernel * shp,
+ char *shmaddr, int shmflg)
+{
+ return security_ops->shm_shmat(shp, shmaddr, shmflg);
+}
+
static inline int security_sem_alloc (struct sem_array *sma)
{
return security_ops->sem_alloc_security (sma);
@@ -1364,6 +1526,22 @@
security_ops->sem_free_security (sma);
}
+static inline int security_sem_associate (struct sem_array * sma, int semflg)
+{
+ return security_ops->sem_associate (sma, semflg);
+}
+
+static inline int security_sem_semctl (struct sem_array * sma, int cmd)
+{
+ return security_ops->sem_semctl(sma, cmd);
+}
+
+static inline int security_sem_semop (struct sem_array * sma,
+ struct sembuf * sops, unsigned nsops,
+ int alter)
+{
+ return security_ops->sem_semop(sma, sops, nsops, alter);
+}
/* prototypes */
extern int security_scaffolding_startup (void);
@@ -1835,6 +2013,14 @@
return 0;
}
+static inline int security_msg_msg_alloc (struct msg_msg * msg)
+{
+ return 0;
+}
+
+static inline void security_msg_msg_free (struct msg_msg * msg)
+{ }
+
static inline int security_msg_queue_alloc (struct msg_queue *msq)
{
return 0;
@@ -1843,6 +2029,31 @@
static inline void security_msg_queue_free (struct msg_queue *msq)
{ }
+static inline int security_msg_queue_associate (struct msg_queue * msq,
+ int msqflg)
+{
+ return 0;
+}
+
+static inline int security_msg_queue_msgctl (struct msg_queue * msq, int cmd)
+{
+ return 0;
+}
+
+static inline int security_msg_queue_msgsnd (struct msg_queue * msq,
+ struct msg_msg * msg, int msqflg)
+{
+ return 0;
+}
+
+static inline int security_msg_queue_msgrcv (struct msg_queue * msq,
+ struct msg_msg * msg,
+ struct task_struct * target,
+ long type, int mode)
+{
+ return 0;
+}
+
static inline int security_shm_alloc (struct shmid_kernel *shp)
{
return 0;
@@ -1851,6 +2062,23 @@
static inline void security_shm_free (struct shmid_kernel *shp)
{ }
+static inline int security_shm_associate (struct shmid_kernel * shp,
+ int shmflg)
+{
+ return 0;
+}
+
+static inline int security_shm_shmctl (struct shmid_kernel * shp, int cmd)
+{
+ return 0;
+}
+
+static inline int security_shm_shmat (struct shmid_kernel * shp,
+ char *shmaddr, int shmflg)
+{
+ return 0;
+}
+
static inline int security_sem_alloc (struct sem_array *sma)
{
return 0;
@@ -1859,6 +2087,22 @@
static inline void security_sem_free (struct sem_array *sma)
{ }
+static inline int security_sem_associate (struct sem_array * sma, int semflg)
+{
+ return 0;
+}
+
+static inline int security_sem_semctl (struct sem_array * sma, int cmd)
+{
+ return 0;
+}
+
+static inline int security_sem_semop (struct sem_array * sma,
+ struct sembuf * sops, unsigned nsops,
+ int alter)
+{
+ return 0;
+}
#endif /* CONFIG_SECURITY */
diff -X /home/sds/dontdiff -ru 2.5.52-lsm-dummy/ipc/msg.c 2.5.52-lsm-ipc/ipc/msg.c
--- 2.5.52-lsm-dummy/ipc/msg.c Sun Dec 15 21:07:42 2002
+++ 2.5.52-lsm-ipc/ipc/msg.c Wed Dec 18 13:36:54 2002
@@ -132,6 +132,9 @@
static void free_msg(struct msg_msg* msg)
{
struct msg_msgseg* seg;
+
+ security_msg_msg_free(msg);
+
seg = msg->next;
kfree(msg);
while(seg != NULL) {
@@ -157,6 +160,7 @@
return ERR_PTR(-ENOMEM);
msg->next = NULL;
+ msg->security = NULL;
if (copy_from_user(msg+1, src, alen)) {
err = -EFAULT;
@@ -186,6 +190,11 @@
len -= alen;
src = ((char*)src)+alen;
}
+
+ err = security_msg_msg_alloc(msg);
+ if (err)
+ goto out_err;
+
return msg;
out_err:
@@ -308,8 +317,12 @@
BUG();
if (ipcperms(&msq->q_perm, msgflg))
ret = -EACCES;
- else
- ret = msg_buildid(id, msq->q_perm.seq);
+ else {
+ int qid = msg_buildid(id, msq->q_perm.seq);
+ ret = security_msg_queue_associate(msq, msgflg);
+ if (!ret)
+ ret = qid;
+ }
msg_unlock(msq);
}
up(&msg_ids.sem);
@@ -431,6 +444,11 @@
* due to padding, it's not enough
* to set all member fields.
*/
+
+ err = security_msg_queue_msgctl(NULL, cmd);
+ if (err)
+ return err;
+
memset(&msginfo,0,sizeof(msginfo));
msginfo.msgmni = msg_ctlmni;
msginfo.msgmax = msg_ctlmax;
@@ -481,6 +499,10 @@
if (ipcperms (&msq->q_perm, S_IRUGO))
goto out_unlock;
+ err = security_msg_queue_msgctl(msq, cmd);
+ if (err)
+ goto out_unlock;
+
kernel_to_ipc64_perm(&msq->q_perm, &tbuf.msg_perm);
tbuf.msg_stime = msq->q_stime;
tbuf.msg_rtime = msq->q_rtime;
@@ -523,11 +545,16 @@
/* We _could_ check for CAP_CHOWN above, but we don't */
goto out_unlock_up;
+ err = security_msg_queue_msgctl(msq, cmd);
+ if (err)
+ goto out_unlock_up;
+
switch (cmd) {
case IPC_SET:
{
if (setbuf.qbytes > msg_ctlmnb && !capable(CAP_SYS_RESOURCE))
goto out_unlock_up;
+
msq->q_qbytes = setbuf.qbytes;
ipcp->uid = setbuf.uid;
@@ -593,7 +620,8 @@
struct msg_receiver* msr;
msr = list_entry(tmp,struct msg_receiver,r_list);
tmp = tmp->next;
- if(testmsg(msg,msr->r_msgtype,msr->r_mode)) {
+ if(testmsg(msg,msr->r_msgtype,msr->r_mode) &&
+ !security_msg_queue_msgrcv(msq, msg, msr->r_tsk, msr->r_msgtype, msr->r_mode)) {
list_del(&msr->r_list);
if(msr->r_maxsize < msg->m_ts) {
msr->r_msg = ERR_PTR(-E2BIG);
@@ -644,6 +672,10 @@
if (ipcperms(&msq->q_perm, S_IWUGO))
goto out_unlock_free;
+ err = security_msg_queue_msgsnd(msq, msg, msgflg);
+ if (err)
+ goto out_unlock_free;
+
if(msgsz + msq->q_cbytes > msq->q_qbytes ||
1 + msq->q_qnum > msq->q_qbytes) {
struct msg_sender s;
@@ -742,7 +774,8 @@
found_msg=NULL;
while (tmp != &msq->q_messages) {
msg = list_entry(tmp,struct msg_msg,m_list);
- if(testmsg(msg,msgtyp,mode)) {
+ if(testmsg(msg,msgtyp,mode) &&
+ !security_msg_queue_msgrcv(msq, msg, current, msgtyp, mode)) {
found_msg = msg;
if(mode == SEARCH_LESSEQUAL && msg->m_type != 1) {
found_msg=msg;
diff -X /home/sds/dontdiff -ru 2.5.52-lsm-dummy/ipc/sem.c 2.5.52-lsm-ipc/ipc/sem.c
--- 2.5.52-lsm-dummy/ipc/sem.c Sun Dec 15 21:07:53 2002
+++ 2.5.52-lsm-ipc/ipc/sem.c Wed Dec 18 13:48:49 2002
@@ -188,8 +188,12 @@
err = -EINVAL;
else if (ipcperms(&sma->sem_perm, semflg))
err = -EACCES;
- else
- err = sem_buildid(id, sma->sem_perm.seq);
+ else {
+ int semid = sem_buildid(id, sma->sem_perm.seq);
+ err = security_sem_associate(sma, semflg);
+ if (!err)
+ err = semid;
+ }
sem_unlock(sma);
}
@@ -466,6 +470,10 @@
struct seminfo seminfo;
int max_id;
+ err = security_sem_semctl(NULL, cmd);
+ if (err)
+ return err;
+
memset(&seminfo,0,sizeof(seminfo));
seminfo.semmni = sc_semmni;
seminfo.semmns = sc_semmns;
@@ -506,6 +514,11 @@
err = -EACCES;
if (ipcperms (&sma->sem_perm, S_IRUGO))
goto out_unlock;
+
+ err = security_sem_semctl(sma, cmd);
+ if (err)
+ goto out_unlock;
+
id = sem_buildid(semid, sma->sem_perm.seq);
kernel_to_ipc64_perm(&sma->sem_perm, &tbuf.sem_perm);
@@ -549,6 +562,11 @@
if (ipcperms (&sma->sem_perm, (cmd==SETVAL||cmd==SETALL)?S_IWUGO:S_IRUGO))
goto out_unlock;
+ err = security_sem_semctl(sma, cmd);
+ if (err)
+ goto out_unlock;
+
+ err = -EACCES;
switch (cmd) {
case GETALL:
{
@@ -740,6 +758,10 @@
goto out_unlock;
}
+ err = security_sem_semctl(sma, cmd);
+ if (err)
+ goto out_unlock;
+
switch(cmd){
case IPC_RMID:
freeary(semid);
@@ -1035,6 +1057,12 @@
error = -EACCES;
if (ipcperms(&sma->sem_perm, alter ? S_IWUGO : S_IRUGO))
goto out_unlock_semundo_free;
+
+ error = security_sem_semop(sma, sops, nsops, alter);
+ if (error)
+ goto out_unlock_semundo_free;
+
+ error = -EACCES;
if (undos) {
/* Make sure we have an undo structure
* for this process and this semaphore set.
diff -X /home/sds/dontdiff -ru 2.5.52-lsm-dummy/ipc/shm.c 2.5.52-lsm-ipc/ipc/shm.c
--- 2.5.52-lsm-dummy/ipc/shm.c Sun Dec 15 21:07:58 2002
+++ 2.5.52-lsm-ipc/ipc/shm.c Wed Dec 18 13:36:54 2002
@@ -257,8 +257,12 @@
err = -EINVAL;
else if (ipcperms(&shp->shm_perm, shmflg))
err = -EACCES;
- else
- err = shm_buildid(id, shp->shm_perm.seq);
+ else {
+ int shmid = shm_buildid(id, shp->shm_perm.seq);
+ err = security_shm_associate(shp, shmflg);
+ if (!err)
+ err = shmid;
+ }
shm_unlock(shp);
}
up(&shm_ids.sem);
@@ -399,6 +403,10 @@
{
struct shminfo64 shminfo;
+ err = security_shm_shmctl(NULL, cmd);
+ if (err)
+ return err;
+
memset(&shminfo,0,sizeof(shminfo));
shminfo.shmmni = shminfo.shmseg = shm_ctlmni;
shminfo.shmmax = shm_ctlmax;
@@ -417,6 +425,10 @@
{
struct shm_info shm_info;
+ err = security_shm_shmctl(NULL, cmd);
+ if (err)
+ return err;
+
memset(&shm_info,0,sizeof(shm_info));
down(&shm_ids.sem);
shm_info.used_ids = shm_ids.in_use;
@@ -458,6 +470,9 @@
err=-EACCES;
if (ipcperms (&shp->shm_perm, S_IRUGO))
goto out_unlock;
+ err = security_shm_shmctl(shp, cmd);
+ if (err)
+ goto out_unlock;
kernel_to_ipc64_perm(&shp->shm_perm, &tbuf.shm_perm);
tbuf.shm_segsz = shp->shm_segsz;
tbuf.shm_atime = shp->shm_atim;
@@ -492,6 +507,11 @@
err = shm_checkid(shp,shmid);
if(err)
goto out_unlock;
+
+ err = security_shm_shmctl(shp, cmd);
+ if (err)
+ goto out_unlock;
+
if(cmd==SHM_LOCK) {
if (!is_file_hugepages(shp->shm_file))
shmem_lock(shp->shm_file, 1);
@@ -524,12 +544,18 @@
err = shm_checkid(shp, shmid);
if(err)
goto out_unlock_up;
+
if (current->euid != shp->shm_perm.uid &&
current->euid != shp->shm_perm.cuid &&
!capable(CAP_SYS_ADMIN)) {
err=-EPERM;
goto out_unlock_up;
}
+
+ err = security_shm_shmctl(shp, cmd);
+ if (err)
+ goto out_unlock_up;
+
if (shp->shm_nattch){
shp->shm_flags |= SHM_DEST;
/* Do not find it any more */
@@ -562,6 +588,10 @@
goto out_unlock_up;
}
+ err = security_shm_shmctl(shp, cmd);
+ if (err)
+ goto out_unlock_up;
+
shp->shm_perm.uid = setbuf.uid;
shp->shm_perm.gid = setbuf.gid;
shp->shm_flags = (shp->shm_flags & ~S_IRWXUGO)
@@ -650,6 +680,13 @@
err = -EACCES;
goto out;
}
+
+ err = security_shm_shmat(shp, shmaddr, shmflg);
+ if (err) {
+ shm_unlock(shp);
+ return err;
+ }
+
file = shp->shm_file;
size = file->f_dentry->d_inode->i_size;
shp->shm_nattch++;
diff -X /home/sds/dontdiff -ru 2.5.52-lsm-dummy/security/dummy.c 2.5.52-lsm-ipc/security/dummy.c
--- 2.5.52-lsm-dummy/security/dummy.c Wed Dec 18 14:00:31 2002
+++ 2.5.52-lsm-ipc/security/dummy.c Wed Dec 18 14:11:56 2002
@@ -501,6 +501,15 @@
return 0;
}
+static int dummy_msg_msg_alloc_security (struct msg_msg *msg)
+{
+ return 0;
+}
+
+static void dummy_msg_msg_free_security (struct msg_msg *msg)
+{
+ return;
+}
static int dummy_msg_queue_alloc_security (struct msg_queue *msq)
{
@@ -512,6 +521,30 @@
return;
}
+static int dummy_msg_queue_associate (struct msg_queue *msq,
+ int msqflg)
+{
+ return 0;
+}
+
+static int dummy_msg_queue_msgctl (struct msg_queue *msq, int cmd)
+{
+ return 0;
+}
+
+static int dummy_msg_queue_msgsnd (struct msg_queue *msq, struct msg_msg *msg,
+ int msgflg)
+{
+ return 0;
+}
+
+static int dummy_msg_queue_msgrcv (struct msg_queue *msq, struct msg_msg *msg,
+ struct task_struct *target, long type,
+ int mode)
+{
+ return 0;
+}
+
static int dummy_shm_alloc_security (struct shmid_kernel *shp)
{
return 0;
@@ -522,6 +555,22 @@
return;
}
+static int dummy_shm_associate (struct shmid_kernel *shp, int shmflg)
+{
+ return 0;
+}
+
+static int dummy_shm_shmctl (struct shmid_kernel *shp, int cmd)
+{
+ return 0;
+}
+
+static int dummy_shm_shmat (struct shmid_kernel *shp, char *shmaddr,
+ int shmflg)
+{
+ return 0;
+}
+
static int dummy_sem_alloc_security (struct sem_array *sma)
{
return 0;
@@ -532,6 +581,22 @@
return;
}
+static int dummy_sem_associate (struct sem_array *sma, int semflg)
+{
+ return 0;
+}
+
+static int dummy_sem_semctl (struct sem_array *sma, int cmd)
+{
+ return 0;
+}
+
+static int dummy_sem_semop (struct sem_array *sma,
+ struct sembuf *sops, unsigned nsops, int alter)
+{
+ return 0;
+}
+
static int dummy_register_security (const char *name, struct security_operations *ops)
{
return -EINVAL;
@@ -640,12 +705,24 @@
set_to_dummy_if_null(ops, task_kmod_set_label);
set_to_dummy_if_null(ops, task_reparent_to_init);
set_to_dummy_if_null(ops, ipc_permission);
+ set_to_dummy_if_null(ops, msg_msg_alloc_security);
+ set_to_dummy_if_null(ops, msg_msg_free_security);
set_to_dummy_if_null(ops, msg_queue_alloc_security);
set_to_dummy_if_null(ops, msg_queue_free_security);
+ set_to_dummy_if_null(ops, msg_queue_associate);
+ set_to_dummy_if_null(ops, msg_queue_msgctl);
+ set_to_dummy_if_null(ops, msg_queue_msgsnd);
+ set_to_dummy_if_null(ops, msg_queue_msgrcv);
set_to_dummy_if_null(ops, shm_alloc_security);
set_to_dummy_if_null(ops, shm_free_security);
+ set_to_dummy_if_null(ops, shm_associate);
+ set_to_dummy_if_null(ops, shm_shmctl);
+ set_to_dummy_if_null(ops, shm_shmat);
set_to_dummy_if_null(ops, sem_alloc_security);
set_to_dummy_if_null(ops, sem_free_security);
+ set_to_dummy_if_null(ops, sem_associate);
+ set_to_dummy_if_null(ops, sem_semctl);
+ set_to_dummy_if_null(ops, sem_semop);
set_to_dummy_if_null(ops, register_security);
set_to_dummy_if_null(ops, unregister_security);
}
^ permalink raw reply
* Re: Linux 2.4.21-pre2 - unresolved
From: Eyal Lebedinsky @ 2002-12-18 23:49 UTC (permalink / raw)
To: Marcelo Tosatti; +Cc: lkml
In-Reply-To: <Pine.LNX.4.50L.0212181721340.18764-100000@freak.distro.conectiva>
depmod: *** Unresolved symbols in
/lib/modules/2.4.21-pre2/kernel/drivers/char/scx200_gpio.o
depmod: scx200_gpio_configure
depmod: scx200_gpio_base
depmod: scx200_gpio_shadow
depmod: *** Unresolved symbols in
/lib/modules/2.4.21-pre2/kernel/drivers/i2c/scx200_i2c.o
depmod: scx200_gpio_configure
depmod: scx200_gpio_base
depmod: scx200_gpio_shadow
depmod: *** Unresolved symbols in
/lib/modules/2.4.21-pre2/kernel/net/irda/irda.o
depmod: irlmp_lap_tx_queue_full
This is my 'full build' .config where I always select 'm' when offered.
i386.
--
Eyal Lebedinsky (eyal@eyal.emu.id.au) <http://samba.org/eyal/>
^ permalink raw reply
* Re: Horrible drive performance under concurrent i/o jobs (dlh problem?)
From: Andrew Morton @ 2002-12-18 23:46 UTC (permalink / raw)
To: Torben Frey; +Cc: Con Kolivas, linux kernel mailing list
In-Reply-To: <3E010531.8020101@mailsammler.de>
Torben Frey wrote:
>
> Hi Andrew, hi Con,
>
> > Here's a diff against base 2.4.20. It may be a little out of date
> > wrt Andrea's latest but it should tell us if we're looking in the
> > right place.
> Ok, I did not run the complete 2.4.20aa1 kernel yet since I am not sure
> if it is intended to be used, but I applied your patch, Andrew (thanks
> for mailing it). It still does not fix the problem. One job doing much
> I/O starts with about 80% CPU but then drops down to about 30% in the
> first 40 seconds. Load goes from 0.00 to 2.4 within that time.
>
> And I can see bdflush and my process marked with "D" in the process list.
>
> Catting the device to /dev/null only made it worse :-(
>
> Creating a 1GB file using dd takes about 1 minute compared to 16 seconds
> without other jobs running.
err, now hang on.
I thought you said that this simple dd sometimes takes 14 seconds,
and sometimes takes 4 minutes.
Please describe _exactly_ what activity is happening, and against
what disks when this problem exhibits. The "other jobs".
> Do you think it could be a ReiserFS problem on a RAID?
Doubtful. As far as reiserfs (and the block layer) is concerned,
your raid array is just a single disk (is this correct??)
> Do you know of anything else I could try?
Try a different filesystem
Try a dd to the blockdevice itself (or cat /dev/zero > /dev/sda1)
Run `vmstat 1' and send us the output which corresponds to
the poor throughput.
Try a different RAID mode.
Pull some disks out.
^ permalink raw reply
* Patch(2.5.52): Add missing PCI ID's for nVidia IDE and PlanB frame grabber
From: Adam J. Richter @ 2002-12-18 23:35 UTC (permalink / raw)
To: mj; +Cc: alan, axboe, andre, mlan, toe, kraxel, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 716 bytes --]
Hi Martin,
This patch adds two pci device id definitions needed to make
a couple of drivers compile in 2.5.52:
drivers/ide/pci/nvidia.c needs PCI_DEVICE_IDE_NVIDIA_NFORCE_IDE
drivers/media/video/planb.c needs PCI_DEVICE_IDE_APPLE_PLANB
If nobody complains, could you please forward these changes to
Linus and confirm to me that you have done this (so I can have a
better idea of what to do if they not appear in 2.5.53)? Thanks in
advance.
--
Adam J. Richter __ ______________ 575 Oroville Road
adam@yggdrasil.com \ / Milpitas, California 95035
+1 408 309-6081 | g g d r a s i l United States of America
"Free Software For The Rest Of Us."
[-- Attachment #2: pci_ids.diff --]
[-- Type: text/plain, Size: 827 bytes --]
--- linux-2.5.52/include/linux/pci_ids.h 2002-12-15 18:07:54.000000000 -0800
+++ linux/include/linux/pci_ids.h 2002-12-18 15:07:29.000000000 -0800
@@ -700,6 +700,7 @@
#define PCI_VENDOR_ID_APPLE 0x106b
#define PCI_DEVICE_ID_APPLE_BANDIT 0x0001
#define PCI_DEVICE_ID_APPLE_GC 0x0002
+#define PCI_DEVICE_ID_APPLE_PLANB 0x0004
#define PCI_DEVICE_ID_APPLE_HYDRA 0x000e
#define PCI_DEVICE_ID_APPLE_UNI_N_FW 0x0018
#define PCI_DEVICE_ID_APPLE_KL_USB 0x0019
@@ -946,6 +947,7 @@
#define PCI_DEVICE_ID_NVIDIA_QUADRO4_550XGL 0x017B
#define PCI_DEVICE_ID_NVIDIA_QUADRO4_500_GOGL 0x017C
#define PCI_DEVICE_ID_NVIDIA_IGEFORCE2 0x01a0
+#define PCI_DEVICE_ID_NVIDIA_NFORCE_IDE 0x01bc
#define PCI_DEVICE_ID_NVIDIA_GEFORCE3 0x0200
#define PCI_DEVICE_ID_NVIDIA_GEFORCE3_1 0x0201
#define PCI_DEVICE_ID_NVIDIA_GEFORCE3_2 0x0202
^ permalink raw reply
* Re: [Linux-ia64] installation help
From: Stephane Eranian @ 2002-12-18 23:35 UTC (permalink / raw)
To: linux-ia64
In-Reply-To: <marc-linux-ia64-105590709805612@msgid-missing>
On Wed, Dec 18, 2002 at 03:25:17PM -0800, Jian Chen wrote:
> Hi,
>
> I downoaded ski and nue, and installed with:
>
> rpm -Uhv ski-0.943l-2.i386.rpm
> rpm -Uhv nue-1.1-1.i386.rpm
> rpm -Uhv nue-fs-1.2-1.i386.rpm
>
> I verified my installation with hello.c, but found
> that the compiled binary file can't be executed. Does
> anyone know why?
>
> My system is Redhat Linux 7.3, CPU Intel Pentium4
> 2.00GHZ, gcc version 2.96 20000731.
>
On some systems, the RPM post install script does not properly
execute the init script necessary to get the IA-64 binary
executed by the simulator. It is very easy to fix.
As root, simply type:
# /etc/rc.d/init.d/ia64fmt start
Then you will be able to run the IA-64 binary inside the NUE environment.
Note that next time you reboot your system, the rc script will be executed
automatically.
--
-Stephane
^ permalink raw reply
* Re: [PATCH][2.4] generic cluster APIC support for systems with more than 8 CPUs
From: William Lee Irwin III @ 2002-12-18 23:41 UTC (permalink / raw)
To: Christoph Hellwig, Pallipadi, Venkatesh, Linux Kernel,
Martin Bligh, John Stultz, Nakajima, Jun, jamesclv,
Mallick, Asit K, Saxena, Sunil
In-Reply-To: <20021218232640.A1746@infradead.org>
On Wed, Dec 18, 2002 at 11:26:40PM +0000, Christoph Hellwig wrote:
> Except of that the patch looks fine, but IMHO something like that should
> get testing in 2.5 first.
Yes, I'd prefer this happen in 2.5 first and that I and the rest of
everyone in our lab test the living daylights out of it on NUMA-Q.
Bill
^ 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.