* Re: linux-next: Tree for January 2
From: Rafael J. Wysocki @ 2009-01-02 14:08 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linux-next, LKML, Greg KH
In-Reply-To: <20090102203303.f314a99a.sfr@canb.auug.org.au>
On Friday 02 January 2009, Stephen Rothwell wrote:
> Hi all,
>
> Changes since 20081231:
>
> Removed tree:
> boot-params (became 2.6.30 material)
>
> Dropped trees (temporarily):
> driver-core (build problem)
Can you please tell me what exactly the build problem with the driver-core tree
is? Maybe I can fix it.
Thanks,
Rafael
^ permalink raw reply
* Re: linux-next: manual merge of the device-mapper tree
From: Alasdair G Kergon @ 2009-01-02 13:17 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linux-next, Ingo Molnar, Kiyoshi Ueda
In-Reply-To: <20081231012754.GC11060@agk.fab.redhat.com>
On Wed, Dec 31, 2008 at 01:27:54AM +0000, Alasdair G Kergon wrote:
> Ta - I'll sort it when I rebase after the Xmas/New Year break.
Rebased.
Alasdair
--
agk@redhat.com
^ permalink raw reply
* Re: linux-next: manual merge of the rr_cpumask tree
From: Ingo Molnar @ 2009-01-02 12:52 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: Rusty Russell, linux-next, Mike Travis
In-Reply-To: <20090102095906.GI1975@elte.hu>
* Ingo Molnar <mingo@elte.hu> wrote:
>
> * Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> > Hi Rusty,
> >
> > Today's linux-next merge of the rr_cpumask tree got a conflict in
> > arch/x86/kernel/io_apic.c between commit
> > 22f65d31b25a320a5246592160bcb102d2791c45 ("x86: Update io_apic.c to use
> > new cpumask API") from the cpus4096 tree and commit
> > 2ca1a615835d9f4990f42102ab1f2ef434e7e89c ("Merge branch 'master' of
> > git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6") (or
> > something - I suspect git has failed me a little here) from the
> > rr_cpumask tree.
> >
> > It is a bit of a train wreck :-)
> >
> > I have dropped the rr_cpumask tree for today and also the rr tree that
> > depends on it.
>
> hm, i'll work with Rusty on fixing that - you should really not be
> seeing conflicts on that level.
ok, i think i got it all sorted out - there will be a new cpus4096 tree
later today (if it passes the tests) that should merge cleanly with
Rusty's latest.
Ingo
^ permalink raw reply
* Re: linux-next: ftrace tree build failure
From: Ingo Molnar @ 2009-01-02 11:16 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linux-next
In-Reply-To: <20090102212242.13f9007e.sfr@canb.auug.org.au>
* Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi Ingo,
>
> On Fri, 2 Jan 2009 10:14:56 +0100 Ingo Molnar <mingo@elte.hu> wrote:
> >
> > this has been fixed already a few days ago (if you google for the build
> > failure string it will send you straight to the fix patch) - i just didnt
> > push it out to the -next branches yet during the hollidays. (did that now)
>
> Thanks.
>
> > Generally if you see a problem with our trees you can check whether an
> > issue is still present in tip/master:
> >
> > http://people.redhat.com/mingo/tip.git/README
>
> I'll try to remember ...
>
> [I wish you had stopped there]
>
> > before duplicating fixing effort and reporting it as a genuine issue -
>
> It broke a linux-next build - just how genuine does an issue have to be?
as genuine i mean 'new, unknown issue' - not an issue that has been
reported to lkml already by testers and has been fixed already.
The thing is, i wouldnt have said that had you not said:
> > [...] A bit more care, please.
i can do without such suggestions in the merge window really - it looked
rather condescending to me. A lkml search or a trivial google for the
build failure pattern would have given you a working patch.
Ingo
^ permalink raw reply
* Re: linux-next: ftrace tree build failure
From: Stephen Rothwell @ 2009-01-02 10:22 UTC (permalink / raw)
To: Ingo Molnar; +Cc: linux-next
In-Reply-To: <20090102091456.GB30018@elte.hu>
[-- Attachment #1: Type: text/plain, Size: 1961 bytes --]
Hi Ingo,
On Fri, 2 Jan 2009 10:14:56 +0100 Ingo Molnar <mingo@elte.hu> wrote:
>
> this has been fixed already a few days ago (if you google for the build
> failure string it will send you straight to the fix patch) - i just didnt
> push it out to the -next branches yet during the hollidays. (did that now)
Thanks.
> Generally if you see a problem with our trees you can check whether an
> issue is still present in tip/master:
>
> http://people.redhat.com/mingo/tip.git/README
I'll try to remember ...
[I wish you had stopped there]
> before duplicating fixing effort and reporting it as a genuine issue -
It broke a linux-next build - just how genuine does an issue have to be?
Even if I knew you had already fixed it, I would still have reported it
(although saying where I got the fix from) so that others know why I have
had to apply a patch.
> especially in a busy timeframe like the merge window when the _next_ merge
> window is the least of our worries.
During the merge window, linux-next is not concerned with the _next_
merge window (as my previous reminder to people spelt out), but very much
with the current merge window. What you don't seem to realise is that
others use linux-next during the merge window to do integration testing
after fixing up their trees to cope with stuff that Linus has already
merged (in order - as much as possible - to not break Linus' tree). So
when you break the linux-next tree, you make life harder for them.
So, how much of your time would have been "wasted" remembering to put
that fix into the linux-next branch compared to my time and the time of
others?
And don't bother responding (especially privately) I don't need the
aggravation. If you feel a need to reply coming on, just delete this
email instead and pretend I didn't write it.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [BUG] next-20081231 - S390x kernel panics while bootup at init_sched_build_groups()
From: Heiko Carstens @ 2009-01-02 10:04 UTC (permalink / raw)
To: Kamalesh Babulal
Cc: Stephen Rothwell, linux-next, LKML, linux-s390, schwidefsky
In-Reply-To: <20081231160329.GC4268@linux.vnet.ibm.com>
On Wed, Dec 31, 2008 at 09:33:29PM +0530, Kamalesh Babulal wrote:
> next-2001231 kernel panic's on S390x box, while boot up
> cpu: 4 configured CPUs, 0 standby CPUs
> cpu: Processor 0 started, address 2, identification 20AB8A
> cpu: Processor 1 started, address 0, identification 00AB8A
> cpu: Processor 2 started, address 1, identification 10AB8A
> cpu: Processor 3 started, address 3, identification 30AB8A
> Brought up 4 CPUs
> Unable to handle kernel pointer dereference at virtual kernel address 0000000100
> 3fa000
> Oops: 003b Ã#1¨ SMP
> Modules linked in:
> CPU: 0 Not tainted 2.6.28-next-20081231-autotest #1
> Process swapper (pid: 1, task: 000000003fe80000, ksp: 000000003fe8ba78)
> Krnl PSW : 0704000180000000 0000000000035632 (init_sched_build_groups+0xae/0x4a4
> )
> R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:0 CC:0 PM:0 EA:3
> Krnl GPRS: 00000000003c27b0 00000001003fa278 0000000000000000 00000000003c2508
> 0000000000000000 000000000026f818 0000000000000000 0000000000000000
> 0000000000000000 000000003fe8be50 00000000ffffffff 000000003fe8bcf0
> Krnl Code: 0000000000035626: a7290000 lghi 00: HCPGSP2629I The virt
Seems to be fixed with linux-next from 2nd of January.
^ permalink raw reply
* Re: [BUILD-FAILURE] next-20081230 - S390 - tape drive fails to build with !CONFIG_BLOCK
From: Heiko Carstens @ 2009-01-02 10:01 UTC (permalink / raw)
To: Kamalesh Babulal
Cc: Stephen Rothwell, linux-next, LKML, linux-s390, schwidefsky
In-Reply-To: <20081231112132.GA4268@linux.vnet.ibm.com>
On Wed, Dec 31, 2008 at 04:51:32PM +0530, Kamalesh Babulal wrote:
> next-20081230 randconfig build fails on S390, with CONFIG_BLOCK=n
>
> Adding the dependency of CONFIG_BLOCK to CONFIG_S390_TAPE_BLOCK
>
> Signed-off-by: Kamalesh Babulal <kamalesh@linux.vnet.ibm.com
>
> --- a/drivers/s390/char/Kconfig
> +++ b/drivers/s390/char/Kconfig
> @@ -100,7 +100,7 @@ comment "S/390 tape interface support"
>
> config S390_TAPE_BLOCK
> bool "Support for tape block devices"
> - depends on S390_TAPE
> + depends on S390_TAPE && BLOCK
Thank you, added it to our patch queue.
^ permalink raw reply
* Re: linux-next: manual merge of the rr_cpumask tree
From: Ingo Molnar @ 2009-01-02 9:59 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: Rusty Russell, linux-next, Mike Travis
In-Reply-To: <20090102133557.0750cdbe.sfr@canb.auug.org.au>
* Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi Rusty,
>
> Today's linux-next merge of the rr_cpumask tree got a conflict in
> arch/x86/kernel/io_apic.c between commit
> 22f65d31b25a320a5246592160bcb102d2791c45 ("x86: Update io_apic.c to use
> new cpumask API") from the cpus4096 tree and commit
> 2ca1a615835d9f4990f42102ab1f2ef434e7e89c ("Merge branch 'master' of
> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6") (or
> something - I suspect git has failed me a little here) from the
> rr_cpumask tree.
>
> It is a bit of a train wreck :-)
>
> I have dropped the rr_cpumask tree for today and also the rr tree that
> depends on it.
hm, i'll work with Rusty on fixing that - you should really not be seeing
conflicts on that level.
Ingo
^ permalink raw reply
* linux-next: Tree for January 2
From: Stephen Rothwell @ 2009-01-02 9:33 UTC (permalink / raw)
To: linux-next; +Cc: LKML
[-- Attachment #1: Type: text/plain, Size: 7426 bytes --]
Hi all,
Changes since 20081231:
Removed tree:
boot-params (became 2.6.30 material)
Dropped trees (temporarily):
driver-core (build problem)
usb (depends on driver-core)
kvm (build problem)
rr_cpumask (complex conflict)
rr (depends on rr_cpumask)
semaphore-removal (due to unfixed conflicts against Linus' tree)
cpu_alloc (build problem)
audit (difficult conflicts)
staging (depends on usb)
Linus' tree lost its build fix.
The tip-core tree lost its conflict.
The ftrace tree gained a build failure for which I applied a temporary
patch.
The timers tree lost its conflict.
The nfsd tree lost its 2 conflicts.
The kvm tree gained a conflict against the x86 tree but still has a build
failure and so remains dropped.
The ocfs2 tree lost its conflict.
The rr_cpumask tree gained a conflict against the timers tree and a
comples one against the cpus4096 tree and was dropped.
The kmemcheck tree lost its 3 conflicts (but inherited one from another
tree).
The cputime tree lost its conflict.
----------------------------------------------------------------------------
I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/sfr/linux-next.git
(patches at
http://www.kernel.org/pub/linux/kernel/people/sfr/linux-next/). If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one. You should use "git fetch" as mentioned in the FAQ on the wiki
(see below).
You can see which trees have been included by looking in the Next/Trees
file in the source. There are also quilt-import.log and merge.log files
in the Next directory. Between each merge, the tree was built with
a ppc64_defconfig for powerpc and an allmodconfig for x86_64. After the
final fixups (if any), it is also built with powerpc allnoconfig,
44x_defconfig and allyesconfig (minus CONFIG_PROFILE_ALL_BRANCHES) and
i386, sparc and sparc64 defconfig.
Below is a summary of the state of the merge.
We are up to 131 trees (counting Linus' and 15 trees of patches pending for
Linus' tree), more are welcome (even if they are currently empty).
Thanks to those who have contributed, and to those who haven't, please do.
Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next . If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.
Thanks to Jan Dittmer for adding the linux-next tree to his build tests
at http://l4x.org/k/ , the guys at http://test.kernel.org/ and Randy
Dunlap for doing many randconfig builds.
There is a wiki covering stuff to do with linux-next at
http://linux.f-seidel.de/linux-next/pmwiki/ . Thanks to Frank Seidel.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
$ git checkout master
$ git reset --hard stable
Merging origin/master
Merging arm-current/master
Merging m68k-current/for-linus
Merging powerpc-merge/merge
Merging sparc-current/master
Merging scsi-rc-fixes/master
Merging net-current/master
Merging sound-current/for-linus
Merging pci-current/for-linus
Merging wireless-current/master
Merging kbuild-current/master
Merging quilt/driver-core.current
Merging quilt/usb.current
Merging cpufreq-current/fixes
Merging input-current/for-linus
Merging md-current/for-linus
Merging audit-current/for-linus
CONFLICT (content): Merge conflict in drivers/char/tty_audit.c
Merging dwmw2/master
Merging arm/devel
Merging avr32/avr32-arch
Merging blackfin/for-linus
Merging cris/for-next
Merging ia64/test
Merging m68k/for-next
Merging m68knommu/for-next
Merging mips/mips-for-linux-next
Merging parisc/master
Merging powerpc/next
Merging 4xx/next
Merging galak/next
Merging pxa/for-next
Merging s390/features
Merging sh/master
Merging sparc/master
Merging x86/auto-x86-next
Merging xtensa/master
Merging tip-core/auto-core-next
Merging cpus4096/auto-cpus4096-next
Merging ftrace/auto-ftrace-next
Merging genirq/auto-genirq-next
Merging safe-poison-pointers/auto-safe-poison-pointers-next
Merging sched/auto-sched-next
Merging stackprotector/auto-stackprotector-next
Merging timers/auto-timers-next
Merging pci/linux-next
Merging quilt/device-mapper
CONFLICT (content): Merge conflict in drivers/md/dm.c
Merging hid/for-next
Merging quilt/i2c
Merging quilt/jdelvare-hwmon
Merging quilt/kernel-doc
Merging v4l-dvb/master
Merging jfs/next
Merging kbuild/master
Merging quilt/ide
Merging libata/NEXT
Merging nfs/linux-next
Merging xfs/master
Merging infiniband/for-next
Merging acpi/test
Merging nfsd/nfsd-next
Merging ieee1394/for-next
Merging ubi/linux-next
Merging kvm/master
CONFLICT (content): Merge conflict in arch/x86/kernel/reboot.c
$ git reset --hard HEAD^
Merging dlm/next
Merging scsi/master
Merging ocfs2/linux-next
Merging ext4/next
Merging async_tx/next
Applying: net: async_tx merge fix
Merging udf/for_next
Merging net/master
Merging mtd/master
CONFLICT (content): Merge conflict in arch/arm/mach-pxa/corgi.c
CONFLICT (content): Merge conflict in arch/arm/mach-pxa/poodle.c
CONFLICT (content): Merge conflict in arch/arm/mach-pxa/spitz.c
Merging wireless/master
Merging crypto/master
Merging vfs/for-next
Merging sound/for-next
Merging cpufreq/next
Merging v9fs/for-next
Merging rr_cpumask/master
CONFLICT (content): Merge conflict in arch/x86/kernel/io_apic.c
CONFLICT (content): Merge conflict in kernel/rcuclassic.c
CONFLICT (content): Merge conflict in kernel/sched.c
CONFLICT (content): Merge conflict in kernel/time/tick-common.c
$ git reset --hard
Merging cifs/master
Merging mmc/next
Merging gfs2/master
Merging input/next
Merging semaphore/semaphore
Merging bkl-removal/bkl-removal
CONFLICT (content): Merge conflict in fs/ioctl.c
Merging ubifs/linux-next
Merging lsm/for-next
Merging block/for-next
Merging embedded/master
Merging firmware/master
CONFLICT (content): Merge conflict in drivers/net/tg3.c
CONFLICT (content): Merge conflict in firmware/Makefile
CONFLICT (content): Merge conflict in firmware/WHENCE
Merging pcmcia/master
Merging battery/master
Merging leds/for-mm
Merging backlight/for-mm
Merging kgdb/kgdb-next
Merging slab/for-next
Merging uclinux/for-next
Merging md/for-next
Merging kmemcheck/auto-kmemcheck-next
CONFLICT (content): Merge conflict in MAINTAINERS
Merging generic-ipi/auto-generic-ipi-next
Merging mfd/for-next
Merging hdlc/hdlc-next
Merging drm/drm-next
Merging voltage/for-next
Merging security-testing/next
Merging lblnet/master
CONFLICT (content): Merge conflict in Documentation/feature-removal-schedule.txt
Merging quilt/ttydev
CONFLICT (content): Merge conflict in fs/devpts/inode.c
Merging agp/agp-next
Merging oprofile/auto-oprofile-next
Merging fastboot/auto-fastboot-next
Merging sparseirq/auto-sparseirq-next
Merging iommu/auto-iommu-next
Merging uwb/for-upstream
CONFLICT (content): Merge conflict in drivers/uwb/wlp/eda.c
Merging watchdog/master
Merging proc/proc
Merging bdev/master
Merging dwmw2-iommu/master
Merging cputime/cputime
Merging osd/linux-next
Merging fatfs/master
Merging fuse/for-next
Merging jc_docs/docs-next
Merging nommu/master
CONFLICT (content): Merge conflict in kernel/fork.c
Merging trivial/for-next
Applying tracing/kmemtrace: fix for build fix
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: linux-next: ftrace tree build failure
From: Ingo Molnar @ 2009-01-02 9:14 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linux-next
In-Reply-To: <20090102200754.3cd3661c.sfr@canb.auug.org.au>
* Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi Ingo,
>
> Today's linux-next build (sparc defconfig) failed like this:
>
> mm/slab.c:105:31: error: tracing/kmemtrace.h: No such file or directory
>
> Caused by commit 3fd4bc015ef879a7d2b955ce97fb125e3a51ba7e
> ("tracing/kmemtrace: export kmemtrace_mark_alloc_node() /
> kmemtrace_mark_free()") from the ftrace tree.
>
> For a "build fix", this didn't :-)
>
> I didn't revert the ftrace tree today, but added the patch below. A bit
> more care, please.
this has been fixed already a few days ago (if you google for the build
failure string it will send you straight to the fix patch) - i just didnt
push it out to the -next branches yet during the hollidays. (did that now)
Generally if you see a problem with our trees you can check whether an
issue is still present in tip/master:
http://people.redhat.com/mingo/tip.git/README
before duplicating fixing effort and reporting it as a genuine issue -
especially in a busy timeframe like the merge window when the _next_ merge
window is the least of our worries.
Thanks,
Ingo
^ permalink raw reply
* linux-next: ftrace tree build failure
From: Stephen Rothwell @ 2009-01-02 9:07 UTC (permalink / raw)
To: Ingo Molnar; +Cc: linux-next
Hi Ingo,
Today's linux-next build (sparc defconfig) failed like this:
mm/slab.c:105:31: error: tracing/kmemtrace.h: No such file or directory
Caused by commit 3fd4bc015ef879a7d2b955ce97fb125e3a51ba7e
("tracing/kmemtrace: export kmemtrace_mark_alloc_node() /
kmemtrace_mark_free()") from the ftrace tree.
For a "build fix", this didn't :-)
I didn't revert the ftrace tree today, but added the patch below. A bit
more care, please.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Fri, 2 Jan 2009 19:25:21 +1100
Subject: [PATCH] tracing/kmemtrace: fix for build fix
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
mm/slab.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/mm/slab.c b/mm/slab.c
index 7241a19..ae76de2 100644
--- a/mm/slab.c
+++ b/mm/slab.c
@@ -102,7 +102,7 @@
#include <linux/cpu.h>
#include <linux/sysctl.h>
#include <linux/module.h>
-#include <tracing/kmemtrace.h>
+#include <trace/kmemtrace.h>
#include <linux/rcupdate.h>
#include <linux/string.h>
#include <linux/uaccess.h>
--
1.6.0.5
^ permalink raw reply related
* Re: linux-next: usb tree build failure
From: Greg KH @ 2009-01-02 7:27 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linux-next, Inaky Perez-Gonzalez
In-Reply-To: <20081229145506.115307fe.sfr@canb.auug.org.au>
On Mon, Dec 29, 2008 at 02:55:06PM +1100, Stephen Rothwell wrote:
> Hi Greg,
>
> On Mon, 22 Dec 2008 11:33:35 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > Today's linux-next build (x86_64 allmodconfig) failed like this:
> >
> > x86_64-linux-ld: drivers/net/wimax/built-in.o: No such file: No such file or directory
> >
> > I reverted commit 66aa675719ab82a03a66b75210fd40be6541f8fb ("wimax:
> > Makefile, Kconfig and docbook linkage for the stack") just to make the
> > build work.
>
> Still there today. Inaky sent you a patch, I think.
Yes he did, sorry, am on vacation with limited network access. I'll try
to get to this tomorrow.
thanks,
greg k-h
^ permalink raw reply
* Re: linux-next: driver-core tree build failure
From: Greg KH @ 2009-01-02 7:26 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: Mark McLoughlin, linux-next
In-Reply-To: <20081231022803.49de507e.sfr@canb.auug.org.au>
On Wed, Dec 31, 2008 at 02:28:03AM +1100, Stephen Rothwell wrote:
> Hi Greg,
>
> On Mon, 29 Dec 2008 17:34:44 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > On Mon, 22 Dec 2008 20:29:32 -0800 Greg KH <greg@kroah.com> wrote:
> > >
> > > On Mon, Dec 22, 2008 at 02:50:46PM +0000, Mark McLoughlin wrote:
> > > > On Mon, 2008-12-22 at 23:59 +1100, Stephen Rothwell wrote:
> > > > > Hi Greg,
> > > > >
> > > > > Today's linux-next build (powerpc allnoconfig) failed like this:
> > > > >
> > > > > drivers/base/core.c: In function '__root_device_register':
> > > > > drivers/base/core.c:1277: error: dereferencing pointer to incomplete type
> > > > >
> > > > > Caused by bf86dbd2451d1012c2c968a960470e485b869f5b ("driver core: add
> > > > > root_device_register()"). This needs to cope with !CONFIG_MODULES (where
> > > > > struct module is not defined).
> > > >
> > > > Ouch, my bad.
> > > >
> > > > > I applied the following patch but only for today because it is too hard
> > > > > to revert the above patch ...
> > > > >
> > >
> > > Ick, I hate ifdefs... I'll go fix this up.
> >
> > Its still there today. Lucky for you I didn't notice early enough to
> > drop the driver-core tree :-). I will reapply my patch.
>
> Today I dropped the driver-core tree (and the usb and staging trees that
> depend on it).
Ugh, very sorry about this, I forgot to push the changes up to the
kernel.org servers after I made them.
Should be there now, thanks for your patience,
greg k-h
^ permalink raw reply
* Re: linux-next: manual merge of the rr_cpumask tree
From: Stephen Rothwell @ 2009-01-02 6:21 UTC (permalink / raw)
To: Rusty Russell; +Cc: linux-next, Mike Travis, Ingo Molnar
In-Reply-To: <200901021617.40995.rusty@rustcorp.com.au>
[-- Attachment #1: Type: text/plain, Size: 517 bytes --]
Hi Rusty,
On Fri, 2 Jan 2009 16:17:40 +1030 Rusty Russell <rusty@rustcorp.com.au> wrote:
>
> On Friday 02 January 2009 13:05:57 Stephen Rothwell wrote:
> Yes, I've had several 'git blame' pointing to merges from Ingo's tree.
> And they tend to be n-way merges, so tracing it down is too hard.
If you are in the middle of a merge operations with conflicts, the "gitk
--merge" is generally useful.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: linux-next: manual merge of the rr_cpumask tree
From: Rusty Russell @ 2009-01-02 5:47 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linux-next, Mike Travis, Ingo Molnar
In-Reply-To: <20090102133557.0750cdbe.sfr@canb.auug.org.au>
On Friday 02 January 2009 13:05:57 Stephen Rothwell wrote:
> Hi Rusty,
>
> Today's linux-next merge of the rr_cpumask tree got a conflict in
> arch/x86/kernel/io_apic.c between commit
> 22f65d31b25a320a5246592160bcb102d2791c45 ("x86: Update io_apic.c to use
> new cpumask API") from the cpus4096 tree and commit
> 2ca1a615835d9f4990f42102ab1f2ef434e7e89c ("Merge branch 'master' of
> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6") (or
> something - I suspect git has failed me a little here)
Yes, I've had several 'git blame' pointing to merges from Ingo's tree.
And they tend to be n-way merges, so tracing it down is too hard.
The cpus4096 tree is supposed to have already merged the cpumask tree,
so this should not have happened.
> I have dropped the rr_cpumask tree for today and also the rr tree that
> depends on it.
OK I will remove this dependency for the moment.
Rusty.
^ permalink raw reply
* linux-next: manual merge of the rr_cpumask tree
From: Stephen Rothwell @ 2009-01-02 2:43 UTC (permalink / raw)
To: Rusty Russell; +Cc: linux-next, Mike Travis, Sebastien Dugue, Ingo Molnar
Hi Rusty,
Today's linux-next merge of the rr_cpumask tree got a conflict in
kernel/time/tick-common.c between commit
5762ba1873b0bb9faa631aaa02f533c2b9837f82 ("hrtimers: allow the
hot-unplugging of all cpus") from the timers tree and commit
6b954823c24f04ed026a8517f6bab5abda279db8 ("cpumask: convert kernel time
functions") from the rr_cpumask tree.
I fixed it up (see below) and can carry the fix as necessary.,
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
diff --cc kernel/time/tick-common.c
index b21410b,63e05d4..0000000
--- a/kernel/time/tick-common.c
+++ b/kernel/time/tick-common.c
@@@ -274,21 -274,6 +274,21 @@@ out_bc
}
/*
+ * Transfer the do_timer job away from a dying cpu.
+ *
+ * Called with interrupts disabled.
+ */
+static void tick_handover_do_timer(int *cpup)
+{
+ if (*cpup == tick_do_timer_cpu) {
- int cpu = first_cpu(cpu_online_map);
++ int cpu = cpumask_first(cpu_online_map);
+
- tick_do_timer_cpu = (cpu != NR_CPUS) ? cpu :
++ tick_do_timer_cpu = (cpu < nr_cpu_ids) ? cpu :
+ TICK_DO_TIMER_NONE;
+ }
+}
+
+/*
* Shutdown an event device on a given cpu:
*
* This is called on a life CPU, when a CPU is dead. So we cannot
^ permalink raw reply
* linux-next: manual merge of the rr_cpumask tree
From: Stephen Rothwell @ 2009-01-02 2:35 UTC (permalink / raw)
To: Rusty Russell; +Cc: linux-next, Mike Travis, Ingo Molnar
[-- Attachment #1: Type: text/plain, Size: 707 bytes --]
Hi Rusty,
Today's linux-next merge of the rr_cpumask tree got a conflict in
arch/x86/kernel/io_apic.c between commit
22f65d31b25a320a5246592160bcb102d2791c45 ("x86: Update io_apic.c to use
new cpumask API") from the cpus4096 tree and commit
2ca1a615835d9f4990f42102ab1f2ef434e7e89c ("Merge branch 'master' of
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6") (or
something - I suspect git has failed me a little here) from the
rr_cpumask tree.
It is a bit of a train wreck :-)
I have dropped the rr_cpumask tree for today and also the rr tree that
depends on it.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: linux-next: manual merge of the mtd tree
From: Stephen Rothwell @ 2009-01-02 2:07 UTC (permalink / raw)
To: David Woodhouse
Cc: Dmitry Eremin-Solenikov, linux-next, Eric Miao, Russell King
In-Reply-To: <20081215151537.70c789eb.sfr@canb.auug.org.au>
[-- Attachment #1: Type: text/plain, Size: 8707 bytes --]
Hi David,
On Mon, 15 Dec 2008 15:15:37 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> On Sat, 13 Dec 2008 10:05:13 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > On Fri, 12 Dec 2008 13:29:01 +0300 "Dmitry Eremin-Solenikov" <dbaryshkov@gmail.com> wrote:
> > >
> > > Sorry for the delay. I've attached the files resulting from the merge
> > > of today linux-next/master and mtd/master.
> >
> > Thanks, I will use them on Monday.
>
> Just copying in these files produced the following diff which I can carry
> as necessary. Thanks again.
These conflicts are now between the mtd tree and Linus' tree, so could be
cleaned up by merging Linus' tree into the mtd tree ...
> diff --cc arch/arm/mach-pxa/corgi.c
> index c5e28a4,b65be8e..0000000
> --- a/arch/arm/mach-pxa/corgi.c
> +++ b/arch/arm/mach-pxa/corgi.c
> @@@ -542,42 -542,61 +543,92 @@@ err_free_1
> static inline void corgi_init_spi(void) {}
> #endif
>
> + static struct mtd_partition sharpsl_nand_partitions[] = {
> + {
> + .name = "System Area",
> + .offset = 0,
> + .size = 7 * 1024 * 1024,
> + },
> + {
> + .name = "Root Filesystem",
> + .offset = 7 * 1024 * 1024,
> + .size = 25 * 1024 * 1024,
> + },
> + {
> + .name = "Home Filesystem",
> + .offset = MTDPART_OFS_APPEND,
> + .size = MTDPART_SIZ_FULL,
> + },
> + };
> +
> + static uint8_t scan_ff_pattern[] = { 0xff, 0xff };
> +
> + static struct nand_bbt_descr sharpsl_bbt = {
> + .options = 0,
> + .offs = 4,
> + .len = 2,
> + .pattern = scan_ff_pattern
> + };
> +
> + static struct sharpsl_nand_platform_data sharpsl_nand_platform_data = {
> + .badblock_pattern = &sharpsl_bbt,
> + .partitions = sharpsl_nand_partitions,
> + .nr_partitions = ARRAY_SIZE(sharpsl_nand_partitions),
> + };
> +
> + static struct resource sharpsl_nand_resources[] = {
> + {
> + .start = 0x0C000000,
> + .end = 0x0C000FFF,
> + .flags = IORESOURCE_MEM,
> + },
> + };
> +
> + static struct platform_device sharpsl_nand_device = {
> + .name = "sharpsl-nand",
> + .id = -1,
> + .resource = sharpsl_nand_resources,
> + .num_resources = ARRAY_SIZE(sharpsl_nand_resources),
> + .dev.platform_data = &sharpsl_nand_platform_data,
> + };
> +
> +static struct mtd_partition sharpsl_rom_parts[] = {
> + {
> + .name ="Boot PROM Filesystem",
> + .offset = 0x00120000,
> + .size = MTDPART_SIZ_FULL,
> + },
> +};
> +
> +static struct physmap_flash_data sharpsl_rom_data = {
> + .width = 2,
> + .nr_parts = ARRAY_SIZE(sharpsl_rom_parts),
> + .parts = sharpsl_rom_parts,
> +};
> +
> +static struct resource sharpsl_rom_resources[] = {
> + {
> + .start = 0x00000000,
> + .end = 0x007fffff,
> + .flags = IORESOURCE_MEM,
> + },
> +};
> +
> +static struct platform_device sharpsl_rom_device = {
> + .name = "physmap-flash",
> + .id = -1,
> + .resource = sharpsl_rom_resources,
> + .num_resources = ARRAY_SIZE(sharpsl_rom_resources),
> + .dev.platform_data = &sharpsl_rom_data,
> +};
> +
> static struct platform_device *devices[] __initdata = {
> &corgiscoop_device,
> &corgifb_device,
> &corgikbd_device,
> &corgiled_device,
> + &sharpsl_nand_device,
> + &sharpsl_rom_device,
> };
>
> static void corgi_poweroff(void)
> diff --cc arch/arm/mach-pxa/poodle.c
> index ae88855,a45afdf..0000000
> --- a/arch/arm/mach-pxa/poodle.c
> +++ b/arch/arm/mach-pxa/poodle.c
> @@@ -414,40 -414,59 +415,90 @@@ static struct pxafb_mach_info poodle_fb
> .lcd_conn = LCD_COLOR_TFT_16BPP,
> };
>
> + static struct mtd_partition sharpsl_nand_partitions[] = {
> + {
> + .name = "System Area",
> + .offset = 0,
> + .size = 7 * 1024 * 1024,
> + },
> + {
> + .name = "Root Filesystem",
> + .offset = 7 * 1024 * 1024,
> + .size = 22 * 1024 * 1024,
> + },
> + {
> + .name = "Home Filesystem",
> + .offset = MTDPART_OFS_APPEND,
> + .size = MTDPART_SIZ_FULL,
> + },
> + };
> +
> + static uint8_t scan_ff_pattern[] = { 0xff, 0xff };
> +
> + static struct nand_bbt_descr sharpsl_bbt = {
> + .options = 0,
> + .offs = 4,
> + .len = 2,
> + .pattern = scan_ff_pattern
> + };
> +
> + static struct sharpsl_nand_platform_data sharpsl_nand_platform_data = {
> + .badblock_pattern = &sharpsl_bbt,
> + .partitions = sharpsl_nand_partitions,
> + .nr_partitions = ARRAY_SIZE(sharpsl_nand_partitions),
> + };
> +
> + static struct resource sharpsl_nand_resources[] = {
> + {
> + .start = 0x0C000000,
> + .end = 0x0C000FFF,
> + .flags = IORESOURCE_MEM,
> + },
> + };
> +
> + static struct platform_device sharpsl_nand_device = {
> + .name = "sharpsl-nand",
> + .id = -1,
> + .resource = sharpsl_nand_resources,
> + .num_resources = ARRAY_SIZE(sharpsl_nand_resources),
> + .dev.platform_data = &sharpsl_nand_platform_data,
> + };
> +
> +static struct mtd_partition sharpsl_rom_parts[] = {
> + {
> + .name ="Boot PROM Filesystem",
> + .offset = 0x00120000,
> + .size = MTDPART_SIZ_FULL,
> + },
> +};
> +
> +static struct physmap_flash_data sharpsl_rom_data = {
> + .width = 2,
> + .nr_parts = ARRAY_SIZE(sharpsl_rom_parts),
> + .parts = sharpsl_rom_parts,
> +};
> +
> +static struct resource sharpsl_rom_resources[] = {
> + {
> + .start = 0x00000000,
> + .end = 0x007fffff,
> + .flags = IORESOURCE_MEM,
> + },
> +};
> +
> +static struct platform_device sharpsl_rom_device = {
> + .name = "physmap-flash",
> + .id = -1,
> + .resource = sharpsl_rom_resources,
> + .num_resources = ARRAY_SIZE(sharpsl_rom_resources),
> + .dev.platform_data = &sharpsl_rom_data,
> +};
> +
> static struct platform_device *devices[] __initdata = {
> &poodle_locomo_device,
> &poodle_scoop_device,
> + &sharpsl_nand_device,
> + &sharpsl_rom_device,
> };
>
> static void poodle_poweroff(void)
> diff --cc arch/arm/mach-pxa/spitz.c
> index 7299d87,7672b09..0000000
> --- a/arch/arm/mach-pxa/spitz.c
> +++ b/arch/arm/mach-pxa/spitz.c
> @@@ -613,42 -609,60 +614,91 @@@ static struct pxafb_mach_info spitz_pxa
> .lcd_conn = LCD_COLOR_TFT_16BPP | LCD_ALTERNATE_MAPPING,
> };
>
> + static struct mtd_partition sharpsl_nand_partitions[] = {
> + {
> + .name = "System Area",
> + .offset = 0,
> + .size = 7 * 1024 * 1024,
> + },
> + {
> + .name = "Root Filesystem",
> + .offset = 7 * 1024 * 1024,
> + },
> + {
> + .name = "Home Filesystem",
> + .offset = MTDPART_OFS_APPEND,
> + .size = MTDPART_SIZ_FULL,
> + },
> + };
> +
> + static uint8_t scan_ff_pattern[] = { 0xff, 0xff };
> +
> + static struct nand_bbt_descr sharpsl_bbt = {
> + .options = 0,
> + .offs = 4,
> + .len = 2,
> + .pattern = scan_ff_pattern
> + };
> +
> + static struct sharpsl_nand_platform_data sharpsl_nand_platform_data = {
> + .badblock_pattern = &sharpsl_bbt,
> + .partitions = sharpsl_nand_partitions,
> + .nr_partitions = ARRAY_SIZE(sharpsl_nand_partitions),
> + };
> +
> + static struct resource sharpsl_nand_resources[] = {
> + {
> + .start = 0x0C000000,
> + .end = 0x0C000FFF,
> + .flags = IORESOURCE_MEM,
> + },
> + };
> +
> + static struct platform_device sharpsl_nand_device = {
> + .name = "sharpsl-nand",
> + .id = -1,
> + .resource = sharpsl_nand_resources,
> + .num_resources = ARRAY_SIZE(sharpsl_nand_resources),
> + .dev.platform_data = &sharpsl_nand_platform_data,
> + };
> +
>
> +static struct mtd_partition sharpsl_rom_parts[] = {
> + {
> + .name ="Boot PROM Filesystem",
> + .offset = 0x00140000,
> + .size = MTDPART_SIZ_FULL,
> + },
> +};
> +
> +static struct physmap_flash_data sharpsl_rom_data = {
> + .width = 2,
> + .nr_parts = ARRAY_SIZE(sharpsl_rom_parts),
> + .parts = sharpsl_rom_parts,
> +};
> +
> +static struct resource sharpsl_rom_resources[] = {
> + {
> + .start = 0x00000000,
> + .end = 0x007fffff,
> + .flags = IORESOURCE_MEM,
> + },
> +};
> +
> +static struct platform_device sharpsl_rom_device = {
> + .name = "physmap-flash",
> + .id = -1,
> + .resource = sharpsl_rom_resources,
> + .num_resources = ARRAY_SIZE(sharpsl_rom_resources),
> + .dev.platform_data = &sharpsl_rom_data,
> +};
> +
> static struct platform_device *devices[] __initdata = {
> &spitzscoop_device,
> &spitzkbd_device,
> &spitzled_device,
> + &sharpsl_nand_device,
> + &sharpsl_rom_device,
> };
>
> static void spitz_poweroff(void)
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: linux-next: kvm tree build failure
From: Stephen Rothwell @ 2009-01-02 0:53 UTC (permalink / raw)
To: Avi Kivity; +Cc: linux-next, Jan Kiszka, Hollis Blanchard
In-Reply-To: <20081229161750.e2197bad.sfr@canb.auug.org.au>
[-- Attachment #1: Type: text/plain, Size: 1616 bytes --]
Hi Avi,
On Mon, 29 Dec 2008 16:17:50 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> On Tue, 23 Dec 2008 00:25:14 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > Today's linux-next build (powerpc ppc44x_config) failed like this:
> >
> > arch/powerpc/kvm/44x.c: In function 'kvmppc_core_load_guest_debugstate':
> > arch/powerpc/kvm/44x.c:58: warning: initialization from incompatible pointer type
> > arch/powerpc/kvm/44x.c:75: error: 'struct kvm_guest_debug' has no member named 'bp'
> > arch/powerpc/kvm/44x.c:76: error: 'struct kvm_guest_debug' has no member named 'bp'
> > arch/powerpc/kvm/44x.c:79: error: 'struct kvm_guest_debug' has no member named 'bp'
> > arch/powerpc/kvm/44x.c:80: error: 'struct kvm_guest_debug' has no member named 'bp'
> > arch/powerpc/kvm/44x.c:83: error: 'struct kvm_guest_debug' has no member named 'bp'
> > arch/powerpc/kvm/44x.c:84: error: 'struct kvm_guest_debug' has no member named 'bp'
> > arch/powerpc/kvm/44x.c:87: error: 'struct kvm_guest_debug' has no member named 'bp'
> > arch/powerpc/kvm/44x.c:88: error: 'struct kvm_guest_debug' has no member named 'bp'
> >
> > Probably caused by commit 6968f31a2163f8fcf26ea8775c44d7e5be54d622 ("KVM:
> > Remove old kvm_guest_debug structs") so I have reverted the kvm tree for
> > today.
>
> This error is still there, so I have dropped the kvm tree again today.
And again. Can you please find some fix for this so that the kvm tree
can get some integration testing ...
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* linux-next: manual merge of the kvm tree
From: Stephen Rothwell @ 2009-01-02 0:44 UTC (permalink / raw)
To: Avi Kivity
Cc: linux-next, Eduardo Habkost, Jaswinder Singh Rajput, Ingo Molnar
Hi Avi,
Today's linux-next merge of the kvm tree got a conflict in
arch/x86/kernel/reboot.c between commit
824877111cd7f2b4fd2fe6947c5c5cbbb3ac5bd8 ("x86, pci: move
arch/x86/pci/pci.h to arch/x86/include/asm/pci_x86.h") from the x86 tree
and commit 87238e8d2a086678c246825bc1a9dd148bba77cb ("x86: disable VMX on
all CPUs on reboot") from the kvm tree.
Just overlapping additions. I fixed it up (see below) and can carry it
as necessary.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
diff --cc arch/x86/kernel/reboot.c
index 5b1f23b,72e0e4e..0000000
--- a/arch/x86/kernel/reboot.c
+++ b/arch/x86/kernel/reboot.c
@@@ -12,7 -12,7 +12,8 @@@
#include <asm/proto.h>
#include <asm/reboot_fixups.h>
#include <asm/reboot.h>
+#include <asm/pci_x86.h>
+ #include <asm/virtext.h>
#ifdef CONFIG_X86_32
# include <linux/dmi.h>
^ permalink raw reply
* Re: Pull request for FS-Cache, including NFS patches
From: Kyle Moffett @ 2009-01-01 18:40 UTC (permalink / raw)
To: Arjan van de Ven
Cc: Muntz, Daniel, Trond Myklebust, Andrew Morton, Stephen Rothwell,
Bernd Schubert, nfsv4, linux-kernel, steved, dhowells, linux-next,
linux-fsdevel, rwheeler
In-Reply-To: <20090101090900.551ada4a@infradead.org>
On Thu, Jan 1, 2009 at 3:09 AM, Arjan van de Ven <arjan@infradead.org> wrote:
> On Wed, 31 Dec 2008 20:11:13 -0800 "Muntz, Daniel" <Dan.Muntz@netapp.com> wrote:
>> If you're following the protocol, it doesn't even matter if a bad guy
>> ("untrusted user"?) gets root on the client--they still can't gain
>> inappropriate access to the file server. OTOH, if my security plan is
>> simply to not allow root access to untrusted users, history says I'm
>> going to lose.
>
> if you have a user, history says you're going to lose.
>
> you can make your system as secure as you want, with physical access
> all bets are off.
Yeah... this is precisely the reason that the security-test-plan and
system-design-document for any really security sensitive system starts
with:
[ ] The system is in a locked rack
[ ] The rack is in a locked server room with detailed access logs
[ ] The server room is in a locked and secured building with 24-hour
camera surveillance and armed guards
I've spent a little time looking into the security guarantees provided
by DAC and by the FS-Cache LSM hooks, and it is possible to reasonably
guarantee that no *REMOTE* user will be able to compromise the
contents of the cache using a combination of DAC (file permissions,
etc) and MAC (SELinux, etc) controls. As previously mentioned, local
users (with physical hardware access) are an entirely different story.
As far as performance considerations for the merge... FS-cache on
flash-based storage also has very different performance tradeoffs from
traditional rotating media. Specifically I have some sample 32GB
SATA-based flash media here with ~230Mbyte/sec sustained read and
~200Mbyte/sec sustained write and with a 75usec read latency. It
doesn't take much link latency at all to completely dwarf that kind of
access time.
Cheers,
Kyle Moffett
^ permalink raw reply
* Re: linux-next: Tree for December 30
From: Stephen Rothwell @ 2009-01-01 9:12 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: linux-next, LKML
In-Reply-To: <Pine.LNX.4.64.0812311202000.14380@anakin>
[-- Attachment #1: Type: text/plain, Size: 654 bytes --]
Hi Geert,
On Wed, 31 Dec 2008 12:02:26 +0100 (CET) Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>
> On Wed, 31 Dec 2008, Stephen Rothwell wrote:
> > Status of my local build tests will be at
> > http://kisskb.ellerman.id.au/linux-next . If maintainers want to give
> > advice about cross compilers/configs that work, we are always open to add
> > more builds.
>
> The website doesn't seem to have been updated during the last few days?
Thanks for pointing that out. I have restated the mirror so it should
all be OK, now.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: Pull request for FS-Cache, including NFS patches
From: Arjan van de Ven @ 2009-01-01 8:09 UTC (permalink / raw)
To: Muntz, Daniel
Cc: Trond Myklebust, Andrew Morton, Stephen Rothwell, Bernd Schubert,
nfsv4, linux-kernel, steved, dhowells, linux-next, linux-fsdevel,
rwheeler
In-Reply-To: <7A24DF798E223B4C9864E8F92E8C93EC01BD14BB@SACMVEXC1-PRD.hq.netapp.com>
On Wed, 31 Dec 2008 20:11:13 -0800
"Muntz, Daniel" <Dan.Muntz@netapp.com> wrote:
please don't top post.
> Sure, trusted kernel and trusted executables, but it's easier than it
> sounds. If you start with a "clean" system, you don't need to verify
> excutables _if_ they're coming from the secured file server (by
> induction: if you started out secure, the executables on the file
> server will remain secure). You simply can't trust the local disk
> from one user to the next. Following the protocol, a student can log
> into a machine, su to do their OS homework, but not compromise the
> security of the distributed file system.
>
> If I can su while another user is logged in, or the kernel/cmds are
> not validated between users, cryptfs isn't safe either.
>
> If you're following the protocol, it doesn't even matter if a bad guy
> ("untrusted user"?) gets root on the client--they still can't gain
> inappropriate access to the file server. OTOH, if my security plan is
> simply to not allow root access to untrusted users, history says I'm
> going to lose.
if you have a user, history says you're going to lose.
you can make your system as secure as you want, with physical access
all bets are off.
keyboard sniffer.. easy.
special dimms that mirror data... not even all THAT hard, just takes a
bit of cash.
running the user in a VM without him noticing.. not too hard either.
etc.
--
Arjan van de Ven Intel Open Source Technology Centre
For development, discussion and tips for power savings,
visit http://www.lesswatts.org
^ permalink raw reply
* RE: Pull request for FS-Cache, including NFS patches
From: Muntz, Daniel @ 2009-01-01 4:11 UTC (permalink / raw)
To: Trond Myklebust
Cc: Andrew Morton, Stephen Rothwell, Bernd Schubert, nfsv4,
linux-kernel, steved, dhowells, linux-next, linux-fsdevel,
rwheeler
In-Reply-To: <1230679056.11508.37.camel@heimdal.trondhjem.org>
Sure, trusted kernel and trusted executables, but it's easier than it
sounds. If you start with a "clean" system, you don't need to verify
excutables _if_ they're coming from the secured file server (by
induction: if you started out secure, the executables on the file server
will remain secure). You simply can't trust the local disk from one
user to the next. Following the protocol, a student can log into a
machine, su to do their OS homework, but not compromise the security of
the distributed file system.
If I can su while another user is logged in, or the kernel/cmds are not
validated between users, cryptfs isn't safe either.
If you're following the protocol, it doesn't even matter if a bad guy
("untrusted user"?) gets root on the client--they still can't gain
inappropriate access to the file server. OTOH, if my security plan is
simply to not allow root access to untrusted users, history says I'm
going to lose.
-Dan
-----Original Message-----
From: Trond Myklebust [mailto:trond.myklebust@fys.uio.no]
Sent: Tuesday, December 30, 2008 3:18 PM
To: Muntz, Daniel
Cc: Andrew Morton; Stephen Rothwell; Bernd Schubert;
nfsv4@linux-nfs.org; linux-kernel@vger.kernel.org; steved@redhat.com;
dhowells@redhat.com; linux-next@vger.kernel.org;
linux-fsdevel@vger.kernel.org; rwheeler@redhat.com
Subject: RE: Pull request for FS-Cache, including NFS patches
On Tue, 2008-12-30 at 15:00 -0800, Muntz, Daniel wrote:
> Yes, and if you have a single user on the machine at a time (with
> cache flushed inbetween, kernel refreshed), root can read /dev/kmem,
> swap, intercept traffic and read cachefs data to its heart's
> content--hence, those requirements.
Unless you _are_ root and can check every executable, after presumably
rebooting into your own trusted kernel, then those requirements won't
mean squat. If you're that paranoid, then you will presumably also be
using a cryptfs-encrypted partition for cachefs, which you unmount when
you're not logged in.
That said, most cluster environments will tend to put most of their
security resources into keeping untrusted users out altogether. The
client nodes tend to be a homogeneous lot with presumably only a trusted
few sysadmins...
Trond
> -----Original Message-----
> From: Trond Myklebust [mailto:trond.myklebust@fys.uio.no]
> Sent: Tuesday, December 30, 2008 2:36 PM
> To: Muntz, Daniel
> Cc: Andrew Morton; Stephen Rothwell; Bernd Schubert;
> nfsv4@linux-nfs.org; linux-kernel@vger.kernel.org; steved@redhat.com;
> dhowells@redhat.com; linux-next@vger.kernel.org;
> linux-fsdevel@vger.kernel.org; rwheeler@redhat.com
> Subject: RE: Pull request for FS-Cache, including NFS patches
>
> On Tue, 2008-12-30 at 14:15 -0800, Muntz, Daniel wrote:
> > >> As for security, look at what MIT had to do to prevent local disk
> > >> caching from breaking the security guarantees of AFS.
> > >
> > >See what David has added to the LSM code to provide the same
> > >guarantees
> > for cachefs...
> > >
> > >Trond
> >
> > Unless it (at least) leverages TPM, the issues I had in mind can't
> > really be addressed in code. One requirement is to prevent a local
> > root user from accessing fs information without appropriate
> permissions.
> > This leads to unwieldly requirements such as allowing only one user
> > on
>
> > a machine at a time, blowing away the cache on logout, validating
> > (e.g.,
> > refreshing) the kernel on each boot, etc. Sure, some applications
> > won't care, but you're also potentially opening holes that users may
> > not consider.
>
> You can't prevent a local root user from accessing cached data: that's
> true with or without cachefs. root can typically access the data using
> /dev/kmem, swap, intercepting tty traffic, spoofing user creds,...
> If root can't be trusted, then find another machine.
>
> The worry is rather that privileged daemons may be tricked into
> revealing said data to unprivileged users, or that unprivileged users
> may attempt to read data from files to which they have no rights using
> the cachefs itself. That is a problem that is addressable by means of
> LSM, and is what David has attempted to solve.
>
> Trond
>
> --
> To unsubscribe from this list: send the line "unsubscribe
> linux-kernel" in the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply
* [BUG] next-20081231 -powerpc - panic at tasklet_kill_immediate()
From: Kamalesh Babulal @ 2008-12-31 16:13 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linux-next, LKML, linuxppc-dev, mel
In-Reply-To: <20090101003258.eaa44700.sfr@canb.auug.org.au>
Hi Stephen,
next-20081231 kernel panic's, while booting up on powerpc. This
panic was visible in next-20081230 kernel also.
[ 1.268844] Brought up 2 CPUs
[ 1.268873] Unable to handle kernel paging request for data at address 0x00000009
[ 1.268876] Faulting instruction address: 0xc00000000005a9f8
[ 1.268880] Oops: Kernel access of bad area, sig: 11 [#1]
[ 1.268882] SMP NR_CPUS=32 NUMA PowerMac
[ 1.268886] Modules linked in:
[ 1.268889] NIP: c00000000005a9f8 LR: c00000000006ee54 CTR: c00000000005a9c0
[ 1.268893] REGS: c0000002763c3c80 TRAP: 0300 Not tainted (2.6.28-next-20081231-autokern1)
[ 1.268896] MSR: 9000000000009032 <EE,ME,IR,DR> CR: 24000024 XER: 000fffff
[ 1.268903] DAR: 0000000000000009, DSISR: 0000000040000000
[ 1.268905] TASK = c0000002760e20c0[5] 'ksoftirqd/1' THREAD: c0000002763c0000 CPU: 1
[ 1.268908] GPR00: 0000000000000000 c0000002763c3f00 c0000000004f9088 0000000000000001
[ 1.268913] GPR04: c0000002760e28d0 0000000000000000 0000000024000022 c000000000010098
[ 1.268917] GPR08: 0000000000000000 000000000ec1c518 c000000000514a40 0000000000000010
[ 1.268922] GPR12: c00000000051c700 c00000000051c500 0000000000000000 0000000000000000
[ 1.268926] GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
[ 1.268930] GPR20: 0000000000000000 0000000000000000 0000000000000000 0000000001400000
[ 1.268934] GPR24: 0000000001829d88 c000000000429b28 0000000001400000 0000000000000000
[ 1.268939] GPR28: c0000002760bfc48 0000000000000001 c000000000498a98 c0000000004b0150
[ 1.268950] NIP [c00000000005a9f8] .tasklet_kill_immediate+0x38/0xb8
[ 1.268955] LR [c00000000006ee54] .kthread+0x78/0xc4
[ 1.268957] Call Trace:
[ 1.268960] [c0000002763c3f00] [c00000000006ee1c] .kthread+0x40/0xc4 (unreliable)
[ 1.268967] [c0000002763c3f90] [c0000000000227a8] .kernel_thread+0x54/0x70
[ 1.268969] Instruction dump:
[ 1.268971] 7c8b07b4 7d693670 7d290194 556b06be e95e8040 7d2907b4 79291f24 e94a0000
[ 1.268977] 7c0a482a 7c005c36 780007e0 0b000000 <e8030008> 7800ffe2 0b000000 e8030008
[ 1.268992] ---[ end trace 31fd0ba7d8756001 ]---
[ 1.269016] Unable to handle kernel paging request for data at address 0x00000000
[ 1.269019] Faulting instruction address: 0xc0000000000d9b4c
[ 1.269022] Oops: Kernel access of bad area, sig: 11 [#2]
[ 1.269024] SMP NR_CPUS=32 NUMA PowerMac
[ 1.269026] Modules linked in:
[ 1.269029] NIP: c0000000000d9b4c LR: c0000000000511fc CTR: 0000000000000003
[ 1.269032] REGS: c0000002763c35d0 TRAP: 0300 Tainted: G D (2.6.28-next-20081231-autokern1)
[ 1.269035] MSR: 9000000000009032 <EE,ME,IR,DR> CR: 28004082 XER: 200fffff
[ 1.269040] DAR: 0000000000000000, DSISR: 0000000040000000
[ 1.269043] TASK = c0000002760e20c0[5] 'ksoftirqd/1' THREAD: c0000002763c0000 CPU: 1
[ 1.269046] GPR00: 0000000000000004 c0000002763c3850 c0000000004f9088 c000000276027d00
[ 1.269051] GPR04: c0000002763b6980 0000000000000000 c000000000457278 c000000000457278
[ 1.269055] GPR08: c0000002760e2290 0000000000000000 c00000000051c500 c0000002763b6080
[ 1.269060] GPR12: 0000000048000084 c00000000051c500 0000000000000000 0000000000000000
[ 1.269064] GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
[ 1.269068] GPR20: 0000000000000000 0000000000000000 0000000000000000 0000000000000001
[ 1.269073] GPR24: c0000002760e20b0 c0000002760e2228 0000000000000000 c000000276027d00
[ 1.269077] GPR28: 0000000000000000 c0000002763b6980 c00000000049c9b8 0000000000000000
[ 1.269086] NIP [c0000000000d9b4c] .kmem_cache_free+0x1b8/0x244
[ 1.269090] LR [c0000000000511fc] .__cleanup_sighand+0x44/0x5c
[ 1.269092] Call Trace:
[ 1.269095] [c0000002763c3850] [c00000000049abe8] 0xc00000000049abe8 (unreliable)
[ 1.269099] [c0000002763c3900] [c0000000000511fc] .__cleanup_sighand+0x44/0x5c
[ 1.269104] [c0000002763c3980] [c000000000057244] .release_task+0x2dc/0x400
[ 1.269108] [c0000002763c3a20] [c000000000057b14] .do_exit+0x7ac/0x858
[ 1.269112] [c0000002763c3af0] [c000000000020414] .die+0x1c8/0x1cc
[ 1.269117] [c0000002763c3b90] [c000000000027f4c] .bad_page_fault+0xb8/0xd4
[ 1.269122] [c0000002763c3c10] [c000000000005318] handle_page_fault+0x3c/0x5c
[ 1.269128] --- Exception: 300 at .tasklet_kill_immediate+0x38/0xb8
[ 1.269130] LR = .kthread+0x78/0xc4
[ 1.269133] [c0000002763c3f00] [c00000000006ee1c] .kthread+0x40/0xc4 (unreliable)
[ 1.269138] [c0000002763c3f90] [c0000000000227a8] .kernel_thread+0x54/0x70
[ 1.269141] Instruction dump:
[ 1.269142] 4800016d e97d0168 880d01dc 2fa00000 41be0010 7c0004ac 38000000 980d01dc
[ 1.269148] 7c2004ac 38000000 900b0040 48000050 <817f0000> 801f0004 7f8b0040 409c001c
[ 1.269155] ---[ end trace 31fd0ba7d8756001 ]---
[ 1.269157] Fixing recursive fault but reboot is needed!
--
Thanks & Regards,
Kamalesh Babulal,
Linux Technology Center,
IBM, ISTL.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox