Hi all,
Changes since next-20080728:
Temporarily dropped trees: acpi (it is being moved to a new tree and is
just accumulating conflicts against Linus' tree).
v4l-dvb (got lots of conflicts against the version that was
merged to Linus).
Changed trees: the tests tree changed directory
the sound tree changed branch
Linus' tree lost the three build fixes.
The pci-current tree gained a build fix patch.
The v4l-dvb tree gained 51 conflicts against Linus' tree and was dropped.
The tests tree lost its conflict.
The rr tree lost its conflicts.
The firmware tree gained a conflict against Linus' tree.
The kmemcheck tree lost its conflicts.
I have also applied the following patches for known problems:
hfcmulti is not supported on big endian
sparc: add iommu_num_pages helper function fix
cpumask: statement expressions confuse some versions of gcc
The sparc(32) defconfig build still fails.
----------------------------------------------------------------------------
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, it is also built with powerpc allnoconfig,
44x_defconfig and allyesconfig and i386, sparc and sparc64 defconfig.
Below is a summary of the state of the merge.
We are up to 105 trees (counting Linus' and 14 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 [email protected]
$ git checkout master
$ git reset --hard stable
Merging origin/master
Merging powerpc-merge/merge
Merging scsi-rc-fixes/master
Merging net-current/master
Merging sparc-current/master
Merging sound-current/for-linus
Merging arm-current/master
Merging pci-current/for-linus
Applying powerpc: generic iommu helper fallout
Merging wireless-current/master
Merging kbuild-current/master
Merging quilt/driver-core.current
CONFLICT (content): Merge conflict in drivers/dca/dca-sysfs.c
Merging quilt/usb.current
Merging cpufreq-current/fixes
Merging input-current/for-linus
Merging md-current/for-2.6.26
Merging quilt/driver-core
Merging quilt/usb
Merging tip-core/auto-core-next
Merging cpus4096/auto-cpus4096-next
CONFLICT (content): Merge conflict in net/sunrpc/svc.c
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 x86/auto-x86-next
CONFLICT (content): Merge conflict in drivers/pci/dmar.c
Merging pci/linux-next
Merging quilt/device-mapper
Merging hid/mm
Merging quilt/i2c
Merging quilt/kernel-doc
Merging avr32/avr32-arch
Merging v4l-dvb/stable
CONFLICT (content): Merge conflict in Documentation/video4linux/CARDLIST.em28xx
CONFLICT (add/add): Merge conflict in Documentation/video4linux/gspca.txt
CONFLICT (content): Merge conflict in drivers/media/dvb/dvb-usb/Kconfig
CONFLICT (content): Merge conflict in drivers/media/dvb/dvb-usb/Makefile
CONFLICT (add/add): Merge conflict in drivers/media/dvb/dvb-usb/anysee.c
CONFLICT (add/add): Merge conflict in drivers/media/dvb/siano/smscoreapi.c
CONFLICT (add/add): Merge conflict in drivers/media/dvb/siano/smsdvb.c
CONFLICT (content): Merge conflict in drivers/media/radio/radio-si470x.c
CONFLICT (content): Merge conflict in drivers/media/video/bt8xx/bttv-driver.c
CONFLICT (content): Merge conflict in drivers/media/video/cx18/cx18-firmware.c
CONFLICT (content): Merge conflict in drivers/media/video/cx18/cx18-ioctl.c
CONFLICT (content): Merge conflict in drivers/media/video/cx18/cx18-streams.c
CONFLICT (content): Merge conflict in drivers/media/video/cx23885/cx23885-417.c
CONFLICT (content): Merge conflict in drivers/media/video/cx23885/cx23885-cards.c
CONFLICT (content): Merge conflict in drivers/media/video/cx25840/cx25840-core.c
CONFLICT (content): Merge conflict in drivers/media/video/em28xx/em28xx-cards.c
CONFLICT (content): Merge conflict in drivers/media/video/em28xx/em28xx-dvb.c
CONFLICT (content): Merge conflict in drivers/media/video/em28xx/em28xx.h
CONFLICT (add/add): Merge conflict in drivers/media/video/gspca/conex.c
CONFLICT (add/add): Merge conflict in drivers/media/video/gspca/etoms.c
CONFLICT (add/add): Merge conflict in drivers/media/video/gspca/gspca.c
CONFLICT (add/add): Merge conflict in drivers/media/video/gspca/mars.c
CONFLICT (add/add): Merge conflict in drivers/media/video/gspca/ov519.c
CONFLICT (add/add): Merge conflict in drivers/media/video/gspca/pac207.c
CONFLICT (add/add): Merge conflict in drivers/media/video/gspca/pac7311.c
CONFLICT (add/add): Merge conflict in drivers/media/video/gspca/sonixb.c
CONFLICT (add/add): Merge conflict in drivers/media/video/gspca/sonixj.c
CONFLICT (add/add): Merge conflict in drivers/media/video/gspca/spca500.c
CONFLICT (add/add): Merge conflict in drivers/media/video/gspca/spca501.c
CONFLICT (add/add): Merge conflict in drivers/media/video/gspca/spca505.c
CONFLICT (add/add): Merge conflict in drivers/media/video/gspca/spca506.c
CONFLICT (add/add): Merge conflict in drivers/media/video/gspca/spca508.c
CONFLICT (add/add): Merge conflict in drivers/media/video/gspca/spca561.c
CONFLICT (add/add): Merge conflict in drivers/media/video/gspca/stk014.c
CONFLICT (add/add): Merge conflict in drivers/media/video/gspca/sunplus.c
CONFLICT (add/add): Merge conflict in drivers/media/video/gspca/t613.c
CONFLICT (add/add): Merge conflict in drivers/media/video/gspca/tv8532.c
CONFLICT (add/add): Merge conflict in drivers/media/video/gspca/vc032x.c
CONFLICT (add/add): Merge conflict in drivers/media/video/gspca/zc3xx.c
CONFLICT (content): Merge conflict in drivers/media/video/ivtv/ivtv-ioctl.c
CONFLICT (add/add): Merge conflict in drivers/media/video/s2255drv.c
CONFLICT (content): Merge conflict in drivers/media/video/saa7134/saa7134-cards.c
CONFLICT (content): Merge conflict in drivers/media/video/saa7134/saa7134-empress.c
CONFLICT (content): Merge conflict in drivers/media/video/saa7134/saa7134-video.c
CONFLICT (add/add): Merge conflict in drivers/media/video/sh_mobile_ceu_camera.c
CONFLICT (content): Merge conflict in drivers/media/video/soc_camera.c
CONFLICT (add/add): Merge conflict in drivers/media/video/videobuf-dma-contig.c
CONFLICT (content): Merge conflict in drivers/media/video/videodev.c
CONFLICT (content): Merge conflict in drivers/media/video/zoran_card.c
CONFLICT (content): Merge conflict in include/linux/videodev2.h
CONFLICT (content): Merge conflict in include/media/v4l2-dev.h
$ git reset --hard
Merging s390/features
Merging sh/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 blackfin/for-linus
Merging nfsd/nfsd-next
Merging ieee1394/for-next
Merging hwmon/testing
Merging ubi/linux-next
Merging kvm/master
Merging dlm/next
Merging scsi/master
Merging ia64/test
Merging tests/master
Merging ocfs2/linux-next
Merging quilt/m68k
Merging powerpc/next
Merging ext4/next
Merging 4xx/next
Merging async_tx/next
Merging udf/for_next
Merging net/master
Merging sparc/master
Merging galak/powerpc-next
Merging mtd/master
Merging wireless/master
Merging crypto/master
Merging vfs/for-next
Merging sound/for-next
Merging arm/devel
Merging cpufreq/next
Merging v9fs/for-next
Merging quilt/rr
Merging cifs/master
Merging mmc/next
Merging gfs2/master
Merging input/next
Merging semaphore/semaphore
Merging semaphore-removal/semaphore-removal
Merging bkl-removal/bkl-removal
Merging trivial/next
CONFLICT (content): Merge conflict in Documentation/edac.txt
CONFLICT (content): Merge conflict in include/linux/securebits.h
Merging ubifs/linux-next
Merging lsm/for-next
Merging block/for-next
Merging embedded/master
Merging firmware/master
CONFLICT (content): Merge conflict in drivers/media/dvb/ttpci/Kconfig
CONFLICT (content): Merge conflict in drivers/media/dvb/ttpci/Makefile
Merging pcmcia/master
Merging battery/master
CONFLICT (content): Merge conflict in drivers/power/Kconfig
CONFLICT (content): Merge conflict in drivers/power/Makefile
Merging leds/for-mm
Merging backlight/for-mm
Merging kgdb/kgdb-next
Merging slab/for-next
Merging m68knommu/for-next
Merging uclinux/for-next
Merging md/for-next
Merging cris/for-next
Merging kmemcheck/auto-kmemcheck-next
Merging generic-ipi/auto-generic-ipi-next
Merging mips/mips-for-linux-next
Merging mfd/for-next
Merging hdlc/hdlc-next
Merging drm/drm-next
CONFLICT (add/add): Merge conflict in drivers/gpu/Makefile
CONFLICT (add/add): Merge conflict in drivers/gpu/drm/i830/Makefile
CONFLICT (content): Merge conflict in include/Kbuild
CONFLICT (add/add): Merge conflict in include/drm/Kbuild
Merging voltage/reg-for-linus
Merging security-testing/next
Merging lblnet/master
Merging quilt/ttydev
Applying hfcmulti is not supported on big endian
Applying sparc: add iommu_num_pages helper function fix
Applying cpumask: statement expressions confuse some versions of gcc
The patch below gets rid of a compile error that would be nice to get
fixed in Linus' tree.
-------- Forwarded Message --------
From: Fernando Luis V?zquez Cao <[email protected]>
To: [email protected], [email protected]
Cc: [email protected], [email protected], [email protected]
Subject: [PATCH] iwlwifi: fix iwl-led compile issue when CONFIG_IWLWIFI_DEBUG is not set
Date: Tue, 29 Jul 2008 14:58:42 +0900
Fix compile error when CONFIG_IWLWIFI_DEBUG not defined.
Signed-off-by: Fernando Luis Vazquez Cao <[email protected]>
---
--- linux-2.6.27-rc1/drivers/net/wireless/iwlwifi/iwl-led.c 2008-07-29 13:51:26.000000000 +0900
+++ linux-2.6.27-rc1-iocontext/drivers/net/wireless/iwlwifi/iwl-led.c 2008-07-29 14:47:13.000000000 +0900
@@ -194,9 +194,10 @@ static void iwl_led_brightness_set(struc
if (test_bit(STATUS_EXIT_PENDING, &priv->status))
return;
-
+#ifdef CONFIG_IWLWIFI_DEBUG
IWL_DEBUG_LED("Led type = %s brightness = %d\n",
led_type_str[led->type], brightness);
+#endif /* CONFIG_IWLWIFI_DEBUG */
switch (brightness) {
case LED_FULL:
if (led->type == IWL_LED_TRG_ASSOC)
Hi,
On Tue, Jul 29, 2008 at 05:23:37PM +1000, Stephen Rothwell wrote:
> Changes since next-20080728:
is linux-next now open for 2.6.28 stuff?
Thanks,
Dominik
Hi,
On Tuesday 29 July 2008, Stephen Rothwell wrote:
> Hi all,
>
> Changes since next-20080728:
I keep reverting commit 0e3638d1e04040121af00195f7e4628078246489 ("warn
when statically-allocated kobjects are used") with each linux-next release
to make it work on my x86_32 laptop (http://lkml.org/lkml/2008/7/19/114).
Depending on the day I either forget to revert it on a first try or (lead by
incurable optimism) I don't try to revert it in hope that it was fixed.
Unfortunately the result is always the same cursing-during-qemu-test-run
-> git-revert -> recompile cycle and a needless time loss.
Could we have some action taken please?
Thanks,
Bart
On Tue, Jul 29, 2008 at 06:25:14PM +0200, Bartlomiej Zolnierkiewicz wrote:
>
> Hi,
>
> On Tuesday 29 July 2008, Stephen Rothwell wrote:
> > Hi all,
> >
> > Changes since next-20080728:
>
> I keep reverting commit 0e3638d1e04040121af00195f7e4628078246489 ("warn
> when statically-allocated kobjects are used") with each linux-next release
> to make it work on my x86_32 laptop (http://lkml.org/lkml/2008/7/19/114).
>
> Depending on the day I either forget to revert it on a first try or (lead by
> incurable optimism) I don't try to revert it in hope that it was fixed.
>
> Unfortunately the result is always the same cursing-during-qemu-test-run
> -> git-revert -> recompile cycle and a needless time loss.
>
> Could we have some action taken please?
What is the problem with this patch that has caused it to suddenly
keeping the boot from working? Is the code in the patch warning you of
objects that are not properly being initialized?
I'll be glad to fix this if possible.
thanks,
greg k-h
On Tue, 29 Jul 2008, Greg KH wrote:
> On Tue, Jul 29, 2008 at 06:25:14PM +0200, Bartlomiej Zolnierkiewicz wrote:
> > On Tuesday 29 July 2008, Stephen Rothwell wrote:
> > >
> > > Changes since next-20080728:
> >
> > I keep reverting commit 0e3638d1e04040121af00195f7e4628078246489 ("warn
> > when statically-allocated kobjects are used") with each linux-next release
> > to make it work on my x86_32 laptop (http://lkml.org/lkml/2008/7/19/114).
> >
> > Depending on the day I either forget to revert it on a first try or (lead by
> > incurable optimism) I don't try to revert it in hope that it was fixed.
> >
> > Unfortunately the result is always the same cursing-during-qemu-test-run
> > -> git-revert -> recompile cycle and a needless time loss.
> >
> > Could we have some action taken please?
>
> What is the problem with this patch that has caused it to suddenly
> keeping the boot from working? Is the code in the patch warning you of
> objects that are not properly being initialized?
>
> I'll be glad to fix this if possible.
Isn't this the opposite end of the same problem for which Bernhard
has been repeatedly trying to find a taker for his patch:
http://article.gmane.org/gmane.linux.kernel.kexec/1882
Hugh
Hi Bart,
On Tue, 29 Jul 2008 18:25:14 +0200 Bartlomiej Zolnierkiewicz <[email protected]> wrote:
>
> I keep reverting commit 0e3638d1e04040121af00195f7e4628078246489 ("warn
> when statically-allocated kobjects are used") with each linux-next release
> to make it work on my x86_32 laptop (http://lkml.org/lkml/2008/7/19/114).
>
> Depending on the day I either forget to revert it on a first try or (lead by
> incurable optimism) I don't try to revert it in hope that it was fixed.
>
> Unfortunately the result is always the same cursing-during-qemu-test-run
> -> git-revert -> recompile cycle and a needless time loss.
>
> Could we have some action taken please?
I have reverted that commit from linux-next today (its id has changed)
and will do so until Greg or Dave tells me it has been fixed. To make
life easier for me, Greg, it would be nice if you removed it from your
series until that time.
--
Cheers,
Stephen Rothwell [email protected]
http://www.canb.auug.org.au/~sfr/
On Tue, Jul 29, 2008 at 09:49:24PM +0100, Hugh Dickins wrote:
> On Tue, 29 Jul 2008, Greg KH wrote:
> > On Tue, Jul 29, 2008 at 06:25:14PM +0200, Bartlomiej Zolnierkiewicz wrote:
> > > On Tuesday 29 July 2008, Stephen Rothwell wrote:
> > > >
> > > > Changes since next-20080728:
> > >
> > > I keep reverting commit 0e3638d1e04040121af00195f7e4628078246489 ("warn
> > > when statically-allocated kobjects are used") with each linux-next release
> > > to make it work on my x86_32 laptop (http://lkml.org/lkml/2008/7/19/114).
> > >
> > > Depending on the day I either forget to revert it on a first try or (lead by
> > > incurable optimism) I don't try to revert it in hope that it was fixed.
> > >
> > > Unfortunately the result is always the same cursing-during-qemu-test-run
> > > -> git-revert -> recompile cycle and a needless time loss.
> > >
> > > Could we have some action taken please?
> >
> > What is the problem with this patch that has caused it to suddenly
> > keeping the boot from working? Is the code in the patch warning you of
> > objects that are not properly being initialized?
> >
> > I'll be glad to fix this if possible.
>
> Isn't this the opposite end of the same problem for which Bernhard
> has been repeatedly trying to find a taker for his patch:
>
> http://article.gmane.org/gmane.linux.kernel.kexec/1882
Yes. It's not the kobject patch at fault here, it's the use of kobjects
so early in the boot process. That needs to be fixed.
thanks,
greg k-h
* Greg KH <[email protected]> [2008-07-29 21:48]:
> > Isn't this the opposite end of the same problem for which Bernhard
> > has been repeatedly trying to find a taker for his patch:
> >
> > http://article.gmane.org/gmane.linux.kernel.kexec/1882
>
> Yes. It's not the kobject patch at fault here, it's the use of kobjects
> so early in the boot process. That needs to be fixed.
Yes, but if somebody could tell me why nobody takes the patch, I would
be happy. Then I would be able to improve the patch. :)
Bernhard
--
Bernhard Walle, SUSE LINUX Products GmbH, Architecture Development
On Wed, 30 Jul 2008 09:06:50 +0200 Bernhard Walle <[email protected]> wrote:
> * Greg KH <[email protected]> [2008-07-29 21:48]:
> > > Isn't this the opposite end of the same problem for which Bernhard
> > > has been repeatedly trying to find a taker for his patch:
> > >
> > > http://article.gmane.org/gmane.linux.kernel.kexec/1882
> >
> > Yes. It's not the kobject patch at fault here, it's the use of kobjects
> > so early in the boot process. That needs to be fixed.
It was a bit optimistic to stick an unconditional GFP_KERNEL allocation
into the previously-atomic kobject_init().
It's only 128 bytes, so why can't we fix both problems thusly?
--- a/lib/kobject.c~a
+++ a/lib/kobject.c
@@ -38,12 +38,10 @@ static int ptr_in_range(void *ptr, void
static void verify_dynamic_kobject_allocation(struct kobject *kobj)
{
- char *namebuf;
+ char namebuf[KSYM_NAME_LEN];
const char *ret;
- namebuf = kzalloc(KSYM_NAME_LEN, GFP_KERNEL);
- ret = kallsyms_lookup((unsigned long)kobj, NULL, NULL, NULL,
- namebuf);
+ ret = kallsyms_lookup((unsigned long)kobj, NULL, NULL, NULL, namebuf);
/*
* This is the X86_32-only part of this function.
* This is here because it is valid to have a kobject
@@ -63,7 +61,7 @@ static void verify_dynamic_kobject_alloc
/* dump_stack(); */
pr_debug("---- end silly warning ----\n");
out:
- kfree(namebuf);
+ return;
}
#else
static void verify_dynamic_kobject_allocation(struct kobject *kobj) { }
_
> Yes, but if somebody could tell me why nobody takes the patch, I would
> be happy. Then I would be able to improve the patch. :)
Copy me on the patch. Then I merge it and people know there will be no
hiding from it.
On Wednesday 30 July 2008, Andrew Morton wrote:
> On Wed, 30 Jul 2008 09:06:50 +0200 Bernhard Walle <[email protected]> wrote:
>
> > * Greg KH <[email protected]> [2008-07-29 21:48]:
> > > > Isn't this the opposite end of the same problem for which Bernhard
> > > > has been repeatedly trying to find a taker for his patch:
> > > >
> > > > http://article.gmane.org/gmane.linux.kernel.kexec/1882
> > >
> > > Yes. It's not the kobject patch at fault here, it's the use of kobjects
> > > so early in the boot process. That needs to be fixed.
>
> It was a bit optimistic to stick an unconditional GFP_KERNEL allocation
> into the previously-atomic kobject_init().
>
> It's only 128 bytes, so why can't we fix both problems thusly?
Fixes the bug for me (also true for previous patch from Bernhard).
Thanks!
On Wednesday 30 July 2008, Stephen Rothwell wrote:
> Hi Bart,
>
> On Tue, 29 Jul 2008 18:25:14 +0200 Bartlomiej Zolnierkiewicz <[email protected]> wrote:
> >
> > I keep reverting commit 0e3638d1e04040121af00195f7e4628078246489 ("warn
> > when statically-allocated kobjects are used") with each linux-next release
> > to make it work on my x86_32 laptop (http://lkml.org/lkml/2008/7/19/114).
> >
> > Depending on the day I either forget to revert it on a first try or (lead by
> > incurable optimism) I don't try to revert it in hope that it was fixed.
> >
> > Unfortunately the result is always the same cursing-during-qemu-test-run
> > -> git-revert -> recompile cycle and a needless time loss.
> >
> > Could we have some action taken please?
>
> I have reverted that commit from linux-next today (its id has changed)
> and will do so until Greg or Dave tells me it has been fixed. To make
> life easier for me, Greg, it would be nice if you removed it from your
> series until that time.
Thanks but since now there is a fix (even two!) for the issue and Dave's
patch has the value of catching real bugs maybe we could have one of the
fixes in linux-next instead of revert?
PS ironically today's linux-next broke xorg for me... call me lucky...
Bart
On Wed, 30 Jul 2008 21:27:41 +0200
Bartlomiej Zolnierkiewicz <[email protected]> wrote:
> On Wednesday 30 July 2008, Andrew Morton wrote:
> > On Wed, 30 Jul 2008 09:06:50 +0200 Bernhard Walle <[email protected]> wrote:
> >
> > > * Greg KH <[email protected]> [2008-07-29 21:48]:
> > > > > Isn't this the opposite end of the same problem for which Bernhard
> > > > > has been repeatedly trying to find a taker for his patch:
> > > > >
> > > > > http://article.gmane.org/gmane.linux.kernel.kexec/1882
> > > >
> > > > Yes. It's not the kobject patch at fault here, it's the use of kobjects
> > > > so early in the boot process. That needs to be fixed.
> >
> > It was a bit optimistic to stick an unconditional GFP_KERNEL allocation
> > into the previously-atomic kobject_init().
> >
> > It's only 128 bytes, so why can't we fix both problems thusly?
>
> Fixes the bug for me (also true for previous patch from Bernhard).
>
Cool.
The offending patch has just got itself turfed from linux-next so my
fix now has nothing to fix.
We'll see what happens!
Hi Andrew,
On Wed, 30 Jul 2008 13:04:19 -0700 Andrew Morton <[email protected]> wrote:
>
> The offending patch has just got itself turfed from linux-next so my
> fix now has nothing to fix.
>
> We'll see what happens!
I will put Dave's patch back with yours on top of it (hoping that Greg
will take your patch).
--
Cheers,
Stephen Rothwell [email protected]
http://www.canb.auug.org.au/~sfr/
On Thu, Jul 31, 2008 at 09:41:05AM +1000, Stephen Rothwell wrote:
> Hi Andrew,
>
> On Wed, 30 Jul 2008 13:04:19 -0700 Andrew Morton <[email protected]> wrote:
> >
> > The offending patch has just got itself turfed from linux-next so my
> > fix now has nothing to fix.
> >
> > We'll see what happens!
>
> I will put Dave's patch back with yours on top of it (hoping that Greg
> will take your patch).
Greg will, it's in my queue.
thanks,
greg k-h
Hi Dominik,
On Tue, 29 Jul 2008 16:45:58 +0200 Dominik Brodowski <[email protected]> wrote:
>
> On Tue, Jul 29, 2008 at 05:23:37PM +1000, Stephen Rothwell wrote:
> > Changes since next-20080728:
>
> is linux-next now open for 2.6.28 stuff?
Yeah, I would say it is, now. (Notice how I cleverly delayed it for a
week :-))
--
Cheers,
Stephen Rothwell [email protected]
http://www.canb.auug.org.au/~sfr/
Hi Stephen,
On Mon, Aug 04, 2008 at 12:56:11AM +1000, Stephen Rothwell wrote:
> On Tue, 29 Jul 2008 16:45:58 +0200 Dominik Brodowski <[email protected]> wrote:
> >
> > On Tue, Jul 29, 2008 at 05:23:37PM +1000, Stephen Rothwell wrote:
> > > Changes since next-20080728:
> >
> > is linux-next now open for 2.6.28 stuff?
>
> Yeah, I would say it is, now. (Notice how I cleverly delayed it for a
> week :-))
Excellent. (Notice how I cunningly predicted this and sneaked in lots of
.28-stuff into pcmcia/master over the weekend ;-)).
Best,
Dominik
HI Greg,
On Wed, 30 Jul 2008 16:44:19 -0700 Greg KH <[email protected]> wrote:
>
> On Thu, Jul 31, 2008 at 09:41:05AM +1000, Stephen Rothwell wrote:
> > Hi Andrew,
> >
> > On Wed, 30 Jul 2008 13:04:19 -0700 Andrew Morton <[email protected]> wrote:
> > >
> > > The offending patch has just got itself turfed from linux-next so my
> > > fix now has nothing to fix.
> > >
> > > We'll see what happens!
> >
> > I will put Dave's patch back with yours on top of it (hoping that Greg
> > will take your patch).
>
> Greg will, it's in my queue.
This is still not in your patch series ... summary email with patch
repeated below.
--
Cheers,
Stephen Rothwell [email protected]
http://www.canb.auug.org.au/~sfr/
Date: Wed, 30 Jul 2008 02:19:47 -0700
From: Andrew Morton <[email protected]>
To: Bernhard Walle <[email protected]>
Cc: Greg KH <[email protected]>, Hugh Dickins <[email protected]>,
Greg KH <[email protected]>,
Bartlomiej Zolnierkiewicz <[email protected]>,
Stephen Rothwell <[email protected]>, [email protected],
LKML <[email protected]>,
Dave Hansen <[email protected]>
Subject: driver-core: kobject verification fixup
On Wed, 30 Jul 2008 09:06:50 +0200 Bernhard Walle <[email protected]> wrote:
> * Greg KH <[email protected]> [2008-07-29 21:48]:
> > > Isn't this the opposite end of the same problem for which Bernhard
> > > has been repeatedly trying to find a taker for his patch:
> > >
> > > http://article.gmane.org/gmane.linux.kernel.kexec/1882
> >
> > Yes. It's not the kobject patch at fault here, it's the use of kobjects
> > so early in the boot process. That needs to be fixed.
It was a bit optimistic to stick an unconditional GFP_KERNEL allocation
into the previously-atomic kobject_init().
It's only 128 bytes, so why can't we fix both problems thusly?
--- a/lib/kobject.c~a
+++ a/lib/kobject.c
@@ -38,12 +38,10 @@ static int ptr_in_range(void *ptr, void
static void verify_dynamic_kobject_allocation(struct kobject *kobj)
{
- char *namebuf;
+ char namebuf[KSYM_NAME_LEN];
const char *ret;
- namebuf = kzalloc(KSYM_NAME_LEN, GFP_KERNEL);
- ret = kallsyms_lookup((unsigned long)kobj, NULL, NULL, NULL,
- namebuf);
+ ret = kallsyms_lookup((unsigned long)kobj, NULL, NULL, NULL, namebuf);
/*
* This is the X86_32-only part of this function.
* This is here because it is valid to have a kobject
@@ -63,7 +61,7 @@ static void verify_dynamic_kobject_alloc
/* dump_stack(); */
pr_debug("---- end silly warning ----\n");
out:
- kfree(namebuf);
+ return;
}
#else
static void verify_dynamic_kobject_allocation(struct kobject *kobj) { }
_
> Yes, but if somebody could tell me why nobody takes the patch, I would
> be happy. Then I would be able to improve the patch. :)
Copy me on the patch. Then I merge it and people know there will be no
hiding from it.
On Thu, Aug 07, 2008 at 11:08:44AM +1000, Stephen Rothwell wrote:
> HI Greg,
>
> On Wed, 30 Jul 2008 16:44:19 -0700 Greg KH <[email protected]> wrote:
> >
> > On Thu, Jul 31, 2008 at 09:41:05AM +1000, Stephen Rothwell wrote:
> > > Hi Andrew,
> > >
> > > On Wed, 30 Jul 2008 13:04:19 -0700 Andrew Morton <[email protected]> wrote:
> > > >
> > > > The offending patch has just got itself turfed from linux-next so my
> > > > fix now has nothing to fix.
> > > >
> > > > We'll see what happens!
> > >
> > > I will put Dave's patch back with yours on top of it (hoping that Greg
> > > will take your patch).
> >
> > Greg will, it's in my queue.
>
> This is still not in your patch series ... summary email with patch
> repeated below.
Just went in about 3 hours ago :)
I merged it with the original, that's the best way to do it.
thanks,
greg k-h
Hi Greg,
On Wed, 6 Aug 2008 20:40:49 -0700 Greg KH <[email protected]> wrote:
>
> Just went in about 3 hours ago :)
Thanks.
> I merged it with the original, that's the best way to do it.
Yep.
--
Cheers,
Stephen Rothwell [email protected]
http://www.canb.auug.org.au/~sfr/