All of lore.kernel.org
 help / color / mirror / Atom feed
* RE: [RFC] FC Transport : Async Events via netlink interface
From: Moore, Eric @ 2006-04-17 22:46 UTC (permalink / raw)
  To: James.Smart; +Cc: linux-scsi

On Monday, April 17, 2006 2:44 PM, James Smart wrote:  

> 
> [netdev folks copied to review the use of the netlink interface]
> 
> This patch adds HBAAPI async event support to the FC transport.
> 
> Events are pushed to userspace via Netlink. This is per the previous
> RFC comments given in :

It would be nice to extend this to scsi_transport_sas, and start
work to addressing sas management, e.g. csmi/sdi. But I did get copied
on an email from Bob Nixon of Emulex saying something about extending
the 
HBA API defined for Fibre Channel/FCP to include consistent management 
of SAS HBAs as well. Do you know anything about this James?

Eric Moore

^ permalink raw reply

* Re: Log message printout cleanups
From: Junio C Hamano @ 2006-04-17 22:45 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0604171149330.3701@g5.osdl.org>

Linus Torvalds <torvalds@osdl.org> writes:

> On Sun, 16 Apr 2006, Junio C Hamano wrote:
>> 
>> In the mid-term, I am hoping we can drop the generate_header()
>> callchain _and_ the custom code that formats commit log in-core,
>> found in cmd_log_wc().
>
> Ok, this was nastier than expected, just because the dependencies between 
> the different log-printing stuff were absolutely _everywhere_, but here's 
> a patch that does exactly that.

I like the new cmd_log_wc() loop very much; I was planning to do
this myself, but I was too slow ;-).

Thanks.

^ permalink raw reply

* Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks
From: Alan Cox @ 2006-04-17 22:48 UTC (permalink / raw)
  To: Gerrit Huizenga
  Cc: James Morris, Serge E. Hallyn, Stephen Smalley, casey,
	linux-security-module, linux-kernel, fireflier-devel
In-Reply-To: <E1FVc0H-00077d-00@w-gerrit.beaverton.ibm.com>

On Llu, 2006-04-17 at 15:15 -0700, Gerrit Huizenga wrote:
> I get the impression from customers that SELinux is so painful to
> configure correctly that most of them disable it.  In theory, LSM +

Red Hat ships SELinux enabled by default with a set of policies that
most users just leave enabled, indeed most users don't even know they
have SELinux enabled or what SELinux is, any more than they could say
tell you what posix acls do.

That said there is a need for nice pretty policy design tools, but
that's not part of an LSM discussion.

> something like AppArmour provides a much simpler security model for

If the AppArmour people care to submit their code upstream and get it
merged then that would be a reason to keep LSM, if they don't then LSM
(if they even want it..) can just become part of their patchkit instead.

> normal human beings who want some level of configuration.  Also,
> the current SELinux config in RH is starting to have a measureable
> performance impact. 

In Fedora Core its impact is far from obvious from my testing. Older
SELinux had some ugly SMP scaling problems but those are fixed.

Alan


^ permalink raw reply

* Re: [Xenomai-core] [PATCH] let skins select nucleus features
From: Jan Kiszka @ 2006-04-17 22:42 UTC (permalink / raw)
  To: Philippe Gerum; +Cc: xenomai-core
In-Reply-To: <4442786B.40301@domain.hid>

[-- Attachment #1: Type: text/plain, Size: 541 bytes --]

Philippe Gerum wrote:
> Jan Kiszka wrote:
>> Hi,
>>
>> this patch aims at avoiding to select unneeded nucleus features if no
>> user is requiring it in the skins. Particularly, it addresses the
>> nucleus registry and the pipes.
>>
>> I have spent no effort on 2.4 yet as I first want to wait for comments.
>> Furthermore, 2.4. is lacking "select", so the feature selection has to
>> remain manually there anyway.
> 
> Looks good. Merged, thanks.
> 

In the same sense, but not that comfortable, here is the a 2.4 variant
of the patch.

Jan

[-- Attachment #2: nucl-reg-select-2.4.patch --]
[-- Type: text/x-patch, Size: 2294 bytes --]

Index: ksrc/skins/vrtx/Config.in
===================================================================
--- ksrc/skins/vrtx/Config.in	(Revision 941)
+++ ksrc/skins/vrtx/Config.in	(Arbeitskopie)
@@ -2,4 +2,10 @@
 # Xenomai configuration for Linux v2.4
 #
 
+if [ "$CONFIG_XENO_OPT_REGISTRY" = "n" ]; then
+	comment 'VRTX emulator requires CONFIG_XENO_OPT_REGISTRY'
+else
+
 dep_tristate 'VRTX emulator' CONFIG_XENO_SKIN_VRTX $CONFIG_XENO_OPT_NUCLEUS
+
+fi
Index: ksrc/skins/vxworks/Config.in
===================================================================
--- ksrc/skins/vxworks/Config.in	(Revision 941)
+++ ksrc/skins/vxworks/Config.in	(Arbeitskopie)
@@ -2,4 +2,10 @@
 # Xenomai configuration for Linux v2.4
 #
 
+if [ "$CONFIG_XENO_OPT_REGISTRY" = "n" ]; then
+	comment 'VxWorks emulator requires CONFIG_XENO_OPT_REGISTRY'
+else
+
 dep_tristate 'VxWorks emulator' CONFIG_XENO_SKIN_VXWORKS $CONFIG_XENO_OPT_NUCLEUS
+
+fi
Index: ksrc/skins/native/Config.in
===================================================================
--- ksrc/skins/native/Config.in	(Revision 941)
+++ ksrc/skins/native/Config.in	(Arbeitskopie)
@@ -2,6 +2,10 @@
 # Xenomai configuration for Linux v2.4
 #
 
+if [ "$CONFIG_XENO_OPT_PERVASIVE" = "y" -a "$CONFIG_XENO_OPT_REGISTRY" = "n" ]; then
+	comment 'Native skin requires CONFIG_XENO_OPT_REGISTRY in pervasive mode'
+else
+
 dep_tristate 'Native skin' CONFIG_XENO_SKIN_NATIVE $CONFIG_XENO_OPT_NUCLEUS
 
 if [ "$CONFIG_XENO_SKIN_NATIVE" != "n" ]; then
@@ -24,3 +28,5 @@ if [ "$CONFIG_XENO_SKIN_NATIVE" != "n" ]
 	bool 'Interrupts' CONFIG_XENO_OPT_NATIVE_INTR
 	endmenu
 fi
+
+fi
Index: ksrc/nucleus/Config.in
===================================================================
--- ksrc/nucleus/Config.in	(Revision 941)
+++ ksrc/nucleus/Config.in	(Arbeitskopie)
@@ -17,11 +17,7 @@ if [ "$CONFIG_XENO_OPT_NUCLEUS" != "n" ]
 	if [ "$CONFIG_XENO_OPT_PIPE" != "n" ]; then
 		int 'Number of pipe devices' CONFIG_XENO_OPT_PIPE_NRDEV 32
 	fi
-	if [ "$CONFIG_XENO_OPT_PERVASIVE" != "n" ]; then
-		define_bool CONFIG_XENO_OPT_REGISTRY y
-	else
-		bool 'Registry support' CONFIG_XENO_OPT_REGISTRY
-	fi
+	bool 'Registry support' CONFIG_XENO_OPT_REGISTRY
 	if [ "$CONFIG_XENO_OPT_REGISTRY" != "n" ]; then
 		int 'Number of registry slots' CONFIG_XENO_OPT_REGISTRY_NRSLOTS 512
 	fi

^ permalink raw reply

* Re: Any glfer users?
From: Al Scanandoah @ 2006-04-17 22:40 UTC (permalink / raw)
  To: Joop Stakenborg; +Cc: linux-hams
In-Reply-To: <1145251767.16709.5.camel@localhost.localdomain>

That took care of it, thank you very much!


Al, K2ZN

Joop Stakenborg wrote:
> Op zo, 16-04-2006 te 18:32 -0400, schreef Al Scanandoah:
>> It looks like it may be getting closer, but still no cigar.  The error 
>> messages have changed.
> 
> You can't compile glfer against version 2.0 of the GTK+ libraries. It is
> an application written for version 1.2 of these libraries. In order to
> get it working with GTK+-2.0 you need the attached patch.
> 
> I have sent this to the glfer author a while back, but he never replied
> to my mail...
> 
> Regards,
> Joop PG4I
> 
> 

^ permalink raw reply

* [PATCH 1/2] scsi: Add scsi_device max_cmd_len (resend)
From: Brian King @ 2006-04-17 22:40 UTC (permalink / raw)
  To: James.Bottomley; +Cc: linux-scsi, jgarzik, linux-ide, brking


Add a max_cmd_len field to the scsi_device struct
to allow for per device limits of allowable command
lengths. This patch was submitted earlier and resulted
in a bit of discussion regarding whether or not
CDB length is a limitation of the host or the device.
For ATA, both the host and the device can limit the
CDB length. Currently libata reads the IDENTIFY
PACKET DEVICE data for an ATAPI device and sets
the max_cmd_len in the scsi host for the maximum
supported CDB length of all ATA/ATAPI devices attached
to the same scsi host. This patch allows libata to
set the max CDB length on a per device basis and
allows the SAS/SATA HBA to set its own max command
length in the scsi host template.

Signed-off-by: Brian King <brking@us.ibm.com>
---

 libata-dev-bjking1/drivers/scsi/scsi.c        |    3 ++-
 libata-dev-bjking1/drivers/scsi/scsi_scan.c   |    1 +
 libata-dev-bjking1/include/scsi/scsi_device.h |    1 +
 3 files changed, 4 insertions(+), 1 deletion(-)

diff -puN include/scsi/scsi_device.h~scsi_device_cdb_len include/scsi/scsi_device.h
--- libata-dev/include/scsi/scsi_device.h~scsi_device_cdb_len	2006-04-17 17:17:50.000000000 -0500
+++ libata-dev-bjking1/include/scsi/scsi_device.h	2006-04-17 17:17:50.000000000 -0500
@@ -72,6 +72,7 @@ struct scsi_device {
 	unsigned int manufacturer;	/* Manufacturer of device, for using 
 					 * vendor-specific cmd's */
 	unsigned sector_size;	/* size in bytes */
+	unsigned char max_cmd_len;
 
 	void *hostdata;		/* available to low-level driver */
 	char type;
diff -puN drivers/scsi/scsi_scan.c~scsi_device_cdb_len drivers/scsi/scsi_scan.c
--- libata-dev/drivers/scsi/scsi_scan.c~scsi_device_cdb_len	2006-04-17 17:17:50.000000000 -0500
+++ libata-dev-bjking1/drivers/scsi/scsi_scan.c	2006-04-17 17:17:50.000000000 -0500
@@ -218,6 +218,7 @@ static struct scsi_device *scsi_alloc_sd
 	sdev->lun = lun;
 	sdev->channel = starget->channel;
 	sdev->sdev_state = SDEV_CREATED;
+	sdev->max_cmd_len = MAX_COMMAND_SIZE;
 	INIT_LIST_HEAD(&sdev->siblings);
 	INIT_LIST_HEAD(&sdev->same_target_siblings);
 	INIT_LIST_HEAD(&sdev->cmd_list);
diff -puN drivers/scsi/scsi.c~scsi_device_cdb_len drivers/scsi/scsi.c
--- libata-dev/drivers/scsi/scsi.c~scsi_device_cdb_len	2006-04-17 17:17:50.000000000 -0500
+++ libata-dev-bjking1/drivers/scsi/scsi.c	2006-04-17 17:17:50.000000000 -0500
@@ -610,7 +610,8 @@ int scsi_dispatch_cmd(struct scsi_cmnd *
 	 * Before we queue this command, check if the command
 	 * length exceeds what the host adapter can handle.
 	 */
-	if (CDB_SIZE(cmd) > cmd->device->host->max_cmd_len) {
+	if (CDB_SIZE(cmd) > cmd->device->host->max_cmd_len ||
+	    CDB_SIZE(cmd) > cmd->device->max_cmd_len) {
 		SCSI_LOG_MLQUEUE(3,
 				printk("queuecommand : command too long.\n"));
 		cmd->result = (DID_ABORT << 16);
_

^ permalink raw reply

* Re: [-rt] time-related problems with CPU frequency scaling
From: Lee Revell @ 2006-04-17 22:35 UTC (permalink / raw)
  To: woho; +Cc: linux-kernel, Ingo Molnar, Thomas Gleixner
In-Reply-To: <200604162041.10844.woho@woho.de>

On Sun, 2006-04-16 at 20:41 +0200, Wolfgang Hoffmann wrote:
> - if CPU frequency is low when jackd is started, it complains:
>     "delay of 2915.000 usecs exceeds estimated spare
>     time of 2847.000; restart ..."
>   as soon as frequency is scaled up. Seems that jackd gets confused by some
>   influence of CPU frequency on timekeeping? No problems as long as CPU
>   frequency isn't scaled up, though.

JACK still uses the TSC for timing and thus is incompatible with CPU
frequency scaling.  You must use the -clockfix branch from CVS.

> - values in /proc/sys/kernel/preempt_max_latency scales inverse to
>     CPU frequency, i.e. 24us with CPU @ 800MHz and 12us with CPU @ 1,6GHz 

This is normal - code that takes 12us to run at 1.6 GHz will take 24us
at 800MHz.  TANSTAAFL ;-)

Lee


^ permalink raw reply

* audit 1.2.1 released
From: Steve Grubb @ 2006-04-17 22:34 UTC (permalink / raw)
  To: linux-audit

Hi,

I've just released a new version of the audit daemon. It can be downloaded 
from http://people.redhat.com/sgrubb/audit  It will also be in rawhide  
tomorrow. The Changelog is:

- New message type for trusted apps
- Add new keywords: today, yesterday, & now for ausearch and aureport
- Make audit_log_user_avc_message really send to syslog on error
- Updated syscall tables in auditctl
- Deprecated the 'possible' action for syscall rules in auditctl
- Update watch code to use file syscalls instead of 'all' in auditctl

This is mostly a bugfix release. Let me know if there are any problems with 
it.

-Steve

^ permalink raw reply

* Re: ramdisk driver strange behaviour
From: Nathan Scott @ 2006-04-17 22:29 UTC (permalink / raw)
  To: Gyorgy Szekely; +Cc: linux-kernel
In-Reply-To: <940be6070604140659q31c45599wf729a47ef25103ee@mail.gmail.com>

On Fri, Apr 14, 2006 at 03:59:07PM +0200, Gyorgy Szekely wrote:
> hi,
> i'm trying to use a ramdisk driver (block/rd.c) and experienced some
> very strnage behaviour. In brief:
> If I set ramdisk_blocksize=512 on the kernel command line, the driver
> operates oddly. I execute the following commands in a shell:
> 
> mkfs.ext2 /dev/ram0     ~runs fine, no errors
> mount /dev/ram0 /mnt/disk    ~doesn't mount the filesystem, can't find
> it on device
> mkfs.ext2 /dev/ram0     ~runs fine, same as above
> mount /dev/ram0 /mnt/disk    ~mounts fine
> 
> I have to make exactly this command sequence, to make the fs usable,
> eg: mkfs.ext2 twice without trying to mount doesn't work. Once the
> mount succeeds everything works fine, i can read/write files,
> unmount/remount everything as expected.
> I copied the ramdisk contents with dd into a file, and after the first
> pass it's all zeros nothing else. Like the first mkfs didn't do
> anything.
> 
> If I remove the ramdisk_blocksize option from the kernel command line
> (defaults to 1024) then all is ok.

I wonder if this is a strange artifact of the supported blocksizes
for the filesystem you're using...

mkfs.ext2 ...
	-b block-size
		Specify the size of blocks in bytes.  Valid block size
		vales are 1024, 2048 and 4096 bytes per block.  ...

During mount the filesystem will tell the driver what its minimum
block size is, and the driver is meant to validate that, and return
an error if its too small.  Whats probably happening in your case
is a failure to handle the too-small case correctly... oh, hmm, yes,
look at the callers of set_blocksize -- in ext3 its return value is
not being checked afaict, and in ext2 I'm not sure where this setup
is done (doesn't seem to be a set_blocksize call there at all - hmm).

You might try XFS too as a data point - XFS will permit a 512 byte
filesystem blocksize - so try mkfs.xfs -bsize=512 /dev/ram0 and see
if that mounts OK first go... that'd backup the above theory if it
does.

cheers.

-- 
Nathan

^ permalink raw reply

* Fw: [Bugme-new] [Bug 6402] New: KERNEL 2.6.16-rX (Gentoo) && PPPD && SNAT
From: Andrew Morton @ 2006-04-17 22:27 UTC (permalink / raw)
  To: netdev; +Cc: slavon, bugme-daemon@kernel-bugs.osdl.org



Begin forwarded message:

Date: Mon, 17 Apr 2006 14:57:03 -0700
From: bugme-daemon@bugzilla.kernel.org
To: bugme-new@lists.osdl.org
Subject: [Bugme-new] [Bug 6402] New: KERNEL 2.6.16-rX (Gentoo) && PPPD && SNAT


http://bugzilla.kernel.org/show_bug.cgi?id=6402

           Summary: KERNEL 2.6.16-rX (Gentoo) && PPPD && SNAT
    Kernel Version: 2.6.16.ALL
            Status: NEW
          Severity: high
             Owner: shemminger@osdl.org
         Submitter: slavon@bigtelecom.ru


After start download file its stop after 4-10 mb and network is down.

Interface ppp0 is UP.
No new dmeseg or debug of syslog

try to ping ppp client:

slavon ~ # ping 192.168.0.2
PING 192.168.0.2 (192.168.0.2) 56(84) bytes of data.
ping: sendmsg: No buffer space available
ping: sendmsg: No buffer space available
ping: sendmsg: No buffer space available
ping: sendmsg: No buffer space available
ping: sendmsg: No buffer space available
ping: sendmsg: No buffer space available
ping: sendmsg: No buffer space available
ping: sendmsg: No buffer space available
ping: sendmsg: No buffer space available
ping: sendmsg: No buffer space available
ping: sendmsg: No buffer space available
ping: sendmsg: No buffer space available
ping: sendmsg: No buffer space available

#ifconfig ppp0
ppp0      Link encap:Point-to-Point Protocol
          inet addr:192.168.0.1  P-t-P:192.168.0.2  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1396  Metric:1
          RX packets:1648 errors:0 dropped:0 overruns:0 frame:0
          TX packets:2407 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:3
          RX bytes:75765 (73.9 Kb)  TX bytes:3242633 (3.0 Mb)

#iptables-save
*nat
:PREROUTING ACCEPT [6826:411515]
:POSTROUTING ACCEPT [11117:531811]
:OUTPUT ACCEPT [11118:531895]
-A POSTROUTING -s 192.168.0.0/255.255.255.0 -j SNAT --to-source XXX.XXX.XXX.XXX
COMMIT

slavon ~ # pppd --version
pppd version 2.4.3

slavon ~ # pptpd --version
pptpd v1.3.1

I try it in 3 Computers 2 - x86 and 1 - x86-64 - All have this trouble

its gentoo patches for kernel

 * Applying 1000_linux-2.6.16.1.patch (-p0+) 
 * Applying 1001_linux-2.6.16.2.patch (-p0+) 
 * Applying 1002_linux-2.6.16.3.patch (-p0+) 
 * Applying 1003_linux-2.6.16.4.patch (-p0+) 
 * Applying 1700_sparc-obp64-naming.patch (-p0+) 
 * Applying 1705_sparc-U1-hme-lockup.patch (-p0+) 
 * Applying 1710_sparc-sparsemem.patch (-p0+) 
 * Applying 1715_ppc32-crosscc-ssp.patch (-p0+) 
 * Applying 2400_sky2-1.1.patch (-p0+) 
 * Applying 2405_skge-1.5.patch (-p0+) 
 * Applying 2600_input-mod-devicetable.patch (-p0+) 
 * Applying 4000_deprecate-sk98lin.patch (-p0+) 
 * Applying 4100_libata-enable-atapi.patch (-p0+) 
 * Applying 4105_dm-bbr.patch (-p0+) 
 * Applying 4110_promise-pdc2037x.patch (-p0+) 
 * Applying 4200_fbsplash-0.9.2-r5.patch (-p0+) 
 * Applying 4205_vesafb-tng-1.0-rc1-r3.patch (-p0+) 
 * Applying 4300_squashfs-3.0.patch (-p0+) 
 * Applying 4400_speakup-20060103.patch (-p0+) 
 * Applying 4401_speakup-highlight-tracking-amd64.patch (-p0+) 
 * Applying 4405_alpha-sysctl-uac.patch (-p0+) 


!! In 2.6.15 kernel ALL WORK.

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

^ permalink raw reply

* Linux kernel 2.6.16.7 released
From: Linux Kernel Distribution System @ 2006-04-17 22:28 UTC (permalink / raw)
  To: linux-kernel-announce

Linux kernel version 2.6.16.7 has been released.  It is available from:

Patch:		ftp://ftp.kernel.org/pub/linux/kernel/v2.6/patch-2.6.16.7.bz2
Full source:	ftp://ftp.kernel.org/pub/linux/kernel/v2.6/linux-2.6.16.7.tar.bz2

Sizes in bytes			Compressed	Uncompressed
------------------------------------------------------------
Patch                                25608             90975
Full source                       40843068         233943040

-----------------------------------------------------------------------------
 This is an automatically generated message.  To unsubscribe from this list,
 please send a message to majordomo@vger.kernel.org containing
 the line:

   unsubscribe linux-kernel-announce <your_email_address>

 ... where <your_email_address> is the email address you are receiving
     this message at.
-----------------------------------------------------------------------------

The following files were changed in this release:

 arch/m32r/lib/getuser.S                         |   88 -------
 arch/m32r/lib/putuser.S                         |   84 -------
 b/Makefile                                      |    2 
 b/arch/alpha/kernel/setup.c                     |   17 +
 b/arch/alpha/kernel/smp.c                       |    8 
 b/arch/i386/kernel/cpu/cpufreq/Kconfig          |    1 
 b/arch/i386/kernel/cpu/cpufreq/p4-clockmod.c    |    2 
 b/arch/i386/kernel/cpu/cpufreq/speedstep-smi.c  |    4 
 b/arch/i386/kernel/dmi_scan.c                   |    2 
 b/arch/m32r/kernel/m32r_ksyms.c                 |    4 
 b/arch/m32r/kernel/setup.c                      |   12 -
 b/arch/m32r/kernel/smpboot.c                    |   19 -
 b/arch/m32r/lib/Makefile                        |    4 
 b/arch/powerpc/kernel/pci_64.c                  |    1 
 b/arch/powerpc/kernel/setup_64.c                |   10 
 b/arch/powerpc/kernel/signal_64.c               |    2 
 b/arch/x86_64/kernel/entry.S                    |   28 --
 b/drivers/base/cpu.c                            |    2 
 b/drivers/base/firmware_class.c                 |    6 
 b/drivers/base/node.c                           |    2 
 b/drivers/block/cciss.c                         |   98 ++++----
 b/drivers/char/Kconfig                          |    1 
 b/drivers/char/tlclk.c                          |   37 +--
 b/drivers/edac/Kconfig                          |    2 
 b/drivers/ieee1394/sbp2.c                       |   32 +-
 b/drivers/md/dm.c                               |   45 ++--
 b/drivers/media/video/Kconfig                   |    1 
 b/drivers/media/video/tuner-types.c             |    4 
 b/drivers/net/irda/irda-usb.c                   |    5 
 b/drivers/net/sky2.c                            |    4 
 b/drivers/net/sky2.h                            |    1 
 b/drivers/net/wireless/Kconfig                  |    5 
 b/drivers/net/wireless/hostap/hostap_80211_tx.c |    2 
 b/drivers/net/wireless/ipw2200.c                |    5 
 b/drivers/pcmcia/ds.c                           |    2 
 b/drivers/scsi/sata_mv.c                        |    7 
 b/drivers/usb/core/message.c                    |   12 -
 b/drivers/usb/host/ehci-sched.c                 |   11 
 b/drivers/usb/serial/console.c                  |    2 
 b/drivers/usb/storage/Kconfig                   |    3 
 b/drivers/video/cfbimgblt.c                     |    2 
 b/drivers/video/i810/i810_main.c                |    2 
 b/fs/9p/vfs_inode.c                             |    3 
 b/fs/cifs/cifsencrypt.c                         |   36 ++-
 b/fs/ext3/resize.c                              |    1 
 b/fs/fuse/file.c                                |    8 
 b/fs/nfsd/nfs3proc.c                            |    2 
 b/fs/nfsd/nfs4proc.c                            |    2 
 b/fs/nfsd/nfsproc.c                             |    2 
 b/fs/partitions/check.c                         |    5 
 b/fs/proc/proc_misc.c                           |    2 
 b/fs/proc/vmcore.c                              |    4 
 b/fs/sysfs/dir.c                                |    1 
 b/fs/sysfs/file.c                               |    2 
 b/fs/sysfs/inode.c                              |    6 
 b/fs/sysfs/symlink.c                            |    1 
 b/fs/xfs/linux-2.6/xfs_aops.c                   |    2 
 b/fs/xfs/linux-2.6/xfs_iops.c                   |    3 
 b/include/asm-m32r/smp.h                        |    3 
 b/include/asm-m32r/uaccess.h                    |  266 ++++++++++--------------
 b/include/asm-powerpc/floppy.h                  |    5 
 b/include/linux/cpu.h                           |    2 
 b/include/linux/fb.h                            |    2 
 b/include/linux/mm.h                            |    5 
 b/include/linux/page-flags.h                    |    8 
 b/include/linux/proc_fs.h                       |    2 
 b/include/linux/raid/raid1.h                    |    2 
 b/include/linux/rtc.h                           |    4 
 b/include/net/ip.h                              |    1 
 b/ipc/shm.c                                     |    2 
 b/kernel/exec_domain.c                          |    1 
 b/kernel/fork.c                                 |    2 
 b/kernel/power/process.c                        |    3 
 b/kernel/ptrace.c                               |    7 
 b/kernel/sched.c                                |    9 
 b/kernel/signal.c                               |    6 
 b/kernel/sys.c                                  |   14 +
 b/mm/madvise.c                                  |    3 
 b/mm/page_alloc.c                               |   31 +-
 b/net/atm/clip.c                                |   42 ++-
 b/net/bridge/br_netfilter.c                     |   13 -
 b/net/core/sock.c                               |    5 
 b/net/ipv4/fib_trie.c                           |   12 -
 b/net/ipv4/ip_output.c                          |   12 -
 b/net/ipv4/netfilter/ip_conntrack_netlink.c     |    2 
 b/net/netfilter/nf_conntrack_netlink.c          |    2 
 b/security/keys/key.c                           |    4 
 b/security/keys/keyring.c                       |    1 
 b/sound/isa/opti9xx/opti92x-ad1848.c            |    6 
 b/sound/pci/hda/patch_realtek.c                 |    2 
 90 files changed, 521 insertions(+), 619 deletions(-)


^ permalink raw reply

* Re: VPN module
From: Erich Schubert @ 2006-04-17 22:23 UTC (permalink / raw)
  To: Christopher J. PeBenito; +Cc: Petre Rodan, SE Linux
In-Reply-To: <1145045255.8881.12.camel@sgc.columbia.tresys.com>

Hi Christopher,
Two more issues with openvpn:
avc:  denied  { sys_tty_config } for  pid=2716 comm="sh" capability=26
scontext=system_u:system_r:openvpn_t:s0
tcontext=system_u:system_r:openvpn_t:s0 tclass=capability
avc:  denied  { search } for  pid=2717 comm="openvpn" name="tun0"
dev=sysfs ino=8054 scontext=system_u:system_r:openvpn_t:s0
tcontext=system_u:object_r:sysfs_t:s0 tclass=dir

The first looks pretty straighforward, I don't know about sysfs handling
in SELinux...

best regards,
Erich Schubert
-- 
   erich@(vitavonni.de|debian.org)    --    GPG Key ID: 4B3A135C    (o_
     This one's tricky. You have to use imaginary numbers, like     //\
                      eleventeen... --- Hobbes                      V_/_
          Ein schöner Moment leuchtet das Leben hindurch.



--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

^ permalink raw reply

* Re: Slab corruption after unloading a module
From: zhiyi huang @ 2006-04-17 22:23 UTC (permalink / raw)
  To: Arjan van de Ven; +Cc: Andrey Borzenkov, linux-kernel
In-Reply-To: <1145311760.2847.97.camel@laptopd505.fenrus.org>

> On Tue, 2006-04-18 at 10:08 +1200, zhiyi huang wrote:
>>>
>>>> There was no problem if I just load and unload the module. But if I
>>>> write to the device using "ls > /dev/temp" and then unload the
>>>> module, I would get slab corruption.
>>>
>>> you return different value as what has really been consumed:
>>>
>>>>         if (*f_pos + count > MAX_DSIZE)
>>>>                 count1 = MAX_DSIZE - *f_pos;
>>>>
>>>>         if (copy_from_user (temp_dev->data+*f_pos, buf, count1)) {
>
> this is still buggy.. what if f_pos is huge???

Well, if you look at my program, the complete code is like this:

         if (*f_pos > MAX_DSIZE)
                 goto wrap_up;
         if (*f_pos + count > MAX_DSIZE)
                 count1 = MAX_DSIZE - *f_pos;

         if (copy_from_user (temp_dev->data+*f_pos, buf, count1)) {


^ permalink raw reply

* Re: RAID5 recovery trouble, bd_claim failed?
From: Nathanial Byrnes @ 2006-04-17 22:21 UTC (permalink / raw)
  To: Neil Brown; +Cc: linux-raid
In-Reply-To: <17476.3083.900753.898632@cse.unsw.edu.au>

Unfortunately nothing changed. 


On Tue, 2006-04-18 at 07:43 +1000, Neil Brown wrote:
> On Monday April 17, nate@qabal.org wrote:
> > Hi Neil, List,
> >     Am I just out of luck? Perhaps a full reboot? Something else?
> >     Thanks,
> >     Nate
> 
> Reboot and try again seems like the best bet at this stage.
> 
> NeilBrown
> -
> To unsubscribe from this list: send the line "unsubscribe linux-raid" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> !DSPAM:44440c1a90901937570534!
> 


^ permalink raw reply

* Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks
From: Serge E. Hallyn @ 2006-04-17 19:47 UTC (permalink / raw)
  To: James Morris
  Cc: Serge E. Hallyn, Stephen Smalley, casey, linux-security-module,
	linux-kernel, fireflier-devel, David Safford
In-Reply-To: <Pine.LNX.4.64.0604171528340.17923@d.namei>

Quoting James Morris (jmorris@namei.org):
> On Mon, 17 Apr 2006, Serge E. Hallyn wrote:
> 
> > Hopefully a new version of evm+slim+ima will be ready for distribution
> > soon.
> 
> Why are you still trying to introduce yet another access control model 
> into the kernel, when SELinux is already there?

Well actually I'm really not much involved.

> Last I recall on this issue, we asked if you could look at providing 
> integrity measurement as a distinct API, and integrity control as either 
> integrated with SELinux or a distinct component which SELinux could use.

And those are what I believe the next patchset will provide.

-serge

^ permalink raw reply

* Re: VPN module
From: Erich Schubert @ 2006-04-17 22:18 UTC (permalink / raw)
  To: Christopher J. PeBenito; +Cc: Petre Rodan, SE Linux
In-Reply-To: <1145045255.8881.12.camel@sgc.columbia.tresys.com>

Hello Christopher,
> Merged.  One fix, I moved the initrc_t reading openvpn_etc_t to the init
> module.

policy/modules/kernel/corenetwork.te.in currently has port 5000 for
OpenVPN.

Port 1194 is the official IANA port for OpenVPN and should be added, too
(or maybe even instead of port 5000, which is more likely to conflict
with custom applications IMHO)

best regards,
Erich Schubert
-- 
     erich@(vitavonni.de|debian.org)    --    GPG Key ID: 4B3A135C    (o_
 Why waste time learning, when ignorance is instantaneous? --- Calvin //\
   Wenn zwei gute Freunde sind, die einander kennen, Sonn' und Mond   V_/_
     begegnen sich, ehe sie sich trennen. --- Clemens von Brentano


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

^ permalink raw reply

* Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks
From: Gerrit Huizenga @ 2006-04-17 22:15 UTC (permalink / raw)
  To: James Morris
  Cc: Serge E. Hallyn, Stephen Smalley, casey, linux-security-module,
	linux-kernel, fireflier-devel
In-Reply-To: <Pine.LNX.4.64.0604171528340.17923@d.namei>


On Mon, 17 Apr 2006 15:31:08 EDT, James Morris wrote:
> On Mon, 17 Apr 2006, Serge E. Hallyn wrote:
> 
> > Hopefully a new version of evm+slim+ima will be ready for distribution
> > soon.
> 
> Why are you still trying to introduce yet another access control model 
> into the kernel, when SELinux is already there?

I get the impression from customers that SELinux is so painful to
configure correctly that most of them disable it.  In theory, LSM +
something like AppArmour provides a much simpler security model for
normal human beings who want some level of configuration.  Also,
the current SELinux config in RH is starting to have a measureable
performance impact.  I'm not sure this particular battle of the
security models is quite over from a real user perspective.

gerrit

^ permalink raw reply

* Re: [Alsa-devel] Re: [linuxsh-dev] [PATCH] ALSA driver for Yamaa AICA on Sega Dreamcast
From: Lee Revell @ 2006-04-17 22:15 UTC (permalink / raw)
  To: Christoph Hellwig
  Cc: Adrian McMenamin, Paul Mundt, Alsa-devel, linux-sh, LKML
In-Reply-To: <20060417220512.GA16119@infradead.org>

On Mon, 2006-04-17 at 23:05 +0100, Christoph Hellwig wrote:
> On Mon, Apr 17, 2006 at 05:47:15PM -0400, Lee Revell wrote:
> > On Mon, 2006-04-17 at 21:00 +0100, Adrian McMenamin wrote:
> > > But I am happy to change it.
> > > 
> > > 
> > 
> > Please don't - when adding code to a subsystem with different
> > conventions than mainline the FAQ says to follow the subsystem
> > conventions.
> 
> Nope.  Alsa needs to gradually converted from something that looks like
> cat puke to normal kernel style.  Every new driver that's written properly
> helps.

OK thanks.  I was certain I saw this in the FAQ at some point but now I
can't find it.

Lee

^ permalink raw reply

* Re: Time to remove LSM (was Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks)
From: Arjan van de Ven @ 2006-04-17 22:10 UTC (permalink / raw)
  To: Chris Wright
  Cc: Emily Ratliff, James Morris, Christoph Hellwig, Andrew Morton,
	Stephen Smalley, T?r?k Edwin, linux-security-module, linux-kernel,
	Linus Torvalds
In-Reply-To: <20060417220713.GF3615@sorel.sous-sol.org>

On Mon, 2006-04-17 at 15:07 -0700, Chris Wright wrote:
> * Emily Ratliff (ejratl@gmail.com) wrote:
> > On 4/17/06, Chris Wright <chrisw@sous-sol.org> wrote:> Based on the
> > discussions we had last year, I think the fair date would
> > > be August not June.
> > Was the one year deadline announced on LKML or the security module mailing
> > list or anywhere that someone who did not attend OLS might have had an
> > opportunity to hear about it? In searching the archives, I can't find this
> > announcement.
> 
> I thought there was something written about it, but I can't find it now.

jamesm posted the LSM mailings he did about this...
which were from may 2005



^ permalink raw reply

* Re: Slab corruption after unloading a module
From: Arjan van de Ven @ 2006-04-17 22:09 UTC (permalink / raw)
  To: zhiyi huang; +Cc: Andrey Borzenkov, linux-kernel
In-Reply-To: <F77F3A5F-D618-4F7F-A266-14391E5DD739@cs.otago.ac.nz>

On Tue, 2006-04-18 at 10:08 +1200, zhiyi huang wrote:
> >
> >> There was no problem if I just load and unload the module. But if I
> >> write to the device using "ls > /dev/temp" and then unload the
> >> module, I would get slab corruption.
> >
> > you return different value as what has really been consumed:
> >
> >>         if (*f_pos + count > MAX_DSIZE)
> >>                 count1 = MAX_DSIZE - *f_pos;
> >>
> >>         if (copy_from_user (temp_dev->data+*f_pos, buf, count1)) {

this is still buggy.. what if f_pos is huge???



^ permalink raw reply

* Re: [Bridge] Re: No UDP NFS over bridges in Linux 2.6.16.x?
From: Chris Rankin @ 2006-04-17 22:09 UTC (permalink / raw)
  To: Patrick McHardy; +Cc: Stephen Hemminger, nfs, bridge
In-Reply-To: <4443DD74.80101@trash.net>

--- Patrick McHardy <kaber@trash.net> wrote:
> >>[patch 06/22] NETFILTER: Fix fragmentation issues with bridge netfilt=
er

Thanks, this patch fixes the "NFS via UDP" problem.

Cheers,
Chris



	=09
___________________________________________________________=20
Yahoo! For Good - Sponsor a London Marathon runner - http://uk.promotions=
.yahoo.com/charity/london-marathon


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting langua=
ge
that extends applications into web and mobile media. Attend the live webc=
ast
and join the prime developer group breaking into this new coding territor=
y!
http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D110944&bid=3D241720&dat=3D=
121642
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

^ permalink raw reply

* Fw: [Bug 6402] New: KERNEL 2.6.16-rX (Gentoo) && PPPD && SNAT
From: Stephen Hemminger @ 2006-04-17 22:08 UTC (permalink / raw)
  To: linux-ppp



Begin forwarded message:

Date: Mon, 17 Apr 2006 14:56:59 -0700
From: bugme-daemon@bugzilla.kernel.org
To: shemminger@osdl.org
Subject: [Bug 6402] New: KERNEL 2.6.16-rX (Gentoo) && PPPD && SNAT


http://bugzilla.kernel.org/show_bug.cgi?idd02

           Summary: KERNEL 2.6.16-rX (Gentoo) && PPPD && SNAT
    Kernel Version: 2.6.16.ALL
            Status: NEW
          Severity: high
             Owner: shemminger@osdl.org
         Submitter: slavon@bigtelecom.ru


After start download file its stop after 4-10 mb and network is down.

Interface ppp0 is UP.
No new dmeseg or debug of syslog

try to ping ppp client:

slavon ~ # ping 192.168.0.2
PING 192.168.0.2 (192.168.0.2) 56(84) bytes of data.
ping: sendmsg: No buffer space available
ping: sendmsg: No buffer space available
ping: sendmsg: No buffer space available
ping: sendmsg: No buffer space available
ping: sendmsg: No buffer space available
ping: sendmsg: No buffer space available
ping: sendmsg: No buffer space available
ping: sendmsg: No buffer space available
ping: sendmsg: No buffer space available
ping: sendmsg: No buffer space available
ping: sendmsg: No buffer space available
ping: sendmsg: No buffer space available
ping: sendmsg: No buffer space available

#ifconfig ppp0
ppp0      Link encap:Point-to-Point Protocol
          inet addr:192.168.0.1  P-t-P:192.168.0.2  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1396  Metric:1
          RX packets:1648 errors:0 dropped:0 overruns:0 frame:0
          TX packets:2407 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:3
          RX bytes:75765 (73.9 Kb)  TX bytes:3242633 (3.0 Mb)

#iptables-save
*nat
:PREROUTING ACCEPT [6826:411515]
:POSTROUTING ACCEPT [11117:531811]
:OUTPUT ACCEPT [11118:531895]
-A POSTROUTING -s 192.168.0.0/255.255.255.0 -j SNAT --to-source XXX.XXX.XXX.XXX
COMMIT

slavon ~ # pppd --version
pppd version 2.4.3

slavon ~ # pptpd --version
pptpd v1.3.1

I try it in 3 Computers 2 - x86 and 1 - x86-64 - All have this trouble

its gentoo patches for kernel

 * Applying 1000_linux-2.6.16.1.patch (-p0+) 
 * Applying 1001_linux-2.6.16.2.patch (-p0+) 
 * Applying 1002_linux-2.6.16.3.patch (-p0+) 
 * Applying 1003_linux-2.6.16.4.patch (-p0+) 
 * Applying 1700_sparc-obp64-naming.patch (-p0+) 
 * Applying 1705_sparc-U1-hme-lockup.patch (-p0+) 
 * Applying 1710_sparc-sparsemem.patch (-p0+) 
 * Applying 1715_ppc32-crosscc-ssp.patch (-p0+) 
 * Applying 2400_sky2-1.1.patch (-p0+) 
 * Applying 2405_skge-1.5.patch (-p0+) 
 * Applying 2600_input-mod-devicetable.patch (-p0+) 
 * Applying 4000_deprecate-sk98lin.patch (-p0+) 
 * Applying 4100_libata-enable-atapi.patch (-p0+) 
 * Applying 4105_dm-bbr.patch (-p0+) 
 * Applying 4110_promise-pdc2037x.patch (-p0+) 
 * Applying 4200_fbsplash-0.9.2-r5.patch (-p0+) 
 * Applying 4205_vesafb-tng-1.0-rc1-r3.patch (-p0+) 
 * Applying 4300_squashfs-3.0.patch (-p0+) 
 * Applying 4400_speakup-20060103.patch (-p0+) 
 * Applying 4401_speakup-highlight-tracking-amd64.patch (-p0+) 
 * Applying 4405_alpha-sysctl-uac.patch (-p0+) 


!! In 2.6.15 kernel ALL WORK.

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

^ permalink raw reply

* Re: Time to remove LSM (was Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks)
From: Chris Wright @ 2006-04-17 22:07 UTC (permalink / raw)
  To: Emily Ratliff
  Cc: Chris Wright, James Morris, Christoph Hellwig, Andrew Morton,
	Stephen Smalley, T?r?k Edwin, linux-security-module, linux-kernel,
	Linus Torvalds
In-Reply-To: <2e00cdfd0604171437g1d6c6923w5db82f317ed0f56@mail.gmail.com>

* Emily Ratliff (ejratl@gmail.com) wrote:
> On 4/17/06, Chris Wright <chrisw@sous-sol.org> wrote:> Based on the
> discussions we had last year, I think the fair date would
> > be August not June.
> Was the one year deadline announced on LKML or the security module mailing
> list or anywhere that someone who did not attend OLS might have had an
> opportunity to hear about it? In searching the archives, I can't find this
> announcement.

I thought there was something written about it, but I can't find it now.

thanks,
-chris

^ permalink raw reply

* Re: Slab corruption after unloading a module
From: zhiyi huang @ 2006-04-17 22:08 UTC (permalink / raw)
  To: Andrey Borzenkov; +Cc: linux-kernel
In-Reply-To: <200604161443.21653.arvidjaar@mail.ru>

>
>> There was no problem if I just load and unload the module. But if I
>> write to the device using "ls > /dev/temp" and then unload the
>> module, I would get slab corruption.
>
> you return different value as what has really been consumed:
>
>>         if (*f_pos + count > MAX_DSIZE)
>>                 count1 = MAX_DSIZE - *f_pos;
>>
>>         if (copy_from_user (temp_dev->data+*f_pos, buf, count1)) {
>>                 rv = -EFAULT;
>>                 goto wrap_up;
>>         }
>>         up (&temp_dev->sem);
>>         *f_pos += count1;
>>         return count;
>
> may be it confuses the rest of kernel a bit?

I did this intentionally. Since my baby device buffer is fixed size,  
I can't overflow the buffer. What I do is to cheat the application  
(by pretending the bytes requested are copied to the device) so that  
the application will be happy and do not hang on to send to the  
device again and again. After all it is a test module for char device.
Nevertheless, I don't think this cheating has something to do with  
the slab corruption.

^ permalink raw reply

* Re: [Alsa-devel] Re: [linuxsh-dev] [PATCH] ALSA driver for Yamaa AICA on Sega Dreamcast
From: Christoph Hellwig @ 2006-04-17 22:05 UTC (permalink / raw)
  To: Lee Revell; +Cc: Adrian McMenamin, Paul Mundt, Alsa-devel, linux-sh, LKML
In-Reply-To: <1145310435.16138.83.camel@mindpipe>

On Mon, Apr 17, 2006 at 05:47:15PM -0400, Lee Revell wrote:
> On Mon, 2006-04-17 at 21:00 +0100, Adrian McMenamin wrote:
> > But I am happy to change it.
> > 
> > 
> 
> Please don't - when adding code to a subsystem with different
> conventions than mainline the FAQ says to follow the subsystem
> conventions.

Nope.  Alsa needs to gradually converted from something that looks like
cat puke to normal kernel style.  Every new driver that's written properly
helps.

^ permalink raw reply


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.