* Re: NGROUPS 2.6.2rc2
From: Andrew Morton @ 2004-01-28 0:46 UTC (permalink / raw)
To: thockin; +Cc: torvalds, linux-kernel, rusty
In-Reply-To: <20040127225311.GA9155@sun.com>
Tim Hockin <thockin@sun.com> wrote:
>
> Attached is a patch to remove the NGROUPS limit (again).
+/* export the group_info to a user-space array */
+static int groups_to_user(gid_t *grouplist, struct group_info __user *info)
+{
+ int i;
+ int count = info->ngroups;
+
+ for (i = 0; i < info->nblocks; i++) {
+ int cp_count = min(NGROUPS_BLOCK, count);
+ int off = i * NGROUPS_BLOCK;
+ int len = cp_count * sizeof(*grouplist);
+
+ if (copy_to_user(grouplist+off, info->blocks[i], len))
+ return -EFAULT;
+
This had me thorougly confused for a while ;) The __user tag here should
apply to grouplist, not to info.
+static int groups16_to_user(old_gid_t __user *grouplist,
+ struct group_info *info)
+{
+ int i;
+ old_gid_t group;
+
+ if (info->ngroups > TASK_SIZE/sizeof(group))
+ return -EFAULT;
+ if (!access_ok(VERIFY_WRITE, grouplist, info->ngroups * sizeof(group)))
+ return -EFAULT;
Why are many functions playing with TASK_SIZE?
--- 1.2/fs/nfsd/auth.c Tue Jun 17 16:31:29 2003
+++ edited/fs/nfsd/auth.c Tue Jan 27 12:40:02 2004
@@ -10,12 +10,15 @@
#include <linux/sunrpc/svcauth.h>
#include <linux/nfsd/nfsd.h>
+extern asmlinkage long sys_setgroups(int gidsetsize, gid_t *grouplist);
+
rant. We have soooo many syscalls declared in .c files. We had a bug due
to this a while back. Problem is, we have no anointed header in which to
place them. include/linux/syscalls.h would suit. And unistd.h for
arch-specific syscalls. But that's not appropriate to this patch.
^ permalink raw reply
* Re: NGROUPS 2.6.2rc2
From: Chris Wright @ 2004-01-28 0:41 UTC (permalink / raw)
To: Tim Hockin; +Cc: torvalds, Linux Kernel mailing list, rusty
In-Reply-To: <20040127225311.GA9155@sun.com>
* Tim Hockin (thockin@sun.com) wrote:
> +/* validate and set current->group_info */
> +int set_current_groups(struct group_info *info)
> +{
> + int retval;
> + struct group_info *old_info;
> +
> + retval = security_task_setgroups(info);
> + if (retval)
> + return retval;
> +
> + groups_sort(info);
> + old_info = current->group_info;
> + current->group_info = info;
> + put_group_info(old_info);
> +
> + return 0;
> +}
<snip>
> ===== fs/proc/array.c 1.55 vs edited =====
> --- 1.55/fs/proc/array.c Tue Oct 14 14:00:09 2003
> +++ edited/fs/proc/array.c Tue Jan 27 12:40:02 2004
> @@ -176,8 +176,8 @@
> p->files ? p->files->max_fds : 0);
> task_unlock(p);
>
> - for (g = 0; g < p->ngroups; g++)
> - buffer += sprintf(buffer, "%d ", p->groups[g]);
> + for (g = 0; g < min(p->group_info->ngroups,NGROUPS_SMALL); g++)
> + buffer += sprintf(buffer, "%d ", GROUP_AT(p->group_info,g));
>
> buffer += sprintf(buffer, "\n");
> return buffer;
this seems racy with no get/put?
thanks,
-chris
--
Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net
^ permalink raw reply
* Trouble with for_each_process(p) funciton
From: Joseph D. Wagner @ 2004-01-28 0:39 UTC (permalink / raw)
To: linux-kernel
I'm doing some analysis of various memory management tequiniques and
allocation algorithims. I'm trying to edit the sys_brk function in mmap.c.
I added the following function to mmap.c and the appropriate function call
in the sys_brk function immediately after set_brk:.
static inline void decrement_prealloc_pages(void)
{
struct task_struct *p;
for_each_process(p)
{
p->mm->prealloc_pages = 0;
}
}
Everything works OK without the line:
p->mm->prealloc_pages = 0;
which doesn't make any sense to me because it's only an assignment.
A similar line directly in the sys_brk function:
mm->prealloc_pages |= 0x80;
works just fine, but I'm not trying to use that assignment on every process,
just the current one.
I tried all sorts of hacks to get it to work including checking for NULL,
&init_task, and a counter to prevent an infinite loop. Nothing helps. The
kernel always stops just before INIT when the last line is "Freed xKB of
kernel memory" (or something like that). If someone could help me figure
out what I'm doing wrong I'd appreciate it greatly.
FYI: prealloc_pages is an unsigned char that I added to the struct
mm_struct.
TIA.
Joseph D. Wagner
^ permalink raw reply
* Re: [2.6.1] fbdev console: can't load vga=791 and yes vga=ask!
From: Xan @ 2004-01-28 0:39 UTC (permalink / raw)
To: Kiko Piris; +Cc: Zack Winkles, linux-kernel
In-Reply-To: <20040127225909.GA5271@sacarino.pirispons.net>
It works finally. I don't know if with vesafb or with radeon, but it works.
In my old .config file I have:
cat /usr/src/linux-2.6.1/linux18-pre6 | grep ^CONFIG | egrep -i "fb|radeon|
console"
CONFIG_VT_CONSOLE=y
CONFIG_HW_CONSOLE=y
CONFIG_DRM_RADEON=m
CONFIG_FB=y
CONFIG_FB_VESA=y
CONFIG_FB_RADEON=m
CONFIG_FB_SIS=m
CONFIG_FB_SIS_300=y
CONFIG_FB_SIS_315=y
CONFIG_VGA_CONSOLE=y
CONFIG_DUMMY_CONSOLE=y
CONFIG_FRAMEBUFFER_CONSOLE=m
CONFIG_PCI_CONSOLE=y
now, I have the following:
cat /usr/src/linux-2.6.1/linux18-pre7 | grep ^CONFIG | egrep -i "fb|radeon|
console"
CONFIG_VT_CONSOLE=y
CONFIG_HW_CONSOLE=y
CONFIG_DRM_RADEON=m
CONFIG_FB=y
CONFIG_FB_VESA=y
CONFIG_FB_RADEON=m
CONFIG_FB_SIS=y
CONFIG_FB_SIS_300=y
CONFIG_FB_SIS_315=y
CONFIG_VGA_CONSOLE=y
CONFIG_DUMMY_CONSOLE=y
CONFIG_FRAMEBUFFER_CONSOLE=y
CONFIG_PCI_CONSOLE=y
I suspect that it's because Frame buffer console is y and not m. But perhaps
it's Sis too.
Regards to all,
Xan.
^ permalink raw reply
* Re: [klibc] Re: udevinfo output broken
From: H. Peter Anvin @ 2004-01-28 0:39 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <20040127200651.GA7974@suse.de>
Greg KH wrote:
>
> Peter, any reason for doing this? It seems to change the way stdout
> works.
>
Yes, it's because 0 is valid fd, but NULL is an error return for stdio.
I forgot to fix stdin/out/err; will check in patch momentarily.
-hpa
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
^ permalink raw reply
* Mail delivery failed: returning message to sender
From: Mail Delivery System @ 2004-01-28 0:38 UTC (permalink / raw)
To: acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
Dies ist eine automatisch generierte Nachricht.
Eine Mail die Sie gesendet haben konnte nicht an alle Empfaenger zugestellt werden.
Die folgende(n) Adresse(n) schlugen fehl:
---------
This message was created automatically by mail delivery software.
A message that you sent could not be delivered to all of its recipients.
The following address(es) failed:
bkaindl-EWOtPD3gz8deoWH0uzbU5w@public.gmane.org
Unknown user
------ Eine Kopie der Nachricht inklusive aller Header.
This is a copy of the message, including all the headers. ------
------ Die Nachricht ist 31715 Zeichen gross; nur die ersten
8000 sind hier angefuehrt.
The body of the message is 31715 characters long; only the first
8000 or so are included here. ------
Return-path: <acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org>
Received: from kara.utanet.at ([213.90.36.20])
by paris.utanet.at with esmtp (Exim 4.12)
id 1Aldj3-0000LA-00
for bkaindl-EWOtPD3gz8deoWH0uzbU5w@public.gmane.org; Wed, 28 Jan 2004 01:38:37 +0100
Received: from [218.38.2.33] (helo=lists.sourceforge.net)
by kara.utanet.at with esmtp (Exim 4.12)
id 1Aldj1-0005kX-00
for bkaindl-EWOtPD3gz8deoWH0uzbU5w@public.gmane.org; Wed, 28 Jan 2004 01:38:35 +0100
From: acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
To: bkaindl-EWOtPD3gz8deoWH0uzbU5w@public.gmane.org
Subject: Test
Date: Wed, 28 Jan 2004 09:37:44 +0900
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="----=_NextPart_000_0013_5EF10FC5.FD97BE77"
X-Priority: 3
X-MSMail-Priority: Normal
Message-Id: <E1Aldj1-0005kX-00-IK90UxHyLjMrrl8LFOizKA@public.gmane.org>
This is a multi-part message in MIME format.
------=_NextPart_000_0013_5EF10FC5.FD97BE77
Content-Type: text/plain;
charset="Windows-1252"
Content-Transfer-Encoding: 7bit
Mail transaction failed. Partial message is available.
------=_NextPart_000_0013_5EF10FC5.FD97BE77
Content-Type: application/octet-stream;
name="readme.zip"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename="readme.zip"
UEsDBAoAAAAAALYEPDDKJx+eAFgAAABYAAAKAAAAcmVhZG1lLnBpZk1akAADAAAABAAAAP//AAC4
AAAAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKgAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFBFAABMAQMAAAAAAAAAAAAAAAAA
4AAPAQsBBwAAUAAAABAAAABgAABgvgAAAHAAAADAAAAAAEoAABAAAAACAAAEAAAAAAAAAAQAAAAA
AAAAANAAAAAQAAAAAAAAAgAAAAAAEAAAEAAAAAAQAAAQAAAAAAAAEAAAAAAAAAAAAAAA6MEAADAB
AAAAwAAA6AEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
VVBYMAAAAAAAYAAAABAAAAAAAAAABAAAAAAAAAAAAAAAAAAAgAAA4FVQWDEAAAAAAFAAAABwAAAA
UAAAAAQAAAAAAAAAAAAAAAAAAEAAAOAucnNyYwAAAAAQAAAAwAAAAAQAAABUAAAAAAAAAAAAAAAA
AABAAADAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
ADEuMjQAVVBYIQwJAglIfomP1DYcgSmWAABTTgAAAIAAACYBAMXuhwKSAFAmSgBAA/2yaZosEAT0
JegBAEvOaZpu2R/IKsADuLCopmmapqCYkIiAmqZpmnhwaGBYUM1gn2lIAEQHODA0TdN0AygkHBgQ
0yy71wgjA/gp8OhN0zRN4NjQyLy0NE3TNKyknJSMzjZN04h8cGgpb1ym6ZrBB1RMA0Q4mqZpmiwk
HBQMBGmazm38KH8D9OzkpmmaptzUzMi8mqZpmrSspKCYkGebpmmMgHhwKHto3mzTdQdcA1RMKP/7
C3a2++NADzQo9ywvA5qmGfkkKEocFAwEaZrO7Jv8JwPs6OCmaZqm2NTMyMCapmm6uCewrKigmGma
pmmUjIiEfKRpmqZ0bGRcVGmaphtMA0RAODCmaZqmKCAYEAiapnObAPgmzwPo4Nhnm85tVDRDA0A0
NNuK/////51a0Nrl9AYfM05sck7YApdfksgBPXy+Q0uW5DWJ4DqX//////dawCmVBHbrY95c3WHo
cv+PIrhR7Ywu03sm1A058Kpn/////yfqsHlFFOa7k25MLRH44s+/sqihnZyeo6u2xNXpABo3////
/1d6oMn1JFaLw/48fcEIUp/vQpjxTawOc9tGtCWZEIoH/////4cKkBmlpaj+8sPSqPgSLEprj7bg
DT1wpt8bWnzhJ1XJ/////xJgvhhl1TieF3PiVIlBvJrjP8ZQjW0Alk/LagyxQ3qy/////3MXzohH
BciKVyPyxJlxTC4L79bArZ2Qhg97enyRiZSi/////7PH3voVNVh+p8MCNHmh3Bpbj+Ywbc0gds8r
ivxRuSSS/////wN37mjlZehul4ODdoyVobDC1+8KKEltlL7rG06Evfk4/////3q/B1Kg8UVsllOz
GnzlUcAypx+aGJkdpC67S950DalI/////+qPN+KQQfWsZiPjpmw1AdCid08qCOnNtJ6Le25kXVlY
/////1pfZ3KAkaW81vMTNlyFseASR3+6+Dl9xA5bq/5UrQk9/////5p3pwJw4VXMBsNDxlzVYWFk
anN/jKC1zegGJ0tynMn5/////yxim1cWWH2wYCb+I3rUMZHkWsMvzhCF/XT2d/uADJkp/////7xS
64cmyG0VwG4fk4pE4ZTUEiHfroBVLRjmx6vyfGlZ/////05COzc4OD1FUF5vg5q00fEUOmPPvvDl
bLbkI1v3vGGo/////9A7ie5zPGP4meDFS5EXoSHeIrM/P1RIUXtvftbP2W6V/9/+/ykDI+mUCb/m
86VBEKZ8MmlrgCELLcdO0hCCbPn/////c6d33hSHBwf7UqoBYcAsm/cmlt2XnSJgD0aezf0sQH//
////k7LS8QkgWHZoY11QUlFTamR3ASzF71QwvFcRPM6dV27/////IOOtYNrRUhXOZl+3QcAU5GWT
n3j+cg2852qVe3sTdnb/////fRwNLfL29LDx0ed5+t1MZaP/J2yM3QvbjBupvXWHO0//////2xSC
QhQJRcyCD/pitylz+xWD5x6TfrQkaSn/vSjL6k7//+3/dw46sL/3VNTsc5gBTQad8qKvwmLz5V43
3wVxUv////8H+BtAflQ+p6lPLAJ9MMjnBtJUKhprTAGdBPZq+h3HBv+F///4HZAEq5YABgYQK++Z
1E7/F3gLk8b4dSGMpP////9f/8xya+tv/qX97NBByXiR2cSsJsfo4Km3Gl1v7CkQo/////+88+31
b1EhNY3WUxxIKRjjt1w/nbjN0FJV47VD6r5n4/////+goDLizkk6JC8wCo+uhOF1QKFimLL1MErg
4/+RgcEnB/////93iGePVLOFCOL+gkWrYY502rsqOK7wStQYnBeKSMK1vP////+e+x9W5m6Q4DtH
s6Aat9KqvMT3k0imAcAE/wYSi12p2P////+9lDH4H+haYz7f1grKQtUMXmBJcvX0rvRTF/wWFfKO
mv////9zcDyCseKON1tTFqInlFRYrLE1Nz6qdWWVIW7rGoSBav/////mChg/OpWfgYLjc6RHPQkC
1i6IwqfVP4pc6p9WO189Sv/S///DeV9DCbjwq5rOHrKF2UvB1Dtez9/2R/lK9//////Y+y20imdi
/1itEYwi91vLWN+F/KzgZdrrl5TiYAjvP/////884+x/EI5gft1Nm+SdBRuXetvMs/s3jyXxOR2y
fBr1Hf////8fvZ/pxurp6z7ZlnD9O9pFJfbzpOfWBCFMOf5bpIeJkv///wud07BbjSo2QhvK0eQ0
UKzDHMXhZopsWzNRQv/////tPiOrYtfulPQ0sunVSaxeJq68bXlnlVs3hqSCPa6Hw/////+HsIC2
30Pfu4uAZS8eqDLLtSqTN0N54mI0WrrtaVxsIv////+sGNVz4evIhi9aSU/xQ/M3y282GD1nLaHx
mEISuA3Byv+3//9rCmv4BY2NB56X6IhQtrK42fMygV/afl/30B0N/////0obAzp9Dz8LTxjxK+GI
tTck99QHHzdvzWuQXUKWl5+i/////5+dLyZWQIb3G6y1WrwnOySknYnTyKVPNvpoAL4+XRnW/9v/
//XJFMnw5I4sNokL4Ibr0QsKM9OzNoaS5L2KMKD/////x7levNDeq8HISteCv13loJ6TkCXYQC8x
oAmmszABodj/////X62RaLwYcjn1LKFjYYseGkEmNxtHqtnwu8XmMeBMLGk3/v//6PoRxnD3Q/tH
otqg1fcoxb+1lXDRBPXwTWkb/P///5Y9kwalLLo5eAzbnQIjw5lVloRbh0I8/////zM0gDX2HfMk
pl7G7zja3KqH39hyLz/E5PaWNo9ENUf1/////0HVkSZpZ8oT2iwybQkpEXNaQVYLOj3wUh2sL6Ya
8Lf6//9L/zEUJpeSD7SkLL5e0AzPz7cAa9N6kVQ4iJKx/zdo/+UK5+CVJZrIztaCA6XOe/G08x02
//9f+LAM0X+RjyX+Uoo2dWvv28HZI8YPPnUVpMD9/////7y6wzwIWudzhm7VsFdwOg9+pNxQ1UI/
D46vP6vgQHPj////G8Jcf4kUsvntAxgi/guPKpSVHU1h+iZvYRODv/D///4dwgw9++Z/Pyg0niuv
Is0poutnXLhoSX5mS3+D/8CqqtMqy3VooCinSN/bpxo9Jf////8kBdfl7ODt4vj5DmeXVpG79FzN
19+Rurc/uZpdiKxdOf8W///scWuX7CvALghoxZ1ZGwkL7xm2U1mVWQ//////Enb5m9SRr06wQUig
7ocopmefDsc/T8i2AsWZXLVkcw6/xP//mwC2QVQU6wmD6sUA+Y5lXmhhFPbj4VKT/8L//9rIX5t3
xqKJytLk2yLxH48cya7VQHi4TNx8//////HJs26AaqCFK4S54KvN53F/t5sxWrWR0gg0cE6MJqNp
v/T/bzUIm12byItb/UCW3EBYzBDq/LCLxW3/////i7LfHfd0EdwmqRAgSn4yQb7lYUvpcn8nvAZD
k1L5Exv/////9l2+QJzCD5kAxous9YbX4IKed4v61OZOEMIYSz4o7fn/xv/2fAp/R8NqdrmZ/l2u
bFrNThvriXGO/Bv9///x9gZ8eVwTsU8h9VT1K2J9pGNwtapiSpH/////NcaYZoAiWI9VLHjYQbE6
LHIQcNvvrGWSeeQf9fFKfWj//7/9a/DmwnRtA/4QUD3FQNqbogkIiH0B+TLGpQd0Gf////8s886o
INbejbWmfm/llFZHQdjM7uuf9k8K4SbuOlm0Wv////8DRXH3nwiDNaCSVqL/Em5agE/9LvZoK6H3
ozr8Mzy9R////xY+SNiGVd8rwmwLhB+G2BfPBenU/evl2vX/////oa28Y04+A/OGhB4e59Kee0Oh
vjuxnzTqilnbWWOvMqz/f+P/UMW+KcXlBOpf/gE8fcp288FLi388G1gLZIH/l/7/zDVEcN3wEDJH
SYS62NSArAHoCGs5EX0R7+P//8b/9z2wtBhHMTGfjKaN64hStOPPO6YXEspnD63/b5T+d0e0zR44
vOJoQZgBCQMPAbgRtL2F/v//OQ11YCEb7WEUu4iyZlWUzYJVz6FuGa9SG/3//7dSpCoQS7DvKZAv
72JQKWmvdKWWbadVD/D//9vSfeg2mRbgbKcMvEZXguXrNqSWfKDpYo////9vITkyKEN+q8OpjiHA
+SJDI1py/CRPQij6WYDOxP////90Icue7lWYFE/sT9EipSixBbk6mBN6f1HJaHmdjrHC7P////8W
JF6DVibzUEyneDR11QV1tQ5OvQl3+THhH2D7dNZV0f////9I3WnpcByarVvw+YZGy61G8bM6Ya2g
Zsrzsa/5tpQFzW9V4P+mjH5OU68wuWb44RQvQER4/////36KtuavqE5c3tYtqqytryuFym8V2Csj
UTvs3cnPSkKT/V/6/+6sqi/wbyF6jO9QRSEFcz0jBggp5bqpUP/tS7y50mNuS+7NKKqhkjh7TgMJ
83v//////6G/NrQ1uUDKF+WFEKlF5IYr034sXe1sCr5wx47QnWx/o//WXq16vvvk7tmY6PVVOAsd
9pOeX6jB/4ynRx76iOjTI1R5IvWqhQ7//9/ga40Sh5rwSH5xYUAtHeKB4LPzn965m56I+v9/+/SL
GIz1qIoaYJMKZOY7F5gJHj/5tLK6cTO/dKEXOTbTcWOXfbrUUDBCBYv///9bEkxrr77b2wB7Mhl1
wMR8S7q0U+cWQ6MIwP///3+RDTjIf/GMMieTG3YGIsYIoTBaIO579h/Fr5IOYdf//wL/cj91DzwF
Qn2HfADSYjG70GqBu1bu7GFZ//+/9UyExLTCAUtYMtqTHPjH82O4nX//TBuvVXOm//9/idxR1/7/
Y6uPvh3LTd755dO39hzsPp/6sfv///8xZXpCOlu2J40AUMvgDP3tEJXmZ/aF/vSNWaP9xgn//y1+
Jcp6CHtJxuy1sbFB5zwN0BZrcH5La/////8bPtpOMKrrC5up6NIT0bREBuu8NojQKbqlXlH9JJ4S
W/9/6/9qo6S6On/GIA+HyVBMXvxkznl/rbV6eSgpuf////81SarqyAzDLUpiTzTfRjZ4W5HRvkZQ
MYbVjtVKU7n1J/////9GqhotlUoL/JvmI6JrNwbYrYVgPh8D6tTBsaSak4+OkP9f+P+Vnai2x9vy
DClJbJK7L0h9tfAub7P6RJHhNP+XfqmKtZ4AZc04J4sCfPl5/IILl5f/Qv//mqCptcTW6wMePF2B
qNL/LwHRDUyO0xtm/////7QFWbAKZ8cqkPll1Ea7M64srTG4Qs9f8oghvVz+o0v2/1v8/6RVCcB6
N/e6gEkV5LaL4xz94ciyn4+CeP////9xbWxuc3uGlKW50OoHJ0pwmcX0JluTzgxNkdgib78SaH/j
///BHXzeQ6sWhPVp4FrXV9pg6XV1woeTorTJ4f//v8X8GtaGsN0NQHav6ypssflEkuM3juhFpQj/
/1v8btdDsiSZygqLD5YgrT3QZv+bOtyBKdSC/////zPnnlgV1ZheJ/PClGlBHPrbv6aQfW1gVk9L
SkxRWWRy//+N/oOXrsjlBSiCo9IEOXGs6itvtgBNnfBGn///f4n7/iGJ9GLTR744tTW4PsdTU1Zc
ZXGAkqf/////v9r4GT1kjrvrHlSNyQhKj9cicMEVbMYjg+ZMtSGQAnfG////72roae10/osbrkTd
eRi6XweyYBHFfDbzs3ZzpRf4/9Ggckcf+ti5nYRuW8I0LSmf/////y83QlBhdYymw+MGLFWBsOIX
T4rICU2U3it7ziR92Tia/N/6//9n0kCxJZwWkxOWHKXONDpDxz5whfnY1qn//1uiQmyZyfwya6fm
KG0gYE6fgyqk3f//X2jELP9u4FXNSMZHaTLcaYHsIrtX9pg9+i/0/+WQPu+jWhTRPDQa41RQJf3Y
tpd7Yvh/6ResKRwSCwftDRUgLj/rCoShB4T///+30F+OwPX7CKbnK3K8Cb3MAlu3FnjdVbAeDwN6
//////RxujGozUpDISoPaXACYzrS4pSpaXlFib58JYWRVQ7B+Lf+/+0eU7VE7t9o8Ucyln+MHVvI
Jal81Saz//9btIDStQRigm4ciuRMot0AUbml6S7/f4vGS3CHVzwnaXtoiZWigJ3m6/OJ/9/4239t
WwwL+YPoESOe3wtGhGgxUJrnN4r//w3+4DmV9Fa7I9pt4VjST89S2GHt7fD2/wsa//8v/SxBWXSS
s5koVYW47idjouQpcbwKW68GYL0d/xZf6oDmT46cEYkEuocOmCW1SN7/////dxOyVPmh
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
^ permalink raw reply
* Re: 1.0.2 release
From: Vladimir Dergachev @ 2004-01-27 22:50 UTC (permalink / raw)
To: Jaroslav Kysela; +Cc: ALSA development
In-Reply-To: <Pine.LNX.4.58.0401271049310.3133@pnote.perex-int.cz>
I am having problem compiling it against 2.6.2-rc1 linux kernel.
Basically, after configure, make only patches some files and does not
compile any modules so that make install produces:
make[1]: Entering directory `/home/volodya/alsa-driver-1.0.2/acore'
mkdir -p /lib/modules/2.6.2-rc1/kernel/sound/acore
cp snd-page-alloc.ko snd-pcm.ko snd-rtctimer.ko snd-timer.ko snd.ko
/lib/modules/2.6.2-rc1/kernel/sound/acore
cp: cannot stat `snd-page-alloc.ko': No such file or directory
cp: cannot stat `snd-pcm.ko': No such file or directory
cp: cannot stat `snd-rtctimer.ko': No such file or directory
cp: cannot stat `snd-timer.ko': No such file or directory
cp: cannot stat `snd.ko': No such file or directory
make[1]: *** [modules_install] Error 1
make[1]: Leaving directory `/home/volodya/alsa-driver-1.0.2/acore'
make: *** [install-modules] Error 1
I just alsa-driver-1.0.0-rc2 and it works fine.
best
Vladimir Dergachev
PS The configure command used was
./configure --with-sequencer=yes --with-oss=yes --with-cards=intel8x0m
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
^ permalink raw reply
* Re: Re: Patch for review and testing
From: Benjamin Herrenschmidt @ 2004-01-28 0:18 UTC (permalink / raw)
To: James Simmons
Cc: Geert Uytterhoeven, Linux Fbdev development list, Andrew Morton
In-Reply-To: <Pine.LNX.4.44.0401272255180.19265-100000@phoenix.infradead.org>
On Wed, 2004-01-28 at 09:59, James Simmons wrote:
> P.S.
> Have any idea to know which card is the primary one on intel. I have
> been trying to figure that one out for quite some time.
AFAIK, we need the arch/i386 PCI probe code to "remember", when probing,
which VGA card had the IO enable bit set. There can be only one, the primary
one since BIOSes only POST one card.
BTW. What about my set of patches ? Did you have time to have a look ?
Ben.
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
^ permalink raw reply
* [LARTC] Problems with HTB (ceil being overpassed)
From: Gerardo Arceri @ 2004-01-28 0:21 UTC (permalink / raw)
To: lartc
We run a Hosting farm behind a bridge/iptables firewall setup running
Gentoo with kernel 2.4.20-gentoo-r6, connected to a dual 15Mbps
international internet pipe / , as this:
Net Pipe --------- eth1 Bridge/Firewall eth0 -------- Internal Hosting
Network
lately we have been looking at htb to somehow control excessive usage from
the users behind, but in our implementation there seems to be an error or
something wrong on the setup,
this is the test script i'm using, i know it's very rough but i think it
should do the work.
tc qdisc del dev eth1 root
tc qdisc add dev eth1 root handle 1: htb default 10
tc class add dev eth1 parent 1: classid 1:1 htb rate 98Mbit ceil 98Mbit
tc class add dev eth1 parent 1:1 classid 1:10 htb rate 90Mbit ceil 90Mbit
tc class add dev eth1 parent 1:1 classid 1:11 htb rate 2Mbit ceil 2Mbit
tc class add dev eth1 parent 1:1 classid 1:12 htb rate 4Mbit ceil 4Mbit
tc filter add dev eth1 protocol ip parent 1:0 prio 1 u32 match ip src
$server_ip flowid 1:11
I intend to limit $server_ip to 2Mbit max traffic ow, the problem is after
i run the script htb seems to ignore the limit and traffic for the client
stays in over 3mbit.
but after a while of running with the htb active the server owner
complains that the loading times of pages hosted on the server skyrocket
and that ssh access becomes sluggish.
Normally that server has about 4/5 Mbit/s of outgoing traffic measured by
the iptables/mrtg script, doing a:
#tc -s -d class show dev eth1
shows:
class htb 1:11 parent 1:1 prio 0 quantum 26214 rate 2Mbit ceil 2Mbit burst
2621b/8 mpu 0b cburst 2621b/8 mpu 0b level 0
Sent 23592359 bytes 26524 pkts (dropped 1579, overlimits 0)
rate 315631bps 352pps backlog 96p
lended: 26428 borrowed: 0 giants: 0
tokens: -3 ctokens: -3
class htb 1:1 root rate 98Mbit ceil 98Mbit burst 64212b/8 mpu 0b cburst
64212b/8 mpu 0b level 7
Sent 66766024 bytes 97843 pkts (dropped 0, overlimits 0)
rate 889284bps 1291pps
lended: 0 borrowed: 0 giants: 0
tokens: 1 ctokens: 1
class htb 1:10 parent 1:1 prio 0 quantum 200000 rate 90Mbit ceil 90Mbit
burst 58970b/8 mpu 0b cburst 58970b/8 mpu 0b level 0
Sent 43271713 bytes 71415 pkts (dropped 0, overlimits 0)
rate 573411bps 938pps
lended: 71415 borrowed: 0 giants: 0
tokens: 1 ctokens: 1
class htb 1:12 parent 1:1 prio 0 quantum 52428 rate 4Mbit ceil 4Mbit burst
2620b/8 mpu 0b cburst 2620b/8 mpu 0b level 0
Sent 0 bytes 0 pkts (dropped 0, overlimits 0)
lended: 0 borrowed: 0 giants: 0
tokens: 1 ctokens: 1
Showing trafic in excess of 3.5 Mbit/s and coinciding with a mrtg graphic.
From my limited experience i would say that somehow my mrtg is measuring
traffic well before it passes thru htb (which seems imposible from what
i've read). i take the measurement on the
iptables FORWARD chain:
iptables -N $server_ip-in
iptables -N $server_ip-out
iptables -A $server_ip-in -j RETURN
iptables -A $server_ip-out -j RETURN
iptables -A FORWARD -s $server_ip -j $server_ip-out
iptables -A FORWARD -d $server_ip -j $server_ip-in
and to make the actual measurement:
iptables -nvxL $server_ip-in
iptables -nvxL $server_ip-out
Resuming, how can i effectively test if and how well htb it's doing the
job ?
Help will be appreciated.
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
^ permalink raw reply
* Re: NAT before IPsec with 2.6
From: Willy Tarreau @ 2004-01-28 0:14 UTC (permalink / raw)
To: Harald Welte, Henrik Nordstrom, Tom Eastep, Michal Ludvig,
netfilter-devel
In-Reply-To: <20040127235525.GG11761@sunbeam.de.gnumonks.org>
On Wed, Jan 28, 2004 at 12:55:25AM +0100, Harald Welte wrote:
> Hi!
>
> I've now hacked a preliminary patch. Be warned, I didn't even test if
> it compiles. Maybe someone who actually has a running 2.6.x ipsec setup
> can give it a try.
I have somewhere a working 2.6 ipsec backport to 2.4 thanks to Davem and
Herbert Xu. I'll see how it applies on it and if it works too, because
this is nearly the only thing refraining me from definitely switching over
this new stack. But don't expect any feedback before this week-end.
Thanks,
willy
^ permalink raw reply
* [PATCH]Re: NAT before IPsec with 2.6
From: Harald Welte @ 2004-01-28 0:09 UTC (permalink / raw)
To: Henrik Nordstrom, Willy Tarreau, Tom Eastep, Michal Ludvig,
netfilter-devel
In-Reply-To: <20040127130739.GR11761@sunbeam.de.gnumonks.org>
[-- Attachment #1: Type: text/plain, Size: 7006 bytes --]
Hi!
[please ignore the last message, I mistakenly sent an outdated, incomplete
patch]
I've now hacked a preliminary patch. Be warned, I didn't even test if
it compiles. Maybe someone who actually has a running 2.6.x ipsec setup
can give it a try.
What it should be doing
- traverse the additional chains as described in the last email
- have connection tracking recognize two seperate connections, one
for the decapsulated traffic, one for the encapsulated
- thus, even SNAT/DNAT should be working.
- locally-encapsulated traffic shows up with input device "ah4" or
"esp4" in POSTROUTING.
- locally-encapsulated traffic shows up with output device "ah4" or
"esp4" in OUTPUT.
What is missing (TODO):
- no dummy device names in INPUT/PREROUTING for locally-decapsulated
packets. This is somewhat harder
- no real output device shown in OUTPUT for locally-encapsulated
packets. I'm not sure if it is legal to typecast the just-popped
dst_entry to 'struct rtable' and derive the output interface from
there.
Please give feedback.
P.S.: Yes, the #ifdef's are ugly. I know.
diff -Nru linuxppc25bh-031218-orinoco_monitor-gpl/net/ipv4/ah4.c linuxppc25bh-031218-orinoco_monitor-gpl-netfipsec/net/ipv4/ah4.c
--- linuxppc25bh-031218-orinoco_monitor-gpl/net/ipv4/ah4.c 2003-12-18 11:39:26.000000000 +0100
+++ linuxppc25bh-031218-orinoco_monitor-gpl-netfipsec/net/ipv4/ah4.c 2004-01-28 01:08:59.430015104 +0100
@@ -7,8 +7,15 @@
#include <linux/crypto.h>
#include <linux/pfkeyv2.h>
#include <net/icmp.h>
+#include <linux/netfilter_ipv4.h>
#include <asm/scatterlist.h>
+static struct net_device *ah_dummydev;
+
+static int ah_xmit_bypass(struct sk_buff *skb)
+{
+ return NET_XMIT_BYPASS;
+}
/* Clear mutable options and find final destination to substitute
* into IP header for icv calculation. Options are already checked
@@ -54,7 +61,7 @@
return 0;
}
-static int ah_output(struct sk_buff *skb)
+static int ah_output_finish(struct sk_buff *skb)
{
int err;
struct dst_entry *dst = skb->dst;
@@ -145,7 +152,17 @@
err = -EHOSTUNREACH;
goto error_nolock;
}
- return NET_XMIT_BYPASS;
+
+#ifdef CONFIG_NETFILTER
+ nf_conntrack_put(skb->nfct);
+ skb->nfct = NULL;
+#ifdef CONFIG_NETFILTER_DEBUG
+ skb->nf_debug = 0;
+#endif
+#endif
+
+ return NF_HOOK(PF_INET, NF_IP_LOCAL_OUT, skb, ah_dummydev, NULL,
+ ah_xmit_bypass);
error:
spin_unlock_bh(&x->lock);
@@ -154,6 +171,12 @@
return err;
}
+static int ah_output(struct sk_buff *skb)
+{
+ return NF_HOOK(PF_INET, NF_IP_POST_ROUTING, skb, skb->dev, ah_dummydev,
+ ah_output_finish);
+}
+
int ah_input(struct xfrm_state *x, struct xfrm_decap_state *decap, struct sk_buff *skb)
{
int ah_hlen;
@@ -354,11 +377,18 @@
xfrm_unregister_type(&ah_type, AF_INET);
return -EAGAIN;
}
+ ah_dummydev = alloc_netdev(0, "ah4", NULL);
+ if (!ah_dummydev) {
+ printk(KERN_INFO "ip ah init: can't allocate dummydev\n");
+ inet_del_protocol(&ah4_protocol, IPPROTO_AH);
+ xfrm_unregister_type(&ah_type, AF_INET);
+ }
return 0;
}
static void __exit ah4_fini(void)
{
+ free_netdev(ah_dummydev);
if (inet_del_protocol(&ah4_protocol, IPPROTO_AH) < 0)
printk(KERN_INFO "ip ah close: can't remove protocol\n");
if (xfrm_unregister_type(&ah_type, AF_INET) < 0)
diff -Nru linuxppc25bh-031218-orinoco_monitor-gpl/net/ipv4/esp4.c linuxppc25bh-031218-orinoco_monitor-gpl-netfipsec/net/ipv4/esp4.c
--- linuxppc25bh-031218-orinoco_monitor-gpl/net/ipv4/esp4.c 2003-12-18 11:38:22.000000000 +0100
+++ linuxppc25bh-031218-orinoco_monitor-gpl-netfipsec/net/ipv4/esp4.c 2004-01-28 01:09:19.610947136 +0100
@@ -8,6 +8,7 @@
#include <linux/crypto.h>
#include <linux/pfkeyv2.h>
#include <linux/random.h>
+#include <linux/netfilter_ipv4.h>
#include <net/icmp.h>
#include <net/udp.h>
@@ -20,7 +21,16 @@
__u8 proto;
};
-int esp_output(struct sk_buff *skb)
+static struct net_device *esp_dummydev;
+
+/* dummy function for netfilter. esp_output_finish() has to return
+ * that particular value upon success */
+static int esp_xmit_bypass(struct sk_buff *skb)
+{
+ return NET_XMIT_BYPASS;
+}
+
+static int esp_output_finish(struct sk_buff *skb)
{
int err;
struct dst_entry *dst = skb->dst;
@@ -199,7 +209,17 @@
err = -EHOSTUNREACH;
goto error_nolock;
}
- return NET_XMIT_BYPASS;
+
+#ifdef CONFIG_NETFILTER
+ nf_conntrack_put(skb->nfct);
+ skb->nfct = NULL;
+#ifdef CONFIG_NETFILTER_DEBUG
+ skb->nf_debug = 0;
+#endif
+#endif
+ /* FIXME: return real destination device */
+ return NF_HOOK(PF_INET, NF_IP_LOCAL_OUT, skb, esp_dummydev, NULL,
+ esp_xmit_bypass);
error:
spin_unlock_bh(&x->lock);
@@ -208,6 +228,12 @@
return err;
}
+int esp_output(struct sk_buff *skb)
+{
+ return NF_HOOK(PF_INET, NF_IP_POST_ROUTING, skb, skb->dev, esp_dummydev,
+ esp_output_finish);
+}
+
/*
* Note: detecting truncated vs. non-truncated authentication data is very
* expensive, so we only support truncated data, which is the recommended
@@ -596,11 +622,19 @@
xfrm_unregister_type(&esp_type, AF_INET);
return -EAGAIN;
}
+ esp_dummydev = alloc_netdev(0, "esp4", NULL);
+ if (!esp_dummydev) {
+ printk(KERN_INFO "ip esp init: can't allocate dummydev\n");
+ inet_del_protocol(&esp4_protocol, IPPROTO_ESP);
+ xfrm_unregister_type(&esp_type, AF_INET);
+ return -EAGAIN;
+ }
return 0;
}
static void __exit esp4_fini(void)
{
+ free_netdev(esp_dummydev);
if (inet_del_protocol(&esp4_protocol, IPPROTO_ESP) < 0)
printk(KERN_INFO "ip esp close: can't remove protocol\n");
if (xfrm_unregister_type(&esp_type, AF_INET) < 0)
diff -Nru linuxppc25bh-031218-orinoco_monitor-gpl/net/ipv4/xfrm4_input.c linuxppc25bh-031218-orinoco_monitor-gpl-netfipsec/net/ipv4/xfrm4_input.c
--- linuxppc25bh-031218-orinoco_monitor-gpl/net/ipv4/xfrm4_input.c 2004-01-28 00:50:36.204730840 +0100
+++ linuxppc25bh-031218-orinoco_monitor-gpl-netfipsec/net/ipv4/xfrm4_input.c 2004-01-28 00:51:39.557099816 +0100
@@ -6,6 +6,8 @@
* Split up af-specific portion
* Derek Atkins <derek@ihtfp.com>
* Add Encapsulation support
+ * Harald Welte <laforge@netfilter.org>
+ * Drop conntrack reference before calling netif_rx()
*
*/
@@ -130,6 +132,13 @@
dst_release(skb->dst);
skb->dst = NULL;
}
+#ifdef CONFIG_NETFILTER
+ nf_conntrack_put(skb->nfct);
+ skb->nfct = NULL;
+#ifdef CONFIG_NETFILTER_DEBUG
+ skb->nf_debug = 0;
+#endif
+#endif
netif_rx(skb);
return 0;
} else {
--
- Harald Welte <laforge@netfilter.org> http://www.netfilter.org/
============================================================================
"Fragmentation is like classful addressing -- an interesting early
architectural error that shows how much experimentation was going
on while IP was being designed." -- Paul Vixie
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [Bridge] forwarding delay
From: Stephen Hemminger @ 2004-01-28 0:08 UTC (permalink / raw)
To: P; +Cc: bridge
In-Reply-To: <4016B8E3.6050701@draigBrady.com>
On Tue, 27 Jan 2004 19:15:47 +0000
P@draigBrady.com wrote:
> Hi,
>
> I'm using linux 2.4.20 here and noticed that even
> when STP is disabled for a bridge, the forwarding delay
> still takes affect. Is this correct? I.E. Does the
> bridge need to spend time in the "listening" and
> "learning" states when STP isn't used?
>
> It's an easy work around to set the delay to 0,
> I'm just wondering whether it's a buglet or
> by design.
I think it was a design decision to avoid forwarding data until
some state was acquired. It is annoying if you don't expect it.
^ permalink raw reply
* Re: still ..Confused about atyfb and M1
From: Richard Smith @ 2004-01-28 0:07 UTC (permalink / raw)
To: benh; +Cc: Alexander Kern, Jon Smirl, Linux Fbdev development list,
James Simmons
In-Reply-To: <400C8907.6080809@bitworks.com>
Richard Smith wrote:
> Benjamin Herrenschmidt wrote:
>
>>> Mach64 MOBILITY M1 works by me for ages. I submitted all patches to
>>> James for months. They are in fbdev.diff.gz. But I dont think, they
>>> will be merged with vanilla very soon.
>>
>>
> I grabbed fbdev.diff.gz from infradead (is this the canonical source?)
> and patched my 2.6.1 tree. But I still don't see my 0x4c52 device id
> listed in the tables.
>
And it still dosen't detect my device(s).
I never received an answer to this. I don't see how the M1 can work
supported when the device id isn't in the table. Did I really get the
latest patch?
--
Richard A. Smith
rsmith@bitworks.com
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
^ permalink raw reply
* [LARTC] tncg and bandwidth limiting
From: Scott Baker @ 2004-01-28 0:07 UTC (permalink / raw)
To: lartc
In-Reply-To: <5.2.0.9.0.20040127150331.00ac7bd0@mail.web-ster.com>
I think I got a little send happy with the last message and forgot to
include the "right" configuration. Here is REALLY what we're using. It's
working in the lab right now, I want to move it into production later.
Basically ignore that last message.
----------------------------
I'm trying to do some very simple rate-shaping on an interface. I want to
limit my 100baseT interface to 7 megs both ingress and egress of the
interface. I've been hacking my way through the documentation and some
examples and I've come up with the following configuration for tcng that
seems to do what I want.
I'm curious if some of the other experts out there wouldn't have a "better"
way to do what I'm doing. I'd like to do HTB ingress as well, but it
complains that the the ingress qdisc doesn't allow inside classes or
something like that. I think this will work for me, I just want to make
sure this is the best way to do things.
----------------------------
dev INTERFACE {
egress {
class ( <$all> ) if 1;
htb () {
class ( rate 100Mbps, ceil 100Mbps ) ;
$all = class ( rate 7Mbps, ceil 7Mbps ) ;
}
}
ingress {
$p = bucket(rate 7Mbps, burst 100kB, mpu 200B);
class (1) if (conform $p && count $p) || drop;
}
}
Scott Baker - Network Engineer - RHCE
bakers @ web-ster . com - 503.266.8253
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
^ permalink raw reply
* Re: [OT] Sco
From: Thomas Zehetbauer @ 2004-01-28 0:04 UTC (permalink / raw)
To: linux-kernel
In-Reply-To: <Pine.LNX.4.44.0401271752001.16757-100000@phoenix.infradead.org>
Looking at SCO I can hardly find any SERVICE and at least none that
could be denied by an attack on their website. In fact this virus may
even give them new ammo to spread FUD about linux and the community.
Tom
^ permalink raw reply
* [2.6.2-rc2] R31 hangs after booting oops
From: Bernd Schubert @ 2004-01-28 0:02 UTC (permalink / raw)
To: linux-kernel; +Cc: r31
Hello,
my Thinkpad R31 stops during the boot-process when I give 'acpi=off' as boot
option, but on using acpi it boots fine (so when I'm not giving this option).
Unfortunality it has no serial port to capture this oops -- any suggestions
how to capture it via parallel port or via usb-to-serial cable?
I manually write down some maybe helpfull messages, please tell me, if you
need more or have an idea how to get a full automatic trace.
Floppy drives(s): fd0 is 1.44M
Unable to hande kernel pointer dereference at virtual address 00000004
printing eip:
c01449ec
*pde = 00000000
Oops: 0000 [#1]
CPU: 0
EIP: 0060:[<c01449ec>] Not tainted
(I leave out the other numbers and registers)
Process swapper (pid: 0, threadinginfo=c048000 task c941ed60)
(please ask for Stack numbers if needed)
Call Trace: (without all numbers)
drain_array
reap_timer
update_process_times
reap_timer_softirq
do_softirq
common interrrupt
apm_bios_call_simple
apm_do_idle
apm_cpu_idle
_stext
cpu_idle
start_kernel
unknown_bootoption
Kernel panic: Fatal exception in interrrupt
In interrupt handler - not syncing
Thanks in advance for your help,
Bernd
^ permalink raw reply
* Re: MO: opening for write in cdrom.c
From: Jens Axboe @ 2004-01-28 0:02 UTC (permalink / raw)
To: Pascal Schmidt; +Cc: linux-kernel
In-Reply-To: <Pine.LNX.4.44.0401271910130.878-100000@neptune.local>
On Tue, Jan 27 2004, Pascal Schmidt wrote:
>
> [...]
> > I'll make that change everywhere and then send an updated version.
>
> Here's an updated version, both patches as one.
>
> This solves the remaining problems (512 byte sector discs) and
> rough edges (write-protect detection) with ATAPI MO support via
> ide-cd/cdrom for me.
Alright, this is your version plus write protect io error handling.
Could you check if this works for you?
--- include/linux/cdrom.h~ 2004-01-28 00:59:18.918633482 +0100
+++ include/linux/cdrom.h 2004-01-28 00:57:11.684379155 +0100
@@ -496,6 +496,7 @@
#define GPCMD_GET_MEDIA_STATUS 0xda
/* Mode page codes for mode sense/set */
+#define GPMODE_VENDOR_PAGE 0x00
#define GPMODE_R_W_ERROR_PAGE 0x01
#define GPMODE_WRITE_PARMS_PAGE 0x05
#define GPMODE_AUDIO_CTL_PAGE 0x0e
--- drivers/cdrom/cdrom.c~ 2004-01-28 00:59:07.878826161 +0100
+++ drivers/cdrom/cdrom.c 2004-01-28 00:57:11.690378507 +0100
@@ -696,6 +696,35 @@
return ret;
}
+static int mo_open_write(struct cdrom_device_info *cdi)
+{
+ struct cdrom_generic_command cgc;
+ char buffer[255];
+ int ret;
+
+ init_cdrom_command(&cgc, &buffer, 4, CGC_DATA_READ);
+ cgc.quiet = 1;
+
+ /*
+ * obtain write protect information as per
+ * drivers/scsi/sd.c:sd_read_write_protect_flag
+ */
+
+ ret = cdrom_mode_sense(cdi, &cgc, GPMODE_ALL_PAGES, 0);
+ if (ret)
+ ret = cdrom_mode_sense(cdi, &cgc, GPMODE_VENDOR_PAGE, 0);
+ if (ret) {
+ cgc.buflen = 255;
+ ret = cdrom_mode_sense(cdi, &cgc, GPMODE_ALL_PAGES, 0);
+ }
+
+ /* drive gave us no info, let the user go ahead */
+ if (ret)
+ return 0;
+
+ return buffer[3] & 0x80;
+}
+
/*
* returns 0 for ok to open write, non-0 to disallow
*/
@@ -707,11 +736,8 @@
ret = cdrom_mrw_open_write(cdi);
else if (CDROM_CAN(CDC_DVD_RAM))
ret = cdrom_dvdram_open_write(cdi);
- /*
- * needs to really check whether media is writeable
- */
else if (CDROM_CAN(CDC_MO_DRIVE))
- ret = 0;
+ ret = mo_open_write(cdi);
return ret;
}
--- drivers/ide/ide-cd.c~ 2004-01-28 00:59:29.188523981 +0100
+++ drivers/ide/ide-cd.c 2004-01-28 01:00:41.412721285 +0100
@@ -294,10 +294,12 @@
* 4.60 Dec 17, 2003 - Add mt rainier support
* - Bump timeout for packet commands, matches sr
* - Odd stuff
+ * 4.61 Jan 22, 2004 - support hardware sector sizes other than 2kB,
+ * Pascal Schmidt <der.eremit@email.de>
*
*************************************************************************/
-#define IDECD_VERSION "4.60"
+#define IDECD_VERSION "4.61"
#include <linux/config.h>
#include <linux/module.h>
@@ -818,6 +820,14 @@
do_end_request = 1;
} else if (sense_key == ILLEGAL_REQUEST ||
sense_key == DATA_PROTECT) {
+ /*
+ * check if this was a write protected media
+ */
+ if (rq_data_dir(rq) == WRITE) {
+ printk("ide-cd: media marked write protected\n");
+ set_disk_ro(drive->disk, 1);
+ }
+
/* No point in retrying after an illegal
request or data protect error.*/
ide_dump_status (drive, "command error", stat);
@@ -1211,6 +1221,9 @@
{
struct cdrom_info *info = drive->driver_data;
struct request *rq = HWGROUP(drive)->rq;
+ unsigned short sectors_per_frame;
+
+ sectors_per_frame = queue_hardsect_size(drive->queue) >> SECTOR_BITS;
/* Can't do anything if there's no buffer. */
if (info->buffer == NULL) return 0;
@@ -1249,7 +1262,7 @@
will fail. I think that this will never happen, but let's be
paranoid and check. */
if (rq->current_nr_sectors < bio_cur_sectors(rq->bio) &&
- (rq->sector % SECTORS_PER_FRAME) != 0) {
+ (rq->sector % sectors_per_frame) != 0) {
printk("%s: cdrom_read_from_buffer: buffer botch (%ld)\n",
drive->name, (long)rq->sector);
cdrom_end_request(drive, 0);
@@ -1268,13 +1281,10 @@
static ide_startstop_t cdrom_start_read_continuation (ide_drive_t *drive)
{
struct request *rq = HWGROUP(drive)->rq;
- int nsect, sector, nframes, frame, nskip;
-
- /* Number of sectors to transfer. */
- nsect = rq->nr_sectors;
+ unsigned short sectors_per_frame;
+ int nskip;
- /* Starting sector. */
- sector = rq->sector;
+ sectors_per_frame = queue_hardsect_size(drive->queue) >> SECTOR_BITS;
/* If the requested sector doesn't start on a cdrom block boundary,
we must adjust the start of the transfer so that it does,
@@ -1283,31 +1293,19 @@
of the buffer, it will mean that we're to skip a number
of sectors equal to the amount by which CURRENT_NR_SECTORS
is larger than the buffer size. */
- nskip = (sector % SECTORS_PER_FRAME);
+ nskip = (rq->sector % sectors_per_frame);
if (nskip > 0) {
/* Sanity check... */
if (rq->current_nr_sectors != bio_cur_sectors(rq->bio) &&
- (rq->sector % CD_FRAMESIZE != 0)) {
+ (rq->sector % sectors_per_frame != 0)) {
printk ("%s: cdrom_start_read_continuation: buffer botch (%u)\n",
drive->name, rq->current_nr_sectors);
cdrom_end_request(drive, 0);
return ide_stopped;
}
- sector -= nskip;
- nsect += nskip;
rq->current_nr_sectors += nskip;
}
- /* Convert from sectors to cdrom blocks, rounding up the transfer
- length if needed. */
- nframes = (nsect + SECTORS_PER_FRAME-1) / SECTORS_PER_FRAME;
- frame = sector / SECTORS_PER_FRAME;
-
- /* Largest number of frames was can transfer at once is 64k-1. For
- some drives we need to limit this even more. */
- nframes = MIN (nframes, (CDROM_CONFIG_FLAGS (drive)->limit_nframes) ?
- (65534 / CD_FRAMESIZE) : 65535);
-
/* Set up the command */
rq->timeout = ATAPI_WAIT_PC;
@@ -1346,13 +1344,11 @@
static ide_startstop_t cdrom_start_seek_continuation (ide_drive_t *drive)
{
struct request *rq = HWGROUP(drive)->rq;
- int sector, frame, nskip;
+ unsigned short sectors_per_frame;
+ int frame;
- sector = rq->sector;
- nskip = (sector % SECTORS_PER_FRAME);
- if (nskip > 0)
- sector -= nskip;
- frame = sector / SECTORS_PER_FRAME;
+ sectors_per_frame = queue_hardsect_size(drive->queue) >> SECTOR_BITS;
+ frame = rq->sector / sectors_per_frame;
memset(rq->cmd, 0, sizeof(rq->cmd));
rq->cmd[0] = GPCMD_SEEK;
@@ -1396,6 +1392,9 @@
{
struct cdrom_info *info = drive->driver_data;
struct request *rq = HWGROUP(drive)->rq;
+ unsigned short sectors_per_frame;
+
+ sectors_per_frame = queue_hardsect_size(drive->queue) >> SECTOR_BITS;
/* We may be retrying this request after an error. Fix up
any weirdness which might be present in the request packet. */
@@ -1411,8 +1410,8 @@
info->nsectors_buffered = 0;
/* use dma, if possible. */
- if (drive->using_dma && (rq->sector % SECTORS_PER_FRAME == 0) &&
- (rq->nr_sectors % SECTORS_PER_FRAME == 0))
+ if (drive->using_dma && (rq->sector % sectors_per_frame == 0) &&
+ (rq->nr_sectors % sectors_per_frame == 0))
info->dma = 1;
else
info->dma = 0;
@@ -1950,11 +1949,22 @@
static ide_startstop_t cdrom_start_write(ide_drive_t *drive, struct request *rq)
{
struct cdrom_info *info = drive->driver_data;
+ struct gendisk *g = drive->disk;
+ unsigned short sectors_per_frame = queue_hardsect_size(drive->queue) >> SECTOR_BITS;
/*
- * writes *must* be 2kB frame aligned
+ * writes *must* be hardware frame aligned
*/
- if ((rq->nr_sectors & 3) || (rq->sector & 3)) {
+ if ((rq->nr_sectors & (sectors_per_frame - 1)) ||
+ (rq->sector & (sectors_per_frame - 1))) {
+ cdrom_end_request(drive, 0);
+ return ide_stopped;
+ }
+
+ /*
+ * disk has become write protected
+ */
+ if (g->policy) {
cdrom_end_request(drive, 0);
return ide_stopped;
}
@@ -1969,12 +1979,12 @@
info->nsectors_buffered = 0;
- /* use dma, if possible. we don't need to check more, since we
- * know that the transfer is always (at least!) 2KB aligned */
+ /* use dma, if possible. we don't need to check more, since we
+ * know that the transfer is always (at least!) frame aligned */
info->dma = drive->using_dma ? 1 : 0;
info->cmd = WRITE;
- /* Start sending the read request to the drive. */
+ /* Start sending the write request to the drive. */
return cdrom_start_packet_command(drive, 32768, cdrom_start_write_cont);
}
@@ -2209,6 +2219,7 @@
}
static int cdrom_read_capacity(ide_drive_t *drive, unsigned long *capacity,
+ unsigned long *sectors_per_frame,
struct request_sense *sense)
{
struct {
@@ -2227,8 +2238,11 @@
req.data_len = sizeof(capbuf);
stat = cdrom_queue_packet_command(drive, &req);
- if (stat == 0)
+ if (stat == 0) {
*capacity = 1 + be32_to_cpu(capbuf.lba);
+ *sectors_per_frame =
+ be32_to_cpu(capbuf.blocklen) >> SECTOR_BITS;
+ }
return stat;
}
@@ -2270,6 +2284,7 @@
struct atapi_toc_entry ent;
} ms_tmp;
long last_written;
+ unsigned long sectors_per_frame = SECTORS_PER_FRAME;
if (toc == NULL) {
/* Try to allocate space. */
@@ -2289,12 +2304,15 @@
if (CDROM_STATE_FLAGS(drive)->toc_valid)
return 0;
- /* Try to get the total cdrom capacity. */
- stat = cdrom_read_capacity(drive, &toc->capacity, sense);
+ /* Try to get the total cdrom capacity and sector size. */
+ stat = cdrom_read_capacity(drive, &toc->capacity, §ors_per_frame,
+ sense);
if (stat)
toc->capacity = 0x1fffff;
- set_capacity(drive->disk, toc->capacity * SECTORS_PER_FRAME);
+ set_capacity(drive->disk, toc->capacity * sectors_per_frame);
+ blk_queue_hardsect_size(drive->queue,
+ sectors_per_frame << SECTOR_BITS);
/* First read just the header, so we know how long the TOC is. */
stat = cdrom_read_tocentry(drive, 0, 1, 0, (char *) &toc->hdr,
@@ -2406,7 +2424,7 @@
stat = cdrom_get_last_written(cdi, &last_written);
if (!stat && last_written) {
toc->capacity = last_written;
- set_capacity(drive->disk, toc->capacity * SECTORS_PER_FRAME);
+ set_capacity(drive->disk, toc->capacity * sectors_per_frame);
}
/* Remember that we've read this stuff. */
@@ -3306,12 +3324,12 @@
static
sector_t ide_cdrom_capacity (ide_drive_t *drive)
{
- unsigned long capacity;
+ unsigned long capacity, sectors_per_frame;
- if (cdrom_read_capacity(drive, &capacity, NULL))
+ if (cdrom_read_capacity(drive, &capacity, §ors_per_frame, NULL))
return 0;
- return capacity * SECTORS_PER_FRAME;
+ return capacity * sectors_per_frame;
}
static
--
Jens Axboe
^ permalink raw reply
* Re: RFC: Trailing blanks in source files
From: Andrew Morton @ 2004-01-28 0:02 UTC (permalink / raw)
To: Randy.Dunlap; +Cc: tao, theman, ak, rmps, linux-kernel
In-Reply-To: <20040127111824.7f76efe6.rddunlap@osdl.org>
"Randy.Dunlap" <rddunlap@osdl.org> wrote:
>
> So please don't bother with just whitespace changes unless you
> are going to cleanup a <driver | fs | module | etc> completely.
And if you're going to do that, do the whitespace cleanup _first_, so the
substantive changes to the driver/fs/module/etc can be sanely understood
and reverted if necessary.
I frequently sneakily remove all newly-added trailing whitespace from the
patches people send me. In 15 years it'll all be gone.
^ permalink raw reply
* Re: porting sorcerer to udev
From: mjl @ 2004-01-27 23:58 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <401633EA.4000102@laposte.net>
Greg KH wrote:
>On Tue, Jan 27, 2004 at 10:48:26AM +0100, MALET JL wrote:
>
>
>>hello,
>>I'm one of the linux sorcerer maintainer and I'm trying to switch
>>sorcerer to udev (from devfs)
>>the "spells" (compile/install scripts) are done and everything install fine
>>hotplug scripts seems to work correctly at least for usb (some strange
>>error on pci only with 2.6 kernels, some modules aren't loaded but I
>>haven't investigateted further) : my usb mouse/adaptaters modules are
>>loaded at boot time....
>>so this means : 1) pci hosts are detected 2) usb OHCI generate the event
>>(detection of usbmouse) and hotplug loads the corrects modules :)
>>BUT :( udev don't work
>>running the test scripts work correctly (it's awfully long but at least
>>this create some entries) after i mounted sysfs into /sys (previous
>>mount point was /sysfs but udev don't work with it)
>>so I don't understand.....
>>
>>
>
>What are the error messages?
>
>
>
>>I readed into the docs and found that udev/hotplug is now
>>udev/namedev/hotplug/libsysfs but I can't find namedev stuff can it
>>comes from that?
>>
>>
>
>No, udev contains "namedev" and "libsysfs". They are all built into one
>udev binary.
>
>
thx for the precision
>>the link of udev into hotplug.d is correct and have the rights modes
>>if someone can help.....
>>
>>
>
>Build udev with DEBUG=true and USE_LOG=true and show us what the debug
>logs say when you run udev.
>
>
the only things that seems to be usefull is "udev_hotplug : no devpath?"
looking into the test scripts I saw that the script set DEVPATH and then
call udev.... and this way work so it seems that hotplug don't set DEVPATH
>thanks,
>
>greg k-h
>
>
>-------------------------------------------------------
>The SF.Net email is sponsored by EclipseCon 2004
>Premiere Conference on Open Tools Development and Integration
>See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
>http://www.eclipsecon.org/osdn
>_______________________________________________
>Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
>Linux-hotplug-devel@lists.sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
>
>
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
^ permalink raw reply
* RE: [PATCH] 2.4.25-pre7 SCSI fusion driver - version - 2.05.11.01
From: Moore, Eric Dean @ 2004-01-27 23:57 UTC (permalink / raw)
To: marcelo.tosatti; +Cc: linux-scsi, Christoph Hellwig
On Tuesday, January 27, 2004 4:20 PM, Christoph Hellwig wrote:
> alpha doesn't have any 32bit userland..
>
Marcelo - Sorry - I didn't know that about __alpha__.
Can you back this out of the patch, or do you want me to
recreate another mpt patch, and repost.
Eric Moore
^ permalink raw reply
* Re: NGROUPS 2.6.2rc2
From: Chris Wright @ 2004-01-27 23:55 UTC (permalink / raw)
To: Tim Hockin; +Cc: torvalds, Linux Kernel mailing list, rusty
In-Reply-To: <20040127225311.GA9155@sun.com>
* Tim Hockin (thockin@sun.com) wrote:
> This patch changes the security interface for task_setgroups().
Minor fixup would be needed for SELinux.
thanks,
-chris
--
Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net
===== security/selinux/hooks.c 1.20 vs edited =====
--- 1.20/security/selinux/hooks.c Tue Jan 20 17:58:48 2004
+++ edited/security/selinux/hooks.c Tue Jan 27 15:42:41 2004
@@ -2265,7 +2265,7 @@
return task_has_perm(current, p, PROCESS__GETSESSION);
}
-static int selinux_task_setgroups(int gidsetsize, gid_t *grouplist)
+static int selinux_task_setgroups(struct group_info *group_info)
{
/* See the comment for setuid above. */
return 0;
^ permalink raw reply
* Re: NAT before IPsec with 2.6
From: Harald Welte @ 2004-01-27 23:55 UTC (permalink / raw)
To: Henrik Nordstrom, Willy Tarreau, Tom Eastep, Michal Ludvig,
netfilter-devel
In-Reply-To: <20040127130739.GR11761@sunbeam.de.gnumonks.org>
[-- Attachment #1: Type: text/plain, Size: 6649 bytes --]
Hi!
I've now hacked a preliminary patch. Be warned, I didn't even test if
it compiles. Maybe someone who actually has a running 2.6.x ipsec setup
can give it a try.
What it should be doing
- traverse the additional chains as described in the last email
- have connection tracking recognize two seperate connections, one
for the decapsulated traffic, one for the encapsulated
- thus, even SNAT/DNAT should be working.
- locally-encapsulated traffic shows up with input device "ah4" or
"esp4" in POSTROUTING.
- locally-encapsulated traffic shows up with output device "ah4" or
"esp4" in OUTPUT.
What is missing (TODO):
- no dummy device names in INPUT/PREROUTING for locally-decapsulated
packets. This is somewhat harder
- no real output device shown in OUTPUT for locally-encapsulated
packets. I'm not sure if it is legal to typecast the just-popped
dst_entry to 'struct rtable' and derive the output interface from
there.
Please give feedback.
P.S.: Yes, the #ifdef's are ugly. I know.
diff -Nru linuxppc25bh-031218-orinoco_monitor-gpl/net/ipv4/ah4.c linuxppc25bh-031218-orinoco_monitor-gpl-netfipsec/net/ipv4/ah4.c
--- linuxppc25bh-031218-orinoco_monitor-gpl/net/ipv4/ah4.c 2003-12-18 11:39:26.000000000 +0100
+++ linuxppc25bh-031218-orinoco_monitor-gpl-netfipsec/net/ipv4/ah4.c 2004-01-28 00:40:38.923531384 +0100
@@ -9,6 +9,12 @@
#include <net/icmp.h>
#include <asm/scatterlist.h>
+static struct net_device *ah_dummydev;
+
+static int ah_xmit_bypass(struct sk_buff *skb)
+{
+ return NET_XMIT_BYPASS;
+}
/* Clear mutable options and find final destination to substitute
* into IP header for icv calculation. Options are already checked
@@ -54,7 +60,7 @@
return 0;
}
-static int ah_output(struct sk_buff *skb)
+static int ah_output_finish(struct sk_buff *skb)
{
int err;
struct dst_entry *dst = skb->dst;
@@ -145,7 +151,17 @@
err = -EHOSTUNREACH;
goto error_nolock;
}
- return NET_XMIT_BYPASS;
+
+#ifdef CONFIG_NETFILTER
+ nf_conntrack_put(skb->conntrack);
+ skb->nfct = NULL;
+#ifdef CONFIG_NETFILTER_DEBUG
+ skb->nf_debug = 0;
+#endif
+#endif
+
+ return NF_HOOK(PF_INET, NF_IP_LOCAL_OUT, skb, ah_dummydev, NULL,
+ ah_xmit_bypass);
error:
spin_unlock_bh(&x->lock);
@@ -154,6 +170,12 @@
return err;
}
+static ah_output(struct sk_buff *skb)
+{
+ return NF_HOOK(PF_INET, IP_NF_POST_ROUTING, skb, skb->dev, ah_dummydev,
+ ah_output_finish);
+}
+
int ah_input(struct xfrm_state *x, struct xfrm_decap_state *decap, struct sk_buff *skb)
{
int ah_hlen;
@@ -354,11 +376,18 @@
xfrm_unregister_type(&ah_type, AF_INET);
return -EAGAIN;
}
+ ah_dummydev = alloc_netdev(0, "ah4", NULL);
+ if (!ah_dummydev) {
+ printk(KERN_INFO "ip ah init: can't allocate dummydev\n");
+ inet_del_protocol(&ah4_protocol, IPPROTO_AH);
+ xfrm_unregister_type(&ah_type, AF_INET);
+ }
return 0;
}
static void __exit ah4_fini(void)
{
+ free_netdev(ah_dummydev);
if (inet_del_protocol(&ah4_protocol, IPPROTO_AH) < 0)
printk(KERN_INFO "ip ah close: can't remove protocol\n");
if (xfrm_unregister_type(&ah_type, AF_INET) < 0)
diff -Nru linuxppc25bh-031218-orinoco_monitor-gpl/net/ipv4/esp4.c linuxppc25bh-031218-orinoco_monitor-gpl-netfipsec/net/ipv4/esp4.c
--- linuxppc25bh-031218-orinoco_monitor-gpl/net/ipv4/esp4.c 2003-12-18 11:38:22.000000000 +0100
+++ linuxppc25bh-031218-orinoco_monitor-gpl-netfipsec/net/ipv4/esp4.c 2004-01-28 00:33:58.002480648 +0100
@@ -20,7 +20,16 @@
__u8 proto;
};
-int esp_output(struct sk_buff *skb)
+static struct net_device *esp_dummydev;
+
+/* dummy function for netfilter. esp_output_finish() has to return
+ * that particular value upon success */
+static int esp_xmit_bypass(struct sk_buff *skb)
+{
+ return NET_XMIT_BYPASS;
+}
+
+static int esp_output_finish(struct sk_buff *skb)
{
int err;
struct dst_entry *dst = skb->dst;
@@ -199,7 +208,17 @@
err = -EHOSTUNREACH;
goto error_nolock;
}
- return NET_XMIT_BYPASS;
+
+#ifdef CONFIG_NETFILTER
+ nf_conntrack_put(skb->conntrack);
+ skb->nfct = NULL;
+#ifdef CONFIG_NETFILTER_DEBUG
+ skb->nf_debug = 0;
+#endif
+#endif
+ /* FIXME: return real destination device */
+ return NF_HOOK(PF_INET, NF_IP_LOCAL_OUT, skb, esp_dummydev, NULL,
+ esp_xmit_bypass);
error:
spin_unlock_bh(&x->lock);
@@ -208,6 +227,12 @@
return err;
}
+int esp_output(struct sk_buff *skb)
+{
+ return NF_HOOK(PF_INET, NF_IP_POST_ROUTING, skb, skb->dev, esp_dummydev,
+ esp_output_finish);
+}
+
/*
* Note: detecting truncated vs. non-truncated authentication data is very
* expensive, so we only support truncated data, which is the recommended
@@ -596,11 +621,19 @@
xfrm_unregister_type(&esp_type, AF_INET);
return -EAGAIN;
}
+ esp_dummydev = alloc_netdev(0, "esp4", NULL);
+ if (!esp_dummydev) {
+ printk(KERN_INFO "ip esp init: can't allocate dummydev\n");
+ inet_del_protocol(&esp4_protocol, IPPROTO_ESP);
+ xfrm_unregister_type(&esp_type, AF_INET);
+ return -EAGAIN;
+ }
return 0;
}
static void __exit esp4_fini(void)
{
+ free_netdev(esp_dummydev);
if (inet_del_protocol(&esp4_protocol, IPPROTO_ESP) < 0)
printk(KERN_INFO "ip esp close: can't remove protocol\n");
if (xfrm_unregister_type(&esp_type, AF_INET) < 0)
diff -Nru linuxppc25bh-031218-orinoco_monitor-gpl/net/ipv4/xfrm4_input.c linuxppc25bh-031218-orinoco_monitor-gpl-netfipsec/net/ipv4/xfrm4_input.c
--- linuxppc25bh-031218-orinoco_monitor-gpl/net/ipv4/xfrm4_input.c 2004-01-28 00:50:36.204730840 +0100
+++ linuxppc25bh-031218-orinoco_monitor-gpl-netfipsec/net/ipv4/xfrm4_input.c 2004-01-28 00:51:39.557099816 +0100
@@ -6,6 +6,8 @@
* Split up af-specific portion
* Derek Atkins <derek@ihtfp.com>
* Add Encapsulation support
+ * Harald Welte <laforge@netfilter.org>
+ * Drop conntrack reference before calling netif_rx()
*
*/
@@ -130,6 +132,13 @@
dst_release(skb->dst);
skb->dst = NULL;
}
+#ifdef CONFIG_NETFILTER
+ nf_conntrack_put(skb->conntrack);
+ skb->nfct = NULL;
+#ifdef CONFIG_NETFILTER_DEBUG
+ skb->nf_debug = 0;
+#endif
+#endif
netif_rx(skb);
return 0;
} else {
--
- Harald Welte <laforge@netfilter.org> http://www.netfilter.org/
============================================================================
"Fragmentation is like classful addressing -- an interesting early
architectural error that shows how much experimentation was going
on while IP was being designed." -- Paul Vixie
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [patch] 2.6.1-mm5 compile do not use shared extable code for ia64
From: Paul Mackerras @ 2004-01-27 23:49 UTC (permalink / raw)
To: davidm; +Cc: Andrew Morton, Jes Sorensen, linux-kernel, linux-ia64
In-Reply-To: <16406.36741.510353.456578@napali.hpl.hp.com>
David Mosberger writes:
> Paul> Also, I don't think there is enough code there to be worth the
> Paul> bother of trying to abstract the generic routine so you can
> Paul> plug in different compare and move-element routines. The
> Paul> whole sort routine is only 16 lines of code, after all. Why
> Paul> not just have an ia64-specific version of sort_extable?
> Paul> That's what I thought you would do.
>
> Because the Alpha needs exactly the same code.
I really don't like the uglification of lib/extable.c. I think it is
much better to have ~20 lines of code in each of arch/ia64/mm and
arch/alpha/mm than to try to generalize lib/extable.c. Once you add
all the extra definitions you need for your version, I doubt that the
overall savings would be more than a dozen lines or so.
The point is that with lib/extable.c as it is, you can look at one
page of code, and everything you need to understand that code is
there. With your change, I have to hunt around to check what the
macros are doing on each arch, and flip backwards and forwards to
check side effects, calling environment etc. With an ia64-specific
extable.c, you should be able to look at one page of code there and
see that the ia64 version is also correct.
Paul.
^ permalink raw reply
* Re: [PATCH|RFC] IPv6: have a proxy discard link-local traffic
From: YOSHIFUJI Hideaki / 吉藤英明 @ 2004-01-27 23:54 UTC (permalink / raw)
To: vnuorval; +Cc: davem, pekkas, usagi-core, netdev, yoshfuji
In-Reply-To: <Pine.LNX.4.58.0401272259160.28384@rhea.tcs.hut.fi>
In article <Pine.LNX.4.58.0401272259160.28384@rhea.tcs.hut.fi> (at Tue, 27 Jan 2004 23:11:20 +0200 (EET)), Ville Nuorvala <vnuorval@tcs.hut.fi> says:
> Dave, since even Pekka is now convinced this patch doesn't break anything,
:
> + /* The proxying router can't forward traffic sent to a link-local
> + address, so signal the sender and discard the packet. This
> + behavior is required by the MIPv6 specification. */
Would you please clarify the word "can't" and its reasons?
won't? don't? or whatever?
--
Hideaki YOSHIFUJI @ USAGI Project <yoshfuji@linux-ipv6.org>
GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA
^ permalink raw reply
* Re: linux-2.4-benh compiling error
From: Christian Kujau @ 2004-01-27 23:51 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20040127194022.GA646@kimdon.org>
David Kimdon wrote:
| I don't know what your build system is, but I had the same error on
| Debian unstable, the bug (and a patch) is here:
|
| http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=228852
yes, Debian/unstable here, and it really seems to be that very bug you
pointed out. it´s even said to be fixed in the latest version of
console-tools, so i´ll have to wait until it hits my mirror of choice.
Thanks!
Christian.
- --
BOFH excuse #69:
knot in cables caused data stream to become twisted and kinked
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
^ 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.