Re: Out of tree kernel images / Lustre image
dann frazier [EMAIL PROTECTED] writes: On Wed, Aug 02, 2006 at 11:06:23AM +, Bastian Blank wrote: If you want to be correct, you can't use linux-source. So the security team have to support another kernel source. A kernel-patch package that applies on top of the kernel team's linux-source is the approach I'd suggest. But to reiterate, if something in a kernel update causes the patch to no longer apply, I would want to have a reliable contact (hopefully 2 people) whom we can call upon for assistance. A Build-Depends on the linux-source or linux-tree will be there. Lustre already comes as patch set to the kernel so there is 0 reason to fork/copy the linux source. I believe security updates should also be less of a problem than actual kernel updates. They don't tend to mess around with the VFS/etx3 code overly much. But as I mentioned, now we are two people needing this for work so there should always be someone available. I guess we can build an image and see how well this works out till etch+1 comes out. I'm not sure if I want this in etch/stable. Having it in unstbale for the time being would be fine with me. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Out of tree kernel images / Lustre image
Dropping security. Alastair McKinstry [EMAIL PROTECTED] writes: dann frazier wrote: On Wed, Aug 02, 2006 at 11:06:23AM +, Bastian Blank wrote: If you want to be correct, you can't use linux-source. So the security team have to support another kernel source. A kernel-patch package that applies on top of the kernel team's linux-source is the approach I'd suggest. But to reiterate, if something in a kernel update causes the patch to no longer apply, I would want to have a reliable contact (hopefully 2 people) whom we can call upon for assistance. How about the mISDN kernel modules as a format? I.e. preparing both patches (ie linux-patch-lustre.deb) that build on top of the kernel(s) (vanilla and debian) and modules that install direct on the relevant kernels shipped in etch? This is what I am currently working on. Regards Alastair McKinstry A linux-patch-lustre.deb is a given for me. We do compile custom kernels with a few other patches locally so I will always need the patch. I'm not sure lustre modules for the stock (lustre unpatched) kernels are of much use though. Have you tried a patchless lustre setup? I've seen a few mails about it on the lustre ML but what I saw from skimming over them the performance and stability isn't the best. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Out of tree kernel images / Lustre image
dann frazier wrote: On Wed, Aug 02, 2006 at 11:06:23AM +, Bastian Blank wrote: If you want to be correct, you can't use linux-source. So the security team have to support another kernel source. A kernel-patch package that applies on top of the kernel team's linux-source is the approach I'd suggest. But to reiterate, if something in a kernel update causes the patch to no longer apply, I would want to have a reliable contact (hopefully 2 people) whom we can call upon for assistance. How about the mISDN kernel modules as a format? I.e. preparing both patches (ie linux-patch-lustre.deb) that build on top of the kernel(s) (vanilla and debian) and modules that install direct on the relevant kernels shipped in etch? This is what I am currently working on. Regards Alastair McKinstry -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Out of tree kernel images / Lustre image
On Wed, Aug 02, 2006 at 04:47:46PM -0600, dann frazier wrote: On Wed, Aug 02, 2006 at 11:06:23AM +, Bastian Blank wrote: If you want to be correct, you can't use linux-source. So the security team have to support another kernel source. A kernel-patch package that applies on top of the kernel team's linux-source is the approach I'd suggest. But to reiterate, if something in a kernel update causes the patch to no longer apply, I would want to have a reliable contact (hopefully 2 people) whom we can call upon for assistance. If the lustre thingy is so important, why not add them as another 'subarch' (do we already have a better name for those ? 'variant' maybe or something), in the same way the vserver or xen images are done ? This would mean for the lustre-folk to join the kernel team though, and an engagement from them to stay active and so on. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Out of tree kernel images / Lustre image
On Tue, Aug 01, 2006 at 05:59:43PM +0200, Goswin von Brederlow wrote: Now to my question. Lustre needs a specialy patched kernel Why? Ah I see, they don't know how to abstract that and get informations how to do that properly from upstream. and builds a ton (~100MB uncompressed) of kernel modules and support binaries. How should that be handled? Modules needs to be seperated from binaries. Would it be OK for lustre to build its own out-of-tree kernel image and modules? It is the same than fai-kernels which is scheduled for removal. Or would that be too much extra work for the security team to support? If you want to be correct, you can't use linux-source. So the security team have to support another kernel source. What is the policy on this kind of thing? As the kernel team to provide them. But with this flacky patchset, this won't work. Bastian -- The heart is not a logical organ. -- Dr. Janet Wallace, The Deadly Years, stardate 3479.4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Out of tree kernel images / Lustre image
dann frazier [EMAIL PROTECTED] writes: How big is the patchset these days, and what does it touch? I haven't messed with Lustre since 2.4.20 where the core patches were mostly adding intents, etc - stuff that I thought had been merged upstream in 2.6. There still is a lot of patching in the VFS stuff for intents and extends for the kernel as well as the patches to make ext3 into ldiskfs for the lustre modules. Bits and peaces have been merged but a lot remains to be in ext4 I believe. Lets look at the kernel patches: % diff -Nurd linux-2.6.15.7 linux-2.6.15.7.vanilla.lustre | wc 3517 12915 106602 % diff -Nurd linux-2.6.15.7 linux-2.6.15.7.vanilla.lustre | grep ^--- | cut -d -f2 | cut -f1 linux-2.6.15.7/Documentation/filesystems/ext2.txt linux-2.6.15.7/arch/i386/kernel/smpboot.c linux-2.6.15.7/block/ll_rw_blk.c linux-2.6.15.7/drivers/scsi/Kconfig linux-2.6.15.7/drivers/scsi/scsi_proc.c linux-2.6.15.7/drivers/scsi/sd.c linux-2.6.15.7/fs/block_dev.c linux-2.6.15.7/fs/cifs/dir.c linux-2.6.15.7/fs/dcache.c linux-2.6.15.7/fs/exec.c linux-2.6.15.7/fs/filesystems.c linux-2.6.15.7/fs/inode.c linux-2.6.15.7/fs/jbd/checkpoint.c linux-2.6.15.7/fs/jbd/commit.c linux-2.6.15.7/fs/jbd/journal.c linux-2.6.15.7/fs/jbd/transaction.c linux-2.6.15.7/fs/namei.c linux-2.6.15.7/fs/namespace.c linux-2.6.15.7/fs/nfs/dir.c linux-2.6.15.7/fs/nfs/nfs4proc.c linux-2.6.15.7/fs/open.c linux-2.6.15.7/fs/stat.c linux-2.6.15.7/include/asm-i386/thread_info.h linux-2.6.15.7/include/linux/dcache.h linux-2.6.15.7/include/linux/fs.h linux-2.6.15.7/include/linux/jbd.h linux-2.6.15.7/include/linux/lustre_version.h linux-2.6.15.7/include/linux/mm.h linux-2.6.15.7/include/linux/mount.h linux-2.6.15.7/include/linux/namei.h linux-2.6.15.7/include/linux/skbuff.h linux-2.6.15.7/include/net/tcp.h linux-2.6.15.7/kernel/exit.c linux-2.6.15.7/kernel/sched.c linux-2.6.15.7/mm/filemap.c linux-2.6.15.7/mm/truncate.c linux-2.6.15.7/net/core/dev.c linux-2.6.15.7/net/core/skbuff.c linux-2.6.15.7/net/ipv4/tcp.c linux-2.6.15.7/net/unix/af_unix.c Still some way to go to get this upstream. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Out of tree kernel images / Lustre image
On Wed, Aug 02, 2006 at 11:06:23AM +, Bastian Blank wrote: If you want to be correct, you can't use linux-source. So the security team have to support another kernel source. A kernel-patch package that applies on top of the kernel team's linux-source is the approach I'd suggest. But to reiterate, if something in a kernel update causes the patch to no longer apply, I would want to have a reliable contact (hopefully 2 people) whom we can call upon for assistance. -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Out of tree kernel images / Lustre image
On Tue, Aug 01, 2006 at 05:59:43PM +0200, Goswin von Brederlow wrote: Sorry, I hit the wrong button (send instead of save) so here we go again: Hi, I took over the ITP (237713) for Lustre from Andres Salomon and recently Alastair McKinstry also showed interest in this. Both of use use Lustre at work so there will be some paid time spend on keeping this current. Cool! Now to my question. Lustre needs a specialy patched kernel and builds a ton (~100MB uncompressed) of kernel modules and support binaries. How should that be handled? Would it be OK for lustre to build its own out-of-tree kernel image and modules? Or would that be too much extra work for the security team to support? I'm ok with maintaining it from a security perspective if it tracks the latest linux-source package and someone on your side is willing to help with Lustre-specific issues (patch conflicts with security fixes, lustre-specific security issues) throughout the lifetime of any stable release it enters. How big is the patchset these days, and what does it touch? I haven't messed with Lustre since 2.4.20 where the core patches were mostly adding intents, etc - stuff that I thought had been merged upstream in 2.6. -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
