* Re: xen PV on HVM and initial domain merge in linux-next
From: Stefano Stabellini @ 2010-10-20 15:16 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Stefano Stabellini, linux-kernel@vger.kernel.org,
Konrad Rzeszutek Wilk, linux-next@vger.kernel.org, Andrew Morton,
Jeremy Fitzhardinge, Chris Wright, virtualization@lists.osdl.org,
xen-devel@lists.xensource.com
In-Reply-To: <20101020113256.3647b1d9.sfr@canb.auug.org.au>
On Wed, 20 Oct 2010, Stephen Rothwell wrote:
> Hi Stefano,
>
> [just casting the net a bit wider ...]
>
> On Tue, 19 Oct 2010 18:51:47 +0100 Stefano Stabellini <stefano.stabellini@eu.citrix.com> wrote:
> >
> > I forgot to CC the LKML and linux-next...
> >
> > On Tue, 19 Oct 2010, Stefano Stabellini wrote:
> > > Stephen,
> > > I have two patch series to merge in linux-next:
> > >
> > > PV on HVM: receive interrupts as xen events
> > > xen: initial domain support
> > >
> > > they have all the acked-by needed and are both stable since several
> > > weeks, however they depend on Konrad's xen-pcifront series and for this
> > > reason I waited until now to ask for a merge in linux-next.
> > >
> > > Could you please pull:
> > >
> > > git://xenbits.xen.org/people/sstabellini/linux-pvhvm.git linux-next-initial-domain-v4
> > >
> > > it contains both series rebased on Konrad's pcifront series merged on
> > > linux-next (warning: it still contains the merge commit of
> > > xen-pcifront-0.8.2 in linux-next).
> > > Let me know if you have any conflicts or if you need me to change the
> > > branch somehow.
>
> Not following the Xen develpment at all, I would like to have a positive
> reply from the listed Xen contacts, please,
>
Sure.
Jeremy?
> I do have concerns that this is turning up so late, but I realise that
> that is mainly due to a misunderstanding on the part of some of the Xen
> community.
>
Thank you very much for understanding!
> Also, the above tree is based on next-20101019 which means that I cannot
> use it as is. All the trees merged into linux-next must be base on some
> other stable tree (almost always Linus' tree). linux-next is rebuilt
> from scratch every day, so I cannot ever include a previous day's version.
>
> Merging in other stable trees is OK (as long as the other maintainer is
> aware of that and makes sure that their tree does not reabse).
>
> Basically what you send to me should be what you intend to send to Linus
> during the next merge window.
All right.
I merged Jeremy's and Konrad's branches (the ones you just merged on
linux-next) on top of linux 2.6.36 rc8, then I rebased my series on top
of the result.
Please checkout this branch:
git://xenbits.xen.org/people/sstabellini/linux-pvhvm.git 2.6.36-rc8-initial-domain-v5
and let me know if it is suitable, it shouldn't have any merge
conflicts.
Cheers,
Stefano
^ permalink raw reply
* RE: [Xen-devel] Re: xen PV on HVM and initial domain merge in linux-next
From: Dan Magenheimer @ 2010-10-20 15:11 UTC (permalink / raw)
To: Stephen Rothwell, Stefano Stabellini
Cc: xen-devel, Jeremy Fitzhardinge, Konrad Wilk, linux-kernel,
Chris Wright, virtualization, linux-next, Andrew Morton
In-Reply-To: <20101020113256.3647b1d9.sfr@canb.auug.org.au>
> Not following the Xen develpment at all, I would like to have a
> positive reply from the listed Xen contacts, please,
I am not officially listed as a maintainer for Xen, but fwiw:
Acked-by: Dan Magenheimer <dan.magenheimer@oracle.com>
And, Stephen, I think Chris Wright and virtualization@lists.osdl.org
are stale entries in the MAINTAINERS file for Xen development,
so you are unlikely to receive replies from him/them.
(Chris, virtualization@lists.osdl.org ... please feel free
to correct me if I am wrong.)
> -----Original Message-----
> From: Stephen Rothwell [mailto:sfr@canb.auug.org.au]
> Sent: Tuesday, October 19, 2010 6:33 PM
> To: Stefano Stabellini
> Cc: xen-devel@lists.xensource.com; Jeremy Fitzhardinge; Konrad
> Rzeszutek Wilk; linux-kernel@vger.kernel.org; Chris Wright;
> virtualization@lists.osdl.org; linux-next@vger.kernel.org; Andrew
> Morton
> Subject: [Xen-devel] Re: xen PV on HVM and initial domain merge in
> linux-next
>
> Hi Stefano,
>
> [just casting the net a bit wider ...]
>
> On Tue, 19 Oct 2010 18:51:47 +0100 Stefano Stabellini
> <stefano.stabellini@eu.citrix.com> wrote:
> >
> > I forgot to CC the LKML and linux-next...
> >
> > On Tue, 19 Oct 2010, Stefano Stabellini wrote:
> > > Stephen,
> > > I have two patch series to merge in linux-next:
> > >
> > > PV on HVM: receive interrupts as xen events
> > > xen: initial domain support
> > >
> > > they have all the acked-by needed and are both stable since several
> > > weeks, however they depend on Konrad's xen-pcifront series and for
> this
> > > reason I waited until now to ask for a merge in linux-next.
> > >
> > > Could you please pull:
> > >
> > > git://xenbits.xen.org/people/sstabellini/linux-pvhvm.git linux-
> next-initial-domain-v4
> > >
> > > it contains both series rebased on Konrad's pcifront series merged
> on
> > > linux-next (warning: it still contains the merge commit of
> > > xen-pcifront-0.8.2 in linux-next).
> > > Let me know if you have any conflicts or if you need me to change
> the
> > > branch somehow.
>
> Not following the Xen develpment at all, I would like to have a
> positive
> reply from the listed Xen contacts, please,
>
> I do have concerns that this is turning up so late, but I realise that
> that is mainly due to a misunderstanding on the part of some of the Xen
> community.
>
> Also, the above tree is based on next-20101019 which means that I
> cannot
> use it as is. All the trees merged into linux-next must be base on
> some
> other stable tree (almost always Linus' tree). linux-next is rebuilt
> from scratch every day, so I cannot ever include a previous day's
> version.
>
> Merging in other stable trees is OK (as long as the other maintainer is
> aware of that and makes sure that their tree does not reabse).
>
> Basically what you send to me should be what you intend to send to
> Linus
> during the next merge window.
>
> --
> Cheers,
> Stephen Rothwell sfr@canb.auug.org.au
> http://www.canb.auug.org.au/~sfr/
^ permalink raw reply
* Re: linux-next: build failure after merge of the final tree (security-testing tree related)
From: Eric Paris @ 2010-10-20 11:46 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: James Morris, linux-next, linux-kernel
In-Reply-To: <20101020161024.af794b4a.sfr@canb.auug.org.au>
On Wed, 2010-10-20 at 16:10 +1100, Stephen Rothwell wrote:
> Hi James,
>
> After merging the final tree, today's linux-next build (powerpc
> allyesconfig) failed like this:
>
> security/selinux/ss/services.c: In function 'security_read_policy':
> security/selinux/ss/services.c:3172: error: implicit declaration of function 'vmalloc_user'
> security/selinux/ss/services.c:3172: warning: assignment makes pointer from integer without a cast
>
> Caused by commit ed167abda544bb7f8cf09dc3d3608c79e1cfb25f ("SELinux:
> allow userspace to read policy back out of the kernel") and
> bb17427490e1e295f3c0550c308684bd952a585d ("selinux: implement mmap
> on /selinux/policy").
>
> Please see Rule 1 (in Documentation/SubmitChecklist).
>
> I applied the following patch for today:
>
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Wed, 20 Oct 2010 16:08:00 +1100
> Subject: [PATCH] selinux: include vmalloc.h for vmalloc_user
Huh, not sure why it builds cleanly here. I'm applying my patch series
on top of linux-next from the 18th. In any case this looks correct.
Acked-by: Eric Paris <eparis@redhat.com>
>
> ---
> security/selinux/ss/services.c | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/security/selinux/ss/services.c b/security/selinux/ss/services.c
> index 3a1739b..223c1ff 100644
> --- a/security/selinux/ss/services.c
> +++ b/security/selinux/ss/services.c
> @@ -51,6 +51,7 @@
> #include <linux/mutex.h>
> #include <linux/selinux.h>
> #include <linux/flex_array.h>
> +#include <linux/vmalloc.h>
> #include <net/netlabel.h>
>
> #include "flask.h"
> --
> 1.7.1
>
^ permalink raw reply
* Re: [PATCH V10] RO/NX protection for loadable kernel modules
From: Rusty Russell @ 2010-10-20 5:59 UTC (permalink / raw)
To: Kees Cook
Cc: H. Peter Anvin, Siarhei Liakh, linux-kernel,
linux-security-module, linux-next, Arjan van de Ven, James Morris,
Andrew Morton, Andi Kleen, Thomas Gleixner, Ingo Molnar,
Stephen Rothwell, Dave Jones
In-Reply-To: <20101020044539.GX6311@outflux.net>
On Wed, 20 Oct 2010 03:15:39 pm Kees Cook wrote:
> Hi,
...
> Sorry for losing track, but where did this patch end up? I don't see it
> in any of the trees I've looked in.
Good question... This would be quite nice to have of course.
Rusty.
^ permalink raw reply
* linux-next: Tree for October 20
From: Stephen Rothwell @ 2010-10-20 5:20 UTC (permalink / raw)
To: linux-next; +Cc: LKML
[-- Attachment #1: Type: text/plain, Size: 11700 bytes --]
Hi all,
Changes since 20101019:
The arm tree lost its conflicts.
The s5p tree lost its merge fix patch.
The v4l-dvb tree still has a build failure for which I applied a patch.
The drm tree lost its conflict.
The security-testing tree lost its build failure but gained another for
which I applied a patch.
The tip tree lost its build failure.
The swiotlb-xen tree gained a conflict against the pci tree.
----------------------------------------------------------------------------
I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/v2.6/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 (32 and
64 bit), ppc44x_defconfig and allyesconfig (minus
CONFIG_PROFILE_ALL_BRANCHES - this fails its final link) and i386, sparc
and sparc64 defconfig. These builds also have
CONFIG_ENABLE_WARN_DEPRECATED, CONFIG_ENABLE_MUST_CHECK and
CONFIG_DEBUG_INFO disabled when necessary.
Below is a summary of the state of the merge.
We are up to 176 trees (counting Linus' and 22 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 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 fixes/fixes
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/rc-fixes
Merging quilt/driver-core.current
Merging quilt/tty.current
Merging quilt/usb.current
Merging quilt/staging.current
Merging cpufreq-current/fixes
Merging input-current/for-linus
Merging md-current/for-linus
Merging audit-current/for-linus
Merging crypto-current/master
Merging ide-curent/master
Merging dwmw2/master
Merging gcl-current/merge
Merging arm/devel
Merging davinci/davinci-next
Merging i.MX/for-next
Merging msm/for-next
Merging omap/for-next
Merging pxa/for-next
Merging samsung/next-samsung
Merging s5p/for-next
Merging tegra/for-next
Merging avr32/avr32-arch
Merging blackfin/for-linus
Merging cris/for-next
Merging ia64/test
Merging m68k/for-next
Merging m68knommu/for-next
Merging microblaze/next
Merging mips/mips-for-linux-next
Merging parisc/next
Merging powerpc/next
Merging 4xx/next
Merging 52xx-and-virtex/next
Merging galak/next
Merging s390/features
Merging sh/master
Merging genesis/master
Merging sparc/master
Merging tile/master
Merging xtensa/master
CONFLICT (content): Merge conflict in arch/xtensa/configs/iss_defconfig
Merging ceph/for-next
Merging cifs/master
Merging configfs/linux-next
Merging ecryptfs/next
Merging ext3/for_next
Merging ext4/next
Merging fatfs/master
Merging fuse/for-next
Merging gfs2/master
Merging hfsplus/for-next
Merging jfs/next
Merging logfs/master
CONFLICT (content): Merge conflict in fs/logfs/logfs.h
Merging nfs/linux-next
Merging nfsd/nfsd-next
Merging nilfs2/for-next
Merging ocfs2/linux-next
Merging omfs/for-next
Merging squashfs/master
Merging udf/for_next
Merging v9fs/for-next
Merging ubifs/linux-next
Merging xfs/master
Merging vfs/for-next
Merging pci/linux-next
Merging hid/for-next
Merging quilt/i2c
Merging bjdooks-i2c/next-i2c
Merging quilt/jdelvare-hwmon
Merging hwmon-staging/hwmon-next
Merging quilt/kernel-doc
Merging v4l-dvb/master
Applying: v4l-dvb: using vmalloc needs vmalloc.h in cx231xx-417.c
Merging kbuild/for-next
Merging kconfig/for-next
Merging ide/master
Merging libata/NEXT
Merging infiniband/for-next
Merging acpi/test
Merging idle-test/idle-test
Merging ieee1394/for-next
Merging ubi/linux-next
Merging kvm/linux-next
Merging dlm/next
Merging swiotlb/master
Merging ibft/master
Merging scsi/master
Merging async_tx/next
Merging net/master
CONFLICT (content): Merge conflict in Documentation/feature-removal-schedule.txt
CONFLICT (content): Merge conflict in arch/arm/mach-omap2/board-zoom-peripherals.c
CONFLICT (delete/modify): drivers/ieee1394/eth1394.c deleted in HEAD and modified in net/master. Version net/master of drivers/ieee1394/eth1394.c left in tree.
$ git rm -f drivers/ieee1394/eth1394.c
Merging wireless/master
Merging bluetooth/master
Merging mtd/master
Merging crypto/master
CONFLICT (content): Merge conflict in arch/arm/mach-omap2/devices.c
Merging sound/for-next
CONFLICT (content): Merge conflict in arch/arm/mach-s3c64xx/dev-audio.c
CONFLICT (content): Merge conflict in drivers/video/sh_mobile_hdmi.c
Merging sound-asoc/for-next
Merging cpufreq/next
Merging quilt/rr
Merging input/next
CONFLICT (content): Merge conflict in drivers/input/keyboard/Kconfig
Merging lsm/for-next
Merging block/for-next
CONFLICT (content): Merge conflict in fs/ext4/mballoc.c
Applying: ext4: merge fix for blkdev_issue_zeroout API change
Merging quilt/device-mapper
Merging embedded/master
Merging firmware/master
Merging pcmcia/master
CONFLICT (content): Merge conflict in drivers/net/pcmcia/smc91c92_cs.c
Merging battery/master
Merging leds/for-mm
Merging backlight/for-mm
Merging mmc/mmc-next
Merging kgdb/kgdb-next
CONFLICT (content): Merge conflict in drivers/char/sysrq.c
Merging slab/for-next
Merging uclinux/for-next
Merging md/for-next
Merging mfd/for-next
CONFLICT (content): Merge conflict in drivers/mfd/sh_mobile_sdhi.c
Merging hdlc/hdlc-next
Merging drm/drm-next
Merging viafb/viafb-next
Merging voltage/for-next
Merging security-testing/next
Merging lblnet/master
Merging agp/agp-next
Merging uwb/for-upstream
Merging watchdog/master
Merging bdev/master
Merging dwmw2-iommu/master
Merging cputime/cputime
Merging osd/linux-next
Merging jc_docs/docs-next
Merging nommu/master
Merging trivial/for-next
CONFLICT (content): Merge conflict in net/irda/irnet/irnet_ppp.c
Merging audit/for-next
Merging quilt/aoe
Merging suspend/linux-next
Merging fsnotify/for-next
Merging irda/for-next
Merging catalin/for-next
CONFLICT (content): Merge conflict in arch/arm/kernel/Makefile
CONFLICT (content): Merge conflict in arch/arm/mach-vexpress/ct-ca9x4.c
CONFLICT (content): Merge conflict in arch/arm/mm/flush.c
Merging alacrity/linux-next
CONFLICT (content): Merge conflict in include/linux/Kbuild
Merging i7core_edac/linux_next
CONFLICT (content): Merge conflict in MAINTAINERS
Merging i7300_edac/linux_next
Merging devicetree/next-devicetree
Merging spi/next-spi
CONFLICT (content): Merge conflict in drivers/spi/Kconfig
CONFLICT (content): Merge conflict in drivers/spi/Makefile
Merging omap_dss2/for-next
Merging tip/auto-latest
CONFLICT (content): Merge conflict in arch/powerpc/kernel/time.c
CONFLICT (content): Merge conflict in arch/sh/kernel/perf_event.c
CONFLICT (content): Merge conflict in include/linux/percpu.h
CONFLICT (content): Merge conflict in net/core/dev.c
Merging rcu/rcu/next
Merging oprofile/for-next
Merging xen/upstream/xen
Merging swiotlb-xen/master
CONFLICT (content): Merge conflict in drivers/pci/Makefile
Merging edac-amd/for-next
Merging percpu/for-next
CONFLICT (content): Merge conflict in include/linux/percpu.h
CONFLICT (content): Merge conflict in mm/percpu.c
Merging workqueues/for-next
CONFLICT (content): Merge conflict in fs/gfs2/main.c
Merging sfi/sfi-test
Merging asm-generic/next
Merging drivers-x86/linux-next
Merging hwpoison/hwpoison
Merging sysctl/master
Merging quilt/driver-core
CONFLICT (content): Merge conflict in drivers/misc/Makefile
Merging quilt/tty
Merging quilt/usb
CONFLICT (content): Merge conflict in drivers/usb/gadget/rndis.c
CONFLICT (content): Merge conflict in drivers/usb/host/Kconfig
CONFLICT (content): Merge conflict in drivers/usb/host/Makefile
Applying: scsi/sd: update for hw_sector_size rename
Merging staging-next/staging-next
CONFLICT (rename/modify): Merge conflict in drivers/misc/ti-st/st_core.c
CONFLICT (rename/modify): Merge conflict in drivers/misc/ti-st/st_kim.c
CONFLICT (content): Merge conflict in arch/arm/plat-omap/devices.c
CONFLICT (content): Merge conflict in drivers/misc/Makefile
CONFLICT (content): Merge conflict in drivers/staging/Makefile
CONFLICT (content): Merge conflict in drivers/staging/batman-adv/hard-interface.c
CONFLICT (content): Merge conflict in drivers/staging/cx25821/cx25821-audio-upstream.c
CONFLICT (content): Merge conflict in drivers/staging/cx25821/cx25821-audio.h
CONFLICT (delete/modify): drivers/staging/mrst-touchscreen/Makefile deleted in HEAD and modified in staging-next/staging-next. Version staging-next/staging-next of drivers/staging/mrst-touchscreen/Makefile left in tree.
CONFLICT (delete/modify): drivers/staging/mrst-touchscreen/intel-mid-touch.c deleted in HEAD and modified in staging-next/staging-next. Version staging-next/staging-next of drivers/staging/mrst-touchscreen/intel-mid-touch.c left in tree.
CONFLICT (delete/modify): drivers/staging/ti-st/st.h deleted in staging-next/staging-next and modified in HEAD. Version HEAD of drivers/staging/ti-st/st.h left in tree.
CONFLICT (delete/modify): drivers/staging/ti-st/st_core.h deleted in staging-next/staging-next and modified in HEAD. Version HEAD of drivers/staging/ti-st/st_core.h left in tree.
$ git rm -f drivers/staging/mrst-touchscreen/Makefile drivers/staging/mrst-touchscreen/intel-mid-touch.c
$ git rm -f drivers/staging/ti-st/st.h drivers/staging/ti-st/st_core.h
Applying: staging: ath6kl: Fixing the driver to use modified mmc_host structure
Merging slabh/slabh
Merging bkl-trivial/trivial
CONFLICT (content): Merge conflict in drivers/block/ataflop.c
CONFLICT (content): Merge conflict in drivers/char/pcmcia/cm4000_cs.c
CONFLICT (content): Merge conflict in drivers/char/pcmcia/cm4040_cs.c
CONFLICT (content): Merge conflict in drivers/mmc/card/block.c
Merging bkl-llseek/llseek
CONFLICT (content): Merge conflict in drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
CONFLICT (content): Merge conflict in drivers/net/wireless/ath/ath9k/debug.c
Applying: ath9k: fix up for .llseek fop change
Merging bkl-vfs/vfs
CONFLICT (content): Merge conflict in fs/cifs/cifsfs.c
CONFLICT (content): Merge conflict in fs/nilfs2/super.c
Merging bkl-config/config
CONFLICT (content): Merge conflict in fs/compat_ioctl.c
Merging irqflags/master
Merging cleancache/linux-next
CONFLICT (content): Merge conflict in include/linux/fs.h
CONFLICT (content): Merge conflict in mm/Kconfig
Merging scsi-post-merge/merge-base:master
Applying: selinux: include vmalloc.h for vmalloc_user
[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* linux-next: build failure after merge of the final tree (security-testing tree related)
From: Stephen Rothwell @ 2010-10-20 5:10 UTC (permalink / raw)
To: James Morris; +Cc: linux-next, linux-kernel, Eric Paris
Hi James,
After merging the final tree, today's linux-next build (powerpc
allyesconfig) failed like this:
security/selinux/ss/services.c: In function 'security_read_policy':
security/selinux/ss/services.c:3172: error: implicit declaration of function 'vmalloc_user'
security/selinux/ss/services.c:3172: warning: assignment makes pointer from integer without a cast
Caused by commit ed167abda544bb7f8cf09dc3d3608c79e1cfb25f ("SELinux:
allow userspace to read policy back out of the kernel") and
bb17427490e1e295f3c0550c308684bd952a585d ("selinux: implement mmap
on /selinux/policy").
Please see Rule 1 (in Documentation/SubmitChecklist).
I applied the following patch for today:
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Wed, 20 Oct 2010 16:08:00 +1100
Subject: [PATCH] selinux: include vmalloc.h for vmalloc_user
---
security/selinux/ss/services.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/security/selinux/ss/services.c b/security/selinux/ss/services.c
index 3a1739b..223c1ff 100644
--- a/security/selinux/ss/services.c
+++ b/security/selinux/ss/services.c
@@ -51,6 +51,7 @@
#include <linux/mutex.h>
#include <linux/selinux.h>
#include <linux/flex_array.h>
+#include <linux/vmalloc.h>
#include <net/netlabel.h>
#include "flask.h"
--
1.7.1
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
^ permalink raw reply related
* Re: [PATCH V10] RO/NX protection for loadable kernel modules
From: Kees Cook @ 2010-10-20 4:45 UTC (permalink / raw)
To: Rusty Russell
Cc: H. Peter Anvin, Siarhei Liakh, linux-kernel,
linux-security-module, linux-next, Arjan van de Ven, James Morris,
Andrew Morton, Andi Kleen, Thomas Gleixner, Ingo Molnar,
Stephen Rothwell, Dave Jones
In-Reply-To: <201002081159.45219.rusty@rustcorp.com.au>
Hi,
On Mon, Feb 08, 2010 at 11:59:44AM +1030, Rusty Russell wrote:
> On Tue, 2 Feb 2010 04:36:49 pm H. Peter Anvin wrote:
> > On 02/01/2010 07:59 PM, Rusty Russell wrote:
> > > On Tue, 2 Feb 2010 10:09:53 am Siarhei Liakh wrote:
> > >> This patch is a logical extension of the protection provided by
> > >> CONFIG_DEBUG_RODATA to LKMs. The protection is provided by splitting
> > >> module_core and module_init into three logical parts each and setting
> > >> appropriate page access permissions for each individual section:
> > >>
> > >> 1. Code: RO+X
> > >> 2. RO data: RO+NX
> > >> 3. RW data: RW+NX
> > >
> > > Thanks, applied!
> >
> > I also applied this to the -tip tree... do you prefer to carry it or
> > should I leave it as is?
>
> I'm always happy for you to do my work for me! There are no other module
> patches likely to conflict.
>
> Acked-by: Rusty Russell <rusty@rustcorp.com.au>
Sorry for losing track, but where did this patch end up? I don't see it
in any of the trees I've looked in.
Thanks,
-Kees
--
Kees Cook
Ubuntu Security Team
^ permalink raw reply
* linux-next: manual merge of the swiotlb-xen tree with the pci tree
From: Stephen Rothwell @ 2010-10-20 3:09 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk
Cc: linux-next, linux-kernel, matt mooney, Jesse Barnes, Ryan Wilson
Hi Konrad,
Today's linux-next merge of the swiotlb-xen tree got a conflict in
drivers/pci/Makefile between commit
350a55e9ff6005032407d3234af800f413b03af5 ("PCI: use new ccflags variable
in Makefile") from the pci tree and commit
956a9202cd1220397933a07beda9f96b3df1fa24 ("xen-pcifront: Xen PCI frontend
driver") from the swiotlb-xen tree.
Just context changes. I fixed it up (see below) and can carry the fix as
necessary.
As I said in my other email, Konrad, you can ignore this report - it is
just for information. The conflict resolution is simple.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --cc drivers/pci/Makefile
index dcd7ace,d5e2705..0000000
--- a/drivers/pci/Makefile
+++ b/drivers/pci/Makefile
@@@ -65,4 -65,8 +65,6 @@@ obj-$(CONFIG_PCI_SYSCALL) += syscall.
obj-$(CONFIG_PCI_STUB) += pci-stub.o
+ obj-$(CONFIG_XEN_PCIDEV_FRONTEND) += xen-pcifront.o
+
-ifeq ($(CONFIG_PCI_DEBUG),y)
-EXTRA_CFLAGS += -DDEBUG
-endif
+ccflags-$(CONFIG_PCI_DEBUG) := -DDEBUG
^ permalink raw reply
* Re: xen PV on HVM and initial domain merge in linux-next
From: Stephen Rothwell @ 2010-10-20 0:32 UTC (permalink / raw)
To: Stefano Stabellini
Cc: xen-devel, Jeremy Fitzhardinge, Konrad Rzeszutek Wilk,
linux-kernel, Chris Wright, virtualization, linux-next,
Andrew Morton
In-Reply-To: <alpine.DEB.2.00.1010191847290.10348@kaball-desktop>
[-- Attachment #1.1: Type: text/plain, Size: 1976 bytes --]
Hi Stefano,
[just casting the net a bit wider ...]
On Tue, 19 Oct 2010 18:51:47 +0100 Stefano Stabellini <stefano.stabellini@eu.citrix.com> wrote:
>
> I forgot to CC the LKML and linux-next...
>
> On Tue, 19 Oct 2010, Stefano Stabellini wrote:
> > Stephen,
> > I have two patch series to merge in linux-next:
> >
> > PV on HVM: receive interrupts as xen events
> > xen: initial domain support
> >
> > they have all the acked-by needed and are both stable since several
> > weeks, however they depend on Konrad's xen-pcifront series and for this
> > reason I waited until now to ask for a merge in linux-next.
> >
> > Could you please pull:
> >
> > git://xenbits.xen.org/people/sstabellini/linux-pvhvm.git linux-next-initial-domain-v4
> >
> > it contains both series rebased on Konrad's pcifront series merged on
> > linux-next (warning: it still contains the merge commit of
> > xen-pcifront-0.8.2 in linux-next).
> > Let me know if you have any conflicts or if you need me to change the
> > branch somehow.
Not following the Xen develpment at all, I would like to have a positive
reply from the listed Xen contacts, please,
I do have concerns that this is turning up so late, but I realise that
that is mainly due to a misunderstanding on the part of some of the Xen
community.
Also, the above tree is based on next-20101019 which means that I cannot
use it as is. All the trees merged into linux-next must be base on some
other stable tree (almost always Linus' tree). linux-next is rebuilt
from scratch every day, so I cannot ever include a previous day's version.
Merging in other stable trees is OK (as long as the other maintainer is
aware of that and makes sure that their tree does not reabse).
Basically what you send to me should be what you intend to send to Linus
during the next merge window.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #1.2: Type: application/pgp-signature, Size: 490 bytes --]
[-- Attachment #2: Type: text/plain, Size: 138 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
^ permalink raw reply
* Re: [PATCH] secmark: fix config problem when CONFIG_NF_CONNTRACK_SECMARK is not set
From: James Morris @ 2010-10-19 22:34 UTC (permalink / raw)
To: Eric Paris; +Cc: linux-next, linux-kernel, paul.moore, kaber, sfr
In-Reply-To: <20101019221732.11590.22215.stgit@paris.rdu.redhat.com>
On Tue, 19 Oct 2010, Eric Paris wrote:
> When CONFIG_NF_CONNTRACK_SECMARK is not set we accidentally attempt to use
> the secmark fielf of struct nf_conn. Problem is when that config isn't set
> the field doesn't exist. whoops. Wrap the incorrect usage in the config.
>
> Signed-off-by: Eric Paris <eparis@redhat.com>
Applied to
git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/security-testing-2.6#next
--
James Morris
<jmorris@namei.org>
^ permalink raw reply
* [PATCH] secmark: fix config problem when CONFIG_NF_CONNTRACK_SECMARK is not set
From: Eric Paris @ 2010-10-19 22:17 UTC (permalink / raw)
To: jmorris; +Cc: linux-next, linux-kernel, paul.moore, kaber, sfr
When CONFIG_NF_CONNTRACK_SECMARK is not set we accidentally attempt to use
the secmark fielf of struct nf_conn. Problem is when that config isn't set
the field doesn't exist. whoops. Wrap the incorrect usage in the config.
Signed-off-by: Eric Paris <eparis@redhat.com>
---
net/netfilter/nf_conntrack_netlink.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/net/netfilter/nf_conntrack_netlink.c b/net/netfilter/nf_conntrack_netlink.c
index b3c6285..146476c 100644
--- a/net/netfilter/nf_conntrack_netlink.c
+++ b/net/netfilter/nf_conntrack_netlink.c
@@ -582,9 +582,11 @@ ctnetlink_conntrack_event(unsigned int events, struct nf_ct_event *item)
&& ctnetlink_dump_helpinfo(skb, ct) < 0)
goto nla_put_failure;
+#ifdef CONFIG_NF_CONNTRACK_SECMARK
if ((events & (1 << IPCT_SECMARK) || ct->secmark)
&& ctnetlink_dump_secctx(skb, ct) < 0)
goto nla_put_failure;
+#endif
if (events & (1 << IPCT_RELATED) &&
ctnetlink_dump_master(skb, ct) < 0)
^ permalink raw reply related
* Re: linux-next: manual merge of the msm tree with the arm tree
From: Daniel Walker @ 2010-10-19 19:24 UTC (permalink / raw)
To: Russell King
Cc: Nicolas Pitre, Arnd Bergmann, Joe Perches, Stephen Rothwell,
linux-next, lkml, Jeremy Kerr, Jeff Ohlstein
In-Reply-To: <20101019185313.GB11088@flint.arm.linux.org.uk>
On Tue, 2010-10-19 at 19:53 +0100, Russell King wrote:
> On Tue, Oct 19, 2010 at 11:42:37AM -0700, Daniel Walker wrote:
> >
> > > That's why on occasions we do transgress the established process to
> > > accommodate such changes. Imagine just for a moment the patch that
> > > modified the interrupt callback prototype to remove the useless pt_regs
> > > argument. Obviously, it had to be done atomically to the _whole_ tree,
> > > and it was agreed that this patch was to be applied at the end of the
> > > merge window. But no one expected a single minute sending a CC to _all_
> > > the driver authors.
> >
> > I don't actually know which patch your talking about, but it sounds
> > pretty simple.. I'm not really addressing really simple fixes, even tho
> > changing a single parameter on a function could be done broken up
> > depending on what it is.
>
> As you think that it's a simple matter, I challenge you to break this
> change up in a way that doesn't result in any build breakage:
> 7d12e780e003f93433d49ce78cfedf4b4c52adc5
I wasn't saying it's simple to break patches up. I was just saying the
patch sounded like something simple, like running sed over the source or
a change replace type patch.
I'll look at the patch you reference tho, maybe I can break it up.
Daniel
^ permalink raw reply
* Re: linux-next: manual merge of the msm tree with the arm tree
From: Russell King @ 2010-10-19 18:53 UTC (permalink / raw)
To: Daniel Walker
Cc: Nicolas Pitre, Arnd Bergmann, Joe Perches, Stephen Rothwell,
linux-next, lkml, Jeremy Kerr, Jeff Ohlstein
In-Reply-To: <1287513757.10071.45.camel@c-dwalke-linux.qualcomm.com>
On Tue, Oct 19, 2010 at 11:42:37AM -0700, Daniel Walker wrote:
>
> > That's why on occasions we do transgress the established process to
> > accommodate such changes. Imagine just for a moment the patch that
> > modified the interrupt callback prototype to remove the useless pt_regs
> > argument. Obviously, it had to be done atomically to the _whole_ tree,
> > and it was agreed that this patch was to be applied at the end of the
> > merge window. But no one expected a single minute sending a CC to _all_
> > the driver authors.
>
> I don't actually know which patch your talking about, but it sounds
> pretty simple.. I'm not really addressing really simple fixes, even tho
> changing a single parameter on a function could be done broken up
> depending on what it is.
As you think that it's a simple matter, I challenge you to break this
change up in a way that doesn't result in any build breakage:
7d12e780e003f93433d49ce78cfedf4b4c52adc5
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of:
^ permalink raw reply
* Re: linux-next: manual merge of the msm tree with the arm tree
From: Daniel Walker @ 2010-10-19 18:49 UTC (permalink / raw)
To: Russell King
Cc: Arnd Bergmann, Joe Perches, Nicolas Pitre, Stephen Rothwell,
linux-next, lkml, Jeremy Kerr, Jeff Ohlstein
In-Reply-To: <20101019183448.GA11088@flint.arm.linux.org.uk>
On Tue, 2010-10-19 at 19:34 +0100, Russell King wrote:
> On Tue, Oct 19, 2010 at 10:03:26AM -0700, Daniel Walker wrote:
> > On Tue, 2010-10-19 at 15:18 +0200, Arnd Bergmann wrote:
> > > On Tuesday 19 October 2010, Joe Perches wrote:
> > > > This could have been done:
> > > >
> > > > $ git show 08a610d9ef5394525b0328da0162d7b58c982cc4 | ./scripts/get_maintainer.pl --nogit | wc -l
> > > > 35
> > > >
> > > > Even then, using 35 CCs is generally silly.
> > > >
> > > > It might make some sense for a cover letter and a
> > > > patch series where the series made tree-wide changes
> > > > in multiple directories.
> > >
> > > Probably not even then: When a single mail header gets too long, you usually land
> > > in some spam filter and get hate mail from the list owners. The lkml limit is 1024
> > > characters (this may come from an official RFC, don't know), which is usually less
> > > than 35 recipients.
> >
> > Patches just shouldn't be this large.
>
> Patches get large. Sometimes they can't be sensibly broken up. We
> have to accept them as is sometimes. This is one of those occasions.
> See the example Nicolas gave you - it's no different.
>
> As for you saying that I'm the one getting excited about this - I'm not.
> I'm getting pissed off by how much discussion effort this trivial matter
> is taking and how much time it's wasting, which really isn't necessary.
> There's far better things to be done (such as testing) rather than taking
> hours to sort out what is basically a trivial merge issue.
>
> Now, you've said in your pull request:
>
> | Here is your pull request Russell. This has the patch which was part of
> | the conflict in MSM, "msm: allow uart to be conditionally disabled"..
> |
> | It's on top of v2.6.36-rc5, and it has one patch that is already in your
> | tree. It's "GIC: Dont disable INT in ack callback" .
> |
> | This pull request is exactly what I would send to Linus is the merge
> | window was open.
>
> As I'm merging it into a tree which does _not_ have the changes from
> Jeremy and Nicolas, what's this "the patch which was part of the
> conflict" and what's it going to do without Nicolas' changes?
Um , the patches I sent you are un-altered from what was originally in
my tree prior to the conflict.
I was just making note of the fact that a conflict in -next happened in
relation to that patch in my tree. I wasn't suggesting that my tree
changed at all.
> The point of dropping Jeremy and Nicolas' changes are to return to a
> state where things were before the troublesome change, so that the
> existing code works. Then Nicolas was going to take what is in my
> tree, and update the patches to take account of what's there.
yeah, that's what I'm assuming.. So I sent you exactly what I would have
sent Linus , i.e. doesn't take into account and troublesome patches of
any kind.
> If you're going to pre-empt that by fixing the stuff yourself, this
> whole exercise has been pointless, because it means that the code in
> your tree currently won't build without these other changes.
There's nothing fixed in my tree. I sent you a the pre-fixed tree. And
the troublesome patches will need to be conflict resolved even after my
tree is pulled.
> So at the moment I don't know whether or not I should pull your tree.
The tree should be what you wanted ..
Daniel
^ permalink raw reply
* Re: linux-next: manual merge of the msm tree with the arm tree
From: Daniel Walker @ 2010-10-19 18:42 UTC (permalink / raw)
To: Nicolas Pitre
Cc: Arnd Bergmann, Joe Perches, Russell King, Stephen Rothwell,
linux-next, lkml, Jeremy Kerr, Jeff Ohlstein
In-Reply-To: <alpine.LFD.2.00.1010191314020.2764@xanadu.home>
> That's why on occasions we do transgress the established process to
> accommodate such changes. Imagine just for a moment the patch that
> modified the interrupt callback prototype to remove the useless pt_regs
> argument. Obviously, it had to be done atomically to the _whole_ tree,
> and it was agreed that this patch was to be applied at the end of the
> merge window. But no one expected a single minute sending a CC to _all_
> the driver authors.
I don't actually know which patch your talking about, but it sounds
pretty simple.. I'm not really addressing really simple fixes, even tho
changing a single parameter on a function could be done broken up
depending on what it is.
Daniel
^ permalink raw reply
* Re: linux-next: manual merge of the msm tree with the arm tree
From: Russell King @ 2010-10-19 18:34 UTC (permalink / raw)
To: Daniel Walker
Cc: Arnd Bergmann, Joe Perches, Nicolas Pitre, Stephen Rothwell,
linux-next, lkml, Jeremy Kerr, Jeff Ohlstein
In-Reply-To: <1287507806.10071.16.camel@c-dwalke-linux.qualcomm.com>
On Tue, Oct 19, 2010 at 10:03:26AM -0700, Daniel Walker wrote:
> On Tue, 2010-10-19 at 15:18 +0200, Arnd Bergmann wrote:
> > On Tuesday 19 October 2010, Joe Perches wrote:
> > > This could have been done:
> > >
> > > $ git show 08a610d9ef5394525b0328da0162d7b58c982cc4 | ./scripts/get_maintainer.pl --nogit | wc -l
> > > 35
> > >
> > > Even then, using 35 CCs is generally silly.
> > >
> > > It might make some sense for a cover letter and a
> > > patch series where the series made tree-wide changes
> > > in multiple directories.
> >
> > Probably not even then: When a single mail header gets too long, you usually land
> > in some spam filter and get hate mail from the list owners. The lkml limit is 1024
> > characters (this may come from an official RFC, don't know), which is usually less
> > than 35 recipients.
>
> Patches just shouldn't be this large.
Patches get large. Sometimes they can't be sensibly broken up. We
have to accept them as is sometimes. This is one of those occasions.
See the example Nicolas gave you - it's no different.
As for you saying that I'm the one getting excited about this - I'm not.
I'm getting pissed off by how much discussion effort this trivial matter
is taking and how much time it's wasting, which really isn't necessary.
There's far better things to be done (such as testing) rather than taking
hours to sort out what is basically a trivial merge issue.
Now, you've said in your pull request:
| Here is your pull request Russell. This has the patch which was part of
| the conflict in MSM, "msm: allow uart to be conditionally disabled"..
|
| It's on top of v2.6.36-rc5, and it has one patch that is already in your
| tree. It's "GIC: Dont disable INT in ack callback" .
|
| This pull request is exactly what I would send to Linus is the merge
| window was open.
As I'm merging it into a tree which does _not_ have the changes from
Jeremy and Nicolas, what's this "the patch which was part of the
conflict" and what's it going to do without Nicolas' changes?
The point of dropping Jeremy and Nicolas' changes are to return to a
state where things were before the troublesome change, so that the
existing code works. Then Nicolas was going to take what is in my
tree, and update the patches to take account of what's there.
If you're going to pre-empt that by fixing the stuff yourself, this
whole exercise has been pointless, because it means that the code in
your tree currently won't build without these other changes.
So at the moment I don't know whether or not I should pull your tree.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of:
^ permalink raw reply
* Re: xen PV on HVM and initial domain merge in linux-next
From: Stefano Stabellini @ 2010-10-19 17:51 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linux-kernel, Konrad Rzeszutek Wilk, linux-next
In-Reply-To: <alpine.DEB.2.00.1010191254460.2423@kaball-desktop>
I forgot to CC the LKML and linux-next...
On Tue, 19 Oct 2010, Stefano Stabellini wrote:
> Stephen,
> I have two patch series to merge in linux-next:
>
> PV on HVM: receive interrupts as xen events
> xen: initial domain support
>
> they have all the acked-by needed and are both stable since several
> weeks, however they depend on Konrad's xen-pcifront series and for this
> reason I waited until now to ask for a merge in linux-next.
>
> Could you please pull:
>
> git://xenbits.xen.org/people/sstabellini/linux-pvhvm.git linux-next-initial-domain-v4
>
> it contains both series rebased on Konrad's pcifront series merged on
> linux-next (warning: it still contains the merge commit of
> xen-pcifront-0.8.2 in linux-next).
> Let me know if you have any conflicts or if you need me to change the
> branch somehow.
>
> Many thanks in advance,
>
> Stefano Stabellini
>
^ permalink raw reply
* Re: linux-next: manual merge of the msm tree with the arm tree
From: Nicolas Pitre @ 2010-10-19 17:18 UTC (permalink / raw)
To: Daniel Walker
Cc: Arnd Bergmann, Joe Perches, Russell King, Stephen Rothwell,
linux-next, lkml, Jeremy Kerr, Jeff Ohlstein
In-Reply-To: <1287507806.10071.16.camel@c-dwalke-linux.qualcomm.com>
On Tue, 19 Oct 2010, Daniel Walker wrote:
> On Tue, 2010-10-19 at 15:18 +0200, Arnd Bergmann wrote:
> > On Tuesday 19 October 2010, Joe Perches wrote:
> > > This could have been done:
> > >
> > > $ git show 08a610d9ef5394525b0328da0162d7b58c982cc4 | ./scripts/get_maintainer.pl --nogit | wc -l
> > > 35
> > >
> > > Even then, using 35 CCs is generally silly.
> > >
> > > It might make some sense for a cover letter and a
> > > patch series where the series made tree-wide changes
> > > in multiple directories.
> >
> > Probably not even then: When a single mail header gets too long, you usually land
> > in some spam filter and get hate mail from the list owners. The lkml limit is 1024
> > characters (this may come from an official RFC, don't know), which is usually less
> > than 35 recipients.
>
> Patches just shouldn't be this large. You want smaller patches for a lot
> of reason. Take the BKL, would it have been acceptable to make all the
> BKL changes in a single patch (and what would the CC have looked like)?
> If you do anything remotely sophisticated then , from my perspective, a
> tree wide patch just isn't going to work.
That's why on occasions we do transgress the established process to
accommodate such changes. Imagine just for a moment the patch that
modified the interrupt callback prototype to remove the useless pt_regs
argument. Obviously, it had to be done atomically to the _whole_ tree,
and it was agreed that this patch was to be applied at the end of the
merge window. But no one expected a single minute sending a CC to _all_
the driver authors.
Nicolas
^ permalink raw reply
* Re: linux-next: manual merge of the msm tree with the arm tree
From: Daniel Walker @ 2010-10-19 17:03 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Joe Perches, Nicolas Pitre, Russell King, Stephen Rothwell,
linux-next, lkml, Jeremy Kerr, Jeff Ohlstein
In-Reply-To: <201010191518.04147.arnd@arndb.de>
On Tue, 2010-10-19 at 15:18 +0200, Arnd Bergmann wrote:
> On Tuesday 19 October 2010, Joe Perches wrote:
> > This could have been done:
> >
> > $ git show 08a610d9ef5394525b0328da0162d7b58c982cc4 | ./scripts/get_maintainer.pl --nogit | wc -l
> > 35
> >
> > Even then, using 35 CCs is generally silly.
> >
> > It might make some sense for a cover letter and a
> > patch series where the series made tree-wide changes
> > in multiple directories.
>
> Probably not even then: When a single mail header gets too long, you usually land
> in some spam filter and get hate mail from the list owners. The lkml limit is 1024
> characters (this may come from an official RFC, don't know), which is usually less
> than 35 recipients.
Patches just shouldn't be this large. You want smaller patches for a lot
of reason. Take the BKL, would it have been acceptable to make all the
BKL changes in a single patch (and what would the CC have looked like)?
If you do anything remotely sophisticated then , from my perspective, a
tree wide patch just isn't going to work.
Daniel
^ permalink raw reply
* Re: linux-next: manual merge of the msm tree with the arm tree
From: Daniel Walker @ 2010-10-19 16:55 UTC (permalink / raw)
To: Nicolas Pitre
Cc: Russell King, Stephen Rothwell, linux-next, lkml, Jeremy Kerr,
Jeff Ohlstein
In-Reply-To: <alpine.LFD.2.00.1010182227440.2764@xanadu.home>
On Mon, 2010-10-18 at 22:47 -0400, Nicolas Pitre wrote:
> On Mon, 18 Oct 2010, Daniel Walker wrote:
>
> > I can say that I know for a fact that people don't read every patch, or
> > every email, or keep track of every single thread. I don't think it's
> > reasonable to expect people to do that. there's too many email, too many
> > threads, too many discussions etc ..
>
> I'm not saying that you should keep track of every threads. But you
> should at least pay attention to what thread is being discussed, simply
> by looking at the subject line. Any good MUA will let you sort emails
> and collapse them into thread view. And scoring those incoming emails
> with "arch/arm/mach-msm" for example is a quick way for you to be
> noticed when a patch might be changing something in your area. Tools
> are there for you.
AFAIK before this thread, I should get CC'd when you modify me tree..
Maybe I'll setup some tools _now_ ..
> > This discussion isn't really about that. It's not about people reading
> > every single patch, which we know they don't do. This is about conflicts
> > in -next.
>
> Glad to get back to the original issue.
>
> > These patches caused conflicts in -next .. What more could I have done
> > to prevent conflicts coming from another tree and patches that appear
> > not to effect me? Even if I read all the patches, and threads, it still
> > seems unreasonable to expect maintainers to predict conflicts not coming
> > from their own tree's.
>
> In this particular case, Stephen did fix the trivial merge conflict.
> Most probably Linus could have done the same. There is nothing you
> needed to do in that case. Or you could have waited until RMK's tree
> hits mainline, then you merge that, fixing the issue within that merge,
> before asking Linus to pull.
>
> And if the merge in linux-next turned out not to be that trivial, or you
> have new machine entries in your tree that failed to compile due to the
> missing fixup, well that's fine too because that's _exactly_ what the
> purpose of the linux-next tree is: finding issues like this before the
> real merge in Linus' tree. So in this case the system did work: the
> conflict was identified by the tool and you were notified.
>
> And the simplest solution to this is simply to merge your stuff into
> RMK's tree in this case, so the generic change affecting all ARM
> machines will cover yours as well. Incidentally that's what has been
> asked of you.
>
> See? Nothing to really get excited about.
Am I excited? Russell is the one getting excited .. I was the one trying
to correct the issues , so Linus doesn't have to deal with it.
Daniel
^ permalink raw reply
* Re: linux-next: manual merge of the staging-next tree with the v4l-dvb tree
From: Greg KH @ 2010-10-19 15:53 UTC (permalink / raw)
To: Stephen Rothwell
Cc: linux-next, linux-kernel, Ruslan Pisarev, Mauro Carvalho Chehab,
Gorskin Ilya
In-Reply-To: <20101019172331.89476ae0.sfr@canb.auug.org.au>
On Tue, Oct 19, 2010 at 05:23:31PM +1100, Stephen Rothwell wrote:
> Hi Greg,
>
> On Tue, 19 Oct 2010 17:12:33 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > Today's linux-next merge of the staging-next tree got a conflict in
> > drivers/staging/cx25821/cx25821-audio-upstream.c between commit
> > d6a0215fc954bd16a21bad94a3292f080d9f6f04 ("[media] Staging: cx25821: fix
> > braces and space coding style issues") from the v4l-dvb tree and commit
> > bb59a4c539140592723e806e852ee171da0eb3eb ("Staging: cx25821: clenup
> > warnings found by checkpatch.pl tool in cx25821-audio-upstream.c and
> > cx25821-audio.h") from the staging-next tree.
> >
> > Basically different versions of the same patch. I fixed it up.
>
> Fixed conflicts in drivers/staging/cx25821/cx25821-audio.h as well.
Thanks for doing this, I appreciate it.
greg k-h
^ permalink raw reply
* Re: linux-next: build warning after merge of the cifs tree
From: Shirish Pargaonkar @ 2010-10-19 15:48 UTC (permalink / raw)
To: Jeff Layton
Cc: Stephen Rothwell, Steve French, linux-cifs-u79uwXL29TY76Z2rM5mHXA,
linux-next-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20101019091339.38e45faa-9yPaYZwiELC+kQycOl6kW4xkIHaj4LzF@public.gmane.org>
On Tue, Oct 19, 2010 at 8:13 AM, Jeff Layton <jlayton-eUNUBHrolfbYtjvyW6yDsg@public.gmane.org> wrote:
> On Tue, 19 Oct 2010 16:21:20 +1100
> Stephen Rothwell <sfr-3FnU+UHB4dNDw9hX6IcOSA@public.gmane.org> wrote:
>
>> Hi Steve,
>>
>> On Fri, 24 Sep 2010 13:55:31 +1000 Stephen Rothwell <sfr-3FnU+UHB4dNDw9hX6IcOSA@public.gmane.org> wrote:
>> >
>> > After merging the irqflags tree, today's linux-next build (powerpc
>> > ppc64_defconfig) produced this warning:
>> >
>> > fs/cifs/sess.c: In function 'CIFS_SessSetup':
>> > fs/cifs/sess.c:595: warning: unused variable 'blob_len'
>> >
>> > Introduced by commit 15f6bdfb9914b0c41848f874719911ba053be931 ("cifs
>> > NTLMv2/NTLMSSP ntlmv2 within ntlmssp autentication code").
>> > CONFIG_CIFS_UPCALL is not set in this build.
>>
>> I am still getting this ...
>>
>
> Yep. Looks clearly broken. blob_len is also declared twice in that
> function which is just plain wrong. What probably makes the most sense
> is to make it a u16 and get rid of the second declaration lower in the
> function. But, there's another semi-related problem here too...
>
> blob_len gets assigned the return value of build_ntlmssp_auth_blob.
> That function however doesn't have any mechanism to pass back an
> error, even though it calls setup_ntlmv2_rsp and that function can
> return one.
>
> The whole house of cards needs a bit of rework I think...
>
> Shirish, since you're already doing work in this area, can you fix that
> too?
>
> Thanks,
> --
> Jeff Layton <jlayton-eUNUBHrolfbYtjvyW6yDsg@public.gmane.org>
>
Looking into it.
^ permalink raw reply
* Re: linux-next: manual merge of the usb tree with the mips tree
From: Greg KH @ 2010-10-19 15:47 UTC (permalink / raw)
To: Stephen Rothwell
Cc: linux-next, linux-kernel, David Daney, Ralf Baechle,
Anatolij Gustschin
In-Reply-To: <20101018170911.63f76c60.sfr@canb.auug.org.au>
On Mon, Oct 18, 2010 at 05:09:11PM +1100, Stephen Rothwell wrote:
> Hi Greg,
>
> Today's linux-next merge of the usb tree got a conflict in
> drivers/usb/host/Makefile between commit
> cd97084c3aff6f1037e00ee711a872719b60441d ("USB: Add EHCI and OHCH glue
> for OCTEON II SOCs") from the mips tree and commit
> f668f1e9868f9bc1bed3d5df1701879ac89cc3ed ("USB: add platform glue driver
> for FSL USB DR controller") from the usb tree.
>
> I fixed it up (see below) and can carry the fix as necessary.
Thanks for the fix, looks fine.
greg k-h
^ permalink raw reply
* Re: linux-next: manual merge of the usb tree with the mips tree
From: Greg KH @ 2010-10-19 15:46 UTC (permalink / raw)
To: Stephen Rothwell
Cc: linux-next, linux-kernel, Anatolij Gustschin, David Daney,
Ralf Baechle
In-Reply-To: <20101018170619.25f6566f.sfr@canb.auug.org.au>
On Mon, Oct 18, 2010 at 05:06:19PM +1100, Stephen Rothwell wrote:
> Hi Greg,
>
> Today's linux-next merge of the usb tree got a conflict in
> drivers/usb/host/Kconfig between commit
> cd97084c3aff6f1037e00ee711a872719b60441d ("USB: Add EHCI and OHCH glue
> for OCTEON II SOCs") from the mips tree and commit
> c67a807cb13570bfc7b78f53158d14a433c59591 ("USB: add USB EHCI support for
> MPC5121 SoC") from the usb tree.
>
> I fixed it up (see below) and can carry the fix as necessary.
Thanks for the fix, looks fine.
greg k-h
^ permalink raw reply
* Re: linux-next: manual merge of the davinci tree with the arm tree
From: Kevin Hilman @ 2010-10-19 15:46 UTC (permalink / raw)
To: Stephen Rothwell
Cc: linux-next, linux-kernel, Sekhar Nori, Nicolas Pitre,
Russell King
In-Reply-To: <20101018103152.33fa12cd.sfr@canb.auug.org.au>
Stephen Rothwell <sfr@canb.auug.org.au> writes:
> Hi Kevin,
>
> Today's linux-next merge of the davinci tree got a conflicts in
> arch/arm/mach-davinci/board-da830-evm.c and
> arch/arm/mach-davinci/board-da850-evm.c between commit
> 861bd81ee62a0d6759144c22909a8a3938951656 ("arm: remove
> machine_desc.io_pg_offst and .phys_io") from the arm tree and commit
> 48ea89eabee96019a4a84615af921f8703320abb ("davinci: introduce support for
> AM1x ARM9 microprocessors") from the davinci tree.
>
> Just context changes, I fixed them up (see below) and can carry the fix
> as necessary.
Hi Stephen,
Thanks for carrying this.
Russell has (temporarily) dropped his version of the patch, but when he
adds it back (today, I believe) I will fix this up in the davinci tree
by pre-merging his branch with mine to handle this conflict.
Kevin
^ 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