* Re: [parisc-linux] Strange newest LAB msg?
From: Joel Soete @ 2006-04-03 13:20 UTC (permalink / raw)
To: deller; +Cc: parisc-linux
Hello Helge,
>
>
> Helge Deller wrote:
> > On Sunday 02 April 2006 13:18, Joel Soete wrote:
> >
[snip]
> >
> >>PS: btw, rm CONFIG_DETECT_SOFTLOCKUP in the config doesn't help on th=
is
system ;<(:
> >>still hanging (this time without Softlockup msg) after only:
> >>top - 09:04:58 up 1 day, 16:26, 3 users, load average: 2.40, 2.26, =
2.20
> >
> >
> > I think the softlockups don't really matter.
> > Does your box hangs without SMP as well ?
> >
> well it did with b2k and n4k runing 64bit kernel with
CONFIG_DETECT_SOFTLOCKUP=3Dy && # CONFIG_SMP is not set
>
> but I need to verify now without CONFIG_DETECT_SOFTLOCKUP.
> (sorry I couldn't do it now but tomorrow morming; ok?
>
Unfortunately, this test (kernel 2.6.16-pa10 up and wiythout
CONFIG_DETECT_SOFTLOCKUP) finished earlier then expected: i.e. the system=
also
hang up after just few hours of build loop ;<(
Joel=0A=0A---------------------------------------------------------------=
=0AA free anti-spam and anti-virus filter on all Scarlet mailboxes=0AMore=
info on http://www.scarlet.be/
^ permalink raw reply
* Re: [PATCH/RFC] MTD: Striping layer core
From: Jörn Engel @ 2006-04-03 13:18 UTC (permalink / raw)
To: Nicolas Pitre
Cc: Alexander Belyakov, Vitaly Wool, Kutergin, Timofey,
Korolev, Alexey, linux-mtd, Artem B. Bityutskiy
In-Reply-To: <20060403130619.GA7659@wohnheim.fh-wedel.de>
On Mon, 3 April 2006 15:06:19 +0200, Jörn Engel wrote:
>
> As a step in that direction, please take a look at this patchset:
> http://wh.fh-wedel.de/~joern/mtd_type.tgzwh.fh-wedel.de/~joern/mtd_type.tgz
Taking a closer look at the code, reader should notice three
interesting things, btw:
1. Nico is a lazy moron,
2. Artem is a lazy moron and
3. Jörn is a lazy moron.
Nico, you didn't notice that the Sibley flashes are just another
iteration of ST's ECC NOR flashes. Special code for both flash types
is nearly identical, except for the field used to store the writesize
in struct mtd_info.
Artem, you didn't notice that Dataflash has the exact same cleanup
routine as ECC NOR and NAND flash has. And for the initialization
code, that could be shared as well.
Jörn, I didn't notice that ECC NOR has the exact same cleanup routine
as NAND flash. And for the initialization code, that could be shared
as well.
Overall, JFFS2 currently has four sets of special setup/cleanup code
for NAND, ECC NOR, Dataflash and Sibley. Simply because the three of
us were too lazy to read the existing code and didn't notice. Noone
else seemed to have noticed either, so the "lazy moron" thing seems to
be fairly universal. Don't take it as an insult, but rather as a
statement about human nature (and a trick to attract attention).
Nico, can you take a close look at the Sibley part of the patches and
checker whether I broke anything? Combining ECC NOR and Sibley was
the low hanging fruit, so I already picked it. Combining the three
remaining sets is harder. Maybe someone else is feeling the urge to
combine those.
Jörn
--
He who knows that enough is enough will always have enough.
-- Lao Tsu
^ permalink raw reply
* [PATCH 3/3] BLIST_ATTACH_PQ3 flags
From: Kurt Garloff @ 2006-04-03 13:20 UTC (permalink / raw)
To: Linux SCSI list, Patrick Mansfield
In-Reply-To: <20060329201020.GG7919@tpkurt.suse.de>
[-- Attachment #1: Type: text/plain, Size: 3294 bytes --]
Hi,
rediff, just for completeness. (Unchanged from old patch that still
applies with minimal offset.)
From: Kurt Garloff <garloff@suse.de>
Subject: Tolerate PQ 3 at LUN 0 for scanning
Patch-mainline:
References: 158532
Some devices report a peripheral qualifier of 3 for LUN 0; with the original
code, we would still try a REPORT_LUNS scan (if SCSI level is >= 3 or if we
have the BLIST_REPORTLUNS2 passed in), but NOT any sequential scan.
Also, the device at LUN 0 (which is not connected according to the PQ) is not
registered with the OS.
Unfortunately, SANs exist that are SCSI-2 and do NOT support REPORT_LUNS, but
report a unknown device with PQ 3 on LUN 0. We still need to scan them, and
most probably we even need BLIST_SPARSELUN (and BLIST_LARGELUN). See the bug
reference for an infamous example.
This is patch 3/3:
3. Implement the blacklist flag BLIST_ATTACH_PQ3 that makes the scsi
scanning code register PQ3 devices and continues scanning; only sg
will attach thanks to scsi_bus_match().
Acked-by:
Signed-off-by: Kurt Garloff <garloff@suse.de>
Index: linux-2.6.16/drivers/scsi/scsi_scan.c
===================================================================
--- linux-2.6.16.orig/drivers/scsi/scsi_scan.c
+++ linux-2.6.16/drivers/scsi/scsi_scan.c
@@ -887,9 +887,9 @@ static int scsi_probe_and_add_lun(struct
*bflagsp = bflags;
/*
* result contains valid SCSI INQUIRY data.
*/
- if ((result[0] >> 5) == 3) {
+ if (((result[0] >> 5) == 3) && !(bflags & BLIST_ATTACH_PQ3)) {
/*
* For a Peripheral qualifier 3 (011b), the SCSI
* spec says: The device server is not capable of
* supporting a physical device on this logical
Index: linux-2.6.16/drivers/scsi/scsi_devinfo.c
===================================================================
--- linux-2.6.16.orig/drivers/scsi/scsi_devinfo.c
+++ linux-2.6.16/drivers/scsi/scsi_devinfo.c
@@ -154,8 +154,10 @@ static struct {
{"Generic", "USB Storage-SMC", "0207", BLIST_FORCELUN | BLIST_INQUIRY_36},
{"HITACHI", "DF400", "*", BLIST_SPARSELUN},
{"HITACHI", "DF500", "*", BLIST_SPARSELUN},
{"HITACHI", "DF600", "*", BLIST_SPARSELUN},
+ {"HITACHI", "DISK-SUBSYSTEM", "*", BLIST_ATTACH_PQ3 | BLIST_SPARSELUN | BLIST_LARGELUN},
+ {"HITACHI", "OPEN-E", "*", BLIST_ATTACH_PQ3 | BLIST_SPARSELUN | BLIST_LARGELUN},
{"HP", "A6189A", NULL, BLIST_SPARSELUN | BLIST_LARGELUN}, /* HP VA7400 */
{"HP", "OPEN-", "*", BLIST_SPARSELUN | BLIST_LARGELUN}, /* HP XP Arrays */
{"HP", "NetRAID-4M", NULL, BLIST_FORCELUN},
{"HP", "HSV100", NULL, BLIST_REPORTLUN2 | BLIST_NOSTARTONADD},
Index: linux-2.6.16/include/scsi/scsi_devinfo.h
===================================================================
--- linux-2.6.16.orig/include/scsi/scsi_devinfo.h
+++ linux-2.6.16/include/scsi/scsi_devinfo.h
@@ -27,5 +27,6 @@
#define BLIST_NOT_LOCKABLE 0x80000 /* don't use PREVENT-ALLOW commands */
#define BLIST_NO_ULD_ATTACH 0x100000 /* device is actually for RAID config */
#define BLIST_SELECT_NO_ATN 0x200000 /* select without ATN */
#define BLIST_RETRY_HWERROR 0x400000 /* retry HARDWARE_ERROR */
+#define BLIST_ATTACH_PQ3 0x800000 /* Scan: Attach to PQ3 devices */
#endif
--
Kurt Garloff, Head Architect Linux R&D, Novell Inc.
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [LARTC] multiple gateways problem
From: Dez Cadena @ 2006-04-03 13:19 UTC (permalink / raw)
To: lartc
I have the following situation:
I have a linux box (not in router-mode) with 2 NICs and 2 gateways. I
want to be able to switch gateways
when one of them is "down". The tricky part is that, by "down" I dont
mean an unreachable gateway, but a gateway
that is reacable but for some reason cannot route packets.
any pointers would be appreciated
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
^ permalink raw reply
* [PATCH 2/3] Better log messages for PQ3 devs
From: Kurt Garloff @ 2006-04-03 13:18 UTC (permalink / raw)
To: Linux SCSI list, Patrick Mansfield
In-Reply-To: <20060329201020.GG7919@tpkurt.suse.de>
[-- Attachment #1: Type: text/plain, Size: 3123 bytes --]
Hi,
wrapped the lines at column 80 as suggested by Matthew and used
sedv_printk as suggested by James.
From: Kurt Garloff <garloff@suse.de>
Subject: Tolerate PQ 3 at LUN 0 for scanning
Patch-mainline:
References: 158532
Some devices report a peripheral qualifier of 3 for LUN 0; with the original
code, we would still try a REPORT_LUNS scan (if SCSI level is >= 3 or if we
have the BLIST_REPORTLUNS2 passed in), but NOT any sequential scan.
Also, the device at LUN 0 (which is not connected according to the PQ) is not
registered with the OS.
Unfortunately, SANs exist that are SCSI-2 and do NOT support REPORT_LUNS, but
report a unknown device with PQ 3 on LUN 0. We still need to scan them, and
most probably we even need BLIST_SPARSELUN (and BLIST_LARGELUN). See the bug
reference for an infamous example.
This patch 2/3:
If a PQ3 device is found, log a message that describes the device
(INQUIRY DATA and C:B:T:U tuple) and make a suggestion for blacklisting
it.
Acked-by:
Signed-off-by: Kurt Garloff <garloff@suse.de>
Index: linux-2.6.16/drivers/scsi/scsi_scan.c
===================================================================
--- linux-2.6.16.orig/drivers/scsi/scsi_scan.c
+++ linux-2.6.16/drivers/scsi/scsi_scan.c
@@ -795,8 +795,31 @@ static inline void scsi_destroy_sdev(str
transport_destroy_device(&sdev->sdev_gendev);
put_device(&sdev->sdev_gendev);
}
+/**
+ * scsi_inq_str - print INQUIRY data from min to max index,
+ * strip trailing whitespace
+ * @buf: Output buffer with at least end-first+1 bytes of space
+ * @inq: Inquiry buffer (input)
+ * @first: Offset of string into inq
+ * @end: Index after last character in inq
+ */
+static unsigned char* scsi_inq_str(unsigned char* buf, unsigned char *inq,
+ unsigned first, unsigned end)
+{
+ unsigned term = 0, idx;
+ for (idx = 0; idx+first < end && idx+first < inq[4]+5; ++idx) {
+ if (inq[idx+first] > 0x20) {
+ buf[idx] = inq[idx+first];
+ term = idx+1;
+ } else {
+ buf[idx] = ' ';
+ }
+ }
+ buf[term] = 0;
+ return buf;
+}
/**
* scsi_probe_and_add_lun - probe a LUN, if a LUN is found add it
* @starget: pointer to target device structure
@@ -875,11 +898,20 @@ static int scsi_probe_and_add_lun(struct
* For disks, this implies that there is no
* logical disk configured at sdev->lun, but there
* is a target id responding.
*/
- SCSI_LOG_SCAN_BUS(3, printk(KERN_INFO
- "scsi scan: peripheral qualifier of 3,"
- " no device added\n"));
+ SCSI_LOG_SCAN_BUS(2, sdev_printk(KERN_INFO, sdev, "scsi scan:"
+ " peripheral qualifier of 3, device not"
+ " added\n"))
+ if (lun == 0) {
+ unsigned char vend[9], mod[17];
+ SCSI_LOG_SCAN_BUS(1, sdev_printk(KERN_INFO, sdev,
+ "scsi scan: consider passing scsi_mod."
+ "dev_flags=%s:%s:0x240 or 0x800240\n",
+ scsi_inq_str(vend, result, 8, 16),
+ scsi_inq_str(mod, result, 16, 32)));
+ }
+
res = SCSI_SCAN_TARGET_PRESENT;
goto out_free_result;
}
--
Kurt Garloff, Head Architect Linux R&D, Novell Inc.
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [PATCH 1/3] Try LUN 1 and use bflags
From: Kurt Garloff @ 2006-04-03 13:16 UTC (permalink / raw)
To: Linux SCSI list, Patrick Mansfield
In-Reply-To: <20060329201020.GG7919@tpkurt.suse.de>
[-- Attachment #1: Type: text/plain, Size: 3589 bytes --]
Hi,
patch redone, incorporating Pat Mansfield's suggestion to remove the
lun0_res variable, as it was unused after patching.
From: Kurt Garloff <garloff@suse.de>
Subject: Tolerate PQ 3 at LUN 0 for scanning
Patch-mainline:
References: 158532
Some devices report a peripheral qualifier of 3 for LUN 0; with the original
code, we would still try a REPORT_LUNS scan (if SCSI level is >= 3 or if we
have the BLIST_REPORTLUNS2 passed in), but NOT any sequential scan.
Also, the device at LUN 0 (which is not connected according to the PQ) is not
registered with the OS.
Unfortunately, SANs exist that are SCSI-2 and do NOT support REPORT_LUNS, but
report a unknown device with PQ 3 on LUN 0. We still need to scan them, and
most probably we even need BLIST_SPARSELUN (and BLIST_LARGELUN). See the bug
reference for an infamous example.
This is patch 1/3:
If we end up in sequential scan, at least try LUN 1 for devices
that reported a PQ of 3 for LUN 0.
Also return blacklist flags, even for PQ3 devices.
Acked-by:
Signed-off-by: Kurt Garloff <garloff@suse.de>
Index: linux-2.6.16/drivers/scsi/scsi_scan.c
===================================================================
--- linux-2.6.16.orig/drivers/scsi/scsi_scan.c
+++ linux-2.6.16/drivers/scsi/scsi_scan.c
@@ -859,8 +859,10 @@ static int scsi_probe_and_add_lun(struct
if (scsi_probe_lun(sdev, result, result_len, &bflags))
goto out_free_result;
+ if (bflagsp)
+ *bflagsp = bflags;
/*
* result contains valid SCSI INQUIRY data.
*/
if ((result[0] >> 5) == 3) {
@@ -886,10 +888,8 @@ static int scsi_probe_and_add_lun(struct
if (bflags & BLIST_KEY) {
sdev->lockable = 0;
scsi_unlock_floptical(sdev, result);
}
- if (bflagsp)
- *bflagsp = bflags;
}
out_free_result:
kfree(result);
@@ -912,9 +912,8 @@ static int scsi_probe_and_add_lun(struct
/**
* scsi_sequential_lun_scan - sequentially scan a SCSI target
* @starget: pointer to target structure to scan
* @bflags: black/white list flag for LUN 0
- * @lun0_res: result of scanning LUN 0
*
* Description:
* Generally, scan from LUN 1 (LUN 0 is assumed to already have been
* scanned) to some maximum lun until a LUN is found with no device
@@ -922,10 +921,9 @@ static int scsi_probe_and_add_lun(struct
*
* Modifies sdevscan->lun.
**/
static void scsi_sequential_lun_scan(struct scsi_target *starget,
- int bflags, int lun0_res, int scsi_level,
- int rescan)
+ int bflags, int scsi_level, int rescan)
{
unsigned int sparse_lun, lun, max_dev_lun;
struct Scsi_Host *shost = dev_to_shost(starget->dev.parent);
@@ -944,15 +942,8 @@ static void scsi_sequential_lun_scan(str
} else
sparse_lun = 0;
/*
- * If not sparse lun and no device attached at LUN 0 do not scan
- * any further.
- */
- if (!sparse_lun && (lun0_res != SCSI_SCAN_LUN_PRESENT))
- return;
-
- /*
* If less than SCSI_1_CSS, and no special lun scaning, stop
* scanning; this matches 2.4 behaviour, but could just be a bug
* (to continue scanning a SCSI_1_CSS device).
*
@@ -1363,9 +1354,9 @@ static void __scsi_scan_target(struct de
* The REPORT LUN did not scan the target,
* do a sequential scan.
*/
scsi_sequential_lun_scan(starget, bflags,
- res, starget->scsi_level, rescan);
+ starget->scsi_level, rescan);
}
out_reap:
/* now determine if the target has any children at all
--
Kurt Garloff, Head Architect Linux R&D, Novell Inc.
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: alsa cvs broken
From: Takashi Iwai @ 2006-04-03 13:13 UTC (permalink / raw)
To: Jaroslav Kysela; +Cc: James Courtier-Dutton, alsa-devel
In-Reply-To: <Pine.LNX.4.61.0604031458460.9509@tm8103.perex-int.cz>
At Mon, 3 Apr 2006 15:08:26 +0200 (CEST),
Jaroslav Kysela wrote:
>
> On Mon, 3 Apr 2006, Takashi Iwai wrote:
>
> > > Is hg stable enough?
> >
> > Yes, it's pretty stable now.
> > But if we switch to another one, it'd be better to run both CVS and
> > hg/git parallel in a short term for checking the stability and
> > usability.
> >
> > Another question is which host. Suggestions?
>
> I can create a hg/git repository on my machine. If we find some trouble
> with it, we can look for another solution.
Hm, wasn't the trouble of CVS on alsa-projerct.org one of reasons we
moved to sf.net...?
> I must say that git looks too much "kernel" oriented and sometimes
> hard-to-use. Mercurial has my sympatics, because it uses Python (on other
> hand, it might imply some performance issues).
AFAIK, no performance hit on hg due to python-scripting.
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: [linux-lvm] LVM Down After Disk Failure
From: Sebastian Walter @ 2006-04-03 13:10 UTC (permalink / raw)
To: LVM general discussion and development
In-Reply-To: <443111EF.5040103@zedat.fu-berlin.de>
Does anybody know how to force lvm to remove a PV or a LV from a PV
(even if the VG is not accessible)? Probably it still is present somehow
in the vgda and lvm tries to access it.... thanks!
Sebastian Walter wrote:
> Dear list,
>
> after a power failure we had troubles with a hard drive, it went down
> unrecoverably. So I removed the LV's wich had PE's on this disk by
> executing, and I got this error:
>
> [root@xxx root]# lvremove /dev/xxx/data5
> lvremove -- do you really want to remove "/dev/vghrsc/data5"? [y/n]: y
> lvremove -- ERROR "vg_write(): write" storing data of volume group
> "vghrsc" on disks
>
> then I got another strange error:
>
> Message from syslogd@xxx at Mon Apr 3 12:14:39 2006 ...
> xxx kernel: journal commit I/O error
>
> therefore I decided to reboot the system. After the reboot, I couldn't
> manage to get the system up and running again, I got error messages
> about vgchange not finding any VG's.
>
> I even ran vgcfgrestore, but it succeeded without giving me a hint about
> errors.
>
> vgscan now gives me:
>
> [root@xxx root]# vgscan
> vgscan -- reading all physical volumes (this may take a while...)
> vgscan -- ERROR "vg_read_with_pv_and_lv(): current PV" can't get data of
> volume group "vghrsc" from physical volume(s)
> vgscan -- "/etc/lvmtab" and "/etc/lvmtab.d" successfully created
> vgscan -- WARNING: This program does not do a VGDA backup of your volume
> group
>
> pvscan gives me (I had to remove the scsi disk, before I got some sense
> key errors here):
>
> [root@mex root]# pvscan
> pvscan -- reading all physical volumes (this may take a while...)
> pvscan -- inactive PV "/dev/sdb1" is associated to unknown VG "vghrsc"
> (run vgscan)
> pvscan -- inactive PV "/dev/sdc1" is associated to unknown VG "vghrsc"
> (run vgscan)
> pvscan -- inactive PV "/dev/sdd1" is associated to unknown VG "vghrsc"
> (run vgscan)
> pvscan -- inactive PV "/dev/sde1" is associated to unknown VG "vghrsc"
> (run vgscan)
> pvscan -- inactive PV "/dev/sdf1" is associated to unknown VG "vghrsc"
> (run vgscan)
> pvscan -- total: 5 [6.84 TB] / in use: 5 [6.84 TB] / in no VG: 0 [0]
>
> /dev/sdf1 is the scsi drive I removed in the meanwhile and which is not
> present anymore.
>
> I would really appreciate any help! Thanks in advance,
> Sebastian
>
>
> _______________________________________________
> linux-lvm mailing list
> linux-lvm@redhat.com
> https://www.redhat.com/mailman/listinfo/linux-lvm
> read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
>
^ permalink raw reply
* Re: alsa cvs broken
From: Jaroslav Kysela @ 2006-04-03 13:08 UTC (permalink / raw)
To: Takashi Iwai; +Cc: James Courtier-Dutton, alsa-devel
In-Reply-To: <s5hlkumbz1t.wl%tiwai@suse.de>
On Mon, 3 Apr 2006, Takashi Iwai wrote:
> > Is hg stable enough?
>
> Yes, it's pretty stable now.
> But if we switch to another one, it'd be better to run both CVS and
> hg/git parallel in a short term for checking the stability and
> usability.
>
> Another question is which host. Suggestions?
I can create a hg/git repository on my machine. If we find some trouble
with it, we can look for another solution.
I must say that git looks too much "kernel" oriented and sometimes
hard-to-use. Mercurial has my sympatics, because it uses Python (on other
hand, it might imply some performance issues).
I would start with mercurial and we'll see then.
Jaroslav
-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SUSE Labs
-------------------------------------------------------
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: Reworked patch for labels on user space messages
From: Steve Grubb @ 2006-04-03 13:08 UTC (permalink / raw)
To: Timothy R. Chavez; +Cc: redhat-lspp, linux-audit
In-Reply-To: <1144045500.26109.7.camel@localhost.localdomain>
On Monday 03 April 2006 02:25, Timothy R. Chavez wrote:
> On Sat, 2006-04-01 at 10:02 -0500, Steve Grubb wrote:
> > The below patch should be applied after the inode and ipc sid patches.
> > This patch is a reworking of Tim's patch that has been updated to match
> > the inode and ipc patches since its similar.
>
> Hey thanks for doing this. I have just one comment below.
>
> + __u32 sid; /* SELinux security id */
>
> I think we agreed not to call this 'sid' as that has another meaning
> (namely "session id") outside of SELinux.
Yeah...right...updated patch below.
Signed-off-by: Steve Grubb <sgrubb@redhat.com>
diff -urp linux-2.6.16.x86_64.orig/include/linux/netlink.h linux-2.6.16.x86_64/include/linux/netlink.h
--- linux-2.6.16.x86_64.orig/include/linux/netlink.h 2006-04-01 08:19:04.000000000 -0500
+++ linux-2.6.16.x86_64/include/linux/netlink.h 2006-04-01 08:00:26.000000000 -0500
@@ -143,6 +143,7 @@ struct netlink_skb_parms
__u32 dst_group;
kernel_cap_t eff_cap;
__u32 loginuid; /* Login (audit) uid */
+ __u32 secid; /* SELinux security id */
};
#define NETLINK_CB(skb) (*(struct netlink_skb_parms*)&((skb)->cb))
diff -urp linux-2.6.16.x86_64.orig/include/linux/selinux.h linux-2.6.16.x86_64/include/linux/selinux.h
--- linux-2.6.16.x86_64.orig/include/linux/selinux.h 2006-04-01 08:19:05.000000000 -0500
+++ linux-2.6.16.x86_64/include/linux/selinux.h 2006-04-01 07:56:15.000000000 -0500
@@ -5,6 +5,7 @@
*
* Copyright (C) 2005 Red Hat, Inc., James Morris <jmorris@redhat.com>
* Copyright (C) 2006 Trusted Computer Solutions, Inc. <dgoeddel@trustedcs.com>
+ * Copyright (C) 2006 IBM Corporation, Timothy R. Chavez <tinytim@us.ibm.com>
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License version 2,
@@ -108,6 +109,16 @@ void selinux_get_inode_sid(const struct
*/
void selinux_get_ipc_sid(const struct kern_ipc_perm *ipcp, u32 *sid);
+/**
+ * selinux_get_task_sid - return the SID of task
+ * @tsk: the task whose SID will be returned
+ * @sid: pointer to security context ID to be filled in.
+ *
+ * Returns nothing
+ */
+void selinux_get_task_sid(struct task_struct *tsk, u32 *sid);
+
+
#else
static inline int selinux_audit_rule_init(u32 field, u32 op,
@@ -156,6 +167,11 @@ static inline void selinux_get_ipc_sid(c
*sid = 0;
}
+static inline void selinux_get_task_sid(struct task_struct *tsk, u32 *sid)
+{
+ *sid = 0;
+}
+
#endif /* CONFIG_SECURITY_SELINUX */
#endif /* _LINUX_SELINUX_H */
diff -urp linux-2.6.16.x86_64.orig/kernel/audit.c linux-2.6.16.x86_64/kernel/audit.c
--- linux-2.6.16.x86_64.orig/kernel/audit.c 2006-04-01 08:19:12.000000000 -0500
+++ linux-2.6.16.x86_64/kernel/audit.c 2006-04-01 08:08:55.000000000 -0500
@@ -389,7 +389,7 @@ static int audit_netlink_ok(kernel_cap_t
static int audit_receive_msg(struct sk_buff *skb, struct nlmsghdr *nlh)
{
- u32 uid, pid, seq;
+ u32 uid, pid, seq, sid;
void *data;
struct audit_status *status_get, status_set;
int err;
@@ -415,6 +415,7 @@ static int audit_receive_msg(struct sk_b
pid = NETLINK_CREDS(skb)->pid;
uid = NETLINK_CREDS(skb)->uid;
loginuid = NETLINK_CB(skb).loginuid;
+ sid = NETLINK_CB(skb).secid;
seq = nlh->nlmsg_seq;
data = NLMSG_DATA(nlh);
@@ -467,8 +468,23 @@ static int audit_receive_msg(struct sk_b
ab = audit_log_start(NULL, GFP_KERNEL, msg_type);
if (ab) {
audit_log_format(ab,
- "user pid=%d uid=%u auid=%u msg='%.1024s'",
- pid, uid, loginuid, (char *)data);
+ "user pid=%d uid=%u auid=%u",
+ pid, uid, loginuid);
+ if (sid) {
+ char *ctx = NULL;
+ u32 len;
+ if (selinux_ctxid_to_string(
+ sid, &ctx, &len)) {
+ audit_log_format(ab,
+ " subj=%u", sid);
+ /* Maybe call audit_panic? */
+ } else
+ audit_log_format(ab,
+ " subj=%s", ctx);
+ kfree(ctx);
+ }
+ audit_log_format(ab, " msg='%.1024s'",
+ (char *)data);
audit_set_pid(ab, pid);
audit_log_end(ab);
}
diff -urp linux-2.6.16.x86_64.orig/net/netlink/af_netlink.c linux-2.6.16.x86_64/net/netlink/af_netlink.c
--- linux-2.6.16.x86_64.orig/net/netlink/af_netlink.c 2006-04-01 08:19:13.000000000 -0500
+++ linux-2.6.16.x86_64/net/netlink/af_netlink.c 2006-04-01 08:11:09.000000000 -0500
@@ -56,6 +56,7 @@
#include <linux/mm.h>
#include <linux/types.h>
#include <linux/audit.h>
+#include <linux/selinux.h>
#include <net/sock.h>
#include <net/scm.h>
@@ -1122,6 +1123,7 @@ static int netlink_sendmsg(struct kiocb
NETLINK_CB(skb).dst_pid = dst_pid;
NETLINK_CB(skb).dst_group = dst_group;
NETLINK_CB(skb).loginuid = audit_get_loginuid(current->audit_context);
+ selinux_get_task_sid(current, &(NETLINK_CB(skb).secid));
memcpy(NETLINK_CREDS(skb), &siocb->scm->creds, sizeof(struct ucred));
/* What can I do? Netlink is asynchronous, so that
diff -urp linux-2.6.16.x86_64.orig/security/selinux/exports.c linux-2.6.16.x86_64/security/selinux/exports.c
--- linux-2.6.16.x86_64.orig/security/selinux/exports.c 2006-04-01 08:19:14.000000000 -0500
+++ linux-2.6.16.x86_64/security/selinux/exports.c 2006-04-01 08:18:28.000000000 -0500
@@ -5,6 +5,7 @@
*
* Copyright (C) 2005 Red Hat, Inc., James Morris <jmorris@redhat.com>
* Copyright (C) 2006 Trusted Computer Solutions, Inc. <dgoeddel@trustedcs.com>
+ * Copyright (C) 2006 IBM Corporation, Timothy R. Chavez <tinytim@us.ibm.com>
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License version 2,
@@ -61,3 +62,13 @@ void selinux_get_ipc_sid(const struct ke
*sid = 0;
}
+void selinux_get_task_sid(struct task_struct *tsk, u32 *sid)
+{
+ if (selinux_enabled) {
+ struct task_security_struct *isec = tsk->security;
+ *sid = isec->sid;
+ return;
+ }
+ *sid = 0;
+}
+
^ permalink raw reply
* Re: Update Iptables in order to use String-Match
From: sven @ 2006-04-03 13:07 UTC (permalink / raw)
To: netfilter
In-Reply-To: <001b01c656a5$314bc680$0101000a@sterenborg.info>
Rob Sterenborg schrieb:
> The last part between the brackets, I suppose iptables wrote it ? (I
> think I got confused there.)
> If this is true, you have the string match from 1.3.3 installed (if you
> already had it, why build a new kernel/iptables ?) and are using
> iptables 1.3.5. (That means you have iptables-1.3.5 installed but didn't
> install string match 1.3.5 which would be true, reading below.)
>
>>> The string match is in the Extra repository. Did you run POM with
>>> "./runme extra" ?
>> hmm no, I will do this now...
>
> I think that will solve your problem.
> (Remember to also recompile iptables..)
The last version of POM does not content String-match!
I found it in a version of 2004, is that right?
^ permalink raw reply
* Re: [PATCH/RFC] MTD: Striping layer core
From: Jörn Engel @ 2006-04-03 13:06 UTC (permalink / raw)
To: Nicolas Pitre
Cc: Alexander Belyakov, Vitaly Wool, Kutergin, Timofey,
Korolev, Alexey, linux-mtd, Artem B. Bityutskiy
In-Reply-To: <Pine.LNX.4.64.0603311221070.14923@localhost.localdomain>
On Fri, 31 March 2006 12:22:50 -0500, Nicolas Pitre wrote:
>
> You are right here. This is why MTD drivers should export _flash_
> features rather than filesystem requirements. And it is up to
> filesystem code to cope with the (lack of) certain flash features not
> the other way around.
As long as noone is being a fundamentalist zealot, we all agree here.
My fine point of disagreement is that I stress "should" above
everything else. Quite a few things can and should be improved about
mtd and its users. If everything were perfect, it would all be about
flash features. Until then, it may make sense to _temporarily_ hold
some filesystem features. While this is undeniably a bad thing in its
own, it can allow you to get rid of bigger warts.
Once the bigger warts are gone, we can aim for perfect. ;)
As a step in that direction, please take a look at this patchset:
http://wh.fh-wedel.de/~joern/mtd_type.tgzwh.fh-wedel.de/~joern/mtd_type.tgz
It removes all types except MTD_ABSENT and all flags but MTD_OOB. As
a replacement, three new flags are introduced. So now we're at a
total of 4 flags (previously 9) and two types (previously 9).
Jörn
--
...one more straw can't possibly matter...
-- Kirby Bakken
^ permalink raw reply
* [LARTC] FTP problem in Load Balancing.....
From: Sandeep Agarwal @ 2006-04-03 12:59 UTC (permalink / raw)
To: lartc
Hi,
Now the load balancing is working fine. Thanks for the list members.
Now two problems i am facing...
1. Users are not able to download the file though FTP connection.
They are using IE from their desktop as they was doing earlier like
ftp://ftp.site.com
on to page right click & login as the user/pass allocated to them.
They are able to see the contents at there but whenever they are
going to download the file, msg appears as you do not have the
privileges to download.
Any pointer where I am wrong?
2. In case of nexthope down, I have to manually down the interface & do the
required changes as suggested on the list.
As my programming skills is zero, can someone send me the scripts to
automatically this process?
Thank you
Sandeep
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
^ permalink raw reply
* Re: [linux-lvm] LVM NOT scary! (was: LVM scary!)
From: Anil Kumar Sharma @ 2006-04-03 12:58 UTC (permalink / raw)
To: LVM general discussion and development
In-Reply-To: <20060403124112.GP19029@fencepost>
[-- Attachment #1: Type: text/plain, Size: 1196 bytes --]
On 4/3/06, Thomas Schwinge <tschwinge@gnu.org > wrote:
>
> On Mon, Apr 03, 2006 at 01:32:48PM +0100, Jim Ford wrote:
> > Hmm, there are so many horror stories on this forum that I'm beginning
> > to wish that I hadn't chosen the LVM option when I installed my Kubuntu
> > system! Mind you, having said that, I never had problems with 5 years of
>
> > software raid on a Slackware box.
>
> Well, it's commonly know that mostly the horror stories are what people
> tell each other and remember. And especially in this very place, as it's
> main purpose (apart from developing the software further) is to be a
> contact point for people encountering such issues.
>
> I'm quite sure that there are (ten- / hundred-)thousands of LVM
> installations that just work; like those I did on a number of systems.
Lists move too fast, what I wrote in other thread should have appeared here.
P.S . Next project for me: make GRUB2 read LVM volumes. Anyone who wants
> to help or has already done something, please speak up now.
>
>
Can contribute in testing, please intimate pointer to test versions.
Meanwhile wish you all the best for making GRUB2.
--
Anil Kumar Shrama
[-- Attachment #2: Type: text/html, Size: 1770 bytes --]
^ permalink raw reply
* Re: alsa cvs broken
From: Takashi Iwai @ 2006-04-03 12:53 UTC (permalink / raw)
To: Jaroslav Kysela; +Cc: James Courtier-Dutton, alsa-devel
In-Reply-To: <Pine.LNX.4.61.0604031438430.9509@tm8103.perex-int.cz>
At Mon, 3 Apr 2006 14:39:15 +0200 (CEST),
Jaroslav Kysela wrote:
>
> On Mon, 3 Apr 2006, James Courtier-Dutton wrote:
>
> > Takashi Iwai wrote:
> > > At Mon, 03 Apr 2006 12:18:00 +0100,
> > > James Courtier-Dutton wrote:
> > >
> > > > Would it be worth considering switching to using git or hg
> > > > (mecurial)?
> > > >
> > >
> > > I'd love to switch, but surely it will bring quite amount of
> > > confusion. Anyhow, it should be after releasing 1.0.11-final.
> > >
> > >
> > > Takashi
> > >
> > Ok, which do you prefer, hg or git. I think hg might be more suitable
> > for our needs(developers writing code), and it has a simple interface
> > for git pulls as well. git is better suited for people deciding whether
> > or not to include patches or not, but is not so good for developers.
>
> Is hg stable enough?
Yes, it's pretty stable now.
But if we switch to another one, it'd be better to run both CVS and
hg/git parallel in a short term for checking the stability and
usability.
Another question is which host. Suggestions?
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: alsa cvs broken
From: Takashi Iwai @ 2006-04-03 12:51 UTC (permalink / raw)
To: Adrian McMenamin; +Cc: James Courtier-Dutton, alsa-devel
In-Reply-To: <1144068409.11511.6.camel@localhost.localdomain>
At Mon, 03 Apr 2006 13:46:49 +0100,
Adrian McMenamin wrote:
>
> On Mon, 2006-04-03 at 14:44 +0200, Takashi Iwai wrote:
>
> > It's always good to submit patches as soon as possible. We need to
> > review patches anwyay before merging.
>
> Indeed, but can I get a pristine set to patch is the issue?
Reviewing your patch is the major matter at this stage.
It's likely that you'd need a small fix/adjustment for a first patch,
so the sync with the latest code can be done later.
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: [linux-lvm] LVM scary!
From: Anil Kumar Sharma @ 2006-04-03 12:51 UTC (permalink / raw)
To: LVM general discussion and development
In-Reply-To: <443115F0.8030503@watford53.freeserve.co.uk>
[-- Attachment #1: Type: text/plain, Size: 960 bytes --]
On 4/3/06, Jim Ford <jaford@watford53.freeserve.co.uk> wrote:
>
> Hmm, there are so many horror stories on this forum that I'm beginning
> to wish that I hadn't chosen the LVM option when I installed my Kubuntu
> system! Mind you, having said that, I never had problems with 5 years of
> software raid on a Slackware box.
>
>
I agree it is scary, by which I mean that you got to play with it carefully.
Having said that, I find LVM a step (generation) above normal partitioning
system.
It can give lot of flexibility provided that is planned properly and in
advance.
In many cases I find users (not anyone particular), let's call 'click
happy',
and here I mean to say that people have taken it for granted that LVM will
be a cake walk, It is if you know how you can play with it.
LVM is not like a computer game where one plays and learns. Here, replay is
very costly and that is causing lot of anguish among users.
--
Anil Kumar Shrama
[-- Attachment #2: Type: text/html, Size: 1340 bytes --]
^ permalink raw reply
* Re: [PATCH] unify PFN_* macros
From: Ralf Baechle @ 2006-04-03 12:49 UTC (permalink / raw)
To: Dave Hansen; +Cc: akpm, linux-kernel
In-Reply-To: <20060323162459.6D45D1CE@localhost.localdomain>
On Thu, Mar 23, 2006 at 08:24:59AM -0800, Dave Hansen wrote:
> Just about every architecture defines some macros to do operations on
> pfns. They're all virtually identical. This patch consolidates all
> of them.
>
> One minor glitch is that at least i386 uses them in a very skeletal
> header file. To keep away from #include dependency hell, I stuck
> the new definitions in a new, isolated header.
>
> Of all of the implementations, sh64 is the only one that varied by a
> bit. It used some masks to ensure that any sign-extension got
> ripped away before the arithmetic is done. This has been posted to
> that sh64 maintainers and the development list.
>
> Compiles on x86, x86_64, ia64 and ppc64.
Ehhh... Looks at this patch I wonder if you actually read the MIPS bits
before submitting it:
o replaces PFN_ALIGN with PAGE_ALIGN
o replaces the IP27 definition of PFN_ALIGN with a different one.
How about posting such stuff to linux-arch? No sane person follows l-k.
Ralf
^ permalink raw reply
* [U-Boot-Users] CONFIG_SKIP_LOWLEVEL_INIT is broken for at91rm9200dk
From: Wolfgang Denk @ 2006-04-03 12:49 UTC (permalink / raw)
To: u-boot
In-Reply-To: <44310E07.50502@mw-itcon.de>
Dear Peter,
in message <44310E07.50502@mw-itcon.de> you wrote:
>
> I now found the the confirmation according to the ticket ID, but my
> mailer did not succeed in correlating it to the original message (and
> you sent some more messages that time ;) ). My mailer often cannot
> correlate responses here on this mailing list. I think (not checked in
> detail), my mailer would like a Reference: field...
Your mailer is not to blame here. There probably was no useful
reference field at all in these messages as you did not actually send
this message, but rather it was me who bounced the whole batch of
open patches. This is supposed to work better when you send a patch
directly to u-boot-patches at denx.de
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
I mean, I . . . think to understand you, I just don't know what you
are saying ... - Terry Pratchett, _Soul Music_
^ permalink raw reply
* [PATCH] [AUDIT] auditfilter.c cleanup/const-ification
From: Mitchell Blank Jr @ 2006-04-03 12:51 UTC (permalink / raw)
To: dwmw2; +Cc: linux-audit
(Not sure if this will make it to the linux-audit mailing list or not; I
tried subscribing to it via the web page a couple days ago but haven't heard
back from mailman)
I noticed the gcc 4.X warning:
kernel/auditfilter.c: In function "audit_filter_user"
kernel/auditfilter.c:588: warning: "state" may be used uninitialized in this function
...and thought I'd take a quick look.
The gcc warning isn't correct (since audit_filter_user() only looked at state
if audit_filter_user_rules() returned non-zero, in which case 'state' would
have been initialized) However the code was needlessly complex --
audit_filter_user_rules() carefully populated the "enum audit_state *state"
with various value but it's only caller just cares if it's AUDIT_DISABLED
or not. It's shorter and simpler to just let audit_filter_user_rules()
modify its caller's return value more directly. As an added bonus this
also removes the warning.
While I was looking at auditfilter.c I did some other minor cleanup
* const-ified pointers where possible
* both audit_data_to_entry() and audit_krule_to_data() had an unused
variable called "void *bufp" which I removed
* [minor] I changed some variables from "int" to "unsigned int" if
they can't be negative. Since ->field_count is unsigned I think it's
a little cleaner to use an unsigned type to iterate through it
I'm not actually using the audit subsystem currently but this at least
compiles and boots ok. I believe it should all be safe.
Signed-off-by: Mitchell Blank Jr <mitch@sfgoth.com>
diff --git a/include/linux/audit.h b/include/linux/audit.h
index 1c47c59..c70049e 100644
--- a/include/linux/audit.h
+++ b/include/linux/audit.h
@@ -363,10 +363,11 @@ extern void audit_log_d_path(struct
struct dentry *dentry,
struct vfsmount *vfsmnt);
/* Private API (for audit.c only) */
-extern int audit_filter_user(struct netlink_skb_parms *cb, int type);
+extern int audit_filter_user(const struct netlink_skb_parms *cb, int type);
extern int audit_filter_type(int type);
extern int audit_receive_filter(int type, int pid, int uid, int seq,
- void *data, size_t datasz, uid_t loginuid);
+ const void *data, size_t datasz,
+ uid_t loginuid);
#else
#define audit_log(c,g,t,f,...) do { ; } while (0)
#define audit_log_start(c,g,t) ({ NULL; })
diff --git a/kernel/auditfilter.c b/kernel/auditfilter.c
index d3a8539..c9932a7 100644
--- a/kernel/auditfilter.c
+++ b/kernel/auditfilter.c
@@ -80,12 +80,13 @@ static __attribute__((unused)) char *aud
}
/* Common user-space to kernel rule translation. */
-static inline struct audit_entry *audit_to_entry_common(struct audit_rule *rule)
+static inline struct audit_entry *audit_to_entry_common(const struct audit_rule *rule)
{
unsigned listnr;
struct audit_entry *entry;
struct audit_field *fields;
- int i, err;
+ unsigned int i;
+ int err;
err = -EINVAL;
listnr = rule->flags & ~AUDIT_FILTER_PREPEND;
@@ -137,11 +138,11 @@ exit_err:
/* Translate struct audit_rule to kernel's rule respresentation.
* Exists for backward compatibility with userspace. */
-static struct audit_entry *audit_rule_to_entry(struct audit_rule *rule)
+static struct audit_entry *audit_rule_to_entry(const struct audit_rule *rule)
{
struct audit_entry *entry;
int err = 0;
- int i;
+ unsigned int i;
entry = audit_to_entry_common(rule);
if (IS_ERR(entry))
@@ -182,20 +183,18 @@ exit_free:
}
/* Translate struct audit_rule_data to kernel's rule respresentation. */
-static struct audit_entry *audit_data_to_entry(struct audit_rule_data *data,
+static struct audit_entry *audit_data_to_entry(const struct audit_rule_data *data,
size_t datasz)
{
int err = 0;
struct audit_entry *entry;
- void *bufp;
/* size_t remain = datasz - sizeof(struct audit_rule_data); */
- int i;
+ unsigned int i;
- entry = audit_to_entry_common((struct audit_rule *)data);
+ entry = audit_to_entry_common((const struct audit_rule *) data);
if (IS_ERR(entry))
goto exit_nofree;
- bufp = data->buf;
entry->rule.vers_ops = 2;
for (i = 0; i < data->field_count; i++) {
struct audit_field *f = &entry->rule.fields[i];
@@ -223,7 +222,7 @@ exit_free:
}
/* Pack a filter field's string representation into data block. */
-static inline size_t audit_pack_string(void **bufp, char *str)
+static inline size_t audit_pack_string(void **bufp, const char *str)
{
size_t len = strlen(str);
@@ -235,10 +234,10 @@ static inline size_t audit_pack_string(v
/* Translate kernel rule respresentation to struct audit_rule.
* Exists for backward compatibility with userspace. */
-static struct audit_rule *audit_krule_to_rule(struct audit_krule *krule)
+static struct audit_rule *audit_krule_to_rule(const struct audit_krule *krule)
{
struct audit_rule *rule;
- int i;
+ unsigned int i;
rule = kmalloc(sizeof(*rule), GFP_KERNEL);
if (unlikely(!rule))
@@ -265,11 +264,10 @@ static struct audit_rule *audit_krule_to
}
/* Translate kernel rule respresentation to struct audit_rule_data. */
-static struct audit_rule_data *audit_krule_to_data(struct audit_krule *krule)
+static struct audit_rule_data *audit_krule_to_data(const struct audit_krule *krule)
{
struct audit_rule_data *data;
- void *bufp;
- int i;
+ unsigned int i;
data = kmalloc(sizeof(*data) + krule->buflen, GFP_KERNEL);
if (unlikely(!data))
@@ -279,7 +277,6 @@ static struct audit_rule_data *audit_kru
data->flags = krule->flags | krule->listnr;
data->action = krule->action;
data->field_count = krule->field_count;
- bufp = data->buf;
for (i = 0; i < data->field_count; i++) {
struct audit_field *f = &krule->fields[i];
@@ -298,9 +295,10 @@ static struct audit_rule_data *audit_kru
/* Compare two rules in kernel format. Considered success if rules
* don't match. */
-static int audit_compare_rule(struct audit_krule *a, struct audit_krule *b)
+static int audit_compare_rule(const struct audit_krule *a,
+ const struct audit_krule *b)
{
- int i;
+ unsigned int i;
if (a->flags != b->flags ||
a->listnr != b->listnr ||
@@ -353,7 +351,7 @@ static inline int audit_add_rule(struct
/* Remove an existing rule from filterlist. Protected by
* audit_netlink_mutex. */
-static inline int audit_del_rule(struct audit_entry *entry,
+static inline int audit_del_rule(const struct audit_entry *entry,
struct list_head *list)
{
struct audit_entry *e;
@@ -376,8 +374,8 @@ static int audit_list(void *_dest)
{
int pid, seq;
int *dest = _dest;
- struct audit_entry *entry;
- int i;
+ const struct audit_entry *entry;
+ unsigned int i;
pid = dest[0];
seq = dest[1];
@@ -410,8 +408,8 @@ static int audit_list_rules(void *_dest)
{
int pid, seq;
int *dest = _dest;
- struct audit_entry *e;
- int i;
+ const struct audit_entry *e;
+ unsigned int i;
pid = dest[0];
seq = dest[1];
@@ -449,10 +447,10 @@ static int audit_list_rules(void *_dest)
* @datasz: size of payload data
* @loginuid: loginuid of sender
*/
-int audit_receive_filter(int type, int pid, int uid, int seq, void *data,
+int audit_receive_filter(int type, int pid, int uid, int seq, const void *data,
size_t datasz, uid_t loginuid)
{
- struct task_struct *tsk;
+ const struct task_struct *tsk;
int *dest;
int err = 0;
struct audit_entry *entry;
@@ -546,14 +544,14 @@ int audit_comparator(const u32 left, con
-static int audit_filter_user_rules(struct netlink_skb_parms *cb,
- struct audit_krule *rule,
- enum audit_state *state)
+static int audit_filter_user_rules(const struct netlink_skb_parms *cb,
+ const struct audit_krule *rule,
+ int *enabledp)
{
- int i;
+ unsigned int i;
for (i = 0; i < rule->field_count; i++) {
- struct audit_field *f = &rule->fields[i];
+ const struct audit_field *f = &rule->fields[i];
int result = 0;
switch (f->type) {
@@ -574,28 +572,20 @@ static int audit_filter_user_rules(struc
if (!result)
return 0;
}
- switch (rule->action) {
- case AUDIT_NEVER: *state = AUDIT_DISABLED; break;
- case AUDIT_POSSIBLE: *state = AUDIT_BUILD_CONTEXT; break;
- case AUDIT_ALWAYS: *state = AUDIT_RECORD_CONTEXT; break;
- }
+ if (rule->action == AUDIT_NEVER)
+ *enabledp = 0;
return 1;
}
-int audit_filter_user(struct netlink_skb_parms *cb, int type)
+int audit_filter_user(const struct netlink_skb_parms *cb, int type)
{
- struct audit_entry *e;
- enum audit_state state;
+ const struct audit_entry *e;
int ret = 1;
rcu_read_lock();
- list_for_each_entry_rcu(e, &audit_filter_list[AUDIT_FILTER_USER], list) {
- if (audit_filter_user_rules(cb, &e->rule, &state)) {
- if (state == AUDIT_DISABLED)
- ret = 0;
+ list_for_each_entry_rcu(e, &audit_filter_list[AUDIT_FILTER_USER], list)
+ if (audit_filter_user_rules(cb, &e->rule, &ret))
break;
- }
- }
rcu_read_unlock();
return ret; /* Audit by default */
@@ -603,7 +593,7 @@ int audit_filter_user(struct netlink_skb
int audit_filter_type(int type)
{
- struct audit_entry *e;
+ const struct audit_entry *e;
int result = 0;
rcu_read_lock();
@@ -612,9 +602,9 @@ int audit_filter_type(int type)
list_for_each_entry_rcu(e, &audit_filter_list[AUDIT_FILTER_TYPE],
list) {
- int i;
+ unsigned int i;
for (i = 0; i < e->rule.field_count; i++) {
- struct audit_field *f = &e->rule.fields[i];
+ const struct audit_field *f = &e->rule.fields[i];
if (f->type == AUDIT_MSGTYPE) {
result = audit_comparator(type, f->op, f->val);
if (!result)
^ permalink raw reply related
* Re: alsa cvs broken
From: Adrian McMenamin @ 2006-04-03 12:46 UTC (permalink / raw)
To: Takashi Iwai; +Cc: James Courtier-Dutton, alsa-devel
In-Reply-To: <s5hodzibzhr.wl%tiwai@suse.de>
On Mon, 2006-04-03 at 14:44 +0200, Takashi Iwai wrote:
> It's always good to submit patches as soon as possible. We need to
> review patches anwyay before merging.
Indeed, but can I get a pristine set to patch is the issue?
-------------------------------------------------------
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
* where do applications get loaded in virtual memory on a 4xx?
From: Ralph Blach @ 2006-04-03 12:46 UTC (permalink / raw)
To: Linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 208 bytes --]
I would like to know where in virtual memory application get loaded.
I can do an NM and see the address in an a.out file? How do these address
actually translate to 4xx virtual address?
thanks
Chip
[-- Attachment #2: Type: text/html, Size: 309 bytes --]
^ permalink raw reply
* Re: [linux-lvm] LVM NOT scary! (was: LVM scary!)
From: Jan-Benedict Glaw @ 2006-04-03 12:46 UTC (permalink / raw)
To: LVM general discussion and development
In-Reply-To: <20060403124112.GP19029@fencepost>
[-- Attachment #1: Type: text/plain, Size: 1251 bytes --]
On Mon, 2006-04-03 08:41:12 -0400, Thomas Schwinge <tschwinge@gnu.org> wrote:
> On Mon, Apr 03, 2006 at 01:32:48PM +0100, Jim Ford wrote:
> > Hmm, there are so many horror stories on this forum that I'm beginning
> > to wish that I hadn't chosen the LVM option when I installed my Kubuntu
> > system! Mind you, having said that, I never had problems with 5 years of
> > software raid on a Slackware box.
>
> Well, it's commonly know that mostly the horror stories are what people
> tell each other and remember. And especially in this very place, as it's
> main purpose (apart from developing the software further) is to be a
> contact point for people encountering such issues.
Full ACK. The most scary cases are those where people expect to get
high-availability by LVM'ing some IDE disks together.
Hey, LVM on MD really is a nice thing, even dm-crypt ontop, works
flawlessly :)
MfG, JBG
--
Jan-Benedict Glaw jbglaw@lug-owl.de . +49-172-7608481 _ O _
"Eine Freie Meinung in einem Freien Kopf | Gegen Zensur | Gegen Krieg _ _ O
für einen Freien Staat voll Freier Bürger" | im Internet! | im Irak! O O O
ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: alsa cvs broken
From: Takashi Iwai @ 2006-04-03 12:44 UTC (permalink / raw)
To: Adrian McMenamin; +Cc: James Courtier-Dutton, alsa-devel
In-Reply-To: <1144067416.11511.4.camel@localhost.localdomain>
At Mon, 03 Apr 2006 13:30:16 +0100,
Adrian McMenamin wrote:
>
> On Mon, 2006-04-03 at 14:07 +0200, Takashi Iwai wrote:
> > At Mon, 03 Apr 2006 12:18:00 +0100,
> > James Courtier-Dutton wrote:
> > >
> > > Hi,
> > >
> > > Is it just me, or is the ssh access to the cvs broken?
> >
> > Yeah it's been broken since last week.
> >
>
> I was planning to submit my driver today (with a bit of luck) does this
> mean there is no point?
It's always good to submit patches as soon as possible. We need to
review patches anwyay before merging.
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: [RFC] sched.c : procfs tunables
From: Mike Galbraith @ 2006-04-03 12:43 UTC (permalink / raw)
To: Al Boldi; +Cc: Con Kolivas, linux-kernel, linux-smp
In-Reply-To: <200604031459.43105.a1426z@gawab.com>
On Mon, 2006-04-03 at 14:59 +0300, Al Boldi wrote:
> Mike Galbraith wrote:
> > Nope, not the existing tunables anyway. The full effect of even a tiny
> > scheduler knob tweak is hard to predict even if you've studied the code
> > carefully. These knobs are just not generic enough to be exposed IMHO.
>
> Are you implying that the code is built around these tunables rather than
> using them?
I'm not implying anything, I'm merely stating my opinion: these knobs
have subtle effects which render them unsuitable for export.
-Mike
^ 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.