* Re: [PATCH 2.6.17-rc1-mm1] sched_domain-handle-kmalloc-failure-fix
From: Dave Hansen @ 2006-04-07 18:01 UTC (permalink / raw)
To: Lee Schermerhorn; +Cc: linux-kernel, Andrew Morton, Eric Whitney
In-Reply-To: <1144353528.5162.190.camel@localhost.localdomain>
On Thu, 2006-04-06 at 15:58 -0400, Lee Schermerhorn wrote:
> 2.6.17-rc1-mm1 hangs during boot on HP rx8620 and dl585 -- both 4 node
> NUMA platforms. Problem is in build_sched_domains() setting up the
> sched_group_nodes[] lists, resulting from patch:
> sched_domain-handle-kmalloc-failure.patch
>
> The referenced patch does not propagate the "next" pointer from the head
> of the list, resulting in a loop between the last 2 groups in the list.
> This causes a tight loop/hang in init_numa_sched_groups_power() because
> 'sg->next' never == 'group_head' when you have > 2 nodes.
Wow. I'm incredibly impressed that you tracked that down. I can't
believe how horribly unintelligible that code is.
I ran into the same freeze on a 4-node NUMA-Q. Your patch fixed it.
Is there any good reason that sched domains has to roll its own linked
lists? Why not use list_heads? Seems like it would avoid crappy
problems like this.
-- Dave
^ permalink raw reply
* Re: fs/binfmt_elf.c:maydump()
From: Daniel Jacobowitz @ 2006-04-07 18:02 UTC (permalink / raw)
To: David S. Miller; +Cc: linux-kernel
In-Reply-To: <20060406.221807.114721185.davem@davemloft.net>
On Thu, Apr 06, 2006 at 10:18:07PM -0700, David S. Miller wrote:
> How about something like the following patch? If it's executable
> and not written to, skip it. This would skip the main executable
> image and all text segments of the shared libraries mapped in.
Will this dump text segments that have been COW'd for the purposes of
inserting a breakpoint?
It's just a question of goals, I guess. We could dump code, but it's
rarely useful, so historically we didn't. Similarly, we could dump
mapped data from shared memory, but it can be huge and is rarely
useful, so generally we don't.
--
Daniel Jacobowitz
CodeSourcery
^ permalink raw reply
* [Qemu-devel] Patch for sending large (>4k) packets through qemu/slirp
From: Kenneth Duda @ 2006-04-07 18:05 UTC (permalink / raw)
To: qemu-devel
In-Reply-To: <6fe044190604060153g1e642409p9682c21a774a21df@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 846 bytes --]
Hi everyone,
I have patches for a few bugs in qemu, and am new to the list --- if
anyone could clue me in on the best way to get patches applied to the
qemu mainline, that would be great.
This patch fixes three problems (actually all in slirp) with sending
large packets from guest to host in qemu-0.8.0.20060327:
(1) the code in slirp's ip_reass() reads a next pointer out an mbuf
after freeing it via m_cat().
(2) the code in slirp's m_inc() calls realloc() on a large mbuf, but
fails to adjust m_data to point to the new allocation (see
http://lists.gnu.org/archive/html/qemu-devel/2005-05/msg00228.html).
(3) there are many places within ip_input(), ip_reass(), udp_input(),
etc., that treat ip_len and ip_off as though they were declared
unsigned, when in fact they have been declared signed.
Thanks,
-Ken
[-- Attachment #2: qemu-slirp-reassembly-bug.patch --]
[-- Type: text/plain, Size: 466 bytes --]
diff -BurN qemu-snapshot-2006-03-27_23.orig/slirp/ip_input.c qemu-snapshot-2006-03-27_23/slirp/ip_input.c
--- qemu-snapshot-2006-03-27_23.orig/slirp/ip_input.c 2004-04-22 00:10:47.000000000 +0000
+++ qemu-snapshot-2006-03-27_23/slirp/ip_input.c 2006-04-06 06:02:52.000000000 +0000
@@ -344,8 +344,8 @@
while (q != (struct ipasfrag *)fp) {
struct mbuf *t;
t = dtom(q);
- m_cat(m, t);
q = (struct ipasfrag *) q->ipf_next;
+ m_cat(m, t);
}
/*
[-- Attachment #3: qemu-slirp-mbuf-bug.patch --]
[-- Type: text/plain, Size: 887 bytes --]
diff -BurN qemu-snapshot-2006-03-27_23.orig/slirp/mbuf.c qemu-snapshot-2006-03-27_23/slirp/mbuf.c
--- qemu-snapshot-2006-03-27_23.orig/slirp/mbuf.c 2004-04-22 00:10:47.000000000 +0000
+++ qemu-snapshot-2006-03-27_23/slirp/mbuf.c 2006-04-05 13:03:03.000000000 +0000
@@ -146,18 +146,19 @@
struct mbuf *m;
int size;
{
+ int datasize;
+
/* some compiles throw up on gotos. This one we can fake. */
if(m->m_size>size) return;
if (m->m_flags & M_EXT) {
- /* datasize = m->m_data - m->m_ext; */
+ datasize = m->m_data - m->m_ext;
m->m_ext = (char *)realloc(m->m_ext,size);
/* if (m->m_ext == NULL)
* return (struct mbuf *)NULL;
*/
- /* m->m_data = m->m_ext + datasize; */
+ m->m_data = m->m_ext + datasize;
} else {
- int datasize;
char *dat;
datasize = m->m_data - m->m_dat;
dat = (char *)malloc(size);
[-- Attachment #4: qemu-slirp-32k-packets.patch --]
[-- Type: text/plain, Size: 4433 bytes --]
diff -burN qemu-snapshot-2006-03-27_23.orig/slirp/ip.h qemu-snapshot-2006-03-27_23/slirp/ip.h
--- qemu-snapshot-2006-03-27_23.orig/slirp/ip.h 2004-04-21 17:10:47.000000000 -0700
+++ qemu-snapshot-2006-03-27_23/slirp/ip.h 2006-04-06 00:28:49.000000000 -0700
@@ -79,6 +79,11 @@
* We declare ip_len and ip_off to be short, rather than u_short
* pragmatically since otherwise unsigned comparisons can result
* against negative integers quite easily, and fail in subtle ways.
+ *
+ * The only problem with the above theory is that these quantities
+ * are in fact unsigned, and sorting fragments by a signed version
+ * of ip_off doesn't work very well, nor does length checks on
+ * ip packets with a signed version of their length!
*/
struct ip {
#ifdef WORDS_BIGENDIAN
@@ -101,6 +106,9 @@
struct in_addr ip_src,ip_dst; /* source and dest address */
};
+#define IP_OFF(ip) (*(u_int16_t *)&((ip)->ip_off))
+#define IP_LEN(ip) (*(u_int16_t *)&((ip)->ip_len))
+
#define IP_MAXPACKET 65535 /* maximum packet size */
/*
diff -burN qemu-snapshot-2006-03-27_23.orig/slirp/ip_input.c qemu-snapshot-2006-03-27_23/slirp/ip_input.c
--- qemu-snapshot-2006-03-27_23.orig/slirp/ip_input.c 2004-04-21 17:10:47.000000000 -0700
+++ qemu-snapshot-2006-03-27_23/slirp/ip_input.c 2006-04-06 00:32:19.000000000 -0700
@@ -111,7 +111,7 @@
* Convert fields to host representation.
*/
NTOHS(ip->ip_len);
- if (ip->ip_len < hlen) {
+ if (IP_LEN(ip) < hlen) {
ipstat.ips_badlen++;
goto bad;
}
@@ -124,13 +124,13 @@
* Trim mbufs if longer than we expect.
* Drop packet if shorter than we expect.
*/
- if (m->m_len < ip->ip_len) {
+ if (m->m_len < IP_LEN(ip)) {
ipstat.ips_tooshort++;
goto bad;
}
/* Should drop packet if mbuf too long? hmmm... */
- if (m->m_len > ip->ip_len)
- m_adj(m, ip->ip_len - m->m_len);
+ if (m->m_len > IP_LEN(ip))
+ m_adj(m, IP_LEN(ip) - m->m_len);
/* check ip_ttl for a correct ICMP reply */
if(ip->ip_ttl==0 || ip->ip_ttl==1) {
@@ -191,7 +191,7 @@
* or if this is not the first fragment,
* attempt reassembly; if it succeeds, proceed.
*/
- if (((struct ipasfrag *)ip)->ipf_mff & 1 || ip->ip_off) {
+ if (((struct ipasfrag *)ip)->ipf_mff & 1 || IP_OFF(ip)) {
ipstat.ips_fragments++;
ip = ip_reass((struct ipasfrag *)ip, fp);
if (ip == 0)
@@ -281,7 +281,7 @@
*/
for (q = (struct ipasfrag *)fp->ipq_next; q != (struct ipasfrag *)fp;
q = (struct ipasfrag *)q->ipf_next)
- if (q->ip_off > ip->ip_off)
+ if (IP_OFF(q) > IP_OFF(ip))
break;
/*
@@ -290,10 +290,10 @@
* segment. If it provides all of our data, drop us.
*/
if (q->ipf_prev != (ipasfragp_32)fp) {
- i = ((struct ipasfrag *)(q->ipf_prev))->ip_off +
- ((struct ipasfrag *)(q->ipf_prev))->ip_len - ip->ip_off;
+ i = IP_OFF((struct ipasfrag *)(q->ipf_prev)) +
+ IP_LEN((struct ipasfrag *)(q->ipf_prev)) - IP_OFF(ip);
if (i > 0) {
- if (i >= ip->ip_len)
+ if (i >= IP_LEN(ip))
goto dropfrag;
m_adj(dtom(ip), i);
ip->ip_off += i;
@@ -305,9 +305,9 @@
* While we overlap succeeding segments trim them or,
* if they are completely covered, dequeue them.
*/
- while (q != (struct ipasfrag *)fp && ip->ip_off + ip->ip_len > q->ip_off) {
- i = (ip->ip_off + ip->ip_len) - q->ip_off;
- if (i < q->ip_len) {
+ while (q != (struct ipasfrag *)fp && IP_OFF(ip) + IP_LEN(ip) > IP_OFF(q)) {
+ i = (IP_OFF(ip) + IP_LEN(ip)) - IP_OFF(q);
+ if (i < IP_LEN(q)) {
q->ip_len -= i;
q->ip_off += i;
m_adj(dtom(q), i);
@@ -327,9 +327,9 @@
next = 0;
for (q = (struct ipasfrag *) fp->ipq_next; q != (struct ipasfrag *)fp;
q = (struct ipasfrag *) q->ipf_next) {
- if (q->ip_off != next)
+ if (IP_OFF(q) != next)
return (0);
- next += q->ip_len;
+ next += IP_LEN(q);
}
if (((struct ipasfrag *)(q->ipf_prev))->ipf_mff & 1)
return (0);
diff -burN qemu-snapshot-2006-03-27_23.orig/slirp/udp.c qemu-snapshot-2006-03-27_23/slirp/udp.c
--- qemu-snapshot-2006-03-27_23.orig/slirp/udp.c 2006-04-06 00:24:30.000000000 -0700
+++ qemu-snapshot-2006-03-27_23/slirp/udp.c 2006-04-06 00:32:55.000000000 -0700
@@ -111,12 +111,12 @@
*/
len = ntohs((u_int16_t)uh->uh_ulen);
- if (ip->ip_len != len) {
- if (len > ip->ip_len) {
+ if (IP_LEN(ip) != len) {
+ if (len > IP_LEN(ip)) {
udpstat.udps_badlen++;
goto bad;
}
- m_adj(m, len - ip->ip_len);
+ m_adj(m, len - IP_LEN(ip));
ip->ip_len = len;
}
^ permalink raw reply
* wierd failures from -mm1
From: Martin Bligh @ 2006-04-07 18:05 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, Andy Whitcroft
I hadn't mailed this out for a while, cause we weren't sure if it was
-mm or a testing glitch, but there's been no -git releases, so Andy
reran -mm to double check, and it still seems to be there. a subsequent
test of rc1 + cons patches didn't hit this ... I think -mm has issues ;-)
Look at the 2.6.17-rc1-mm1 column from: http://test.kernel.org/
Drilling down into the console logs:
http://test.kernel.org/abat/27597/debug/console.log
Hangs after testing NMI watchdog.
http://test.kernel.org/abat/27596/debug/console.log
Hangs after bringing up cpus.
http://test.kernel.org/abat/27598/debug/console.log
http://test.kernel.org/abat/27593/debug/console.log
Both fail with reiserfs fsck errors; at first sight look like just dirty
root partitions, but I don't think they are.
Filesystem is clean
Failed to lock the process to fsck the mounted ro partition. Bad address.
fsck.reiserfs /dev/sda3 failed (status 0x8). Run manually!
Note that it's actually saying it's clean.
^ permalink raw reply
* Re: chmod u+s confusion
From: Chris Largret @ 2006-04-07 18:06 UTC (permalink / raw)
To: David Fierbaugh; +Cc: linux-newbie
In-Reply-To: <200604070842.19837.david@fierbaugh.org>
On Fri, 2006-04-07 at 08:42 +0000, David Fierbaugh wrote:
> I'd have to actually do a little playing around to make sure, but I believe
> that whoami is specifically written to NOT take SUID into account. It figures
> out exactly who ran the process which called it.
>
> This prevents faking out whoami into saying everyone is root.
I probably should have mentioned that this was just a PoC for what I was
trying to do. I'm actually trying to have the script create a file
someplace like /etc/cron.hourly. It has limited uses (and only my user
and root will be able to run it -- root group), but the script is
refusing to create the file.
> Why?
> Let's say you have a script that runs whoami to determine what
> access/control/etc a user should be given. If an attacker could manage to
> fake whoami into always saying the user was root by using suid, then they now
> have administrative access to whatever that script does.
>
> This would be a bad thing.
>
> You might also want to take a look at /bin/id
/usr/bin/id (where my id program is placed) still returns my username.
Thanks for the reply, but I'm still stumped :)
> > $ echo -e '#!/bin/sh\n\nwhoami'>whoami.sh
> > # chown root:root whoami.sh
> > # chmod 4755 whoami.sh
> > $ ./whoami.sh
> > chris
> > # chmod u+s `which whoami`
> > $ whoami
> > root
--
Chris Largret <http://daga.dyndns.org>
-
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: Trying again with cross compile
From: Adrian McMenamin @ 2006-04-07 18:07 UTC (permalink / raw)
To: Takashi Iwai; +Cc: alsa-devel
In-Reply-To: <s5hmzextpl7.wl%tiwai@suse.de>
On Fri, 2006-04-07 at 16:41 +0200, Takashi Iwai wrote:
> Maybe not yet? The fix is simple as below.
>
>
> Takashi
>
>
> diff -r fd751f7a6395 -r 6cddb34dad21 include/core.h
> --- a/include/core.h Thu Apr 6 15:23:55 2006 +0200
> +++ b/include/core.h Thu Apr 6 15:26:05 2006 +0200
> @@ -176,7 +176,7 @@ int snd_power_wait(struct snd_card *card
>
> #define snd_power_lock(card) do { (void)(card); } while (0)
> #define snd_power_unlock(card) do { (void)(card); } while (0)
> -static inline int snd_power_wait(struct snd_card *card, unsigned int state, struct file *file) { return 0; }
> +static inline int snd_power_wait(struct snd_card *card, unsigned int state) { return 0; }
> #define snd_power_get_state(card) SNDRV_CTL_POWER_D0
> #define snd_power_change_state(card, state) do { (void)(card); } while (0)
>
>
I've patched and everything seems to be fine expect that the build gets
wedged on hpi6000
I've even tried leaving if for over an hour - to no avail
Here's what make reports with debugging on if that helps anyone...
Successfully remade target file
`/home/adrian/alsa-driver/pci/asihpi/hpi4000.o'.
Considering target file
`/home/adrian/alsa-driver/pci/asihpi/hpi6000.o'.
File `/home/adrian/alsa-driver/pci/asihpi/hpi6000.o' does not
exist.
Looking for an implicit rule for
`/home/adrian/alsa-driver/pci/asihpi/hpi6000.o'.
Trying pattern rule with stem `hpi6000.o'.
Trying implicit prerequisite
`/home/adrian/alsa-driver/pci/asihpi/hpi6000.o_shipped'.
Trying pattern rule with stem `hpi6000'.
Trying implicit prerequisite
`/home/adrian/alsa-driver/pci/asihpi/hpi6000.c'.
Trying rule prerequisite `FORCE'.
Found an implicit rule for
`/home/adrian/alsa-driver/pci/asihpi/hpi6000.o'.
Considering target file
`/home/adrian/alsa-driver/pci/asihpi/hpi6000.c'.
Looking for an implicit rule for
`/home/adrian/alsa-driver/pci/asihpi/hpi6000.c'.
Trying pattern rule with stem `hpi6000.c'.
Trying implicit prerequisite
`/home/adrian/alsa-driver/pci/asihpi/hpi6000.c_shipped'.
Trying pattern rule with stem `hpi6000'.
Trying implicit prerequisite
`/home/adrian/alsa-driver/pci/asihpi/hpi6000.y'.
Trying pattern rule with stem `hpi6000'.
Trying implicit prerequisite
`/home/adrian/alsa-driver/pci/asihpi/hpi6000.l'.
Trying pattern rule with stem `hpi6000'.
Trying implicit prerequisite
`/home/adrian/alsa-driver/pci/asihpi/hpi6000.w'.
Trying pattern rule with stem `hpi6000'.
Trying implicit prerequisite
`/home/adrian/alsa-driver/pci/asihpi/hpi6000.w'.
Trying pattern rule with stem `hpi6000.c'.
Trying implicit prerequisite
`/home/adrian/alsa-driver/pci/asihpi/hpi6000.c,v'.
Trying pattern rule with stem `hpi6000.c'.
Trying implicit prerequisite
`/home/adrian/alsa-driver/pci/asihpi/RCS/hpi6000.c,v'.
Trying pattern rule with stem `hpi6000.c'.
Trying implicit prerequisite
`/home/adrian/alsa-driver/pci/asihpi/RCS/hpi6000.c'.
Trying pattern rule with stem `hpi6000.c'.
Trying implicit prerequisite
`/home/adrian/alsa-driver/pci/asihpi/s.hpi6000.c'.
Trying pattern rule with stem `hpi6000.c'.
Trying implicit prerequisite
`/home/adrian/alsa-driver/pci/asihpi/SCCS/s.hpi6000.c'.
Trying pattern rule with stem `hpi6000'.
Trying implicit prerequisite
`/home/adrian/alsa-driver/pci/asihpi/hpi6000.y'.
Looking for a rule with intermediate file
`/home/adrian/alsa-driver/pci/asihpi/hpi6000.y'.
Avoiding implicit rule recursion.
Trying pattern rule with stem `hpi6000.y'.
Trying implicit prerequisite
`/home/adrian/alsa-driver/pci/asihpi/hpi6000.y_shipped'.
Trying pattern rule with stem `hpi6000.y'.
Trying implicit prerequisite
`/home/adrian/alsa-driver/pci/asihpi/hpi6000.y,v'.
Trying pattern rule with stem `hpi6000.y'.
Trying implicit prerequisite
`/home/adrian/alsa-driver/pci/asihpi/RCS/hpi6000.y,v'.
Trying pattern rule with stem `hpi6000.y'.
Trying implicit prerequisite
`/home/adrian/alsa-driver/pci/asihpi/RCS/hpi6000.y'.
Trying pattern rule with stem `hpi6000.y'.
Trying implicit prerequisite
`/home/adrian/alsa-driver/pci/asihpi/s.hpi6000.y'.
Trying pattern rule with stem `hpi6000.y'.
Trying implicit prerequisite
`/home/adrian/alsa-driver/pci/asihpi/SCCS/s.hpi6000.y'.
Trying pattern rule with stem `hpi6000'.
Trying implicit prerequisite
`/home/adrian/alsa-driver/pci/asihpi/hpi6000.l'.
Looking for a rule with intermediate file
`/home/adrian/alsa-driver/pci/asihpi/hpi6000.l'.
Avoiding implicit rule recursion.
Trying pattern rule with stem `hpi6000.l'.
Trying implicit prerequisite
`/home/adrian/alsa-driver/pci/asihpi/hpi6000.l_shipped'.
Trying pattern rule with stem `hpi6000.l'.
Trying implicit prerequisite
`/home/adrian/alsa-driver/pci/asihpi/hpi6000.l,v'.
Trying pattern rule with stem `hpi6000.l'.
Trying implicit prerequisite
`/home/adrian/alsa-driver/pci/asihpi/RCS/hpi6000.l,v'.
Trying pattern rule with stem `hpi6000.l'.
Trying implicit prerequisite
`/home/adrian/alsa-driver/pci/asihpi/RCS/hpi6000.l'.
Trying pattern rule with stem `hpi6000.l'.
Trying implicit prerequisite
`/home/adrian/alsa-driver/pci/asihpi/s.hpi6000.l'.
Trying pattern rule with stem `hpi6000.l'.
Trying implicit prerequisite
`/home/adrian/alsa-driver/pci/asihpi/SCCS/s.hpi6000.l'.
Trying pattern rule with stem `hpi6000'.
Trying implicit prerequisite
`/home/adrian/alsa-driver/pci/asihpi/hpi6000.w'.
Looking for a rule with intermediate file
`/home/adrian/alsa-driver/pci/asihpi/hpi6000.w'.
Avoiding implicit rule recursion.
Trying pattern rule with stem `hpi6000.w'.
Trying implicit prerequisite
`/home/adrian/alsa-driver/pci/asihpi/hpi6000.w_shipped'.
Trying pattern rule with stem `hpi6000.w'.
Trying implicit prerequisite
`/home/adrian/alsa-driver/pci/asihpi/hpi6000.w,v'.
Trying pattern rule with stem `hpi6000.w'.
Trying implicit prerequisite
`/home/adrian/alsa-driver/pci/asihpi/RCS/hpi6000.w,v'.
Trying pattern rule with stem `hpi6000.w'.
Trying implicit prerequisite
`/home/adrian/alsa-driver/pci/asihpi/RCS/hpi6000.w'.
Trying pattern rule with stem `hpi6000.w'.
Trying implicit prerequisite
`/home/adrian/alsa-driver/pci/asihpi/s.hpi6000.w'.
Trying pattern rule with stem `hpi6000.w'.
Trying implicit prerequisite
`/home/adrian/alsa-driver/pci/asihpi/SCCS/s.hpi6000.w'.
Trying pattern rule with stem `hpi6000'.
Rejecting impossible implicit prerequisite
`/home/adrian/alsa-driver/pci/asihpi/hpi6000.w'.
No implicit rule found for
`/home/adrian/alsa-driver/pci/asihpi/hpi6000.c'.
Finished prerequisites of target file
`/home/adrian/alsa-driver/pci/asihpi/hpi6000.c'.
No need to remake target
`/home/adrian/alsa-driver/pci/asihpi/hpi6000.c'.
Pruning file `FORCE'.
Finished prerequisites of target file
`/home/adrian/alsa-driver/pci/asihpi/hpi6000.o'.
Must remake target `/home/adrian/alsa-driver/pci/asihpi/hpi6000.o'.
Putting child 0x080e9bd8 (/home/adrian/alsa-driver/pci/asihpi/hpi6000.o)
PID 19527 on the chain.
Live child 0x080e9bd8 (/home/adrian/alsa-driver/pci/asihpi/hpi6000.o)
PID 19527
CC [M] /home/adrian/alsa-driver/pci/asihpi/hpi6000.o
It sticks here for ever - though top reports cc1 is still active
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
^ permalink raw reply
* [Bluez-devel] Discoverabe Mode - GIAC or LIAC
From: Renan @ 2006-04-07 18:07 UTC (permalink / raw)
To: bluez-devel
[-- Attachment #1: Type: text/plain, Size: 212 bytes --]
Hello everyone!!!
Does anybody know how to set the discoverable mode for a device under
Linux?
How to set the LIAC/GIAC mode for a device?
Thanks in advance.
Renan Martins
renan@atlantico.com.br
[-- Attachment #2: Type: text/html, Size: 5366 bytes --]
^ permalink raw reply
* [Qemu-devel] Patch for minor qemu heap corruption bug when the console is zero width
From: Kenneth Duda @ 2006-04-07 18:08 UTC (permalink / raw)
To: qemu-devel
In-Reply-To: <6fe044190604060153i6b43333dlec41c663f2229cd3@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 522 bytes --]
Hi everyone, here is another patch for a much less significant bug. If
your "vc" console width is 0, qemu corrupts the heap (because it
writes one character into a screen buffer that's been malloc'ed as
size 0). I don't know if this bug ever causes problems in practice
--- I picked it up using mcheck() when debugging heap corruption due
to various slirp bugs. Anyway, this trivial patch fixes the trivial
bug. Feedback on what I can do to get patches like this applied most
appreciated!
Thanks,
-Ken
[-- Attachment #2: qemu-zero-width-console.patch --]
[-- Type: text/plain, Size: 664 bytes --]
diff -burN qemu-snapshot-2006-03-27_23.orig/console.c qemu-snapshot-2006-03-27_23/console.c
--- qemu-snapshot-2006-03-27_23.orig/console.c 2006-03-11 07:35:30.000000000 -0800
+++ qemu-snapshot-2006-03-27_23/console.c 2006-04-06 00:25:41.000000000 -0700
@@ -407,7 +407,8 @@
if (s->width < w1)
w1 = s->width;
- cells = qemu_malloc(s->width * s->total_height * sizeof(TextCell));
+ cells = qemu_malloc((s->width * s->total_height + 1) * sizeof(TextCell));
+ /* Add one extra in case s->width is 0, so we can still store one character. */
for(y = 0; y < s->total_height; y++) {
c = &cells[y * s->width];
if (w1 > 0) {
^ permalink raw reply
* [linux-lvm] logical extent (630) already mapped
From: Oliver Hörold @ 2006-04-07 18:09 UTC (permalink / raw)
To: lvm mailinglist
hi,
after using for some time lvm without any problems, my lvm system
generates after rebooting some strang errors.
the problems look like these:
http://www.copilotconsulting.com/mail-archives/linux-lvm.2005/msg00025.html
but the solution doesnt work for me.
summery:
system suse 10.1, boot drive sata /dev/sda (no lvm)
lvm composed of 8 ide drives (/dev/hda to /dev/hdh)
worked for some time, but i think the auto-update of suse screwed the
lvm.
pvscan, pvdisplay, lvsvan and vgscan all generate errors. i have no idea
where the "logic extend" is already mapped. i cant diagnose the error.
i think the pv are still intact, but i dont knwo how to put em back
together.
here are some of the errors:
tokyoo:/tmp # pvscan
/dev/sdb: open failed: Kein Medium gefunden (No Media found)
/dev/sdc: open failed: Kein Medium gefunden
/dev/sdd: open failed: Kein Medium gefunden
/dev/sde: open failed: Kein Medium gefunden
logical extent (630) already mapped.
Couldn't fill logical volume maps.
logical extent (630) already mapped.
Couldn't fill logical volume maps.
No matching physical volumes found
tokyoo:/tmp # pvdisplay
logical extent (630) already mapped.
Couldn't fill logical volume maps.
logical extent (630) already mapped.
Couldn't fill logical volume maps.
remark: with every commad that generates an error i get the "No Media
found" error block f�r the /dev/sdx devices. i removed them to save
space.
but strangely the single drives are recognised as proper PV:
tokyoo:/tmp # pvdisplay /dev/hda1
--- Physical volume ---
PV Name /dev/hda1
VG Name system
PV Size 111,78 GB / not usable 0
Allocatable yes
PE Size (KByte) 16384
Total PE 7154
Free PE 7154
Allocated PE 0
PV UUID afdGTQ-95Qv-f3oL-anWh-V2LO-PKIf-eXTbRb
[...]
some other things i tried:
tokyoo:/tmp # lvscan
logical extent (630) already mapped.
Couldn't fill logical volume maps.
logical extent (630) already mapped.
Couldn't fill logical volume maps.
Volume group "system" not found
tokyoo:/tmp # lvdisplay
logical extent (630) already mapped.
Couldn't fill logical volume maps.
logical extent (630) already mapped.
Couldn't fill logical volume maps.
Volume group "system" not found
tokyoo:/tmp # lvdisplay system
logical extent (630) already mapped.
Couldn't fill logical volume maps.
logical extent (630) already mapped.
Couldn't fill logical volume maps.
Volume group "system" not found
tokyoo:/tmp # vgscan
Reading all physical volumes. This may take a while...
logical extent (630) already mapped.
Couldn't fill logical volume maps.
logical extent (630) already mapped.
Couldn't fill logical volume maps.
Volume group "system" not found
tokyoo:/tmp # vgcreate
erwin /dev/hda1 /dev/hdc1 /dev/hdd1 /dev/hde1 /dev/hdf1 /dev/hdg1 /dev/hdh1
Physical volume '/dev/hda1' is already in volume group 'system'
Unable to add physical volume '/dev/hda1' to volume group 'erwin'.
^ permalink raw reply
* Re: Trying again with cross compile
From: Takashi Iwai @ 2006-04-07 18:10 UTC (permalink / raw)
To: Adrian McMenamin; +Cc: alsa-devel
In-Reply-To: <1144433221.9653.51.camel@localhost.localdomain>
At Fri, 07 Apr 2006 19:07:01 +0100,
Adrian McMenamin wrote:
>
> On Fri, 2006-04-07 at 16:41 +0200, Takashi Iwai wrote:
>
> > Maybe not yet? The fix is simple as below.
> >
> >
> > Takashi
> >
> >
> > diff -r fd751f7a6395 -r 6cddb34dad21 include/core.h
> > --- a/include/core.h Thu Apr 6 15:23:55 2006 +0200
> > +++ b/include/core.h Thu Apr 6 15:26:05 2006 +0200
> > @@ -176,7 +176,7 @@ int snd_power_wait(struct snd_card *card
> >
> > #define snd_power_lock(card) do { (void)(card); } while (0)
> > #define snd_power_unlock(card) do { (void)(card); } while (0)
> > -static inline int snd_power_wait(struct snd_card *card, unsigned int state, struct file *file) { return 0; }
> > +static inline int snd_power_wait(struct snd_card *card, unsigned int state) { return 0; }
> > #define snd_power_get_state(card) SNDRV_CTL_POWER_D0
> > #define snd_power_change_state(card, state) do { (void)(card); } while (0)
> >
> >
>
> I've patched and everything seems to be fine expect that the build gets
> wedged on hpi6000
>
> I've even tried leaving if for over an hour - to no avail
>
> Here's what make reports with debugging on if that helps anyone...
Above all, why do you compile that driver??
You'd better to use --with-cards option.
Takashi
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
^ permalink raw reply
* Re: Trying again with cross compile
From: Adrian McMenamin @ 2006-04-07 18:18 UTC (permalink / raw)
To: Takashi Iwai; +Cc: alsa-devel
In-Reply-To: <s5h4q151ckb.wl%tiwai@suse.de>
On Fri, 2006-04-07 at 20:10 +0200, Takashi Iwai wrote:
> At Fri, 07 Apr 2006 19:07:01 +0100,
> Adrian McMenamin wrote:
> >
> > On Fri, 2006-04-07 at 16:41 +0200, Takashi Iwai wrote:
> >
> > > Maybe not yet? The fix is simple as below.
> > >
> > >
> > > Takashi
> > >
> > >
> > > diff -r fd751f7a6395 -r 6cddb34dad21 include/core.h
> > > --- a/include/core.h Thu Apr 6 15:23:55 2006 +0200
> > > +++ b/include/core.h Thu Apr 6 15:26:05 2006 +0200
> > > @@ -176,7 +176,7 @@ int snd_power_wait(struct snd_card *card
> > >
> > > #define snd_power_lock(card) do { (void)(card); } while (0)
> > > #define snd_power_unlock(card) do { (void)(card); } while (0)
> > > -static inline int snd_power_wait(struct snd_card *card, unsigned int state, struct file *file) { return 0; }
> > > +static inline int snd_power_wait(struct snd_card *card, unsigned int state) { return 0; }
> > > #define snd_power_get_state(card) SNDRV_CTL_POWER_D0
> > > #define snd_power_change_state(card, state) do { (void)(card); } while (0)
> > >
> > >
> >
> > I've patched and everything seems to be fine expect that the build gets
> > wedged on hpi6000
> >
> > I've even tried leaving if for over an hour - to no avail
> >
> > Here's what make reports with debugging on if that helps anyone...
>
> Above all, why do you compile that driver??
> You'd better to use --with-cards option.
Because I still haven't worked out how to get it to build the sh drivers
and I was just testing it building 'all'
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
^ permalink raw reply
* Re: wierd failures from -mm1
From: Martin Bligh @ 2006-04-07 18:20 UTC (permalink / raw)
To: Dave Hansen; +Cc: Andrew Morton, linux-kernel, Andy Whitcroft
In-Reply-To: <1144433309.24221.7.camel@localhost.localdomain>
Dave Hansen wrote:
> On Fri, 2006-04-07 at 11:05 -0700, Martin Bligh wrote:
>
>>http://test.kernel.org/abat/27596/debug/console.log
>>Hangs after bringing up cpus.
>
>
> See attached patch. It fixes curly.
Splendid -thanks. This may well fix the first two ... I think the reiser
thing is likely still borked though.
M.
> -- Dave
>
>
> ------------------------------------------------------------------------
>
> Subject:
> [PATCH 2.6.17-rc1-mm1] sched_domain-handle-kmalloc-failure-fix
> From:
> Lee Schermerhorn <Lee.Schermerhorn@hp.com>
> Date:
> Thu, 06 Apr 2006 15:58:47 -0400
> To:
> linux-kernel <linux-kernel@vger.kernel.org>
>
> To:
> linux-kernel <linux-kernel@vger.kernel.org>
> CC:
> Andrew Morton <akpm@osdl.org>, Eric Whitney <eric.whitney@hp.com>
>
>
> [PATCH] sched_domain-handle-kmalloc-failure-fix
>
> 2.6.17-rc1-mm1 hangs during boot on HP rx8620 and dl585 -- both 4 node
> NUMA platforms. Problem is in build_sched_domains() setting up the
> sched_group_nodes[] lists, resulting from patch:
> sched_domain-handle-kmalloc-failure.patch
>
> The referenced patch does not propagate the "next" pointer from the head
> of the list, resulting in a loop between the last 2 groups in the list.
> This causes a tight loop/hang in init_numa_sched_groups_power() because
> 'sg->next' never == 'group_head' when you have > 2 nodes.
>
> This patch seems to fix the problem.
>
> Signed-off-by: Lee Schermerhorn <lee.schermerhorn@hp.com>
>
> Index: linux-2.6.17-rc1-mm1/kernel/sched.c
> ===================================================================
> --- linux-2.6.17-rc1-mm1.orig/kernel/sched.c 2006-04-06 15:18:32.000000000 -0400
> +++ linux-2.6.17-rc1-mm1/kernel/sched.c 2006-04-06 15:20:49.000000000 -0400
> @@ -6360,7 +6360,7 @@ static int build_sched_domains(const cpu
> }
> sg->cpu_power = 0;
> sg->cpumask = tmp;
> - sg->next = prev;
> + sg->next = prev->next;
> cpus_or(covered, covered, tmp);
> prev->next = sg;
> prev = sg;
>
>
> -
> 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/
^ permalink raw reply
* [ALSA - driver 0002004]: Via say unknown codec on FSC Amilo 1667G
From: bugtrack @ 2006-04-07 18:21 UTC (permalink / raw)
To: alsa-devel
A NOTE has been added to this issue.
======================================================================
<https://bugtrack.alsa-project.org/alsa-bug/view.php?id=2004>
======================================================================
Reported By: deathlove23
Assigned To:
======================================================================
Project: ALSA - driver
Issue ID: 2004
Category: PCI - via82xx
Reproducibility: always
Severity: feature
Priority: normal
Status: new
Distribution: Gentoo
Kernel Version: 2.6.16
======================================================================
Date Submitted: 04-05-2006 18:40 CEST
Last Modified: 04-07-2006 20:21 CEST
======================================================================
Summary: Via say unknown codec on FSC Amilo 1667G
Description:
Hello,
I have a Notebook from FSC: Amilo 1667G
and is get thes messages in boot bzw. on dmesg:
---
ALSA device list:
#0: VIA 8237 with unknown codec at 0xc800, irq 50
---
my Alsa Kernel config is:
---
CONFIG_SND=y
CONFIG_SND_TIMER=y
CONFIG_SND_PCM=y
CONFIG_SND_RAWMIDI=y
CONFIG_SND_RTCTIMER=y
CONFIG_SND_MPU401_UART=y
CONFIG_SND_AC97_CODEC=y
CONFIG_SND_AC97_BUS=y
CONFIG_SND_VIA82XX=y
---
and my lspci -vv is:
---
00:11.5 Multimedia audio controller: VIA Technologies, Inc.
VT8233/A/8235/8237 AC97 Audio Controller (rev 60)
Subsystem: Fujitsu Siemens Computer GmbH Unknown device 1093
Control: I/O+ Mem- BusMaster- SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Interrupt: pin C routed to IRQ 50
Region 0: I/O ports at c800 [size=256]
Capabilities: [c0] Power Management version 2
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
---
can you my soundcard to the ID lists eg. another Amilio's?
Thanks
Alex - Deathlove23
======================================================================
----------------------------------------------------------------------
tiwai - 04-07-06 19:21
----------------------------------------------------------------------
Please upload the contents of /proc/asound/card0/codec97#0/* files.
----------------------------------------------------------------------
deathlove23 - 04-07-06 20:21
----------------------------------------------------------------------
thanks for you replay, i upload the Files.
Issue History
Date Modified Username Field Change
======================================================================
04-05-06 18:40 deathlove23 New Issue
04-05-06 18:40 deathlove23 Distribution => Gentoo
04-05-06 18:40 deathlove23 Kernel Version => 2.6.16
04-07-06 19:21 tiwai Note Added: 0009145
04-07-06 20:17 deathlove23 Issue Monitored: deathlove23
04-07-06 20:19 deathlove23 File Added: ac97#0-0
04-07-06 20:19 deathlove23 File Added: ac97#0-0+regs
04-07-06 20:19 deathlove23 Issue End Monitor: deathlove23
04-07-06 20:21 deathlove23 Note Added: 0009155
======================================================================
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
^ permalink raw reply
* Re: Trying again with cross compile
From: Takashi Iwai @ 2006-04-07 18:22 UTC (permalink / raw)
To: Adrian McMenamin; +Cc: alsa-devel
In-Reply-To: <1144433926.9653.53.camel@localhost.localdomain>
At Fri, 07 Apr 2006 19:18:45 +0100,
Adrian McMenamin wrote:
>
> On Fri, 2006-04-07 at 20:10 +0200, Takashi Iwai wrote:
> > At Fri, 07 Apr 2006 19:07:01 +0100,
> > Adrian McMenamin wrote:
> > >
> > > On Fri, 2006-04-07 at 16:41 +0200, Takashi Iwai wrote:
> > >
> > > > Maybe not yet? The fix is simple as below.
> > > >
> > > >
> > > > Takashi
> > > >
> > > >
> > > > diff -r fd751f7a6395 -r 6cddb34dad21 include/core.h
> > > > --- a/include/core.h Thu Apr 6 15:23:55 2006 +0200
> > > > +++ b/include/core.h Thu Apr 6 15:26:05 2006 +0200
> > > > @@ -176,7 +176,7 @@ int snd_power_wait(struct snd_card *card
> > > >
> > > > #define snd_power_lock(card) do { (void)(card); } while (0)
> > > > #define snd_power_unlock(card) do { (void)(card); } while (0)
> > > > -static inline int snd_power_wait(struct snd_card *card, unsigned int state, struct file *file) { return 0; }
> > > > +static inline int snd_power_wait(struct snd_card *card, unsigned int state) { return 0; }
> > > > #define snd_power_get_state(card) SNDRV_CTL_POWER_D0
> > > > #define snd_power_change_state(card, state) do { (void)(card); } while (0)
> > > >
> > > >
> > >
> > > I've patched and everything seems to be fine expect that the build gets
> > > wedged on hpi6000
> > >
> > > I've even tried leaving if for over an hour - to no avail
> > >
> > > Here's what make reports with debugging on if that helps anyone...
> >
> > Above all, why do you compile that driver??
> > You'd better to use --with-cards option.
>
> Because I still haven't worked out how to get it to build the sh drivers
> and I was just testing it building 'all'
Then better to fix that first. Why don't you post the patch you're
trying?
Takashi
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
^ permalink raw reply
* Re: SuSE 10.0 and it's RPM 4.1.1??
From: Hal MacArgle @ 2006-04-07 18:23 UTC (permalink / raw)
To: SOTL; +Cc: linux-newbie
In-Reply-To: <200604060902.11198.sotl155360@earthlink.net>
On 04-06, SOTL wrote:
> On Wednesday 05 April 2006 11:10 am, Hal MacArgle wrote:
> > Greetings: A Slackware junkie all my Linux life, I'm just now
> > "playing" with other distributions that use RPM..
> >
> > At first I thought, piece of cake, invoking rpm -i package.rpm;
> > slick..
> >
> > That didn't last, when I tried installing a package that didn't play
> > ball, and opened Pandora's box of queries.. Man rpm shed some light,
> > what I understood, so I pulled a book I had covering Red Hat 6.2 -
> > rather old, but just maybe??
> >
> > rpm -i package.rpm - returns "warning: package.rpm: V3 DSA signature:
> > NOKEY, key ID [octet of characters]
> > error: Failed dependencies: (with a list of no less than 15 of them
> > reporting the exact library needed...)
> >
> > First off, I didn't know what V3 DSA meant, but the missing
> > dependencies are fairly normal these days.. I had some work ahead of
> > me but the RedHat book said to use rpm -q --redhatprovides
> > <library.so.X> and it would list the base package needed.. This is
> > not RedHat, of course, but there is a --provides flag that didn't
> > return anything except that the package was missing.. I tried that
> > entering a library that's either in /lib or /usr/lib, and it returned
> > "Package not installed." I'm presuming this has been changed for, at
> > least, libraries.. Or--is it the NOKEY thingy?? Stumped!!
> >
> > BTW the subject package was fetched from rpm.pbone.net, whereas the
> > rpm's installed previous to that were ones in the SuSE distribution
> > package.. That has to have a lot to do with it, IMHO... <grin>
> >
> > Is there a tutorial that explains this better than the man?? TIA.
>
> If I recall correctly RPM stands for Red Hat Package Manager which I believe
> is uses by Fedora/Redhat and FreeMandriva/Mandriva/Mandrake.
True AFAIK; plus others including Slackware that has the rpm
program but warns us that it doesn't work with all apps... Open
Source keeps us on our toes, eh?? Could it be with SuSe that it means
something like Reliable Package Manager, instead of RedHat Package
Manager?? Stranger things have happened.. The study of acronyms is
another PhD dissertation..
> Not sure on this but I believe that SuSE uses a different package system which
> is not compatable with Red Hat's.
This is what I really needed to know.. "RPM" is not,
necessarily, "RPM"... Open Source again??
> I am sure that Debian uses a different system which is also used by Ubuntu and
> Kubuntu.
Yes; ".deb" and it too probably works with other
distributions unknown by me.. It's getting much more complicated than
when I first found Linux after years of Unix...
> If what you are doing is what I infer from your title that you are trying to
> install RPM into a SuSE system then I do not believe even if there were no
> issues with the package manager that it would work as Red Hat and SuSE do
> things internally sufficiently different that the only package that I am
> aware of that will run equally on both system is OpenOffice.org's Office
> package which basically puts all libraries and all components into a separate
> root directory with no integration. Since this is not the Linux/Unix way but
> is the MS way which OO is emulating I do not believe that you will find any
> other package that will install and run in a equivalent way.Thus I believe
> that it may be best to find the correct SuSE package for installation. From
> past experience not with SuSE but other distributions if you do not you are
> simply asking for problems.
More or less, simply, I've been looking for a distribution
that supports streaming video including editing, etc, not that I want
the M$ route either.. It's obviously extremely complicated so I'm
going to build on what I have already using Slackware 10.2, kernel
2.4.31... Skirting around to other distributions to make it "simple"
just hasn't happened.. My mind was definately made up when I tried
yet another .rpm package that needed 25 extra dependencies, most of
which I already had in either /lib or /usr/lib and I have no idea why
the package didn't find them... It's moot now... <grin>
Appreciate your comments; you did confirm one big suspicion..
Hal - in Terra Alta, WV/US - Slackware GNU/Linux 10.1 (2.4.29)
.
-
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: wait4/waitpid/waitid oddness
From: Eric W. Biederman @ 2006-04-07 18:23 UTC (permalink / raw)
To: Albert Cahalan; +Cc: linux-kernel
In-Reply-To: <787b0d920604052038i3a75bdb6ic0818d93805b881b@mail.gmail.com>
"Albert Cahalan" <acahalan@gmail.com> writes:
> The kernel prohibits:
>
> 1. WNOHANG on waitpid/wait4
Not 2.6.17-rc1, and not for a lot of earlier kernels.
At least not on ingress, and just skimming the code
I can't see any deeper checks that would prevent this.
> 2. __WALL on waitid
>
> Why? I need both at once.
Which kernel is failing, and how?
Eric
^ permalink raw reply
* Slow guest network I/O when CPU is pegged - Looking for acknowledgement from developers
From: Matt Ayres @ 2006-04-07 18:25 UTC (permalink / raw)
To: xen-devel@lists.xensource.com
Ok, so we all know that guest network I/O is slow when the system CPU's
are being utilized extensively whether it be from dom0 or from other
guests. Lots of people have written about this and I can post concrete
tests if required.
I'm just looking for one of the Xen developers to acknowledge that they
have been able to replicate the problem and it is indeed being worked on
or will be sometime in the near future. No one has acknowledged any of
the previous threads on either list so I want to make sure it is an
outstanding issue that is not being overlooked.
Thank you,
Matt Ayres
(Just ask for my tests and I'll paste the output / file a bug, but I
think it's been an established bug and didn't want to make this e-mail
too verbose.)
^ permalink raw reply
* [LARTC] u32 and iptables do not work together
From: Nataniel Klug @ 2006-04-07 18:26 UTC (permalink / raw)
To: lartc
Hello all,
I am trying to make a filter into my QoS rules and I founded that
when I try to use filters u32 and with fwmark they do not work together.
This is the filter I use, just and example, for u32:
$TC filter add dev $DL parent 1:0 protocol ip prio 1 u32 match ip sport
22 0xffff flowid 1:10
This is working fine. Now if I try to mark a package that I want it
to go to the same class (1:10) it get an error:
$IPT -t mangle -A PREROUTING -s 200.163.208.4 -j MARK --set-mark 10
Then I tryed to make the filter for this:
$TC filter add dev $DL parent 1:0 protocol ip prio 1 handle 10 fw
classid 1:10
RETURNS:
[root@ns1 rc.d]# /sbin/tc filter add dev eth3 parent 1:0 protocol ip
prio 1 handle 10 fw classid 1:10
RTNETLINK answers: Invalid argument
We have an error talking to the kernel
[root@ns1 rc.d]#
Anyone knows what can I do? My full script (the one that is working
fine is at the end).
Att,
Nataniel Klug
------
#!/bin/sh
#------
# Script de QoS Cyber Nett
#------
# Nataniel Klug
# suporte@cnett.com.br
#------
TC="/sbin/tc"
IPT="/usr/local/sbin/iptables"
DL="eth3"
#------
# Apagando regras antigas de QoS
#------
$TC qdisc del dev $DL root 2> /dev/null > /dev/null
$TC qdisc del dev $DL ingress 2> /dev/null > /dev/null
#------
# Regras para a placa eth1
#------
$TC qdisc add dev $DL root handle 1: htb default 50
CLASS="/sbin/tc class add dev $DL parent"
$CLASS 1: classid 1:1 htb rate 3072Kbit
$CLASS 1:1 classid 1:10 htb rate 256Kbit prio 1
$CLASS 1:1 classid 1:20 htb rate 1024Kbit ceil 2048Kbit prio 2
$CLASS 1:1 classid 1:30 htb rate 512Kbit ceil 512Kbit prio 3
$CLASS 1:1 classid 1:40 htb rate 512Kbit ceil 512Kbit prio 3
$CLASS 1:1 classid 1:50 htb rate 512Kbit ceil 512Kbit prio 4
QDISC="/sbin/tc qdisc add dev $DL parent"
$QDISC 1:10 handle 10: sfq perturb 10
$QDISC 1:20 handle 20: sfq perturb 10
$QDISC 1:30 handle 30: sfq perturb 10
$QDISC 1:40 handle 40: sfq perturb 10
$QDISC 1:50 handle 50: sfq perturb 10
FILTER="/sbin/tc filter add dev $DL parent 1:0 protocol ip prio 1 u32"
$FILTER match ip protocol 1 0xff flowid 1:10
$FILTER match ip sport 22 0xffff flowid 1:10
$FILTER match ip sport 23 0xffff flowid 1:10
$FILTER match ip sport 2202 0xffff flowid 1:10
$FILTER match ip sport 6121 0xffff flowid 1:10
$FILTER match ip sport 5121 0xffff flowid 1:10
$FILTER match ip sport 80 0xffff flowid 1:20
$FILTER match ip sport 443 0xffff flowid 1:20
$FILTER match ip sport 3128 0xffff flowid 1:20
$FILTER match ip src 200.189.176.206/32 flowid 1:20
$FILTER match ip src 200.189.176.205/32 flowid 1:20
$FILTER match ip sport 5065 0xffff flowid 1:20
$FILTER match ip sport 5070 0xffff flowid 1:20
$FILTER match ip sport 53 0xffff flowid 1:30
$FILTER match ip sport 25 0xffff flowid 1:30
$FILTER match ip sport 110 0xffff flowid 1:30
$FILTER match ip sport 21 0xffff flowid 1:40
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
^ permalink raw reply
* Re: Oops at __bio_clone with 2.6.16-rc6 anyone??????
From: Don Dupuis @ 2006-04-07 18:29 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel
In-Reply-To: <632b79000604070823s7f495d5ci416c9cef63ba11b@mail.gmail.com>
On 4/7/06, Don Dupuis <dondster@gmail.com> wrote:
> On 3/28/06, Andrew Morton <akpm@osdl.org> wrote:
> > "Don Dupuis" <dondster@gmail.com> wrote:
> > >
> > > Yes it does also happen on 2.6.16
> > >
> >
> > (please don't top-post).
> >
> > >
> > > On 3/27/06, Andrew Morton <akpm@osdl.org> wrote:
> > > > "Don Dupuis" <dondster@gmail.com> wrote:
> > > > >
> > > > > I will get this oops during reboots. It doesn't happen everytime, but
> > > > > It happens on this system at least 1 to 2 out of 10 reboots. The
> > > > > machine is a Dell Powervault 745n. Here is the oops output:
> > > > >
> > > > > Mar 20 22:27:49 (none) kernel: EXT3-fs: mounted filesystem with
> > > > > journal data mode.
> > > > > Mar 20 22:27:49 (none) kernel: Unable to handle kernel paging request
> > > > > at virtual address f8000000
> > > > > Mar 20 22:27:49 (none) kernel: printing eip:
> > > > > Mar 20 22:27:49 (none) kernel: c0156db1
> > > > > Mar 20 22:27:49 (none) kernel: *pde = 00000000
> > > > > Mar 20 22:27:49 (none) kernel: Oops: 0000 [#1]
> > > > > Mar 20 22:27:49 (none) kernel: SMP
> > > > > Mar 20 22:27:49 (none) kernel: Modules linked in:
> > > > > Mar 20 22:27:49 (none) kernel: CPU: 0
> > > > > Mar 20 22:27:50 (none) kernel: EIP: 0060:[<c0156db1>] Not tainted VLI
> > > > > Mar 20 22:27:50 (none) kernel: EFLAGS: 00010206 (2.6.16-rc6 #3)
> > > > > Mar 20 22:27:50 (none) kernel: EIP is at __bio_clone+0x29/0x9b
> > > > > Mar 20 22:27:50 (none) kernel: eax: 00000300 ebx: f68f3700 ecx:
> > > > > 00000002 edx: f7fffc80
> > > > > Mar 20 22:27:50 (none) kernel: esi: f8000000 edi: f7f3d378 ebp:
> > > > > f7c44b98 esp: f7c44b84
> > > > > Mar 20 22:27:50 (none) kernel: ds: 007b es: 007b ss: 0068
> > > > > Mar 20 22:27:50 (none) kernel: Process ldconfig (pid: 581,
> > > > > threadinfo=f7c44000 task=f7db9070)
> > > > > Mar 20 22:27:50 (none) kernel: Stack: <0>f7d3b458 f68f3700 f68f3700
> > > > > f7fffc80 f65b4640 f7c44ba8 c0156e4e f7d4c664
> > > > > Mar 20 22:27:50 (none) kernel: 00000010 f7c44bf4 c02c8346
> > > > > 00000080 00000000 00000e00 c0154b1b 00000000
> > > > > Mar 20 22:27:50 (none) kernel: 0000007f 00000080 f7fffc80
> > > > > f7d4a740 f7d44400 f7fffc80 f7d3b458 c01579c3
> > > > > Mar 20 22:27:50 (none) kernel: Call Trace:
> > > > > Mar 20 22:27:50 (none) kernel: [<c0104260>] show_stack_log_lvl+0xa8/0xb0
> > > > > Mar 20 22:27:50 (none) kernel: [<c0104397>] show_registers+0x109/0x171
> > > > > Mar 20 22:27:50 (none) kernel: [<c010456e>] die+0xfb/0x16f
> > > > > Mar 20 22:27:50 (none) kernel: [<c0114750>] do_page_fault+0x359/0x48b
> > > > > Mar 20 22:27:50 (none) kernel: [<c0103f0b>] error_code+0x4f/0x54
> > > > > Mar 20 22:27:50 (none) kernel: [<c0156e4e>] bio_clone+0x2b/0x31
> > > > > Mar 20 22:27:50 (none) kernel: [<c02c8346>] make_request+0x208/0x3d4
> > > > > Mar 20 22:27:50 (none) kernel: [<c02c8211>] make_request+0xd3/0x3d4
> > > > > Mar 20 22:27:50 (none) kernel: [<c01d3b68>] generic_make_request+0xf5/0x105
> > > > > Mar 20 22:27:50 (none) kernel: [<c01d3c19>] submit_bio+0xa1/0xa9
> > > > > Mar 20 22:27:50 (none) kernel: [<c0170453>] mpage_bio_submit+0x1c/0x21
> > > > > Mar 20 22:27:50 (none) kernel: [<c017085c>] do_mpage_readpage+0x30b/0x44d
> > > > > Mar 20 22:27:50 (none) kernel: [<c0170a2b>] mpage_readpages+0x8d/0xf1
> > > > > Mar 20 22:27:50 (none) kernel: [<c01a7ee7>] ext3_readpages+0x14/0x16
> > > > > Mar 20 22:27:50 (none) kernel: [<c013e92f>] read_pages+0x26/0xc6
> >
> > Jens points out that the "dm: bio split bvec fix" patch which went into
> > 2.6.16.1 might fix this. Can you try it please?
> >
> Sorry about the late response. I have been out of town for a week and
> didn't get to try it until last night. It STILL HAPPENS with 2.6.16.1
>
> Don
>
This is the oops output from 2.6.16.1
Apr 7 07:12:52 (none) kernel: Unable to handle kernel paging request at
virtual address f8000000
Apr 7 07:12:52 (none) kernel: printing eip:
Apr 7 07:12:52 (none) kernel: c0155cfd
Apr 7 07:12:52 (none) kernel: *pde = 00000000
Apr 7 07:12:52 (none) kernel: Oops: 0000 [#1]
Apr 7 07:12:52 (none) kernel: SMP
Apr 7 07:12:52 (none) kernel: Modules linked in:
Apr 7 07:12:52 (none) kernel: CPU: 1
Apr 7 07:12:52 (none) kernel: EIP: 0060:[<c0155cfd>] Not tainted VLI
Apr 7 07:12:52 (none) kernel: EFLAGS: 00010206 (2.6.16.1 #4)
Apr 7 07:12:52 (none) kernel: EIP is at __bio_clone+0x29/0x9b
Apr 7 07:12:52 (none) kernel: eax: 00000300 ebx: f5e37280 ecx: 00000082
edx: f7fffe80
Apr 7 07:12:52 (none) kernel: esi: f8000000 edi: f7f56a78 ebp: f7ce9b98
esp: f7ce9b84
Apr 7 07:12:52 (none) kernel: ds: 007b es: 007b ss: 0068
Apr 7 07:12:52 (none) kernel: Process ldconfig (pid: 533, threadinfo=f7ce9000
task=f7c3d540)
Apr 7 07:12:52 (none) kernel: Stack: <0>f7e29458 f5e37280 f5e37280 f7fffe80
f5e2b140 f7ce9ba8 c0155d9a f7d9ed98
Apr 7 07:12:52 (none) kernel: 00000000 f7ce9bf4 c02c7126 00000080
00000000 00000e00 c01d2a5c 00000000
Apr 7 07:12:52 (none) kernel: 0000007f 00000080 f7fffe80 f7e23bc0
f7e22000 f7fffe80 f7e29458 c015690f
Apr 7 07:12:52 (none) kernel: Call Trace:
Apr 7 07:12:52 (none) kernel: [<c0104260>] show_stack_log_lvl+0xa8/0xb0
Apr 7 07:12:52 (none) kernel: [<c0104397>] show_registers+0x109/0x171
Apr 7 07:12:52 (none) kernel: [<c010456e>] die+0xfb/0x16f
Apr 7 07:12:52 (none) kernel: [<c0114754>] do_page_fault+0x359/0x48b
Apr 7 07:12:52 (none) kernel: [<c0103f0b>] error_code+0x4f/0x54
Apr 7 07:12:52 (none) kernel: [<c0155d9a>] bio_clone+0x2b/0x31
Apr 7 07:12:52 (none) kernel: [<c02c7126>] make_request+0x208/0x3d4
Apr 7 07:12:52 (none) kernel: [<c02c6ff1>] make_request+0xd3/0x3d4
Apr 7 07:12:52 (none) kernel: [<c01d2a5c>] generic_make_request+0xf5/0x105
Apr 7 07:12:52 (none) kernel: [<c01d2b0d>] submit_bio+0xa1/0xa9
Apr 7 07:12:52 (none) kernel: [<c016f307>] mpage_bio_submit+0x1c/0x21
Apr 7 07:12:52 (none) kernel: [<c016f710>] do_mpage_readpage+0x30b/0x44d
Apr 7 07:12:52 (none) kernel: [<c016f8df>] mpage_readpages+0x8d/0xf1
Apr 7 07:12:52 (none) kernel: [<c01a6dc3>] ext3_readpages+0x14/0x16
Apr 7 07:12:52 (none) kernel: [<c013d867>] read_pages+0x26/0xc6
Apr 7 07:12:53 (none) kernel: [<c013da20>]
__do_page_cache_readahead+0x119/0x135
Apr 7 07:12:53 (none) kernel: [<c013dae4>] do_page_cache_readahead+0x3d/0x49
Apr 7 07:12:53 (none) kernel: [<c0138c5e>] filemap_nopage+0x149/0x2c9
Apr 7 07:12:53 (none) kernel: [<c0143528>] do_no_page+0x82/0x245
Apr 7 07:12:53 (none) kernel: [<c0143855>] __handle_mm_fault+0xf4/0x1ba
Apr 7 07:12:53 (none) kernel: [<c011456f>] do_page_fault+0x174/0x48b
Apr 7 07:12:53 (none) kernel: [<c0103f0b>] error_code+0x4f/0x54
Apr 7 07:12:53 (none) kernel: Code: 5d c3 55 89 e5 57 56 53 51 51 89 45 f0 8b
42
^ permalink raw reply
* Re: [PATCH] mm: limit lowmem_reserve
From: Nick Piggin @ 2006-04-07 12:40 UTC (permalink / raw)
To: Con Kolivas; +Cc: Andrew Morton, ck, linux list, linux-mm
In-Reply-To: <200604071902.16011.kernel@kolivas.org>
Con Kolivas wrote:
> On Friday 07 April 2006 16:25, Nick Piggin wrote:
>
>>Con Kolivas wrote:
>>
>>>It is possible with a low enough lowmem_reserve ratio to make
>>>zone_watermark_ok always fail if the lower_zone is small enough.
>>
>>I don't see how this would happen?
>
>
> 3GB lowmem and a reserve ratio of 180 is enough to do it.
>
How would zone_watermark_ok always fail though?
--
SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.com
^ permalink raw reply
* [BUG] 2.6.17-rc1: SCSI kobject_add problems
From: Bob Tracy @ 2006-04-07 18:31 UTC (permalink / raw)
To: linux-kernel
System is a DEC Alpha 433au with two SCSI disks. SCSI controller is a
QLA1040 supported by the qla1280 driver. Runs 2.6.16 fine. Tried
booting 2.6.17-rc1 and got
kobject_add failed for 0:0: with -EEXIST, don't try to register things with the same name in the same directory
and a fairly long trace output when the system attempted to add sdb.
Not surprisingly, sdb was inaccessible.
Normally (for 2.6.16 anyway), the following relationship exists:
sd 0:0:0:0 sda
sd 0:0:1:0 sdb
More information *might* be available if needed, but will have to be
transcribed by hand. My /usr partition is on sdb, so I don't get very
far with 2.6.17-rc1 on Alpha :-). The problem is probably specific to
the qla1280 or the Alpha, as I have a x86 Adaptec SCSI-based system
with multiple spindles that works fine with 2.6.17-rc1.
--
-----------------------------------------------------------------------
Bob Tracy WTO + WIPO = DMCA? http://www.anti-dmca.org
rct@frus.com
-----------------------------------------------------------------------
^ permalink raw reply
* Re: Cygwin can't handle huge packfiles?
From: Junio C Hamano @ 2006-04-07 18:31 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0604071002530.2215@localhost.localdomain>
Nicolas Pitre <nico@cam.org> writes:
> On Fri, 7 Apr 2006, Junio C Hamano wrote:
>
>> Linus Torvalds <torvalds@osdl.org> writes:
>>
>> > On Mon, 3 Apr 2006, Linus Torvalds wrote:
>> >>
>> >> That said, I think git _does_ have problems with large pack-files. We have
>> >> some 32-bit issues etc
>> >
>> > I should clarify that. git _itself_ shouldn't have any 32-bit issues, but
>> > the packfile data structure does. The index has 32-bit offsets into
>> > individual pack-files.
>> >
>> > That's not hugely fundamental,...
>>
>> Linus _does_ understand what he means, but let me clarify and
>> outline a possible future direction.
>
> For the record, the delta code also has 32-bit limitations of its own
> presently. It cannot encode a delta against a buffer which is larger
> than 4GB.
>
> I however made sure the byte 0 could be used as a prefix for future
> encoding extensions, like 64-bit file offsets for example.
True the delta data representation, not just the "delta code",
has that limitation, but I do not think you issue "insert 0-byte
literal data" command from the deltifier side right now, so we
should be OK.
Maybe we would want to check (cmd == 0) case to detect delta
extension that we do not handle right now?
^ permalink raw reply
* [RFC][PATCH 4/5] utsname namespaces: sysctl hack
From: Serge E. Hallyn @ 2006-04-07 18:36 UTC (permalink / raw)
To: linux-kernel, Kirill Korotaev, herbert, devel, sam,
Eric W. Biederman, xemul, devel, James Morris
In-Reply-To: <20060407095132.455784000@sergelap>
Sysctl uts patch. This clearly will need to be done another way, but
since sysctl itself needs to be container aware, 'the right thing' is
a separate patchset.
Signed-off-by: Serge E. Hallyn <serue@us.ibm.com>
---
kernel/sysctl.c | 38 ++++++++++++++++++++++++++++----------
1 files changed, 28 insertions(+), 10 deletions(-)
40f7e1320c82efb6e875fc3bf44408cdfd093f21
diff --git a/kernel/sysctl.c b/kernel/sysctl.c
index e82726f..c2b18ef 100644
--- a/kernel/sysctl.c
+++ b/kernel/sysctl.c
@@ -233,8 +233,8 @@ static ctl_table kern_table[] = {
{
.ctl_name = KERN_OSTYPE,
.procname = "ostype",
- .data = system_utsname.sysname,
- .maxlen = sizeof(system_utsname.sysname),
+ .data = init_uts_ns.name.sysname,
+ .maxlen = sizeof(init_uts_ns.name.sysname),
.mode = 0444,
.proc_handler = &proc_doutsstring,
.strategy = &sysctl_string,
@@ -242,8 +242,8 @@ static ctl_table kern_table[] = {
{
.ctl_name = KERN_OSRELEASE,
.procname = "osrelease",
- .data = system_utsname.release,
- .maxlen = sizeof(system_utsname.release),
+ .data = init_uts_ns.name.release,
+ .maxlen = sizeof(init_uts_ns.name.release),
.mode = 0444,
.proc_handler = &proc_doutsstring,
.strategy = &sysctl_string,
@@ -251,8 +251,8 @@ static ctl_table kern_table[] = {
{
.ctl_name = KERN_VERSION,
.procname = "version",
- .data = system_utsname.version,
- .maxlen = sizeof(system_utsname.version),
+ .data = init_uts_ns.name.version,
+ .maxlen = sizeof(init_uts_ns.name.version),
.mode = 0444,
.proc_handler = &proc_doutsstring,
.strategy = &sysctl_string,
@@ -260,8 +260,8 @@ static ctl_table kern_table[] = {
{
.ctl_name = KERN_NODENAME,
.procname = "hostname",
- .data = system_utsname.nodename,
- .maxlen = sizeof(system_utsname.nodename),
+ .data = init_uts_ns.name.nodename,
+ .maxlen = sizeof(init_uts_ns.name.nodename),
.mode = 0644,
.proc_handler = &proc_doutsstring,
.strategy = &sysctl_string,
@@ -269,8 +269,8 @@ static ctl_table kern_table[] = {
{
.ctl_name = KERN_DOMAINNAME,
.procname = "domainname",
- .data = system_utsname.domainname,
- .maxlen = sizeof(system_utsname.domainname),
+ .data = init_uts_ns.name.domainname,
+ .maxlen = sizeof(init_uts_ns.name.domainname),
.mode = 0644,
.proc_handler = &proc_doutsstring,
.strategy = &sysctl_string,
@@ -1619,6 +1619,24 @@ static int proc_doutsstring(ctl_table *t
{
int r;
+ switch (table->ctl_name) {
+ case KERN_OSTYPE:
+ table->data = utsname()->sysname;
+ break;
+ case KERN_OSRELEASE:
+ table->data = utsname()->release;
+ break;
+ case KERN_VERSION:
+ table->data = utsname()->version;
+ break;
+ case KERN_NODENAME:
+ table->data = utsname()->nodename;
+ break;
+ case KERN_DOMAINNAME:
+ table->data = utsname()->domainname;
+ break;
+ }
+
if (!write) {
down_read(&uts_sem);
r=proc_dostring(table,0,filp,buffer,lenp, ppos);
--
1.2.4
^ permalink raw reply related
* [RFC][PATCH 0/5] uts namespaces: Introduction
From: Serge E. Hallyn @ 2006-04-07 18:36 UTC (permalink / raw)
To: linux-kernel, Kirill Korotaev, herbert, devel, sam,
Eric W. Biederman, xemul, devel, James Morris
Introduce utsname namespaces. Instead of a single system_utsname
containing hostname domainname etc, a process can request it's
copy of the uts info to be cloned. The data will be copied from
it's original, but any further changes will not be seen by processes
which are not it's children, and vice versa.
This is useful, for instance, for vserver/openvz, which can now clone
a new uts namespace for each new virtual server.
This patchset is based on Kirill Korotaev's Mar 24 submission, taking
comments (in particular from James Morris and Eric Biederman) into
account.
Some performance results are attached. I was mainly curious whether
it would be worth putting the task_struct->uts_ns pointer inside
a #ifdef CONFIG_UTS_NS. The result show that leaving it in when
CONFIG_UTS_NS=n has negligable performance impact, so that is the
approach this patch takes.
-serge
Performance testing was done on a 2-cpu hyperthreaded
x86 box with 16G ram. The following tests were run:
dbench (20 times, four clients, on reiser fs non-isolated partition)
tbench (20 times, 5 connections)
kernbench (20 times)
reaim (20 times ranging from 1 to 15 users)
They were run on 2.6.17-rc1:
pristine
patched, but with !CONFIG_UTS_NS ("disabled")
patched with CONFIG_UTS_NS=y ("enabled")
All results are presented as means +/- 95% confidence interval.
Dbench results:
pristine: 387.080727 +/- 9.344585
patched disabled: 389.524364 +/- 9.574921
patched enabled: 370.155600 +/- 30.127808
Tbench results:
pristine: 388.940100 +/- 18.095104
patched disabled: 389.173700 +/- 23.658035
patched enabled: 394.333200 +/- 25.813393
Kernbench results:
pristine: 70.317500 +/- 0.210833
patched, disabled: 70.860000 +/- 0.179292
patched, enabled: 70.346500 +/- 0.184784
Reaim results:
pristine:
Nclients Mean 95% CI
1 106080.000000 11327.896029
3 236057.142000 18205.544810
5 247867.136000 23536.800062
7 265370.000000 21284.335743
9 262969.936000 18225.497529
11 278256.000000 6230.342816
13 284288.016000 8924.589388
15 286987.170000 7881.034658
patched, disabled:
Nclients Mean 95% CI
1 105400.000000 8739.978241
3 229500.000000 0.000000
5 252325.176667 16685.663423
7 265125.000000 6747.777319
9 271258.645000 11715.635212
11 280662.608333 7775.229351
13 277719.706667 8173.390359
15 278515.421667 10963.211450
patched, enabled:
Nclients Mean 95% CI
1 102000.000000 0.000000
3 224400.000000 14159.870036
5 242963.288000 40529.490781
7 255150.000000 8745.802081
9 270154.284000 8918.863136
11 283134.260000 12239.361252
13 288497.540000 11336.550964
15 280022.728000 8804.882369
^ permalink raw reply
* [RFC][PATCH 1/5] uts namespaces: Implement utsname namespaces
From: Serge E. Hallyn @ 2006-04-07 18:36 UTC (permalink / raw)
To: linux-kernel, Kirill Korotaev, herbert, devel, sam,
Eric W. Biederman, xemul, devel, James Morris
In-Reply-To: <20060407095132.455784000@sergelap>
This patch defines the uts namespace and some manipulators.
Adds the uts namespace to task_struct, and initializes a
system-wide init namespace which will continue to be used when
it makes sense.
Signed-off-by: Serge E. Hallyn <serue@us.ibm.com>
---
include/linux/init_task.h | 2 +
include/linux/sched.h | 2 +
include/linux/utsname.h | 40 +++++++++++++++++++++++++-
init/Kconfig | 8 +++++
init/version.c | 70 ++++++++++++++++++++++++++++++++++++++++-----
kernel/exit.c | 2 +
kernel/fork.c | 9 +++++-
7 files changed, 122 insertions(+), 11 deletions(-)
14c326d603d88d9ed40a1ddafbf23fc3da68a645
diff --git a/include/linux/init_task.h b/include/linux/init_task.h
index 41ecbb8..21b1751 100644
--- a/include/linux/init_task.h
+++ b/include/linux/init_task.h
@@ -3,6 +3,7 @@
#include <linux/file.h>
#include <linux/rcupdate.h>
+#include <linux/utsname.h>
#define INIT_FDTABLE \
{ \
@@ -123,6 +124,7 @@ extern struct group_info init_groups;
.journal_info = NULL, \
.cpu_timers = INIT_CPU_TIMERS(tsk.cpu_timers), \
.fs_excl = ATOMIC_INIT(0), \
+ .uts_ns = &init_uts_ns, \
}
diff --git a/include/linux/sched.h b/include/linux/sched.h
index 541f482..97c7990 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -684,6 +684,7 @@ static inline void prefetch_stack(struct
struct audit_context; /* See audit.c */
struct mempolicy;
+struct uts_namespace;
enum sleep_type {
SLEEP_NORMAL,
@@ -807,6 +808,7 @@ struct task_struct {
struct files_struct *files;
/* namespace */
struct namespace *namespace;
+ struct uts_namespace *uts_ns;
/* signal handlers */
struct signal_struct *signal;
struct sighand_struct *sighand;
diff --git a/include/linux/utsname.h b/include/linux/utsname.h
index 13e1da0..cc28ac5 100644
--- a/include/linux/utsname.h
+++ b/include/linux/utsname.h
@@ -1,5 +1,8 @@
#ifndef _LINUX_UTSNAME_H
#define _LINUX_UTSNAME_H
+#include <linux/sched.h>
+#include <linux/kref.h>
+#include <asm/atomic.h>
#define __OLD_UTS_LEN 8
@@ -30,7 +33,42 @@ struct new_utsname {
char domainname[65];
};
-extern struct new_utsname system_utsname;
+struct uts_namespace {
+ struct kref kref;
+ struct new_utsname name;
+};
+extern struct uts_namespace init_uts_ns;
+
+#ifdef CONFIG_UTS_NS
+
+extern struct uts_namespace *clone_uts_ns(struct uts_namespace *old_ns);
+extern struct uts_namespace *unshare_uts_ns(void);
+extern void free_uts_ns(struct kref *kref);
+
+static inline void get_uts_ns(struct uts_namespace *ns)
+{
+ kref_get(&ns->kref);
+}
+
+static inline void put_uts_ns(struct uts_namespace *ns)
+{
+ kref_put(&ns->kref, free_uts_ns);
+}
+
+#else
+static inline void get_uts_ns(struct uts_namespace *ns)
+{
+}
+static inline void put_uts_ns(struct uts_namespace *ns)
+{
+}
+#endif
+
+static inline struct new_utsname *utsname(void)
+{
+ return ¤t->uts_ns->name;
+}
+
extern struct rw_semaphore uts_sem;
#endif
diff --git a/init/Kconfig b/init/Kconfig
index 3b36a1d..8460e5a 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -166,6 +166,14 @@ config SYSCTL
building a kernel for install/rescue disks or your system is very
limited in memory.
+config UTS_NS
+ bool "UTS Namespaces"
+ default n
+ help
+ Support uts namespaces. This allows containers, i.e.
+ vservers, to use uts namespaces to provide different
+ uts info for different servers. If unsure, say N.
+
config AUDIT
bool "Auditing support"
depends on NET
diff --git a/init/version.c b/init/version.c
index 3ddc3ce..e128d72 100644
--- a/init/version.c
+++ b/init/version.c
@@ -11,22 +11,76 @@
#include <linux/uts.h>
#include <linux/utsname.h>
#include <linux/version.h>
+#include <linux/sched.h>
#define version(a) Version_ ## a
#define version_string(a) version(a)
int version_string(LINUX_VERSION_CODE);
-struct new_utsname system_utsname = {
- .sysname = UTS_SYSNAME,
- .nodename = UTS_NODENAME,
- .release = UTS_RELEASE,
- .version = UTS_VERSION,
- .machine = UTS_MACHINE,
- .domainname = UTS_DOMAINNAME,
+struct uts_namespace init_uts_ns = {
+ .kref = {
+ .refcount = ATOMIC_INIT(2),
+ },
+ .name = {
+ .sysname = UTS_SYSNAME,
+ .nodename = UTS_NODENAME,
+ .release = UTS_RELEASE,
+ .version = UTS_VERSION,
+ .machine = UTS_MACHINE,
+ .domainname = UTS_DOMAINNAME,
+ },
};
-EXPORT_SYMBOL(system_utsname);
+#ifdef CONFIG_UTS_NS
+/*
+ * Clone a new ns copying an original utsname, setting refcount to 1
+ * @old_ns: namespace to clone
+ * Return NULL on error (failure to kmalloc), new ns otherwise
+ */
+struct uts_namespace *clone_uts_ns(struct uts_namespace *old_ns)
+{
+ struct uts_namespace *ns;
+
+ ns = kmalloc(sizeof(struct uts_namespace), GFP_KERNEL);
+ if (ns) {
+ memcpy(&ns->name, &old_ns->name, sizeof(ns->name));
+ kref_init(&ns->kref);
+ }
+ return ns;
+}
+
+/*
+ * unshare the current process' utsname namespace. Changes
+ * to the utsname of this process won't be seen by parent, and
+ * vice versa
+ *
+ * Return NULL on error (failure to kmalloc), new ns otherwise
+ *
+ * TODO: decide where this should be locked (depends on how/where
+ * we decide to use this)
+ */
+struct uts_namespace *unshare_uts_ns(void)
+{
+ struct uts_namespace *old_ns = current->uts_ns;
+ struct uts_namespace *new_ns = clone_uts_ns(old_ns);
+ if (new_ns) {
+ current->uts_ns = new_ns;
+ put_uts_ns(old_ns);
+ }
+ return new_ns;
+}
+EXPORT_SYMBOL(unshare_uts_ns);
+
+void free_uts_ns(struct kref *kref)
+{
+ struct uts_namespace *ns;
+
+ ns = container_of(kref, struct uts_namespace, kref);
+ kfree(ns);
+}
+EXPORT_SYMBOL(free_uts_ns);
+#endif
const char linux_banner[] =
"Linux version " UTS_RELEASE " (" LINUX_COMPILE_BY "@"
diff --git a/kernel/exit.c b/kernel/exit.c
index 6c2eeb8..97c5405 100644
--- a/kernel/exit.c
+++ b/kernel/exit.c
@@ -34,6 +34,7 @@
#include <linux/mutex.h>
#include <linux/futex.h>
#include <linux/compat.h>
+#include <linux/utsname.h>
#include <asm/uaccess.h>
#include <asm/unistd.h>
@@ -173,6 +174,7 @@ repeat:
spin_unlock(&p->proc_lock);
proc_pid_flush(proc_dentry);
release_thread(p);
+ put_uts_ns(p->uts_ns);
call_rcu(&p->rcu, delayed_put_task_struct);
p = leader;
diff --git a/kernel/fork.c b/kernel/fork.c
index 3384eb8..62e4479 100644
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@ -44,6 +44,7 @@
#include <linux/rmap.h>
#include <linux/acct.h>
#include <linux/cn_proc.h>
+#include <linux/utsname.h>
#include <asm/pgtable.h>
#include <asm/pgalloc.h>
@@ -1119,6 +1120,8 @@ static task_t *copy_process(unsigned lon
/* Perform scheduler related setup. Assign this task to a CPU. */
sched_fork(p, clone_flags);
+ get_uts_ns(p->uts_ns);
+
/* Need tasklist lock for parent etc handling! */
write_lock_irq(&tasklist_lock);
@@ -1158,7 +1161,7 @@ static task_t *copy_process(unsigned lon
spin_unlock(¤t->sighand->siglock);
write_unlock_irq(&tasklist_lock);
retval = -ERESTARTNOINTR;
- goto bad_fork_cleanup_namespace;
+ goto bad_fork_cleanup_utsns;
}
if (clone_flags & CLONE_THREAD) {
@@ -1171,7 +1174,7 @@ static task_t *copy_process(unsigned lon
spin_unlock(¤t->sighand->siglock);
write_unlock_irq(&tasklist_lock);
retval = -EAGAIN;
- goto bad_fork_cleanup_namespace;
+ goto bad_fork_cleanup_utsns;
}
p->group_leader = current->group_leader;
@@ -1223,6 +1226,8 @@ static task_t *copy_process(unsigned lon
proc_fork_connector(p);
return p;
+bad_fork_cleanup_utsns:
+ put_uts_ns(p->uts_ns);
bad_fork_cleanup_namespace:
exit_namespace(p);
bad_fork_cleanup_keys:
--
1.2.4
^ permalink raw reply related
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.